IBM Cloud Docs
Présentation de PKCS #11 -Plan Standard

Présentation de PKCS #11 -Plan Standard

PKCS #11 est une norme qui spécifie une API, nommée Cryptoki, pour les dispositifs qui contiennent des informations de chiffrement et effectuent des fonctions de chiffrement. L'API Cryptoki suit une approche simple basée sur les objets. Cette approche répond aux objectifs d'indépendance technologique et de partage des ressources, en présentant aux applications une vue commune et logique du dispositif, appelée jeton de chiffrement.

Cryptoki isole une application des détails de l'unité de chiffrement. L'application n'a pas à remplacer l'interface par un autre type d'unité ou à s'exécuter dans un environnement différent. Par conséquent, l'application est portable.Les fonctions de l'interface de ligne de commande Cryptoki sont organisées en différentes catégories, présentées ci-dessous :

Toutes les fonctions PKCS #11 ne sont pas implémentées par IBM Cloud® Hyper Protect Crypto Services. Pour connaître les fonctions PKCS #11 implémentées, voir la rubrique Fonctions PKCS #11 prises en charge.

Pour consulter la documentation sur la norme PKCS #11, voir :

Composants d'implémentation de PKCS #11

Pour vous connecter et utiliser l'API PKCS #11, vous devez comprendre l'API PKCS #11 implémentée par Hyper Protect Crypto Services et la relation avec l'API GREP11. Pour plus d'informations, voir Comparaison des API PKCS #11 et GREP11. Avec la prise en charge de l'interface de programmation #11 PKCS, vous n'avez pas besoin de modifier vos applications existantes qui utilisent la norme PKCS #11. Hyper Protect Crypto Services fournit également les fichiers de clés isolés pour stocker les clés cryptographiques générées par les fonctions PKCS #11 . Ces clés sont protégées par la clé principale et les applications ne voient jamais les fichiers de clés localement.

Avant de pouvoir utiliser l'API PKCS #11, vous devez d'abord installer la bibliothèque PKCS #11. De cette façon, l'application PKCS #11 peut interagir avec la bibliothèque PKCS #11, qui appelle ensuite les fonctions de chiffrement implémentées par Hyper Protect Crypto Services via gRPC. Le diagramme suivant présente les composants clés implémentés par la bibliothèque PKCS #11 Hyper Protect Crypto Services et les interactions entre les différents composants.

Exécution d'opérations de chiffrement avec l'API PKCS #11
Figure 1. Exécution d'opérations de chiffrement à l'aide de l'API PKCS #11

Les sections ci-après décrivent chaque composant PKCS #11 de façon détaillée.

Application

Une application s'exécute dans un espace adresse unique. Toutes les unités d'exécution de contrôle sont exécutées dans l'application. Une application devient une application Cryptoki lorsque la fonction Cryptoki C_Initialize est appelée à partir de l'une des unités d'exécution. Une fois cet appel effectué, l'application peut appeler d'autres fonctions Cryptoki. Lorsque l'application a fini d'utiliser Cryptoki, elle appelle la fonction Cryptoki C_Finalize et cesse d'être une application Cryptoki.

Si vous exécutez une application Java PKCS #11 à l'aide du fournisseur SunPKCS11 sur la plateforme IBM Z (s390x), veillez à utiliser la dernière machine virtuelle Java IBM Semeru et à spécifier l'option -Xjit:noResumableTrapHandler Java lors du démarrage de votre application. Vous pouvez télécharger la dernière version s390x de la JVM IBM Semeru en remplaçant la zone de filtre Architecture par s390x sur la page IBM Semeru Runtime Downloads.

Utilisateur

La norme PKCS #11 définit deux types d'utilisateur pour la connexion : un responsable de la sécurité et un utilisateur standard.Si un utilisateur ne se connecte pas à l'aide de la fonction Cryptoki C_Login, il est connu sous le nom d'utilisateur anonyme.Seul l'utilisateur standard peut accéder aux objets privés sur le jeton et cet accès lui est accordé uniquement après son authentification. Dans l'implémentation de l'API PKCS #11 d'Hyper Protect Crypto Services, les responsables de la sécurité et les utilisateurs standard sont authentifiés par des clés d'API. Les utilisateurs anonymes sont également pris en charge.Pour obtenir des instructions relatives à la configuration des types d'utilisateur PKCS #11, voir la rubrique Pratiques recommandées pour la configuration des types d'utilisateur PKCS #11.

avec le client

L'API Cryptoki exige qu'une application ouvre une ou plusieurs sessions avec un jeton pour permettre l'accès aux objets et aux fonctions du jeton. Une session fournit une connexion logique entre l'application et le jeton. Une session peut être accessible en lecture/écriture ou en lecture seule.

Pour accéder aux objets privés du jeton, l'utilisateur normal doit se connecter et est authentifié. Pour un examen approfondi des sessions, voir PKCS #11 Cryptographic Token Interface Usage Guide.

