Chat with us, powered by LiveChat
Nous utilisons des témoins à des fins d’analyse du Site Web, de statistiques, de profilage et de reciblage publicitaire. Nous pouvons aussi partager de l’information sur votre utilisation du Site Web avec nos partenaires publicitaires et analytiques. Vous pouvez désactiver les témoins dans les paramètres de votre navigateur à tout moment. Politique de confidentialité .
FERMER X
 Dans Blogue, Communications Unifiées, Fax, Innovation, Productivité, Sécurité, Technologie

Si votre travail consiste à assurer la liaison avec les services informatiques du gouvernement américain, ou si vous produisez des solutions matérielles et/ou logicielles que vous espérez fournir au gouvernement américain, vous avez certainement entendu parler de la conformité aux normes FIPS 140-2, mais savez-vous ce que le respect des normes FIPS 140-2 signifie et pourquoi il est important pour vous ?

Que signifie FIPS ?

L’acronyme FIPS renvoie à « Federal Information Processing Standards » (normes fédérales de traitement de l’information). La série de normes FIPS 140 correspond aux normes de sécurité informatique établies par le National Institute of Standards & Technology (NIST) pour le gouvernement des États-Unis.

Glossaire des termes

Les normes FIPS 140-2 portent plus particulièrement sur les clés de cryptage et leur protection physique. Pour tous ceux qui souhaitent comprendre en quoi cela consiste sans être pour autant des professionnels du cryptage, voici une liste de quelques termes essentiels :

  • Cryptologie – Porte sur la recherche et le développement de méthodes de communication sécurisées, y compris le développement et le perfectionnement de systèmes de cryptage et autres méthodes permettant d’assurer la sécurité et la confidentialité des données.
  • Clé cryptographique – Une série de caractères en texte clair utilisée par un algorithme pour chiffrer ou déchiffrer un texte.
  • Module cryptographique – Un dispositif qui se charge du cryptage, du décryptage, des signatures numériques, de l’authentification des utilisateurs et de la génération de nombres aléatoires.
  • Paramètre de sécurité critique (PSC) – Selon le Glossaire du NIST, les CSP comprennent les informations relatives à la sécurité, dont la modification ou la divulgation peuvent compromettre la sécurité d’un module cryptographique.
  • Critères communs (CC) – Également connus sous l’appellation Common Criteria for Information Technology Security Evaluation (Critères communs pour l’évaluation de la sécurité informatique). Sert de base technique pour le Common Criteria Recognition Arrangement (CCRA), une entente internationale assurant que les produits de sécurité sont adéquatement testés par des laboratoires agréés indépendants.
  • Cryptage – Le processus de codage d’un message ou d’un fichier, généralement à l’aide d’un algorithme conçu pour être difficile à décoder en ingénierie inversée, afin que seules les parties autorisées puissent consulter ce message ou fichier.
  • Texte clair – Du texte qui n’a pas été calculé ou brouillé par un algorithme de cryptage. N’importe qui peut consulter et lire un texte clair non sécurisé et (ou) non crypté.

Qu’est-ce que la série FIPS 140-2 ?

