Chiffrement bout en bout pour collaboration multi-utilisateurs

Une application collaborative chiffrée ne se réduit pas à chiffrer chaque message pour chaque destinataire. Dès qu’un groupe change, qu’un appareil est ajouté ou qu’un document est partagé hors ligne, la gestion des clés devient le produit. Le compromis central est brutal : obtenir une confidentialité durable face au serveur impose de distribuer, versionner et révoquer un état cryptographique par groupe.

→ Lire l’explication complète de la marmotte

Modèle de groupe et compromis de l’E2EE collaborative

Le chiffrement de bout en bout, ou E2EE (End-to-End Encryption), protège le contenu entre les appareils des membres. Le serveur transporte les opérations, conserve des blobs chiffrés et orchestre la synchronisation, mais ne possède pas les clés de déchiffrement. Cette frontière doit être nette : un serveur qui peut rejouer une clé de contenu ou injecter un appareil est un participant déguisé en infrastructure.

Pour une collaboration asynchrone, le choix à privilégier est Messaging Layer Security, ou MLS. MLS définit un protocole de groupe avec renouvellement de clés à chaque changement de membres, confidentialité des messages passés pour les nouveaux arrivants et confidentialité des messages futurs pour les membres retirés. Il ne faut pas reconstruire ce mécanisme avec une boucle for qui chiffre la même clé pour chaque utilisateur. Cette approche fonctionne jusqu’au premier ajout concurrent, puis transforme la révocation en art contemporain.

MLS repose sur un arbre de clés. Chaque membre détient une partie de cet arbre ; une modification de groupe produit une nouvelle époque cryptographique. Un message chiffré dans une époque ne doit être accepté que si son contexte de groupe, son numéro d’époque et son expéditeur correspondent à l’état validé localement. Accepter silencieusement un message d’une ancienne époque après une exclusion réintroduit précisément l’accès que la révocation devait retirer.

Le bon périmètre de groupe correspond à une frontière d’autorisation stable : une conversation, un dossier partagé ou un espace de travail dont les membres accèdent au même corpus. Un groupe par organisation crée des rotations gigantesques et augmente le rayon d’exposition. Un groupe par document multiplie les états, les invitations et les échecs de synchronisation. Le choix dépend de la fréquence des changements d’accès : l’unité doit contenir des membres qui changent ensemble, pas des données qui ont vaguement le même logo.

L’architecture gagne en confidentialité contre le serveur et contre une fuite de base de données. Elle paie ce gain par des états locaux persistants, des transitions concurrentes, des procédures de récupération d’appareil et une disponibilité dépendante de la distribution des mises à jour de groupe. Le chiffrement ne rend pas la collaboration gratuite, il déplace son coût là où les slides commerciales évitent soigneusement de regarder.

Identités d’appareil, annuaire et transparence des clés

Une identité utilisateur ne suffit pas. Chaque appareil possède une clé de signature d’identité et une clé d’accord de secret, protégées par le stockage matériel disponible sur la plateforme. L’inscription d’un appareil doit produire une preuve vérifiable par les autres appareils déjà approuvés, ou être validée par une procédure d’enrôlement forte. Une authentification fédérée réussie ne prouve pas, à elle seule, que la clé fournie par l’annuaire appartient au bon appareil.

L’annuaire publie les paquets de clés nécessaires à l’ajout asynchrone d’un membre. Il devient donc une cible de substitution : un serveur malveillant peut présenter une clé d’attaquant à un groupe et lire les futurs contenus sans casser l’algorithme. La parade est une transparence de clés append-only, avec preuves d’inclusion et de cohérence vérifiées côté client. Chaque appareil doit détecter qu’une identité a reçu deux versions incompatibles de son jeu de clés.

Les clés d’identité doivent être liées à un compte via une attestation d’enrôlement ou un certificat signé par une autorité interne. Cette autorité ne doit signer que l’identité et l’état d’autorisation, jamais une clé permettant de déchiffrer le contenu. Un HSM (Hardware Security Module) peut protéger la clé de signature de l’annuaire ou de l’autorité, mais ne transforme pas le serveur en coffre-fort pour les secrets utilisateurs. Un HSM protège une opération de signature ; il ne chasse pas les appareils compromis à coups de marteau.

Les changements d’identité et d’appareil exigent une validation visible : comparaison de code de sécurité, approbation depuis un appareil existant ou récupération par plusieurs facteurs indépendants. Une réinitialisation de compte qui remplace toutes les clés sans avertissement est une porte dérobée administrative avec un formulaire de support devant.

