Livre Blanc Sécurité SeraVault

Architecture Technique & Implémentation Cryptographique Post-Quantique

Version: 1.0 Date: Novembre 2025 Statut: Production

1. Résumé

SeraVault est une plateforme de stockage de fichiers et de messagerie chiffrée de bout en bout à connaissance nulle, conçue pour résister aux attaques des ordinateurs classiques et quantiques. Le système utilise ML-KEM-768 (NIST FIPS 203), un mécanisme d'encapsulation de clés basé sur des réseaux standardisé par le NIST pour la cryptographie post-quantique, combiné avec AES-256-GCM pour le chiffrement symétrique.

Ce livre blanc fournit une description technique complète de l'architecture cryptographique de SeraVault, du modèle de sécurité et de l'implémentation. Nous détaillons notre conception à connaissance nulle, les protocoles de gestion des clés et les primitives cryptographiques post-quantiques.

Note: Ceci est un document évolutif. À mesure que les standards cryptographiques évoluent et que la recherche en sécurité progresse, nous mettrons à jour notre implémentation et cette documentation en conséquence. La version actuelle reflète le système de production à novembre 2025.

2. Modèle de Menace

2.1 Capacités de l'Adversaire

SeraVault est conçu pour protéger contre les adversaires suivants:

2.1.1 Compromission du Serveur

Nous supposons que l'infrastructure serveur peut être entièrement compromise. Un attaquant obtenant un accès complet à nos serveurs ne devrait pas être capable de déchiffrer les fichiers ou messages des utilisateurs. Ceci est réalisé grâce au chiffrement côté client où les clés de chiffrement n'atteignent jamais le serveur en clair.

2.1.2 Adversaire Réseau

Nous supposons qu'un adversaire peut intercepter, modifier ou injecter du trafic réseau entre clients et serveurs. TLS fournit une sécurité au niveau transport, mais notre chiffrement au niveau applicatif garantit que même la compromission TLS n'expose pas les données en clair.

2.1.3 Adversaire Quantique

Nous anticipons de futurs adversaires ayant accès à des ordinateurs quantiques cryptographiquement pertinents (CRQC). Les cryptosystèmes à clé publique traditionnels comme RSA et la cryptographie sur courbes elliptiques sont vulnérables à l'algorithme de Shor. SeraVault utilise ML-KEM-768, qui est basé sur la difficulté des problèmes de réseaux supposés résistants aux attaques quantiques.

2.1.4 Adversaire Étatique

Nous concevons contre des acteurs étatiques avec des ressources computationnelles significatives, la capacité de contraindre les fournisseurs de services et des capacités "Récolter Maintenant, Déchiffrer Plus Tard" où les données chiffrées sont stockées pour un déchiffrement futur quand les ordinateurs quantiques deviendront disponibles.

2.2 Hypothèses de Confiance

2.3 Hors Portée

Les menaces suivantes sont explicitement hors portée:

3. Architecture Système

3.1 Conception à Connaissance Nulle

SeraVault implémente une véritable architecture à connaissance nulle où le serveur n'a pas accès à:

Toutes les opérations de chiffrement et déchiffrement se produisent côté client dans le navigateur ou l'application de l'utilisateur. Le serveur stocke uniquement des données chiffrées et agit comme une couche de stockage et de synchronisation passive.

3.2 Vue d'Ensemble des Composants

3.2.1 Application Client

3.2.2 Backend Cloud

3.3 Flux de Données

Flux de Téléchargement de Fichier

  1. L'utilisateur sélectionne un fichier dans le navigateur
  2. Le client génère une clé symétrique aléatoire de 256 bits (Clé Fichier)
  3. Le client chiffre le contenu du fichier avec AES-256-GCM utilisant la Clé Fichier
  4. Le client chiffre les métadonnées du fichier (nom, taille, type) avec le Secret Partagé de l'utilisateur
  5. Le client encapsule la Clé Fichier pour la clé publique de l'utilisateur utilisant ML-KEM-768
  6. Le client télécharge le blob chiffré vers le stockage cloud
  7. Le client écrit les métadonnées chiffrées et la clé encapsulée dans la base de données backend

