PD-81 — Expression de besoin¶

1. Contexte¶

ProbatioVault repose sur un modèle zero-knowledge strict : les documents sont chiffrés côté client, la plateforme ne peut jamais accéder aux contenus en clair, et les clés de chiffrement sont détenues exclusivement par l'utilisateur.

Cependant, certains cas exceptionnels et encadrés juridiquement imposent un accès temporaire aux données :

• Réquisition judiciaire : mandat signé électroniquement par un juge (eIDAS)
• Procédure pénale ou civile impliquant des preuves numériques
• Cas d'obstruction d'un représentant légal (ex : mineur)

L'architecture ProbatioVault prévoit un mécanisme Legal PRE (Proxy Re-Encryption) documenté dans la fiche brevet (803 - Fiche_Brevet_1_Legal_PRE). Les briques cryptographiques nécessaires sont déjà implémentées :

• PD-41 : Service PRE NuCypher/Umbral — generateReKey(), reEncrypt(), validate()
• PD-82 : Mécanisme de double validation 2-of-2 (parent + autorité)
• PD-37 : Signature HSM pour audit probatoire
• PD-38 : Hash SHA-3 pour intégrité
• PD-39 : Horodatage TSA RFC 3161

PD-81 crée le module Legal PRE : la couche orchestrant le workflow judiciaire complet, de la réception du mandat à la destruction des mécanismes temporaires.

2. Besoin utilisateur¶

En tant que plateforme ProbatioVault, Je veux un module d'accès judiciaire strictement encadré, exceptionnel, traçable et juridiquement opposable, Afin de me conformer aux obligations légales (réquisition judiciaire) sans introduire de backdoor permanente ni compromettre le modèle zero-knowledge global.

3. Périmètre fonctionnel¶

3.1 Inclus¶

1. Réception et validation d'un mandat judiciaire
2. Enregistrement d'un mandat signé électroniquement (format eIDAS, signature qualifiée)
3. Vérification complète via intégration TSP (Trust Service Provider) :
   • Authenticité de la signature (certificat qualifié)
   • Identité de l'autorité émettrice (juge, magistrat)
   • Validité temporelle du mandat
   • Chaîne de certificats (root → intermédiaire → signataire)

4. Extraction et validation du périmètre du mandat (documents ciblés, durée)

5. Double validation interne (réutilisation PD-82)

6. Intégration avec le service DoubleValidation de PD-82 :
   • Validation juridique interne (DPO ou équivalent)
   • Validation conformité (second validateur indépendant)
7. Adaptation du contexte PD-82 au cas "Legal PRE" (rôles : DPO + Responsable juridique au lieu de parent + autorité)

8. Traçabilité nominative des validations (identité non contestable des validateurs internes)

9. Activation d'un accès temporaire via PRE (adaptation PD-41)

10. Génération de clés de re-chiffrement temporaires via PD-41 (generateReKey()) avec :
    • TTL borné (durée définie par le mandat, max 30 jours)
    • Périmètre limité aux documents spécifiés dans le mandat (liste de documentId)
    • Mode lecture seule (re-chiffrement pour consultation, pas de modification)
11. Activation du mécanisme PRE uniquement après double validation complète (état ACTIVATED de PD-82)
12. Impossibilité d'accès au reste du coffre

13. Rate limiting sur les consultations (anti-extraction massive)

14. Traçabilité probatoire complète

15. Chaque étape génère un événement journalisé append-only
16. Signature probatoire HSM via PD-37
17. Inclusion dans l'arbre de Merkle
18. Ancrage blockchain périodique
19. Génération d'une preuve composite vérifiable indépendamment

20. L'utilisateur (titulaire du coffre) peut auditer l'opération a posteriori

21. Destruction cryptographique post-opération

22. Suppression immédiate et vérifiable des clés temporaires (ReKey) à expiration ou fin de consultation
23. Impossibilité de réutilisation (zeroization mémoire)
24. Traçabilité de la destruction (événement append-only + signature HSM)

25. Vérification d'absence de persistance cachée

26. Adaptation du service PRE (PD-41) pour le mode "legal"

