Utilisation des sous-clés OpenPGP dans le développement de Debian

Que sont les clés ?

En cryptographie à clé publique, une clé est en réalité une paire : une clé publique et une clé privée. La clé privée est utilisée pour signer numériquement des fichiers et la clé publique permet à quiconque la possède de vérifier ces signatures. À l’inverse, on utilise la clé publique pour chiffrer des fichiers et la clé privée permet de les déchiffrer.

Aussi longtemps que vous resterez la seule personne ayant accès à la clé privée, les autres pourront se fier aux signatures numériques que vous avez émises et vous pourrez vous fier à la confidentialité des fichiers chiffrés qui vous sont destinés.

Que sont les sous-clés ?

OpenPGP étend le support les sous-clés, lesquelles sont similaires à de simples clés, excepté qu’elles sont liées à une paire de clés maîtresse. Le réel intérêt des sous-clés réside dans la possibilité de les stocker ou de les révoquer indépendamment des clés maîtresses.

En d’autres termes, les sous-clés peuvent être considérées comme des paires de clés séparées, mais automatiquement associées à votre paire de clés principale.

La clé principale actuellement utilisée par GnuPG est exclusivement dédiée aux signatures et une sous-clé de chiffrement est automatiquement créée avec. Sans elle, vous ne pouvez pas chiffrer de fichiers. Debian requiert que vous disposiez de la sous-clé de chiffrement afin que certains documents puissent vous être transmis de façon sécurisée, tel que le mot de passe initial de votre compte shell sur debian.org.

Pourquoi ?

Les sous-clés facilitent la gestion des clés.

La clé maîtresse est d’une certaine importance : elle est la meilleure preuve de votre identité en ligne, au moins pour Debian, et en cas de perte, vous devrez reconstruire votre réputation à partir de rien. Si n’importe qui d’autre accède à votre clé privée maîtresse ou ses sous-clés privées, elles lui permettront de s’approprier votre identité : envoyer des paquets en votre nom, voter en votre nom et, plus largement, tout ce que vous pouviez faire avec. Cela serait néfaste pour Debian et vous ne l’apprécieriez peut-être pas non plus. Gardez donc toutes vos clés privées en sûreté.

Votre clé privée maîtresse devrait être gardée très, très en sûreté. Cependant, appliquer cette politique pour toutes vos clés n’est que peu pratique : à chaque nouvelle signature d’un envoi de paquets, il vous faudrait copier ces paquets sur un support amovible, vous rendre dans votre bunker, prouver aux gardes armés que vous êtes la personne que vous prétendez être par des méthodes biométriques et autres, traverser un labyrinthe mortel et nourrir le chien de garde avec la bonne pâtée pour enfin pouvoir ouvrir votre coffre-fort, en sortir l’ordinateur contenant la clé de signature, puis signer les paquets. Dès lors, vous pourriez rentrer chez vous et, de là, y envoyer vos paquets.

Les sous-clés rendent tout cela plus aisé : vous possédez déjà une sous-clé de chiffrement créée automatiquement et vous pouvez créer une autre sous-clé attribuée aux signatures ; ces sous-clés pourront être conservées sur votre ordinateur principal et devraient être communiquées à un serveur de clés publiques. Vos contacts pourront alors utiliser celles-ci plutôt que votre clé publique maîtresse.

Vous nécessiterez toutefois votre clé privée maîtresse dans certaines circonstances, notamment la modification de vos clés ou de celles de tiers. Plus en détail, ces circonstances sont :

  • la signature des clés d’autres personnes (nommé certification) ou la révocation de telles signatures ;
  • l’ajout, la modification, la suppression et le marquage d’une identité (UID) comme principale (primary) ;
  • la création d’une nouvelle sous-clé ;
  • la révocation d’une identité ou de sous-clés ;
  • le changement de préférences (par exemple, avec setpref) d’une identité ;
  • le changement de date d’expiration de vos (sous-)clés ;
  • la révocation ou la génération d’un certificat de révocation pour une paire de clés maîtresse complète, incluant donc les sous-clés y étant rattachées.

Puisque chaque lien de la Toile de confiance constitue l’approbation d’une concordance entre une clé publique et une identité, les certifications OpenPGP sont relatives à ces identités, et ne s’appliquent donc pas aux sous-clés. En particulier, la création ou la révocation de sous-clés n’affectent pas la réputation de leur clé maîtresse. Ainsi, au cas où une sous-clé serait compromise alors que sa clé maîtresse serait toujours en sécurité, vous pourriez la révoquer puis la remplacer par une nouvelle sans devoir rebâtir votre réputation ni impacter celle d’autres gens dont la clé aurait été signée par la vôtre.