Flux de Téléchargement de Fichier

  1. Le client récupère les métadonnées chiffrées de la base de données backend
  2. Le client déchiffre les métadonnées utilisant le Secret Partagé de l'utilisateur
  3. Le client décapsule la Clé Fichier utilisant ML-KEM-768 avec la clé privée de l'utilisateur
  4. Le client télécharge le blob chiffré depuis le stockage cloud
  5. Le client déchiffre le contenu du fichier avec AES-256-GCM utilisant la Clé Fichier
  6. Le client présente le fichier en clair à l'utilisateur

4. Primitives Cryptographiques

4.1 ML-KEM-768 (NIST FIPS 203)

Mécanisme d'Encapsulation de Clés Basé sur les Réseaux Modulaires est notre primitive cryptographique post-quantique principale, standardisée par le NIST en août 2024 comme FIPS 203.

Paramètres

Paramètre Valeur
Niveau de Sécurité NIST Niveau 3 (équivalent à AES-192)
Taille Clé Publique 1 184 octets
Taille Clé Privée 2 400 octets
Taille Texte Chiffré 1 088 octets
Taille Secret Partagé 32 octets

Pourquoi ML-KEM-768?

4.2 AES-256-GCM

Advanced Encryption Standard avec clés 256 bits en mode Galois/Counter fournit le chiffrement authentifié pour le contenu des fichiers.

Propriétés

4.3 ChaCha20-Poly1305

ChaCha20-Poly1305 est un algorithme de chiffrement authentifié à haute vitesse utilisé pour protéger le matériel de clé sensible (comme votre clé privée) au repos.

4.4 Argon2id

Argon2id pour dériver des clés de chiffrement à partir de phrases secrètes utilisateur. Vainqueur du Password Hashing Competition (2015).

Pourquoi Argon2id: Argon2id nécessite beaucoup de mémoire, rendant les attaques GPU et ASIC coûteuses. Il combine les approches indépendantes des données (Argon2i) et dépendantes des données (Argon2d) pour la résistance aux canaux auxiliaires et une protection maximale contre les tentatives de craquage parallèles.

5. Protocole de Chiffrement de Fichiers

5.1 Génération de Clés

Lorsqu'un utilisateur crée son compte et génère ses clés de chiffrement :

// Générer une paire de clés ML-KEM-768 (cléPublique, cléPrivée) = ML-KEM-768.KeyGen() // Dériver une clé de chiffrement à partir de la phrase secrète sel = CSPRNG(32 octets) cléChiffrement = Argon2id(phraseSecrète, sel, t=3, m=64Mio, p=4, 32 octets) // Chiffrer la clé privée avec la clé dérivée de la phrase secrète nonce = CSPRNG(12 octets) cléPrivéeChiffrée = ChaCha20-Poly1305.Encrypt(cléChiffrement, nonce, cléPrivée) // Stocker la clé privée chiffrée dans la base de données backend // Clé publique stockée dans la base de données backend (en clair, elle est publique)

5.2 Chiffrement de Fichier

Pour chaque fichier téléchargé :

// 1. Générer une clé de chiffrement de fichier aléatoire cléFichier = CSPRNG(32 octets) // 2. Chiffrer le contenu du fichier nonce = CSPRNG(12 octets) contenuChiffré = AES-256-GCM.Encrypt(cléFichier, nonce, contenuFichier) // Le résultat inclut une étiquette d'authentification de 16 octets // 3. Encapsuler la clé de fichier pour le propriétaire (texteChiffré, secretPartagé) = ML-KEM-768.Encapsulate(cléPubliquePropriétaire) // Le secret partagé est utilisé pour chiffrer la clé de fichier nonceClé = CSPRNG(12 octets) cléFichierChiffrée = AES-256-GCM.Encrypt(secretPartagé, nonceClé, cléFichier) // 4. Chiffrer les métadonnées métadonnées = {nom, taille, type, dateEnvoi} nonceMétadonnées = CSPRNG(12 octets) métadonnéesChiffrées = AES-256-GCM.Encrypt(secretPartagéUtilisateur, nonceMétadonnées, métadonnées)

