Sommaire
- Faut-il changer les algorithmes préférés ?
- Clef primaire et sous-clefs
- Faut-il faire expirer les clefs ?
- Où et comment stocker ses clefs privées ?
- Quelles sont les autres données à protéger ?
- Clef privée compromise, quelles conséquences ?
Dans un commentaire de la dépêche sur la carte OpenPGP, Spack demandait :
OK mais je la mets où ma clef ? Sous l’oreiller ? Quels sont les bons conseils pour mettre sa clef privée au chaud et de façon pérenne ?
Ce à quoi je répondais, en bottant honteusement en touche, que ça n’avait rien à voir avec la carte OpenPGP. Mais la question n’en est pas moins intéressante et mérite que l’on tente d’y répondre.
Je me propose donc, dans ce journal, d’aborder pêle-mêle plusieurs questions tournant autour du thème central de la « bonne gestion de ses clefs OpenPGP ». Il pourrait s’agir du premier journal d’une série plus large consacrée à OpenPGP et GnuPG, si les lecteurs se montrent intéressés.
Comme le fait remarquer la FAQ de GnuPG, il n’y a pas beaucoup de « bonnes pratiques » liées à OpenPGP qui fassent réellement consensus. Sauf mention contraire, les pratiques que j’évoquerai dans ce journal ne seront en fait rien d’autres que mes pratiques, avec tout ce que ça implique concernant leur valeur et leur pertinence (étant entendu, au cas où quelqu’un en douterait, que je ne suis ni cryptographe ni expert en sécurité informatique). Les commentaires pourront bien sûr servir à discuter du bien-fondé des pratiques en questions.
Faut-il changer les algorithmes préférés ?
Chaque certificat OpenPGP contient, entre autres choses, une sélection d’algorithmes préférés permettant au titulaire du certificat d’annoncer les algorithmes à utiliser pour communiquer avec lui. Plusieurs documents sur Internet suggèrent que la sélection par défaut de GnuPG est bancale et doit être corrigée par l’utilisateur. Par exemple, une critique qui revient souvent est que l’algorithme de condensation préféré par défaut serait SHA-1.
Ce n’est plus vrai depuis… GnuPG 2.0.13, il y a bientôt six ans.
En fait, si on regarde les préférences par défaut sur une clef fraîchement générée :
$ gpg2 --edit-key alice
[…]
gpg> showpref
[ultimate] (1). Alice <alice@example.org>
Cipher: AES256, AES192, AES, 3DES
Digest: SHA256, SHA384, SHA512, SHA224, SHA1
Compression: ZLIB, BZIP2, ZIP, Uncompressed
Features: MDC, Keyserver no-modifyon constate que ces préférences sont plutôt « saines » et ne nécessitent pas, à mon avis, que l’on recommande systématiquement aux utilisateurs de les changer (pour chipoter, je ferais bien passer AES128 avant AES256 et AES192, mais c’est un détail). La présence de 3DES et SHA1 peut surprendre (à quoi bon les utiliser si AES et la famille SHA2 sont disponibles ?), mais ces algorithmes sont les seuls imposés par le standard OpenPGP1 et ils garantissent l’interopérabilité avec d’autres implémentations du standard (pas la peine d’essayer de les supprimer de la liste des préférences, GnuPG les rajoutera implicitement).
Donc, à moins que vous n’ayez des opinions bien arrêtées sur ce que valent les différents algorithmes cryptographiques, faites confiance à la sélection par défaut de GnuPG.
Détail amusant, même Bruce Schneier n’a pas jugé utile de changer les préférences par défaut de GnuPG pour sa clef, même pas pour y insérer ses propres algorithmes Blowfish (qui fut en compétition avec Rijndael pour devenir AES) ou Twofish.
Attention néanmoins, si vous avez générée votre clef il y a longtemps, sa sélection d’algorithmes préférés est peut-être effectivement dépassée. Pour la mettre automatiquement à jour, utilisez la commande setpref sans arguments dans l’éditeur de clef de GnuPG.
Clef primaire et sous-clefs
Lors de la création d’une nouvelle clef, le comportement par défaut de GnuPG est de créer en réalité deux clefs : une clef primaire de certification et de signature, et une sous-clef de chiffrement.
L’utilisation de sous-clefs se justifie d’abord pour une simple raison technique : à l’exception notable du très flexible RSA, la plupart des algorithmes à clef publiques utilisés par OpenPGP permettent soit de signer (comme DSA ou ECDSA) soit de chiffrer (comme ElGamal ou ECDH), mais ils ne permettent pas de faire les deux. Cela impose donc d’utiliser des clefs distinctes pour les opérations de signature/certification et de chiffrement.
Mais un autre avantage des sous-clefs est qu’elles peuvent être remplacées à tout moment indépendamment de la clef primaire dont elles dépendent.
La clef primaire est la clef qui est associée à vos identités, c’est celle que tout le monde connaît et surtout c’est celle que tout le monde signe. Révoquer cette clef et la remplacer par une autre revient à perdre toutes les signatures péniblement accumulées au fil du temps, et à disparaître virtuellement de la toile de confiance. Il faut alors faire signer sa nouvelle clef pour se ré-introduire dans la toile ; comme cela implique généralement de sortir de chez soi (Brrr) et de voir du monde (Argh), c’est quelque chose que l’on souhaite naturellement avoir à faire le moins souvent possible.
À l’inverse, une sous-clef peut être révoquée et remplacée à tout moment, cela n’affecte aucunement la validité et la réputation de la clef primaire, et c’est en plus transparent pour les utilisateurs qui de toute façon ne manipulent jamais directement les sous-clefs : si votre interlocuteur veut vous envoyer un message chiffré, il n’a besoin que de sélectionner votre clef primaire, c’est son implémentation d’OpenPGP qui se chargera de trouver la sous-clef de chiffrement.
En bref, le principe des sous-clefs permet de dissocier la clef qui établit votre identité et vous représente au sein de la toile de confiance, des clefs que vous utilisez concrètement.
Donc, ne vous contentez pas de la sous-clef de chiffrement générée par défaut par GnuPG, et générez en plus une seconde sous-clef pour les opérations de signature. Utilisez la clef primaire exclusivement pour signer des clefs.
Sous-clefs de compatibilité
Il n’y a, en principe, pas de raison d’avoir plus d’une sous-clef de chiffrement et une sous-clef de signature.
Une raison plausible et intéressante, toutefois, est d’assurer une certaine compatibilité avec des implémentations plus anciennes d’OpenPGP.
Imaginons la situation suivante : Alice utilise GnuPG 2.1, et elle aimerait pouvoir utiliser les algorithmes à base de courbes elliptiques (ECC, Elliptic Curve Cryptography) que ce dernier prend en charge. Malheureusement, si Bob utilise aussi GnuPG 2.1, Charlie, lui, utilise encore GnuPG 2.0, qui ne connaît pas les courbes elliptiques. Si Alice génère des clefs ECC, elle se coupe de Charlie ; si elle génère des clefs RSA, elle ne se coupe de personne, mais personne ne profite de l’introduction d’ECC dans GnuPG — du coup, pas grand’monde n’est motivé pour passer à GnuPG 2.1, ce qui freine d’autant plus le déploiement des clefs ECC dont tout le monde dit pourtant qu’elles sont l’avenir parce que RSA, c’est has-been.2
Les sous-clefs offrent une solution possible à ce blocage. Si Alice a une clef primaire RSA, elle peut avoir une sous-clef de chiffrement RSA et une sous-clef de chiffrement ECDH. Quand Charlie voudra chiffrer un message à destination d’Alice, son GnuPG 2.0 sélectionnera automatiquement la sous-clef RSA en ignorant la sous-clef ECDH qu’il ne sait pas utiliser. Le GnuPG 2.1 de Bob, en revanche, pourra utiliser la sous-clef ECDH (petite subtilité : il faudra que la sous-clef ECDH ait été générée après la sous-clef RSA, puisque GnuPG sélectionne automatiquement la sous-clef la plus récente lorsqu’il en trouve plusieurs utilisables). Ainsi, Alice ne se coupe de personne, et peut utiliser les algorithmes les plus récents avec ceux qui les acceptent.
Cette solution est aussi applicable aux opérations de signature. Dans ce cas, comme le signataire ne sait pas forcément qui vérifiera la signature, la compatibilité maximale peut être assurée en signant systématiquement à la fois avec une sous-clef RSA ou DSA et avec une sous-clef ECDSA.
À terme, lorsque GnuPG 2.1 (ou d’autres implémentations d’OpenPGP prenant en charge les courbes elliptiques, comme Google End-to-end) sera suffisamment répandu, les sous-clefs RSA pourront éventuellement être révoquées.
Disclaimer : J’ai expérimenté cette notion de « sous-clefs de compatibilité » à l’occasion de l’écriture de ce journal, mais je ne l’utilise pas en pratique. Je n’ai pas de clefs ECC, donc le problème de compatibilité avec GnuPG 1.4 et 2.0 ne se pose pas à moi.
Faut-il faire expirer les clefs ?
Par défaut, les nouvelles clefs OpenPGP créées par GnuPG 2.1 n’ont pas de date d’expiration et sont donc valides ad vitam aeternam jusqu’à ce qu’elles soient éventuellement révoquées. Est-ce une bonne idée ? Faudrait-il spécifier une date d’expiration, et le cas échéant, quelle devrait être la durée initiale de validité ?
Je n’ai pas de réponse absolue à ces questions, mais il faut noter deux choses pour commencer. D’une part, GnuPG est assez psychorigide vis-à-vis de l’expiration et refusera catégoriquement de vous laisser utiliser une clef expirée (ce comportement est non-débrayable, ce qui est sujet à débat dans la communauté). D’autre part, la date d’expiration n’est pas gravée dans le marbre : tant que vous avez accès à la clef primaire privée, vous pouvez à tout moment changer la date d’expiration à votre guise (y compris ajouter une date d’expiration à une clef qui était initialement éternellement valide, ou inversement repousser la date d’expiration initiale aux calendes grecques). Cela se fait en re-signant votre propre clef.
Cela étant dit, quel est l’intérêt de faire expirer une clef ?
Sur une clef primaire, qui ne peut être révoquée que par la clef privée correspondante,3 l’intérêt se manifeste dans le cas où vous perdez d’une façon ou d’une autre l’usage de votre clef privée, et que n’avez pas (ou plus) sous la main le certificat de révocation qui avait été généré en même temps (par exemple, une défaillance de votre disque dur vous fait perdre tout votre répertoire ~/.gnupg, et quant à vos sauvegardes… « euh, quelles sauvegardes ? »). L’expiration permettra dans ce cas d’éviter de laisser en circulation une clef éternellement valide mais en pratique inutilisable.
Notez que l’expiration n’a aucun intérêt en cas de vol de votre clef privée, puisque votre attaquant n’aura qu’à utiliser la clef volée pour re-signer votre clef publique et repousser la date d’expiration.
Sur une sous-clef, l’intérêt est à mon sens plus réduit. Si vous perdez l’usage d’une sous-clef, vous pourrez toujours révoquer la clef publique correspondante (et donc signaler à vos interlocuteurs de ne plus l’utiliser) avec votre clef primaire. En fait, même si vous ne révoquez pas la clef inutilisable, le simple fait de générer une nouvelle sous-clef devrait suffire pour que vos interlocuteurs cessent d’utiliser l’ancienne, puisqu’en présence de plusieurs sous-clefs GnuPG utilisera systématiquement la plus récente. Faire expirer ou révoquer les anciennes clefs permet juste d’exprimer explicitement votre volonté de ne plus voir ces clefs utilisées.
Je suggérerai personnellement (sans aller néanmoins jusqu’à prétendre que c’est une bonne pratique) de faire expirer votre clef primaire tous les deux ou trois. Ça vous oblige à la re-signer périodiquement, ce qui d’une part vous donne l’occasion de vérifier qu’elle est bien à jour (par exemple, elle ne contient pas une identité que vous n’utilisez plus depuis des années, et que vous aviez complètement oublié), et d’autre part ré-affirme auprès des autres utilisateurs que cette clef est toujours d’actualité et que vous continuez à vous en servir.
Où et comment stocker ses clefs privées ?
À part les attaques cryptanalytiques, le principal risque auquel sont exposées les clefs privées est celui de l’exfiltration, où un attaquant obtient une copie de vos clefs privées. Le stockage des clefs doit tenir compte de ce risque.
GnuPG stocke les clefs privées dans le dossier ~/.gnupg/private-keys-v1.d, à raison d’un fichier par clef, ou dans le fichier ~/.gnupg/secring.gpg (GnuPG 1.4/2.0). La restriction de l’accès à ces fichiers est du ressort du système d’exploitation, GnuPG n’a pas grand’chose à voir là-dedans — tout ce qu’il fait, lors de la première utilisation, est de s’assurer que le dossier $GNUPGHOME a les permissions appropriées, soit 0700.
Les clefs sont chiffrées par une clef AES de 128 bits dérivée de votre phrase de passe par n itérations d’une fonction de condensation, n étant déterminée empiriquement pour que la dérivation prenne environ 100 millisecondes — ceci afin de rendre la recherche exhaustive de la phrase de passe trop coûteuse. Par ailleurs, une clef n’est déchiffrée que juste avant d’être utilisée, et la clef déchiffrée est supprimée de la mémoire immédiatement après utilisation.
Un attaquant souhaitant s’emparer de vos clefs a donc deux obstacles à surmonter : il doit accéder aux fichiers contenant les clefs (par effraction physique ou, plus probablement, par piratage informatique), et déchiffrer celles-ci (soit en cassant la clef AES, soit en trouvant la phrase de passe).
Toutefois, dans un scénario où l’attaquant a infiltré votre machine pour exfiltrer les fichiers contenant les clefs privées, il n’est pas difficile d’imaginer qu’il a aussi installé un keylogger pour récupérer en même temps votre phrase de passe.
L’exposition de vos clefs à ce dernier scénario peut être réduite en les stockant hors-ligne, au lieu de les laisser sur votre machine.
Stockage hors-ligne de la clef primaire
Si vous avez une sous-clef de chiffrement et une sous-clef de signature comme recommandée plus haut, vous n’avez plus besoin de la clef primaire que pour modifier votre propre clef (ajouter/révoquer une identité ou une sous-clef, changer les préférences) et signer les clefs d’autres utilisateurs. Du coup, vous ne perdrez pas grand’chose en confort d’utilisation à conserver la clef primaire privée exclusivement hors ligne, hors de portée de toute attaque informatique.
Si la procédure pour cela était relativement « tordue » avec GnuPG 1.4/2.0 (il n’était pas possible de supprimer uniquement la clef primaire du trousseau privée, de sorte qu’il fallait, en gros : ① exporter les sous-clefs uniquement, ② supprimer la clef primaire, ce qui supprimait aussi les sous-clefs rattachées, puis ③ ré-importer uniquement les sous-clefs — et encore je ne parle pas de la procédure à suivre pour utiliser la clef hors-ligne…), c’est devenu beaucoup plus simple avec GnuPG 2.1.
Trouvez le keygrip de votre clef primaire :
$ gpg2 --with-keygrip -K
/home/alice/.gnupg/pubring.kbx
------------------------------
sec rsa4096/5B491A54 2014-12-31 [SC] [expires: 2017-12-30]
Keygrip = D4DF0C35D3E22FA6AC37DA2E54FB03F73616A3CB
uid [ultimate] Alice <alice@example.org>
[…]La clef privée 5B491A54 se trouve dans le fichier ~/.gnupg/private-keys-v1.d/D4DF0C35D3E22FA6AC37DA2E54FB03F73616A3CB.key. Sortez simplement ce fichier de son répertoire et stockez-le sur le support de votre choix. Quand vous avez besoin d’utiliser la clef primaire, remettez temporairement le fichier en place. C’est tout.
Le « support de votre choix » peut être une clef USB, une carte SD, une disquette, un CD-R…
Où conserver le support ? Là où on ne vous le volera pas, mais aussi et surtout là où vous ne le perdrez pas (égarer le support est un risque probablement plus grand que le risque de vol, à mon avis). Donc, pas caché quelque part dans un coin improbable (sous l’oreiller, dans une brique creuse de la cheminée ou sous une latte de parquet), mais plutôt proprement rangé dans un tiroir, en fait au même endroit que là où vous rangez déjà vos papiers et autres trucs importants.
(La FSF Europe recommande une grotte gardée par des orques, ce qui est certainement efficace, mais si vous n’avez pas ni grottes ni orques dans votre région, un coffre-fort gardé par des banquiers peut aussi faire l’affaire.)
Une option intéressante est d’utiliser une méthode de secret réparti pour partager la clef privée en n fragments, dont m sont nécessaires pour reconstituer la clef complète. La clef peut ainsi répartie sur plusieurs supports sans que la perte de l’un d’entre eux ne fasse perdre toute la clef, et sans que le vol de l’un d’entre eux ne compromette toute la clef non plus.
Chez moi, j’utilise libgfshare, une implémentation de la méthode de secret réparti d’Adi Shamir, pour mettre en œuvre cette dernière option.
Stockage hors-ligne des sous-clefs
En principe, les sous-clefs peuvent être gardées hors-ligne de la même façon que la clef primaire. Toutefois, les sous-clefs sont utilisées beaucoup plus fréquemment que la clef primaire et devoir ressortir le support et rapatrier les clefs dans le dossier ~/.gnupg/private-keys-v1.d pour chaque opération de signature ou de chiffrement deviendrait rapidement pénible.
Si vous tenez à garder les sous-clefs hors-ligne, la meilleure solution est de les stocker sur un token à partir duquel elles peuvent être directement utilisées sans devoir les rapatrier sur l’ordinateur. C’est ce que permet la carte OpenPGP, sur laquelle je ne m’étendrai pas ici puisque j’en ai déjà largement parlé dans ma dépêche de décembre dernier.
Les sauvegardes
Une question voisine du stockage des clefs privées est celle de leur sauvegarde. Avoir (au moins) une copie de sauvegarde de vos clefs privées est crucial : plein de choses imprévues peuvent arriver à vos clefs ou au disque dur sur lequel elles se trouvent.4 En fait, la perte accidentelle est probablement plus probable qu’une compromission par un attaquant…
Il est préférable de ne pas sauvegarder les clefs privées au même endroit que le reste de vos données, à moins que vous ne stockiez toutes vos sauvegardes sur des supports eux-mêmes chiffrés et/ou auxquels vous seul avez accès. (Si votre support de sauvegarde est chiffré, attention au problème d’œuf et de poule : ne sauvegardez pas la clef permettant d’ouvrir le support de sauvegarde sur ce même support !)
Outre les copies de sauvegardes classiques, je recommande également une sauvegarde au format papier. L’outil paperkey exporte les informations essentielles de votre trousseau privé dans un format aisément imprimable sur une bonne vieille feuille de papier, dont la capacité de rétention d’informations sur de longues périodes n’est plus à démontrer. Conservez ensuite cette feuille avec le reste de vos documents importants.
Quelles sont les autres données à protéger ?
À part les clefs privées, quels sont les autres fichiers sensibles ?
Le(s) certificat(s) de révocation. Quiconque s’en empare peut inconditionnellement révoquer votre clef (par exemple pour tenter de faire accepter ensuite une fausse clef à vos correspondants, avant que nous n’ayez eu le temps d’en générer une nouvelle de votre côté). Il est souvent recommandé de le stocker hors-ligne, au même endroit que là où vous mettez votre clef primaire.
L’état du pool d’entropie (stocké dans ~/.gnupg/random_seed). La connaissance de cet état pourrait permettre à un attaquant de déduire les prochaines clefs de session. En cas de doute, il vaut mieux supprimer purement et simplement ce fichier, GnuPG reconstituera un pool avec de l’entropie en provenance du système.
La base de confiance (stockée dans /.gnupg/trustdb.gpg). Modérément sensible. La fuite de cette base peut permettre de tisser un graphe plus précis de vos relations : savoir que vous avez signé la clef d’Alice (ce que tout le monde peut savoir en regardant sa clef publique) dit seulement que vous connaissez Alice, mais savoir que vous lui faites complètement confiance témoigne que vous le connaissez bien (ou que vous prenez la gestion de votre toile de confiance à la légère). Cette base de confiance peut toujours être reconstituée manuellement si besoin (mais c’est fastidieux si votre trousseau public est bien rempli).
Clef privée compromise, quelles conséquences ?
Il n’est pas inutile, je pense, de passer rapidement en revue les conséquences d’une compromission d’une clef privée. Admettons donc, pour les besoins du raisonnement, que Mallory a d’une façon ou d’une autre mis la main sur une des clefs privées d’Alice, à son insu. Que peut-il en faire ?
Sous-clef de chiffrement compromise
C’est probablement le pire cas de figure pour la confidentialité des communications. Mallory peut déchiffrer tous les messages à l’intention d’Alice, le risque de détection pour lui est quasiment nul : tout ce qu’il a à faire est d’intercepter les messages destinés à Alice tout en les laissant arriver intact jusqu’à elle. Seule une erreur de Mallory, comme une exploitation imprudente des renseignements qu’il obtient de cette manière, pourra conduire Alice à soupçonner que ses messages sont lus.
Sous-clef de signature compromise
Mallory peut signer des messages au nom d’Alice. C’est potentiellement dommageable (imaginons par exemple qu’Alice signe les releases de son logiciel libre : Mallory peut faire accepter à Bob une version proprement troué par ses soins), mais avec un risque de détection assez élevé. Mallory doit absolument éviter que les fausses signatures ne parviennent jusqu’à Alice, faute de quoi celle-ci réalisera immédiatement que quelque chose ne va pas. C’est néanmoins envisageable si Mallory a un contrôle suffisant du réseau (et en cryptographie, on suppose toujours que l’attaquant contrôle totalement le réseau).
Clef primaire compromise
Il est un peu plus difficile d’appréhender ce que peut faire un attaquant ayant mis la main sur la clef primaire. Avant tout, il faut noter que Mallory ne peut pas s’en servir pour obtenir les sous-clefs privées : il n’y a aucun lien mathématique entre une clef primaire et une sous-clef et la connaissance de la clef primaire ne permet pas de tirer la moindre information sur les sous-clefs. Partant, Mallory ne peut pas déchiffrer en l’état les communications d’Alice.
En revanche, Mallory peut
Signer des messages au nom d’Alice. Même si Alice a une sous-clef de signature, la clef primaire reste utilisable pour signer.
Signer des clefs au nom d’Alice. À la différence de la sous-clef de signature, la clef primaire peut signer non seulement des messages mais aussi les clefs d’autres utilisateurs. Mallory peut ainsi faire accepter de fausses clefs à ceux qui font confiance en la signature d’Alice.
Jouer à l’homme du milieu. Mallory génère une nouvelle sous-clef de chiffrement et publie une nouvelle version de la clef publique d’Alice avec cette sous-clef rattachée. Les correspondants d’Alice récupèrent cette sous-clef en rafraîchissant leur trousseau public (contrairement à une attaque MITM « classique », Mallory n’a ici aucune difficulté à faire accepter sa sous-clef de chiffrement, puisqu’elle est attachée à la vraie clef publique d’Alice que ses correspondants connaissent), et se mettent à chiffrer leurs messages destinés à Alice avec la sous-clef créée par Mallory. Celui-ci intercepte les messages, les déchiffre, les re-chiffre avec la sous-clef de chiffrement originale d’Alice, et les fait suivre à Alice.
Toutes ces actions ont en commun de présenter un risque de détection élevé. C’est particulièrement vrai pour la dernière, où Mallory doit s’assurer non seulement que sa nouvelle sous-clef de chiffrement n’est vue que par les correspondants d’Alice et surtout pas par Alice elle-même, mais aussi qu’il intercepte bien tous les messages destinés à Alice — si celle-ci voit arriver ne serait-ce qu’un seul message à son intention mais chiffré avec une sous-clef qu’elle ne connaît pas, elle réalisera immédiatement l’interférence.
Modifier les préférences de la clef publique. Plus sournoisement, Mallory peut publier une nouvelle version de la clef publique d’Alice dans laquelle il a altéré la sélection d’algorithmes préférés, afin de mettre en tête (ou uniquement) un algorithme plus « facile » à casser (3DES par exemple). Contrairement à ce qui précède, cette attaque, même si elle est détectable, peut tout de même facilement inaperçue. Elle suppose néanmoins que Mallory soit capable de casser au moins un des algorithmes symétriques utilisés par OpenPGP, ce qui n’est pas gagné (même 3DES, a priori le plus faible des algorithmes disponibles, résiste encore très bien aux attaques cryptanalytiques).
-
La première version du standard, en 1998, demandait que MD5 soit aussi pris en charge aux côtés de SHA1, mais la version suivante en 2007 a déclaré cet algorithme obsolète. SHA1 pourrait subir le même sort si une troisième version devait voir le jour. ↩
-
Pour ce que ça vaut, je ne partage absolument pas cette opinion. Je suis même plutôt sceptique vis-à-vis des algorithmes ECC et surtout des courbes dont les paramètres ont été choisis sur des critères non-spécifiés. ↩
-
C’est un petit mensonge : il est en réalité possible de désigner des « révocateurs », des tiers de confiance que vous autoriser à révoquer votre clef à votre place dans l’éventualité où vous perdriez l’usage de votre clef primaire privée. ↩
-
Dernier exemple en date, chez moi : un synthétiseur de quinze kilos qui tombe sur un ordinateur portable de un kilo et demi, le disque dur du portable n’a pas survécu — j’avais pensé à plein d’incidents pouvant arriver à mes données, mais ça je dois avouer que je ne l’avais pas vu venir… ’foiré de chat ! ↩
# Merci :-)
Posté par orel . Évalué à 6.
Merci pour ce journal, j'ai justement une clé pgp à créer et il n'est pas facile de trouver une info claire et pas trop datée sur les internets.
Concernant les bonnes pratiques j'étais tombé sur le site de riseup.net, qui fournit un fichier de config, qui est celui utilisé dans tails.
Pour ce qui concerne la gestion des sous-clés il y a bien le wiki debian, mais ce que j'avais de plus complet est ce blog, par contre, je n'avais rien vu sur ta procédure très simple d'extraction d'une clé primaire. Donc encore merci :-)
[^] # Re: Merci :-)
Posté par Ellendhel (site web personnel) . Évalué à 4.
Un autre article sur la création d'une clé et de sous-clés, avec des choix personnels sur certains points (tels que l'expiration), est disponible sur le blog de S. Bortzmeyer.
[^] # Re: Merci :-)
Posté par gouttegd . Évalué à 5.
Tout-à-fait, c’est une des raisons qui m’ont poussé à écrire ce journal (et à écrire la dépêche de décembre dernier).
Aucun des documents actuellement disponibles que j’ai trouvé ne parle de GnuPG 2.1. Bon, ça peut se comprendre, ce dernier est n’est sorti en version stable qu’à l’automne 2014. Mais ce qui est moins compréhensible, c’est que la plupart de ces documents ne parlent en fait même pas de GnuPG 2.0, mais exclusivement de GnuPG 1.4.
C’est très dommage, parce que GnuPG 2.0 rendait déjà plusieurs de ces documents obsolètes même au moment où ils ont été écrits.
# Merci
Posté par ®om (site web personnel) . Évalué à 5. Dernière modification le 17 mai 2015 à 23:12.
Merci pour le journal, très intéressant.
Il y a aussi l'outil
ssssen ligne de commande (packagé dans Debian). Malheureusement, il ne permet que de gérer 1024 bits, ce qui est insuffisant (souvent de peu) pour stocker une clé privée.man ssss:Merci pour
paperkey, je ne connaissais pas, minimiser le nombre d'octets nécessaires à la clé peut être bien pratique. Juste un questionnement néanmoins sur le fait de l'imprimer : les imprimantes sont-elles dignes de confiance? Les logiciels qui tournent dedans sont le plus souvent non-libres et opaques, et elles ont parfois un accès Wifi. À l'ère post-Snowden, il ne me paraît pas improbable qu'elles puissent leaker des informations dans le cadre d'une surveillance massive (et pas seulement ciblée).blog.rom1v.com
[^] # Re: Merci
Posté par gouttegd . Évalué à 5.
Hum, dans le cas où le secret est une clef privée OpenPGP, c’est superflu : la clef est déjà chiffrée par GnuPG. Plutôt que de rajouter une couche de chiffrement et de partager la clef qui chiffre la clef, il vaudrait mieux utiliser une phrase de passe longue et complètement aléatoire, que l’on partagera ensuite avec ssss.
Aucune idée, mais parmi ce qui me vient à l’esprit :
Même sous sa forme exportée par paperkey, la clef reste protégée par la phrase de passe (elle est toujours chiffrée) — donc on n’envoie pas la clef « à poil » vers l’imprimante.
Peu de risque a priori si l’imprimante est directement connectée à l’ordinateur, par USB ou câble parallèle.
Si c’est une imprimante réseau, personnellement je me méfierais davantage de ce qui peut se passer entre ma machine et l’imprimante, que de l’imprimante proprement dit. Je ne connais pas très bien les protocoles d’impression (je ne les connais pas du tout en fait), mais je ne serais pas surpris qu’ils fassent tout circuler en clair.
On peut envisager de configurer le pare-feu local pour bloquer tous les paquets en provenance de l’imprimante et à destination de l’extérieur. En fait ça me semblerait une bonne chose à faire de toute façon, même si on n’envisage pas d’imprimer des clefs OpenPGP.
[^] # Re: Merci
Posté par feth . Évalué à 4.
Les imprimantes un peu évoluées stockent les documents imprimés, il n'y a plus qu'à venir se servir.
# Dépêche ?
Posté par Professeur Méphisto . Évalué à 5.
Très intéressant, merci. Ça vaut peut-être le coup de pousser le journal dans les dépêches, non ?
# Unité de mesure
Posté par Professeur Méphisto . Évalué à 10.
deux ou trois siècles, nanosecondes ou kilogrammes ? ;-)
[^] # Re: Unité de mesure
Posté par gouttegd . Évalué à 4.
Je voulais bien sûr dire « toutes les deux ou trois versions majeures du noyau Linux » — sur linuxfr.org, ça me semblait évident, voyons. :-°
Blague à part, il faut lire « tous les deux ou trois ans ans » (mais notez la proposition alternative de jben un peu plus bas, qui parle de deux ou trois mois sur les sous-clefs).
# Sous-clef de chiffrement
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Si le pire est la perte de la Sous-clef de chiffrement, il faudrait la protéger au moins autant que la clef primaire non ?
Ou alors, il faudrait une clef de signature de plus, gérer par un token, sans que cette clef n'y sortent jamais (je pars du principe que chiffrer dans un token est trop lent).
Ou alors, il faut révoquer périodiquement cette sous clef.
"La première sécurité est la liberté"
[^] # Re: Sous-clef de chiffrement
Posté par gouttegd . Évalué à 4.
Je chipote, mais le pire n’est pas la perte : si tu perds ta sous-clef de chiffrement, tu sais que tu dois la considérer comme compromise, tu la révoques et tu en génères une autre. Dans le pire des cas, seules tes communications passées (jusqu’au moment où tu réalises la perte) sont potentiellement compromises.
Le pire, c’est une exfiltration réalisée de telle sorte que tu ne t’aperçois de rien, parce que tes correspondants vont alors continuer à t’envoyer des messages chiffrés avec cette clef, que ton attaquant pourra lire tranquillement. Tes communications passées et futures sont compromises.
Cela étant, oui, la sous-clef de chiffrement est à protéger avec soin, autant sinon plus que la clef primaire. C’est tout l’intérêt de la mettre sur un token comme la carte OpenPGP.
Ce n’est pas le cas.
D’une part, le token ne chiffre jamais, il ne fait que déchiffrer — le chiffrement ne requiert que la clef publique de ton correspondant, aucune raison de mettre celle-ci sur un token. Mais je chipote encore (désolé), il est évident que tu parlais de déchiffrer.
D’autre part, on ne déchiffre avec la clef privée rien de plus que la clef de session symétrique avec laquelle on peut ensuite déchiffrer le corps du message. La complexité de l’opération RSA fait que déchiffrer la clef de session est déjà, la plupart du temps, la partie la plus lente (même si le corps du message est beaucoup plus gros que la clef de session, AES est beaucoup plus rapide à déchiffrer, d’autant plus que beaucoup de processeurs ont des instructions AES spécifiques), faire effectuer cette opération par un token ne la ralentit pas beaucoup plus.
C’est une possibilité en effet. Je n’irai pas jusqu’à le recommander, mais c’est une option à considérer en fonction des opposants auxquels on pense faire face.
[^] # Re: Sous-clef de chiffrement
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Concernant le token, est-ce que vous avez tenu compte que cela peut être plus ou moins facile de récupérer les secrets d'une carte à puce ? (cf les cartes à puce de décodeurs satellites)
Une carte à puce est un ordinateur très simple dont on peut observer le fonctionnement. Et je ne parle pas des bêtes failles de débordement de buffer qui peuvent permettre de lire complètement la mémoire et donc la clef privée.
"La première sécurité est la liberté"
[^] # Re: Sous-clef de chiffrement
Posté par gouttegd . Évalué à 5.
Je suis d’accord qu’une carte à puce n’est pas plus infaillible que n’importe quel autre système du même genre. On a déjà réussi à extraire des clefs stockées dans des HSM beaucoup plus chers que des cartes à puces, il est prudent de supposer que les différentes implémentations de la carte OpenPGP ne résisteraient probablement pas davantage face à un attaquant déterminé.
Mais attaquer physiquement une carte à puce suppose de l’avoir à sa disposition. Donc de la soustraire à son propriétaire, qui devrait logiquement s’en apercevoir — et considérer les clefs comme compromises, et donc les révoquer.
La carte à puce n’est pas un outil magique qui va mettre les clefs à l’abri de toutes les menaces (si c’est l’impression qui se dégage de ma dépêche, j’en suis désolé — une section sur les risques spécifiques à la carte à puce, et les risques contre lesquels elle ne protège pas, aurait sans doute été bienvenue). Son rôle premier est de soustraire les clefs aux menaces qui pèsent sur elles tant qu’elles sont sur le disque dur d’un ordinateur vraisembablement connecté à Internet (menaces probablement à la fois plus nombreuses et plus crédibles qu’une attaque matérielle).
[^] # Re: Sous-clef de chiffrement
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
C'est vrai :)
J'imagine que le plus dure est de gérer l'accès à la carte quand elle est connecté sur un ordinateur. Mais c'est censé être rare.
Le plus simple pour qu'une carte résiste est que son contenu soit relativement unique. En général, il faut plusieurs carte pour briser leur sécurité, ce qui n'est pas le cas avec une clef privé par carte.
"La première sécurité est la liberté"
[^] # Re: Sous-clef de chiffrement
Posté par gorbal . Évalué à 2.
Je n'ai jamais vu d'informations concernant l'extraction des clefs secrètes d'une carte à puce. D'ailleurs Moreno avait de son vivant lancé un concours qui n'a jamais été relevé.
Si c'était faisable, ce n'est pas les cartes satellites qui seraient les premières victimes mais nos cartes bancaires qui contiennent des clefs secrètes utilisées pour authentifier toutes nos transactions effectuées en utilisant la puce.
En général les failles se trouvent dans la faiblesses de clefs utilisées ou dans le protocole d'authentification, mais ceci n'a pas n'a pas pour origine les fait de stocker les clefs dans une carte.
```
[^] # Re: Sous-clef de chiffrement
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Canal+ a été piraté de cette façon, il y a plus de 10 ans.
cf :
http://www.murdochspirates.com/Pirates/Medias/MACOS_9.2.2_Desktop_Folder_Telesatellite_code.pdf
Ils ont récupérés la manière de générer les clefs.
Suite à cette affaire, Canal+ a monté un laboratoire de teste avant de distribuer une nouvelle carte(ck2).
"La première sécurité est la liberté"
[^] # Re: Sous-clef de chiffrement
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Les techniques : http://www.cl.cam.ac.uk/~mgk25/sc99-tamper.pdf
"La première sécurité est la liberté"
# Utilité des sous-clés
Posté par eingousef . Évalué à 2. Dernière modification le 18 mai 2015 à 11:41.
Avec les usages actuels, très limités, de la toile de confiance OpenPGP, c'est peut-être le cas, mais les usages peuvent évoluer. Déterminer si on peut faire confiance à quelqu'un, ça peut servir à beaucoup de choses !
Les développeurs d'OpenUDC proposent un standard permettant d'ajouter à une clé un champ qui permet de définir plus finement pour quoi sera utilisée la clé : chiffrer des messages, signer des messages, authentifier des sites web, signer des commits, recevoir et envoyer de l'argent, prouver son existence en tant que personne physique (et éventuellement pouvoir recevoir un dividende universel). Par exemple Alice vient aux key signing parties, dans son trousseau de clés elle va mettre une clé qu'elle va utiliser pour recevoir un dividende, alors que Bob (qui n'est que le pseudo d'Alice dans les tréfonds anonymes de dissidents politiques d'anarcho-gauchistes des Internetz) pourrait être reconnu comme digne de confiance pour échanger des messages, ou recevoir de l'argent sous forme de dons par exemple, mais pas pour recevoir un dividende comme une personne physique. Alors on peut être pour ou contre le dividende universel, spa la question, c'est juste pour dire que l'usage qu'on a de GPG actuellement n'est pas gravé dans le marbre et qu'on peut (qu'on va, sûrement, en fait) développer des usages qui font qui rendront peut-être nécessaire la possession de beaucoup de sous-clés sous une même clé primaire.
Je sais qu'ils voulaient proposer le standard en tant que RFC mais je sais pas où ça en est.
*splash!*
[^] # Re: Utilité des sous-clés
Posté par gouttegd . Évalué à 2.
Je ne suis pas sûr qu’utiliser des sous-clefs soit pertinent dans le cas que tu présentes, ou alors je ne comprends pas très bien l’objectif.
Est-ce que les interlocuteurs d’Alice (ceux qui vont utiliser la sous-clef destinée à recevoir des dividendes) sont supposés ne pas savoir que la même personne, sous le nom de Bob, reçoit des dons ? Je ne vois pas comment faire ça avec des sous-clefs : quiconque obtient le certificat d’Alice connaîtra toutes les identités et toutes les sous-clefs associées.
J’ai l’impression que ce tu cherches nécessiterait plutôt plusieurs clefs primaires complètement indépendantes.
[^] # Re: Utilité des sous-clés
Posté par eingousef . Évalué à 2.
Ce que je veux dire c'est que Alice a une clé primaire avec plusieurs sous-clés : celle qu'elle utilise pour signer ses messages, celle qu'elle utilise pour signer ses commits, celle qu'elle utilise pour son site web, celle qu'elle utilise pour recevoir des dons et celle qu'elle utilise pour recevoir un dividende.
Bob a une clé primaire avec les sous-clés pour signer ses messages, pour authentifier ses publications sur son .onion, pour recevoir des dons, mais pas pour recevoir un dividende (ou alors il en a une mais elle n'est validée par personne).
Si chacun n'a qu'un set de clés limité (actuellement le trousseau classique c'est trois clés : celle pour chiffrer, celle pour signer des contenus, et la clé primaire pour signer d'autres clés), alors le cas de figure de Bob n'est pas envisageable (ni tout autre cas de figure similaire, comme des gens à qui on ferait confiance pour échanger des mails, mais pas pour commiter sur un projet, par exemple, ou à qui on ferait confiance pour les mails et les commits, mais pas pour faire des échanges d'argent).
*splash!*
[^] # Re: Utilité des sous-clés
Posté par gouttegd . Évalué à 3.
OK, je vois.
Mais ce qui empêche de faire ça actuellement n’est pas le fait d’avoir « un set de clés limité » (au passage, il n’y a pas de limite au nombre de sous-clefs qu’il est possible d’avoir — si le trousseau typique contient trois clefs, c’est seulement parce qu’on a rarement besoin de plus), c’est le fait qu’on ne signe que la clef primaire et qu’en faisant ça on valide implicitement toutes les sous-clefs, indépendamment de leur usage.
Il existe déjà « un champ qui permet de définir plus finement pour quoi sera utilisée la clef » (RFC 4880 §5.2.3.21, Key Flags), il serait possible de rajouter les usages que tu mentionnes (il faut un consensus de l’IETF pour ça), mais ce qui manque surtout est la possibilité pour Alice de signer uniquement les sous-clefs qu’elle veut parmi toutes les sous-clefs de Bob (par exemple, les sous-clefs de chiffrement, de signature et de réception de dons, mais pas la sous-clef de réception de dividendes), au lieu de signer la clef primaire.
[^] # Re: Utilité des sous-clés
Posté par kna . Évalué à 3. Dernière modification le 18 mai 2015 à 14:06.
Je pense à une autre utilité : le nomadisme.
L'idée est de garder une sous-clé de chiffrement et une sous-clé de signature, typiquement sur son desktop/laptop ; mais de générer une autre clé de signature pour des usages moins safe comme l'utilisation sur un smartphone/NSA ou sur une clé USB qu'on garde avec soi pour consulter le webmail via un PC public ou d'un ami potentiellement vérolé. On peut révoquer et renouveler plus souvent cette clé qui a plus de chances d'être compromise.
Ça implique cependant de ne pouvoir accéder aux messages chiffrés que via les devices sûrs. Mais permet de signer tous ses messages (chiffrer parfois, signer toujours).
Ça me parait logique dit comme ça, mais est-ce réellement faisable à l'usage ?
[^] # Re: Utilité des sous-clés
Posté par eingousef . Évalué à 3.
Je ne sais pas, mais ce que je sais c'est que une clé que tu utilises sur des ordis que tu ne contrôles pas, je la signe pas.
*splash!*
[^] # Re: Utilité des sous-clés
Posté par kna . Évalué à 2.
Si j'ai bien compris (mais c'est possible que non), c'est la clé primaire que tu signes. Je ne vois pas sinon comment révoquer les sous-clés si les correspondants n'ont pas connaissance de la clé primaire.
Donc tu peux refuser de signer une clé primaire si elle a des sous-clés utilisés sur des devices non sûrs (comment le sais-tu ?). En revanche, rien ne m'empêche d'utiliser une sous-clé sur un ordinateur vérolé après que tu l'aies signé.
Enfin, il faut définir ce qu'est un ordinateur que tu ne contrôles pas. Est-ce qu'il suffit que j'en sois le propriétaire ? Ou le seul utilisateur ? Un smartphone c'est bon ou pas ? Sous Windows c'est bon ou pas ?
Je pense que tout le monde n'aura pas la même définition.
[^] # Re: Utilité des sous-clés
Posté par gouttegd . Évalué à 2.
Oui. La clef primaire et la ou les identité(s) associée(s), plus exactement.
Il ne peut pas le savoir. Ce n’est pas pour rien qu’on parle de confiance envers le titulaire (ownertrust)…
[^] # Re: Utilité des sous-clés
Posté par gouttegd . Évalué à 3.
À mon avis, tu confonds le fait de signer et le fait d’accorder ta confiance.
Signer indique que tu sais que la clef appartient bien à qui elle prétend appartenir : tu certifies, auprès de tous ceux qui te font confiance, que telle clef et telle identité sont associées. En signant, tu ne dis absolument rien de la confiance à accorder au titulaire de la clef (hors le cas des trust signature, très peu utilisées en pratique).
Si tu n’as pas confiance dans le titulaire de la clef, pour quelque raison que ce soit (tu penses qu’il est laxiste, qu’il utilise sa clef sur une machine vérolée jusqu’à la moelle, que sa phrase de passe est sur un post-it sous l’écran, etc.), ben… tu dis explicitement à GnuPG que tu ne lui fais pas confiance (ownertrust = never). Les certifications émises par cette clef seront alors systématiquement ignorées, et le laxisme du titulaire n’aura pas de conséquence sur ta toile de confiance.
# OpenPGP, libsodium...
Posté par Inso . Évalué à 1.
J'ai une petite question du point de vue crypto/mathématiques.
Sur OpenPGP,les clés mettent parfois plusieurs minutes à se générer.
Avec la librairie libsodium, elles sont générées instantanément à la volée. http://doc.libsodium.org/
De ce que j'ai compris, la différence vient de l'utilisation d'algos à courbes elliptiques.
[^] # Re: OpenPGP, libsodium...
Posté par gouttegd . Évalué à 4.
Si, mais c’est une addition récente au standard (RFC 6637).
GnuPG permet d’utiliser les courbes elliptiques depuis la version 2.1.0, mais pas par défaut. Il faut utiliser le « mode expert » (option
--expert) pour se voir offrir la possibilité de générer des clefs ECC.Je crois que l’introduction des courbes elliptiques a été freinée par des histoires de brevets logiciels, mais je ne connais pas les détails.
Si elles ne sont pas utilisées par défaut dans GnuPG aujourd’hui, c’est surtout parce que rare sont les implémentations d’OpenPGP qui les prennent en charge. Générer des clefs ECC par défaut signifierait que les utilisateurs qui acceptent les réglages par défaut se retrouveraient avec des clefs inutilisables pour la plupart des gens (tous ceux qui utilisent des implémentations sans support d’ECC, en particulier tous les utilisateurs de GnuPG 1.4/2.0).
Ce ne sont pas des « manières de générer des clefs », ce sont des types de clefs complètement différents, basés sur des problèmes mathématiques distincts.
Je ne suis absolument pas qualifié pour discuter des différences fondamentales entre la cryptographie « non-ECC » (tous les algorithmes classiques comme RSA, ElGamal, DSA) et la cryptographie ECC (ECDH, ECDSA). Tout ce que je sais, c’est que la plupart des cryptographes admettent que les clefs ECC fournissent une sécurité au moins équivalente à celle de RSA pour des tailles de clefs très inférieures (une clef ECC typique fait 256 bits, et c’est déjà considéré comme fournissant une sécurité supérieure à celle fournie par une clef RSA de 2048 bits).
(Ah oui, et je sais aussi que je n’ai que très modérément confiance dans la plupart des courbes elliptiques dont les paramètres ont été judicieusement choisis — mais judicieusement pour qui ? — sur des critères non-spécifiés…)
Si libsodium génére des clefs ECC, la génération peut être plus rapide déjà parce que les clefs sont plus petites. Mais surtout, il est probable que cette bibliothèque utilise une méthode de génération de nombres aléatoires différente.
GnuPG est assez lent à générer des clefs d’une part parce qu’il est assez gourmad en entropie (probablement trop, ce qui a justement fait l’objet d’une discussion récente sur gnupg-devel), et d’autre part parce, du moins sous GNU/Linux, il obtient son entropie depuis le pool bloquant du système (
/dev/random). Beaucoup d’autres implémentations puisent à l’inverse dans le pool non-bloquant (/dev/urandom) — pas forcément à tort d’ailleurs.[^] # Re: OpenPGP, libsodium...
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il me semble aussi que certain cryptographe se demande si la NSA n'aurait pas déjà cassé de l'ECC. C'est pour ça qu'il mette en avant RSA qui est solide depuis des années.
"La première sécurité est la liberté"
[^] # Re: OpenPGP, libsodium...
Posté par copapa . Évalué à 1.
À noter le démon haveged (paquet éponyme sous Debian) qui rempli /dev/random en récupérant de l'entropie généré par les aléa des différents Cache/TLB/echecs de la prédiction de branches.
Chez moi,
pvme donne un 14Mo/s pour /dev/urandom, 6o/s pour /dev/random classique (en téléchargeant un gros fichier) et 2Mo/s pour /dev/random avec haveged.https://www.irisa.fr/caps/projects/hipsor/index.php
[^] # Re: OpenPGP, libsodium...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il n'y a personne pour utiliser les bits de poids faible d'une entré de carte son ?
"La première sécurité est la liberté"
[^] # Re: OpenPGP, libsodium...
Posté par khivapia . Évalué à 2.
démon randomsound sous debian.
Ce n'est pas incompatible d'Havege d'ailleurs, mais tout le monde n'a pas un micro de branché.
[^] # Re: OpenPGP, libsodium...
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Pas besoin de micro, l'entrée ligne est forcément bruité.
"La première sécurité est la liberté"
# Perte des communications passées ?
Posté par MCMic (site web personnel) . Évalué à 2.
Tu dis plus haut que si tu perds ta sous-clé de chiffrement ou la pense compromise, tu la révoque et en crée une nouvelle, tu dis aussi dans le journal qu’une clé expirée ne peut plus être utilisée, est-ce que ça veut dire que lors d’une telle manip tu perds accès à tout message précédant le changement de clé ? (Donc chiffré avec la clé révoquée)
Empêcher les autres d’accéder à mes messages c’est intéressant mais j’ai toujours peur de finir par ne plus pouvoir y accéder moi même.
[^] # Re: Perte des communications passées ?
Posté par gouttegd . Évalué à 3.
Si tu perds ta sous-clef de chiffrement, c’est-à-dire que d’une façon ou d’une autre tu ne l’as plus en ta possession1 (par exemple si le support sur lequel se trouvait la seule copie devient hors d’usage, ou si tu égares ce support), alors oui, tu perds avec elle toute possibilité de lire tous les messages ayant été chiffrés avec cette clef.
En revanche, si la clef est expirée ou révoquée (par exemple parce que tu soupçonnes, voire même tu sais qu’elle a été compromise), ce sont tes correspondants qui ne pourront plus se servir de la sous-clef publique correspondante pour chiffrer de nouveaux messages à ton intention. Toi, de ton côté, tu pourras toujours utiliser la sous-clef privée pour déchiffrer les anciens messages.
C’est en partie l’intérêt de révoquer (ou laisser expirer) une sous-clef au lieu de la supprimer : la clef existe toujours et tu peux toujours t’en servir, mais tu signales à tes correspondants que eux ne doivent plus l’utiliser — alors que supprimer la clef empêcherait certes tes correspondants de s’en servir, mais toi tu ne pourrais plus t’en servir non plus.
Ou si tu oublies la phrase de passe, ce qui revient au même : tu ne peux plus utiliser la clef. ↩
[^] # Re: Perte des communications passées ?
Posté par BAKfr . Évalué à 1.
Ce que me fait me demander, comment sont propagées les mises à jour des clés ?
Par exemple (corriges moi si je me trompe), Alice révoque sa clé, et upload sa clé révoquée sur son serveur de clé pour "publier" l'information.
Comment Bob fait-il pour être informé des modifications ? C'est automatique, ou manuel ?
Il n'y a pas de risque d'avoir des clés obsolètes et de les utiliser quand même ?
[^] # Re: Perte des communications passées ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il me semble que tu es censé chargé un énorme fichier de clef révoqué depuis le serveur de clef, c'est le point noire du système.
"La première sécurité est la liberté"
[^] # Re: Perte des communications passées ?
Posté par gouttegd . Évalué à 5.
Non, ça ce sont les CRL utilisées pour transmettre les révocations de certificats X.509.
Quand tu révoques une clef OpenPGP, la révocation est directement incluse dans la clef publique1. En rafraîchissant celle-ci (via un serveur de clefs ou n’importe quel autre moyen), tu obtiens automatiquement l’information que cette clef est révoquée.
Alerte d’abus de langage : ce qu’on appelle ici la clef publique est en réalité un certificat OpenPGP, qui contient non seulement la clef publique proprement dite mais aussi les identités associées à cette clef et les différentes signatures (dont l’auto-signature de révocation, le cas échéant). ↩
[^] # Re: Perte des communications passées ?
Posté par gouttegd . Évalué à 6.
Il doit « rafraîchir » sa copie de la clef d’Alice. Si la clef est disponible sur un serveur de clefs, la commande
--refresh-keys Alices’en chargera.Attention, utilisée sans arguments, la commande
--refresh-keysrafraîchit toutes les clefs du trousseau public. C’est pratique, mais ça occasionne une fuite d’informations : ça révèle d’un coup le contenu de ton trousseau public, et donc les noms de toutes les personnes avec qui tu es potentiellement en contact (même celles dont tu n’as pas signé la clef).Il existe des outils pour rafraîchir le trousseau automatiquement, périodiquement et à raison d’une clef à la fois.
Si (cf. message de jben ci-dessous).
# À propos de l'expiration des clefs
Posté par jben . Évalué à 3.
Dans l'hypothèse pessimiste, classiquement utilisée en crypto, ie. l'attaquant contrôle le réseau, tu n'as aucune garantie que le changement de date d'expiration arrive aux utilisateurs de ta clef publique. Ça ne pose pas de problème si la date d'expiration est repoussée, car au pire la clef sera inutilisable, mais dans le cas où tu raccourcis la date d'expiration, il est possible que les utilisateurs ne soient jamais au courant et continuent d'utiliser la clef, qui pour toi est expirée. C'est dans cet esprit, que je considère qu'une date d'expiration plutôt courte est un plus, puisqu'on peut toujours changer d'avis en repoussant, l'inverse n'étant pas possible sous les conditions de contrôle du réseau par l'attaquant.
Après, je vois un autre point utile à avoir une date d'expiration plutôt courte (pour moi, c'est deux mois uniquement sur les sous-clefs), c'est que tu force tes correspondants à synchroniser ta clef publique, et à éventuellement voire les révocations. Je n'ai pour ma part pas confiance au processus de révocation, l'attaquant peut très bien bloquer la diffusion de cette révocation, ou un utilisateur ne jamais la recevoir de sa propre faute. Je considère donc qu'un délai de deux mois sans avoir de nouvelles de ma part (mise-à-jour de la date d'expiration) doit valoir une inutilisabilité de ma clef publique.
[^] # Re: À propos de l'expiration des clefs
Posté par gouttegd . Évalué à 2.
Le problème, c’est que comme tu le dis toi-même tu n’as aucune garantie que le changement de date d’expiration arrive aux utilisateurs de ta clef publique.
Si Alice repousse la date d’expiration de sa clef tous les deux mois mais que Mallory empêche Bob de mettre à jour sa copie de la clef d’Alice, Bob va se retrouver coincé avec une clef expirée que GnuPG lui interdira formellement d’utiliser.
Là, deux possibilités :
a) Soit Bob renonce à envoyer son message à Alice (mieux vaut ne pas communiquer que communiquer sur un canal non-sûr), et dans ce cas Mallory n’a certes pas compromis la confidentialité de leurs communications, mais il les a empêché de communiquer tout court — moi je compte ça comme une attaque.
b) Soit Bob dit « oh, fuck it, j’envoie en clair », et en voulant à tout prix exiger une communication sécurisée, on obtient exactement le contraire.
[^] # Re: À propos de l'expiration des clefs
Posté par jben . Évalué à 3.
Je suis complètement d'accord avec ton raisonnement, mais j'ai une remarque sur l'hypothèse b. Quand on en est au point d'être attaqué par quelqu'un qui maîtrise le réseau, et qu'on choisi de communiquer en clair, on est conscient des enjeux.
[^] # Re: À propos de l'expiration des clefs
Posté par claudex . Évalué à 3. Dernière modification le 19 mai 2015 à 19:44.
Si l'attaquant maîtrise le réseau au point de d'empêcher le rafraichissement des clefs, il y a beaucoup de chances qu'il puisse empêcher toute communication chiffrée, ce qui revient à la même situation que de ne pas pouvoir chiffrer le message.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Confier sa clé privée à des logiciels
Posté par openmind . Évalué à 2.
D'abord merci pour tes dépêches sur OpenPGP, c'est toujours passionnant, même s'il est parfois difficile de se figurer son utilisation au quotidien.
Concernant celle-ci, je comprend bien comment garder ses clés privées à l'abri du vol, mais j'ai un doute sur la façon dont GnuPG les gère, lui. Si j'utilise Enigmail par exemple, est-ce que Enigmail envoi le message à chiffrer/signer à GnuPG qui lui renvoie le résultat, ou est-ce que GnuPG refile à Enigmail ma clé privée pour que celui-ci chiffre/signe? J'ose imaginer que c'est la première solution.
Du coup, il «suffit» d'avoir confiance en GnuPG pour conserver ma clé privée à l'abri?
[^] # Re: Confier sa clé privée à des logiciels
Posté par gouttegd . Évalué à 4.
Surtout pas. En fait, même gpg (le binaire principal de GnuPG) ne voit jamais la clef privée. Le seul composant de GnuPG qui manipule les clefs privées est l’agent GnuPG (gpg-agent).
Dans le cas d’Enigmail, il se passe à peu près ça :
① Enigmail invoque gpg en lui donnant le message à déchiffrer ;
② gpg extrait du message la clef de session chiffrée et l’envoie à l’agent GnuPG ;
③ l’agent demande à l’utilisateur sa phrase de passe (via un programme de la famille pinentry) (si elle n’était pas déjà en cache) ;
④ l’agent lit la clef privée chiffrée depuis le disque dur, la déchiffre à l’aide de la phrase de passe, et l’utilise immédiatement pour déchiffrer la clef de session ;
⑤ l’agent renvoie la clef de session déchiffrée à gpg, qui s’en sert pour déchiffrer le corps du message ;
⑥ gpg renvoie le message déchiffré à Enigmail.
En GnuPG et dans le système sur lequel il tourne. Si ce dernier est compromis, GnuPG seul ne sauvera pas la mise.
[^] # Re: Confier sa clé privée à des logiciels
Posté par openmind . Évalué à 1.
Si le système lui-même est compromis, peut-on imaginer que l'utilisation d'un token type carte OpenPGP permet au moins de ne pas transmettre la clé?
[^] # Re: Confier sa clé privée à des logiciels
Posté par gouttegd . Évalué à 2.
Ne pas transmettre les clefs, oui. L’ordinateur compromis ne peut pas obtenir du token qu’il lui transfère les clefs — celles-ci ne peuvent pas quitter le token.
En revanche, si l’attaquant a le contrôle de l’ordinateur il peut parfaitement utiliser le token sans en récupérer les clefs, et ainsi faire déchiffrer ou signer des messages à sa guise.
Si l’utilisation du token est protégée par un PIN, pas de problème : soit l’attaquant obtient le PIN (il contrôle la machine, ce n’est pas une difficulté pour lui), soit il attend tranquillement que l’utilisateur se serve de son token et le déverouille pour lui.
On peut réduire un tout petit peu le risque en prenant soin de déconnecter le token après chaque utilisation, mais globalement si ta machine est compromise tu ne ne peux plus avoir la moindre assurance sur la confidentialité ou l’intégrité de tes données et de tes communications.
# Signature, chiffrement, bi-clefs...
Posté par khivapia . Évalué à 4.
"à l’exception notable du très flexible RSA, la plupart des algorithmes à clef publiques utilisés par OpenPGP permettent soit de signer (comme DSA ou ECDSA) soit de chiffrer (comme ElGamal ou ECDH), mais ils ne permettent pas de faire les deux. Cela impose donc d’utiliser des clefs distinctes pour les opérations de signature/certification et de chiffrement."
Notons que RSA ne permet pas de chiffrer et signer avec la même clef, du tout, surtout pas, jamais, en aucun cas ! L'algorithme est le même ((RSA, RSA) vs (DSA/ECDSA, ElGamal)), mais les exposants secret et public sont utilisés à l'inverse l'un de l'autre, du coup finalement signer un message n'est pas très différent de le déchiffrer et ça amène nombre de problèmes de sécurité.
Conformément aux principes de Kerckhoff il ne FAUT PAS utiliser un même secret à deux usages distincts (en l'occurence, une même clef pour à la fois signer et chiffrer). D'ailleurs GPG gère bien les clefs par couple.
# Chiffrement des clefs, dérivation et recherche exhaustive
Posté par khivapia . Évalué à 3.
Quelqu'un sait comment c'est fait en pratique ? Les 100ms sont valables sur la machine sur laquelle la clef est protégée ou 100ms c'est en général sur une machine représentative ?
Parce que protéger une clef avec 100ms de temps de calcul sur un processeur vieux ou lent n'est pas la même chose que de le protéger avec 100ms de calcul sur un processeur de serveur moderne.
Par ailleurs pour vraiment gêner la recherche exhaustive il est bon d'utiliser une fonction de hachage pas très performante en implémentation logicielle comme matérielle (une carte FPGA ne coûte vraiment pas cher) à l'inverse des fonctions de hachage standardisées (qui visent à être rapide sur toutes les plate-formes). En gros, l'idéal est d'utiliser des fonctions spécialisées vraiment grosses et lentes pour la recherche exhaustive tout en étant assez rapides pour la dérivation de mot de passe en clefs.
En 100ms, une machine a de quoi faire vraiment plein de calculs et surtout, ce qui coûte vraiment cher en pratique pour la recherche exhaustive, d'utiliser plein de mémoire (quelques mégaoctets bien réutilisés peuvent considérablement gêner l'utilisation des caches et ne pas tenir sur un FPGA tout en étant traités en moins de 100ms).
Bref, comme le dit l'article cité ci-dessous, il ne vaut mieux pas trop compter sur une simple augmentation du nombre d'appels à une fonction optimisée :
https://www.tarsnap.com/scrypt/scrypt.pdf explique "Consequently, using existing key derivation algorithms, even if the iteration count is increased such that the time taken to verify a password remains constant, the cost of finding a password by using a brute force attack implemented in hardware drops each year."
[^] # Re: Chiffrement des clefs, dérivation et recherche exhaustive
Posté par gouttegd . Évalué à 3.
C’est l’agent GnuPG qui détermine à son démarrage le nombre d’itérations à utiliser (en gros il appelle en boucle la fonction de condensation jusqu’à ce que 100 ms se soient écoulées). Du coup, c’est 100 ms sur la machine où tourne GnuPG.
Complètement d’accord, mais en l’espèce GnuPG ne fait que suivre ce qu’impose le standard OpenPGP (RFC 4880, §3.7 String-to-Key Specifiers et §9.4 Hash Algorithms) — standard qui à mon avis mériterait bien une remise à jour, mais apparemment le groupe de travail OpenPGP à l’IETF ne se réunit plus.
[^] # Re: Chiffrement des clefs, dérivation et recherche exhaustive
Posté par gouttegd . Évalué à 2.
Au cas où quelqu’un suivrait encore les commentaires de ce journal, je signale que le groupe de travail OpenPGP a en fait décidé de se reformer dans l’objectif de publier un nouveau RFC (temporairement surnommé RFC4880bis) pour mettre à jour le standard OpenPGP.
L’addition de nouveaux mécanismes de dérivation de clefs à partir de la phase de passe est notamment au programme (PKBDF2 et scrypt sont envisagés, et peut-être aussi le vainqueur de la compétition PHC qui se tient actuellement).
Affaire à suivre…
[^] # Re: Chiffrement des clefs, dérivation et recherche exhaustive
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Merci pour le suivi :)
# Pourquoi 3 clés?
Posté par openmind . Évalué à 1.
Bonjour encore,
je vois que sur la carte OpenPGP, on peut/doit stocker 2 ou 3 clés. Pourquoi donc?
Dans les tutos que je lis sur OpenPGP, on explique que tout est fait avec une seule paire de clés publique/privée (chiffrement de la parte de mes correspondants avec la première, signature et déchiffrement chez moi avec la seconde). Pourquoi alors avoir une clé de chiffrement et une clé de signature différentes?
Et question corollaire: Si j'ai 3 clés différentes, j'ai donc 3 clés publiques à communiquer. Comment mes correspondants gèrent-ils tout ça? C'est automagiquement fait par GnuPG?
[^] # Re: Pourquoi 3 clés?
Posté par gouttegd . Évalué à 5.
Une clef de signature, une clef de (dé)chiffrement, et une clef d’authentification.
Comme j’essaie de l’expliquer dans le journal, seul RSA permet d’utiliser une même paire de clefs à la fois pour signer/vérifier (signer avec la clef privée, vérifier avec la clef publique) et pour chiffrer/déchiffrer (chiffrer avec la clef publique, déchiffrer avec la clef privée). Les autres algorithmes asymétriques n’ont pas cette flexibilité (une paire ElGamal ou ECDH ne permet que de chiffrer/déchiffrer, une paire DSA ou ECDSA ne permet que de signer).
Et même dans le cas de RSA utiliser une seule paire pour toutes les opérations n’est pas forcément considéré comme une bonne idée (cf. message de khivapia ci-dessus).
On touche là du doigt un problème de vocabulaire récurrent et enquiquinant dans le monde OpenPGP, lié au fait que le terme « clef publique » peut désigner deux choses complètement différentes.
Au sens strict, une « clef publique » est juste un ensemble de quelques valeurs numériques (par exemple, une clef publique RSA est un couple {n,e} où n est le module et e l’exposant de chiffrement), sans aucune autre information. C’est le pendant de la clef privée dans une « paire de clefs ».
Mais dans le monde OpenPGP, on emploie très souvent « clef publique » pour désigner ce qu’il conviendrait plutôt d’appeler un « certificat OpenPGP »¹, et qui comprend :
Ce que les utilisateurs d’OpenPGP manipulent, ce sont des certificats, jamais des clefs publiques au sens strict.
Peu importe le nombre de sous-clefs, quand tu communiques ta « clef publique », tu communiques un certificat contenant toutes les informations ci-dessus (y compris toutes les sous-clefs publiques). Tes correspondants n’ont pas à se soucier de ce que contient ton certificat.
¹ Cette notion de « certificat » a été évitée dans les RFC 2440/4880 pour des raisons politiques (pour ne pas marcher sur les plates-bandes de X.509 et PKIX), d’après un des auteurs desdites RFC.
[^] # Re: Pourquoi 3 clés?
Posté par openmind . Évalué à 1.
Super clair.
Merci :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.