Comment ?

Malheureusement ou non, l’interface utilisateur de GnuPG n’est pas vraiment très fun. Nous vous guiderons donc dans les étapes à suivre.

Ces instructions supposent que vous utilisez un unique ordinateur et que vos clés maîtresses sont stockées sur un support amovible chiffré, ou préférablement deux (vous devriez garder une sauvegarde de vos clés privées). Évidemment, vous devez déjà posséder une paire de clés maîtresses. Si ce n’est pas le cas, dirigez-vous vers la page http://keyring.debian.org/creating-key.html en premier lieu.

1.Avant toute chose, sauvegardez vos fichiers GnuPG ($HOME/.gnupg). Si quelque chose tournait mal durant l’opération, vous pourriez en avoir besoin pour la recommencer en toute sérénité :

    umask 077 ; tar -cf $HOME/gnupg-backup.tar -C $HOME .gnupg

umask 077 appliquera des permissions restrictives à votre sauvegarde.

2.Créer une nouvelle sous-clé de signature.
Trouvez l’identifiant (adresse messagerie) de votre clé : gpg --list-keys

    gpg --edit-key identifiant addkey

Choisissez l’option (4) RSA (signature seule)
Il serait judicieux de choisir une taille de clé de 4096 bits.
Définissez une date d’expiration (vous pouvez planifier une rotation plus fréquente que vos clés maîtresses ou la lier à celle de votre paire maîtresse, et donc ne pas en définir).
GnuPG va (éventuellement) générer une clé, mais il vous faudra attendre qu’il dispose d’assez d’entropie pour cela.
Sauvegardez la clé : gpg> save

Vous pouvez répéter cette procédure et tout aussi bien créer une sous-clé de chiffrement RSA (encrypt only) si vous le désirez. Pour ses besoins, Debian ne requiert qu’une clé de signature.

Maintenant, copier votre dossier $HOME/.gnupg sur votre support chiffré.
C’est ici qu’arrive la partie délicate. Il va vous falloir **supprimer la clé privée maîtresse**, mais GnuPG ne le permet pas de façon pratique.
Vous allez devoir exporter la sous-clé, supprimer la clé privée, puis réimporter la sous-clé.

  • Trouvez l’identifiant de votre nouvelle sous-clé privée : gpg --list-secret-keys
  • Exportez votre (ou vos) sous-clé(s) : gpg --output $HOME/subkeys.gpg --export-secret-subkeys [SubkeyID!...]
    • Sans argument, toutes vos sous-clés seront exportées. Si vous n’en spécifiez que certaines, n’oubliez pas les points d’exclamation !
  • Supprimez votre clé privée maîtresse : gpg --delete-secret-keys KeyID
  • Réimportez vos sous-clés : gpg --import subkeys.gpg
  • Vérifiez que gpg -K affiche sec# en face de l’identifiant de votre clé maîtresse, et non un simple sec. Cela signifie que la clé secrète n'est pas réellement présente.
  • Changez la phrase de passe protégeant vos sous-clés : gpg --edit-key KeyID passwd. De cette manière, même si votre phrase de passe de tous les jours est compromise, la clé privée maîtresse et ses sous-clés sauvegardées précédemment sont encore protégées par votre ancienne phrase de passe.
  • Pour finir, effacez les traces : rm $HOME/subkeys.gpg $HOME/gnupg-backup.tar

Votre machine est maintenant prête pour un usage normal.

Quand vous devrez utiliser vos clés maîtresses, montez votre support chiffré, puis définissez la variable d’environnement GNUPGHOME :

export GNUPGHOME=/media/<votre_support>/gnupg
gpg -K

ou avec l’option –homedir :

gpg --homedir /media/<votre_support>/gnupg -K

Cette commande devrait lister votre clé privée en mentionnant sec devant votre identifiant de clé primaire, et non sec#.

Et ensuite ?

À ce point, vous disposez d’une sous-clé que vous pourrez envoyer au serveur de clés de Debian (si votre clé figure déjà dans le trousseau Debian) ainsi qu’au réseau des serveurs de clés publiques :

gpg --send-keys --keyserver keyring.debian.org KeyID
gpg --send-keys --keyserver subkeys.pgp.net KeyID

