Auteurs: Jennifer Brady et Apurva Varalikar

Jusqu’à présent, nous avons établi le calendrier prévu de la transition FIPS 140-3 prévue (clé FIPS 140-3 Dates), ainsi que les principaux termes et définitions que vous devez connaître, (Partie 1: Termes et définitions clés). Aujourd’hui, notre série de blogs continue avec les différences entre FIPS 140-2 et FIPS 140-3. Cet article traite des sections individuelles de la norme ISO / CEI 19790 / ISO / CEI 24759 (que nous appellerons FIPS 140-3) et identifie comment elles correspondent et diffèrent des sections de la norme FIPS 140-2 et des IG actuelles. . Cet article se concentrera sur les trois premières sections de FIPS 140-2 et des IG connexes, et les sections 7.2-7.4 de l’ISO / CEI 19790, à savoir la spécification du module cryptographique, les interfaces et les rôles des modules cryptographiques, et les sections Services et Authentification respectivement.

Spécification du module cryptographique

Types de modules cryptographiques / limite cryptographique

La norme FIPS 140-2 (publiée en 2001) a été initialement écrite avec l’idée que tous les modules étaient des modules matériels. Ce n’est que plus tard que différents types de modules (hybrides, logiciels et micrologiciels) ont été ajoutés et définis dans l’IG (IG 1.9, 1.16 et 1.17). De plus, FIPS 140-2 IG 1.9 a limité les modules hybrides à une validation FIPS 140-2 niveau 1.

FIPS 140-3 comprendra le module matériel, le module firmware, le module logiciel, le module logiciel hybride et module de micrologiciel hybride. Il définit explicitement chaque type de module dans la section 7.2.2 de la norme. Il n’y a pas non plus de restriction quant au niveau auquel un module hybride peut être validé dans la nouvelle norme. C’est une excellente nouvelle pour les fournisseurs de modules hybrides qui cherchent à être validés à un niveau supérieur au niveau 1!

Modes de fonctionnement

Deux nouveaux termes; « Fonctionnement normal » et « Fonctionnement dégradé » ont été introduits dans FIPS 140-3 19790 et mentionnés dans le blog précédent.

Le fonctionnement normal est l’endroit où la fonctionnalité complète d’un module cryptographique est disponible et / ou configurable, c’est-à-dire tous les algorithmes, fonctions de sécurité et services.

Une opération dégradée est l’endroit où un sous-ensemble de la fonctionnalité est disponible et / ou configurable à la suite d’une reconfiguration à partir d’un état d’erreur.

Si un module prend en charge une opération dégradée, alors le le mode de fonctionnement ne peut être entré qu’une fois que le module a quitté un état d’erreur. Qu’est-ce que cela signifie? Un mécanisme ou une fonction a échoué et le module est entré dans l’état d’erreur et émet un indicateur d’erreur. Une fois dans un état d’erreur, le module qui prend en charge ce fonctionnement dégradé peut passer en mode de fonctionnement dégradé et continuer à fonctionner avec des capacités réduites. Voici quelques exigences supplémentaires dont vous voudrez vous souvenir lorsque vous préparerez vos modules pour la nouvelle norme. Le module doit fournir des informations d’état lorsque le mode de fonctionnement dégradé est entré, la fonction qui a échoué doit être isolée, tous les autotests conditionnels doivent être effectués, avant l’utilisation de toute fonction cryptographique en mode dégradé, et enfin et surtout, s’il y a une tentative, en mode de fonctionnement dégradé, d’utiliser un algorithme, une fonction de sécurité ou un processus non opérationnel; les services doivent indiquer qu’une telle tentative a été faite.

Voici un commentaire supplémentaire sur l’opération dégradée comme indiqué dans FIPS 140-3. La dernière phrase de la section 7.2.4.3 indique « Si le module échoue aux auto-tests pré-opérationnels, le module ne doit pas entrer en fonctionnement dégradé. » Eh bien, attendez, vous dites, je pensais que l’opération dégradée devait être utilisée lorsque quelque chose comme un auto-test échouait, mais ici, cela signifie que vous ne pouvez pas y entrer? N’oubliez pas que vous ne pouvez entrer en mode dégradé qu’à partir d’un état d’erreur. Donc , le module doit d’abord entrer l’état d’erreur, puis entrer l’opération dégradée, tout en répondant aux autres exigences décrites ci-dessus.

