Modules de sécurité matériels : des clés dans du matériel certifié

Ce qui compte, c'est la preuve exigée pour votre cas d'usage. Nous vérifions le certificat, son statut, la version du matériel et du firmware, ainsi que les conditions d'utilisation documentées. FIPS, Common Criteria et les certifications de paiement ont des périmètres différents. Un certificat seul n'atteste pas automatiquement l'ensemble de la solution.

Il existe différentes certifications pour les HSM. Toutes les certifications ne conviennent pas à tous les usages. Nous vérifions le type exact d'appareil, la version du logiciel et l'usage autorisé. Une preuve pour l'appareil ne vaut pas automatiquement pour tout le système.

Un seul fabricant peut simplifier l'intégration et l'exploitation. Des exigences différentes peuvent toutefois nécessiter des plateformes différentes. Nous séparons d'abord les domaines de sécurité et les cas d'usage. Nous décidons ensuite, de manière argumentée, si plusieurs fabricants sont nécessaires pour cela ; la séparation à elle seule n'impose pas automatiquement des marques différentes.

Un seul fabricant peut simplifier l'exploitation. Parfois, des tâches différentes nécessitent des appareils différents. Nous vérifions si elles nécessitent aussi des fabricants différents.

Le matériel détenu en propre, l'exploitation confiée à un prestataire et les services managés diffèrent en matière de responsabilité, de coûts et de disponibilité. Les sites et les régions sont définis explicitement. La sauvegarde, la reprise après incident, le support du fabricant et une éventuelle sortie ultérieure font partie de la même décision.

Vous pouvez utiliser vos propres appareils ou souscrire un service. Les coûts et les tâches diffèrent. Nous définissons ensemble les sites, les responsabilités et la restauration. Nous anticipons aussi un changement ultérieur.

La prise en charge de la PQC dépend du matériel, du firmware, des interfaces et de l'application. Une mise à jour annoncée ne prouve pas l'existence d'une configuration validée et utilisable en production. Nous inventorions les clés et les protocoles, vérifions l'état actuel côté fabricant et planifions des transitions compatibles, y compris pour les systèmes distants et la restauration.

Les nouveaux procédés cryptographiques doivent être pris en charge par l'appareil et par l'application. Une mise à jour annoncée ne suffit pas à titre de preuve. Nous vérifions les systèmes existants et planifions une transition adaptée.

Un module de sécurité matériel protège les clés cryptographiques et exécute les opérations prises en charge à l'intérieur d'une limite de sécurité définie. La possibilité d'exporter une clé dépend de sa configuration et du procédé pris en charge. Les fournisseurs PKCS #11, CNG ou Java, ainsi que les interfaces de gestion des clés, remplissent des rôles différents. Nous examinons l'ensemble de la chaîne applicative plutôt que la simple mention d'une interface. La cryptographie et les modules de sécurité matériels sont notre cœur de métier. Nous connaissons les séries des fabricants, les numéros de certificat et les limites de chaque plateforme. Nous menons votre projet du choix à l'exploitation courante, en passant par la cérémonie des clés.

Quatre cas d'usage typiques montrent où les HSM sont utilisés à bon escient. Les preuves et mécanismes de protection nécessaires découlent de votre application et de vos exigences concrètes. Un HSM seul n'atteste ni la sécurité de l'ensemble de l'environnement, ni sa conformité.

Ces quatre exemples montrent des tâches possibles pour un HSM. Les preuves nécessaires dépendent de votre usage. Un appareil certifié ne rend pas automatiquement tout l'environnement sûr.

Les AC racines et les AC émettrices peuvent utiliser leurs clés privées via une connexion HSM prise en charge. Cela inclut des profils de certificats, des rôles et des procédures de révocation adaptés. Un serveur d'AC compromis peut déclencher des demandes non autorisées malgré une clé protégée. C'est pourquoi nous sécurisons également les validations et l'application.

Une autorité de certification délivre des certificats. Ses clés privées peuvent se trouver dans un HSM. Le logiciel doit malgré tout être protégé. Sinon, quiconque en prend le contrôle pourrait demander des signatures non autorisées.

