Chiffrement de bout en bout sans compromis

Note : Cet article décrit l’architecture et la conception de Mandraki. Certaines fonctionnalités discutées sont déployées progressivement et peuvent ne pas encore être disponibles dans tous les plans.

Le chiffrement de bout en bout est l’une de ces fonctionnalités qui est facile à promettre et difficile à livrer correctement. De nombreuses plateformes de collaboration prétendent offrir E2EE, mais les détails de leurs implémentations varient énormément — et les détails sont où la sécurité vit ou meurt.

Cet article explique comment Mandraki met en œuvre le chiffrement de bout en bout, les choix de protocoles que nous avons faits et les compromis sur lesquels nous sommes transparents.

Ce que le chiffrement de bout en bout signifie réellement

Dans un système avec chiffrement de bout en bout, les messages et les médias sont chiffrés sur l’appareil de l’expéditeur et ne peuvent être déchiffrés que sur les appareils des destinataires. Le serveur qui relaie les données ne voit que le texte chiffré. Il ne peut pas lire le contenu, même s’il est contraint par un jugement, un employé malveillant ou une violation de sécurité.

C’est fondamentalement différent du chiffrement de transport (TLS), qui protège les données en transit entre un client et un serveur mais laisse le serveur avec accès au texte clair. C’est aussi différent du chiffrement au repos, qui protège les données sur disque mais laisse la couche application avec accès au texte clair lors du traitement.

Le vrai E2EE signifie que le serveur n’est pas fiable par conception. C’est un relais, pas un lecteur.

Le protocole MLS pour la messagerie

Pour la messagerie chiffrée, nous utilisons le protocole de sécurité de la couche de messagerie (MLS), standardisé en tant que RFC 9420 par l’IETF. MLS a été conçu spécifiquement pour les scénarios de messagerie de groupe et offre plusieurs avantages par rapport aux approches plus anciennes.

MLS utilise une structure d’accord de clé basée sur les arbres appelée TreeKEM, qui permet à un groupe de participants d’établir un secret partagé efficacement. Quand un membre rejoint ou quitte un groupe, le matériel de clé est mis à jour via un message Commit qui fait avancer l’époque du groupe. Cela fournit le secret de succession — compromettre les clés d’un membre à un moment dans le temps ne révèle pas les messages d’époque antérieures — et la sécurité post-compromis — le groupe récupère la sécurité après un compromis dès que le matériel de clé du membre affecté est pivoté.

Chaque appareil d’utilisateur télécharge des paquets de clés à usage unique à destination du serveur. Ce sont des ensembles cryptographiques uniques qui permettent aux autres appareils de les ajouter à un groupe sans nécessiter que l’appareil soit en ligne à ce moment-là. Quand un paquet de clé est consommé, l’appareil doit télécharger des nouveaux. Le serveur stocke et distribue ces paquets mais n’a jamais accès au matériel de clé privée qu’ils contiennent.

Les groupes MLS dans Mandraki se mappent sur les canaux et les fils de messages directs. Quand vous envoyez un message dans un canal chiffré, votre client le chiffre en utilisant la clé de l’époque actuelle du groupe. Le serveur reçoit le texte chiffré, le stocke et le distribue aux membres du groupe. Leurs clients le déchiffrent localement.

SFrame pour le chiffrement des médias

Le chiffrement des médias en temps réel — audio et vidéo dans un appel de groupe — présente des défis différents de la messagerie. La tolérance de latence se mesure en millisecondes, pas en secondes. Les débits de données sont des ordres de magnitude plus élevés. Et les médias passent via une unité de routage sélectif (SFU), qui doit acheminer les paquets aux participants appropriés sans pouvoir voir le contenu.

Nous utilisons SFrame (RFC 9605) pour le chiffrement des médias, appliqué via l’API WebRTC Encoded Transform. Cette API permet au code JavaScript d’intercepter les trames médias encodées après l’encodage mais avant la packetisation, de les chiffrer et de passer le texte chiffré à la couche de transport. À l’extrémité réceptrice, les trames sont déchiffrées après le réassemblage mais avant le décodage.

L’avantage clé de SFrame dans une architecture SFU est que le SFU peut toujours effectuer sa fonction de routage — transmettre les paquets d’un participant aux autres, prendre des décisions adaptables à la bande passante sur quelles couches transmettre — sans jamais avoir accès aux médias en texte clair. Le SFU voit les trames chiffrées et les transmet comme des blobs opaques.

Les compromis dont nous sommes honnêtes

Le chiffrement de bout en bout n’est pas gratuit. Il introduit des contraintes réelles que nous croyons mériter d’être reconnues.

La recherche côté serveur n’est pas possible sur le contenu E2EE. Si les messages sont chiffrés avec des clés que le serveur ne détient pas, le serveur ne peut pas les indexer pour la recherche. Mandraki y remédie en maintenant un indice de recherche chiffré local sur le client en utilisant IndexedDB. Cela fournit la recherche par appareil mais ne supporte pas la recherche d’historique multi-appareil pour les messages reçus avant qu’un appareil soit ajouté au groupe.

Les fonctionnalités IA côté serveur s’excluent mutuellement avec E2EE. Nos fonctionnalités de transcription et de résumé IA nécessitent l’accès côté serveur à l’audio en texte clair. Un appel ou un canal ne peut pas avoir à la fois E2EE et les fonctionnalités IA activées simultanément. C’est appliqué architecturalement, pas seulement par politique. Les organisations choisissent au niveau de l’appel ou du canal quel modèle elles préfèrent.

Les nouveaux appareils voient les messages seulement du point de jonction en avant. Quand vous ajoutez un nouvel appareil à votre compte, il peut déchiffrer les messages à partir du moment où il rejoint le groupe MLS en avant. Les messages historiques chiffrés sous les époque antérieures ne sont pas accessibles sur le nouvel appareil. C’est une propriété fondamentale du secret de succession. Nous explorons les mécanismes de sauvegarde sécurisée qui permettraient aux utilisateurs d’exporter l’historique des messages chiffrés vers un nouvel appareil, mais cela reste un travail en cours.

La gestion des clés ajoute la complexité. Chaque appareil doit maintenir le matériel de clé, télécharger les paquets de clés frais et traiter les mises à jour d’état du groupe. Nous investissons un effort d’ingénierie significatif pour rendre cela invisible aux utilisateurs. L’objectif est que le chiffrement ne soit pas quelque chose que vous configurez ou dont vous pensez — cela se produit simplement.

E2EE et le chiffrement côté serveur coexistent

Il vaut la peine de noter que la couche E2EE de Mandraki et notre chiffrement d’enveloppe côté serveur (la hiérarchie de clés trois couches décrite dans notre architecture de sécurité) servent des purposes complémentaires. Le chiffrement côté serveur protège les données au repos sur notre infrastructure — si un disque est volé ou une sauvegarde de base de données est compromised, les données sont illisibles sans les clés de chiffrement. E2EE va plus loin en s’assurant que le serveur ne voit jamais du texte clair en premier lieu.

Pour les organisations qui activent E2EE, les deux couches sont actives simultanément. Les données sont chiffrées de bout en bout par les clients et aussi chiffrées au repos sur le serveur. Ceinture et bretelles.

Nous croyons que le chiffrement de bout en bout devrait être l’option par défaut pour les communications sensibles, pas un ajout premium ou une case à cocher que la plupart des utilisateurs ne trouvent jamais. Mandraki le rend simple à activer, transparent dans ses limitations et robuste dans son implémentation.