Concepts supplémentaires

Gardez un œil sur le SP 800-140 documents que la CMVP publiera au cours des prochains mois pour voir si les IG de FIPS 140-2 qui n’étaient pas traitées dans la norme ISO 19790: 2012 / ISO 24759: 2014 sont traitées dans l’une des publications spéciales. Plusieurs IG de la première section peut être absorbée dans un manuel de gestion CMVP basé sur le Web, tandis que d’autres peuvent continuer à être traitées comme des IG.

Interfaces de modules cryptographiques

Le blog précédent a abordé les types d’interfaces introduit dans le document ISO (HMI: Hardware Module Interface, SFMI: Software or Firmware Module Interface, HSMI : Hybrid Software Module Interface ou HFMI: Hybrid Firmware Module Interface), nous n’allons donc pas en discuter pour le moment. Au lieu de cela, nous allons aborder les interfaces d’entrée et de sortie.

Interfaces traditionnelles et nouvelles

Les FIPS 140-2 et FIPS 140-3 contiennent toutes deux: les quatre interfaces logiques d’entrée de données, de sortie de données, d’entrée de contrôle et de sortie d’état. FIPS 140-3 introduit une cinquième interface, appelée interface de sortie de contrôle. Une interface de sortie de contrôle est utilisée pour la sortie des commandes. Les signaux et les données de contrôle sont utilisés pour contrôler ou indiquer l’état de fonctionnement. Cette sortie de contrôle peut être une information envoyée à un autre module cryptographique. L’interface d’alimentation est également une interface requise sur tous sauf les modules logiciels.

Trusted Channel

Un autre concept introduit dans la FIPS 140-3 est celui d’un « canal de confiance » qui est similaire au concept FIPS 140-2 d’un «chemin de confiance» (Section 4.7.4 et IG 2.1). Il s’agit d’un lien de communication sécurisé entre le module cryptographique et le périphérique d’extrémité qui envoie et reçoit des données du module, dans le but de sécuriser les CSP non protégés.

Similaire au FIPS 140-2 IG 2.1, il n’y a aucune exigence pour l’utilisation d’un canal de confiance pour les niveaux de sécurité 1 et 2 dans FIPS 140-3. FIPS 140-3 a plusieurs exigences pour les niveaux de sécurité 3 et 4, tels que: les fournisseurs de services cryptographiques en texte brut non protégés, les composants clés et les données d’authentification, qui doivent utiliser un canal de confiance lors de la transmission entre le module et un émetteur / récepteur. Le canal de confiance doit empêcher toute modification, substitution et divulgation non autorisées. Les services utilisant un canal de confiance doivent utiliser une authentification basée sur l’identité et le module doit fournir un indicateur d’état lors de l’utilisation du canal de confiance.

FIPS 140-3 impose une exigence supplémentaire pour un module utilisant un canal de confiance à niveau de sécurité 4 que nous n’avons pas vu dans la précédente FIPS 140-2 ou IG 2.1. Un module de niveau 4 utilisant un canal de confiance doit utiliser l’authentification multifacteur basée sur l’identité pour tous les services utilisant le canal de confiance.

Rôles, services et authentification

Rôles

La norme FIPS 140-2 (section 4.3.1), exige qu’un module prenne en charge à la fois un rôle de responsable crypto et un rôle d’utilisateur, et la prise en charge d’un rôle de maintenance était facultative. FIPS 140-3 a toujours ces trois mêmes rôles, mais seul le rôle de responsable crypto est requis (section 7.4.2). Le rôle d’utilisateur et le rôle de maintenance sont désormais facultatifs.

Services

Services requis

Il y a trois services requis dans la norme FIPS 140-2: afficher l’état , effectuer des auto-tests et exécuter une fonction de sécurité approuvée (section 4.3.2). Ces trois mêmes services sont requis dans FIPS 140-3, en plus de deux services supplémentaires requis: afficher les informations de version des modules et effectuer la remise à zéro (section 7.4.3.1). « Afficher les informations de contrôle de version du module » exige que le module cryptographique fournisse le nom / identifiant du module et les informations de contrôle de version, qui peuvent être vérifiées par rapport à un certificat de validation. Les spécifications du service de remise à zéro sont définies à la section 7.9.7 et seront traitées futur blog.