Les mécanismes de fédération, les certificats et leur durée de vie relèvent de la même discipline que la gestion des identités et la PKI TLS. La différence est structurelle : dans une architecture E2EE, l’infrastructure authentifie les identités sans obtenir le contenu qu’elles protègent.

Époques MLS, révocation et conflits de collaboration

Un ajout, un retrait ou une mise à jour de clé d’appareil produit une opération de commit MLS. Tous les clients doivent valider cette opération, vérifier sa signature et avancer vers la nouvelle époque avant d’accepter les nouveaux messages. Deux commits concurrents nécessitent une résolution déterministe selon les règles du protocole ; inventer une priorité applicative au-dessus de MLS est une manière rapide de produire des groupes qui divergent sans bruit.

La révocation protège l’avenir, pas le passé déjà reçu. Un membre exclu peut conserver les documents déchiffrés, exporter les pièces jointes et garder les clés des époques précédentes. Aucune primitive ne rappelle un octet déjà affiché sur un appareil légitime. Pour des données à durée de vie courte, il faut ajouter une expiration applicative, un contrôle d’accès local et, si nécessaire, une politique de non-export. Ce dernier point dépend du système d’exploitation et du poste, pas de MLS.

Les pièces jointes ne doivent pas être chiffrées directement avec la clé de groupe. Générer une clé de données unique par objet, chiffrer l’objet avec AES-GCM (Advanced Encryption Standard Galois/Counter Mode), puis chiffrer cette clé de données dans un message MLS. La clé de données ne doit jamais être réutilisée pour deux objets. L’IV (Initialization Vector) AES-GCM doit être unique pour chaque chiffrement sous une même clé, sans exception décorative pour le fichier de profil.

Les opérations collaboratives, par exemple les éditions concurrentes d’un document, doivent être authentifiées et chiffrées avant leur diffusion. Le serveur peut ordonner, retarder ou supprimer ces opérations. Il ne doit pas pouvoir en fabriquer une valide. Pour les modèles de données de type CRDT (Conflict-free Replicated Data Type), la signature ou l’authentification du lot d’opérations doit couvrir l’identifiant du document, l’époque du groupe, le compteur de l’émetteur et le contenu sérialisé. Sinon, une opération légitime peut être rejouée dans un autre document.

Une architecture local-first convient particulièrement : persister le journal chiffré localement, synchroniser les opérations opaques, puis réconcilier selon les règles du modèle métier. Le serveur devient disponible sans devenir confident. Ce n’est pas magique, seulement moins fragile qu’un serveur omniscient qui promet de ne jamais regarder.

Exemple reproductible de chiffrement d’une pièce jointe

Cet exemple chiffre un objet avec une clé de données aléatoire, puis chiffre cette clé pour transport dans le message de groupe. En production, l’enveloppe de clé doit être produite et consommée par la bibliothèque MLS retenue ; l’exemple montre la séparation indispensable entre contenu et contrôle de groupe.

# Installer la dépendance dans un environnement Python isolé.
python3 -m pip install cryptography

# Exécuter ensuite ce script : il génère un fichier chiffré et son enveloppe.
python3 - <<'PY'
import os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

plaintext = b"contenu collaboratif a synchroniser"
data_key = AESGCM.generate_key(bit_length=256)
content_nonce = os.urandom(12)

# Le contexte lie le chiffrement au document et à son époque MLS.
aad = b"document=42;epoch=17"
ciphertext = AESGCM(data_key).encrypt(content_nonce, plaintext, aad)

# Cette clé représente la clé de secret applicative dérivée de MLS pour l'époque 17.
# Elle ne doit jamais être réemployée pour une autre enveloppe.
group_wrap_key = AESGCM.generate_key(bit_length=256)
wrap_nonce = os.urandom(12)
wrapped_data_key = AESGCM(group_wrap_key).encrypt(wrap_nonce, data_key, aad)

open("document.bin", "wb").write(content_nonce + ciphertext)
open("document.key.envelope", "wb").write(wrap_nonce + wrapped_data_key)
PY

L’authentification associée, ici aad, doit être reconstruite exactement à la lecture. Modifier l’identifiant du document, l’époque ou le contenu provoque un échec de déchiffrement. Cet échec doit être traité comme un incident de synchronisation ou d’intégrité, jamais comme une invitation à retirer les vérifications parce que « le fichier est pourtant là ».

Exploitation, sauvegarde et limites non négociables

Les états MLS, les clés d’identité et les compteurs de réception sont des données critiques. Une restauration incohérente peut ramener un appareil à une ancienne époque, faire rejouer des messages ou rendre un groupe irrécupérable. La sauvegarde doit chiffrer séparément l’état de chaque appareil avec une clé de récupération protégée par un secret utilisateur fort ou par plusieurs approbateurs. Sauvegarder les clés dans le compte cloud en clair logique revient à demander au serveur E2EE de garder un double des clés, ce qui est une interprétation créative du mot « bout ».

