À mesure que les agences gouvernementales, les fournisseurs de soins de santé et les institutions financières déploient de plus en plus de services complexes orientés réseau, la gamme d'appareils permettant d'accéder à ces systèmes continue de s'élargir. Parallèlement à ce développement, ces secteurs se concentrent de plus en plus sur la sécurité et la confidentialité des informations : les organisations investissent d'énormes sommes afin de répondre aux exigences de sécurité des données pour tout, des serveurs et équipements réseau aux ordinateurs portables, en passant par les smartphones et imprimantes. Par exemple, au cours des cinq prochaines années, le gouvernement fédéral américain investira plus de 500 milliards de dollars dans les technologies de l'information (IT)1, dont une part importante sera consacrée au Programme de modernisation de la cryptographie et aux activités apparentées au chiffrement et à la gestion des clés.
Pour aider à réduire la complexité et les coûts de ces besoins grandissants en sécurité et réseau, le gouvernement fédéral américain a publié des normes strictes et des exigences d'interopérabilité : exigences de sécurité de la norme Federal Information Processing Standard (FIPS) 140-2 pour les modules cryptographiques. Cette norme de sécurité cryptographique a été adoptée par plusieurs autres gouvernements, et est devenue une norme de référence dans la santé, la finance et dans le secteur émergent des réseaux intelligents. Dans le cadre du Programme de modernisation de la cryptographie du gouvernement américain, la mise en place d'autres techniques cryptographiques avancées, comme l'Elliptic Curve Cryptography2, augmente et devrait influencer l'avenir de la sécurité.
Pour soutenir la concurrence dans ces marchés, les fournisseurs de logiciels et d'appareils doivent prouver que leurs produits répondent aux exigences de cryptographie validées par la norme Federal Information Processing Standard (FIPS), un effort long, complexe et coûteux qui doit être réitéré à chaque mise à niveau de produit. Les fournisseurs doivent également veiller à ce que les mises à niveau, même les plus anodines, ne compromettent pas la conformité de leurs produits à la norme de sécurité FIPS, car ils doivent aussi constamment surveiller les normes eux-mêmes pour veiller à ce que leurs produits restent au niveau des exigences changeantes. La norme FIPS 140-3, définie pour remplacer la norme FIPS 140-2, est déjà disponible à l'état de brouillon.
Parmi les nombreux et divers composants qui constituent les systèmes logiciels d'aujourd'hui, deux sont considérés comme les plus importants pour la sécurité des systèmes :
- un système d'exploitation qui répond à des exigences de sécurité strictes pour la fiabilité
- un module de cryptographie validé par la norme FIPS
Dans ce document, nous examinons les défis clés associés au processus de validation de la norme FIPS 140-2, et décrivons en quoi le RTOS QNX® Neutrino® et la bibliothèque cryptographique Government Security Edition (GSE) de Certicom Security Builder peuvent aider à simplifier la création et la fourniture de logiciels conformes à la norme FIPS 140-2.
COTS et sécurité
À l'instar des autres organisations, les agences gouvernementales souhaiteraient pouvoir utiliser les produits COTS (Commercial Off-The-Shelf), afin de profiter de l'expertise et des économies offertes par les fournisseurs concurrents. Cependant, pour pouvoir être utilisés par ces agences, ces produits de fournisseurs COTS doivent respecter des exigences de sécurité strictes définies par (aux États-Unis) des organisations comme le Département de la Défense (DoD), l'Agence Nationale de Sécurité (NSA) et l'lnstitut National des Normes et Technologies (NIST). La norme FIPS 140-2 est le dénominateur commun des plus importantes directives de sécurité informatique ; le DoD, par exemple, fait référence à cette norme dans des directives régissant la communication des données sensibles.
Les secteurs de la santé et des services financiers sont également concernés par les exigences de sécurité de l'information, notamment avec le nombre croissant de divulgations de données personnelles. Les exigences de sécurité des données dans ces secteurs découlent des lois gouvernementales, dont le Health Insurance Portability and Accountability Act (HIPAA) et le Health Information Technology for Economic and Clinical Health (HITECH) Act pour les fournisseurs de soins de santé, et les règles du Gramm-Leach-Bliley Act (GLBA) sur la confidentialité des consommateurs pour les banques et les sociétés financières. Ces exigences conduisent naturellement les fournisseurs vers la norme FIPS 140-2 pour obtenir des conseils sur la cryptographie et la sécurité des données.
Les règles du HIPAA stipulent que « les processus de chiffrement valides pour les données mobiles sont conformes aux exigences de la norme Federal Information Processing Standard (FIPS) 140-2. » Ce même document précise que les données inactives doivent être protégées conformément à la norme Special Publication 800-1116 du NIST, qui recommande l'utilisation d'algorithmes cryptographiques certifiés FIPS. Plus loin, le HITECH Act promeut même l'utilisation de technologies de sécurité prouvées en proposant un allègement des audits aux organisations qui utilisent les produits certifiés FIPS.
Cependant, l'importance de la norme FIPS 140-2 ne s'arrête pas là. À mesure que les systèmes d'infrastructure critiques, comme la distribution de gaz et les systèmes de contrôle de réseaux intelligents, deviennent plus structurés en réseau, ces secteurs sont susceptibles d'adopter également des contrôles stricts sur la cryptographie utilisée pour protéger leurs données en transit, en créant davantage de demande pour les solutions de cryptographie certifiées FIPS.
Pour conquérir une part plus importante de ce marché croissant, ou même maintenir leurs positions actuelles, les fournisseurs COTS qui n'exigeaient pas de niveau élevé d'expertise en sécurité n'ont pas d'autre
choix que de mieux comprendre les normes de sécurité et technologies de cryptographie actuelles et futures, tout en surveillant étroitement les exigences changeantes de la norme FIPS. Ils doivent également trouver des moyens de relever le défi majeur de prendre en charge ces exigences dans des systèmes intégrés.
Des bases solides
Une exigence fondamentale pour tout système sécurisé est de fonctionner sur un système d'exploitation fiable. Bâtir un système sécurisé sur un système d'exploitation ne pouvant pas fournir de garanties de fiabilité est comme bâtir un coffre fort sur de la terre battue. Une personne finira par le remarquer et exploiter cette faiblesse fondamentale.
Les caractéristiques clés qui font du RTOS QNX Neutrino l'environnement idéal pour la bibliothèque cryptographique GSE de Certicom incluent :
Des garanties de fiabilité de temps réel : seul un système d'exploitation temps réel (RTOS) est conçu expressément pour des systèmes qui doivent répondre de manière correcte et prévisible aux requêtes en temps opportun.
Une architecture micro-noyau : avec l'architecture micro-noyau du RTOS QNX Neutrino, les applications, les pilotes d'appareils, les systèmes de fichiers et les piles réseau résident tous en dehors du noyau dans des espaces d'adresses séparés, et sont donc isolés du noyau et les uns des autres. Un défaut dans un composant ne provoque pas l'effondrement du système entier, et les mécanismes de récupération peuvent redémarrer le processus défaillant.
Préemption des appels au noyau de faible priorité : pour respecter les engagements en temps réel, le RTOS QNX Neutrino autorise les appels au noyau de faible priorité à être préemptés par des processus de priorité supérieure. Les fenêtres de temps pendant lesquelles la préemption ne peut se produire sont extrêmement courtes. De plus, il existe une limite supérieure sur le temps durant lequel la préemption est bloquée et les interruptions désactivées, pour permettre aux développeurs de constater les pires cas de latences.
Un héritage des priorités : le RTOS QNX Neutrino implémente l'héritage des priorités, une technique pour empêcher les inversions de priorités (le problème devenu tristement célèbre qui mit à mal le projet Mars Pathfinder en juillet 1978) en attribuant la priorité d'une tâche bloquée à priorité supérieure au fil de priorité inférieure faisant le blocage jusqu'à ce que la tâche bloquante soit terminée.
Un partitionnement adaptatif : le RTOS QNX Neutrino utilise le partitionnement adaptatif pour empêcher les processus ou les fils de monopoliser les cycles du processeur et d'affamer les autres processeurs et fils. Avec le partitionnement adaptatif, les développeurs peuvent attribuer des budgets garantis de temps de processeur aux processus et fils, et un algorithme de programmation dynamique réattribue dynamiquement les cycles de processeur non utilisés par des partitions vers des partitions qui peuvent profiter d'un temps de traitement supplémentaire. Les budgets de partition sont appliqués uniquement lorsque le processeur fonctionne au maximum de ses capacités. Tous les cycles disponibles sont utilisés s'ils sont nécessaires, mais lorsque des processus dans plus d'une partition sont en concurrence pour des cycles, le partitionnement applique les budgets de ressources et empêche le manque de ressources.
un cadre de haute disponibilité : aucun système n'est sans faille ; pour garantir une disponibilité continue, le RTOS QNX Neutrino prend en charge un cadre de haute disponibilité qui inclut un chien de garde qui surveille les processus en cas de défaillances ; des mécanismes automatiques qui redémarrent les processus défaillants sans redémarrage du système ; des processus miroirs qui se tiennent perpétuellement prêts à prendre en charge les tâches du chien de garde le cas échéant ; et une interface de programmation qui laisse le concepteur du système déterminer comment le chien de garde réagira aux défaillances spécifiques.
Des capacités de multiprocesseur : pour garantir la stabilité pendant et après la migration, et l'efficacité sur les systèmes multicœurs, le RTOS QNX Neutrino utilise le multitraitement lié (BMP), une extension de l'affinité du processeur (ou du fil) propre à QNX qui permet aux développeurs de préciser l'héritage du masque de fonctionnement pour les fils. En permettant aux développeurs de définir des masques de fonctionnement qui limitent non seulement les fils spécifiés mais aussi les fils enfants aux cœurs spécifiques, BMP aide à protéger un système migré vers un multicœurs des bugs latents ou de caractéristiques de conception, comme la programmation FIFO, qui rend le code écrit pour des processeurs mono-cœur peu fiable sur des systèmes multicoeurs, et cela aide à résoudre les problèmes, tels que l'emballement du cache, communément associés au traitement multicœurs symétrique. Les développeurs qui migrent des systèmes vers un multicœurs peuvent lier les hiérarchies entières de fils à un processeur unique pour veiller à ce qu'il n'y ait aucune mauvaise surprise dans le nouvel environnement.
Norme FIPS 140-2
Aux États-Unis, les exigences pour la sécurité gouvernementale sont régulées par les publications de la norme FIPS. Le NIST développe ces publications pour qu'elles soient utilisées dans toutes les agences gouvernementales. Il développe et publie de nouvelles publications de la norme FIPS lorsqu'il s'agit d'exigences indiscutables du gouvernement fédéral pour les nouvelles normes de sécurité et d'interopérabilité.
La norme FIPS 140-2 décrit les exigences de cryptographie du gouvernement fédéral américain que les produits logiciels et matériels doivent respecter pour une utilisation sensible mais non classifiée. La norme FIPS 140-2 fait référence à la validation du module complet que les applications doivent utiliser pour exécuter des fonctions cryptographiques spécifiques. Voir « Validation de la norme FIPS » ci-dessous. Les autres normes FIPS, comme la FIPS 186-2, qui décrit l'utilisation de l'Elliptic Curve Digital Signature Algorithm (ECDSA), et la FIPS 197, qui définit la norme Advanced Encryption Standard (AES), sont des implémentations spécifiques d'algorithmes cryptographiques qui sont inclus dans un module validé par la norme FIPS 140-2.
En 2002, le Federal Information Security Management Act (FISMA) a supprimé une provision qui autorisait les agences gouvernementales à émettre des dérogations pour l'achat de produits non approuvés par la norme FIPS. Cette suppression impliquait que, dorénavant, la validation de la norme FIPS 140-2 devenait obligatoire pour tous les produits qui mettent en place la cryptographie et sont vendus au gouvernement fédéral américain. Sans la validation de la norme FIPS 140-2, les produits ne seront pas pris en compte par les clients du gouvernement américains. De plus, en dehors des États-Unis, des pays comme le Royaume-Uni et le Canada via son Communication Security Establishment (CSE), ont adopté la norme FIPS 140-2 pour leurs exigences de sécurité.
De la même façon, alors que la validation de la norme FIPS n'est pas toujours obligatoire pour les applications dans les secteurs de la santé et de la finance, elle reste néanmoins souvent une exigence. Par exemple, elle est obligatoire pour les installations médicales dans les établissements du gouvernement américain où la technologie sans fil est déployée pour transporter les données des patients. Et lorsque la validation de la norme FIPS n'est pas explicitement requise, elle est hautement recommandée lorsque la sécurité des données est nécessaire. En résumé, les produits validés par la norme FIPS profitent d'un avantage concurrentiel dans ces secteurs.
Validation de la norme FIPS 140-2
Pour la plupart des fournisseurs, il existe deux niveaux de validation de la norme FIPS. Le premier niveau valide les techniques de chiffrement utilisées par des algorithmes spécifiques, comme ceux mentionnés dans les normes FIPS 186-2 et FIPS 197. Ces algorithmes incluent des algorithmes de chiffrement symétrique comme AES, DES, 3DES et RSA ;des algorithmes de hachage comme SHA-1 ; et des signatures numériques comme RSA et ECDSA. La norme FIPS spécifie comment ces algorithmes sont définis, et comment ils doivent être implémentés pour réussir la validation. Le Cryptographic Algorithm Validation Program (CAVP) du NIST réalise ces validations.
Le second niveau concerne la validation de niveau supérieur et la plus importante : celle de la norme FIPS 140-2. Cette norme définit onze points de sécurité qui doivent être respectées par un module cryptographique fonctionnant à l'intérieur d'un système sécurisé pour protéger les informations contenues dans ce système. Ce module cryptographique peut être matériel, micrologiciel ou logiciel. Il prend en charge les services de sécurité pour le système dans lequel il est utilisé, en réalisant des fonctions cryptographiques comme le chiffrement, l'authentification et la génération de nombres aléatoires.
La norme FIPS 140-2 définit quatre niveaux de sécurité, de1 à 4 (4 étant le plus sécurisé) pour chacun des onze points de sécurité qu'il spécifie ; il attribue ensuite une note globale unique pour le module de sécurité. Pour obtenir davantage d'informations détaillées sur ces niveaux, veuillez vous reporter à la note d'application de Certicom : « Certicom Security for Government Suppliers » (Certicom Security pour les fournisseurs gouvernementaux), disponible sur www.certicom.com/fips.
Pour recevoir la validation FIPS 140-2, un module cryptographique doit :
-
avoir des limites cryptographiques bien définies afin que les informations de sécurité sensibles restent dans le cœur cryptographique du produit
-
utiliser au moins un algorithme approuvé FIPS avec une implémentation correcte et une limite cryptographique intacte
Le processus pour valider un algorithme ou un module cryptographique FIPS 140-2 est défini dans la Figure 1 ci-dessus. Au moins un algorithme utilisé dans le module FIPS doit être validé par le CAVP avant de se lancer dans le processus de validation FIPS 140-2 via le CMVP. Le module FIPS doit donc être validé via le Cryptographic Module Validation Program (CMVP), qui comme le CAVP est géré par le NIST. Tous les tests du CMVP sont réalisés par l'un des laboratoires de Cryptographic Modules Testing (CMT) accrédités dans le cadre du National Voluntary Laboratory Accreditation Program (NVLAP).
Problèmes et barrières liés à l'entrée sur le marché
Alors que le marché gouvernemental est attractif et lucratif, pour de nombreux fournisseurs le processus de validation FIPS représente une barrière d'entrée considérable. Les choix qui s'offrent aux fournisseurs espérant vendre aux agences gouvernementales (ou même à de nombreux organismes de santé et financiers) sont limités : ils peuvent soit créer un produit en partant de rien ou acheter un module cryptographique validé FIPS-140-2 auprès d'un fournisseur commercial.
Ceux qui envisageraient la création doivent noter que le processus de validation prend de 8 à 12 mois, exige l'engagement de plusieurs développeurs ainsi qu'un investissement de 50 000 $ juste pour la validation initiale. À cette première dépense s'ajoutent des sommes de 10 000 $ à 15 000 $ pour chaque soumission ultérieure du même module (mises à jour, correction de bugs et d'erreurs initiales, etc.). Par conséquent, en tenant compte des coûts de développement, la validation d'un module revient facilement à plus de 100 000 $.
Notez également qu'en soumettant un module logiciel cryptographique pour validation, le fournisseur doit fournir les documents suivants : une politique de sécurité, une machine à état fini, les descriptions du module logiciel, une liste des codes sources pour tous les logiciels dans les limites cryptographiques, une description des rôles et services du module, une description du cycle de vie de gestion des clés et les certificats de conformité des algorithmes. La validation est propre à chaque plateforme : les numéros individuels de certificat de validation sont nécessaires pour chaque plateforme. De plus, tout changement ou ajout concernant un produit validé exige un nouveau cycle de validation sur ce produit, ainsi que des coûts supplémentaires.
En outre, la création d'un module cryptographique conforme à la norme FIPS 140-2 est non seulement complexe, mais possède un taux d'échec élevé. Selon le NIST, 48 % des modules cryptographiques soumis par de nouveaux candidats et 20 % des modules de candidats récurrents contiennent des failles de sécurité. 30 % des algorithmes testés par le NIST ne sont pas conformes à la norme FIPS. Ce taux d'échec suggère que les entreprises investissent beaucoup de temps et d'argent dans le développement d'une solution qui exige une validation FIPS, la soumettent à un processus de test pouvant durer jusqu'à un an, pour finalement découvrir que leur solution est défaillante et ne peut pas être validée FIPS sans un investissement de temps et financier supplémentaire.
Enfin, l'investissement financier dans une validation FIPS ne se termine pas lorsqu'un produit reçoit sa première validation. Une expertise interne est nécessaire pour surveiller les normes de sécurité changeantes et les tendances du secteur, qui peuvent dicter les changements du produit pour répondre à la demande du marché, ou rester au niveau des nouvelles exigences FIPS. La norme FIPS 140-2 est mise à jour tous les cinq ans, et de nouveaux algorithmes sont ajoutés pour l'améliorer, l'aligner avec les tendances du secteur et la rendre plus robuste. Bien que les validations existantes restent valables en cas de modification de la norme FIPS, si un fournisseur veut profiter des nouveaux algorithmes de la norme, son produit devra être mis à jour et soumis une fois encore à validation.
Au lieu d'essayer de créer leurs propres modules cryptographiques, les fournisseurs peuvent choisir d'acheter un module cryptographique prévalidé, qu'ils peuvent intégrer dans leursproduits. Les avantages de cette approche incluent la validation FIPS 140-2 tout en contournant totalement son processus, des coûts de développement minimes, une commercialisation plus rapide et des efforts de développement concentrés sur les compétences essentielles. Les considérations suivantes vous aideront à faire le bon choix de module cryptographique :
Architecture extensible : une plateforme qui offre une API commune facilite la prise en charge de nouveaux algorithmes et protocoles de sécurité avec peu de code à réécrire.
Flexibilité des mises à jour : l'utilisation d'un module prévalidé permet au fournisseur de modifier son produit ou sa solution et de conserver la validation FIPS en réutilisant le même module pour la sécurité. Le fournisseur de module FIPS prend en charge la surveillance de la norme FIPS, en appliquant les changements au module et en validant le module mis à jour. Le fournisseur doit uniquement remplacer le module FIPS dans son produit pour conserver sa validation FIPS.
Flexibilité de la plateforme : si la validation FIPS 140-2 est requise pour plusieurs plateformes du système, le fournisseur de module FIPS doit proposer des modules de sécurité validés pour toutes les plateformes nécessaires.
Contraintes de ressources : l'utilisation d'un module FIPS conçu spécialement pour des appareils avec contraintes de ressources peut considérablement améliorer les performances du système en réduisant la bande passante du processeur et les exigences de mémoire. Cet avantage est bien réel pour les appareils mobiles pour lesquels la durée de vie de la batterie est un gros problème.
Conclusion
Compte tenu des barrières et avantages associés au développement d'un produit validé FIPS, la recherche d'une implémentation FIPS fiable permettant de commercialiser rapidement le produit et avec le moins de risques possible peut faire la différence entre réussite et échec.
QNX Software Systems et Certicom ont collaboré pour fournir une bibliothèque de module d'objets partagés qui offre aux développeurs un moyen facile et rentable de profiter des bibliothèques cryptographiques validées FIPS GSE de Certicom Security Builder. Cette solution permet aux fabricants d'appareils et aux fournisseurs de logiciels indépendants d'offrir à leurs clients des solutions grâce à la technologie de sécurité certifiée FIPS 140-2 sur une base RTOS prouvée.