Objet de clé

Les objets de clé sont stockés dans le magasin de clés en mémoire qui réside avec l'application PKCS #11 ou dans un magasin de données enregistré dans une base de données.Si la valeur de l'attribut CKA_TOKEN est true pour l'objet de clé, celui-ci est stocké dans le magasin de données enregistré dans une base de données. Sinon, l'objet de clé est stocké dans le magasin de clés en mémoire.

Les objets de clé du magasin de clés en mémoire ne font pas l'objet d'une rotation automatique après la rotation de la clé principale. Si les magasins de clés PKCS #11 sont activés dans votre instance de service, vous devez redémarrer toutes les applications PKCS #11 actives pour effacer le magasin de clés en mémoire une fois la rotation de la clé principale terminée.

Comme le montre le diagramme suivant, un objet de clé PKCS #11 est un exemple de classe d'objet PKCS #11 :

  • Données : un objet de données est défini par une application.
  • Certificats : un objet de certificat stocke un certificat.
  • Clés : un objet de clé stocke une clé de chiffrement.La clé peut être une clé publique, une clé privée ou une clé secrète. Chacun de ces types de clé comporte des sous-types qui peuvent être utilisés dans des mécanismes spécifiques.
    • Clé publique : composant public d'une paire de clés qui est utilisée par quiconque souhaitant chiffrer des messages destinés à une personne spécifique ayant accès à la clé privée de la paire de clés. La clé publique est également utilisée pour vérifier les signatures créées par la clé privée.
    • Clé privée : composant privé d'une paire de clés utilisée pour déchiffrer les messages. La clé privée est également utilisée pour créer des signatures.
    • Clé secrète : flux de bits généré qui est utilisé pour chiffrer et déchiffrer les messages de manière symétrique.

Classes d'objets PKCS #11
Figure 2. Classes d'objets PKCS #11

Cloud Identity and Access Management

IBM Cloud Identity and Access Management (IAM) fournit une authentification d'utilisateur et un contrôle d'accès pour l'implémentation de l'API PKCS #11.En utilisant les clés d'interface de programmation, la bibliothèque PKCS #11 obtient des jetons au porteur qui sont utilisés pour effectuer des appels d'interface de programmation Cryptoki.

Cette implémentation de l'API PKCS #11 équivaut à celle d'une clé d'API avec le code confidentiel d'un utilisateur. Pour plus d'informations sur la configuration de l'ID de service et de la clé d'API correspondante, voir Création d'ID de service pour l'utilisateur SO, l'utilisateur normal et l'utilisateur anonyme.

Service de chiffrement

Dans le cadre du processus d'initialisation de la bibliothèque PKCS #11, une connexion gRPC est établie entre cette bibliothèque et IBM Cloud. La connexion gRPC facilite la bibliothèque #11 PKCS pour appeler les fonctions Cryptoki, telles que C_Encrypt, C_Decrypt, C_Signet C_Verify, ce qui nécessite l'utilisation d'un module de sécurité matérielle (HSM).

Magasin de clés

Deux principaux types de magasins de clés sont disponibles :

  • Magasins de clés en mémoire : Stocke les objets de clé temporairement en mémoire. Les objets de clé qui sont stockés dans le magasin de clés en mémoire sont également appelés objets de session. Les objets de session d'une session spécifique sont détruits lorsque vous appelez la fonction C_CloseSession pour cette session. Les objets de session de toutes les sessions sont détruits après l'appel de la fonction C_Finalize.
  • Magasins de clés enregistrés dans une base de données : Stocke les objets de clé dans des bases de données. Les objets de clé qui sont stockés dans le magasin de clés enregistré dans une base de données sont également appelés objets de jeton. Si le paramètre sessionauth est activé et qu'un mot de passe est configuré pour le magasin de clés, le magasin de clés rattaché à la base de données est chiffré et authentifié. Par défaut, le paramètre sessionauth est désactivé. Pour chaque instance de service, un maximum de cinq magasins de clés authentifiés est pris en charge. Vous pouvez activer le paramètre sessionauth pour chiffrer les clés générées dans le magasin de clés ou pour déchiffrer la clé avant de l'utiliser. Le mot de passe peut contenir de 6 à 8 caractères.

Les mots de passe du magasin de clés ne sont pas stockés dans l'instance du service. En tant qu'administrateur du magasin de clés, vous êtes responsable de la conservation d'une copie locale des mots de passe. En cas de perte du mot de passe, vous devez contacter l'équipe d'assistance pour réinitialiser le magasin de clés, et donc effacer toutes les données qu'il contient.

Les magasins de clés en mémoire et les magasins de clés enregistrés dans une base de données comprennent les types de magasins suivants :

  • Magasin de clés public : stocke des clés qui sont moins sensibles et qui peuvent être consultées par n'importe quel type d'utilisateur.
  • Magasin de clés privé : stocke des clés qui chiffrent des données sensibles et qui ne peuvent être consultées que par un utilisateur standard.