5.3 Déchiffrement de Fichier

// 1. Déchiffrer la clé privée avec la phrase secrète cléChiffrement = Argon2id(phraseSecrète, sel, t=3, m=64Mio, p=4, 32 octets) cléPrivée = ChaCha20-Poly1305.Decrypt(cléChiffrement, nonce, cléPrivéeChiffrée) // 2. Décapsuler pour récupérer le secret partagé secretPartagé = ML-KEM-768.Decapsulate(cléPrivée, texteChiffré) // 3. Déchiffrer la clé de fichier cléFichier = AES-256-GCM.Decrypt(secretPartagé, nonceClé, cléFichierChiffrée) // 4. Déchiffrer le contenu du fichier contenuFichier = AES-256-GCM.Decrypt(cléFichier, nonce, contenuChiffré) // 5. Déchiffrer les métadonnées métadonnées = AES-256-GCM.Decrypt(secretPartagéUtilisateur, nonceMétadonnées, métadonnéesChiffrées)

5.4 Chiffrement des Métadonnées

Contrairement à de nombreux systèmes de stockage chiffré, SeraVault chiffre les métadonnées de fichier incluant :

Cela empêche le serveur de construire un profil des modèles d'activité de l'utilisateur basé sur les noms ou types de fichiers.

Visibilité des Métadonnées : Bien que le contenu et les noms soient chiffrés, le serveur connaît toujours :
  • Tailles des blobs chiffrés (tailles approximatives des fichiers)
  • Horodatages de téléchargement/modification
  • Nombre de fichiers par utilisateur
  • Relations de partage (utilisateur A a partagé quelque chose avec utilisateur B)
Ceci est inhérent à tout système de stockage cloud et ne peut être complètement éliminé sans utiliser des techniques comme ORAM (Oblivious RAM), qui impacteraient gravement les performances.

6. Gestion des Clés

6.1 Hiérarchie des Clés Utilisateur

Chaque utilisateur possède plusieurs clés servant différents objectifs :

Type de Clé Objectif Stockage
Clé Publique ML-KEM-768 Encapsulation de clé de fichier (autres chiffrent pour vous) Base de données backend (en clair)
Clé Privée ML-KEM-768 Décapsulation de clé de fichier Base de données backend (chiffrée avec clé dérivée de phrase secrète)
Secret Partagé Chiffrement des métadonnées Dérivé de la paire de clés ML-KEM-768
Clé Dérivée de Phrase Secrète Chiffre la clé privée Dérivée à la demande, jamais stockée

6.2 Emplacements de Stockage des Clés

Important : SeraVault supporte plusieurs méthodes d'authentification simultanément. Les utilisateurs peuvent activer l'authentification par phrase secrète, par clé matérielle et par biométrie en même temps. Chaque méthode stocke une copie indépendamment chiffrée de la clé privée à différents emplacements, offrant redondance et flexibilité.

6.2.1 Authentification par Phrase Secrète

La méthode d'authentification principale où la clé privée est chiffrée avec une clé dérivée de phrase secrète et stockée dans la base de données backend :

6.2.2 Authentification par Clé Matérielle

Les utilisateurs peuvent activer l'authentification par clé matérielle en plus ou à la place de l'authentification par phrase secrète. Les clés privées sont protégées par une clé de sécurité matérielle (YubiKey, Titan Key) utilisant FIDO2/WebAuthn :

