Critères communs (ISO/CEI 15408) : ce que signifie l'évaluation cryptographique pour les fournisseurs de produits informatiques

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.

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.

What is Common Criteria (ISO/IEC 15408)?
Common Criteria is the internationally recognized framework for evaluating IT product security, adopted as ISO/IEC 15408:2022. Vendors define requirements in a Security Target, and an accredited lab independently verifies that the product meets those claims.

What is a Security Target versus a Protection Profile?
A Security Target states the security requirements a specific product claims to meet, and it is often built from a published Protection Profile. A Protection Profile is a standardized set of requirements for a product category, such as the Network Device cPP or Full Drive Encryption cPP. Where a Protection Profile applies, the Security Target must claim exact conformance to it, meaning it cannot add or drop mandatory requirements.

Does Common Criteria replace FIPS 140-3 validation?
No. NIAP Policy Letter #5 makes clear that a Common Criteria evaluation is not a substitute for CAVP or CMVP validation. The underlying algorithms and modules should already hold current validation before evaluation begins.

Why do buyers require Common Criteria certification?
For government and defense buyers worldwide, certification is frequently a literal procurement gate. Many national procurement rules cite it directly as a baseline for categories like network devices, VPN gateways, and mobile device management platforms.

Are Common Criteria certificates recognized across countries?
Yes. Certificates issued under the Common Criteria Recognition Arrangement are mutually recognized across signatory nations, spanning roughly 31 countries, so vendors avoid duplicate evaluations in each market.

What do assessors look for in a Common Criteria evaluation?
Assessors focus on demonstrated evidence, including Security Target accuracy, active CAVP/CMVP status, Protection Profile assurance activity evidence, configuration management documentation, assurance continuity change tracking, and patch signing with version matching.

What happens to a certificate when we change cryptography?
Cryptographic changes are tracked against the certified baseline under the CCDB assurance continuity requirements and your scheme’s maintenance policy. . Depending on the change, this can trigger an Assurance Continuity review or a full re-evaluation.

How does the CMVP Historical List affect a Common Criteria certificate?
A product cannot cleanly pass evaluation while its cryptographic module sits unvalidated or has moved to the CMVP Historical List. Modules still on FIPS 140-2 face the September 21, 2026 transition, so plan migration ahead of that date.