Service de contournement

FIPS 140-2 et FIPS 140-3 contiennent le service de contournement facultatif. La FIPS 140-3 appelle spécifiquement un opérateur qui peut configurer un contournement la capacité du module doit assumer un rôle autorisé. Bien que la norme FIPS 140-2 n’énonce pas spécifiquement cette exigence, la plupart des authentifications supposées à un rôle autorisé étaient nécessaires étant donné que le service pouvait être utilisé pour divulguer les fournisseurs de services de communication et / affecter la sécurité des informations protégées par le module (IG 3.1).

Sortie cryptographique auto-initiée

Une nouvelle fonctionnalité, abordée dans FIPS 140-3, est la « Capacité de sortie cryptographique auto-initiée. » Ici, le module peut effectuer des opérations cryptographiques ou d’autres fonctions de sécurité approuvées sans aucune intervention de l’opérateur. Le responsable du cryptage peut configurer cette fonctionnalité, alors que cette configuration peut être persistante lors des redémarrages. Deux actions internes sont nécessaires pour activer le service et le module doit indiquer que le service est activé.

Chargement du logiciel / micrologiciel

Le chargement du logiciel / micrologiciel est traité dans la FIPS 140-2 standard, et dans IG 9.7, dans le cadre de l’autotest requis lors du chargement du logiciel / firmware. FIPS 140-2 ne le traite pas comme un service comme nous le voyons dans FIPS 140-3 (section 7.4.3.4). Certaines des exigences énoncées dans le document incluent que, pour que le module reste un module validé, tout logiciel / micrologiciel chargé doit être validé par une autorité de validation. Ici, toutes les sorties de données doivent être inhibées jusqu’à ce que le logiciel / firmware soit terminé avec succès; le test de charge du logiciel / micrologiciel doit être effectué avant l’exécution du code; le module n’exécute pas le code chargé tant que les auto-tests pré-opérationnels ne se sont pas exécutés avec succès et, enfin et surtout, les informations de version des modules doivent être mises à jour pour refléter l’ajout / la mise à jour du logiciel / micrologiciel.

Commentaire supplémentaire

Les services non authentifiés ne sont pas explicitement traités dans FIPS 140-3, nous aurons donc besoin de voir si ce concept, qui est abordé dans l’IG 3.1 actuel, est reporté dans l’un des documents SP800-140. Plus d’informations à ce sujet seront abordées dans les prochains blogs.

Authentification

FIPS 140-3 est similaire à FIPS 140-2 pour l’authentification aux niveaux de sécurité 1-3: (ISO 19790: Niveau 1 – aucune exigence d’authentification; Niveau 2 – authentification minimale basée sur les rôles; Niveau 3 – authentification basée sur l’identité). La plus grande différence réside dans le fait que pour le niveau 2, l’ajout du mot «minimum» a été ajouté, ce qui correspond à la clarification traitée dans l’IG 3.4. L’authentification de niveau 4, dans la norme ISO FIPS 140-3, prend l’authentification un niveau, en exigeant non seulement l’authentification basée sur l’identité. Pour l’authentification de niveau 4, elle doit être basée sur l’identité multifactorielle.

Quelques éléments supplémentaires à noter dans cette section sont que FIPS 140-2 a spécifié la force d’authentification requise par le module. La force n’est pas définie dans FIPS 140-3, mais elle doit être spécifiée dans la politique de sécurité du module. Très probablement, chaque autorité de validation inclura une force d’authentification dans sa documentation supplémentaire.

Les mécanismes d’authentification approuvés ne peuvent pas être mis en œuvre par des procédures documentées ou des règles de sécurité (c’est-à-dire une politique). Cela signifie que les restrictions de taille de mot de passe doivent être configurées et appliquées par le module. Cela peut affecter le fonctionnement de plusieurs des modules actuels. Ainsi , Soyez conscient de cela lorsque vous préparez vos modules pour les exigences ISO.

En bref

Il y a beaucoup à apprendre sur les différences entre FIPS 140-2 et FIPS 140-3. Bien qu’il existe une myriade de similitudes, il y a aussi pas mal de changements. Notre série sur ce sujet se poursuivra, abordant un nouveau domaine à chaque publication. Comme toujours, si vous avez des questions, n’hésitez pas à nous contacter directement. Notre équipe est toujours là pour vous aider.