Compromis Clé Matérielle : Si vous utilisez des clés matérielles sans authentification par phrase secrète, perdre la clé matérielle signifie perdre l'accès à vos données chiffrées sauf si vous avez une clé de sauvegarde ou un fichier de clé exporté. La clé privée chiffrée dans IndexedDB ne peut pas être déchiffrée sans la clé matérielle physique présente.

6.2.3 Authentification Biométrique

Les utilisateurs peuvent activer l'authentification biométrique (empreinte digitale, Face ID) pour un accès pratique sur appareils mobiles :

6.2.4 Sauvegarde de Fichier de Clé

Les utilisateurs peuvent exporter leur clé privée chiffrée avec une phrase secrète séparée :

6.3 Rotation des Clés

SeraVault supporte la rotation des clés pour maintenir la confidentialité persistante :

Processus de Rotation des Clés

  1. L'utilisateur génère une nouvelle paire de clés ML-KEM-768
  2. Pour chaque fichier possédé par l'utilisateur :
    • Déchiffrer la clé de fichier avec l'ancienne clé privée
    • Re-encapsuler la clé de fichier avec la nouvelle clé publique
    • Mettre à jour la base de données backend avec la nouvelle clé encapsulée
  3. Pour chaque fichier partagé :
    • Notifier les partenaires de partage du changement de clé
    • Re-encapsuler les clés partagées avec la nouvelle clé publique
  4. Ancienne clé privée effacée en sécurité
  5. Nouvelle clé publique publiée
Considération Performance : La rotation de clés pour les utilisateurs avec des milliers de fichiers peut être chronophage. L'opération est effectuée progressivement en arrière-plan.

7. Partage Sécurisé de Fichiers

7.1 Modèle de Partage

SeraVault implémente l'encapsulation de clé par destinataire pour le partage de fichiers :

// Le propriétaire du fichier partage le fichier avec le destinataire // 1. Le propriétaire récupère la clé publique du destinataire depuis la base de données backend cléPubliqueDestinataire = Backend.getPublicKey(idUtilisateurDestinataire) // 2. Le propriétaire déchiffre la clé de fichier pour lui-même secretPartagéPropriétaire = ML-KEM-768.Decapsulate(cléPrivéePropriétaire, texteChiffréPropriétaire) cléFichier = AES-256-GCM.Decrypt(secretPartagéPropriétaire, nonceClé, cléFichierChiffrée) // 3. Le propriétaire encapsule la clé de fichier pour le destinataire (texteChiffréDestinataire, secretPartagéDestinataire) = ML-KEM-768.Encapsulate(cléPubliqueDestinataire) nonceCléDestinataire = CSPRNG(12 octets) cléFichierChiffréeDestinataire = AES-256-GCM.Encrypt(secretPartagéDestinataire, nonceCléDestinataire, cléFichier) // 4. Stocker la clé encapsulée du destinataire dans la base de données backend Backend.grantAccess(idFichier, idUtilisateurDestinataire, texteChiffréDestinataire, cléFichierChiffréeDestinataire)

7.2 Propriétés du Partage

7.3 Modèle de Permissions

Permission Description
Propriétaire Contrôle total : lire, modifier, supprimer, partager, révoquer
Visualiser Peut déchiffrer et visualiser le fichier, ne peut pas modifier ou partager

Actuellement, SeraVault implémente un simple modèle de permission propriétaire/visualisation. Les utilisateurs partagés peuvent visualiser les fichiers mais ne peuvent pas les modifier ou les partager avec d'autres.

7.4 Partage de Groupe

Pour partager avec plusieurs utilisateurs, le propriétaire peut créer un "partage de groupe" :

Coût de Stockage : Chaque fichier partagé nécessite de stocker une clé encapsulée par destinataire (~1 Ko). Pour un partage à grande échelle, c'est négligeable comparé au contenu du fichier lui-même. Seul le quota de stockage du propriétaire du fichier est consommé, peu importe le nombre de personnes avec qui c'est partagé.

8. Méthodes d'Authentification

8.1 Authentification Multi-Facteurs

