Aller au contenu principal

Fonctionnement

Comment se comporte la bibliothèque PKCS#11 de DuoKey — le modèle proxy, les sessions, la connexion, les attributs sensibles, la préséance de configuration et les particularités connues.

S'applique à :
PKCS#11 (Cryptoki) 2.40Bibliothèque PKCS#11 de DuoKey

Ces notes complètent la Vue d'ensemble et la Couverture des fonctions. Elles décrivent le comportement du fournisseur afin que les intégrateurs puissent raisonner sur les erreurs, les sessions et la configuration.

Le modèle proxy​

La bibliothèque n'effectue aucune cryptographie localement et ne détient aucune clé. Chaque appel Cryptoki est transformé en une unique requête HTTPS vers le DuoKey Cockpit, qui exécute l'opération auprès du coffre du tenant ou du HSM sous-jacent et retourne le résultat. La bibliothèque se contente d'encoder les payloads et de les transmettre ; le matériel de clé ne traverse jamais la frontière PKCS#11 vers l'hôte de l'application.

  • Sessions série uniquement. Tout l'état de la bibliothèque est sérialisé derrière un verrou global unique, et seules les sessions série sont prises en charge — C_OpenSession rejette toute requête ne comportant pas CKF_SERIAL_SESSION avec CKR_SESSION_PARALLEL_NOT_SUPPORTED. L'aller-retour réseau, plus lent, est effectué sans détenir le verrou, de sorte qu'un backend lent ne bloque pas les appels non liés.
  • Handles d'objets. Les handles entiers PKCS#11 correspondent à des identifiants d'objets côté serveur. L'internement déduplique par identifiant serveur, de sorte que redécouvrir le même objet retourne le même handle. C_DestroyObject supprime l'objet au niveau du Cockpit, puis oublie le handle local.

Connexion et authentification​

Aucun PIN n'est transmis

C_Login n'envoie aucun PIN — les arguments pPin / ulPinLen sont ignorés. L'authentification côté backend est portée à chaque requête par le jeton d'accès porteur issu de la configuration. C_Login n'accepte que CKU_USER et CKU_CONTEXT_SPECIFIC (le rôle SO retourne CKR_USER_TYPE_INVALID) et fait simplement passer la session à l'état utilisateur pour que l'application puisse continuer. C_GenerateKey et C_GenerateKeyPair requièrent l'état connecté.

Attributs et matériel sensible​

C_GetAttributeValue répond à partir d'un descripteur mis en cache et suit le protocole de tampon Cryptoki standard en deux appels (un pointeur de valeur nul retourne la longueur requise ; un tampon trop petit retourne CKR_BUFFER_TOO_SMALL).

  • CKA_VALUE retourne toujours CKR_ATTRIBUTE_SENSITIVE — le matériel de clé brut ne réside que dans le backend.
  • Les clés déclarent des valeurs par défaut raisonnables : CKA_TOKEN = true, CKA_SENSITIVE = true, CKA_EXTRACTABLE = false, CKA_NEVER_EXTRACTABLE = true, CKA_MODIFIABLE = false.
  • Un type d'attribut non reconnu retourne CKR_ATTRIBUTE_TYPE_INVALID. Les attributs non reconnus dans les filtres de recherche et les modèles de génération de clé sont ignorés silencieusement.

Gestion d'AES-GCM​

Pour AES-GCM, le tag d'authentification est concaténé au texte chiffré (ciphertext || tag) puis re-séparé au déchiffrement, de sorte que les appelants voient un unique blob opaque.

Protocole de transport​

Chaque opération Cryptoki est une unique requête HTTPS vers l'unique server_url configuré, authentifiée avec le jeton d'accès porteur. Les échecs cryptographiques sont retournés de manière à permettre à la bibliothèque de mapper la valeur de retour Cryptoki exacte plutôt qu'une erreur de transport générique.

Référence API
Le protocole détaillé de requête/réponse est documenté séparément dans la Documentation développeur → API DKE.

Préséance de configuration​

La bibliothèque lit un fichier TOML depuis DKE_PKCS11_CONF ; les variables d'environnement remplacent le fichier. La préséance est variable d'environnement (non vide) > fichier TOML > valeur par défaut intégrée. Si aucun fichier n'est défini, la configuration est entièrement construite à partir des variables d'environnement (DKE_PKCS11_SERVER_URL est requis au minimum).

  • verify_tls = false désactive la validation des certificats TLS — pour les tests uniquement.
  • La journalisation est initialisée lors de C_Initialize à partir de logging_level / logging_folder.

Voir Vue d'ensemble → Configuration pour le schéma complet de pkcs11.toml et la liste des variables.

Particularités et mises en garde connues​

Cas limites des mécanismes
  • CKM_SHA_1 est annoncé par C_GetMechanismList, mais un digest SHA-1 est rejeté par le backend (CKR_MECHANISM_INVALID) — seuls SHA-256/384/512 sont calculés.
  • Le chiffrement et le déchiffrement utilisent la même primitive du coffre, de sorte que le mécanisme Cryptoki est indicatif — l'intégrité aller-retour est garantie pour les blobs opaques stockés par le consommateur.
Aucune création d'objet locale

C_CreateObject, C_CopyObject et C_SetAttributeValue ne sont pas pris en charge (CKR_FUNCTION_NOT_SUPPORTED). Les objets sont créés via les opérations de génération de clé (C_GenerateKey / C_GenerateKeyPair) ou découverts avec C_FindObjects, jamais assemblés attribut par attribut côté client.

Les consommateurs utilisent des mécanismes différents

Comme il s'agit d'un fournisseur Cryptoki généraliste, les mécanismes annoncés (AES / RSA / EC / SHA / HMAC) sont utilisés selon le consommateur. Oracle TDE utilise uniquement AES — sa clé maître est en AES256 — voir Oracle TDE → Cockpit v2.

Voir aussi