Les HSM de paiement prennent en charge des fonctions dédiées au traitement des PIN, aux clés de carte ou à la distribution de clés. Nous vérifions les commandes, les procédures liées aux clés, les exigences des partenaires et le statut de certification concret de l'appareil. Un HSM à usage général ne constitue pas automatiquement un substitut.

Un HSM de paiement est conçu pour les tâches liées aux paiements. Il peut par exemple aider à vérifier les codes PIN. Nous vérifions les fonctions nécessaires et les exigences de vos partenaires. Tous les HSM ne peuvent pas remplir ces tâches.

Les signatures reposant sur un HSM permettent de protéger les clés utilisées pour les logiciels et micrologiciels. Le processus doit en outre définir qui valide et peut signer chaque artefact. Les exigences de conservation des clés sont examinées en fonction du certificat et du modèle de confiance utilisés.

Une signature numérique aide à vérifier un logiciel et son éditeur. Le HSM peut protéger la clé de signature. Il faut en outre définir qui valide quel logiciel pour la signature.

Un système de gestion des clés peut connecter des applications et des espaces de stockage via des protocoles pris en charge comme KMIP, et utiliser un HSM comme composant de protection. Pour le BYOK, la gestion externe des clés et le chiffrement par enveloppe, nous vérifions où chaque clé est utilisée et qui peut déclencher les opérations. Le BYOK seul n'exclut pas un accès du fournisseur aux données.

Un système central peut gérer les clés des applications et du stockage. Un HSM peut alors protéger les clés les plus importantes. Nous vérifions qui a le droit d'utiliser quelle clé. Disposer de votre propre clé dans le cloud ne signifie pas automatiquement que le fournisseur ne peut pas lire les données.

Quatre questions déterminent le fabricant et la série : le niveau de certification exigé, les performances nécessaires, les interfaces de vos applications et le modèle d'exploitation. Nous y répondons lors d'un atelier et consignons le résultat dans un document de décision.

Quatre questions déterminent le fabricant et la série. Premièrement, le niveau de certification exigé. Deuxièmement, les performances nécessaires. Troisièmement, les interfaces de vos applications. Quatrièmement, le modèle d'exploitation. Nous répondons à ces questions lors d'un atelier. Nous consignons le résultat dans un document.

Le débit n'est comparable qu'en tenant compte de l'algorithme, de la taille des clés, du parallélisme et de la connexion client. Nous mesurons également la latence et le comportement en cas de panne. Pour la séparation des locataires, ce qui compte, ce sont les droits, les ressources partagées et l'administration, pas seulement le nombre de partitions.

La vitesse dépend de la tâche à accomplir. La taille des clés et les requêtes simultanées jouent aussi un rôle. Nous testons votre application. En cas de séparation des utilisateurs, nous vérifions aussi les droits et les ressources partagées.

Les fournisseurs, les mécanismes et les attributs de clé doivent correspondre à l'application. Un simulateur peut clarifier les premières questions de développement, mais ne remplace pas une preuve du comportement du matériel, des performances ou du mode de certification. Les tests représentatifs sont réalisés dans l'environnement cible prévu.

L'appareil et l'application doivent être compatibles. Un simulateur aide pour les premiers tests. Il ne reproduit toutefois pas toutes les propriétés du matériel réel. Nous réalisons donc les tests importants dans l'environnement cible prévu.

Les certifications et les exigences réglementaires ne sont pas des labels de qualité interchangeables. Pour la sélection, nous rattachons les preuves au module précis, à sa version et à l'utilisation prévue. Avant l'acquisition, nous vérifions le statut auprès des organismes compétents.

Les certifications et les exigences réglementaires ne sont pas des labels de qualité interchangeables. Pour la sélection, nous rattachons les preuves au module précis, à sa version et à l'utilisation prévue. Avant l'acquisition, nous vérifions le statut auprès des organismes compétents.

Vérifier le certificat CMVP, la Security Policy, les versions, le mode de fonctionnement et le statut