Surveillance généralisée : quid de la confidentialité persistante ?

Magazine
Marque
MISC
Numéro
77
|
Mois de parution
janvier 2015
|
Domaines


Résumé
Dans l'écosystème actuel des bonnes propriétés cryptographiques des outils à destination du grand public, nous avons la désormais célèbre « confidentialité persistante ». Conceptualisée puis implémentée à la fin des années 1980, elle devient aujourd'hui incontournable dans l'élaboration de nouveaux protocoles de communication à destination du plus grand nombre, tels OTR ou celui utilisé par crypto.cat.

Body

1. Une nouvelle menace ?

À l'origine théorisée en 1989 [1], la confidentialité persistante revient depuis ces dernières années comme une caractéristique essentielle des outils de communication électronique à destination du grand public. En trouver les raisons n'est pas difficile : les compromissions très fréquentes des clefs (stockage en clair, vol, clef faible), l'encadrement législatif relativement récent de l'usage de la cryptographie (qui impose notamment en France la remise des clefs de chiffrement sous certaines conditions), et désormais la surveillance effectuée par de nombreuses agences de renseignement qui peuvent potentiellement enregistrer tout ce qui est relatif au trafic chiffré pour, dans l'hypothèse où la clef de chiffrement serait obtenue, déchiffrer l'ensemble des flux ainsi conservés. Ce cas de figure s'est avéré, au moins outre-Atlantique, dans le cas de la demande de remise de clef effectuée par le FBI auprès de Lavabit dans le cadre des révélations d'Edward Snowden [2].

2. Confidentialité persistante : une affaire de longue durée

La confidentialité persistante a été initialement définie comme le fait qu'« un échange de clef authentifié fournit une confidentialité persistante si la découverte de la clef secrète longue durée ne compromet pas la confidentialité des clefs échangées précédemment ». La notion d'échange de clef authentifié se réfère bien entendu à la génération d'un secret partagé éphémère entre deux parties dont l'objet sera, dans de nombreux cas, le chiffrement d'une partie de la communication. On peut nommer cette dernière clef « clef de session », une session étant ici un concept abstrait se référant seulement à une durée finie (liée par exemple à l'envoi d'un message dans un système de messagerie instantanée, ou encore la durée d'une connexion TCP, ou une période fixe d'une semaine par exemple). Concernant la clef secrète longue durée, cette notion se réfère au secret partagé au préalable par les deux parties (dans le cas d'un système symétrique) ou alors à la clef privée RSA de chacune des parties. Bien que l'usage de cette clef ne soit pas spécifié dans la définition originale, elle peut, et cela dépend bien entendu des spécifications utilisées, servir pour l'authentification ou le chiffrement au début de l'échange. Un échange de clef naïf tel la génération d'une chaîne aléatoire et son chiffrement avec la clef longue durée puis son envoi n'offre donc pas, au regard de cette première définition, une confidentialité persistante. Cette définition de base ne couvrant pas l'ensemble des problèmes potentiellement rencontrés (on ne parle ici que de la découverte du secret longue durée), voyons plus en détail les notions utilisées à l'heure actuelle.

2.1 Définitions

D'un côté, nous avons la Forward Secrecy : un échange de clef authentifié fournit la Forward Secrecy si la découverte de la clef secrète longue durée (telle celle d'un certificat X509) ne compromet pas la confidentialité des messages chiffrés passés. C'est-à-dire que la clef utilisée pour chiffrer l'échange (clef de session) est indépendante de la clef secrète longue durée. D'un autre côté, la Perfect Forward Secrecy conserve également la confidentialité des messages chiffrés passés même en cas de compromission de la clef de session. En d'autres termes, connaissant la clef de la session courante, il est impossible de retrouver les clefs générées précédemment qui permettraient de déchiffrer les sessions passées. Une autre définition assez récente concerne la compromission des futures sessions. Dans le cas de la PFS (et de la FS), nous ne pouvons en rien affirmer que les futures sessions ne seront pas compromises dans le cas du vol d'une clef de session. Imaginons par exemple un protocole qui dériverait la clef de la session n+1 en utilisant un procédé déterministe, une fonction de hachage disons, sur la clef de la session n : ce protocole assure bien la confidentialité des messages passés en cas de découverte de la clef de session courante (fonction de hachage non inversible), mais un attaquant ayant réussi à obtenir la clef de session courante pourrait alors la dériver (application de la fonction de hachage) et obtenir ainsi la clef de session suivante. Le fait que la découverte de la clef de session ne compromet pas la confidentialité des messages futurs a été élégamment nommée Future Secrecy. En définitive, l'ensemble de ces propriétés (Forward Secrecy, Perfect Forward Secrecy et Future Secrecy) implique de bien distinguer chaque cas de compromission de clef possible.

