Ce que c’est
Implémentation logicielle de l’interface PKCS#11, qui permet d’expérimenter sans module matériel de sécurité.
Ce qu’on y travaille dans le laboratoire
- ·Reproduire les interactions normalement confiées à un HSM
- ·Travailler la génération et la conservation des clés
- ·Préparer une migration vers un module matériel réel
Parcours de maîtrise
Dix niveaux, trente-cinq travaux pratiques en sept blocs — du premier jeton à l’architecture cryptographique préparant un module matériel réel.
Niveau 1 · Bloc 1 · TP 1 à 5 · Livrable : premier jeton
Comprendre le module de sécurité
Poser les concepts avant la première commande.
- Module de sécurité, clé, jeton, emplacement
- Codes d’administration et d’utilisateur, authentification
- Chiffrer et déchiffrer, signer et vérifier, certificats
- Clés symétriques et asymétriques
Niveau 2 · Initiation · Livrable : laboratoire multi-jetons
Architecture du simulateur
Comprendre comment le composant fonctionne à l’intérieur.
- Emplacements, jetons, sessions
- Gestionnaires de sessions, d’emplacements, d’utilisateurs
- Magasin d’objets sécurisé et couche d’abstraction cryptographique
- Création de plusieurs environnements : développement, test, paiement, infrastructure à clés
Niveau 3 · Bloc 2 · TP 6 à 10 · Livrable : bac à sable de l’interface
L’interface normalisée
Maîtriser l’interface standard d’accès aux clés.
- Emplacements, sessions, jetons, objets
- Fonctions d’initialisation, d’ouverture de session, d’authentification
- Génération de clés et de paires de clés, recherche d’objets
- Outils en ligne de commande
Niveau 4 · Bloc 3 · TP 11 à 18 · Livrable : laboratoire de gestion des clés
Gestion des clés
Tenir un cycle de vie complet.
- Génération de clés symétriques et de paires asymétriques
- Import, politique d’export, attributs d’objets
- Enveloppement et désenveloppement de clés
- Rotation et hiérarchie : clé maîtresse, clés de chiffrement de clés, clés de données
Niveau 5 · Bloc 4 · TP 19 à 26 · Livrable : laboratoire d’opérations
Opérations cryptographiques
Exécuter les opérations sans jamais sortir la clé.
- Chiffrement et déchiffrement, signature et vérification
- Empreintes et codes d’authentification de message
- Chiffrement asymétrique avec remplissage, signature sur courbes elliptiques
- Dérivation et rotation de clés
Niveau 6 · Bloc 5 · TP 27 à 30 · Livrable : laboratoire d’infrastructure à clés
Infrastructure à clés publiques
Construire une chaîne de confiance interne.
- Autorité de certification racine puis intermédiaire
- Génération de certificats
- Usage d’une clé privée sans jamais l’extraire
- Certificats et chiffrement du transport
Niveau 7 · Bloc 6 · TP 31 à 33 · Livrable : laboratoire de sécurité des paiements
Sécurité des paiements
Aborder les mécanismes propres à la monétique.
- Hiérarchie de clés de chiffrement et de clés de données
- Clés de zone, clés de terminal, clés d’authentification
- Bloc de code confidentiel, codes de vérification, dérivation par transaction
- Formats normalisés d’échange de clés
Niveau 8 · Bloc 7 · TP 34 · Livrable : laboratoire d’intégration
Intégration
Raccorder les composants du laboratoire au module.
- Intégration applicative par l’interface normalisée
- Gestion des identités et passerelle d’API en amont
- Séparation stricte entre l’application et la gestion des clés
- Raccordement des briques de paiement du laboratoire
Niveau 9 · Projet avancé · Livrable : service cryptographique
Service cryptographique
Faire demander une opération plutôt que livrer une clé.
- Interfaces de gestion des clés, de chiffrement, de signature, de vérification
- Rotation, audit, moteur de politiques
- Les applications demandent une opération, jamais la clé elle-même
- Traçabilité de chaque usage
Niveau 10 · Bloc 7 · TP 35 · Livrable : architecture cryptographique
Vers un module matériel
Préparer la transition sans réécrire les applications.
- Abstraction par l’interface normalisée
- Architecture multi-fournisseurs : laboratoire, test, production
- Migration, haute disponibilité, cycle de vie des clés
- Séparation des responsabilités et cérémonie de clés
Le parcours se valide sur preuve. Chaque niveau se franchit par une démonstration en conditions réelles devant un jury, avec un critère d’acceptation écrit à l’avance — la règle de la Méthode SAKITI appliquée au laboratoire.
La limite à ne jamais perdre de vue
Elle figure en tête du parcours, et elle conditionne tout usage du composant.
SoftHSM2 est destiné au laboratoire, à l’apprentissage, à l’intégration et aux tests. Il ne remplace pas un module matériel certifié dans un environnement de production qui l’exige.
Certaines fonctions spécialisées des modules dédiés au paiement ne sont pas fournies nativement. Elles doivent être étudiées, simulées ou implémentées séparément dans le laboratoire — jamais présentées comme équivalentes.
Le principe qui justifie tout le reste
Une clé ne sort pas du module. L’application ne la manipule jamais.
La hiérarchie de clés
Quatre niveaux, chacun protégeant celui du dessous. C’est le modèle que tout système de paiement reproduit, avec ou sans matériel dédié.
| Niveau | Rôle |
|---|---|
| Clé maîtresse | Protège tout l’édifice ; ne quitte jamais le module |
| Clés de chiffrement de clés | Enveloppent les clés opérationnelles pour leur transport et leur stockage |
| Clés de données | Chiffrent les données applicatives |
| Clés de signature et d’authentification | Signent les messages et en contrôlent l’intégrité |
Le principe d’architecture du service cryptographique
Le niveau 9 énonce une règle simple et souvent violée.
Les applications demandent une opération cryptographique au service ; elles ne récupèrent jamais la clé. Dès qu’une application détient une clé, le module ne protège plus rien — il ne fait que la conserver.
Préparer la production sans réécrire
Le niveau 10 est une leçon d’architecture : l’abstraction par l’interface normalisée permet de changer de fournisseur sans toucher aux applications.
Les sept paliers de compétence
Du premier jeton à l’architecture cryptographique d’un système de paiement.
Aller à la source
Les liens ci-dessous ouvrent les ressources officielles du projet, hors de ce site.
| Ressource | Adresse |
|---|---|
| Site officiel | www.opendnssec.org/softhsm |
| Dépôt public | github.com/softhsm/SoftHSMv2 |
À vérifier au moment de la qualification. Licence exacte, version courante, activité du projet, gestion des vulnérabilités et conditions de support évoluent. Le statut affiché sur ce radar ne vaut ni certification, ni aptitude au déploiement en production dans une infrastructure de paiement.
Les autres briques du domaine
jPOS · Moov ISO8583 · Moov iso8583-connection · OpenSCDP · PC/SC Tools