Ce document présente l\'architecture technique de ProbatioVault, une plateforme de stockage probatoire zero-knowledge. L\'architecture garantit qu\'aucun serveur ne peut accéder aux contenus utilisateurs, même en cas de compromission totale de l\'infrastructure.

Objectif du document : Fournir l\'état de l\'art technique servant de base aux 5 dépôts de brevet ProbatioVault.

Architecture générale¶

L\'architecture repose sur une séparation stricte entre :\ \ • Serveur API Backend : Orchestration, authentification, métadonnées chiffrées\ • Serveur Clés (HSM) : Enveloppes cryptographiques, isolation VPC privé. Le serveur HSM est isolé sur un VPC privé 10.0.2.0/24, inaccessible depuis Internet, communiquant uniquement via mTLS (certificats X.509).\ • Serveur Documents (S3) : Fichiers chiffrés, stockage WORM (Write Once Read Many)

[Note: La séparation physique des serveurs constitue une défense en profondeur. La compromission d\'un serveur n\'entraîne pas la compromission des données.]

Principes cryptographiques fondamentaux¶

Zero-Knowledge : Le serveur ne voit jamais le mot de passe utilisateur ni les clés de chiffrement. L\'authentification utilise le protocole SRP-6a (RFC 5054).

[Note: SRP-6a est un protocole d\'authentification par mot de passe résistant aux attaques par dictionnaire, normalisé par l\'IETF.]

Chiffrement bout-en-bout : Tous les fichiers sont chiffrés localement sur l\'appareil avec AES-256-GCM avant transmission. Les serveurs ne manipulent que des blobs binaires chiffrés.

Double dérivation de clés : À partir du mot de passe, deux clés distinctes sont dérivées via Argon2id : K_auth (authentification éphémère) et K_encryption (chiffrement persistant).

[Note: Cette séparation garantit qu\'une compromission de la session d\'authentification ne permet pas l\'accès aux documents chiffrés.]

Vue d\'ensemble du flux de données¶

Le schéma ci-dessous illustre le flux complet de données dans l\'architecture ProbatioVault, de l\'authentification à la consultation d\'un document :

[Note: Ce flux illustre la séparation stricte des responsabilités : l\'authentification (Backend), la gestion des clés (HSM), le stockage (S3) et l\'ancrage probatoire (Blockchain) sont isolés physiquement et cryptographiquement.]

Une image contenant texte, diagramme, Plan, conception Le contenu
généré par l'IA peut être
incorrect. {width="4.785416666666666in" height="9.0in"}

Matrice des interactions serveurs¶

Le tableau ci-dessous détaille les communications entre composants et leurs mécanismes de sécurité :

[Note: La communication Backend ↔ HSM utilise mutual TLS (mTLS) avec validation de certificats X.509 sur VPC privé 10.0.2.0/24, inaccessible depuis Internet.]

Source Destination Protocole Authentification Données transmises

App iOS API Backend HTTPS/TLS 1.3 JWT Bearer Requests chiffrées

API Backend Serveur Clés HTTPS/mTLS Certificat X.509 Enveloppes HSM chiffrées

API Backend PostgreSQL TLS 1.3 Role PostgreSQL Metadata chiffrées

App iOS S3 Documents HTTPS Signed URL Fichiers chiffrés

API Backend Blockchain HTTPS/RPC API Key Merkle root hash

[]{#_Toc212728292 .anchor}

Ancrage probatoire (détails d'exploitation) :

Journal interne append-only (hash chaîné SHA3-256) mis à jour en continu.
Batch Merkle (1 000--10 000 hashes) et ancrage sur Ethereum (mainnet/L2) et Tezos, toutes les 24 h (plans Pro) ou 7 j (plans Standard).
Stockage anchorage_audit_log : merkle_root, tx_id, chaîne, signature backend et preuve TSA.
Preuve individuelle = Merkle path + merkle_root + tx_id + jeton TSA + signature HSM (réf. Preuve Composite).

Spécifications cryptographiques détaillées¶

Cette section détaille les paramètres cryptographiques exacts utilisés dans ProbatioVault, assurant l\'interopérabilité et la vérifiabilité des implémentations.

Paramètres SRP-6a¶

Safe Prime N : Groupe 2048 bits (RFC 5054, Appendix A)\ N = 2^2048 - 2^1984 - 1 + 2^64 * { [2^1918 pi] + 124476 }

Générateur g : 2 (générateur standard)

Fonction de hash H : SHA3-256 (NIST FIPS 180-4)

Multiplier k : k = H(N, g) = SHA3-256(N || g)

Scrambling parameter u : u = H(A, B) = SHA3-256(A || B)

[Note: Ces paramètres garantissent une sécurité de 112 bits minimum, équivalente à RSA-2048. Le safe prime N empêche les attaques par sous-groupes (small subgroup attacks).]

Paramètres Argon2id¶

Version : Argon2id v1.3 (RFC 9106)

Time cost (t) : 3 iterations

Memory cost (m) : 65536 KiB (64 MiB)

Parallelism (p) : 4 threads

Output length : 32 bytes (256 bits)

Salt : salt_user (16 bytes)

Associated Data (ad) :

\"ProbatioVault_Auth_v1\" pour K_auth
\"ProbatioVault_Encryption_v1\" pour K_encryption

[Note: Ces paramètres sont conformes aux recommandations OWASP 2024 pour applications mobiles. Temps de calcul : ~500ms sur iPhone 12 Pro, rendant les attaques par dictionnaire économiquement non-viables (10M tentatives = 58 jours CPU).]

Paramètres HKDF-SHA3-256¶

Fonction : HKDF (RFC 5869, phase Extract + Expand)

PRF : HMAC-SHA3-256

Phase Extract : salt = doc_id (UUID 16 bytes), IKM = K_master_user

Phase Expand : info = \"ProbatioVault::Kdoc::v1\", L = 32 bytes

Output : K_doc (32 bytes / 256 bits, clé AES-256-GCM)

[Note: L\'utilisation de doc_id comme salt garantit que chaque document possède une clé unique, même si K_encryption est compromise. L\'info context empêche la réutilisation des clés dérivées dans d\'autres contextes (domain separation).]

Paramètres AES-256-GCM¶

Mode : GCM (Galois/Counter Mode) -- AEAD

Taille clé : 256 bits

Nonce : 12 bytes (96 bits) aléatoires (CSPRNG)

Tag d\'authentification : 16 bytes (128 bits)

Associated Data (AAD) : doc_id + mime_type + version (non chiffré mais authentifié)

[Note: Le mode GCM fournit simultanément confidentialité et authentification (AEAD). Le nonce DOIT être unique par chiffrement sous la même clé. Nous utilisons un générateur cryptographiquement sûr (SecRandomCopyBytes sur iOS).]

Architecture de clés hiérarchique (4 niveaux)¶

L\'architecture ProbatioVault utilise une hiérarchie à 4 niveaux de clés pour permettre le changement de mot de passe sans re-chiffrement des documents et la révocation granulaire par device.

Une image contenant diagramme, ligne, texte, Plan Le contenu généré
par l'IA peut être incorrect. {width="6.5in" height="3.00625in"}

Niveau 1 - Password utilisateur¶

Le mot de passe saisi par l\'utilisateur. Jamais stocké, uniquement utilisé pour dériver K_encryption.

Niveau 2A - K_encryption (dérivée du password)¶

K_encryption = Argon2id(

password,

salt = salt_user,

t = 3, m = 64 MiB, p = 4,

ad = \"ProbatioVault_Encryption_v1\"

)

Cette clé sert à chiffrer/déchiffrer la Master Envelope contenant K_master_user.

Changement de password → nouvelle K_encryption → re-chiffrement de la Master Envelope.

Niveau 2B - K_device (Secure Enclave, par device)¶

Chaque device autorisé possède une K_device unique générée aléatoirement (256 bits) et stockée dans la Secure Enclave (iOS) ou Android Keystore (TEE). K_device chiffre une Device Envelope contenant K_master_user. Révocation device → suppression Device Envelope.

Niveau 3 - K_master_user (clé maître utilisateur)¶

Clé aléatoire de 256 bits générée lors de la création du compte. Elle reste IDENTIQUE durant toute la vie du compte, même si le password change. C\'est le \"secret maître\" qui sert à dériver toutes les clés de documents.

Stockage : K_master_user n\'existe jamais en clair sur les serveurs. Elle est toujours chiffrée dans trois types d\'enveloppes stockées dans le HSM :

Master Envelope : Enc(K_encryption, K_master_user)
Device Envelopes : Enc(K_device_iPhone, K_master_user), Enc(K_device_iPad, K_master_user), etc.
Recovery Envelope : Enc(K_recovery, K_master_user)

Niveau 4 - K_doc (clés de documents)¶

Pour chaque document, une clé unique est dérivée :

K_doc = HKDF-Expand(

HKDF-Extract(

salt=doc_id,

IKM=K_master_user),

info = \"ProbatioVault::Kdoc::v1\",

L=32)

Gestion du cycle de vie des clés¶

Cette section décrit les mécanismes de rotation, révocation et récupération des clés tout en maintenant les garanties zero-knowledge.

Changement de mot de passe utilisateur¶

Problématique : Si l\'utilisateur change son mot de passe, K_encryption dérivée change également. Or K_encryption sert à dériver toutes les K_doc des documents. Comment maintenir l\'accès sans re-chiffrer tous les documents ?\ Une image contenant texte, diagramme, Parallèle, ligne Le contenu
généré par l'IA peut être
incorrect. {width="3.817361111111111in" height="9.0in"}\ Solution (Key Wrapping Hierarchy) :\

Génération d\'une K_master_user aléatoire (256 bits) lors de la création du compte\
K_master_user sert à dériver les K_doc : K_doc = HKDF(K_master_user, doc_id)\
K_encryption sert uniquement à chiffrer K_master_user : Enc(K_encryption, K_master_user)\
Lors du changement de password :\ a. Dériver nouvelle K_encryption_new depuis nouveau password\ b. Déchiffrer K_master_user avec ancienne K_encryption\ c. Re-chiffrer K_master_user avec K_encryption_new\ d. Mettre à jour l\'enveloppe dans HSM\ \ Avantage : Aucun document n\'est re-chiffré. Seule la petite enveloppe (32 bytes) est mise à jour. Opération quasi-instantanée même avec des milliers de documents.

[Note: Cette architecture à quatre niveaux (password → K_encryption → K_master_user → K_doc) est utilisée par 1Password et Bitwarden. Elle permet la rotation du mot de passe sans impact sur les données chiffrées.]

Le changement de mot de passe implique DEUX types d\'enveloppes stockées dans le HSM¶

Master Envelope (UNE seule par utilisateur) :

Contenu : Enc(K_encryption, K_master_user)

Usage : Changement de password, création nouveau device

Mise à jour : OUI lors du changement de password

Device Envelopes (UNE par device autorisé) :

Contenu : Enc(K_device_iPhone, K_master_user), Enc(K_device_iPad, K_master_user), etc.

Usage : Accès quotidien aux documents

Mise à jour : NON lors du changement de password (restent inchangées)

Flux détaillé du changement de password¶

Utilisateur saisit ancien password + nouveau password
Dérivation : K_encryption_OLD = Argon2id(password_old)
Récupération Master Envelope depuis HSM
Déchiffrement : K_master_user = Dec(K_encryption_OLD, master_envelope)
Dérivation : K_encryption_NEW = Argon2id(password_new)
Re-chiffrement : master_envelope_NEW = Enc(K_encryption_NEW, K_master_user)
Mise à jour atomique dans HSM (transaction)
Génération nouveau verifier SRP-6a pour authentification future

Résultat :

✅ Master Envelope mise à jour

✅ Password changé

❌ Device Envelopes INCHANGÉES (iPhone/iPad/Mac continuent de fonctionner)

❌ Aucun document re-chiffré

Performance : \< 2 secondes (dont 800ms Argon2id × 2)

Données transférées : \< 1 KB (juste la nouvelle enveloppe 32 bytes)

Révocation d\'un device compromis¶

Scénario : Un iPhone est perdu ou volé. L\'utilisateur doit révoquer l\'accès immédiatement.\ Une image contenant texte, diagramme, Parallèle, capture d'écran Le
contenu généré par l'IA peut être
incorrect. {width="5.01730971128609in" height="8.437048337707786in"}

Procédure de révocation :\

Depuis un device de confiance, l\'utilisateur accède à \"Mes appareils\"\
Sélectionne le device compromis et clique \"Révoquer\"\
Backend supprime toutes les enveloppes liées à ce device_id dans HSM\
Backend invalide tous les refresh_tokens associés\
Backend enregistre device_id dans blacklist (vérifiée à chaque requête)\ \ Effet immédiat : Le device compromis ne peut plus :\ • S\'authentifier (refresh token invalidé)\ • Récupérer les enveloppes de clés (supprimées du HSM)\ • Accéder aux nouveaux documents (blacklist)\ \ Note importante : Les documents déjà téléchargés et déchiffrés sur le device compromis AVANT la révocation restent accessibles localement. C\'est une limite fondamentale du chiffrement bout-en-bout. Pour les documents ultra-sensibles, utiliser la fonctionnalité \"Expiration automatique\" qui efface les fichiers temporaires après consultation. [Note: La révocation est irréversible. Pour ré-autoriser le device, l\'utilisateur devra le ré-enregistrer via le processus normal d\'approbation (notification push sur device de confiance).]

Transaction atomique de révocation¶

La révocation d\'un device s\'effectue en une transaction atomique (BEGIN/COMMIT) garantissant la cohérence :

Invalidation refresh_token :

UPDATE refresh_tokens

SET status = \'revoked\' WHERE device_id = ?

Ajout blacklist :

INSERT INTO device_blacklist

(device_id, user_id, reason, revoked_at)

Suppression enveloppes HSM :

DELETE FROM document_keys WHERE device_id = ?

(Suppression de toutes les Device Envelopes : Enc(K_device_compromis, K_master_user))

Logs audit signés :

INSERT INTO audit_logs

(action: \'device_revoked\', signature: HMAC-SHA3-256)

Si une étape échoue, ROLLBACK complet → aucune révocation partielle.

Tentatives d\'accès du device révoqué¶

Scénario A - Tentative refresh token¶

Device compromis → POST /auth/refresh

Backend vérifie blacklist → device_id trouvé

→ HTTP 403 Forbidden {\"error\": \"device_revoked\"}

Scénario B - Tentative avec JWT valide (rare, \< 1h après révocation)¶

Device compromis → GET /documents/12345 avec JWT non expiré

Backend extrait device_id depuis JWT claims

Backend vérifie blacklist → device_id trouvé

→ HTTP 403 Forbidden {\"error\": \"device_revoked\"}

Scénario C - Tentative récupération enveloppe¶

Device compromis → GET /keys/envelope/doc_12345

HSM cherche : SELECT * FROM document_keys WHERE device_id = ?

→ Aucun résultat (enveloppes supprimées)

→ HTTP 404 Not Found

Limitation fondamentale¶

Les documents déjà déchiffrés et stockés en cache local AVANT la révocation restent accessibles jusqu\'à expiration du cache (1h par défaut) ou reboot du device. Cette limite est inhérente au chiffrement bout-en-bout : une fois déchiffré localement, le serveur ne peut plus contrôler l\'accès.

Protections complémentaires recommandées¶

MDM Wipe (Mobile Device Management) si device d\'entreprise
Apple Find My / Activation Lock pour effacement à distance
FileProtectionComplete iOS (chiffrement après reboot)
Expiration cache agressive (15 min au lieu de 1h) pour documents sensibles

Recovery Key (clé de récupération)¶

Usage : Si l\'utilisateur perd tous ses devices ET oublie son mot de passe, la Recovery Key permet de restaurer l\'accès.

Une image contenant texte, diagramme, ligne, Parallèle Le contenu
généré par l'IA peut être
incorrect. {width="4.658333333333333in" height="9.0in"}\ \ Génération : Lors de la création du compte :\ • Génération d\'une phrase mnémonique BIP39 (24 mots)\ • Dérivation d\'une clé de 256 bits depuis la phrase\ • Chiffrement de K_master_user avec cette clé\ • Stockage de l\'enveloppe dans HSM\ \ Affichage unique : La Recovery Key est affichée UNE SEULE FOIS à l\'utilisateur avec instruction de la stocker en lieu sûr (impression papier, coffre-fort physique). Elle n\'est JAMAIS stockée par ProbatioVault.\ \ Procédure de récupération :\

L\'utilisateur accède à \"Récupération de compte\"\
Saisit son email et les 24 mots de la Recovery Key\
Backend vérifie l\'enveloppe Recovery Key\
Application déchiffre K_master_user\
Utilisateur définit un nouveau mot de passe\
K_master_user est re-chiffrée avec le nouveau K_encryption\ [Note: La Recovery Key constitue un point de vulnérabilité contrôlé. Un attaquant possédant la Recovery Key ET l\'accès à la base HSM pourrait déchiffrer les documents. C\'est pourquoi nous recommandons un stockage physique sécurisé (coffre-fort, tiers de confiance).]

Spécifications techniques de la Recovery Key¶

Génération de la phrase mnémonique¶

Génération entropie : 256 bits aléatoires (SecRandomCopyBytes sur iOS)
Conversion BIP39 : Utilisation de la wordlist anglaise standard BIP39 (2048 mots)
Phrase mnémonique : 24 mots (256 bits entropie = 24 mots BIP39)
Checksum : Les derniers bits incluent un checksum pour détecter erreurs de saisie

Exemple de phrase (24 mots)¶

abandon ability able about above absent absorb abstract absurd abuse access accident account accuse achieve acid acoustic acquire across act action actor actress actual adapt

Dérivation de K_recovery depuis la phrase¶

K_recovery = PBKDF2-HMAC-SHA512(

password: mnemonic_phrase (UTF-8),

salt: \"ProbatioVault Recovery v1\",

iterations: 2048,

output: 32 bytes (256 bits)

)

Note : PBKDF2 avec 2048 itérations est suffisant car la phrase a déjà 256 bits d\'entropie (vs password utilisateur qui a ~40-60 bits). L\'objectif est la dérivation reproductible, pas la résistance brute-force.

Création de la Recovery Envelope¶

recovery_envelope = AES-256-GCM-Encrypt(

key: K_recovery,

plaintext: K_master_user,

aad: user_id + \"recovery_v1\" (Associated Authenticated Data)

)

Stockage HSM¶

INSERT INTO recovery_keys

(user_id, recovery_envelope, created_at, version)

VALUES (?, ?, NOW(), \'v1\')

Trois types d\'enveloppes dans ProbatioVault¶

Master Envelope : Enc(K_encryption, K_master_user)

→ Usage : Changement password, création nouveau device

→ Mise à jour : Oui lors changement password

Device Envelopes : Enc(K_device, K_master_user) (une par device)

→ Usage : Accès quotidien documents

→ Mise à jour : Non lors changement password, Suppression lors révocation

Recovery Envelope : Enc(K_recovery, K_master_user)

→ Usage : Récupération compte si tous devices perdus + password oublié

→ Mise à jour : Recommandé tous les 2 ans (régénération nouvelle phrase)

Procédure de récupération complète¶

Phase 1 - Validation Recovery Key¶

Utilisateur saisit email + 24 mots sur nouveau device
Backend retourne user_id + salt
Device reconstruit : mnemonic = join(24_words, \" \")
Device dérive : K_recovery = PBKDF2(mnemonic, salt)
Device récupère recovery_envelope depuis HSM
Device déchiffre : K_master_user = Dec(K_recovery, recovery_envelope)
Si déchiffrement échoue → Recovery Key invalide → ABORT

Phase 2 - Réinitialisation compte¶

Utilisateur définit nouveau password
Device génère : K_encryption_NEW = Argon2id(password_new)
Device génère nouveau verifier SRP-6a
Device re-chiffre : master_envelope_NEW = Enc(K_encryption_NEW, K_master_user)
Backend révoque TOUS les anciens devices (blacklist + suppression Device Envelopes)
Backend crée nouveau Device Envelope : Enc(K_device_nouveau, K_master_user)
Transaction atomique : UPDATE users, UPDATE master_envelope, DELETE device_envelopes, INSERT nouveau device

Phase 3 - Sécurité post-recovery¶

Email notification : \"Compte récupéré via Recovery Key le 30/10/2025\"
Recommandation : Générer nouvelle Recovery Key depuis paramètres
Recommandation : Activer MFA (TOTP/FIDO2)
Destruction ancienne Recovery Key (papier) par l\'utilisateur

Sécurité de la Recovery Key¶

Risques :

🔴 Si Recovery Key + accès HSM → Accès total documents

🟡 Stockage physique (papier) peut être perdu/volé/brûlé

🟡 Pas de révocation (si compromise, changer password + régénérer)

Mitigations :

✅ Recovery Key stockée OFFLINE (papier, jamais numérique)

✅ Phrase affichée UNE SEULE FOIS (jamais ré-affichable)

✅ Vérification obligatoire (saisir 3 mots aléatoires) avant validation

✅ Audit logs signés à chaque utilisation Recovery Envelope

✅ Email notification à chaque récupération de compte

Comparaison standards industrie¶

1Password : Emergency Kit (34 caractères alphanumériques)
Bitwarden : Recovery Code (8 groupes de 4 chiffres = 32 chiffres)
Apple : Recovery Key (28 caractères alphanumériques)
ProbatioVault : BIP39 24 mots (standard crypto, 256 bits entropie)

Avantage BIP39 : Interopérable avec wallets crypto, plus facile à noter (mots vs caractères aléatoires), checksum intégré détecte erreurs de saisie.

Phase 1 : Authentification Zero-Knowledge¶

La phase d\'authentification établit une session sécurisée sans jamais révéler le mot de passe au serveur. Elle utilise le protocole SRP-6a combiné à une dérivation de clés Argon2id.

Une image contenant texte, capture d'écran, nombre, Parallèle Le
contenu généré par l'IA peut être
incorrect.

Étapes clés¶

[]{#_Toc212728309 .anchor}*Étapes 1-4 : Demande d\'authentification* L\'utilisateur saisit ses identifiants. Le serveur retourne le salt (public) stocké lors de la création du compte. Le mot de passe ne quitte jamais l\'appareil.

[]{#_Toc212728310 .anchor}*Étapes 5-6 : Dérivation locale des clés* L\'application dérive deux clés distinctes avec des contextes différents :

K_auth = Argon2id(password, salt_user, time_cost=3, memory_cost=64MB, parallelism=4, ad=\"ProbatioVault_Auth_v1\")
K_encryption = Argon2id(password, salt_user, time_cost=3, memory_cost=64MB, parallelism=4, ad=\"ProbatioVault_Encryption_v1\")

Le mot de passe est immédiatement effacé de la mémoire.

[Note: Argon2id est configuré avec timeCost=3 et memoryCost=64MB pour résister aux attaques par GPU/ASIC (recommandation OWASP 2024).]

[]{#_Toc212728311 .anchor}*Étapes 7-17 : Protocole SRP-6a* Challenge-response cryptographique entre client et serveur. Le client génère un challenge éphémère A, le serveur répond avec B. Les preuves M1 et M2 permettent une authentification mutuelle sans révéler K_auth.

[Note: SRP-6a utilise un safe prime de 2048 bits (sécurité équivalente RSA-2048). Le protocole est normalisé dans RFC 5054.]

[]{#_Toc212728312 .anchor}*Étapes 18-21 : Validation et JWT* Après vérification mutuelle, le serveur génère un JWT token (RS256, expiration 1h) et un refresh token (30 jours). K_auth est effacée, K_encryption est conservée pour la Phase 2.

Garanties de sécurité¶

Ce que le serveur voit : email, salt (public), verifier SRP, challenges A/B, preuve M1

Ce que le serveur ne voit JAMAIS : password en clair, K_auth en clair, K_encryption (même chiffrée), clé de session K.

[Note: Un employé malveillant avec accès total à la base de données ne peut pas déchiffrer les documents utilisateurs. C\'est la garantie zero-knowledge.]

Phase 2 : Dépôt de fichier sécurisé¶

Le dépôt d\'un fichier implique un chiffrement local, un upload du fichier chiffré vers S3, le stockage des métadonnées chiffrées, et optionnellement un ancrage blockchain pour la preuve probatoire.

Une image contenant texte, diagramme, Parallèle, ligne Le contenu
généré par l'IA peut être incorrect. {width="6.2in" height="9.0in"}

Étapes clés¶

[]{#_Toc212728316 .anchor}*Étapes 1-2 : Préparation du fichier* L\'utilisateur sélectionne un fichier et saisit les métadonnées (titre, description, tags). Un identifiant unique (UUID) est généré pour ce document.

[]{#_Toc212728317 .anchor}Étape 3 : Chiffrement local zero-knowledge

Une clé de document K_doc est dérivée via HKDF-SHA3-256 (Extract + Expand, RFC 5869) :

K_doc = HKDF-Expand(

HKDF-Extract(

salt = doc_id,

IKM = K_master_user),

info = \"ProbatioVault::Kdoc::v1\",

L = 32)

Une clé de session K_share (256 bits aléatoire) est ensuite générée pour chiffrer le fichier :

doc.enc = AES-256-GCM(K_share, fichier, nonce, AAD)

K_share.enc = Enc_K(K_doc, K_share)

Le serveur ne conserve que les clés encapsulées : { K_doc.enc, K_share.enc, doc.enc }.

[Note : HKDF-SHA3-256 dérive K_doc à partir de la clé maître utilisateur (K_master_user) en utilisant doc_id comme sel (salt) et le contexte fixe \"ProbatioVault::Kdoc::v1\".\ Chaque document possède ainsi une clé de dérivation unique et indépendante.\ K_doc sert ensuite à encapsuler la clé de session K_share (Enc_K(K_doc, K_share)), qui chiffre effectivement le contenu du document (AES-256-GCM).\ Ce chaînage garantit l'unicité et l'isolation cryptographique complète de chaque document, conformément au principe Zero-Knowledge.]

[]{#_Toc212728318 .anchor}Étapes 4-11 : Upload du fichier chiffré* Le backend génère une URL pré-signée S3 (expiration 5 minutes). L\'application upload directement le fichier chiffré vers S3 sans transiter par le backend. Le stockage S3 utilise Object Lock en mode COMPLIANCE (WORM). *[Note: Le mode WORM garantit que même l\'administrateur root ne peut supprimer ou modifier le fichier avant l\'expiration. Conforme NF Z42-013.]

[]{#_Toc212728319 .anchor}Étapes 12-16 : Stockage métadonnées et enveloppe de clé* Les métadonnées chiffrées sont stockées dans PostgreSQL. K_doc est chiffrée avec K_device (clé Secure Enclave) pour créer une enveloppe, stockée sur le serveur de clés HSM. *[Note: L\'enveloppe permet l\'accès multi-device. Chaque device autorisé possède sa propre enveloppe chiffrée avec sa K_device unique.]

[]{#_Toc212728320 .anchor}Étapes 17-19 : Ancrage blockchain (optionnel)* Pour la valeur probatoire, les hash sont regroupés quotidiennement dans un arbre de Merkle. La racine est ancrée sur blockchain (Arbitrum L2 ou Tezos). Le merkle_proof permet de prouver l\'inclusion d\'un document sans révéler les autres. *[Note: Ceci correspond au brevet \'Preuve Composite Ancrée\'. L\'ancrage blockchain fournit une preuve d\'horodatage immuable.]

Flux de données¶

Donnée App iOS API Backend Serveur Clés Serveur Docs

Fichier clair ✅ Temporaire ❌ ❌ ❌

Fichier ✅ Temporaire ❌ Transit ❌ ✅ WORM chiffré

K_doc ✅ RAM ❌ ⚠️ Envelope ❌ volatile

Metadata ✅ ❌ ❌ ❌ claires

Metadata ✅ ✅ PostgreSQL ❌ ❌ chiffrées

Phase 3 : Accès aux documents¶

La phase de récupération permet à l\'utilisateur d\'accéder à un document précédemment déposé. Le processus implique la récupération de l\'enveloppe cryptographique, le téléchargement du fichier chiffré, et le déchiffrement local sur l\'appareil. Le serveur ne voit jamais le contenu en clair.

Une image contenant texte, diagramme, ligne, Parallèle Le contenu
généré par l'IA peut être
incorrect. {width="4.290972222222222in" height="9.0in"}

Étapes clés¶

Étapes 1-3 : Demande de consultation¶

L\'utilisateur sélectionne un document depuis la liste, la recherche ou un partage. L\'application envoie une requête authentifiée au backend qui vérifie les permissions via PostgreSQL Row-Level Security (RLS). Seuls les documents appartenant à l\'utilisateur authentifié sont accessibles.[Note: La vérification RLS garantit une isolation stricte des données en architecture multi-tenant (brevet B2B2C).]

Étapes 4-10 : Récupération de l\'enveloppe de clé¶

Le backend interroge le serveur de clés HSM (via mTLS) pour récupérer l\'enveloppe cryptographique correspondant au document et au device actuel. L\'enveloppe contient K_doc chiffrée avec K_device (Secure Enclave). Le serveur de clés enregistre chaque accès dans un journal d\'audit signé et immuable. [Note: K_device reste dans la Secure Enclave et n\'est jamais extractible. Seul le device autorisé peut déchiffrer l\'enveloppe.]

Étapes 11-17 : Téléchargement du fichier chiffré¶

Le backend génère une URL pré-signée S3 (expiration 5 minutes) permettant le téléchargement direct depuis le serveur de documents. L\'application vérifie le checksum SHA3-256 du fichier téléchargé pour détecter toute altération pendant le transfert. Le fichier reste chiffré durant tout le transit. [Note: Le stockage WORM (Object Lock) garantit l\'immutabilité du fichier. Aucune modification n\'est possible, même par l\'administrateur.]

Étapes 18-21 : Déchiffrement local zero-knowledge¶

L\'application déchiffre d\'abord l\'enveloppe avec K_device pour obtenir K_doc. Les métadonnées puis le contenu du fichier sont déchiffrés localement avec K_doc. La vérification du tag d\'authentification AEAD (AES-256-GCM) détecte toute tentative d\'altération du fichier chiffré. Si le tag est invalide, le processus est abandonné immédiatement. [Note: Le mode AEAD (Authenticated Encryption with Associated Data) garantit simultanément la confidentialité et l\'intégrité des données.]

Étapes 22-24 : Affichage et nettoyage sécurisé¶

Le fichier déchiffré est stocké temporairement avec FileProtectionComplete (iOS) et expire après consultation ou timeout (1h par défaut). L\'application utilise les viewers natifs (PDFKit, QuickLook) pour l\'affichage. Après utilisation, K_doc et le fichier temporaire sont effacés de manière sécurisée via secure_zero() et secure_delete(). K_encryption reste en mémoire pour les prochaines opérations.

Étapes 25-30 : Vérification probatoire blockchain (optionnel)¶

L\'utilisateur peut demander une vérification de l\'ancrage blockchain. Le backend retourne le transaction_id blockchain, le merkle_proof et l\'horodatage d\'ancrage. L\'application vérifie localement que le hash du document est bien inclus dans l\'arbre de Merkle ancré. Cette preuve d\'existence est infalsifiable et horodatée. [Note: Ceci correspond au brevet \'Preuve Composite Ancrée\'. Le merkle_proof permet de prouver l\'inclusion sans révéler les autres documents du batch.]

Garanties de sécurité¶

Ce que le serveur voit : doc_id, user_id, device_id, timestamp des accès, metadata chiffrées

Ce que le serveur ne voit JAMAIS : K_doc en clair, contenu du fichier, métadonnées en clair, K_device [Note: Un attaquant compromettant simultanément les trois serveurs (API, Clés, Documents) ne pourrait toujours pas déchiffrer les fichiers sans accès physique au device autorisé.]

Flux inverse (Dépôt vs Récupération)¶

La Phase 3 constitue le flux inverse de la Phase 2. Le tableau ci-dessous illustre la symétrie des opérations :

Donnée Phase 2 (Dépôt) Phase 3 (Récupération)

Direction Client → Serveur Serveur → Client

K_doc Générée (HKDF Récupérée (enveloppe) dérivation)

Fichier Chiffré puis uploadé Téléchargé puis déchiffré

Enveloppe Créée et stockée HSM Récupérée HSM et déchiffrée

Blockchain Ancrage (écriture Vérification (lecture merkle) proof)

Métadonnées Chiffrées lors saisie Déchiffrées lors affichage

Analyse des menaces (STRIDE)¶

Le modèle STRIDE (Microsoft) identifie six catégories de menaces. Cette section analyse chaque menace et les mécanismes de protection ProbatioVault.

[Note: L\'analyse STRIDE est exigée pour les certifications ISO 27001 et SecNumCloud. Elle démontre une approche méthodique de la sécurité.]

Menace STRIDE Scénario d\'attaque Mécanisme de protection

Spoofing Attaquant se fait • SRP-6a (pas de mot (Usurpation identité) passer pour de passe en clair)\ utilisateur légitime • MFA obligatoire (TOTP/FIDO2)\ • Device fingerprinting\ • Rate limiting (5 tentatives/5min)

Tampering Modification fichiers • AES-GCM auth_tag (Altération données) chiffrés en transit (détecte altération)\ ou au repos • WORM S3 Object Lock\ • Hash blockchain immuable\ • Checksum SHA3-256 vérifiés

Repudiation Utilisateur nie avoir • Logs audit signés (Non-répudiation) déposé un document (append-only)\ • Ancrage blockchain horodaté\ • Merkle proof inclusion\ • JWT signé RS256

Information Employé malveillant • Zero-knowledge Disclosure ou piratage serveur architecture\ (Fuite d\'info) accède aux données • Chiffrement bout-en-bout\ • Metadata chiffrées\ • Séparation serveurs (defense-in-depth)

Denial of Service Attaque DDoS ou • Rate limiting WAF\ (Déni de service) sabotage • CDN CloudFlare\ infrastructure • Réplication multi-région (Paris + Francfort)\ • Health checks + auto-scaling

Elevation of Attaquant obtient • PostgreSQL RLS Privilege droits admin ou (Row-Level Security)\ (Escalade privilèges) accède documents • Principe du moindre d\'autrui privilège\ • JWT scopes limités\ • Audit logs accès privilégiés

Performance et scalabilité¶

Les choix cryptographiques et architecturaux de ProbatioVault sont optimisés pour équilibrer sécurité maximale et expérience utilisateur fluide.

Opération Latence moyenne Goulot Optimisation d\'étranglement

Authentification 800ms Argon2id (CPU) Cache salt Redis SRP

Dérivation K_doc 2ms HKDF-SHA3-256 Parallélisable

Chiffrement 15ms CPU mobile Hardware AES-NI AES-GCM (iOS) (1 MB)

Upload S3 2-5s Bande passante Multipart upload (10 MB)

Récupération 50ms Latence réseau Redis cache enveloppe (5min TTL)

Déchiffrement 15ms CPU mobile Hardware AES-NI local\ (1 MB)

Vérification 5ms Hash SHA3-256 Pré-calculé Merkle proof serveur

Ancrage blockchain 24h batch Coût transaction Groupage quotidien

\ Scalabilité horizontale :\ • API Backend : Stateless, Kubernetes auto-scaling (2-50 pods)\ • PostgreSQL : Read replicas (3 régions)\ • S3 : Illimité par design AWS\ • HSM : Shared tenancy OVH (1000 req/s garantis)\ • Blockchain : L2 Arbitrum (4000 TPS)\ \ Charge cible 2027 :\ • 10,000 utilisateurs actifs\ • 1,000 uploads/jour (moyenne 2 MB)\ • 10,000 consultations/jour\ • 50 TB stockage total\ [Note: Les tests de charge (K6) sur environnement staging montrent une tenue à 500 req/s avec p95 latency \< 200ms. Objectif production : p99 \< 500ms.]

Interopérabilité multi-plateforme¶

ProbatioVault garantit un chiffrement compatible entre iOS, Android et Web, permettant à l\'utilisateur d\'accéder à ses documents depuis n\'importe quel appareil.

Plateforme Stockage Librairie crypto Tested K_device

iOS (Swift) Secure Enclave CryptoKit ✅ v1.0 (Apple)

Android (Kotlin) Android Keystore Tink (Google) 🔄 Q2 2026 (TEE)

Web (TypeScript) IndexedDB Web Crypto API 🔄 Q3 2026 chiffré

Desktop OS Keychain Node.js crypto ⏳ 2027 (Electron)

\ Compatibilité des formats :\ • Header fichiers : JSON UTF-8 (version, nonce, algo)\ • Encodage enveloppes : Base64 standard (RFC 4648)\ • Identifiants : UUID v4 (RFC 4122)\ • Timestamps : ISO 8601 (UTC)\ [Note: Les vecteurs de test cryptographiques (test vectors) sont partagés entre plateformes pour garantir l\'interopérabilité. Vérifiés via CI/CD (GitHub Actions).]

Liens avec les 5 brevets ProbatioVault¶

Les flux techniques décrits ci-dessus constituent l\'infrastructure de base permettant les 5 innovations brevetables de ProbatioVault :

B2B2C - Architecture multi-tenant¶

L\'authentification JWT inclut un tenant_id permettant une séparation stricte des données par organisation. Le backend applique un Row-Level Security (RLS) PostgreSQL pour isoler les données B2B et B2C. La facturation est calculée par tenant.

[Note: Référence: Fiche_de_Brevet_Détaillée_-_B2B2C.docx]

Legal PRE - Proof of Retrievability and Existence¶

Le procédé Legal PRE (Legal Proxy Re-Encryption) permet le transfert probatoire d'un droit d'accès à un document chiffré d'un utilisateur A vers un utilisateur B, sans déchiffrement intermédiaire et sans duplication du fichier.

Le système combine :

un moteur Proxy Re-Encryption (Umbral, NuCypher) assurant la transformation cryptographique aveugle ;
un module HSM Cloud (PKCS#11, FIPS 140-⅔) signant et autorisant chaque re-chiffrement de manière probatoire ;
une PKI (Keycloak + certificats X.509) pour l'authentification des titulaires ;
un stockage WORM (OVH Object Lock) pour la journalisation immuable des événements ;
une autorité d'horodatage RFC 3161 (TSA) et un ancrage Merkle publié périodiquement sur blockchain publique (Ethereum / Tezos / Bitcoin).

Chaque délégation ou révocation produit un événement signé par le HSM, horodaté, inséré dans l'arbre de Merkle et ancré sur blockchain.

La preuve composite associée contient : `events.ndjson`, `merkle_proof`, `tsa_token`, `hsm_signature` et `blockchain_tx_id`, assurant une traçabilité vérifiable hors système.

Ainsi, Legal PRE établit simultanément :

la **preuve de possession** (Retrievability) : le serveur peut prouver qu'il détient le chiffré sans l'exposer ;
la **preuve d'existence probatoire** (Existence) : la signature HSM + TSA + ancrage blockchain garantit la date et l'intégrité du document.

[Note: Référence: Fiche_de_Brevet_Détaillée_-_Legal_PRE.docx]

Tap-to-Claim - Réclamation NFC sécurisée¶

Le device_fingerprint inclut le secure_enclave_id matériel, créant un lien cryptographique non-transférable entre le document et l\'appareil physique. Un transfert NFC permet à un utilisateur de \'réclamer\' un document en prouvant la possession physique du device.

[Note: Référence: Fiche_de_Brevet_Détaillée_-_Tap-to-Claim.docx]

Preuve Composite Ancrée - Ancrage blockchain Merkle¶

Les hash de documents sont regroupés dans un arbre de Merkle dont la racine est ancrée quotidiennement sur blockchain (Ethereum L2 ou Tezos). Chaque document dispose d\'un merkle_proof permettant de vérifier son inclusion sans révéler les autres documents du batch.

[Note: Référence: Fiche_Invention_02_Preuve_Composite_Ancree.docx]

Inférence Locale Confidentielle - ML zero-knowledge¶

Les modèles ML sont chiffrés avec le même mécanisme que les documents (K_model = HKDF(K_encryption, model_id)). L\'inférence s\'effectue localement sur l\'appareil après déchiffrement. Aucune donnée sensible ne transite vers le serveur, garantissant la confidentialité totale.

[Note: Référence: Fiche_Invention_05_Inference_Locale_Confidentielle.docx]

Glossaire technique¶

AES-256-GCM : Advanced Encryption Standard 256 bits, mode Galois/Counter Mode. Chiffrement authentifié (AEAD) standard NIST.

Argon2id : Fonction de dérivation de clé résistante aux attaques GPU/ASIC. Gagnante du Password Hashing Competition 2015.

HKDF : HMAC-based Key Derivation Function (RFC 5869). Dérive des clés cryptographiquement sûres.

HSM : Hardware Security Module. Module cryptographique matériel certifié FIPS 140-2.

JWT : JSON Web Token (RFC 7519). Token d\'authentification signé cryptographiquement.

Merkle Tree : Arbre de hash cryptographique permettant des preuves d\'inclusion efficaces.

OWASP : Open Web Application Security Project. Organisation de référence pour la sécurité applicative.

RLS : Row-Level Security. Isolation des données au niveau des lignes PostgreSQL.

Secure Enclave : Coprocesseur cryptographique iOS (Apple). Clés non-extractibles, certifié Common Criteria EAL4+.

SRP-6a : Secure Remote Password version 6a (RFC 5054). Authentification zero-knowledge par mot de passe.

WORM : Write Once Read Many. Mode de stockage immuable (Object Lock S3 COMPLIANCE mode).

Zero-Knowledge : Architecture où le serveur ne peut pas accéder aux données utilisateur, même avec accès root.

Références standards et normes¶

Standards cryptographiques

RFC 3161 -- Internet X.509 Time-Stamp Protocol (TSP)
RFC 5054 - Using the Secure Remote Password (SRP) Protocol for TLS Authentication
RFC 5869 - HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
RFC 7519 - JSON Web Token (JWT)
RFC 9106 - Argon2 Memory-Hard Function
NIST FIPS 197 - Advanced Encryption Standard (AES)
NIST FIPS 180-4 - Secure Hash Standard (SHA3-256)

Normes de sécurité

FIPS 140-2 Level 3 - Hardware Security Module certification
Common Criteria EAL4+ - Secure Enclave iOS certification
OWASP Password Storage Cheat Sheet (2024)

Normes probatoires françaises

NF Z42-013 - Archivage électronique
NF Z42-020 - Spécifications fonctionnelles d\'un composant Coffre-Fort Numérique
Règlement eIDAS - Identification électronique et services de confiance (UE)

Certifications cloud

SecNumCloud (ANSSI) - Qualification hébergement données sensibles France
ISO 27001 - Système de management de la sécurité de l\'information
SOC 2 Type II - Service Organization Control (AICPA)

Contrôle de version du document¶

Version : 2.1\ \ Date : 30 octobre 2025\ \ Auteur : Équipe Architecture ProbatioVault

Modifications v2.1 :

Ajout section 1.6 : Architecture de clés hiérarchique (4 niveaux)
Enrichissement section Changement de mot de passe utilisateur
Enrichissement section Révocation d\'un device compromis
Enrichissement section Recovery Key (clé de récupération)
Clarification des 3 types d\'enveloppes (Master, Device, Recovery)
Ajout diagrammes Mermaid pour cycle de vie des clés

Modifications v2.0 :

Ajout section 1.3 : Vue d\'ensemble du flux de données
Ajout section 1.4 : Matrice des interactions serveurs
Ajout section 1.5 : Spécifications cryptographiques détaillées
Ajout section 1.6 : Gestion du cycle de vie des clés
Ajout section 4.1 : Analyse des menaces (STRIDE)
Ajout section 4.2 : Performance et scalabilité
Ajout section 4.3 : Interopérabilité multi-plateforme
Enrichissement Phase 3 avec texte détaillé\ \ Statut : DRAFT - En révision pour dépôts de brevet