Installer SoftHSM v2 sur Debian/Ubuntu pour un laboratoire PKCS#11

SoftHSM v2 est une implémentation purement logicielle de PKCS#11 (Public-Key Cryptography Standards numéro 11), l’interface que parlent les HSM (Hardware Security Module, module matériel de sécurité). Ce guide monte sur Debian ou Ubuntu un laboratoire complet : installation, jeton, clés, signature, wrap et unwrap, branchement d’OpenSSL, remise à zéro. Il dit aussi où s’arrête l’exercice : SoftHSM imite l’interface d’un HSM, pas ses garanties.

→ Lire l’explication complète de la marmotte

Ce que SoftHSM est, et ce qu’il n’est pas

Le compromis tient en une ligne. On gagne un banc d’essai PKCS#11 gratuit, scriptable, jetable, disponible en trente secondes. On paie avec la totalité de ce qui justifie l’achat d’un HSM : aucune frontière matérielle, des clés stockées dans des fichiers, un calcul cryptographique réalisé dans la mémoire du processus appelant, aucune certification (ni FIPS, Federal Information Processing Standards, ni Critères Communs, voir les certifications des modules matériels).

La position défendue ici ne laisse pas de marge : SoftHSM sert à apprendre, à développer et à tester une intégration, jamais à protéger une clé qui a de la valeur. Pas « en attendant le vrai », pas « pour la préproduction qui contient les vraies données », pas « derrière un pare-feu ». Une clé de production dans SoftHSM est une clé dans un fichier, avec une interface plus pénible qu’un fichier.

Le schéma ci-dessous montre où vivent les clés dans le laboratoire, et ce qu’un HSM réel met à la place de chaque maillon.

À lire de haut en bas : dans le laboratoire, tout se passe dans un seul processus et finit sur le disque ; avec un HSM réel, la bibliothèque n’est qu’un messager et la clé ne quitte pas le boîtier. Pour le modèle complet (emplacements, sessions, objets), la page PKCS#11 expliqué pose les bases ; ce guide les met sous les doigts.

Prérequis et installation des paquets softhsm2 et opensc

Ce qui doit exister avant de commencer :

une Debian ou une Ubuntu maintenue, avec un accès sudo pour l’installation des paquets (le laboratoire lui-même tourne ensuite sans droits root) ;
le paquet softhsm2, qui fournit softhsm2-util et la bibliothèque libsofthsm2.so (branche 2.6 sur les versions courantes des deux distributions) ;
le paquet opensc, qui fournit pkcs11-tool, le couteau suisse en ligne de commande pour parler à n’importe quel module PKCS#11 ;
OpenSSL 3 pour la partie fournisseur ; les options --wrap et --unwrap de pkcs11-tool manquent aux anciennes versions d’OpenSC, d’où le contrôle ci-dessous.

Les commandes de ce guide ont été rejouées sur Debian 13 avec SoftHSM 2.6.1, OpenSC 0.26.1, OpenSSL 3.5 et pkcs11-provider 1.0. Sur Ubuntu, les paquets portent les mêmes noms ; les versions, donc certaines sorties, diffèrent.

sudo apt update
sudo apt install softhsm2 opensc

# Versions réellement installées : elles conditionnent la suite
softhsm2-util --version
pkcs11-tool --help 2>&1 | grep -E -- '--(wrap|unwrap)'

# Chemin réel de la bibliothèque (il varie selon l'architecture)
dpkg -L libsofthsm2 | grep 'libsofthsm2.so'

Le chemin attendu est /usr/lib/softhsm/libsofthsm2.so : sous Debian, c’est un lien symbolique vers la bibliothèque rangée dans le répertoire de l’architecture (/usr/lib/x86_64-linux-gnu/softhsm/ sur un PC 64 bits). Si dpkg -L n’affiche que ce second chemin, c’est celui-là qu’il faut passer à --module dans toute la suite.

softhsm2.conf, tokendir et SOFTHSM2_CONF pour un laboratoire sans root

SoftHSM lit un seul fichier de configuration. Ordre de recherche : la variable d’environnement SOFTHSM2_CONF si elle est définie, puis ~/.config/softhsm2/softhsm2.conf, puis le fichier système /etc/softhsm/softhsm2.conf. Deux directives comptent :