SeraVault sépare l'authentification du compte de l'accès aux clés de chiffrement :

8.2 Authentification Basée sur Phrase Secrète

La méthode d'authentification par défaut :

8.3 Authentification Biométrique

Utilise WebAuthn avec authentificateurs de plateforme :

8.4 Authentification par Clé Matérielle (YubiKey)

Utilise FIDO2/CTAP2 pour authentification soutenue par matériel :

8.5 Passkey (Authentificateur de Plateforme)

Authentification moderne sans mot de passe utilisant WebAuthn :

9. Messagerie Chiffrée

9.1 Architecture de Chat

SeraVault inclut une messagerie chiffrée de bout en bout utilisant les mêmes primitives cryptographiques que le chiffrement de fichiers :

9.2 Échange de Clé de Conversation

// Créer une conversation // 1. L'initiateur génère une clé de conversation aléatoire cléConversation = CSPRNG(32 octets) // 2. Pour chaque participant (y compris l'initiateur) : (texteChiffré_i, secretPartagé_i) = ML-KEM-768.Encapsulate(cléPublique_participant_i) nonce_i = CSPRNG(12 octets) cléConversationChiffrée_i = AES-256-GCM.Encrypt(secretPartagé_i, nonce_i, cléConversation) // 3. Stocker les clés de conversation chiffrées dans la base de données backend // Chaque participant peut déchiffrer avec sa clé privée

9.3 Chiffrement de Message

// Envoyer un message // 1. L'expéditeur déchiffre la clé de conversation secretPartagé = ML-KEM-768.Decapsulate(cléPrivéeExpéditeur, texteChiffréExpéditeur) cléConversation = AES-256-GCM.Decrypt(secretPartagé, nonce, cléConversationChiffrée) // 2. Chiffrer le message nonceMessage = CSPRNG(12 octets) messageChiffré = AES-256-GCM.Encrypt(cléConversation, nonceMessage, contenuMessage) // 3. Télécharger vers la base de données backend Backend.addMessage(idConversation, messageChiffré, nonceMessage, horodatage)

9.4 Propriétés du Chat

Visibilité des Métadonnées : Le serveur connaît :
  • Qui est dans quelles conversations
  • Horodatages des messages
  • Longueurs approximatives des messages
C'est similaire à la visibilité des métadonnées côté serveur de Signal.

9.5 Améliorations Futures

Améliorations potentielles pour versions futures :

10. Détails d'Implémentation

10.1 Stack Technologique

Composant Technologie
Frontend React + TypeScript
Bibliothèque Crypto Web Crypto API + ml-kem (WebAssembly)
Backend Base de Données Cloud, Stockage Objet, Service d'Authentification, Fonctions Serverless
Authentification WebAuthn, FIDO2, OAuth 2.0

10.2 Implémentation ML-KEM-768

Nous utilisons la bibliothèque JavaScript ml-kem, qui fournit :

10.3 Génération de Nombres Aléatoires

Tout hasard cryptographique utilise crypto.getRandomValues() :

function générerOctetsAléatoires(longueur: number): Uint8Array { const tableau = new Uint8Array(longueur); crypto.getRandomValues(tableau); return tableau; }

10.4 Gestion Sécurisée de la Mémoire

JavaScript ne fournit pas de contrôle mémoire explicite, mais nous suivons les meilleures pratiques :

function effacementSécurisé(tableau: Uint8Array): void { tableau.fill(0); }

10.5 Gestion des Erreurs

Les erreurs cryptographiques sont gérées soigneusement pour prévenir la fuite d'information :

11. Analyse de Sécurité

11.1 Analyse des Menaces

11.1.1 Compromission du Serveur

Menace : Un attaquant obtient un accès complet à l'infrastructure cloud.

Impact : Faible. L'attaquant obtient fichiers chiffrés, clés privées chiffrées, clés publiques, métadonnées chiffrées.