2.2 Primitives cryptographiques

Afin de fournir de telles propriétés, il est nécessaire de générer des clefs éphémères. Le protocole de mise en accord de clef Diffie-Hellman étant la référence actuelle, décrivons brièvement son fonctionnement ainsi que les différents usages qui lui sont associés. Nous verrons également par la suite qu'il existe plusieurs méthodes permettant de dériver des clefs tout au long d'une communication offrant une confidentialité persistante. Du côté des primitives nécessaires, ces différentes méthodes (connues sous le nom de ratchet) n'utilisent guère plus qu'une fonction de hachage ou (de nouveau) un échange Diffie-Hellman pour l'obtention d'une nouvelle clef.

2.2.1 Le protocole Diffie-Hellman

Sans prétendre détailler l'ensemble du cadre de la théorie des nombres sur lequel repose ce protocole, celui-ci permet à deux entités de générer un secret partagé au travers d'un canal public sans qu'il soit possible pour un adversaire passif de retrouver le secret, même en ayant enregistré l'intégralité de l'échange. Voici, dans sa version simplifiée, l'échange de clef : Alice et Bob choisissent ensemble les paramètres p et g. Le premier étant un nombre premier de grande taille et le second un générateur du sous-groupe Z/pZ. S'ensuit l'échange suivant (l'ensemble des opérations est effectué modulo p) :

- Alice génère localement un nombre aléatoire a puis envoie g^a ;

- Bob génère localement un nombre aléatoire b puis envoie g^b ;

- Alice et Bob génèrent localement le (même !) secret partagé (g^a)^b et (g^b)^a.

La difficulté pour un adversaire passif va être le calcul de : a (ou b) connaissant g^a (ou g^b). C'est un problème bien connu et qui résiste depuis des années : le calcul du logarithme discret. Un clin d’œil à l'actualité où une publication de recherche de début d'année propose un algorithme de calcul du logarithme discret en temps quasi polynomial [3].

On trouvera également des variantes de ce protocole, notamment celles utilisant les courbes elliptiques, permettant l'utilisation de clefs plus petites avec un niveau de sécurité aussi élevé. Pour comparaison, selon les recommandations de l'ANSSI [4], une courbe elliptique utilisant une clef de 256 bits est évaluée comme étant aussi solide qu'une clef RSA de 3072 bits. Celle-ci repose également sur le problème du logarithme discret (mais sur courbe elliptique) et se retrouve pour le protocole d'échange de clef Diffie-Hellman sous l'acronyme d'ECDH, pour Elliptic Curve Diffie Hellman.

2.2.2 Usages de Diffie-Hellman pour la confidentialité persistante

L'élément essentiel dans le fait de fournir les propriétés liées à la confidentialité persistante va résider dans le changement fréquent de la clef de session (donc l'usage de Diffie-Hellman), ainsi que l'indépendance de cette clef vis-à-vis de l'ensemble des autres clefs (passées, futures et longue durée). Prenons un exemple concret utilisé massivement à l'heure actuelle : TLS pour le transport sécurisé de HTTP. Synthétiquement, une poignée de main TLS sans PFS présente côté client les primitives disponibles puis, côté serveur, les primitives supportées et le certificat X509 contenant la clef publique du serveur afin d'en effectuer l'authentification (seul le serveur est authentifié). Enfin, une clef de session est alors générée par le client, chiffrée avec la clef publique du serveur puis envoyée à celui-ci. Cette dernière clef sera utilisée comme clef de chiffrement durant toute la durée de la session TLS. Ce type d'échange ne permet en rien d'assurer la confidentialité persistante : si la clef privée associée au certificat du serveur est corrompue, alors la clef de session pourra être déchiffrée. TLS permet, afin d'offrir la PFS, l'utilisation d'un échange Diffie-Hellman éphémère, c'est-à-dire qui sera effectué en début de chaque session. Une clef unique sera utilisée comme clef de session et le certificat permettra uniquement l'authentification du serveur. Détail d'importance, car l'échange de clef Diffie-Hellman nécessite en effet de se prémunir d'attaque MITM. On retrouvera ces primitives sous les noms ECDHE et DHE (le dernier E étant ici pour ephemeral). TLS n'est qu'un exemple particulier dans l'ensemble des contextes possibles dans lequel Diffie-Hellman peut être utilisé. La notion de session étant ici utilisée dans un contexte synchrone et de courte durée, une clef de chiffrement éphémère est tout à fait appropriée au chiffrement de chaque message envoyé durant cette session. Si l'on se place dans un cadre asynchrone avec des sessions très longues, alors il convient de chiffrer chaque message durant cette session avec une clef différente (décrit par la suite avec l'exemple de Pond).

