Pour de nombreux acheteurs du secteur public et de la défense, une certification « Critères communs » n’est pas un simple atout. C’est une condition sine qua non. Si votre produit ne peut pas en justifier une, l’affaire est souvent close avant même que les négociations ne commencent.
Voici le point sensible que la plupart des fournisseurs découvrent trop tard : les Critères communs viennent se superposer à votre infrastructure cryptographique. Une faille dans votre statut de validation FIPS ne reste pas isolée. Elle peut discrètement se transformer en un problème lié aux Critères communs, qui apparaîtra au moment même où un laboratoire commencera à examiner votre cible de sécurité.
Les « Critères communs » ont été adoptés sous la référence ISO/IEC 15408:2022, le référentiel internationalement reconnu pour l'évaluation de la sécurité des produits informatiques. Ce guide explique en détail ce qu'ils sont, pourquoi ils sont importants, comment ils s'articulent avec la cryptographie, comment se préparer à un audit et quel est leur lien avec la norme FIPS 140-3.
Qu'est-ce que les Critères communs (ISO/IEC 15408) ?
Les Critères communs constituent une méthode structurée permettant de démontrer qu'une configuration de produit définie, appelée « cible d'évaluation », répond aux exigences de sécurité spécifiques qui lui sont associées, ces exigences étant vérifiées par un organisme tiers accrédité plutôt que par le fournisseur.
Le fonctionnement est simple. Les fournisseurs définissent leurs exigences de sécurité dans un « objectif de sécurité », souvent élaboré à partir d’un profil de protection publié. Un laboratoire d’essai accrédité vérifie ensuite de manière indépendante que le produit répond bien à ces exigences. Les certificats délivrés dans le cadre de l’Accord de reconnaissance des Critères communs (CCRA) sont mutuellement reconnus par tous les pays signataires, ce qui évite à un produit de subir des évaluations redondantes sur chaque marché où il est commercialisé.
Quelques rôles garantissent l'intégrité du système :
- Les organismes nationaux de certification délivrent des certificats sur la base d'une évaluation réalisée par un laboratoire : le NIAP (qui gère le programme américain CCEVS), le BSI en Allemagne, le CCCS au Canada. Les règles varient d'un organisme à l'autre. Le NIAP n'accepte que les évaluations fondées sur un profil de protection ; par conséquent, une cible de sécurité reposant uniquement sur le niveau EAL ne permet pas d'accéder au marché américain.
- Les laboratoires d'essais accrédités procèdent à l'évaluation par rapport à l'objectif de sécurité d'un produit. Le label varie selon le programme : CCTL aux États-Unis, CCEF au Canada, ITSEF en Allemagne et dans le cadre de l'EUCC.
À qui cela s'adresse-t-il et où ?
Les Critères communs ont une portée internationale. L'ACRC couvre environ 31 pays ; le dispositif en question est le « Common Criteria Evaluation and Validation Scheme » (CCEVS), géré par le National Information Assurance Partnership (NIAP) et mis en œuvre par la NSA. Les laboratoires procèdent à l'évaluation ; le NIAP valide les résultats et délivre le certificat.
Elle s'applique plus particulièrement aux fournisseurs de produits informatiques souhaitant faire évaluer leurs solutions par rapport à un profil de protection publié, notamment les systèmes d'exploitation, les équipements réseau, les systèmes de bases de données, les solutions de gestion des appareils mobiles, les messageries électroniques, les VPN et les pare-feu. Les organismes nationaux de certification et les laboratoires d'essais accrédités complètent cet écosystème.
Si vous souhaitez consulter les sources primaires, celles qui sont pertinentes dans ce contexte sont la norme ISO/IEC 15408:2022 (parties 1 à 5), les profils de protection approuvés par le NIAP, tels que le cPP « Network Device » et le cPP « Full Drive Encryption », ainsi que la lettre de politique n° 5 du NIAP, qui coordonne les activités d’assurance cryptographique des Critères communs avec les programmes CAVP et CMVP du NIST.
Pourquoi les Critères communs sont-ils importants pour l'évaluation cryptographique ?
La réalité commerciale est sans appel : pour les acheteurs des secteurs public et de la défense à travers le monde, la certification constitue souvent un véritable critère d'éligibilité à l'appel d'offres, et non une question d'interprétation. De nombreuses réglementations nationales en matière de marchés publics la mentionnent explicitement comme une exigence fondamentale pour des catégories telles que les équipements réseau, les passerelles VPN et les plateformes de gestion des appareils mobiles.
Les exigences varient selon les programmes. Le présent guide s'appuie sur le NIAP, le programme américain. Les programmes européens tels que le BSI et l'ANSSI appliquent leurs propres recommandations en matière de cryptographie plutôt que celles du CAVP.
C'est la connexion cryptographique qui pose problème. Les profils de protection spécifiques à la cryptographie, ainsi que les exigences fonctionnelles de sécurité de la classe FCS, partent généralement du principe que les algorithmes sous-jacents ont déjà été validés dans le cadre du programme de validation des algorithmes cryptographiques (CAVP) du NIST ou du CMVP. La lettre de politique NIAP n° 5 formalise cette relation. Une évaluation selon les Critères communs ne remplace pas la validation CAVP ou CMVP ; elle s'appuie sur celle-ci.
Comment les Critères communs s'appliquent à la cryptographie
La norme ISO/IEC 15408 aborde la cryptographie à travers plusieurs domaines de contrôle étroitement liés. Chacun d’entre eux a une implication cryptographique directe. Certains sont pris en charge par des outils ; d’autres constituent des obligations de processus qui incombent à vos équipes de développement et de conformité et ne peuvent être achetées.
| Zone de contrôle | Ce qu'il faut |
|---|---|
| Exigences cryptographiques relatives aux cibles de sécurité (15408-2, classe FCS) | Précisez les algorithmes, les tailles de clé et les opérations que la cible d'évaluation doit mettre en œuvre, ainsi que la manière dont un laboratoire les vérifiera. |
| Conformité au profil de protection | Mettre en correspondance les capacités cryptographiques avec le profil de protection spécifique selon lequel un produit est évalué, de manière préconfigurée pour les activités d'assurance qualité du laboratoire. |
| Principes fondamentaux de la validation du CAVP/CMVP (Lettre de politique n° 5 du NIAP) | Vérifiez que les algorithmes et les modules mentionnés dans la cible de sécurité ont déjà obtenu les validations CAVP et CMVP en vigueur avant le début de l'évaluation. |
| Gestion de la configuration des composants cryptographiques (15408-3, classe ALC) | Démontrer la mise en œuvre de contrôles de gestion de la configuration et du cycle de vie des composants cryptographiques situés à l'intérieur des limites du produit certifié. |
| Garantie de la continuité après des modifications cryptographiques (CCDB, NIAP) | Suivre les mises à jour des algorithmes et les correctifs apportés aux bibliothèques par rapport à la référence certifiée afin de déterminer quand une réévaluation ou un examen de la continuité de l'assurance doit être déclenché. |
| Versions signées des produits (FPT_TUD_EXT.1 et FPT_TUD_EXT.2, mise à jour sécurisée) | Signer cryptographiquement les correctifs et les mises à jour afin que les clients puissent vérifier qu'une version correspond toujours à la référence évaluée. |
La tendance est la même dans les six domaines : votre cryptographie doit être définie, validée, contrôlée et traçable, et pas seulement mise en place.
La dépendance FIPS que vous ne pouvez pas ignorer
C'est ce lien qui bloque les évaluations. Étant donné que la plupart des profils de protection intègrent des activités d'assurance cryptographique qui reposent sur des algorithmes validés selon les normes CAVP ou CMVP, une lacune dans le statut de validation FIPS se traduit par une lacune dans l'évaluation selon les Critères communs.
En termes simples : un produit ne peut pas réussir l’évaluation selon les Critères communs si son module cryptographique n’est pas validé ou s’il figure sur la liste historique du CMVP. Les certificats existants ne sont pas invalidés rétroactivement, mais après cette date, un certificat 140-2 ne sera plus valable pour les nouvelles acquisitions fédérales, et les délais d’examen actuels du CMVP dépassent largement un an. La plupart des cPP exigent une validation CAVP et CMVP à jour et active pour satisfaire aux activités d’assurance du FCS ; ainsi, un certificat périmé peut retarder ou bloquer la certification selon le profil de protection applicable.
Ce risque est soumis à une échéance. Les modules encore conformes à la norme FIPS 140-2 seront concernés par la transition vers la « liste historique » du CMVP prévue le 21 septembre 2026, ce qui pourrait compromettre la validité d’un certificat existant. Si votre évaluation repose sur l’un de ces modules, le compte à rebours pour la migration a déjà commencé. (Lorsque le chapitre consacré à la norme FIPS 140-3 sera publié, ce sera l’endroit idéal pour y insérer un lien vers celui-ci afin de proposer une présentation plus détaillée.)
Préparation à l'audit selon les Critères communs : ce que vérifient les évaluateurs
Les évaluateurs s'appuient sur des preuves tangibles, et non pas uniquement sur des déclarations d'intention. Chaque évaluation selon les Critères communs est réalisée par un laboratoire accrédité, et le résultat est validé par l'organisme de certification. Il n'existe pas de procédure d'auto-évaluation ni d'alternative gérée par une autorité de régulation. Les six domaines ci-dessous sont ceux sur lesquels le laboratoire et l'organisme de validation se penchent. Considérez-les comme une liste de contrôle :
- Précision cryptographique de l'objectif de sécurité. L'objectif de sécurité décrit-il avec précision les algorithmes, les modes et les tailles de clés effectivement mis en œuvre dans le produit commercialisé ?
- Statut CAVP/CMVP sous-jacent. Les algorithmes et modules mentionnés disposent-ils d'une validation CAVP et CMVP à jour et active ?
- Preuves relatives aux activités d'assurance du profil de protection. Existe-t-il des preuves de test pour chaque activité d'assurance cryptographique prévue dans le profil de protection applicable ?
- Documentation relative à la gestion de la configuration. La documentation de classe ALC fait-elle état d'un contrôle des composants cryptographiques situés à l'intérieur du périmètre évalué ?
- Suivi des changements visant à garantir la continuité. Existe-t-il un processus permettant de déterminer à quel moment une mise à jour de la bibliothèque ou une modification de l'algorithme doit donner lieu à un examen ou à une réévaluation complète ?
- Signature des correctifs et correspondance des versions. Les correctifs sont-ils signés, et la version déployée correspond-elle à celle couverte par le certificat ?
Comment Keyfactor vous aider
En rassemblant toutes ces informations, un modèle opérationnel clair se dessine. AgileSec prend en charge la découverte cryptographique et assure la continuité. Keyfactor Command Il gère le cycle de vie des certificats et des clés. EJBCA fournit des solutions « PKI » basées sur des modules validés. SignServer et les « Signum » signent les versions des produits.
Il existe un raccourci utile qui mérite d'être souligné. « EJBCA » est fourni avec un certificat « Common Criteria » conforme au profil de protection NIAP pour les autorités de certification et figure sur la liste des composants CSfC. Cela signifie que la fonction d'autorité de certification est déjà évaluée, au lieu de constituer un composant supplémentaire à inclure dans votre propre périmètre d'évaluation.
Cette fonctionnalité offre une vue d'ensemble continue et prête à servir de preuve de la cryptographie sous-jacente à un certificat, plutôt qu'une analyse ponctuelle réalisée dans les semaines précédant un audit.
Conclusion et prochaines étapes
Les Critères communs récompensent les fournisseurs qui considèrent la cryptographie comme un fondement réglementé et dont la conformité est continuellement démontrée, et ils dénoncent ceux qui ne le font pas. Le certificat délivré à la fin n'est en réalité qu'un résultat indirect de cette rigueur.
Commencez par les points où les risques sont les plus concentrés. Évaluez votre parc cryptographique et l'état de validation FIPS bien avant l'évaluation, vérifiez que votre « objectif de sécurité » correspond bien au produit livré, et assurez-vous que chaque module référencé dispose d'une validation à jour et active. À partir de là, associez chaque domaine de contrôle à un processus reproductible plutôt qu'à un audit ponctuel.
Prêt à découvrir comment « Keyfactor » répond à chaque domaine de contrôle des Critères communs ? Demander une démo.
Vous avez des questions sur les Critères communs ? Nous avons les réponses.
Qu'est-ce que les Critères communs (ISO/IEC 15408) ?
Les Critèrescommuns constituent le référentiel internationalement reconnu pour l'évaluation de la sécurité des produits informatiques, adopté sous la référence ISO/IEC15408:2022. Les éditeurs définissent leurs exigences dans un « objectif de sécurité », et un laboratoire accrédité vérifie de manière indépendante que le produit répond bien à ces exigences.
Qu'est-ce qu'un objectif de sécurité par rapport à un profil de protection ?
Un objectif de sécuritédéfinit les exigences de sécurité qu'un produit spécifique prétend respecter ; il est souvent élaboré à partir d'un profil de protection publié. Un profil de protection est un ensemble normalisé d'exigences applicables à une catégorie de produits, comme le cPP « Dispositifs réseau » ou le cPP « Chiffrement complet du disque ». Lorsqu'un profil de protection s'applique, l'objectif de sécurité doit déclarer une conformité exacte à celui-ci, ce qui signifie qu'il ne peut ni ajouter ni supprimer d'exigences obligatoires.
Les Critères communs remplacent-ils la validation FIPS 140-3 ?
Non. La lettre de politique n° 5 du NIAP précise clairement qu’une évaluation selon les Critèrescommuns ne remplacepas la validation CAVP ou CMVP. Les algorithmes et modules sous-jacents doivent déjà avoir obtenu une validation à jour avant le début de l’évaluation.
Pourquoi les acheteurs exigent-ils la certification « Critères communs » ?
Pour les acheteurs des secteurs public et de la défense à travers le monde, cette certification constitue souvent un véritable critère d'éligibilité pour les marchés publics. De nombreuses réglementations nationales en matière de marchés publics la mentionnent explicitement comme exigence minimale pour des catégories telles que les équipements réseau, les passerelles VPN et les plateformes de gestion des appareils mobiles.
Les certificats « Common Criteria » sont-ils reconnus dans tous les pays ?
Oui. Les certificats délivrés dans le cadre de l’Accord de reconnaissance des critères communs (Common Criteria Recognition Arrangement) font l’objet d’une reconnaissance mutuelle entre les pays signataires, soit environ 31 pays, ce qui permet aux fournisseurs d’éviter de devoir se soumettre à des évaluations redondantes sur chaque marché.
Que recherchent les évaluateurs lors d'une évaluation selon les Critères communs ?
Les évaluateurs se concentrent sur les preuves fournies, notamment la conformité aux objectifs de sécurité, le statut actif des programmes CAVP/CMVP, les preuves des activités d'assurance du profil de protection, la documentation relative à la gestion de la configuration, le suivi des changements dans le cadre de la continuité de l'assurance, ainsi que la signature des correctifs avec correspondance des versions.
Que devient un certificat lorsque l'on modifie le système cryptographique ?
Les modifications cryptographiques sont suivies par rapport à la référence certifiée, conformément aux exigences de continuité de l'assurance de la CCDB et à la politique de maintenance de votre programme. Selon la nature de la modification, cela peut donner lieu à un examen de la continuité de l'assurance ou à une réévaluation complète.
Quel est l'impact de la liste historique du CMVP sur un certificat « Common Criteria » ?
Un produit ne peut pas réussir pleinement l'évaluation tant que son module cryptographique n'est pas validé ou qu'il figure désormais sur la liste historique du CMVP. Les modules encore conformes à la norme FIPS 140-2 devront faire face à la transition prévue le 21 septembre 2026 ; il convient donc de planifier leur migration avant cette date.