Mitigation : Sans phrases secrètes utilisateur ou clés matérielles, l'attaquant ne peut pas déchiffrer. L'architecture à connaissance nulle limite les dommages à la collecte de données chiffrées.

11.1.2 Écoute Passive du Réseau

Menace : Un attaquant intercepte le trafic réseau.

Impact : Faible. TLS protège le transport, mais même la compromission TLS n'expose que des données chiffrées.

Mitigation : Le chiffrement au niveau application assure que le texte en clair n'est jamais transmis. Métadonnées chiffrées.

11.1.3 Attaque par Ordinateur Quantique

Menace : Un ordinateur quantique futur tente de casser le chiffrement.

Impact : Faible pour données protégées par ML-KEM-768. Sécurité du chiffrement symétrique (AES-256) réduite mais toujours forte.

Mitigation : ML-KEM-768 basé sur problèmes de réseau résistants aux algorithmes quantiques connus. AES-256 fournit 128 bits de sécurité contre attaques quantiques (algorithme de Grover), suffisant pour la plupart des cas d'usage.

11.1.4 Phrase Secrète Faible

Menace : L'utilisateur choisit une phrase secrète faible, l'attaquant effectue une force brute hors ligne.

Impact : Élevé si réussi. L'attaquant déchiffre la clé privée et obtient accès à tous les fichiers.

Mitigation :

11.1.5 Phishing

Menace : Utilisateur trompé pour entrer phrase secrète sur site malveillant.

Impact : Élevé. L'attaquant obtient la phrase secrète et peut déchiffrer la clé privée.

Mitigation :

11.2 Force Cryptographique

Primitive Sécurité Classique Sécurité Quantique
ML-KEM-768 192 bits 192 bits (Niveau NIST 3)
AES-256-GCM 256 bits 128 bits (Grover)
Argon2id (64 Mio) Dépend de phrase secrète Dépend de phrase secrète

11.3 Limitations Connues

  1. Fuite de Métadonnées : Tailles de fichiers, horodatages, relations de partage visibles au serveur
  2. Confidentialité Persistante : Chat n'implémente pas confidentialité persistante parfaite (pas de ratcheting)
  3. Force de Phrase Secrète : Sécurité système limitée par force de phrase secrète choisie par utilisateur
  4. Sécurité du Navigateur : Repose sur sandboxing navigateur et implémentation Web Crypto API
  5. Pas de Déniabilité : Messages chiffrés fournissent authentification mais pas déniabilité
  6. Analyse de Trafic : Modèles d'activité (téléchargements, téléversements, connexions) observables par serveur

11.4 Audit et Vérification

SeraVault est open source, permettant des audits de sécurité indépendants :

12. Références

  1. NIST FIPS 203 : Module-Lattice-Based Key-Encapsulation Mechanism Standard. https://csrc.nist.gov/pubs/fips/203/final
  2. NIST Post-Quantum Cryptography : Algorithmes Sélectionnés 2024. https://csrc.nist.gov/projects/post-quantum-cryptography
  3. AES-GCM : Recommandation pour les Modes de Chiffrement par Bloc : Galois/Counter Mode (GCM) et GMAC. NIST SP 800-38D.
  4. WebAuthn : Web Authentication: An API for accessing Public Key Credentials Level 2. Recommandation W3C.
  5. Argon2 : Argon2: the memory-hard function for password hashing. Vainqueur Password Hashing Competition (2015). Vainqueur PHC
  6. Web Crypto API : Recommandation W3C. https://www.w3.org/TR/WebCryptoAPI/
  7. Algorithme de Grover : A fast quantum mechanical algorithm for database search. L.K. Grover, 1996.
  8. Algorithme de Shor : Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer. P.W. Shor, 1997.
  9. Learning With Errors : On lattices, learning with errors, random linear codes, and cryptography. O. Regev, 2005.

Version Document 1.0 | Novembre 2025

Pour questions ou rapports de sécurité, contactez: security@seravault.com

← Retour à l'Accueil SeraVault