Aller au contenu

PKCS#11 : Cryptoki

Gestion des clés

Interface standard (API C) pour dialoguer avec un module cryptographique matériel ou un token : le même code fonctionne d’un module à l’autre.

Modèle : Slots (lecteurs) → tokens (modules) → sessions → objets (clés, certificats). Chaque objet porte des attributs (sensitive, extractable…).

Mécanismes : Chiffrement, signature, dérivation, wrapping… désignés par des constantes CKM_*. SoftHSM permet de tester sans matériel.

Pièges : Attributs mal posés (CKA_EXTRACTABLE=true) qui laissent sortir une clé ; gestion des sessions et du login par PIN.

Ce qui arrive si on s'en passe

Sans interface normalisée, chaque application doit être écrite pour un module cryptographique précis, et changer de fournisseur revient à réécrire le code. Mal employée, l'interface devient elle-même la fuite : une clé créée avec CKA_EXTRACTABLE à vrai, ou sans l'attribut sensitive, peut sortir du module qui devait la retenir, et la sécurité du coffre matériel se réduit à celle du programme qui l'interroge. Un PIN stocké en clair dans une configuration ouvre enfin les clés à quiconque lit le fichier. Acheter un coffre-fort matériel pour en laisser la porte entrebâillée par un simple booléen témoigne d'un sens de l'équilibre tout à fait personnel.

Explication de la marmotte

Imagine que tu as plusieurs boîtes à outils différentes, mais tu veux utiliser la même clé pour ouvrir chacune d’elles, sans te compliquer la vie. PKCS#11, c’est un peu cette clé universelle : c’est une façon simple et standard pour un ordinateur de parler avec des appareils qui gardent des secrets très importants, comme des coffres-forts numériques. Grâce à cette méthode, un programme peut fonctionner avec plein d’appareils différents sans changer son code, un peu comme si tu pouvais ouvrir plusieurs portes avec une seule clé spéciale.

Où ce terme est utilisé

← Tout le glossaire