directories.tokendir : le répertoire où chaque jeton devient un sous-répertoire de fichiers .object ;
objectstore.backend : file par défaut (un fichier par objet) ; la valeur db n’existe que si le paquet a été compilé avec le support correspondant, et n’apporte rien à un laboratoire.

Le fichier système pointe vers /var/lib/softhsm/tokens/. Sous Debian, ce répertoire appartient à root et à un groupe softhsm (à constater avec ls -ld /var/lib/softhsm/tokens et getent group softhsm) : sans appartenance au groupe, toute commande s’arrête sur ERROR: Could not load the SoftHSM configuration., message qui accuse la configuration alors que le problème est un droit d’accès. Plutôt que d’ajouter un compte à un groupe système, le laboratoire vit mieux dans le répertoire personnel : rien à nettoyer côté système, et la suppression tient en une commande.

mkdir -p "$HOME/labo-hsm/tokens"
chmod 700 "$HOME/labo-hsm"

cat > "$HOME/labo-hsm/softhsm2.conf" <<EOF
directories.tokendir = $HOME/labo-hsm/tokens
objectstore.backend = file
log.level = INFO
slots.removable = false
EOF

# À exporter dans CHAQUE shell qui doit voir ce laboratoire
export SOFTHSM2_CONF="$HOME/labo-hsm/softhsm2.conf"

Le piège qui consomme le plus de temps sur SoftHSM n’a rien de cryptographique : c’est la variable d’environnement. sudo ne la transmet pas par défaut, un service systemd ne l’hérite pas, un second terminal ne la connaît pas. Dans ces trois cas, la bibliothèque retombe en silence sur le fichier système et présente un autre magasin, vide. Un jeton « disparu » est presque toujours un jeton regardé depuis la mauvaise configuration ou le mauvais compte. Le répertoire tokendir doit aussi exister avant le premier appel : SoftHSM ne le crée pas et répond Failed to enumerate object store.

Initialiser un jeton : softhsm2-util, PIN SO et PIN utilisateur

Un jeton PKCS#11 a deux rôles, chacun avec son PIN (Personal Identification Number, code secret d’ouverture de session). Le SO (Security Officer, responsable de sécurité) administre le jeton : il le réinitialise et fixe le PIN utilisateur, mais n’utilise pas les clés. L’utilisateur crée et utilise les objets privés. Les deux PIN ci-dessous sont des valeurs de laboratoire, à ne réutiliser nulle part.

# --free : prend le premier emplacement libre
softhsm2-util --init-token --free --label labo --so-pin 5678 --pin 1234
# Sortie attendue (le numéro change à chaque initialisation) :
# The token has been initialized and is reassigned to slot 1681312137

Le message contient l’information qui surprend au premier passage : après initialisation, le jeton est réaffecté à un numéro d’emplacement dérivé de son numéro de série, et un nouvel emplacement vide apparaît pour le jeton suivant. Un script qui cible --slot 0 casse donc dès la deuxième exécution. Règle à garder pour toute la suite, et pour tout HSM réel : désigner un jeton par son étiquette ou son numéro de série, jamais par un numéro d’emplacement.

Lister emplacements, jetons et mécanismes avec pkcs11-tool

Pour éviter de retaper le module et l’étiquette à chaque ligne, une fonction de shell (valable sous bash comme sous zsh) :

p11() {
  pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so --token-label labo "$@"
}

softhsm2-util --show-slots   # vue SoftHSM : jeton "labo" et un emplacement non initialisé
p11 --list-token-slots       # vue PKCS#11 : emplacements contenant un jeton
p11 --list-mechanisms        # ce que le module sait faire, et avec quelles tailles de clé
p11 --list-mechanisms | grep -i -E 'wrap|oaep'

La liste des mécanismes est la sortie à archiver. Chaque ligne donne un nom (SHA256-RSA-PKCS, ECDSA, AES-KEY-WRAP…), les tailles de clé acceptées et les opérations permises (sign, verify, wrap, unwrap, generate). C’est le contrat réel du module, par opposition au contrat supposé par le code applicatif. La même commande, lancée plus tard contre le HSM cible, donnera une liste différente ; comparer les deux par diff vaut toutes les matrices de compatibilité d’une plaquette commerciale.

Exemple : générer une paire RSA et une clé AES, signer, vérifier

L’exemple génère une paire RSA (Rivest-Shamir-Adleman) de signature, signe un fichier dans le jeton, puis vérifie deux fois : par le jeton, et à l’extérieur par OpenSSL à partir de la seule clé publique exportée en DER (Distinguished Encoding Rules, encodage binaire). La seconde vérification compte davantage : elle prouve que la signature est interopérable, pas seulement que le module est d’accord avec lui-même.

