wget/gist:840f803e58d2677e0e46

## gistfile1.txt
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
	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