Created
March 2, 2015 09:44
-
-
Save wget/840f803e58d2677e0e46 to your computer and use it in GitHub Desktop.
OpenGPG
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
François, | |
Comme promis, voici mon opinion à propos du post de la semaine dernière | |
évoquant PGP[1]. | |
L'idée principale que j'en retiens, c'est que l'auteur tente de démontrer que | |
la cryptographie actuellement est vraiment compliquée pour un non initié, ou | |
tout simplement pour le commmun des mortels sans éducation informatique. | |
Malheureusement, ne pas comprendre le principe de clé publique/clé privée | |
revient à devoir repenser la cryptographie asymétrique dans son fondement. | |
Je ne pense pas qu'on doive être aussi radical. La solution actuelle me semble, | |
à mon humble avis, sans aucune mesure plus solide et éprouvée face à toutes | |
autres nouvelles solutions basées sur la biométrie, les jetons USB, les modules | |
TPM, etc. Le support de stockage des clés change, mais le principe reste | |
indéniablement le même. | |
"Bien que tout le monde semble préoccupé de sa vie privée, le choix de GnuPG | |
est un choix délibéré." Je suis entièrement d'accord avec ce fait, bien qu'à | |
mon humble avis, GPG ait réussi à s'imposer comme standard de facto, du moins | |
en ce qui concerne les mails. Je pense qu'il aurait dû être plus largement | |
utilisé. Les entreprises technologiques auraient vraiment dû pousser son | |
adoption et financer le projet (cf. Heartbleed avec OpenSsl). | |
On peut saluer l'idée que la Belgique a eue avec sa Belgian eID. Chaque citoyen | |
belge et majeur reçoit une paire de clé privée/publique lui permettant de | |
signer un mail ou un acte ayant la même valeur que sa signature manuscrite. | |
Malheureusement, ce que j'en retiens c'est que ce n'est compatible qu'entre | |
citoyens de nationalité belge et les majeurs. Les étrangers (parrait qu'on doit | |
dire allochtone désormais) et les mineurs ne sont pas concernés. De plus, la | |
solution choisie se base sur la seule confiance en une autorité pour signer | |
l'ensemble des clés. Si demain la clé privée du Belgian Root Certificate venait | |
à être dévoilée, le système s'effondre. | |
Là où GnuPG (ou PGP) a une longueur d'avance reste son modèle décentralisé. | |
Sachant que chacun signe la clé de l'autre, si une clé privée venait à être | |
compromise, ça ne pose pas de problème. La personne concernée revoque sa clé, | |
et nous, nous révoquons sa signature. A ma connaissance il n'existe pas de | |
système de vérification automatisé à ce niveau. Nous devons manuellement | |
vérifier si l'ensemble de nos signatures ont été réalisées à l'aide de clés | |
privées toujours valides. De même, pour reprendre ton exemple où une entreprise | |
malveillante viendrait à signer tout un ensemble de clés sans procéder | |
à quelconque vérification, c'est à la personne recevant les signatures d'être | |
libre ou non de les intégrer à sa clé publique qui sera publiée sur un serveur | |
de clés. Nous sommes donc libres de choisir qui va signer notre clé et libre de | |
l'envoyer (ou non) sur le serveur de clés publiques d enotre choix. | |
Là où le bât blesse, c'est qu'il n'existe aucun serveur de clés centralisé | |
digne de confiance. A l'instart des DNS qui sont (anycast mis à part) de nature | |
centralisée, il n'existe pas vraiment de serveur qui se soit imposé comme | |
standard[3][4]. Comme il n'y a pas d'authentification au niveau du serveur de | |
publication des clés, je pourrais par exemple publier une clé en me faisant | |
passer pour toi. La seule vérification est effectuée au niveau de l'adresse | |
mail. Si une personne publie une clé publique sur un serveur de clés, celui-ci | |
nous en averti par le biais d'un email. Si l'envoi de clés n'est pas légitime, | |
nous sommes libres de le révoquer en cliquant sur le lien approprié reçu par | |
mail. Comme on peut s'en rendre compte, cette solution de vérification est loin | |
d'être la plus efficace et la plus sûre. | |
Par contre, dans le cadre d'une attaque MITM à grande échelle, et dans le but | |
d'intercepter des mails chiffrés, toutes modifications de la clé publique | |
visant à se faire passer pour la personne concernée sont aisément détectables. | |
Il suffit pour nous au bout d'un temps, de vérifier si le fingerprint | |
(empreinte) de notre clé publique est toujours la même. Or, ce dont nous sommes | |
toujours incapables de détecter c'est dans le cas d'une fenêtre d'attaque menée | |
sur une durée de temps très courte. Par exemple, toujours dans le cadre d'une | |
attaque à grande échelle, un intervenant arrive à prendre possession de notre | |
adresse mail, récupérer nos emails, changer notre clé publique et la remettre | |
telle qu'elle était avant l'attaque, tout ceci avant que nous ne vérifions son | |
empreinte. Si pendant ce temps quelqu'un ne possédant pas notre clé publique | |
vient à nous envoyer un mail critique, juste pendant cette fenêtre d'attaque, | |
le système GPG est failible. Le problème, une fois encore, réside dans la | |
transmission de la clé publique. | |
De façon similaire à la solution de certificat SSL que Mozilla, accompagné | |
d'acteurs technologiques tiers, essaie de mettre sur le marché, j'attends | |
impatiemment une révolution dans la facilité d'utilisation de PGP. Malgré le | |
fait que Mozilla se soit désaisi du projet Thunderbird, du nouveau est annoncé | |
pour la version 38, la prochaine mouture. Espérons que ça porte également sur | |
l'intégraion de GnuPg (Enigmail). | |
Cordialement, | |
[1] http://www.thoughtcrime.org/blog/gpg-and-me/ | |
[2] https://letsencrypt.org/ | |
[3] http://pgp.mit.edu:11371/ | |
[4] https://keyserver.pgp.com/vkd/GetWelcomeScreen.event |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Je me demande si cela ne serait pas plus simple de déléguer la crypto à HTTPS. Chaque utilisateur utilise un nom de domaine pour exposer sa clé (emailhash.mailusers.outlook.com pour email@outlook.com, lolhash.mailusers.toto.be pour lol@toto.be) et on envoie les messages en les vérifiant/encodant sur base de la clé publique liée au nom de domaine de l'envoyeur.
Comme ça on peut se fier à HTTPS/DNS pour le gros du travail, et on s'abstrait d'un système qui me parait compliqué. Pour ce qui est de lié ton identité physique à la clé (est-ce vraiment nécessaire? selon moi on n'en a pas besoin dans 99.99% des cas) on peut tout simplement signer le certificat de son nom de domaine https avec une clé reconnue comme celle de notre carte d'identité.
Si on ne peut pas, tant pis j'ai envie de dire. De toute façon, se lier à une identité physique n'a aucun intérêt dans un grand nombre de cas, et pour les autres cas il suffit d'aller emmerder son gouvernement ^_^