L’envoi au serveur de clés de Debian ne fonctionnera que si votre clé publique maîtresse figure déjà au sein des trousseaux Développeurs Debian ou Mainteneurs Debian : ce serveur de clés accepte les mises à jour des clés qu’il connaît, mais pas de nouvelles clés, celles-ci étant ajoutées manuellement par les mainteneurs de ces trousseaux. Par ailleurs, les mises à jour de clés depuis le serveur vers les différents trousseaux sont elles aussi effectuées manuellement, généralement une fois par mois. Voyez la page https://anonscm.debian.org/cgit/keyring/keyring.git/log/ pour savoir si votre sous-clé a été ajoutée.

Cela peut prendre 1 mois pour que la nouvelle sous-clé soit mise à jour vers les serveurs de Debian.

Après ça, vous devriez être en mesure d’envoyer vos paquets vers l’archive Debian en utilisant l’une de vos sous-clés plutôt que votre clé principale.

Révocation !

Si un désastre se produit et qu’il vous faille révoquer une sous-clé, suivez ces consignes :

  • montez votre support chiffré gpg --homedir /media/<votre_support>/gnupg --edit-key KeyID
  • À l’invite de commande gpg>, listez les clés (list), sélectionnez celle en question (key KeyNumber), puis révoquez-la (revkey). Enfin, sauvegardez (save).
  • Envoyez la sous-clé mise à jour au serveur de clés comme expliqué ci-dessus.

Avertissements

Unique ou multiples sous-clés

D’aucuns pourraient être tentés de dédier une sous-clé à chaque machine afin de limiter les dégâts d’une compromission de l’une d’elles. Dans le cas d’une sous-clé unique commune à toutes vos machines, il vous faudrait propager sa révocation à l’ensemble de votre parc.

Toutefois, cela ne vaut que pour les sous-clés de signature. Si plusieurs sous-clés de chiffrement sont disponibles, GPG ne chiffre que pour la plus récente et non pour toutes celles valides connues.

GPG : Suppression et création d’une sous-clé

On veut une sous-clé Authentification cikey@cikey.tld
Supprimer la sous-clé SEA
Créer une sous-clé Authentification

Editer la clé

Ouverture en mode édition de la clé concernée cikey@cikey.tld
gpg --homedir /mnt/usb --expert --edit-key cikey@cikey.tld

gpg (GnuPG) 2.2.1; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

La clef secrète est disponible.

sec  rsa4096/24808875270EAE21
     créé : 2016-03-07  expire : jamais      utilisation : C   
     confiance : ultime        validité : ultime
ssb  rsa4096/042EDD369186EEA6
     créé : 2016-03-07  expire : jamais      utilisation : S   
ssb  rsa4096/6F6D15B69DD92F54
     créé : 2016-03-07  expire : jamais      utilisation : E   
ssb  rsa4096/DDEA557E21CD31BB
     créé : 2017-10-10  expire : jamais      utilisation : SEA 
[  ultime ] (1). cikey Pi <ciket@cikey.tld>
[  ultime ] (2)  cikey Pi <cikey@cikey.tld>

Sélectionner une sous-clé

Sélectionner la sous-clé (ssb) à supprimer , elles sont indexées à partir de 0
Pour information :

0  -->  sec  rsa4096/24808875270EAE21
1  -->  ssb  rsa4096/042EDD369186EEA6
2  -->  ssb  rsa4096/6F6D15B69DD92F54
3  -->  ssb  rsa4096/DDEA557E21CD31BB

La clé SEA a pour index 3, on la sélectionne ,un (*) nous l’indique

gpg> key 3

sec  rsa4096/24808875270EAE21
     créé : 2016-03-07  expire : jamais      utilisation : C   
     confiance : ultime        validité : ultime
ssb  rsa4096/042EDD369186EEA6
     créé : 2016-03-07  expire : jamais      utilisation : S   
ssb  rsa4096/6F6D15B69DD92F54
     créé : 2016-03-07  expire : jamais      utilisation : E   
ssb* rsa4096/DDEA557E21CD31BB
     créé : 2017-10-10  expire : jamais      utilisation : SEA 
[  ultime ] (1). cikey Pi <ciket@cikey.tld>
[  ultime ] (2)  cikey Pi <cikey@cikey.tld>

Supprimer une sous-clé

Supprimer la sous-clé sélectionnée

gpg> delkey
Voulez-vous vraiment supprimer cette clef ? (o/N) o

sec  rsa4096/24808875270EAE21
     créé : 2016-03-07  expire : jamais      utilisation : C   
     confiance : ultime        validité : ultime
