Les sous-clés OpenPGP expliquées — clés séparées pour la signature, le chiffrement et l'authentification

Une « clé » OpenPGP moderne est en réalité un petit ensemble : une clé primaire plus une ou plusieurs sous-clés. La clé primaire signe et certifie. Les sous-clés font le travail quotidien de chiffrement et de signature. Cette séparation est l'une des rares bonnes pratiques opérationnelles incontestablement bonnes dans PGP.

Pourquoi les sous-clés existent

La clé primaire porte votre identité. Son empreinte est ce que les autres vérifient, ce que vous publiez, ce que les gens signent lors des key-signing parties, ce qui est lié à votre identifiant utilisateur. Faire tourner la clé primaire signifie perdre toute la confiance accumulée — chaque signature dessus, chaque référence publiée, chaque carte de visite.

Vous voulez aussi utiliser une clé sur des appareils où elle pourrait être exposée : chiffrer des messages sur votre ordinateur portable, signer des e-mails sur votre téléphone. Si ces clés d'usage quotidien sont la clé primaire, un seul appareil compromis brûle toute l'identité.

Les sous-clés résolvent les deux problèmes. La clé primaire reste froide (hors ligne, air-gappée, ou utilisée uniquement pour certifier). Les sous-clés vont sur les appareils quotidiens. Si une sous-clé est compromise, vous révoquez juste cette sous-clé, la clé primaire signe un nouveau remplacement, et votre identité continue sans perte de confiance accumulée.

Les trois rôles des sous-clés

• Sign (S) — produit des signatures sur des messages, fichiers, commits, versions de paquets. La sous-clé la plus utilisée pour beaucoup de personnes.
• Encrypt (E) — reçoit des messages chiffrés. Quand quelqu'un vous chiffre, son outil choisit votre sous-clé de chiffrement dans le bundle de clé publique.
• Authenticate (A) — utilisée comme clé SSH (via gpg-agent), pour l'authentification client TLS, ou d'autres flux de travail « prouver son identité à un serveur ». Optionnel.

Chaque rôle peut avoir plusieurs sous-clés (ex. une courante + une de secours) et chacune peut avoir un algorithme différent (RSA-4096 pour signer, Curve25519 pour chiffrer, etc.). Les sous-clés peuvent aussi avoir leurs propres dates d'expiration, indépendantes de la clé primaire.

Comportement par défaut

Quand vous générez une clé avec la plupart des outils modernes — GPG, OpenPGP.js, cette application — vous obtenez automatiquement une clé primaire + une sous-clé de chiffrement + (selon l'outil) une sous-clé de signature. Les outils Chiffrer et Signer ici utilisent la clé primaire pour signer parce que le bundle livre une seule sous-clé capable de signer par défaut ; la génération à rôles séparés complets est plus courante en ligne de commande.

Pour un utilisateur occasionnel, la valeur par défaut convient. Pour une hygiène opérationnelle à long terme, vous voulez la configuration à quatre sous-clés : clé primaire froide (Certifier uniquement), sous-clé de signature en ligne, sous-clé de chiffrement en ligne, sous-clé d'authentification optionnelle.

Flux de travail pratique avec GPG

Configurer une fois avec le modèle de clé primaire hors ligne :

gpg --quick-generate-key "Alice <[email protected]>" ed25519 cert never
gpg --edit-key [email protected]
  > addkey   # add a sign subkey
  > addkey   # add an encrypt subkey
  > addkey   # add an auth subkey
  > save

Exportez ensuite la clé privée primaire sur une clé USB, stockez-la hors ligne, et supprimez-la de votre trousseau quotidien avec gpg --delete-secret-keys (les sous-clés restent ; c'est le modèle « stub » spécifique à gpg). Les opérations quotidiennes de signature/chiffrement s'exécutent maintenant uniquement depuis des sous-clés — la clé primaire n'est nécessaire que pour ajouter ou révoquer une autre sous-clé, ce qui devrait être rare.

Rotation d'une sous-clé

• Branchez la clé primaire hors ligne.
• gpg --edit-key [email protected], exécutez addkey pour créer une nouvelle sous-clé du rôle approprié.
• Optionnellement revkey l'ancienne sous-clé pour la faire tourner (ou laissez-la simplement expirer).
• gpg --send-keys pour publier la clé publique mise à jour. Les destinataires récupéreront la nouvelle sous-clé au prochain rafraîchissement.

Leurs messages chiffrés vers l'ancienne sous-clé continuent de se déchiffrer avec l'ancienne sous-clé, que vous gardez pour l'accès aux archives. Les nouveaux messages utiliseront automatiquement la nouvelle sous-clé.