La série FIPS 140 consiste en un ensemble d’exigences et de normes relatives aux modules cryptographiques pour des composants tant matériels que logiciels utilisés par les départements et les agences du gouvernement des États-Unis. Les normes FIPS 140-2 constituent le deuxième et le plus actuel des ensembles de normes FIPS 140 publiés par le NIST. Diffusées le 25 mai 2001, les normes FIPS 140-2 étendent la portée des normes FIPS 140-1 (diffusées le 11 janvier 1994), tirent parti des niveaux d’assurance d’évaluation (EAL) des critères communs (CC) [Common Criteria (Evaluation Assurance Levels] pour déterminer le niveau de sécurité, et prennent en compte les commentaires de la communauté, ainsi que les nouveaux développements en matière de technologie et d’informatique depuis 1994.

Il est important de noter que bien que ces éléments portent sur les normes de cryptographie et de sécurité pour le matériel et les logiciels, la conformité d’un produit donné aux normes FIPS 140-2 n’en garantit pas la sécurité. Les normes FIPS 140-2 ne visent à s’appliquer qu’aux modules cryptographiques interagissant avec des charges de travail gérant des informations confidentiels, mais non classées (SBU)

Que sont les niveaux d’assurance d’évaluation (Evaluation Assurance Levels)?

Les critères communs (Common Criteria) établissent sept (7) niveaux différents d’assurance d’évaluation (EAL), nommés EAL1 à EAL7. Il est aussi courant de voir un signe « + » en regard d’un EAL donné (p. ex., EAL5+) pour signifier qu’un dispositif donné respecte les critères au-delà du minimum pour un EAL donné. Puisque le niveau le plus élevé prévu par les normes FIPS 140-2 ne requiert qu’un niveau de sécurité EAL4, nous ne discuterons que des niveaux EAL1 à EAL4 dans cet article.

  • EAL1 : Niveau prévu pour les cibles d’évaluation (Targets of Evaluation, ou ToE), où les menaces pour la sécurité ne sont pas considérées comme graves, mais où il faut être assuré que les dispositifs de sécurité mis en œuvre fonctionnent comme prévu. Le niveau EAL1 est intéressant pour étayer les allégations qu’une organisation donnée s’est convenablement souciée de protéger la confidentialité des renseignements personnels.
  • EAL2 : Idéal pour les produits nécessitant d’une assurance de sécurité raisonnable quand la documentation de développement pour une cible d’évaluation (ToE) n’est pas disponible, comme pour des environnements informatiques existant de longue date.
  • EAL3 : Conçu pour fournir un niveau modéré de sécurité garantie. Le niveau EAL3 analyse la cible d’évaluation (ToE) plus en profondeur, y compris son développement. Ce niveau est idéal pour les organisations ayant des pratiques robustes en matière d’ingénierie de sécurité intégrées au niveau de la conception, et qui ne prévoient pas de reconception importante de la cible d’évaluation.
  • EAL4 : Le niveau de sécurité le plus élevé qui est économiquement envisageable pour l’ajustement d’une gamme de produits existants (c’est-à-dire que les tests et la reconception de produits qui n’ont pas été construits conformément aux niveaux EAL les plus élevés seront probablement trop coûteux et prendront beaucoup de temps). Le niveau EAL4 sert à conférer une garantie de sécurité maximale fondée sur les meilleures pratiques en matière de développement informatique.

Quels sont les différents niveaux prévus par les normes FIPS 140-2 ?

La publication FIPS 140-2 établit quatre niveaux de sécurité différents. Le niveau 1 présente le niveau de sécurité le plus bas, tandis que le niveau 4 constitue le niveau le plus élevé de sécurité.

FIPS 140-2 – Niveau 1
Le niveau le plus bas des exigences de sécurité relatives à un module cryptographique donné. Le premier niveau de sécurité ne nécessite aucun mécanisme de sécurité physique au-delà des exigences de base pour des composants de production et permet à un module cryptographique d’être exécuté sur un ordinateur d’usage général à l’aide d’un système d’exploitation non évalué.

Un exemple de module cryptographique de niveau de sécurité 1 est un tableau de cryptage sur un ordinateur personnel (PC).

FIPS 140-2 – Niveau 2
Le deuxième niveau de sécurité prolonge le niveau 1 en y ajoutant trois exigences principales :

  • Preuve d’altération des modules cryptographiques : Cela peut inclure des revêtements, des sceaux ou des serrures sécurisées révélant les tentatives d’altération. Les mesures permettant de révéler les tentatives d’altération doivent être appliquées de manière que les sceaux et (ou) revêtements doivent être brisés pour pouvoir accéder physiquement aux clés cryptographiques en texte clair et aux paramètres de sécurité critiques (CSP).
  • Authentification fondée sur le rôle : L’exigence de sécurité minimum de niveau 2 stipule qu’un utilisateur donné doit être associé à un rôle spécifique et à un niveau d’autorisation authentifiés par le module cryptographique.
  • Exigences de système d’exploitation : Le niveau de sécurité 2 permet à un module cryptographique d’être exécuté sur un PC d’usage général tournant sur un système d’exploitation fiable, approuvé ou évalué. Les systèmes d’exploitation doivent être évalués au niveau d’assurance d’évaluation des critères communs EAL2 ou plus. Pour plus d’informations, veuillez-vous reporter à la Section 1.2 de la publication FIPS 140-2.

FIPS 140-2 – Niveau 3
Les exigences de sécurité établies par le niveau 3, ajoutent à celles du niveau 2, quatre domaines principaux :

  • Prévention des intrusions : Allant au-delà des mesures de preuve d’altération du niveau de sécurité 2, le niveau de sécurité 3 exige des mécanismes de sécurité physique conçus pour empêcher tout intrus d’accéder aux CSP au sein du module cryptographique. Ces mécanismes offrent de fortes probabilités de détecter toute tentative d’accès au module cryptographique ou d’altération ou d’utilisation de celui-ci, et d’y réagir. Parmi les exemples de mécanismes de ce genre, on compte les boitiers robustes et des circuits conçus pour mettre à zéros (effacer) les CSP en texte clair lorsqu’une tentative est faite d’altérer le module cryptographique.
  • Authentification fondée sur l’identité : Constituant une méthode d’authentification plus fine, l’authentification fondée sur l’identité permet d’améliorer l’exigence relative à l’authentification du niveau de sécurité 2. Cela est accompli en vérifiant l’identité d’un utilisateur donné plutôt que d’authentifier le rôle de celui-ci. Un exemple de cette différence serait un réseau qui exige des identifiants spécifiques à l’utilisateur, au lieu d’un réseau qui détient des comptes d’utilisateur général ou invité en plus d’un compte générique d’administrateur.
  • Séparation physique (ou logique) : Pour se conformer au niveau de sécurité 3, l’entrée ou la sortie de CSP en texte clair doivent être faites à l’aide de ports qui sont physiquement séparés des autres ports (ou à l’aide d’interfaces logiquement séparées, s’il s’agit d’un environnement virtuel). Les CSP en texte clair doivent être entrés dans le module cryptographique, ou en sortir par le biais d’un système de boîtier ou capable d’intervenir en cas de tentative d’altération seulement s’ils sont sous forme cryptée.
  • Exigences de système d’exploitation : Tout comme le niveau de sécurité 2, le niveau de sécurité 3 permet à un module cryptographique donné d’être exécuté sur un PC d’usage général tournant sur un système d’exploitation respectant les exigences minimales. Les exigences pour le niveau de sécurité 3 sont plus rigoureuses que celles pour le niveau 2 et comprennent une assurance d’évaluation des CC de niveau EAL3 ou plus élevé. De plus amples informations sur les exigences de système d’exploitation inhérentes au niveau de sécurité 3 sont disponibles à la Section 1.3 de la publication FIPS 140-2.

FIPS 140-2 – Niveau 4
Des quatre niveaux de sécurité prévus par les normes FIPS 140-2, le niveau de sécurité 4 est le plus élevé et est idéal pour les modules cryptographiques tournant dans des environnements physiquement non protégés. Pour avoir une idée de ce qui constitue un environnement physiquement non protégé, il faut penser à tout lieu où des informations ou des communications gouvernementales peuvent être traitées ou stockées, ou par lequel celles-ci transitent, comme les satellites ou les véhicules aériens sans pilote. L’intention du niveau de sécurité 4 consiste à assurer que des mécanismes physiques de sécurité sont complètement enveloppés et protègent le module cryptographique de toute tentative non autorisée d’y accéder physiquement. Ces mécanismes doivent fournir une forte probabilité de détecter une intrusion et doivent être conçus de manière à immédiatement remettre à zéros les CSP en texte clair dans le cas où une intrusion est détectée.

Pour être conforme au niveau de sécurité 4 des normes FIPS 140-2, un module cryptographique donné doit également être protégé contre des conditions environnementales qui pourraient soumettre le module à des paramètres hors des limites normales auxquelles il est supposé fonctionner. Il est courant que des intrus potentiels poussent un module cryptographique à des températures ou à des voltages qui en compromettent la sécurité. Parmi les exemples, on peut citer le chauffage ou le refroidissement extrêmes de l’enceinte du module dans le but de la fragiliser (pensez à l’espion dans les films, qui verse de l’azote liquide sur une serrure pour la faire geler et la casser).

La protection environnementale peut prendre la forme de fonctionnalités qui remettent à zéro les CSP si le module cryptographique détecte des fluctuations de paramètres hors de la gamme des valeurs de fonctionnement normal. En reprenant l’exemple ci-dessus, si l’espion dans les films faisait geler une serrure pour la briser afin d’accéder à un module cryptographique, les mesures de protection environnementale détecteraient que la serrure est soumise à des températures bien au-dessous du seuil acceptable et effaceraient le module. Cela rendrait le module inutilisable par l’espion, même si celui-ci finissait par y accéder.

Autrement, l’exigence de protection environnementale peut être remplie par le biais d’une garantie raisonnable que les fluctuations des paramètres en dehors de la plage de fonctionnement normales ne compromettent pas la sécurité du module.

Tout comme les niveaux de sécurité 2 et 3, le niveau de sécurité 4 exige également que le système d’exploitation respecte un certain niveau d’assurance d’évaluation des CC. Pour qu’un module cryptographique puisse être considéré conforme au niveau de sécurité 4 établi dans les normes FIPS 140-2, le système d’exploitation sur lequel il tourne doit avoir reçu une assurance d’évaluation des CC de niveau EAL4 ou plus élevé.

Obtenir la certification FIPS 140-2

Pour qu’un module cryptographique donné soit validé comme conforme aux normes FIPS 140-2, une organisation doit soumettre ce module au Programme de validation des modules cryptographiques (PVMC). Le PVMC constitue un effort conjoint entre le NIST et le CSTC (Centre de la sécurité des télécommunications Canada) pour le gouvernement canadien.

Pour voir son module évalué par le PVMC, l’organisation doit soumettre le module à un laboratoire de test de module cryptographique agréé. Les laboratoires agréés sont des laboratoires tiers qui ont été agréés par le programme National Voluntary Laboratory Accreditation Program (NVLAP).

Conserver la certification FIPS 140-2

Le processus de certification FIPS 140-2 peut être long et fastidieux, prenant généralement plusieurs mois à une année du début à la fin. De plus, un module doit faire l’objet d’une réévaluation pour chaque modification, même minime, du logiciel. Dans le cas où un problème est découvert dans un module conforme aux normes FIPS, la solution perd sa certification FIPS jusqu’à ce qu’elle soit réévaluée et certifiée à nouveau. Durant cette période, l’organisation ne peut pas fournir son module aux fournisseurs et agences exigeant la conformité à ces normes.

Critiques des normes FIPS 140-2

Bien que la certification FIPS 140-2 soit essentielle pour travailler avec les services informatiques du gouvernement américain, le processus de validation est sujet à certaines critiques valides des normes FIPS 140-2.

Le premier élément de critique est lié à la durée du processus de validation. Du fait que le processus de validation peut durer des mois voire une année, et que les organisations doivent refaire valider leur module pour chaque modification, aussi minime soit-elle, de nombreuses compagnies hésitent à mettre à jour ou à niveau leur logiciel, même si un bogue est détecté. Cela peut entrainer un retard en matière de mises à niveau vitales et peut même pousser les organisations à dissimuler des bogues mineurs dans leur code.

Les organisations ont découvert des bogues et des vulnérabilités dans leur logiciel, mais ont trouvé difficile et peu clair le processus de validation accéléré de la conformité aux normes FIPS 140-2 d’un correctif. Dans un exemple, une organisation a découvert une vulnérabilité dans un module certifié et avait le correctif prêt pour déploiement le jour même, mais n’a pas pu faire valider le correctif dans un délai approprié. Par conséquent, quand l’organisation a annoncé la vulnérabilité dans son logiciel, le PVMC a presque immédiatement révoqué la certification FIPS 140-2 du module, laissant l’organisation et ses clients dans l’incertitude jusqu’à ce que le processus de validation du correctif soit achevé.

Ce qui rend cet exemple particulièrement notable, c’est que la vulnérabilité a été découverte dans un dérivé du code source ouvert d’OpenSSL, sur lequel leur certification propriétaire était fondée. Alors qu’il y avait d’autres certifications propriétaires fondées sur ce même code, très peu, voire aucune d’entre elles n’a fait l’objet d’une révocation. Cela tient au fait que d’autres organisations avaient légèrement modifié leur code puis l’on fait valider de nouveau sous un nom différent, au lieu d’exploiter le code comme un code source ouvert. Cette façon de procéder avait en fait caché l’origine du code et les autres compagnies ont pu éviter la révocation qui aurait résulté de la découverte d’une vulnérabilité dans le code source ouvert.

Questions à se poser

Étant donné les critiques du processus de validation de la conformité aux normes FIPS 140-2, toute organisation qui souhaitant que son module cryptographique soit utilisé par le gouvernement américain, devrait poser au créateur du module quelques questions importantes :

  • Quelle est la dernière fois que le module cryptographique a été mis à jour ou validé?
  • Y a-t-il une nouvelle version du module cryptographique qui est en cours de validation?
  • Y a-t-il des bogues ou des vulnérabilités connus dans le module ou dans le code sous-jacent, qui pourraient ne pas avoir été divulgués?
  • Des plans de mise à jour ou de nouvelle validation du module cryptographique sont-ils prévus dans un avenir proche?
  • Quels sont le processus et le rythme de mise à jour du module conforme aux normes FIPS 140-2?
  • Le module cryptographique a-t-il subi un test ou une validation en dehors de ceux effectués par le PVMC?

***

À propos de XMedius

XMedius est un chef de file mondial dans le domaine des solutions de communication pour les entreprises. Son offre de solutions de communications professionnelles sur site et dans le Cloud permet aux entreprises de bénéficier de communications sécurisées et unifiées, ainsi que d’échanger des données confidentielles et sensibles qui respectent et dépassent les exigences en matière de conformité et de règlementation. XMedius est basée à Montréal au Canada, et possède des bureaux à Seattle aux États-Unis et à Paris en France. Notre société travaille avec des entreprises et des fournisseurs de service par l’intermédiaire de notre équipe internationale d’employés axée sur la clientèle. Ses solutions sont déployées dans le monde entier, dans une pléthore de secteurs comme l’éducation, la finance, le gouvernement, la santé, la production, le commerce de détail et les services juridiques. Pour de plus amples renseignements sur XMedius et ses solutions, veuillez consulterwww.xmedius.com/fr et nous suivre sur LinkedIn et Twitter.

PARLEZ À UN EXPERT

 

Leave a Comment

Start typing and press Enter to search