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.

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.