Interprétation des journaux d'audit HSM - AWS CloudHSM

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Interprétation des journaux d'audit HSM

Les événements des journaux d'audit de HSM ont des champs standard. Certains types d'événement ont des champs supplémentaires qui capturent des informations utiles sur l'événement. Par exemple, les événements de connexion utilisateur et de gestion des utilisateurs incluent le nom de l'utilisateur et le type d'utilisateur de l'utilisateur. Les commandes de gestion de clé incluent le handle de la clé.

Plusieurs des champs fournissent des informations particulièrement importantes. Le champ Opcode identifie la commande de gestion qui est en cours d'enregistrement. La Sequence No identifie un événement dans le flux de journaux et indique l'ordre dans lequel il a été enregistré.

Par exemple, l'exemple d'événement suivant est le deuxième événement (Sequence No: 0x1) dans le flux de journal pour un HSM. Il indique le HSM qui génère un mot de passe clé de chiffrement, ce qui fait partie de sa routine de démarrage.

Time: 12/19/17 21:01:17.140812, usecs:1513717277140812 Sequence No : 0x1 Reboot counter : 0xe8 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_GEN_PSWD_ENC_KEY (0x1d) Session Handle : 0x1004001 Response : 0:HSM Return: SUCCESS Log type : MINIMAL_LOG_ENTRY (0)

Les champs suivants sont communs à tous les AWS CloudHSM événements du journal d'audit.

Heure

Heure à la laquelle l'événement s'est produit dans le fuseau horaire UTC. L'heure est affichée dans un format compréhensible par les utilisateurs et au format d'heure Unix en microsecondes.

Reboot counter (Compteur de redémarrages)

Compteur ordinal 32 bits persistant, incrémenté quand le matériel HSM est redémarré.

Tous les événements d'un flux de journaux ont la même valeur de compteur de redémarrages. Toutefois, le compteur de redémarrages peut ne pas être unique pour un flux de journaux, car il peut varier entre les différentes instances HSM dans le même cluster.

Sequence No (N° de séquence)

Compteur ordinal 64 bits incrémenté pour chaque événement de journal. Le premier événement de chaque flux de journaux a le numéro de séquence 0x0. Il ne doit y avoir aucun écart dans les valeurs Sequence No. Le numéro de séquence est unique au sein d'un flux de journaux uniquement.

Command type (Type de commande)

Valeur hexadécimale qui représente la catégorie de la commande. Les commandes dans les flux de journaux AWS CloudHSM ont un type de commande CN_MGMT_CMD (0x0) ou CN_CERT_AUTH_CMD (0x9).