27. Extension de l'interface PRE avec un mode legal :
    • generateLegalReKey() : génère un ReKey temporaire avec TTL et périmètre
    • revokeReKey() : destruction immédiate d'un ReKey temporaire
    • getLegalAccessStatus() : état de l'accès temporaire
28. Les ReKey "legal" portent un flag isLegal: true et un mandateId traçable
29. Les ReKey "legal" sont stockés séparément des ReKey standards (isolation)

3.2 Exclus (hors périmètre)¶

• Partages standards entre adultes (PRE classique via PD-41)
• Délégations internes B2B
• Intégration API machine-to-machine judiciaire (phase 2 future)
• Interface utilisateur du portail autorité (story frontend dédiée)
• Gestion des identités PKI des autorités (story dédiée)
• Résistance post-quantique
• Notification de l'utilisateur (story UX dédiée — l'événement est loggé, la notification est hors périmètre)

4. Contraintes et décisions¶

4.1 Intégration eIDAS complète¶

Le module DOIT intégrer un TSP (Trust Service Provider) conforme eIDAS 2.0 pour vérifier : - Les signatures qualifiées sur les mandats - Les certificats de l'autorité émettrice - La révocation CRL/OCSP

Décision : Intégration avec un TSP réel (pas de stub). Le choix du TSP sera documenté dans le plan d'implémentation.

4.2 Réutilisation de PD-82¶

Le mécanisme de double validation réutilise le service PD-82 existant en adaptant : - Les rôles : DPO + LegalOfficer (au lieu de parent + authority) - Le contexte : LEGAL_PRE_MANDATE (au lieu de MINOR_PRE_DELEGATION) - Le TTL : configurable par type de mandat (défaut : 7 jours pour la double validation, comme PD-82)

4.3 Adaptation de PD-41¶

Le service PRE de PD-41 sera étendu (pas remplacé) avec : - De nouvelles méthodes dédiées au mode "legal" - Un stockage isolé pour les ReKey temporaires - Un scheduler de destruction automatique à expiration du TTL

4.4 Conformité juridique¶

Le module DOIT être compatible avec : - eIDAS 2.0 : signature qualifiée - RGPD : proportionnalité, minimisation des données - NF Z42-013 / ISO 14641 : intégrité probatoire - Code civil art. 1366 : force probante électronique - Secret professionnel applicable selon le cas (mineur, santé, etc.)

4.5 Durée d'accès¶

• Durée maximale : 30 jours (configurable, borne dure)
• Durée par défaut : définie par le mandat
• Renouvellement : nouveau mandat obligatoire (pas de prolongation automatique)

5. Invariants de sécurité (non négociables)¶

6. Tensions identifiées (à préserver)¶

7. Résultats inacceptables¶

1. Existence d'un mécanisme caché d'accès permanent
2. Possibilité pour l'entreprise d'accéder au contenu sans mandat
3. Déclenchement par un seul administrateur
4. Accès non journalisé ou non signé
5. Absence d'ancrage probatoire
6. Clé temporaire réutilisable après expiration
7. Accès élargi au-delà du périmètre judiciaire
8. Impossibilité pour l'utilisateur de vérifier l'opération

8. Indicateurs de succès¶

Le besoin est satisfait si : 1. Un mandat valide (eIDAS) permet un accès contrôlé et limité après double validation 2. L'accès est traçable de bout en bout (mandat → validation → activation → consultation → destruction) 3. L'utilisateur peut auditer l'opération a posteriori via preuve composite 4. L'opération est juridiquement opposable (signatures, horodatage, ancrage) 5. Aucune altération du modèle zero-knowledge global n'est introduite 6. Les clés temporaires sont détruites de manière vérifiable

9. Dépendances¶

10. Positionnement stratégique¶

Ce module constitue : - Une garantie de conformité judiciaire pour ProbatioVault - Un argument de crédibilité institutionnelle face aux administrations et juridictions - Un élément central du brevet Legal PRE (803 - Fiche_Brevet_1_Legal_PRE) - Une brique différenciante face aux solutions cloud classiques (qui n'offrent pas d'accès judiciaire contrôlé en zero-knowledge)