# Paire RSA 2048 bits : usage signature, clé privée marquée sensible
p11 --login --pin 1234 --keypairgen --key-type rsa:2048 \
    --id 01 --label sig-rsa --usage-sign --sensitive

# Clé AES de 32 octets (256 bits), sensible, sans --extractable
# --private : l'objet n'est visible qu'après ouverture de session
p11 --login --pin 1234 --keygen --key-type AES:32 \
    --id 20 --label aes-fixe --sensitive --private

# Signature : SHA-256 puis RSA, calculés par le module
echo "bon pour signature" > msg.txt
p11 --login --pin 1234 --sign --mechanism SHA256-RSA-PKCS \
    --id 01 --input-file msg.txt --output-file msg.sig

# Vérification par le jeton
p11 --verify --mechanism SHA256-RSA-PKCS \
    --id 01 --input-file msg.txt --signature-file msg.sig
# Sortie attendue : Signature is valid

# Vérification hors jeton : export de la clé publique, puis OpenSSL
p11 --read-object --type pubkey --id 01 --output-file pub.der
openssl dgst -sha256 -verify pub.der -keyform DER -signature msg.sig msg.txt
# Sortie attendue : Verified OK

AES désigne ici l’Advanced Encryption Standard, et SHA-256 le Secure Hash Algorithm à condensat de 256 bits. Deux remarques de terrain. Passer --pin sur la ligne de commande expose le PIN dans l’historique du shell et dans la liste des processus : tolérable avec une valeur de laboratoire, à proscrire partout ailleurs (sans l’option, pkcs11-tool le demande au clavier). Ensuite, le même exercice avec une clé sur courbe elliptique (--key-type EC:prime256v1) réserve deux surprises classiques. SoftHSM 2.6 n’annonce que le mécanisme ECDSA nu, sans condensat intégré : ECDSA-SHA256 est refusé (CKR_MECHANISM_INVALID), et c’est le condensat du fichier, calculé à part, qu’on donne à signer. Puis PKCS#11 rend une signature ECDSA (Elliptic Curve Digital Signature Algorithm) sous forme brute, deux entiers concaténés (64 octets sur cette courbe), alors qu’OpenSSL attend une structure encodée. L’option --signature-format openssl de pkcs11-tool fait la conversion ; l’oublier produit une signature parfaitement valide qu’OpenSSL refuse de vérifier.

Attributs sensitive et extractable, essai de wrap et unwrap

Deux attributs décident de ce qu’une clé peut subir. CKA_SENSITIVE interdit de lire sa valeur par l’interface. CKA_EXTRACTABLE autorise sa sortie sous forme enveloppée (wrap), c’est-à-dire chiffrée par une autre clé. Les deux sont à sens unique : une clé sensible ne redevient pas lisible, une clé non extractable ne le devient jamais. Un gabarit mal réglé à la génération ne se corrige donc pas ; il se paie par une nouvelle clé.

p11 --login --pin 1234 --list-objects
# Extrait (OpenSC 0.26 ; le détail varie selon la version) :
# Private Key Object; RSA
#   label:      sig-rsa
#   ID:         01
#   Usage:      decrypt, sign, signRecover, unwrap
#   Access:     sensitive, always sensitive, never extractable, local

Les lignes Usage et Access sont celles à relire après chaque génération, et l’extrait montre pourquoi : la paire demandée avec --usage-sign seul sait aussi déchiffrer et désenvelopper, et les clés AES de ce guide affichent tous les usages, --usage-wrap ou non. Les valeurs par défaut dépendent à la fois de l’outil (qui ne transmet que certains attributs) et du module (qui choisit quand le gabarit se tait). Vingt ans de gabarits PKCS#11 apprennent que « la valeur par défaut » est une notion qui change selon la personne interrogée. La règle : fixer explicitement chaque attribut de sécurité que l’outil permet de fixer, relire, et tenir l’écart restant pour un point à traiter dans le code applicatif, qui maîtrise son gabarit en entier.