Selon les paramètres de types d'utilisateur et d'attributs de clés, les clés générées sont stockées dans des magasins de clés différents. La liste ci-dessous récapitule les critères de stockage des clés :

  • La valeur d'attribut CKA_TOKEN détermine si la clé générée est stockée dans un magasin de clés en mémoire ou dans un magasin de clés enregistré dans une base de données.

    Si vous souhaitez stocker la clé dans le magasin de clés enregistré dans une base de données, définissez CKA_TOKEN sur TRUE dans les modèles de génération d'une clé ou d'une paire de clés. Dans le cadre du processus d'initialisation de la bibliothèque PKCS #11, une connexion gRPC est établie entre cette bibliothèque et IBM Cloud, ce qui facilite le stockage et l'extraction des objets de clé vers ou depuis le magasin de clés enregistré dans une base de données. Par défaut, CKA_TOKEN est défini sur FALSE, ce qui signifie que l'objet de clé est stocké dans un magasin de clés en mémoire, dans l'espace adresse de processus de l'application PKCS #11.

  • La valeur d'attribut CKA_PRIVATE détermine si une clé générée par des utilisateurs normaux doit être stockée dans un magasin de clés public ou privé.

    Par défaut, si un utilisateur est connecté en tant qu'utilisateur normal, les clés générées sont stockées dans les magasins de clés privés, sauf dans le cas où CKA_PRIVATE est défini sur FALSE. Si un utilisateur est connecté en tant que responsable de la sécurité ou s'il n'est pas connecté (utilisateur anonyme), les clés générées sont toujours stockées dans les magasins de clés publics. Si un utilisateur SO ou un utilisateur anonyme définit CKA_PRIVATE sur TRUE dans les modèles de génération de clés, une erreur est renvoyée par le serveur.

    Pour une paire de clés asymétriques, vous avez besoin de définir l'attribut CKA_PRIVATE séparément pour les clés publiques et privées, ce qui signifie que les paires de clés peuvent être stockées dans des magasins de clés différents.

Reportez-vous au tableau ci-dessous pour obtenir des explications détaillées sur la relation entre les types d'utilisateur, les attributs de clés et les magasins de clés, ainsi que sur le mode de stockage des clés.

Tableau 1. Cas de stockage de clés EP11 dans différents magasins de clés
Type d'utilisateur CKA_TOKEN CKA_PRIVATE Magasin pour les clés Privé ou public ?
utilisateur de commande de service FALSE N/A Magasin de clés en mémoire Public
utilisateur de commande de service TRUE N/A Magasin de clés enregistré dans une base de données Public
Utilisateur anonyme FALSE N/A Magasin de clés en mémoire Public
Utilisateur anonyme TRUE N/A Magasin de clés enregistré dans une base de données Public
Utilisateur standard FALSE FALSE Magasin de clés en mémoire Public
Utilisateur standard FALSE TRUE Magasin de clés en mémoire Privé
Utilisateur standard TRUE FALSE Magasin de clés enregistré dans une base de données Public
Utilisateur standard TRUE TRUE Magasin de clés enregistré dans une base de données Privé

Prise en charge de la cryptographie post-quantique

Avec l'API PKCS #11 , vous pouvez également effectuer des opérations cryptographiques post-quantiques. La cryptographie traditionnelle repose sur des problèmes mathématiques complexes qui sont difficiles à résoudre pour les ordinateurs classiques. Cependant, grâce à leurs capacités de calcul, les ordinateurs quantiques peuvent résoudre ces problèmes. La cryptographie post-quantique est considérée comme résistante aux attaques cryptanalytiques des ordinateurs quantiques. Elle utilise généralement des algorithmes asymétriques et a plusieurs approches.

L'API PKCS #11 fournit l'algorithme Dilithium pour la cryptographie post-quantique. Il s'agit d'un schéma de signature numérique basé sur le réseau et qui peut être utilisé pour la génération et la vérification des signatures. Actuellement, seule la version à haute sécurité de la deuxième version de Dilithium est prise en charge et n'est pas disponible pour les opérations C_SignUpdate et C_VerifyUpdate.

L'algorithme Dilithium n'est pris en charge que par la carte de chiffrement IBM 4769, également appelée Crypto Express 7S (CEX7S). Si vous créez vos instances dans des régions de cloud privé virtuel (VPC) dans lesquelles des cartes cryptographiques CEX7S sont utilisées, vous pouvez utiliser l'algorithme Dilithium pour la cryptographie post-quantique avec l'API PKCS #11. Pour obtenir la liste des régions de VPC, consultez Régions et emplacements.

Pour plus d'informations sur la prise en charge de l'algorithme Dilithium dans PKCS #11, consultez Référence d'API PKCS #11. Vous trouverez également des exemples de code d'algorithme Dilithium dans l'exemple de référentielGitHub.