Protocole de chiffrement

Ce document décrit le protocole de chiffrement de bout en bout (E2E) implémenté par Pli Scellé. Toutes les opérations cryptographiques utilisent l'API Web Crypto du W3C — aucune bibliothèque cryptographique externe n'est utilisée.

1. Primitives cryptographiques

2. Architecture Zero-Knowledge

En mode E2E, le serveur n'a jamais accès à la clé de chiffrement ni au contenu en clair. La clé est générée côté client et transmise exclusivement via le fragment URL (#key=...), qui n'est jamais envoyé au serveur par le navigateur (RFC 3986 §3.5).

Conséquence : même avec un accès complet à la base de données et au stockage, un attaquant ne peut pas déchiffrer les partages E2E sans la clé détenue exclusivement par l'expéditeur et le destinataire.

3. Chiffrement des fichiers (streaming par chunks)

Les fichiers volumineux sont chiffrés en streaming via un Web Worker dédié pour ne pas bloquer le thread principal et minimiser l'empreinte mémoire.

Processus

1. Une clé AES-256 aléatoire est générée via Web Crypto API
2. Le fichier est découpé en chunks de taille fixe pour un chiffrement en streaming
3. Un IV de 96 bits aléatoire est généré une fois par fichier
4. Chaque chunk reçoit un IV dérivé unique pour garantir l'absence de réutilisation d'IV
5. Chaque chunk est chiffré indépendamment avec AES-256-GCM
6. Le résultat utilise un format binaire versionné pour la compatibilité ascendante

Transport de la clé

La clé est exportée en base64url et ajoutée à l'URL de partage en tant que fragment. Le fragment n'étant jamais inclus dans les requêtes HTTP, le serveur ne peut pas intercepter la clé pendant le transport.

4. Chiffrement des secrets (mots de passe et texte)

1. Un salt aléatoire cryptographique est généré
2. La clé de chiffrement est dérivée du mot de passe d'accès via PBKDF2-SHA-256 avec 600 000 itérations
3. Le texte est chiffré avec AES-256-GCM en utilisant un IV de 96 bits aléatoire
4. Le serveur stocke uniquement le ciphertext, l'IV et le salt — jamais le texte en clair ni la clé

Déchiffrement par le destinataire : le destinataire saisit le mot de passe d'accès → la clé est re-dérivée à partir du mot de passe + salt → le secret est déchiffré entièrement côté client.

5. Cycle de vie d'un partage

1. Création : l'expéditeur chiffre le contenu dans le navigateur, envoie le ciphertext, reçoit une URL unique avec la clé dans le fragment
2. Partage : l'URL est transmise hors-bande (email, messagerie, etc.)
3. Accès : le destinataire ouvre l'URL → le navigateur extrait la clé du fragment → télécharge le ciphertext → déchiffre localement
4. Expiration : après la durée configurée (1 heure à 7 jours) ou le nombre maximum de vues, le partage est purgé définitivement — ciphertext supprimé du stockage, métadonnées effacées de la base de données
5. Révocation : l'expéditeur peut détruire un partage à tout moment depuis son tableau de bord

6. Sécurité du transport

• TLS 1.2+ obligatoire sur toutes les communications client-serveur (HSTS preload)
• Tokens d'accès : aléatoires cryptographiquement, générés côté serveur avec une entropie élevée
• Tokens de téléchargement : éphémères à courte durée de vie, vérifiés via comparaison à temps constant pour prévenir les attaques temporelles
• Rate limiting : limitation sur tous les endpoints publics pour atténuer les attaques par force brute et les abus

7. Stockage et rétention

• Au repos : tous les fichiers sont chiffrés au repos via un chiffrement au niveau du stockage. En mode E2E, une couche supplémentaire de chiffrement côté client garantit que le serveur ne détient que du ciphertext qu'il ne peut pas déchiffrer. Les secrets texte sont toujours chiffrés au repos (côté client en mode E2E, côté serveur sinon)
• Purge automatique : un processus en tâche de fond supprime définitivement les partages expirés (ciphertext + métadonnées) sans possibilité de récupération
• Antivirus : tous les fichiers uploadés accessibles par le serveur sont analysés par ClamAV avant d'être rendus disponibles. En mode E2E, l'analyse du contenu n'est pas possible puisque le serveur ne détient que du ciphertext
• Hébergement : France exclusivement (datacenters en France métropolitaine). Aucun transfert hors de l'Union Européenne

8. Résistance aux attaques quantiques

Le chiffrement de Pli Scellé repose sur AES-256-GCM (symétrique) et PBKDF2-SHA-256 (dérivation de clé). Ces algorithmes sont considérés résistants aux attaques quantiques : l'algorithme de Grover réduit la sécurité effective d'AES-256 à ~AES-128, un niveau toujours considéré sûr par le NIST et l'ANSSI.

Le flux de partage actuel n'utilise pas d'échange de clé asymétrique (RSA, ECDH) — les algorithmes vulnérables aux attaques quantiques ne sont pas présents dans le protocole.

Pour les futures fonctionnalités nécessitant un échange asymétrique, l'architecture est conçue pour intégrer ML-KEM (Kyber, FIPS 203) en mode hybride (classique + post-quantique) lorsque les standards navigateur (Web Crypto API) et les bibliothèques auditées seront disponibles.

Les partages sur Pli Scellé sont éphémères (expiration de 1 heure à 7 jours, purge automatique). Le scénario « stocker maintenant, déchiffrer plus tard » — où un attaquant capture le ciphertext aujourd'hui et le déchiffre dans 10–20 ans avec un ordinateur quantique — ne s'applique pas aux données éphémères qui n'existent plus.

9. Transparence et posture sécurité

• Mode non-E2E : les partages créés sans E2E utilisent le chiffrement côté serveur. Le serveur peut déchiffrer ces partages. Le mode E2E est recommandé pour une confidentialité maximale.
• Modèle de confiance navigateur : comme pour tout chiffrement E2E basé sur le web, la sécurité dépend de l'intégrité du code livré au navigateur. Nous atténuons ce risque avec des en-têtes Content Security Policy stricts, le Subresource Integrity, et des évaluations de sécurité régulières.
• Gestion du fragment URL : bien que le fragment ne soit pas transmis au serveur, il peut apparaître dans l'historique du navigateur ou être partagé par inadvertance. Nous recommandons d'utiliser des partages protégés par mot de passe pour les contenus sensibles.