Le chiffrement de bout en bout : c’est quoi ?
Découvrez l’algorithme au coeur des messageries instantanées Whatsapp et Telegram, mais aussi les technologies Apple.
Pourquoi ?
En effet, c’est bien la question à se poser. Voici comment nous en sommes venu là.
HTTP : échange de données
Les données en HTTP transitent en clair.
Par exemple :
HTTPS : échange de données sur un canal sécurisé
Le HTTPS est une variante du HTTP incluant l’utilisation d’un canal de communication sécurisé.
Ce procédé est assez fiable, du moment que l’on est prêt à donner sa confiance à un tiers. Une confiance qui a bien diminuée notamment depuis l’affaire Snowden.
Sans parler des différents procédés de piratage qui permettent de contourner la sécurité HTTPS. (dans certaines conditions : ce n’est pas à la portée de tout le monde)
Chiffrement de bout en bout : de la sécurité dans la sécurité
L’idée est simple : les données qui transitent en HTTPS apparaissent en clair si la sécurité HTTPS est rompue.
Comment améliorer ce procédé ? En sécurisant les données elle-même et en ne les rendant déchiffrable que par les personnes échangeant les messages.
Comment cela peut-il fonctionner ? C’est tout le sujet du présent article.
La sécurité des données : un jeu de clés
Bien souvent, pour sécuriser des données, on doit utiliser un jeu de clé asymétriques :
- une clé publique (chiffrement)
- une clé privée (déchiffrement).
La clé privée est générée aléatoirement.
La clé publique est générée à partir de la clé privée.
Bob et Alice : exemple simple
Le récepteur du message (Alice) génère une clé privée (A) et une clé publique (B).
Le récepteur du message (Alice) envoie sa clé publique (B) à un émetteur (Bob).
L’émetteur (Bob) chiffre son message avec la clé publique (B) du récepteur (Alice).
Le récepteur (Alice) déchiffre le message de l’émetteur (Bob) grâce à sa clé privée (A).
Seul le récepteur (Alice) pourra prendre connaissance des messages de l’émetteur (Bob).
Il suffit que l’émetteur (Bob) applique le même procédé que le récepteur (Alice) et cet échange de clés publiques leur permet une communication bi-directionnelle sécurisée.
Fonction de hachage
L’idée de la fonction de hachage est de permettre d’obtenir une signature numérique unique concernant un ensemble de données.
L’idée est d’identifier très rapidement la donnée, sans l’avoir de manière complète. Un hachage est souvent représenté par un ensemble de caractères.
Imaginons l’envoi d’un fichier par email. J’effectue, grâce à un algorithme (SHA-256 par exemple), le hachage de ce fichier qui me donne “12bg” pour l’exemple. Je joins à mon email le hachage du fichier en plus du fichier. Le récepteur de l’email pourra vérifier que le fichier est bien arrivé en son intégrité en appliquant lui-même le hachage du fichier reçu. Si la valeur retournée est autre que “12bg”, cela signifie que le fichier est corrompu.
Hachage à partir de clés privées et clés publiques
Imaginons qu’un message soit envoyé d’un émetteur (Alice) à un récepteur (Bob).
Avec son message chiffré, l’émetteur (Alice) joint le hachage du message (“1234”) généré à partir de la clé privée.
Le récepteur (Bob) pourra utiliser la clé publique de l’émetteur (Alice) afin de vérifier le hachage du message reçu (“1234”). Si le hachage est identique, cela signifie que l’émetteur est bien celui qu’il prétend être.
Le problème
Dans le cas du HTTPS, les clés privées et publiques sont échangées en clair et sont gérées par des tiers.
Cela fait une personne de trop dans l’équation pour une confidentialité optimale.
ECDH : échanges de clés Diffie-Hellman
Ce protocole repose sur un algorithme mathématique assez complexe, mais dont l’usage est plutôt simple à comprendre.
Il s’appuie sur la courbe elliptique Curve25519, découverte en 2005 par Daniel J. Bernstein.
Bob et Alice sont espionnés
Le seul moyen pour Alice et Bob est de passer par un tiers qui n’est pas vraiment de confiance. Ils doivent donc ruser pour échanger leurs messages de manière sécurisée.
Alice génère une clé privée (pA) et une clé publique (PA) reposant sur un algorithme à base de courbe elliptique Curve25519.
Bob génère une clé privée (pB) et une clé publique (PB) reposant sur le même procédé.
Alice envoie sa clé publique (PA) à Bob.
Bob envoie sa clé publique (PB) à Alice.
C’est là que ECDH entre en scène.
À partir de sa clé privée (pA) et de la clé publique de Bob (PB), Alice va utiliser ECDH pour générer un secret (sA).
À partir de sa clé privée (pB) et de la clé publique de Alice (PA), Bob va utiliser ECDH pour générer un secret (sB).
Et c’est là que la magie mathématique opère : sA et sB sont identiques !
Personne d’autre que Alice et Bob ne connait ce secret partagé car personne d’autre n’a de clé privée.
Utilisation des secrets partagées
Ce secret partagé est utilisé pour chiffrer les messages, par le biais de fonctions de hachage.
Cas d’usage
Ces procédés sont utilisés dans de nombreux cas.
À l’installation, l’application génère un couple de clés : les clés d’identité.
Des clés intermédiaires sont générées à partir des clés d’identité et sont actualisées à intervalles réguliers.
Un ensemble de clés à usage unique est généré à l’installation et est renouvelé au besoin.
Une clé de session racine de 32 octets est également crée.
Elle permet de créer une clé intermédiaire de 32 octets.
Cette clé intermédaire permet de générer une dernière clé de session : la clé de message qui fait 80 octets et permet de chiffrer les messages. Pour faire simple, ces 80 octets réunissent l’ensemble des éléments nécessaires à chiffrer un message sécurisé. Ils sont condensés par commodité.
Les clés publiques (et uniquement les clés publiques, avec signature) de l’utilisateur sont envoyées aux serveurs WhatsApp à l’enregistrement de l’appareil sur la plateforme.
Avant d’initier une communication, une session chiffrée doit être initiée.
L’initiateur de la communication (Alice) demande au récepteur (Bob) ses clés publiques ainsi qu’une clé à usage unique.
La clé à usage unique est renvoyée une seule fois par le serveur et supprimée aussitôt. Jamais le serveur n’enverra deux fois de suite la même clé à usage unique.
L’initiateur de la communication (Alice) sauvegarde les clés du récepteur (Bob) et génère grâce à ECDH des secrets partagées.
Une clé maître est ensuite générée à partir des secrets partagés.
L’initiateur (Alice) se sert de cette clé maître et de l’algorithme de dérivation HKDF pour générer une clé racine et des clés intermédiaires.
À partir de là, l’initiateur (Alice) peut directement envoyer des messages. Jusqu’à ce que le récepteur (Bob) réponde, l’initiateur envoie en en-tête du message les informations qui permettent d’établir une session.
Pour déchiffrer les données, le récepteur (Bob) n’a qu’à opérer de manière inverse pour retrouver la clé maître et les clés intermédiaires.
Chaque message est chiffré grâce à une clé de message. Cette clé de message change à chaque message.
En gros, la clé de message est calculée à partir de la clé intermédiaire. Clé intermédiaire qui est elle-même régulièrement actualisée par un autre procédé.
En gros, le risque se situe dans la phase d’initialisation de la communication. Car ensuite, seuls les deux interlocuteurs connaissent les clés de chiffrement de la communication.
Clés qui varient énormément à chaque échange de message, ce qui rend la communication quasiment impossible à décoder.
Les clés peuvent également être validées en vis-à-vis par QRCode, pour être vraiment sûr que personne ne s’est interposé dans la discussion.
Au final, WhatsApp ne peut pas espionner les échanges car les clés privées sont stockées sur les appareils.
La documentation complète est disponible en ligne.
Apple
Au-delà de l’aspect design et qualité, le “fond de commerce” d’Apple est la protection des informations personnelles.
Une page complète est d’ailleurs dédiée à ce sujet sur le site du constructeur.
Les conversations iMessage et FaceTime sont chiffrées de bout en bout. Certaines données sont stockées sur iCloud en utilisant le même procédé.
Le chiffrement de bout en bout d’Apple fonctionne, dans les grandes lignes, de manière similaire. Le canal de communication est par contre sécurisé directement par l’OS et si possible par un chiffrement matériel.
La documentation officielle sur la sécurité Apple détaille bien le procédé.
De l’importance du respect de la vie privée
Ces outils sont mis à disposition afin de renforcer le respect de la vie privée de chacun.
D’autres outils sont également mis en place afin de vous assurer que votre vie privée vous appartiennent.
À l’ère des assistants vocaux et des enceintes intelligentes, c’est un sujet majeur.
Sujet au coeur de la GDPR, qui entre en vigueur fin mai de cette année.
Parmi les solutions les plus efficaces, la confidentialité différentielle permet l’utilisation de données de masse sans avoir à empiéter sur la vie privée.
Mais ceci est un autre sujet. 🙂
