Retrouver une vie privée en ligne

Retrouver une vie privée en ligne
Caliopen
Étude de détail de Caliopen:
les indices de confidentialité
et la gestion des clés.
2013: Révélation d’E. Snowden
Prise de conscience du grand public,
mais
Peu ou pas de changement des pratiques.
L’équation
Snowden
❖
L’hyper-centralisation des services permet la surveillance de
masse à moindre coût.
❖ La grande majorité des internautes considère sa propre vie
privée comme sans importance.
“La même chose mais” ou rien
Messagerie sécurisée, ou autohébergée (Lavabit, Protonmail, Tutanota,
Mailpile…)
Les
mauvaises
réponses
❖
Un public trop restreint, par manque de motivation ou d’expertise
technique.
❖
Des utilisateurs qui n’ont d’autre choix que de correspondre avec des
contacts restés dans les grands silos.
❖
Un seul protocole concerné quand nos correspondances privées en
utilisent beaucoup d’autres.
Alternatives “post email”
(BitMessage, Pond, Bote mail…)
❖
Des utilisateurs qui se coupent de la quasi-totalité de leurs contacts.
❖
Une vision égocentrique et totalitaire de la sécurité.
Répondre à un besoin
Agréger une correspondance privée trop dispersée
Caliopen
❖
Un seul outil pour gérer tous ses contacts.
❖
Une conversation est définie par la liste de ses participants plutôt que
par un protocole sous-jacent.
❖
Tous les protocoles et services permettant une correspondance privée
peuvent être ajoutés.
Redonner une valeur à la vie privée de l’utilisateur
❖
Associer un “indice de confidentialité” à chaque élément de l’interface.
❖
Proposer des solutions pour améliorer ces indicateurs.
❖
Récompenser les progrès.
Privacy Index (« indice de confidentialité »)
Retrouver une notion connue de l’utilisateur
Philosophie
du PI
❖
La lettre cachetée proposait un certain niveau de confidentialité.
❖
Cette notion n’a disparu qu’avec l’avènement de la correspondance
numérique.
❖
La confidentialité s’évalue en fonction d’éléments divers, ce n’est pas
une valeur binaire.
Afficher des valeurs intuitives et compréhensibles
❖
Les métriques ne doivent pas comporter d’éléments cachés
❖
L’outil doit accompagner l’utilisateur dans sa progression.
❖
Chaque élément de Caliopen a sa propre métrique.
Éléments de confidentialité
Chaque partie d’un compte Caliopen aura son propre PI:
La liste des
PI
❖
Les contacts de l’utilisateur
❖
Les terminaux utilisés pour accéder à son compte
❖
Les messages reçus et émis
❖
Les discussions (ensembles de messages émis et reçus)
❖
Les fichiers et agendas
❖
Et le compte de utilisateur lui-même
Les différents calculs ne sont pas encore tous détaillés, mais de
nombreux éléments de métriques sont identifiés.
Le PI d’un message
Tous les indices de confidentialité ont une valeur allant de 0
à 100. Pour un message on additionne les éléments suivants:
Exemple de
PI
❖
Protocole utilisé (XMPP/OTR+TLS : 15 points, SMTP/ TLS et XMPP/TLS :
10 points, IRC/OTR : 8 points, SMS/SMSsecure : 6 points).
❖
Évaluation de l’authentification du serveur émetteur (TLS avec certificat
connu: 10 points, TLS autosigné: 5 points…)
❖
Chiffrement du contenu: 20 points
❖
PI du terminal émetteur (dans une limite de 20 points)
❖
PI du contact de plus bas niveau (dans une limite de 20 points)
15 points restant à attribuer.
Le PI d’un compte utilisateur
Composante technique et composante comportementale:
❖
Exemple de
PI
Présence d’une clé publique, type,
taille, authentification : de 0 à 9
❖
PI du terminal de référence (de 0 à 9)
❖
PI moyen des contacts (de 0 à 9)
❖
Utilisation de son propre MX (20)
❖
Type d’authentification à la
connexion (simple password: 0 à 2,
double authentification: 3 à 4,
certificat client: 5 points)
❖
PI du terminal en cours (de -2 à +2)
❖
Fréquence de déconnexion (-5 à +5)
❖
Fréquence du chiffrement (0 à 10)
❖
PI des correspondants (0 à 10)
❖
Pénalité de 5 points pour réponse
non chiffrée à un message chiffré
❖
Pénalité allant jusqu’à 20 points pour
affichage d’un message sur un
terminal de PI inférieur.
L’oeuf et la poule
Difficile de trouver la clé de chiffrement d’un contact
Diffusion
de clé
❖
Premier échange non chiffré
❖
Systèmes centralisés (CA) type S/MIME
❖
Serveurs de clés
Question de confiance
❖
Outils standards sans gestion des clés intégrée
❖
Systèmes centralisés aisément détournés par les états
❖
Serveurs de clés sans contrôle de l’utilisateur
❖
Authentification difficile (Web of Trust)
Une solution “évidente”
Utilisation du DNS pour stocker et diffuser les clés
Ta clé dans
ta zone
❖
Système décentralisé, difficile à détourner
❖
Relation entre identifiant d’un contact et sa zone DNS
❖
Protocole déjà existant (DANE)
Nombreux avantages annexes
❖
Meilleure garantie d’authenticité (DNSSEC)
❖
Aisément automatisable (recherche, révocation, cache…)
❖
Confiance par défaut dans le gestionnaire de la zone DNS
Quelques questions
❖
Diffusion du graphe social, mapping de la partie locale
Pistes alternatives
Brouillon « SMTP and SUBMISSION Service Extensions For Address Query »
❖
Délègue la gestion des clés au serveur MX de la zone
Webfinger (RFC 7033)
What else ?
❖
Peu connu
La généralisation
GnuPG vient d’intégrer le brouillon IETF OpenPGP DANE
❖
Extension
du domaine
À partir de la version 2.1.9 (octobre 2015)
Enigmail propose d’utiliser une ébauche de PI
❖
Indicateurs “binaires” de confidentialité et d’authenticité
Gmail va bientôt afficher une alerte de confidentialité
❖
Si le transport d’un message n’est pas sécurisé
L’IETF a commencé à formaliser
❖
Le RFC 7444 prévoit un champ technique pour un futur PI