2.2.3 Usage d'une fonction de hachage pour la confidentialité persistante

Un autre exemple est celui de SCIMP [5] (Silent Circle Instant Message Protocol), un protocole dont le but est de fournir une communication de type « messagerie instantanée » sécurisée en utilisant XMPP. Après la génération d'un secret partagé par l'usage de Diffie-Hellman, la clef est dérivée par l'usage d'une fonction de hachage afin de produire une clef différente pour chaque message envoyé. Un des points faibles de ce type de ratcheting est que la compromission de la clef de chiffrement en un point de la communication compromet l'ensemble des clefs suivantes. Cette méthode d'offre donc pas la  Future Secrecy.

2.3 Limites

Un des problèmes majeurs qui n'a été que partiellement formulé dans l'ensemble des paragraphes précédents reste celui de l'authentification. Une attaque par « l'homme du milieu » (man in the middle) est toujours possible sur un échange de clef Diffie-Hellman, il faut donc que ce dernier soit authentifié. C'est de ce problème que découle une des limites de la confidentialité persistante, qui est que la clef permettant l'authentification peut également être découverte. Ainsi, la combinaison d'une attaque MITM avec l'usage de la clef permettant l'authentification (on notera également qu'une attaque plus triviale peut même utiliser une autre clef si l'utilisateur n'effectue pas de vérification sur cette dernière) engendre la perte totale de la confidentialité des messages, présents et futurs. Si la PFS est par exemple fournie au-dessus d'un protocole tel que Jabber (qui fournit le chiffrement entre le client et le serveur seulement), la compromission du serveur offre alors une attaque efficace contre la PFS.

En plus de cet aspect important, il convient de rappeler que la PFS repose sur des primitives cryptographiques qui pourront un jour être rendues obsolètes par l'arrivée de puissances de calcul plus grandes (telles celles promises par l'informatique quantique) ou tout simplement, car une solution au problème a été trouvée (décomposition en facteurs premiers et calcul du logarithme discret en un temps raisonnable). On pourra également mentionner l'usage de paramètres dégradés pour Diffie-Hellman ou de nouveaux types d'attaque concernant la cryptographie à base de courbe elliptique.

Enfin, en termes d'implémentation dans des applications pour la vie de tous les jours, la confidentialité persistante reste difficile à utiliser avec plus de deux entités comme un canal de discussion public, ainsi que dans un contexte de communication asynchrone (tel le courrier électronique). Ces derniers problèmes seront détaillés par des exemples pratiques dans la suite de l'article.

2.4 Quelques exemples concrets

Pour le cas déjà cité de HTTPS avec l'utilisation des primitives ECDHE ou DHE, relevons que Google propose l'usage de ces primitives depuis fin 2011 et Twitter depuis fin 2013, et que selon le projet SSL Pulse, qui établit des statistiques sur 200 000 sites utilisant SSL/TLS, environ 50 % d'entre eux permettent l'usage de primitives offrant la PFS. De nombreux autres protocoles font de même, tels que SSH, IPSec ou encore WPA2. Aussi quelques protocoles ont-ils été entièrem