ssb  rsa4096/042EDD369186EEA6
     créé : 2016-03-07  expire : jamais      utilisation : S   
ssb  rsa4096/6F6D15B69DD92F54
     créé : 2016-03-07  expire : jamais      utilisation : E   
[  ultime ] (1). cikey Pi <ciket@cikey.tld>
[  ultime ] (2)  cikey Pi <cikey@cikey.tld>

Créer une sous-clé

Créer une sous-clé Authentification de type RSA

gpg> addkey
Sélectionnez le type de clef désiré :
   (3) DSA (signature seule)
   (4) RSA (signature seule)
   (5) Elgamal (chiffrement seul)
   (6) RSA (chiffrement seul)
   (7) DSA (indiquez vous-même les capacités)
   (8) RSA (indiquez vous-même les capacités)
  (10) ECC (signature seule)
  (11) ECC (indiquez vous-même les capacités)
  (12) ECC (chiffrement seul)
  (13) Clef existante
Quel est votre choix ? 8

Actions possibles pour une clef RSA : Signer Chiffrer Authentifier 
Actions actuellement permises : Signer Chiffrer 

   (S) Inverser la capacité de signature
   (C) Inverser la capacité de chiffrement
   (A) Inverser la capacité d'authentification
   (Q) Terminé

Quel est votre choix ? 

On veut que la sous-clé soit uniquement réserver à l’authentification et actuellement on ne peut que Signer Chiffrer
Pour obtenir une sous-clé d’authentification :

  1. (S) Inverser la capacité de signature
  2. (C) Inverser la capacité de chiffrement
  3. (A) Inverser la capacité d’authentification
  4. (Q) Terminé
Quel est votre choix ? S

Actions possibles pour une clef RSA : Signer Chiffrer Authentifier 
Actions actuellement permises : Chiffrer 

   (S) Inverser la capacité de signature
   (C) Inverser la capacité de chiffrement
   (A) Inverser la capacité d'authentification
   (Q) Terminé

Quel est votre choix ? C

Actions possibles pour une clef RSA : Signer Chiffrer Authentifier 
Actions actuellement permises : 

   (S) Inverser la capacité de signature
   (C) Inverser la capacité de chiffrement
   (A) Inverser la capacité d'authentification
   (Q) Terminé

Quel est votre choix ? A

Actions possibles pour une clef RSA : Signer Chiffrer Authentifier 
Actions actuellement permises : Authentifier 

   (S) Inverser la capacité de signature
   (C) Inverser la capacité de chiffrement
   (A) Inverser la capacité d'authentification
   (Q) Terminé

Quel est votre choix ? Q

Saisir la taille RSA à 4096
La clef n’expire pas

les clefs RSA peuvent faire une taille comprise entre 1024 et 4096 bits.
Quelle taille de clef désirez-vous ? (2048) 4096
La taille demandée est 4096 bits
Veuillez indiquer le temps pendant lequel cette clef devrait être valable.
         0 = la clef n'expire pas
      <n>  = la clef expire dans n jours
      <n>w = la clef expire dans n semaines
      <n>m = la clef expire dans n mois
      <n>y = la clef expire dans n ans
Pendant combien de temps la clef est-elle valable ? (0) 
La clef n'expire pas du tout
Est-ce correct ? (o/N) o

A la question suivante , il faudra saisir la passphrase après avoir validé (o)

Faut-il vraiment la créer ? (o/N) o
De nombreux octets aléatoires doivent être générés. Vous devriez faire
autre chose (taper au clavier, déplacer la souris, utiliser les disques)
pendant la génération de nombres premiers ; cela donne au générateur de
nombres aléatoires une meilleure chance d'obtenir suffisamment d'entropie.

sec  rsa4096/24808875270EAE21
     créé : 2016-03-07  expire : jamais      utilisation : C   
     confiance : ultime        validité : ultime
ssb  rsa4096/042EDD369186EEA6
     créé : 2016-03-07  expire : jamais      utilisation : S   
ssb  rsa4096/6F6D15B69DD92F54
     créé : 2016-03-07  expire : jamais      utilisation : E   
ssb  rsa4096/1C9CD930391A9FB7
     créé : 2017-10-10  expire : jamais      utilisation : A   
[  ultime ] (1). cikey Pi <ciket@cikey.tld>
[  ultime ] (2)  cikey Pi <cikey@cikey.tld>

La sous-clé d’authentification a été créée

Sauvegarde et retour au shell

gpg> save
$