Pourquoi les clés principales PGP n'ont-elles qu'une seule sous-clé et associent-elles la certification à la signature par défaut?

Question

Après avoir appris plus sur les sous-clés PGP et comment séparer les rôles de (S) igning, (E) ncryption, (A) uthentication et (C) ertification, j'ai découvert que dans la plupart des cas (?) Une clé principale par défaut a une sous-clé pour séparer le travail de chiffrement:

pub 2048R/AAAAAAAA usage: SC sub 2048R/BBBBBBBB usage: E

Ici, AAAAAAAA est la clé principale. S permet de signer du contenu, C permet de créer de nouvelles sous-clés. (Un avantage de ceci est que vous pouvez donner à AAAAAAAA un délai d'expiration plus long que BBBBBBBB puis créer une nouvelle clé de chiffrement avec AAAAAAAA car elle a C autorisation d'utilisation.)

Cependant, il me semble que les éléments suivants ne seraient pas moins sûrs pour les utilisateurs travaillant sur une seule machine, tout en offrant plus de sécurité aux utilisateurs qui souhaitent recevoir du courrier crypté, par exemple, au travail et à la maison:

pub 2048R/AAAAAAAA usage: C sub 2048R/BBBBBBBB usage: E sub 2048R/CCCCCCCC usage: S

Avec cette configuration, la clé principale AAAAAAAA ne peut pas signer/vérifier ou chiffrer/déchiffrer, mais peut collecter la confiance. Ainsi, vous pouvez donner à la clé principale AAAAAAAA un délai d'expiration plus long et l'utiliser pour ajouter de nouvelles sous-clés. En exportant ensuite BBBBBBBB et CCCCCCCC vers, disons, un ordinateur de travail séparé qui est beaucoup plus déplacé et moins sécurisé, sans la clé principale, si l'ordinateur de travail est compromis, des sous-clés peuvent être révoquées et de nouvelles clés ajoutées, sans perte de réputation.