Deux constats se font en une seconde. Les avertissements CKR_ATTRIBUTE_SENSITIVE qui précèdent la liste sont une bonne nouvelle : pkcs11-tool a tenté de lire la valeur d’une clé sensible et le module a refusé. Et sans --login, la même commande ne montre que les objets publics, ici la clé publique RSA. Une clé AES créée sans --private y figurerait aussi : l’attribut CKA_PRIVATE, qui réserve un objet aux sessions ouvertes, ne va pas de soi pour une clé secrète.

Pour l’essai de wrap, il faut une KEK (Key Encryption Key, clé qui chiffre d’autres clés) portant le droit d’envelopper, et une clé cible extractable. Dans pkcs11-tool, la clé d’enveloppe est désignée par --id, la clé à envelopper par --application-id ; la syntaxe a évolué entre versions, man pkcs11-tool fait foi.

# KEK : AES 256 bits, droits wrap et unwrap, non extractable
p11 --login --pin 1234 --keygen --key-type AES:32 \
    --id 10 --label kek-labo --usage-wrap --sensitive --private

# Clé cible : sensible ET extractable (illisible, mais enveloppable)
p11 --login --pin 1234 --keygen --key-type AES:32 \
    --id 21 --label aes-mobile --sensitive --extractable --private

# Wrap : la clé 21 sort chiffrée sous la KEK 10
p11 --login --pin 1234 --wrap --mechanism AES-KEY-WRAP \
    --id 10 --application-id 21 --output-file aes-mobile.wrapped

# Contre-épreuve : même demande sur la clé 20 (never extractable)
p11 --login --pin 1234 --wrap --mechanism AES-KEY-WRAP \
    --id 10 --application-id 20 --output-file refus.wrapped
# Attendu : échec, code CKR_KEY_UNEXTRACTABLE

# Unwrap : réimport sous un nouvel identifiant
p11 --login --pin 1234 --unwrap --mechanism AES-KEY-WRAP \
    --id 10 --input-file aes-mobile.wrapped --key-type AES: \
    --application-id 22 --application-label aes-reimportee --sensitive --private
# Attendu : Key unwrapped, puis Access: sensitive (ni « always sensitive » ni « local »)

Si le module ou l’outil refuse AES-KEY-WRAP (CKR_MECHANISM_INVALID), la liste des mécanismes tranche : le laboratoire accepte aussi un wrap sous clé publique RSA, avec une paire générée avec --usage-wrap. Ce refus éventuel est déjà la leçon principale du guide, en miniature. Point d’attention sur l’unwrap : la clé réimportée reçoit les attributs du nouveau gabarit, pas ceux de l’originale, et perd les mentions always sensitive et local, qui ne valent que pour une clé née dans le module. La contre-épreuve vaut le détour : la même commande d’unwrap sans --sensitive produit une clé dont pkcs11-tool affiche aussitôt la valeur en clair. Une clé sensible à la source renaît lisible à l’arrivée si le gabarit d’import est laxiste ; le wrap protège le transport, pas la destination. Les usages légitimes du mécanisme sont détaillés dans wrap et unwrap et dans KEK et DEK.

Brancher OpenSSL sur le jeton par le fournisseur pkcs11

OpenSSL 3 remplace les anciens moteurs (engines, dépréciés) par des fournisseurs (providers). Pour PKCS#11, le fournisseur vient du paquet pkcs11-provider sur les versions récentes de Debian et d’Ubuntu (à contrôler avec apt-cache policy pkcs11-provider). Sur une version plus ancienne, le repli est le moteur du paquet libengine-pkcs11-openssl, appelé avec -engine pkcs11 -keyform engine : il fonctionne, mais son avenir est derrière lui.

sudo apt install pkcs11-provider

cat > "$HOME/labo-hsm/openssl-p11.cnf" <<'EOF'
openssl_conf = openssl_init

[openssl_init]
providers = provider_sect

[provider_sect]
default = default_sect
pkcs11 = pkcs11_sect

[default_sect]
activate = 1

[pkcs11_sect]
pkcs11-module-path = /usr/lib/softhsm/libsofthsm2.so
# Propre à SoftHSM : sans cette ligne, openssl plante en fin de commande
pkcs11-module-quirks = no-deinit
activate = 1
EOF

# Limité à ce shell : la configuration système d'OpenSSL reste intacte
export OPENSSL_CONF="$HOME/labo-hsm/openssl-p11.cnf"
openssl list -providers      # attendu : default ET pkcs11

Les clés se désignent ensuite par une URI (Uniform Resource Identifier) pkcs11:, qui nomme le jeton et l’objet au lieu d’un fichier :

