Si par « il » tu veux dire GnuPG, ici GnuPG ne fait que suivre le standard OpenPGP. La faille se trouve dans le standard lui-même, pas dans les implémentations.
Du coup la question devient : Pourquoi le standard OpenPGP utilise-t-il, pour l’échange d’une clef privée, un format spécifique (le Secret-Key Packet Format, RFC 4880 §5.5.3) au lieu de simplement mettre la clef privée dans un Symmetrically Encrypted Integrity Protected Data Packet (le format utilisé entre autres pour l’échange de messages protégés par une phrase de passe, RFC 4880 §5.13), qui offrirait toutes les garanties nécessaires ?
Seuls les auteurs du standard peuvent répondre à cette question, mais si je devais deviner je dirais que c’est lié à l’âge du standard (il date du début des années 1990) et résulte d’un soucis de performance (à l’époque il était pertinent de ne vouloir chiffrer que le strict minimum d’octets, les opérations cryptographiques étant coûteuses) et de manque de considération pour les attaques actives (un problème général de la cryptographie des années 1990 ; SSL en a largement souffert aussi).
Quel est le problème avec le Secret-Key Packet Format ? Ce format contient à la fois les parties publiques et secrètes d’une clef OpenPGP, mais seule la partie secrète est chiffrée avec la phrase de passe. La partie publique est en clair. Après tout, la partie publique, comme son nom l’indique, est, euh, publique, donc pourquoi faudrait-il la chiffrer ? L’attaquant peut l’obtenir directement depuis les serveurs de clefs de toute façon, on ne gagne rien à chiffrer cette partie-là, pas vrai ?
Si on ne considère que les attaques passives, c’est vrai, et le format protège toujours efficacement contre ces attaques. Pas d’inquiétude à avoir si vous avez laissé votre clef au format Secret-Key Packet (tel que généré par gpg --export-secret-key) quelque part où Eve a pu mettre la main dessus : elle n’aura pas plus de chance qu’hier d’obtenir une forme utilisable de votre clef privée (sous réserve d’avoir utilisé une phrase de passe solide évidemment).
Par contre, si votre clef au format Secret-Key Packet tombe entre les mains de l’attaquant actif Mallory, rien ne va plus. Sans avoir besoin de déchiffrer la partie secrète (ce qu’il ne peut pas faire), Mallory peut modifier à sa guise le contenu de la partie publique, qui n’a aucune protection. S’il peut ensuite faire en sorte que vous utilisiez sa version modifiée de votre clef,1 il vous rend vulnérable à toutes sortes d’attaques la prochaine fois que vous déchiffrerez ou signerez un message.2
La contre-mesure la plus simple et la plus immédiatement accessible pour les utilisateurs de GnuPG est de simplement s’assurer que l’intégralité du Secret-Key Packet est chiffré (d’où la commande donnée dans mon message précédent).
La contre-mesure définitive a déjà été ajouté au brouillon de la prochaine version du standard OpenPGP et consistera, non pas à chiffrer la partie publique de la clef, mais à ajouter un mécanisme de vérification de l’intégrité de celle-ci, de sorte qu’aucune modification ne puisse passer inaperçue.
1 Comment Mallory pourrait-il vous faire utiliser sa copie modifiée de votre propre clef ? On peut imaginer plusieurs scénarios. Par exemple, vous avez stockée une copie de sauvegarde de votre clef privée quelque part en ligne (sans craindre pour sa sécurité puisque vous avez utilisé une phrase de passe forte), puis vient le jour où vous avez besoin de restaurer votre clef depuis cette sauvegarde, sans vous douter qu’entre-temps Mallory avait eu accès à cet espace de stockage en ligne, et n’attendait que le jour où vous récupéreriez votre sauvegarde (Mallory est notoirement très patient). Plus réalistement, certains services de messagerie chiffrée aujourd‘hui reposent sur le fait que la clef privée est en permanence stockée sur les serveurs du fournisseur plutôt que sur votre propre machine ; c’est le cas par exemple de ProtonMail, qui était précisément vulnérable au type d’attaque présenté ici (ProtonMail a implémenté des contre-mesures après une responsible disclosure des auteurs du papier).
2 Les attaques rendues possibles par des modifications astucieuses de la partie publique d’une clef dépendent du type de clef (DSA, RSA, ECDSA...). Dans le pire des cas, elles peuvent aller jusqu’à permettre l’extraction complète de la clef privée à partir de seulement une signature émise par la clef modifiée.
[^] # Re: Bref résumé
Posté par gouttegd . En réponse au lien Attaque sur le format d’échange des clefs privées OpenPGP. Évalué à 9.
Si par « il » tu veux dire GnuPG, ici GnuPG ne fait que suivre le standard OpenPGP. La faille se trouve dans le standard lui-même, pas dans les implémentations.
Du coup la question devient : Pourquoi le standard OpenPGP utilise-t-il, pour l’échange d’une clef privée, un format spécifique (le Secret-Key Packet Format, RFC 4880 §5.5.3) au lieu de simplement mettre la clef privée dans un Symmetrically Encrypted Integrity Protected Data Packet (le format utilisé entre autres pour l’échange de messages protégés par une phrase de passe, RFC 4880 §5.13), qui offrirait toutes les garanties nécessaires ?
Seuls les auteurs du standard peuvent répondre à cette question, mais si je devais deviner je dirais que c’est lié à l’âge du standard (il date du début des années 1990) et résulte d’un soucis de performance (à l’époque il était pertinent de ne vouloir chiffrer que le strict minimum d’octets, les opérations cryptographiques étant coûteuses) et de manque de considération pour les attaques actives (un problème général de la cryptographie des années 1990 ; SSL en a largement souffert aussi).
Quel est le problème avec le Secret-Key Packet Format ? Ce format contient à la fois les parties publiques et secrètes d’une clef OpenPGP, mais seule la partie secrète est chiffrée avec la phrase de passe. La partie publique est en clair. Après tout, la partie publique, comme son nom l’indique, est, euh, publique, donc pourquoi faudrait-il la chiffrer ? L’attaquant peut l’obtenir directement depuis les serveurs de clefs de toute façon, on ne gagne rien à chiffrer cette partie-là, pas vrai ?
Si on ne considère que les attaques passives, c’est vrai, et le format protège toujours efficacement contre ces attaques. Pas d’inquiétude à avoir si vous avez laissé votre clef au format Secret-Key Packet (tel que généré par
gpg --export-secret-key) quelque part où Eve a pu mettre la main dessus : elle n’aura pas plus de chance qu’hier d’obtenir une forme utilisable de votre clef privée (sous réserve d’avoir utilisé une phrase de passe solide évidemment).Par contre, si votre clef au format Secret-Key Packet tombe entre les mains de l’attaquant actif Mallory, rien ne va plus. Sans avoir besoin de déchiffrer la partie secrète (ce qu’il ne peut pas faire), Mallory peut modifier à sa guise le contenu de la partie publique, qui n’a aucune protection. S’il peut ensuite faire en sorte que vous utilisiez sa version modifiée de votre clef,1 il vous rend vulnérable à toutes sortes d’attaques la prochaine fois que vous déchiffrerez ou signerez un message.2
La contre-mesure la plus simple et la plus immédiatement accessible pour les utilisateurs de GnuPG est de simplement s’assurer que l’intégralité du Secret-Key Packet est chiffré (d’où la commande donnée dans mon message précédent).
La contre-mesure définitive a déjà été ajouté au brouillon de la prochaine version du standard OpenPGP et consistera, non pas à chiffrer la partie publique de la clef, mais à ajouter un mécanisme de vérification de l’intégrité de celle-ci, de sorte qu’aucune modification ne puisse passer inaperçue.
1 Comment Mallory pourrait-il vous faire utiliser sa copie modifiée de votre propre clef ? On peut imaginer plusieurs scénarios. Par exemple, vous avez stockée une copie de sauvegarde de votre clef privée quelque part en ligne (sans craindre pour sa sécurité puisque vous avez utilisé une phrase de passe forte), puis vient le jour où vous avez besoin de restaurer votre clef depuis cette sauvegarde, sans vous douter qu’entre-temps Mallory avait eu accès à cet espace de stockage en ligne, et n’attendait que le jour où vous récupéreriez votre sauvegarde (Mallory est notoirement très patient). Plus réalistement, certains services de messagerie chiffrée aujourd‘hui reposent sur le fait que la clef privée est en permanence stockée sur les serveurs du fournisseur plutôt que sur votre propre machine ; c’est le cas par exemple de ProtonMail, qui était précisément vulnérable au type d’attaque présenté ici (ProtonMail a implémenté des contre-mesures après une responsible disclosure des auteurs du papier).
2 Les attaques rendues possibles par des modifications astucieuses de la partie publique d’une clef dépendent du type de clef (DSA, RSA, ECDSA...). Dans le pire des cas, elles peuvent aller jusqu’à permettre l’extraction complète de la clef privée à partir de seulement une signature émise par la clef modifiée.