(Vous pouvez même aller jusqu'à garder la partie secrète de la clé de certification principale dans un bunker secret super sécurisé, bien sûr.)

Je sais que la mise en place de ce paramètre semblait impossible via une interface graphique (ils ne semblent pas intéressés par les sous-clés, que ce soit la visualisation ou l'édition, sans parler du contrôle de ce que la clé principale peut et ne peut pas faire), mais ma question est:

Y a-t-il une raison spécifique pour laquelle cela n'est pas fait avec les implémentations PGP existantes? L'exportation de clés secrètes vers d'autres machines sans privilèges de certification semble être une grande sécurité gagner. (Si seules les interfaces graphiques facilitaient la tâche.) Ma seule pensée possible est que l'importation de sous-clés secrètes avec une clé secrète principale paralysée n'est peut-être pas largement prise en charge, car --export-secret-subkeys (Dans la page de manuel gpg(1)) conseils sur:

--export-secret-keys --export-secret-subkeys Same as --export, but exports the secret keys instead. This is normally not very useful and a security risk. The second form of the command has the special property to render the secret part of the primary key useless; this is a GNU extension to OpenPGP and other implementations can not be expected to suc‐ cessfully import such a key. See the option --simple-sk-check‐ sum if you want to import such an exported key with an older OpenPGP implementation.

Edit : On dirait que Debian suit cette même pratique? https://wiki.debian.org/subkeys

Diti · Answer

J'ai deux points de vue sur cette question: l'un est basé sur des faits historiques (et est un peu technique), tandis que l'autre est purement le mien, une opinion originale.

Quoi qu'il en soit, il semble en effet plus sûr, ou à tout le moins plus pratique, d'utiliser une clé distincte pour les signatures; De cette façon, vous n'utilisez votre clé principale que pour les certifications (et vous pouvez la stocker), et vous n'avez pas à recommencer tout le processus de certification (réunions IRL) si votre clé est compromise.

Faits historiques

Après avoir soigneusement examiné le code source C des versions stables de GnuPG (1.4 et 2.0), j'ai trouvé la fonction responsable de la définition des capacités par défaut des clés publiques; le code (dans le fichier g10/misc.c) ressemble à ça:

476 int 477 openpgp_pk_algo_usage ( int algo ) 478 { 479 int use = 0; 480 481 /* They are hardwired in gpg 1.0. */ 482 switch ( algo ) { 483 case PUBKEY_ALGO_RSA: 484 use = (PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG 485 | PUBKEY_USAGE_ENC | PUBKEY_USAGE_AUTH); 486 break; 487 case PUBKEY_ALGO_RSA_E: 488 use = PUBKEY_USAGE_ENC; 489 break; 490 case PUBKEY_ALGO_RSA_S: 491 use = PUBKEY_USAGE_CERT | PUBKEY_USAGE_SIG; 492 break; ... 509 default: 510 break; 511 } 512 return use; 513 }

J'ai trouvé cette fonction parce que j'ai d'abord regardé comment la génération de clés a été effectuée (g10/keygen.c); c'est en effet lors de la (sous) génération de clés que GnuPG peut donner les "rôles" des clés. Une fois la clé principale créée, vous ne pouvez pas modifier ses capacités.

Le code source ne disait pas grand-chose (sauf qu'une clé RSA pour signature est également livrée avec la possibilité de certifier), mais en exécutant une recherche Web pour le commentaire (ligne 481 ci-dessus) m'a amené à envoyer un message le 2005-08-03 dans le gnupg-users mailing-list, en disant :

GnuPG ne fait pas encore de distinction entre C et S. Donc, cela n'a pas beaucoup de sens d'avoir un moyen de le sélectionner.

Il semble donc que ces paramètres par défaut existent simplement parce que GnuPG ne faisait aucune distinction entre les clés de signature et les clés de certification.

De plus, ces paramètres par défaut peuvent être en place à cause de DSA , comme Simon Richter a souligné :

Pendant un certain temps, gpg a utilisé des clés DSA par défaut, qui ne peuvent être utilisées que pour la signature, puis a dû attacher une sous-clé elGamal (qui ne peut être utilisée que pour le cryptage) pour obtenir une clé entièrement fonctionnelle.

Pour RSA, ce n'est pas nécessaire, mais il a été conservé pour une raison quelconque.

Les sous-types RSA "signer uniquement" ou "chiffrer uniquement" ne sont pas des limitations techniques de l'algorithme.

Faits originaux

De nos jours, je crois que la seule raison de cela (capacités de clé primaire par défaut définies sur SC et non C seul) est pour aider les utilisateurs réguliers avec vérification des signatures.

Disons que vous avez ces deux clés dans votre trousseau de clés:

pub 4096R/00000001 1970-01-01 usage: C uid Alice Owl sub 4096R/AE687A0C 1970-01-01 usage: S sub 4096R/F77A9AF1 1970-01-01 usage: E pub 4096R/FFFFFFFE 1970-01-01 usage: CS uid Bob Penguin sub 4096R/00FF42CD 1970-01-01 usage: E

Alice Owl est un utilisateur régulier de GnuPG, elle est confiante avec OpenPGP et a généré une paire de clés avec GnuPG's --expert drapeau, afin qu'elle puisse définir ses propres capacités clés. La clé primaire a le drapeau C bien sûr , mais elle signe les documents avec une sous-clé.
Bob Penguin ne sait presque rien de la cryptographie. La seule chose qu'il veut, c'est un peu d'intimité/d'intimité. Il a généré sa clé comme n'importe quel utilisateur ordinaire le ferait (sans toucher à aucun paramètre qu'il ne comprend pas).

Maintenant, supposons que vous - le lecteur - soyez aussi un débutant. Vous recevez des documents signés d'Alice et de Bob. Vous connaissez les bases de gnupg, et en particulier:

Les utilisateurs sont identifiés avec leurs clés primaires:
- Je sais donc que Alice est 00000001 , et je sais aussi que Bob est FFFFFFFE .
On peut vérifier les messages avec GnuPG's --verify ou --verify-files options.

Maintenant, vérifions les documents qu'ils vous ont envoyés.

$ gpg --verify from-bob.txt.asc gpg: Signature made <date> using RSA key ID FFFFFFFE gpg: Good signature from "Bob Penguin" $ gpg --verify from-alice.txt.asc gpg: Signature made <date> using RSA key ID AE687A0C gpg: Good signature from "Alice Owl"

Attends quoi? Je pensais que la clé d'Alice était 00000001?

En effet, les signatures sur les documents ne sont pas nécessairement faites avec la clé principale; elles sont faites avec la clé qui a la capacité de signature (S). Il est peu probable qu'un débutant le sache.

Peut-être que l'explication réelle n'a rien à voir avec cette hypothèse ("plus les débutants utilisent les touches SC, mieux c'est pour les autres débutants "), mais c'est la seule explication que je peux trouver sans déranger les contributeurs GnuPG.

Simon Richter · Answer

Diti a presque raison sur le contexte historique, mais la vraie raison historique est dans la partie qu'il/elle a omise.

Pendant un certain temps, gpg a utilisé des clés DSA par défaut, qui ne peuvent être utilisées que pour la signature, puis a dû attacher une sous-clé elGamal (qui ne peut être utilisée que pour le cryptage) pour obtenir une clé entièrement fonctionnelle.

Pour RSA, ce n'est pas nécessaire, mais il a été conservé pour une raison quelconque.

Les sous-types RSA "signer uniquement" ou "chiffrer uniquement" ne sont pas des limitations techniques de l'algorithme.

Tom Leek · Answer

Lorsque vous créez différentes clés pour signer des données et pour signer des certificats, les personnes qui "signent votre clé" doivent en fait signer votre clé de certification , pas vos données- clé de signature; sinon, le Web of Trust ne passera pas votre clé sur le Web. Cependant, lorsque vous signez un e-mail, vous le faites avec votre clé de signature de données, pas votre clé de certification, et c'est votre clé publique de signature de données qui est copiée dans l'e-mail.

Il est donc possible de séparer les clés de signature et de certification, mais cela nécessite que les personnes impliquées et/ou les implémentations logicielles fassent plus attention à ce qu'elles signent et distribuent. Je peux imaginer que vous pourriez rencontrer des problèmes de convivialité.