Opcode (Code d'opération)

Identifie la commande de gestion qui a été exécutée. Pour obtenir la liste des Opcode valeurs figurant dans les journaux AWS CloudHSM d'audit, consultezRéférence des journaux d'audit HSM.

Session handle (Handle de session)

Identifie la session dans laquelle la commande a été exécutée et l'événement a été consigné.

Réponse

Enregistre la réponse à la commande de gestion. Vous pouvez rechercher les valeurs SUCCESS et ERROR dans le champ Response.

Type de journal

Indique le type de AWS CloudHSM journal du journal qui a enregistré la commande.

  • MINIMAL_LOG_ENTRY (0)

  • MGMT_KEY_DETAILS_LOG (1)

  • MGMT_USER_DETAILS_LOG (2)

  • GENERIC_LOG

Exemples d'événements de journaux d'audit

Les événements d'un flux de journaux enregistrent l'historique du HSM de sa création à sa suppression. Vous pouvez utiliser le journal pour vérifier le cycle de vie de vos HSM et mieux comprendre leur fonctionnement. Lorsque vous interprétez les événements, notez le Opcode, qui indique la commande de gestion ou l'action et le Sequence No, qui indique l'ordre des événements.

Exemple : Initialiser le premier HSM dans un cluster

Le flux de journaux d'audit pour le premier HSM de chaque cluster diffère de manière significative des flux de journaux des autres HSM du cluster. Le journal d'audit du premier HSM de chaque cluster enregistre la création et l'initialisation de celui-ci. Les journaux des autres HSM du cluster, qui sont générées à partir de sauvegardes, commencent par un événement de connexion.

Important

Les entrées d'initialisation suivantes n'apparaîtront pas dans les CloudWatch journaux des clusters initialisés avant le lancement de la fonctionnalité de journalisation d'audit CloudHSM (30 août 2018). Pour plus d'informations, consultez Historique du document.

Les exemples d'événements suivants apparaissent dans le flux de journaux pour le premier HSM d'un cluster. Le premier événement dans le journal, celui contenant Sequence No 0x0, représente la commande permettant d’initialiser le HSM (CN_INIT_TOKEN). La réponse indique que la commande a réussi (Response : 0: HSM Return: SUCCESS).

Time: 12/19/17 21:01:16.962174, usecs:1513717276962174 Sequence No : 0x0 Reboot counter : 0xe8 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_INIT_TOKEN (0x1) Session Handle : 0x1004001 Response : 0:HSM Return: SUCCESS Log type : MINIMAL_LOG_ENTRY (0)

Le deuxième événement de cet exemple de flux de journaux (Sequence No 0x1) enregistre la commande pour créer la clé de chiffrement de mot de passe que le HSM utilise (CN_GEN_PSWD_ENC_KEY).

Il s'agit d'une séquence de démarrage classique pour le premier HSM de chaque cluster. Comme les HSM suivants du même cluster sont des clones du premier HSM, ils utilisent la même clé de chiffrement de mot de passe.

Time: 12/19/17 21:01:17.140812, usecs:1513717277140812 Sequence No : 0x1 Reboot counter : 0xe8 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_GEN_PSWD_ENC_KEY (0x1d) Session Handle : 0x1004001 Response : 0:HSM Return: SUCCESS Log type : MINIMAL_LOG_ENTRY (0)

Le troisième événement de cet exemple de flux de journaux (Sequence No 0x2) est la création de l'utilisateur de l'appareil (AU), qui est le service AWS CloudHSM . Les événements qui impliquent des utilisateurs de HSM incluent des champs supplémentaires pour le nom d'utilisateur et le type d'utilisateur.

Time: 12/19/17 21:01:17.174902, usecs:1513717277174902 Sequence No : 0x2 Reboot counter : 0xe8 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_CREATE_APPLIANCE_USER (0xfc) Session Handle : 0x1004001 Response : 0:HSM Return: SUCCESS Log type : MGMT_USER_DETAILS_LOG (2) User Name : app_user User Type : CN_APPLIANCE_USER (5)

Le quatrième événement de cet exemple de flux de journaux (Sequence No 0x3) enregistre l'événement CN_INIT_DONE, qui termine l'initialisation du HSM.

Time: 12/19/17 21:01:17.298914, usecs:1513717277298914 Sequence No : 0x3 Reboot counter : 0xe8 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_INIT_DONE (0x95) Session Handle : 0x1004001 Response : 0:HSM Return: SUCCESS Log type : MINIMAL_LOG_ENTRY (0)

Vous pouvez suivre les autres événements dans la séquence de démarrage. Ces événements peuvent inclure plusieurs événements de connexion et de déconnexion, et la génération de la clé de chiffrement de clé (KEK). L'événement suivant enregistre la commande qui modifie le mot de passe du responsable du pré-chiffrement (PRECO). Cette commande active le cluster.

Time: 12/13/17 23:04:33.846554, usecs:1513206273846554 Sequence No: 0x1d Reboot counter: 0xe8 Command Type(hex): CN_MGMT_CMD (0x0) Opcode: CN_CHANGE_PSWD (0x9) Session Handle: 0x2010003 Response: 0:HSM Return: SUCCESS Log type: MGMT_USER_DETAILS_LOG (2) User Name: admin User Type: CN_CRYPTO_PRE_OFFICER (6)

Événements de connexion et de déconnexion

Lors de l'interprétation de votre journal d'audit, notez les événements qui enregistrent la connexion au HSM et la déconnexion de celui-ci. Ces événements pour vous aident à déterminer quel utilisateur est responsable des commandes de gestion qui apparaissent dans la séquence entre les commandes de connexion et de déconnexion.

Par exemple, cette entrée de journal enregistre une connexion par un responsable de chiffrement nommé admin. Le numéro de séquence, 0x0, indique qu'il s'agit du premier événement de ce flux de journaux.

Lorsqu'un utilisateur se connecte à un HSM, les autres HSM du cluster enregistrent également un événement de connexion pour l'utilisateur. Vous pouvez trouver les événements de connexion correspondants dans les flux de journaux des autres HSM du cluster peu de temps après l'événement de connexion initiale.

Time: 01/16/18 01:48:49.824999, usecs:1516067329824999 Sequence No : 0x0 Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_LOGIN (0xd) Session Handle : 0x7014006 Response : 0:HSM Return: SUCCESS Log type : MGMT_USER_DETAILS_LOG (2) User Name : admin User Type : CN_CRYPTO_OFFICER (2)

L'exemple d'événement suivant enregistre la déconnexion du responsable de chiffrement admin. Le numéro de séquence, 0x2, indique qu'il s'agit du troisième événement du flux de journaux.

Si l'utilisateur connecté ferme la session sans se déconnecter, le flux de journaux inclut un CN_APP_FINALIZE ou un événement de fermeture de session (CN_SESSION_CLOSE), au lieu d'un événement CN_LOGOUT. Contrairement à l'événement de connexion, cet événement de déconnexion est enregistré généralement uniquement par le HSM qui exécute la commande.

Time: 01/16/18 01:49:55.993404, usecs:1516067395993404 Sequence No : 0x2 Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_LOGOUT (0xe) Session Handle : 0x7014000 Response : 0:HSM Return: SUCCESS Log type : MGMT_USER_DETAILS_LOG (2) User Name : admin User Type : CN_CRYPTO_OFFICER (2)

Si une tentative de connexion échoue parce que le nom d'utilisateur n'est pas valide, le HSM enregistre un événement CN_LOGIN avec le nom et le type d'utilisateur fournis dans la commande de connexion. La réponse affiche un message d'erreur 157, qui explique que le nom d'utilisateur n'existe pas.

Time: 01/24/18 17:41:39.037255, usecs:1516815699037255 Sequence No : 0x4 Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_LOGIN (0xd) Session Handle : 0xc008002 Response : 157:HSM Error: user isn't initialized or user with this name doesn't exist Log type : MGMT_USER_DETAILS_LOG (2) User Name : ExampleUser User Type : CN_CRYPTO_USER (1)

Si une tentative de connexion échoue parce que le mot de passe n'est pas valide, le HSM enregistre un événement CN_LOGIN avec le nom et le type d'utilisateur fournis dans la commande de connexion. La réponse affiche le message d'erreur avec le code d'erreur RET_USER_LOGIN_FAILURE.

Time: 01/24/18 17:44:25.013218, usecs:1516815865013218 Sequence No : 0x5 Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_LOGIN (0xd) Session Handle : 0xc008002 Response : 163:HSM Error: RET_USER_LOGIN_FAILURE Log type : MGMT_USER_DETAILS_LOG (2) User Name : testuser User Type : CN_CRYPTO_USER (1)

Exemple : Créer et supprimer des utilisateurs

Cet exemple montre les événements de journal qui sont enregistrés lorsqu'un responsable de chiffrement (CO) crée et supprime des utilisateurs.

Le premier événement enregistre un CO, admin, qui se connecte au HSM. Le numéro de séquence 0x0 indique qu'il s'agit du premier événement du flux de journaux. Le nom et le type de l'utilisateur qui s'est connecté sont inclus dans l'événement.

Time: 01/16/18 01:48:49.824999, usecs:1516067329824999 Sequence No : 0x0 Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_LOGIN (0xd) Session Handle : 0x7014006 Response : 0:HSM Return: SUCCESS Log type : MGMT_USER_DETAILS_LOG (2) User Name : admin User Type : CN_CRYPTO_OFFICER (2)

L'événement suivant dans le flux de journaux (séquence 0x1) enregistre que le responsable de chiffrement (CO) crée un utilisateur de chiffrement (CU). Le nom et le type du nouvel utilisateur sont inclus dans l'événement.

Time: 01/16/18 01:49:39.437708, usecs:1516067379437708 Sequence No : 0x1 Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_CREATE_USER (0x3) Session Handle : 0x7014006 Response : 0:HSM Return: SUCCESS Log type : MGMT_USER_DETAILS_LOG (2) User Name : bob User Type : CN_CRYPTO_USER (1)

Ensuite, le CO crée un autre responsable de chiffrement, alice. Le numéro de séquence indique que cette action suivait l'action précédente sans action intermédiaire.

Time: 01/16/18 01:49:55.993404, usecs:1516067395993404 Sequence No : 0x2 Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_CREATE_CO (0x4) Session Handle : 0x7014007 Response : 0:HSM Return: SUCCESS Log type : MGMT_USER_DETAILS_LOG (2) User Name : alice User Type : CN_CRYPTO_OFFICER (2)

Plus tard, le CO nommé admin se connecte et supprime le responsable de chiffrement nommé alice. Le HSM enregistre un événement CN_DELETE_USER. Le nom et le type de l'utilisateur supprimé sont inclus dans l'événement.

Time: 01/23/18 19:58:23.451420, usecs:1516737503451420 Sequence No : 0xb Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_DELETE_USER (0xa1) Session Handle : 0x7014007 Response : 0:HSM Return: SUCCESS Log type : MGMT_USER_DETAILS_LOG (2) User Name : alice User Type : CN_CRYPTO_OFFICER (2)

Exemple : Créer et supprimer une paire de clés

Cet exemple montre les événements qui sont enregistrés dans le journal d'audit d'un HSM lorsque vous créez et supprimez une paire de clés.

L'événement suivant enregistre l'utilisateur de chiffrement (CU) nommé crypto_user qui se connecte au HSM.

Time: 12/13/17 23:09:04.648952, usecs:1513206544648952 Sequence No: 0x28 Reboot counter: 0xe8 Command Type(hex): CN_MGMT_CMD (0x0) Opcode: CN_LOGIN (0xd) Session Handle: 0x2014005 Response: 0:HSM Return: SUCCESS Log type: MGMT_USER_DETAILS_LOG (2) User Name: crypto_user User Type: CN_CRYPTO_USER (1)

Ensuite, le CU génère une paire de clés (CN_GENERATE_KEY_PAIR). La clé privée dispose du handle de clé 131079. La clé publique dispose du handle de clé 131078.

Time: 12/13/17 23:09:04.761594, usecs:1513206544761594 Sequence No: 0x29 Reboot counter: 0xe8 Command Type(hex): CN_MGMT_CMD (0x0) Opcode: CN_GENERATE_KEY_PAIR (0x19) Session Handle: 0x2014004 Response: 0:HSM Return: SUCCESS Log type: MGMT_KEY_DETAILS_LOG (1) Priv/Secret Key Handle: 131079 Public Key Handle: 131078

Le CU supprime immédiatement la paire de clés. Un événement CN_DESTROY_OBJECT enregistre la suppression de la clé publique (131078).

Time: 12/13/17 23:09:04.813977, usecs:1513206544813977 Sequence No: 0x2a Reboot counter: 0xe8 Command Type(hex): CN_MGMT_CMD (0x0) Opcode: CN_DESTROY_OBJECT (0x11) Session Handle: 0x2014004 Response: 0:HSM Return: SUCCESS Log type: MGMT_KEY_DETAILS_LOG (1) Priv/Secret Key Handle: 131078 Public Key Handle: 0

Ensuite, un deuxième événement CN_DESTROY_OBJECT enregistre la suppression de la clé privée (131079).

Time: 12/13/17 23:09:04.815530, usecs:1513206544815530 Sequence No: 0x2b Reboot counter: 0xe8 Command Type(hex): CN_MGMT_CMD (0x0) Opcode: CN_DESTROY_OBJECT (0x11) Session Handle: 0x2014004 Response: 0:HSM Return: SUCCESS Log type: MGMT_KEY_DETAILS_LOG (1) Priv/Secret Key Handle: 131079 Public Key Handle: 0

Enfin, le CU se déconnecte.

Time: 12/13/17 23:09:04.817222, usecs:1513206544817222 Sequence No: 0x2c Reboot counter: 0xe8 Command Type(hex): CN_MGMT_CMD (0x0) Opcode: CN_LOGOUT (0xe) Session Handle: 0x2014004 Response: 0:HSM Return: SUCCESS Log type: MGMT_USER_DETAILS_LOG (2) User Name: crypto_user User Type: CN_CRYPTO_USER (1)

Exemple : Générer et Synchroniser une clé

Cet exemple montre l'effet de la création d'une clé dans un cluster avec plusieurs HSM. La clé est générée sur un HSM, extraite du HSM en tant qu'objet masqué, et insérée dans les autres HSM en tant qu'objet masqué.

Note

Les outils du client peuvent échouer à synchroniser la clé. Ou la commande peut inclure le paramètre min_srv qui synchronise la clé uniquement pour le nombre spécifié de HSM. Dans les deux cas, le AWS CloudHSM service synchronise la clé avec les autres HSM du cluster. Comme les HSM enregistrent uniquement les commandes de gestion côté client dans leurs journaux, la synchronisation côté serveur n'est pas consignée dans le journal du HSM.

Examinez d'abord le flux de journaux du HSM qui reçoit et exécute les commandes. Le flux de journaux est nommé pour le HSM ID hsm-abcde123456, mais l'ID du HSM n'apparaît pas dans les événements du journal.

Tout d'abord, l'utilisateur de chiffrement (CU) testuser se connecte au HSM hsm-abcde123456.

Time: 01/24/18 00:39:23.172777, usecs:1516754363172777 Sequence No : 0x0 Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_LOGIN (0xd) Session Handle : 0xc008002 Response : 0:HSM Return: SUCCESS Log type : MGMT_USER_DETAILS_LOG (2) User Name : testuser User Type : CN_CRYPTO_USER (1)

La CU exécute une exSymKeycommande pour générer une clé symétrique. Le HSM hsm-abcde123456 génère une clé symétrique avec un handle de clé 262152. Le HSM enregistre un événement CN_GENERATE_KEY dans son journal.

Time: 01/24/18 00:39:30.328334, usecs:1516754370328334 Sequence No : 0x1 Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_GENERATE_KEY (0x17) Session Handle : 0xc008004 Response : 0:HSM Return: SUCCESS Log type : MGMT_KEY_DETAILS_LOG (1) Priv/Secret Key Handle : 262152 Public Key Handle : 0

L'événement suivant dans le flux de journaux pour hsm-abcde123456 enregistre la première étape du processus de synchronisation de clé. La nouvelle clé (handle de clé 262152) est extraite du HSM en tant qu'objet masqué.

Time: 01/24/18 00:39:30.330956, usecs:1516754370330956 Sequence No : 0x2 Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_EXTRACT_MASKED_OBJECT_USER (0xf0) Session Handle : 0xc008004 Response : 0:HSM Return: SUCCESS Log type : MGMT_KEY_DETAILS_LOG (1) Priv/Secret Key Handle : 262152 Public Key Handle : 0

Examinez maintenant le flux de journaux pour le HSM hsm-zyxwv987654, un autre HSM du même cluster. Ce flux de journaux inclut également un événement de connexion pour l'utilisateur de chiffrement (CU) testuser. La valeur temporelle montre que cela se produit peu de temps après que l'utilisateur se connecte au HSM hsm-abcde123456.

Time: 01/24/18 00:39:23.199740, usecs:1516754363199740 Sequence No : 0xd Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_LOGIN (0xd) Session Handle : 0x7004004 Response : 0:HSM Return: SUCCESS Log type : MGMT_USER_DETAILS_LOG (2) User Name : testuser User Type : CN_CRYPTO_USER (1)

Ce flux de journaux pour ce HSM n'a pas d'événement CN_GENERATE_KEY. Mais il y a un événement qui enregistre la synchronisation de la clé pour ce HSM. L'événement CN_INSERT_MASKED_OBJECT_USER enregistre la réception de la clé 262152 en tant qu'objet masqué. Maintenant, la clé 262152 existe sur les deux HSM du cluster.

Time: 01/24/18 00:39:30.408950, usecs:1516754370408950 Sequence No : 0xe Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_INSERT_MASKED_OBJECT_USER (0xf1) Session Handle : 0x7004003 Response : 0:HSM Return: SUCCESS Log type : MGMT_KEY_DETAILS_LOG (1) Priv/Secret Key Handle : 262152 Public Key Handle : 0

Lorsque l'utilisateur de chiffrement (CU) se déconnecte, cet événement CN_LOGOUT s'affiche uniquement dans le flux de journaux du HSM qui reçoit les commandes.

Exemple : Exporter une clé

Cet exemple montre les événements de journal d'audit qui sont enregistrés lorsqu'un utilisateur de chiffrement (CU) exporte des clés à partir d'un cluster avec plusieurs HSM.

L'événement suivant enregistre la journalisation CU (testuser) dans key_mgmt_util.

Time: 01/24/18 19:42:22.695884, usecs:1516822942695884 Sequence No : 0x26 Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_LOGIN (0xd) Session Handle : 0x7004004 Response : 0:HSM Return: SUCCESS Log type : MGMT_USER_DETAILS_LOG (2) User Name : testuser User Type : CN_CRYPTO_USER (1)

La CU exécute une exSymKeycommande pour exporter la clé7, une clé AES 256 bits. La commande utilise la clé 6, une clé AES 256 bits sur le HSM, comme clé d'encapsulage.

Le HSM qui reçoit la commande enregistre un événement CN_WRAP_KEY pour la clé 7, la clé qui est exportée.

Time: 01/24/18 19:51:12.860123, usecs:1516823472860123 Sequence No : 0x27 Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_WRAP_KEY (0x1a) Session Handle : 0x7004003 Response : 0:HSM Return: SUCCESS Log type : MGMT_KEY_DETAILS_LOG (1) Priv/Secret Key Handle : 7 Public Key Handle : 0

Ensuite, le HSM enregistre un événement CN_NIST_AES_WRAP pour la clé d'encapsulage, la clé 6. La clé est encapsulée, puis immédiatement désencapsulée, mais le HSM n'enregistre qu'un seul événement.

Time: 01/24/18 19:51:12.905257, usecs:1516823472905257 Sequence No : 0x28 Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_NIST_AES_WRAP (0x1e) Session Handle : 0x7004003 Response : 0:HSM Return: SUCCESS Log type : MGMT_KEY_DETAILS_LOG (1) Priv/Secret Key Handle : 6 Public Key Handle : 0

La commande exSymKey écrit les clés exportées dans un fichier, mais ne modifie pas la clé dans le HSM. Par conséquent, il n'y a pas d'événements correspondants dans les journaux des autres HSM du cluster.

Exemple : Importer une clé

Cet exemple montre les événements de journal d'audit qui sont enregistrés lorsque vous importez des clés dans les HSM d'un cluster. Dans cet exemple, l'utilisateur cryptographique (CU) utilise la imSymKeycommande pour importer une clé AES dans les HSM. La commande utilise la clé 6 en tant que clé d'encapsulage.

Le HSM qui reçoit les commandes enregistre un événement CN_NIST_AES_WRAP pour la clé 6, la clé d'encapsulage.

Time: 01/24/18 19:58:23.170518, usecs:1516823903170518 Sequence No : 0x29 Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_NIST_AES_WRAP (0x1e) Session Handle : 0x7004003 Response : 0:HSM Return: SUCCESS Log type : MGMT_KEY_DETAILS_LOG (1) Priv/Secret Key Handle : 6 Public Key Handle : 0

Ensuite, le HSM enregistre un événement CN_UNWRAP_KEY qui représente l'opération d'importation. Le handle de clé 11 est attribué à la clé importée.

Time: 01/24/18 19:58:23.200711, usecs:1516823903200711 Sequence No : 0x2a Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_UNWRAP_KEY (0x1b) Session Handle : 0x7004003 Response : 0:HSM Return: SUCCESS Log type : MGMT_KEY_DETAILS_LOG (1) Priv/Secret Key Handle : 11 Public Key Handle : 0

Lorsqu'une nouvelle clé est générée ou importée, les outils client tentent automatiquement de synchroniser la nouvelle clé pour les autres HSM du cluster. Dans ce cas, le HSM enregistre un événement CN_EXTRACT_MASKED_OBJECT_USER lorsque la clé 11 est extraite du HSM en tant qu'objet masqué.

Time: 01/24/18 19:58:23.203350, usecs:1516823903203350 Sequence No : 0x2b Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_EXTRACT_MASKED_OBJECT_USER (0xf0) Session Handle : 0x7004003 Response : 0:HSM Return: SUCCESS Log type : MGMT_KEY_DETAILS_LOG (1) Priv/Secret Key Handle : 11 Public Key Handle : 0

Les flux de journaux des autres HSM du cluster reflètent l'arrivée de la nouvelle clé importée.

Par exemple, cet événement a été enregistré dans le flux de journaux d'un autre HSM du même cluster. Cet événement CN_INSERT_MASKED_OBJECT_USER enregistre l'arrivée d'un objet masqué qui représente la clé 11.

Time: 01/24/18 19:58:23.286793, usecs:1516823903286793 Sequence No : 0xb Reboot counter : 0x107 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_INSERT_MASKED_OBJECT_USER (0xf1) Session Handle : 0xc008004 Response : 0:HSM Return: SUCCESS Log type : MGMT_KEY_DETAILS_LOG (1) Priv/Secret Key Handle : 11 Public Key Handle : 0

Exemple : Partager une clé et annuler le partage d’une clé

Cet exemple illustre l’événement de journal d’audit qui est enregistré lorsqu’un utilisateur de chiffrement (CU) partage ou annule le partage d’une clé privée ECC avec d'autres utilisateurs de chiffrement. Le CU utilise la commande shareKey et fournit le handle de clé, l’ID utilisateur et la valeur 1 pour partager ou la valeur 0 pour annuler le partage de la clé.

Dans l'exemple suivant, le HSM qui reçoit la commande, enregistre un événement CM_SHARE_OBJECT qui représente l'opération de partage.

Time: 02/08/19 19:35:39.480168, usecs:1549654539480168 Sequence No : 0x3f Reboot counter : 0x38 Command Type(hex) : CN_MGMT_CMD (0x0) Opcode : CN_SHARE_OBJECT (0x12) Session Handle : 0x3014007 Response : 0:HSM Return: SUCCESS Log type : UNKNOWN_LOG_TYPE (5)