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

Les fichiers sont chiffrés dans le navigateur avant l'envoi. Une clé AES-256 aléatoire est générée par fichier via l'API Web Crypto, et le contenu est chiffré avec AES-256-GCM. La clé est exportée en fragment base64url dans l'URL de partage. Le fragment n'étant jamais inclus dans les requêtes HTTP, le serveur ne la reçoit jamais.

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 à 30 jours selon la gamme) 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 :en mode E2E, le serveur ne détient que du ciphertext qu'il ne peut pas déchiffrer. Les secrets texte non-E2E sont chiffrés côté serveur ; le texte en clair n'est jamais stocké.
• Purge automatique : les partages expirés sont supprimés définitivement (ciphertext et métadonnées), sans récupération possible.
• Antivirus :les fichiers non chiffrés, dans les limites d'analyse, sont contrôlés par ClamAV avant mise à disposition. Le contenu chiffré de bout en bout n'est jamais analysable, le serveur ne détenant que du ciphertext.
• Hébergement :France exclusivement. 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 à 30 jours selon la gamme, 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.