# Clé publique lue dans le jeton
openssl pkey -pubin -in "pkcs11:token=labo;object=sig-rsa;type=public" -pubout -out pub.pem

# Signature : la clé privée reste dans le jeton, OpenSSL délègue le calcul
openssl dgst -sha256 \
  -sign "pkcs11:token=labo;object=sig-rsa;type=private?pin-value=1234" \
  -out msg2.sig msg.txt

openssl dgst -sha256 -verify pub.pem -signature msg2.sig msg.txt
# Sortie attendue : Verified OK

La section default activée à côté de pkcs11 n’est pas décorative : sans elle, OpenSSL n’a plus d’implémentation pour les algorithmes que le jeton ne fournit pas, et les erreurs obtenues n’évoquent en rien la cause. La ligne pkcs11-module-quirks = no-deinit ne l’est pas davantage : SoftHSM utilise lui-même OpenSSL, et sans elle la commande openssl se termine par une erreur de segmentation, après avoir écrit une signature pourtant valide. Ce réglage tient à SoftHSM, pas à PKCS#11 : il n’a pas à suivre vers un HSM réel sans raison. Le comportement exact des URI (paramètre pin-value, sélection par object ou par id) dépend de la version du fournisseur ; sa documentation prime sur tout exemple. Ce branchement est la répétition générale d’une signature par HSM dans une chaîne d’intégration.

Surface d’attaque, exploitation et remise à zéro du laboratoire SoftHSM

Même jetable, le laboratoire a une surface d’attaque, et la connaître évite de croire qu’un PIN protège quoi que ce soit.

Copie des fichiers du jeton. Les valeurs sensibles sont chiffrées par une clé du jeton, elle-même protégée par une clé dérivée du PIN ; étiquettes et clés publiques restent en clair. Quiconque lit tokendir (compte local, sauvegarde, image de conteneur, dépôt Git où le répertoire a été commité par mégarde) emporte le jeton et attaque le PIN hors ligne, sans compteur d’essais ni verrouillage. Un PIN à quatre chiffres tient le temps d’un café. Contre-mesure : droits 700, aucune clé réelle, et tokendir exclu des sauvegardes comme des dépôts.
Lecture de la mémoire du processus. La bibliothèque calcule dans l’espace d’adressage de l’application : un débogueur attaché, un vidage mémoire ou une faille de l’application exposent la clé déchiffrée. Aucune contre-mesure dans SoftHSM ; c’est précisément ce qu’un boîtier matériel apporte.
Détournement de la configuration. Qui contrôle SOFTHSM2_CONF ou le chemin du module fait signer l’application avec ses propres clés, ou lui fait charger une bibliothèque qui note le PIN au passage. Ce risque survit au passage au matériel : une bibliothèque PKCS#11 reste du code chargé dans le processus, à traiter comme tel (chemin figé, fichier non modifiable par le compte applicatif).

Côté exploitation, la liste est courte par construction. Secrets : deux PIN de laboratoire, sans valeur. Rotation : rien à faire tourner, on détruit et on recrée. Supervision : log.level envoie quelques messages au journal système, sans rapport avec la journalisation native d’un HSM. Sauvegarde : une archive de tokendir restaure tout le jeton, ce qui résume le problème en une phrase. L’actif à conserver est le script qui reconstruit le laboratoire, pas le laboratoire.

# Supprimer un jeton précis
softhsm2-util --delete-token --token labo

# Ou tout raser, configuration comprise
rm -rf "$HOME/labo-hsm"
unset SOFTHSM2_CONF OPENSSL_CONF

Du laboratoire SoftHSM au HSM réel : ce qui se transpose

La promesse est vraie à moitié, et la moitié fausse coûte cher. Vraie : le passage au matériel ne change, côté application, que le chemin du module (et l’étiquette du jeton). Les appels, les URI, la gestion des sessions, l’ouverture de session et les codes d’erreur se répètent à l’identique. Fausse : ce que le module accepte derrière la même interface varie d’un fabricant à l’autre, et parfois d’un mode de configuration à l’autre sur un même boîtier.

Ce qui diverge en pratique :

