Chapitre 3 -- Modele de securite¶

Statut : DONE Stories de reference : PD-1, PD-7, PD-8, PD-33, PD-34, PD-36, PD-60 Invariants couverts : INV-249-01, INV-249-02, INV-249-03, INV-249-06, INV-249-07

3.1 Defense-in-depth -- Les cinq couches cryptographiques¶

Le modele de securite de ProbatioVault repose sur une architecture de defense en profondeur ou chaque couche protege independamment les donnees archivees. La compromission d'une couche ne suffit pas a exposer le contenu des documents.

Couche 1 -- Transport (TLS 1.3)¶

Toutes les communications entre le client (application mobile, navigateur) et les serveurs backend sont chiffrees via TLS 1.3. Ce protocole garantit la confidentialite et l'integrite des echanges en transit, y compris la protection contre les attaques de type interception (man-in-the-middle). Le choix de TLS 1.3 -- plutot que TLS 1.2 -- elimine les suites cryptographiques obsoletes et impose le Perfect Forward Secrecy (PFS) sur toutes les connexions.

Couche 2 -- Application (AES-256-GCM)¶

Le chiffrement applicatif est effectue cote client, avant tout envoi au serveur. Chaque document est chiffre avec une cle AES-256-GCM unique, derivee de la cle maitre de l'utilisateur. Le mode GCM (Galois/Counter Mode) assure simultanement la confidentialite et l'authenticite des donnees via un tag d'authentification de 128 bits. Le serveur ne recoit et ne stocke que des blobs chiffres, conformement au principe Zero-Knowledge (cf. section 3.2).

Conformite : NIST SP 800-38D.

Couche 3 -- Stockage (S3 Object Lock COMPLIANCE)¶

Les documents chiffres sont stockes dans des buckets S3 configures en mode WORM (Write Once Read Many) via S3 Object Lock en mode COMPLIANCE. Ce mode empeche toute suppression ou modification des objets pendant la duree de retention, y compris par les administrateurs de la plateforme et par le compte root AWS. Cette immutabilite constitue une garantie architecturale d'integrite au repos, independante des couches cryptographiques logicielles.

Couche 4 -- Cle (AES-KW + HSM)¶

La cle maitre de chaque utilisateur (K_master_user) est protegee par un mecanisme d'enveloppement de cle (Key Wrapping) conforme a NIST SP 800-38F. Cote serveur, les cles de wrapping sont stockees dans le HSM (cf. couche 5) et ne sont jamais exportables. Cote client, la cle maitre est enveloppee dans une Master Envelope chiffree par K_encryption, elle-meme derivee du mot de passe utilisateur via Argon2id. La separation entre cle de donnees et cle d'enveloppement permet la rotation de mot de passe sans re-chiffrement des documents.

Conformite : NIST SP 800-38F (AES-KWP-256).

Couche 5 -- Materiel (HSM PKCS#11)¶

Les cles maitres du systeme -- cle de signature probatoire, cle d'enveloppement, cle TSA -- resident exclusivement dans un cluster AWS CloudHSM certifie FIPS 140-2 Level 3. Les cles privees ne quittent jamais le perimetre materiel du HSM. Toutes les operations cryptographiques privilegiees (signature, wrapping) sont executees a l'interieur du HSM via l'interface PKCS#11. Le cluster est deploye en haute disponibilite sur deux zones de disponibilite (eu-west-3a, eu-west-3b).

Conformite : FIPS 140-2 Level 3, PKCS#11 v2.40.

Diagramme : Couches de defense en profondeur¶

graph TB
    subgraph C5["Couche 5 -- Materiel"]
        HSM["HSM FIPS 140-2 L3<br/>Cles non exportables"]
    end

    subgraph C4["Couche 4 -- Cle"]
        KW["AES-KW-256<br/>Enveloppement de cle"]
    end

    subgraph C3["Couche 3 -- Stockage"]
        WORM["S3 Object Lock<br/>COMPLIANCE mode"]
    end

    subgraph C2["Couche 2 -- Application"]
        AES["AES-256-GCM<br/>Chiffrement client-side"]
    end

    subgraph C1["Couche 1 -- Transport"]
        TLS["TLS 1.3<br/>Perfect Forward Secrecy"]
    end

    C1 --> C2
    C2 --> C3
    C3 --> C4
    C4 --> C5

    style C5 fill:#1a1a2e,color:#e0e0e0
    style C4 fill:#16213e,color:#e0e0e0
    style C3 fill:#0f3460,color:#e0e0e0
    style C2 fill:#533483,color:#e0e0e0
    style C1 fill:#7b2d8e,color:#e0e0e0

Legende : Les couches sont ordonnees de la plus externe (transport) a la plus interne (materiel). Chaque couche est independante : une compromission du transport (couche 1) ne compromet pas le chiffrement applicatif (couche 2), et une compromission du stockage (couche 3) ne permet pas d'acceder aux cles (couches 4-5).

3.2 Zero-Knowledge -- Le serveur ne voit jamais les donnees en clair¶

Principe architectural¶

L'architecture Zero-Knowledge de ProbatioVault garantit que le serveur backend n'a acces a aucune donnee en clair, ni aux cles permettant de les dechiffrer. Le chiffrement et le dechiffrement sont effectues exclusivement sur l'appareil de l'utilisateur. Le serveur ne manipule que des donnees chiffrees, des empreintes cryptographiques et des metadonnees non sensibles.

Perimetres de connaissance¶

Mecanismes de garantie¶

Chiffrement prealable a l'envoi : L'application cliente chiffre chaque document avec AES-256-GCM avant transmission. Le hash probatoire SHA3-256 est calcule sur le document deja chiffre, de sorte que le serveur puisse verifier l'integrite sans jamais acceder au contenu.

Authentification sans mot de passe transmis : L'authentification utilise le protocole SRP-6a (Secure Remote Password), qui permet de prouver la connaissance du mot de passe sans le transmettre ni le stocker cote serveur. Le sel SRP et le verificateur sont les seules donnees liees au mot de passe presentes en base de donnees.

Derivation locale des cles : Toute la hierarchie de cles (K_encryption, K_master_user, K_doc) est derivee localement sur l'appareil de l'utilisateur. Le serveur ne participe a aucune etape de derivation et ne recoit jamais de materiel cryptographique en clair.

3.3 Gestion des cles HSM PKCS#11¶

Infrastructure CloudHSM¶

ProbatioVault utilise AWS CloudHSM comme socle materiel pour la gestion des cles maitres du systeme. Le cluster est deploye en region eu-west-3 (Paris) avec deux instances HSM reparties sur deux zones de disponibilite, assurant haute disponibilite et synchronisation automatique des cles.

Cles maitres du systeme¶

Trois cles maitres resident dans le HSM et ne sont jamais exportables :

Roles et separation des privileges¶

La gestion du HSM respecte une separation stricte des roles conforme a PKCS#11 :

Le compte pv-crypto-user n'est jamais deploye sur le backend applicatif. Le service backend n'a acces qu'aux operations de signature et de verification, jamais a la creation ou la suppression de cles.

Rotation des cles HSM¶

La rotation des cles HSM suit une procedure annuelle avec quorum de deux operateurs :

1. Generation de la nouvelle cle avec le label de l'annee courante (ex: pv-master-sign-2027)
2. Preservation de l'ancienne cle (aucune suppression -- conformite WORM)
3. Basculement du backend vers le nouveau label via configuration
4. Re-signature eventuelle des documents si necessaire (module rotation/ du backend)
5. Inventaire d'audit pour confirmer la rotation

Les credentials du HSM (PIN des CU) sont stockes dans AWS Secrets Manager et HashiCorp Vault, avec rotation annuelle.

3.4 Key Wrapping -- Enveloppes et distribution multi-device¶

Hierarchie des cles¶

L'architecture de cles de ProbatioVault suit une hierarchie a trois niveaux, de la cle derivee du mot de passe jusqu'a la cle de chiffrement de chaque document :

Niveau 1 -- K_encryption : Derivee du mot de passe utilisateur par Argon2id v1.3 (RFC 9106) avec les parametres : memoire 64 MiB, 3 iterations, parallalisme 4, sel unique de 16 octets par utilisateur. Cette cle ne protege que l'enveloppe maitre et n'est jamais stockee.

Niveau 2 -- K_master_user : Cle aleatoire de 32 octets, generee une seule fois a la creation du compte. Elle reste identique durant toute la vie du compte. Elle est stockee exclusivement sous forme chiffree dans une enveloppe (Master Envelope).

Niveau 3 -- K_doc : Cle unique de 32 octets pour chaque document, derivee par HKDF-SHA3-256 a partir de K_master_user et de l'identifiant du document. Cette derivation deterministe avec separation de domaine ("ProbatioVault_Document_v1") garantit l'isolation cryptographique entre documents.

Systeme d'enveloppes¶

Chaque cle de niveau 2 est encapsulee dans une enveloppe chiffree. Trois types d'enveloppes coexistent pour couvrir les differents scenarios d'acces :

Ce modele presente un avantage determinant : lors d'un changement de mot de passe, seule la Master Envelope est re-chiffree. La cle K_master_user reste identique, ce qui evite de re-chiffrer l'ensemble des documents -- une operation couteuse et incompatible avec le stockage WORM.

Securite des enveloppes¶

• Transactions atomiques : La creation, la rotation et la revocation d'enveloppes sont effectuees dans des transactions PostgreSQL atomiques pour garantir la coherence.
• Blacklist d'appareils : La revocation d'un appareil est permanente ; l'appareil est ajoute a une liste noire et ne peut plus generer d'enveloppe.
• Zeroization : La cle K_master_user est effacee de la memoire apres chaque utilisation.
• Row Level Security : Les enveloppes sont protegees par RLS PostgreSQL (cf. section 3.5).

Diagramme : Hierarchie des cles et enveloppes¶

graph TB
    PWD["Mot de passe<br/>utilisateur"]
    PWD -->|"Argon2id<br/>RFC 9106"| KENC["K_encryption<br/>32 octets"]
    KENC -->|"AES-256-GCM<br/>Master Envelope"| KMASTER["K_master_user<br/>32 octets"]
    KMASTER -->|"HKDF-SHA3-256<br/>par document"| KDOC["K_doc<br/>32 octets / document"]
    KDOC -->|"AES-256-GCM"| DOC["Document chiffre"]

    KDEV["K_device<br/>Secure Enclave"]
    KDEV -->|"Device Envelope"| KMASTER

    KREC["K_recovery<br/>BIP39"]
    KREC -->|"Recovery Envelope"| KMASTER

    HSM2["HSM pv-master-wrap<br/>AES-KWP-256"]
    HSM2 -.->|"Wrapping serveur"| KMASTER

    style HSM2 fill:#1a1a2e,color:#e0e0e0
    style DOC fill:#0f3460,color:#e0e0e0

Legende : Les fleches pleines representent les derivations et les enveloppements effectues cote client. La fleche en pointilles represente le wrapping cote serveur par le HSM pour les operations de certification. K_master_user est le pivot central : elle ne change jamais, seules ses enveloppes sont renouvelees.

3.5 Controle d'acces -- RLS PostgreSQL, RBAC et middleware¶

Row Level Security (RLS) PostgreSQL¶

L'isolation des donnees entre utilisateurs est assuree au niveau de la base de donnees par le mecanisme RLS (Row Level Security) de PostgreSQL. Chaque requete SQL est automatiquement filtree pour ne retourner que les lignes appartenant a l'utilisateur authentifie.

Fonctionnement :

1. Le middleware RLS NestJS extrait l'identifiant utilisateur (userId) du jeton JWT authentifie
2. Le userId est injecte dans le contexte de la connexion PostgreSQL via SET LOCAL
3. Les politiques RLS definies sur chaque table filtrent automatiquement les lignes selon ce contexte
4. Le RlsSubscriber TypeORM applique ce contexte a chaque requete

Ce mecanisme fonctionne au niveau du moteur SQL, en amont de l'application. Meme en cas de defaut dans le code applicatif, un utilisateur ne peut pas acceder aux donnees d'un autre utilisateur. C'est une garantie architecturale, non dependante de la logique metier.

RBAC (Role-Based Access Control)¶

Le controle d'acces par role definit les permissions selon le profil de l'utilisateur. Les roles principaux sont :

Middleware de securite¶

La chaine de middleware NestJS applique les controles dans l'ordre suivant :

1. Authentification JWT : Validation du jeton, extraction de l'identite utilisateur
2. Middleware RLS : Injection du contexte userId dans la session PostgreSQL
3. Guards RBAC : Verification des permissions du role sur la route demandee
4. Validation des entrees : Schema de validation (DTO) sur les donnees entrantes

Chaque etape est un prerequis de la suivante. Un echec a n'importe quelle etape arrete immediatement le traitement de la requete.

3.6 Proxy Re-Encryption (PV-PRE) -- Partage delegue sans dechiffrement serveur¶

Objectif¶

Le protocole PV-PRE (ProbatioVault Proxy Re-Encryption), base sur le schema Umbral (NuCypher), permet l'acces legal judiciaire aux documents chiffres sans compromettre le principe Zero-Knowledge. Le proxy ProbatioVault peut transformer un texte chiffre de la cle du proprietaire vers la cle du requerant legal, sans jamais pouvoir dechiffrer le contenu.

Mecanisme¶

Le protocole PV-PRE fonctionne en quatre phases :

Phase 1 -- Generation des fragments de re-chiffrement : Le proprietaire genere n fragments de cle de re-chiffrement (KFrag) selon un schema a seuil polynomial (t, n), ou t fragments suffisent pour re-chiffrer. Les cles publiques du proprietaire et du requerant sont validees via certificats eIDAS.

Phase 2 -- Double validation : Avant toute operation de re-chiffrement, une double validation est requise. Le DPO (Data Protection Officer) verifie la conformite RGPD de la requete, et l'autorite legale (magistrat, OPJ) verifie le mandat judiciaire. Le mandat est lie cryptographiquement au contexte du ReKey (binding cryptographique) pour empecher toute reutilisation hors perimetre.

Phase 3 -- Re-chiffrement par le proxy : Le proxy applique chaque KFrag sur la capsule cryptographique du document pour produire un fragment de capsule re-chiffree (CFrag). Chaque operation consomme un nonce unique d'au moins 96 bits (CSPRNG) pour garantir l'anti-rejeu.

Phase 4 -- Reconstruction par le requerant : Le requerant collecte t CFrags et reconstruit la cle symetrique du document avec sa propre cle privee. Cette reconstruction se fait exclusivement cote requerant -- le proxy n'y participe pas.

Propriete Zero-Knowledge du proxy¶

La garantie que le proxy ne peut jamais dechiffrer est assuree a deux niveaux :

• Garde architectural : Le modele formel (TLA+, Alloy, Z, Prolog) ne contient aucune operation decrypt. Cette absence est une garantie structurelle verifiee par model checking.
• Garantie cryptographique : Les proprietes de securite du schema Umbral assurent que le proxy, meme en possession de tous les KFrag, ne peut pas reconstruire la cle privee du proprietaire ni dechiffrer le contenu.

Cycle de vie des ReKeys¶

Chaque cle de re-chiffrement suit un cycle de vie strict avec etats terminaux irreversibles :

La destruction cryptographique couvre trois perimetres : les KFrag en memoire (zeroization), les entrees en base de donnees (suppression ou marquage), et le cache applicatif (invalidation). Cette destruction est conforme a l'article 17 du RGPD (droit a l'effacement).

Verification formelle¶

Le protocole PV-PRE est specifie formellement et verifie par model checking :

Courbe elliptique utilisee : secp256k1 (compresse, 33 octets), choisie pour la compatibilite avec l'ancrage blockchain Ethereum de ProbatioVault.

3.7 Synthese des algorithmes et conformite normative¶

References¶

• NIST SP 800-38D -- AES-GCM
• NIST SP 800-38F -- AES Key Wrap
• NIST FIPS 202 -- SHA-3
• RFC 9106 -- Argon2
• RFC 5869 -- HKDF
• RFC 3161 -- TSA
• PV-PRE RFC interne : docs/normes/pv-pre/RFC-PV-PRE.md