Pourquoi faut-il signer sa propre clef?


    "Why should I sign my own public key?", l'original de ce texte, disponible sur http://www.stack.nl/~galactus/remailers/selfsign.html, et reproduit là : http://security.tao.ca/selfsign.shtml, date de 1997.

    Les liens donnés en bas de page sont obsolètes ;(, le texte n'en est pas moins instructif. Cf le traducteur, ou bug brother, ou bien encore l'auteur. Voir aussi l'article "Distribuer vos clefs publiques sur l'uZine.

    Tout ce qui est décrit plus bas a été confirmé en utilisant PGP 2.6.3i (32Bit).
    Le principe reste valide, mais il faut noter que toutes les versions de PGP >= 5 ainsi que GnuPG self-signent automatiquement une clé publique au moment de sa création. Il est donc inutile de le faire manuellement. L'explication "pourquoi faut-il signer sa propre clé", en dehors d'un intérêt théorique et didactique, ne s'applique donc en pratique qu'à PGP <= 2.x.

    Sommaire:

      1. Pourquoi parler de signatures personnelles?
      2. N'importe qui peut-il manipuler mes IDs?
      3. Qu'est ce que la signature fait à la clef?
      4. Comment marchent les attaques de Denial Of Service?
      5. Pourquoi les signatures protègent mes IDs?
      5.1. Les clefs sur un ordinateur personnel.
      5.2. Les clefs sur un serveur de clef public.
      6. A-t-on besoin de serveurs de clefs plus sûrs?
      7. Est-ce qu'une signature personnelle certifie l'identité du propriétaire?
      8. Des arguments contre la signature personnelle?
      9. Signer une nouvelle clef ou des ID supplémentaires.
      10. Comment signer mes ID?
      11. Comment puis-je vérifier une ID?
      12. Résumé.
      13. Références.
      14. Remerciements.

    1. Pourquoi parler de signatures personnelles?

    Un des avantages majeurs du système de cryptage par clef public comme PGP dépend beaucoup du fait que les clefs sont disponibles pour tout le monde. Des canaux sûrs ne sont pas nécessaires à la distribution des clefs. Pourtant un/e utilisateur/rice de PGP doit toujours s'assurer que la clef public qu'il/elle a obtenu appartient réellement à la personne à qui il/elle veut envoyer un message crypté. Si la clef a été signée avec l'identité d'utilisateur d'une personne de confiance, elle peut être considérée comme sûre.

    Il est donc recommandé de signer toutes les clefs publiques. Cette procédure n'est pas décrite dans la documentation PGP (1) de Phil Zimmerman mais elle est abordée tant dans le PGP FAQ (2) que dans plusieurs autres publications sur le Web (3, 4,5). Le propos de cet article est d'offrir une explication compréhensive des thèmes relatifs à la signature personnelle en PGP et de fait d'aborder les problèmes qui ne sont pas listés dans les différentes documentations sur le sujet. Les termes techniques seront évités afin de rendre l'explication plus simple à comprendre.

    2. N'importe qui peut-il manipuler mon identité d'utilisateur (user ID)?

    Il n'y a pas de commande PGP pour modifier une identité. Les seules manipulations possibles sont l'effacement (-kr) et la création d'une nouvelle (-ke). Bien que la clef privée et le mot de passe (en général une phrase entière qui est ensuite codée) ne sont pas nécessaires pour effacer une ID, en créer une autre ne peut être fait que par le possesseur de la clef. Malheureusement, il existe un moyen "officieux" de changer l'ID de quelqu'un/e et PGP n'est même pas nécessaire. Ce type d'attaque (Denial Of Service), qui ne sera pas décrite ici en détail, s'appuie sur le fait que les IDs ne sont pas cryptées quand elles sont sur le keyring (liste/cercle des ID et des clefs publiques des contacts de l'utilisateur).

    Exemple. La clef de John ressemble à ça (pgp -kvv):

    Type Bits/KeyID    Date       User ID
    pub  1024/ABCD1234 1996/01/01 John Deuf <john@company.com>
    

    Pour un cracker, il n'y a aucun problème à la modifier pour:

    Type Bits/KeyID    Date       User ID
    pub  1024/ABCD1234 1996/01/01 John Deuf <john@network.net>
    

    Quand vous dites à PGP d'ajouter cette fausse ID à votre keyring, il le fera sans hésiter. Si la clef originale (ABCD1234) y était déjà, PGP ne la remplacera pas mais ajoutera la fausse adresse comme une nouvelle ID.

    Type Bits/KeyID    Date       User ID
    pub  1024/ABCD1234 1996/01/01 John Deuf <john@company.com>
    John Deuf <john@network.net>
    

    3. Qu'est ce que la signature fait à la clef?

    La signature garantit, avec un certain degré de confiance, que la clef donnée a bien était générée par celui/celle qui dit l'avoir fait. Actuellement, les signataires ne signent plus la clef mais l'ID elle-même (ou l'une d'elles s'il/elle en a plusieurs). Quand une clef est signée, PGP calcule un résumé de quelques informations qui sont uniques à la clef signée. Ce résume, appelé le MD5 hash, est un peu un "checksum" (sommaire de vérification) qui représente les informations hachées. Comme matériaux brut, PGP utilise des informations tirées de la clef publique RSA, des caractères de l'ID qui doit être signée et d'autres choses. Le MD5 hash est alors crypté avec la clef privée de l'utilisateur et le résultat écrit au destinataire comme la signature digitale de l'utilisateur. Personne ne peut forger une signature sans clef privée. En affichant ou en vérifiant les signatures (-kvv, -kc, -ka), PGP regarde toutes les clefs publiques des signataires dans le fichier pubring.pgp. S'il ne trouve pas la clef appropriée, il ne peut ni afficher ni vérifier la signature. Comme la signature digitale renferme des informations unique sur le signataire et l'ID signée, leur manipulation peut être détéctée. Signer est donc indispensable pour que PGP puisse identifier une fausse ID.

    4. Comment fonctionne les attaques de Denial Of Service?

    Si le/la pirate est propriétaire de la fausse ID et qu'il/elle distribue largement la clef manipulée, il lui est possible d'intercepter une partie des e-mails de John. Si le message intercepté a été crypté avec la clef de John (ou celle qui a été modifiée), le/la pirate ne pourra pas le lire mais au moins se l'est-il/elle approprié. Cela s'appelle le Denial Of Service et peut être aussi réalisé en générant et en distribuant une toute nouvelle clef avec l'ID de John. Mais il est peu probable que cette "imitation" soit identique à la véritable clef:

    Type Bits/KeyID    Date       User ID
    pub  1024/0987DCBA 1996/01/01 John Deuf <john@company.com>
    

    Un certain type d'attaque (appelée la "dead beef", décrite pour la première fois par Paul Leyland) peut être utilisée pour agir sur une clef de facon à modifier non seulement l'ID mais aussi la clef (6). Mais commme ce type d'imitation aura une empreinte digitale différente, l'option PGP -kvc peut être utilisée pour neutraliser cette attaque.

    5. Pourquoi la signature protège mes IDs?

    Quand une ID signée a été modifiée, PGP bippera et affichera **** BAD SIGNATURE! **** quand la clef sera ajoutée à votre keyring. Le même avertissement sera affiché en vérifiant la signature avec l'option PGP -kc. Le MD hash décrypté ne correspondant plus aux lettres de l'ID, vous devriez en être alerté, et donc rejeter la clef avant d'informer derechef son véritable propriétaire.

    5.1. Clefs stockées sur un ordinateur personnel.

    N'importe qui peut enlever l'ID et la signature des clef contenues dans son keyring sans même avoir besoin de la clef privée ni du mot de passe. Avant de changer une ID, tout/e bon/ne pirate enlevera d'abord les signatures. Elles ne pourront ainsi prévenir ce genre d'attaque!

    5.2. Clefs déposées sur les serveurs de clefs publiques.

    N'importe qui peut modifier ce qui a été déposé sur les serveurs de clefs publiques. Un/e pirate ou plaisantin/e peut télécharger une clef, changer une ID et la resoumettre au serveur (et donc ajouter une nouvelle ID à cette clef). Aucun message ne pourra bien sûr circuler de cette facon, même pas "N'utilisez plus cette clef", "cette clef est révoquée", "John est un con" ou "ma nouvelle adresse est"...). Le serveur de clef ne vérifie pas l'identité de l'expéditeur. Contrairement au keyring personnel, rien ne peut être effacé sur le serveur. Même le posseseur de la clef ne peut effacer la fausse ID ou signature. Comme le/la pirate ne peut forger la véritable signature, toute ID non signée devra être considérée comme suspecte. Ne vous fiez jamais à ce genre d'ID et clefs non signées. Une ID signée par quelqu'un que vous ne connaissez pas n'est pas plus valide. Le/la pirate peut avoir créé une ou plusieurs clefs et signé la fausse ID lui-même. Une signature connue, considérée comme digne de confiance et vérifiée par -kc assure un degré de sécurité suffisant. Pour vérifier les IDs, les signatures sont préférables pour 2 raisons:

    1. Des clefs publiques supplémentaires ne sont pas nécessaires pour les vérifier (-kc)
    2. En vérifiant seulement la signature, vous vous rendrez compte que certaines ID ont sans aucun doute été ajoutées par le/la propriétaire de la clef lui/elle-même.

    Il est donc fortement recommandé de signer toutes les IDs prévues pour être soumises aux serveurs de clefs publiques. Les IDs non signées doivent toujours être considérées avec méfiance.

    6. A-t-on besoin de serveur de clefs publiques plus sûrs?

    Les serveurs de clefs publiques jouent un rôle important en rendant les clefs disponibles à la communauté des utilisateurs de PGP. C'est pour cela qu'ils ont été conçus. Le logiciel du serveur est conçu pour assurer le stockage et la distribution des clefs. Malheureusement, certaines personnes profitent du fait que les serveurs de clefs n'empêchent pas la manipulation des clefs. Actuellement, les programmeurs des logiciels de serveurs de clefs s'attaquent à l'amélioration des performances et de la sécurité des serveurs (7). Ils mettent au point de nouvelles versions qui ont l'avantage de pouvoir empêcher ces manipulations. Marc Horowitz et Jeffrey Schiller (jis@mit.edu) du MIT ont réécrit les serveurs d'e-mail basé sur les clefs, en utilisant du C à la place du perl et de PGP pour s'occuper des clefs. Le serveur est écrit de facon à être plus rapide. Mais il ne fait actuellemnt pas de vérifications supplémentaires par rapport aux anciens serveurs. Michael Graff (explorer@flame.org) travaille sur les serveurs de clef de 2eme génération, basés sur un système du type de DNS distribuée et déléguée. Ce serveur assurera plus de sécurité avant toute chose mais aussi:

    • ce serveur sera de type distribué. Chaque serveur ne connaitra qu'une partie de la clef.
    • Pour avoir la clef entière, M. Graff projette de fonctionner en envoyant un message à l'adresse e-mail de la clef ( ou de celui qui la propose si il n'y a pas d'adresse dans l'ID) demandant à décoder une chaine de caractère aléatoire et de le renvoyer pour rendre la clef utilisable dans le serveur de clef. Cela demandera d'avoir la clef en question et de savoir comment l'utiliser. Cela devrait également résoudre les problèmes lorsque quelqu'un soumet une fausse clef.
    • Seuls le posseseur de la clef, l'administrateur du site ou un/e de ses délégués aura la possibilité de changer une clef dans la base de donnée. Les mises à jour des clefs ne pourront être proposé que par le possesseur. Tout ce qu'il y a à faire est de signer la requête de changement et le serveur vérifiera la signature.
    • Les mises à jour seront des remplacements, le possesseur decidera exactement du changement.

    Nous ne disposons pas encore de la prochaine génération de serveurs. Changer, ajouter ou signer la clef de quelqu'un d'autre sur un serveur est vivement déconseillé, à moins qu'il n'en ait donné la permission.

    Il existe un registre commercial de clef en fonction au catalogue des services de Four11 (SLED) ou seul le possesseur de la clef, en utilisant sa clef privée peut mettre à jour la sienne. Les vieilles clefs sont purgées. Seules les clefs signées et certifiées par Four11 (8) sont utilisables sur leur serveur.

    7. Est-ce qu'une signature certifie l'identité du propriétaire?

    Non, une signature personnelle n'est pas la panacée de la sécurité sur le Web! Seule la signature de quelqu'un que vous connaissez personnellement (et à qui vous faites confiance) peut être vérifiée. Si la clef entière est contrefaite, le/la pirate peut avoir signé avec la clef secrète:

    pub  1024/0987DCBA 1996/01/01 John Deuf <john@network.net>
    sig       0987DCBA             John Deuf <john@network.net>
    
    Bien qu'étant signée, il ne s'agit pas de la clef de John!

    8. Des arguments contre la signature personnelle?

    "Je n'ai jamais utilisé de clef sans qu'elle ne soit signée par un-e ami-e de confiance. Malgre tout la signature personnelle n'a pas de sens a mes yeux. Signer personnellement est une perte d'espace et encourage une confiance abusive."

    Si vous êtes un puriste de la sécurité, vous êtes méfiant a propos de toutes les clefs. Si une fausse clef arrive dans votre keyring, vous la rejetez et n'envoyez jamais de messages cryptés à son possesseur. Mais... envoyez-vous des messages en texte clair à la place? Ou refusez vous toute communications à des personnes inconnues? La plupart des utilisateurs-rices de PGP dans le monde n'écrivent des messages cryptés à des inconnus-es qu'une fois de temps en temps. Et majoritairement ils-elles utilisent des clefs qu'ils-elles ne peuvent pas vérifier. La signature personnelle est au moins une preuve que l'ID n'a pas été manipulée. Les serveurs de clef n'ont pas été configurés pour servir de répertoires d'e-mail. Si vous envoyez un mail à quelqu'un d'inconnu/e et que vous prenez son adresse d'une source sûre, le pire qui peut arriver est qu'elle ne puisse décrypter votre mail parce que vous n'avez pas utilisé une clef valide. Bien sur, le destinataire vous en informera et la fois d'après vous utiliserez une clef correcte. Les E-mail devrait toujours être encryptés, même les messages à des inconnus/es dont la clef ne peut être vérifiée. Les clefs qui n'ont pas votre confiance, même si vous ne savez pas à qui elles sont, peuvent aussi être trés utiles. Même si vous ne savez pas qui est de l'autre côté de l'e-mail, et tant qu'il s'agit de la même personne, la clef est au moins aussi sécurisée que si la conversation s'était déroulé sans cryptographie, voir même plus.

    9. Signer une nouvelle clef ou une ID supplémentaire.

    Quand vous créez une nouvelle clef à votre nom et que vous avez déjà une clé qui a été signée par des personnes de confiance, vous pouvez signer votre nouvelle ID avec celle-ci. Pour tous-tes les utilisateurs-rices de PGP qui ont votre ancienne clef, cette signature assurera le même niveau de sécurité pour votre nouvelle clef publique que toutes les signatures présentes sous l'ancienne.

    Il en va de même pour une nouvelle ID. Si l'ancienne a des signatures de confiance, votre propre signature sous la nouvelle ID assurrera le même niveau de sécurité. Cela servira en plus à introduire votre nouvelle ID. Il n'est pas nécessaire de redemander à vos amis-es de resigner.

    10. Comment signer mes IDs?

    Pour signer une de vos ID:

    pgp -ks VOTRE_ID -u [VOTRE_CLEF] [VOTRE_KEYRING]

    Cela ajoutera une signature créée avec la clef privée de VOTRE_CLEF à VOTRE_ID dans votre keyring correspondant. Si votre ID est votre clef (comme 0xABCD1234), la signature sera attribuée à votre ID par défaut. Si votre ID en est une parmi d'autres, vous signerez uniquement cette ID-ci. Si vous ne spécifiez pas VOTRE_KEYRING, PGP prendra pubring.pgp comme votre keyring public.

    Exemple: John Deuf signe son ID dans pubring.pgp

    pgp -ks "John Deuf" -u 0xABCD1234 Le résultat est comme suit:
    Type Bits/KeyID   Date        UserID
    pub 1024/ABCD1234 1996/01/01  John Deuf 
    sig      ABCD1234              John Deuf 
    
    La version internationale de PGP (2.6.3i) signe toutes les ID par défaut, ce que ne fait pas la version du MIT (PGP 2.6.2). L'option de signature peut être controllée par la déclaration AUTOSIGN=OFF/ON dans config.txt (9).

    11. Comment vérifier une ID?

    PGP ne détectera pas la forge d'une ID à moins que cette ID n'ait été signée par le possesseur lui-même ou quelqu'un d'autre. Seules les IDs signées peuvent être vérifiées. Avec l'option -kc, PGP essaira de décrypté le matériel haché emmagasiné dans la signature avec la clef publique du signataire. Cette clef est donc indispensable pour vérifier une signature. Si PGP ne la trouve pas dans le keyring, il affichera "Unknown Signature" et ne pourra vérifier la signature.

    Pour vérifier une ID et sa signature:

    pgp -kc [ID_A_VERIFIER][VOTRE_KEYRING]

    Si ID_A_VERIFIER n'est pas spécifié, PGP listera et vérifiera toutes les signatures de VOTRE_KEYRING. Si ID_A_VERIFIER est remplie, seules les signatures de cette ID particulière seront vérifiées. Vous pouriez aussi spécifier la clef à la place, comme : pgp-kc 0xABCD1234.

    Une vérification de la signature permet une vérification de l'ID, étant donné que des informations sur les caractères de l'ID ont été ajouté à la fonction de hachage quand la clef a été signée. Comparé le MD5 hash de la signature avec l'actuelle montrera la manipulation. Quand l'ID aura été manipuler, vous entendrez un petit bip et verrez un message s'afficher:

    pub  1024/ABCD1234 1996/01/01 John Deuf <john@network.net>
    sig*      ABCD1234             John Deuf <john@network.net>
                                   ****  BAD SIGNATURE! ****
    Remove bad signatures (Y/n)?
    

    PGP enlevera les fausses signatures à la demande, mais il ne peut distinguer entre fausse signature ou fausse ID. Donc prenez ce message sérieusement. Vous pouvez vouloir effacer une fausse signature de quelqu'un que vous ne connaissez pas de toute facon, mais cela ne résoudra pas le problème d'une mauvaise ID! Quand une vérification -kc montre une mauvaise ID, toute la signature n'est peut être pas mauvaise. Quelqu'un (surement le cracker lui-même) peut avoir signer une ID après l'avoir modifiée, ce qui créera une vrai signature pour une fausse ID.

    pgp -kvv n'assure pas une vérification. Les signatures seront seulement affichées. La même chose fonctionne pour le cryptage d'un message. Quand vous spécifierez une fausse ID pour crypter une clef publique, PGP ne vous préviendra pas.

    Quand vous ajoutez une clef à votre keyring public (pgp -ka), PGP lance automatiquement une vérification de la signature. Quand il vous annonce que la signature est fausse, enlevez la immédiatement. Vous pouvez aussi vérifier l'adresse E-mail du possesseur et l'avertir de ce qui se passe.

    12. Résumé.

    - Actuellement, les serveurs de clef jouent un rôle important en mettant les clefs à disposition de la communauté PGP. Mais ils ne protègent pas les clefs des pirates et des bouffons de l'internet. Cela changera avec la 2eme génération de serveurs.

    - La signature personnelle (comme toutes les signatures) des clefs est un moyen de rendre les attaques de Denial Of Service plus difficile et est particulièrement recommandée pour les clefs destinées à être soumises à une serveur de clef public. Pourtant, PGP ne peut pas empécher des attaques mais juste les détecter

    - Une signature personnelle n'est pas la panacée de la sécurité sur le Web. Cela ne vérifie pas l'identité du possesseur mais peut être utilisée pour les IDs des clefs et révéler au moins un type d'attaque de Denial Of Service.

    -Pour quelqu'un qui ne connait ni le possesseur de la clef ni les personnes qui ont signés sa clef, une signature personnelle est toujours mieux que toute signature de personne inconnue

    - Une signature sous une ID supplémentaire sert d'introduction à la nouvelle ID, si l'ancienne avait déjà des signatures à laquelle la confiance était accordé.

    13. Références.

    [NdT : comme indiqué en introduction, aucun des liens ci-dessous n'est encore valide. Pour toute information mise à jour, veuillez vous reporter aux sites OpenPGP en français, ou The PGP International Home Page. Nous laissons ces liens pour la beauté des archives ;]

    (1) pgp documentation
    by Phil Zimmerman
    http://www/ifi.uio.no/pgp/doc.html

    (2) alt.security.pgp:Frequently Asked Questions
    by Jeff Licquia, 21/05/1995
    http://www.prairienet.org/~jalicqui/pgpfaq.txt

    (3) Why should you sign your own pgp public key?
    by Francis Litterio
    http://world.std.com/~franl/pgp/why-sign-your-key.html

    (4) EFH PGP workshop
    by Paul Elliot, Electronic Frontiers Houston
    http://efh.org/pgp/pgpwork.html

    (5) The beginner's guide to pretty good privacy
    by Bill Morton, version 1.1, 13/04/1995
    http://netaccess.on.ca/~rbarclay/bq2pgp.txt

    (6) "Dead Beef" attack against PGP's key management
    posting to alt.security.pgp of 01/04/1996
    Raph Levien (raph@c2.org)

    (7) Known future developments in PGP servers and related subjects
    http://www.pgp.net/pgpnet/

    (8) Four11 Directory Services
    http://www.Four11.com/

    (9) Differences in International PGP Version by Stale Schumacher
    http://www.ifi.uio.no/pgp/diffs.shtml

    14. Remerciements (sans aucun ordre particulier).

    L'auteur aimerait remercier Michael Graff, Arnoud "Galactus" Engelfriet, Dave Tweten, Seth Golub, Jeffrey Schiller, Harald Fuchs, Gavan Schneider an d Nollaig MacKenzie, et d'autres sans qui il n'aurait jamais pu écrire tout cela.

    Last modified: 18 Jul 1997 (traduction : 28.01.2001)
    Author: Walter Soldierer (traduction : bertagaz@yahoo.fr)
    Comments: galactus@stack.nl (traduction : bigband@bugbrother.com)




    security section index.