La rotation couvre quatre objets distincts : clés d’identité d’appareil, paquets de clés publiés, secrets de groupe à chaque commit et clés de récupération. Une rotation d’identité exige une approbation ; une rotation de groupe découle des changements de membres ; une rotation de récupération doit invalider les anciens artefacts sauvegardés. Un KEK (Key Encryption Key) d’infrastructure peut protéger les sauvegardes serveur, mais ne doit pas devenir une clé universelle de récupération du contenu utilisateur.

La supervision ne doit jamais journaliser de texte déchiffré, de clés, de nonces complets ou de paquets de clés privés. Mesurer plutôt les échecs de validation de commit, les preuves de transparence refusées, les appareils bloqués sur une époque, l’âge des paquets de clés et le taux d’échec de restauration. Les pratiques de supervision restent valables, avec une différence : le diagnostic doit survivre sans aspirer le secret dans les logs.

L’E2EE ne protège ni un appareil compromis, ni une capture d’écran, ni les métadonnées réseau, ni un utilisateur autorisé malveillant. Il ne garantit pas non plus la disponibilité : le serveur peut censurer une opération ou isoler un sous-groupe. Il faut donc des journaux d’audit signés, des mécanismes de détection de fork, des alertes de retard de synchronisation et une gouvernance d’accès distincte de la cryptographie. La clé protège le contenu ; elle n’écrit pas la politique, ne recolle pas les conflits et ne répare pas un terminal infecté.

🐝 Ce qui arrive si on s’en passe

Sans chiffrement de bout en bout, le contenu collaboratif est lisible par le serveur ou par une clé qu’il détient ; chaque copie technique devient alors une copie lisible : réplicas de base, sauvegardes, index de recherche, caches, vidages mémoire après plantage, traitements confiés à des sous-traitants (antivirus, aperçus, analyse). Un seul identifiant d’administration compromis, ou une réquisition adressée à l’hébergeur, donne accès à l’historique complet de tous les groupes, et pas seulement aux échanges futurs. Le retrait d’un membre ne repose plus que sur une règle de contrôle d’accès : une erreur de configuration ou une régression applicative rouvre l’accès à tout le corpus, sans qu’aucune vérification côté client ne le signale. La suppression d’un document exige enfin de purger chaque copie en clair, ce que les sauvegardes rendent rarement vérifiable.

🦫 Explication de la marmotte 🍫

Chaque personne utilise un ou plusieurs appareils. Chaque appareil possède ses propres secrets, stockés localement, et une preuve permettant aux autres de reconnaître son identité. Quand un espace de travail est créé, les appareils autorisés calculent un secret de groupe. Ce secret change quand une personne ou un appareil arrive, part ou remplace ses clés.

Pour envoyer une modification de document, l’application chiffre d’abord la modification sur l’appareil qui l’émet. Le serveur reçoit seulement une version illisible. Il peut la conserver et la transmettre aux autres appareils, mais il ne possède pas le secret nécessaire pour lire le contenu. Les appareils qui font encore partie du groupe utilisent leur état local pour vérifier que la modification vient bien d’un membre autorisé, puis la déchiffrent.

Une pièce jointe reçoit son propre secret de chiffrement. Ce secret est lui-même protégé pour le groupe, ce qui évite de chiffrer tout le fichier séparément pour chaque personne. Si un membre est exclu, le groupe crée un nouveau secret. Cette personne ne peut plus lire les nouvelles modifications, mais peut garder les données déjà lues.

Si le serveur essaie de remplacer une identité ou de présenter des versions différentes du groupe, les appareils doivent détecter cette incohérence grâce à des preuves vérifiables. Si un appareil perd ses secrets sans sauvegarde protégée, il ne peut plus relire certains contenus. Si un appareil est piraté, le chiffrement ne peut pas empêcher le pirate de lire ce que cet appareil peut déjà afficher.

Pages voisines

La citent

Chiffrement bout en bout pour collaboration multi-utilisateurs

Elle cite

: les deux pages se citent l’une l’autre.

Chiffrement bout en bout pour collaboration multi-utilisateurs

Chiffrement bout en bout pour collaboration multi-utilisateurs

Modèle de groupe et compromis de l’E2EE collaborative

Identités d’appareil, annuaire et transparence des clés

Époques MLS, révocation et conflits de collaboration

Exemple reproductible de chiffrement d’une pièce jointe

Exploitation, sauvegarde et limites non négociables

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines