PD-33 — Dérivation de la clé K_encryption via Argon2id¶

Références¶

• EPIC : PD-189 — CRYPTO
• JIRA : PD-33
• Composant : Client-side crypto (mobile, desktop, PWA)

Objectif¶

Implémenter la dérivation cryptographique de la clé K_encryption à partir du mot de passe utilisateur, en utilisant Argon2id avec des paramètres strictement normatifs ProbatioVault.

Cette clé constitue le point d'entrée cryptographique du compte utilisateur et permet exclusivement de chiffrer et déchiffrer la Master Envelope contenant K_master_user.

Toute compromission à ce niveau invaliderait l'ensemble du modèle zero-knowledge, d'où des exigences de conformité et de sécurité strictes.

Description fonctionnelle¶

Lors de la création de compte ou d'un changement de mot de passe :

• Le mot de passe utilisateur est traité uniquement côté client.
• Une clé dérivée K_encryption est générée via Argon2id.
• Cette clé est utilisée pour :
• chiffrer la Master Envelope à l'inscription ;
• déchiffrer puis re-chiffrer la Master Envelope lors d'une rotation.
• Ni le mot de passe, ni la clé dérivée, ni la clé maître utilisateur ne sont jamais transmis au backend.

La dérivation doit être :

• déterministe (mêmes entrées → même sortie),
• coûteuse en CPU et mémoire,
• résistante aux attaques GPU / ASIC,
• compatible multi-plateforme.

Périmètre¶

Inclus¶

• Fonction de dérivation derivePassword(password, salt_user) → K_encryption.
• Implémentation Argon2id conforme RFC 9106.
• Paramètres cryptographiques normatifs ProbatioVault.
• Exécution locale sur mobile, desktop et web.
• Tests unitaires, de performance et de conformité.
• Documentation crypto associée.

Exclu¶

• Authentification réseau (SRP-6a).
• Gestion du changement de mot de passe.
• Génération ou stockage de K_master_user.
• Gestion des enveloppes de clés.
• Chiffrement des documents.
• Toute exécution backend, worker ou HSM.

Paramètres cryptographiques normatifs¶

La fonction de dérivation doit respecter strictement les paramètres suivants :

Toute déviation invalide la conformité cryptographique du produit.

Propriétés attendues¶

Sécurité¶

• Résistance élevée aux attaques par dictionnaire.
• Couplage obligatoire mot de passe + salt + paramètres exacts.
• Coût mémoire empêchant une attaque GPU rentable.
• Aucune clé dérivée exploitable sans accès au device utilisateur.

Zero-Knowledge¶

• Le mot de passe ne quitte jamais l'appareil.
• Aucune clé dérivée n'est transmise ou stockée côté serveur.
• Aucun log, exception ou trace ne doit contenir :
• le mot de passe,
• le salt,
• K_encryption,
• un hash ou une représentation encodée.

Interopérabilité¶

• Résultat strictement déterministe.
• Compatible avec les modules cryptographiques suivants :
• déchiffrement Master Envelope,
• rotation de mot de passe,
• dérivation documentaire ultérieure (PD-34).
• Résultats identiques sur iOS, Android, desktop et web.

Diagrammes Mermaid¶

Séquence — Dérivation K_encryption (inscription)¶

Ce diagramme illustre le flux nominal de dérivation lors de la création de compte. Le mot de passe et la clé dérivée ne quittent jamais le client (zero-knowledge, cf. TA-5).

sequenceDiagram
    participant U as Utilisateur
    participant C as Client (device)
    participant A as Argon2id (WASM)
    participant ME as Master Envelope

    U->>C: Saisit mot de passe
    Note over C: salt_user = CSPRNG(16 bytes)
    C->>A: derivePassword(password, salt_user)
    Note over A: Argon2id v1.3<br/>m=64 MiB, t=3, p=4<br/>ad="ProbatioVault_Encryption_v1"<br/>(cf. Paramètres normatifs, TA-4)
    A-->>C: K_encryption (32 bytes)
    Note over C: Déterministe : même entrée → même sortie (TA-1)
    C->>ME: Chiffre Master Envelope avec K_encryption
    Note over ME: Contient K_master_user
    C->>C: wipeKey(password, K_encryption)
    Note over C: Effacement mémoire best-effort (TA-5)

Séquence — Rotation de mot de passe¶

Ce diagramme illustre le re-chiffrement de la Master Envelope lors d'un changement de mot de passe. Les documents existants restent accessibles car K_master_user ne change pas (cf. TA-7).

sequenceDiagram
    participant U as Utilisateur
    participant C as Client (device)
    participant A as Argon2id (WASM)
    participant ME as Master Envelope

    U->>C: Ancien mot de passe + nouveau mot de passe
    C->>A: derivePassword(ancien_mdp, salt_user)
    A-->>C: K_encryption_old
    C->>ME: Déchiffre Master Envelope → K_master_user
    Note over C: Nouveau salt_user = CSPRNG(16 bytes)
    C->>A: derivePassword(nouveau_mdp, nouveau_salt)
    Note over A: Mêmes paramètres RFC 9106 (TA-4)
    A-->>C: K_encryption_new
    C->>ME: Re-chiffre Master Envelope avec K_encryption_new
    Note over ME: K_master_user inchangé → accès docs préservé (TA-7)
    C->>C: wipeKey(ancien_mdp, nouveau_mdp, K_encryption_old, K_encryption_new)
    Note over C: Aucune clé transmise au backend (zero-knowledge)

Séquence — Vérification de conformité Argon2id¶

Ce diagramme détaille les contrôles internes de la fonction de dérivation, garantissant la conformité RFC 9106 avant toute opération cryptographique.

sequenceDiagram
    participant Caller as Appelant
    participant D as derivePassword()
    participant V as Validation
    participant A as Argon2id (WASM)

    Caller->>D: (password, salt_user)
    D->>V: Valide inputs
    Note over V: password ≠ vide<br/>salt = 16 bytes exactement
    alt Inputs invalides
        V-->>Caller: Erreur (aucun log sensible, TA-5)
    else Inputs valides
        V-->>D: OK
        D->>D: Charge paramètres normatifs
        Note over D: m=65536 KiB, t=3, p=4<br/>ad="ProbatioVault_Encryption_v1"<br/>output=32 bytes
        D->>A: argon2id(password, salt, params)
        Note over A: Aucun fallback PBKDF2 en production
        A-->>D: raw_key (32 bytes, TA-4)
        D-->>Caller: K_encryption
        Note over D: Variation salt → clé distincte (TA-2)
    end

Contraintes¶

• Exécution exclusivement côté client.
• Bibliothèque Argon2id réputée et auditée.
• Aucune dépendance WebAssembly opaque ou non auditable.
• Aucun fallback PBKDF2 ou équivalent.
• Aucun calcul déporté (backend, worker distant, HSM).

Hypothèses¶

• Le salt_user est généré une seule fois à la création du compte.
• Le salt est stocké en clair côté backend.
• Le mot de passe respecte la politique minimale définie par le produit.
• L'environnement client dispose de ressources suffisantes pour Argon2id.
• Les modules de chiffrement sont traités par d'autres User Stories.

Tests d'acceptation¶

TA-1 — Déterminisme¶

À password et salt identiques, la fonction retourne toujours exactement la même clé de 32 bytes.

TA-2 — Variation du salt¶

À mot de passe identique mais salt différent, les clés dérivées doivent être totalement distinctes (distance de Hamming significative).

TA-3 — Performance client¶

• Mobile milieu de gamme : 300–600 ms.
• Desktop moderne : < 100 ms.
• Aucune exécution serveur.

TA-4 — Conformité RFC¶

• Version Argon2 correcte.
• Mémoire allouée ≈ 64 MiB.
• Output length exact de 32 bytes.

TA-5 — Sécurité applicative¶

• Aucun log sensible.
• Aucune fuite via stacktrace ou exception.
• Effacement mémoire best-effort du mot de passe après usage.

TA-6 — Compatibilité Master Envelope¶

La clé dérivée permet de chiffrer et déchiffrer correctement une Master Envelope valide.

TA-7 — Rotation mot de passe¶

Une nouvelle clé dérivée permet de re-chiffrer la Master Envelope sans invalider l'accès aux documents existants.

Livrables¶

• Fonction de dérivation intégrée au module crypto client.
• Tests unitaires isolés (sans réseau).
• Tests multi-plateformes.
• Documentation /docs/crypto/argon2id.md.
• Exemple reproductible (test vector).

Liens documentaires¶

• EPIC : PD-189 — CRYPTO
• Spécifications techniques ProbatioVault — Zero-Knowledge
• RFC 9106 — Argon2
• Architecture cryptographique — Hiérarchie des clés

Definition of Done¶

• Implémentation conforme aux paramètres normatifs.
• Tests unitaires et de performance validés.
• Documentation publiée.
• Revue sécurité validée.
• Aucun log ou fuite de secret.
• Mention explicite de conformité RFC 9106.