Les mécanismes. SoftHSM est accommodant. Un HSM réel peut refuser un mécanisme de wrap, une taille de clé ou un bourrage que le laboratoire a acceptés sans broncher, surtout en mode certifié.
Les attributs. Certains boîtiers imposent CKA_SENSITIVE à vrai, interdisent la création d’une clé extractable, ou ajoutent des attributs propriétaires absents de SoftHSM. Un gabarit validé au laboratoire peut être rejeté tel quel.
Les rôles et l’authentification. Quorum d’administrateurs, partitions, authentification par carte : rien de tout cela n’existe dans le modèle à deux PIN.
La performance et la disponibilité. Latence réseau, nombre de sessions, bascule entre boîtiers : SoftHSM n’en dit rien, et ses temps de réponse ne présagent de rien.

La recommandation qui en découle : garder SoftHSM pour le développement et les tests d’intégration automatisés, où il excelle, et prévoir une campagne de validation sur le matériel cible avant toute mise en service, avec la comparaison des listes de mécanismes comme premier livrable. Le code applicatif gagne à interroger le module sur ses capacités plutôt qu’à les supposer ; c’est aussi ce qui rend supportable une migration entre fabricants. Pour ce que le matériel apporte réellement, et ce qu’il n’apporte pas non plus, voir le module cryptographique matériel expliqué et l’éditorial un HSM n’est pas un coffre-fort.

🐝 Ce qui arrive si on s’en passe

Sans banc d’essai, la première rencontre avec PKCS#11 a lieu sur le boîtier de production. Les gabarits d’attributs s’y règlent par tâtonnement, alors que les erreurs y sont irréversibles : une clé créée avec le mauvais réglage ne se corrige pas, elle se régénère, avec les certificats qui en dépendent. Les partitions réelles accumulent des objets d’essai et des traces d’audit sans signification, que personne n’ose ensuite supprimer. La procédure de sortie et de réimport d’une clé n’est jamais répétée avant le jour où elle devient nécessaire. Et le code applicatif, développé faute de mieux contre des clés en fichiers, découvre l’ouverture de session, les sessions concurrentes et les codes d’erreur du module le jour de la bascule, soit le pire moment disponible.

🦫 Explication de la marmotte 🍫

Certaines entreprises gardent leurs clés secrètes dans un boîtier spécialisé qui fait les calculs lui-même et ne laisse jamais sortir les clés. Les programmes lui parlent toujours avec les mêmes demandes : ouvre une session, crée une clé, signe ce fichier. SoftHSM est un logiciel qui répond à ces mêmes demandes, mais sans boîtier : il range les clés dans des fichiers de l’ordinateur, protégés par un code secret. On l’installe, on lui indique dans un petit fichier de réglages où ranger ces fichiers, puis on crée un espace de rangement avec deux codes : un pour l’administrer, un pour s’en servir. On peut alors créer des clés, signer un document, vérifier la signature, et décider pour chaque clé si elle peut être lue ou sortie sous forme chiffrée. Ces deux réglages ne se changent plus ensuite : une clé mal réglée doit être recréée. Si le programme lit le mauvais fichier de réglages, il ne trouve plus rien, alors que rien n’a disparu. Et quiconque copie les fichiers peut essayer tous les codes possibles sans limite, jusqu’à trouver le bon. Voilà pourquoi ce logiciel sert à s’entraîner et à tester ses programmes, jamais à garder une vraie clé. Le jour où le vrai boîtier arrive, les programmes changent très peu, mais le boîtier peut refuser des opérations que le logiciel d’entraînement acceptait.

Pages voisines

Installer SoftHSM v2 sur Debian/Ubuntu pour un laboratoire PKCS#11

Elle cite

: les deux pages se citent l’une l’autre.

Installer SoftHSM v2 sur Debian/Ubuntu pour un laboratoire PKCS#11

Installer SoftHSM v2 sur Debian/Ubuntu pour un laboratoire PKCS#11

Ce que SoftHSM est, et ce qu’il n’est pas

Prérequis et installation des paquets softhsm2 et opensc

softhsm2.conf, tokendir et SOFTHSM2_CONF pour un laboratoire sans root

Initialiser un jeton : softhsm2-util, PIN SO et PIN utilisateur

Lister emplacements, jetons et mécanismes avec pkcs11-tool

Exemple : générer une paire RSA et une clé AES, signer, vérifier

Attributs sensitive et extractable, essai de wrap et unwrap

Brancher OpenSSL sur le jeton par le fournisseur pkcs11

Surface d’attaque, exploitation et remise à zéro du laboratoire SoftHSM

Du laboratoire SoftHSM au HSM réel : ce qui se transpose

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines