📝 RETOUR D'EXPÉRIENCE (REX)¶

PD-25 — Authentification SRP-6a (Phase 2 : preuve, clé de session, token)

📌 EPIC ➡️ PD-189 — CRYPTO

📌 Artefact produit ➡️ PD-25-rex.md

1. Résumé exécutif¶

Synthèse : L'implémentation PD-25 respecte l'architecture Zero-Knowledge SRP-6a et couvre la majorité des invariants de sécurité. Un écart majeur a été identifié concernant le timing de dérivation de la clé de session (INV-3). La traçabilité audit (INV-7) a été correctement implémentée. Statut : ACCEPTÉ AVEC RÉSERVES.

2. Points fluides¶

2.1 Intégration AuditService (INV-7)¶

L'intégration de l'AuditService dans AuthService s'est déroulée sans friction :

• Import AuditModule dans auth.module.ts : trivial
• Injection AuditService dans le constructeur : pattern NestJS standard
• Appels auditService.log() aux points clés : code fourni dans le plan

Temps réel : ~30 minutes (vs 2h estimées)

2.2 Gestion des erreurs déterministe¶

La matrice d'erreurs définie en spec §6 était directement transposable en code :

// Pattern clair et répétable
if (!session) throw new UnauthorizedException('Session SRP expirée ou invalide');
if (expired) throw new UnauthorizedException('Session SRP expirée');
if (m1Invalid) throw new UnauthorizedException('Identifiants invalides');

2.3 Suppression session Redis¶

Le mécanisme de nettoyage session après usage (succès ou échec) était déjà implémenté dans PD-24, facilitant la garantie d'usage unique.

3. Points difficiles¶

3.1 Séquencement calcul K vs validation M1 (E-01)¶

Problème : Le protocole SRP-6a nécessite de calculer K' (candidat) pour vérifier M1 (car M1 = SHA3-256(A||B||K)). La distinction entre "K' candidat" et "K établie" n'était pas explicite dans l'implémentation initiale.

Impact : Le code retourne sessionKey dans l'objet résultat même si M1 est invalide, violant INV-3 ("clé de session dérivée qu'après vérification réussie").

Difficulté : Tension entre l'algorithme SRP qui impose de calculer K' avant de pouvoir vérifier M1, et l'invariant qui interdit "d'établir" K avant validation.

Solution recommandée : Refactorer verifyClientProof() pour : 1. Calculer K' comme variable locale 2. Vérifier M1 avec K' 3. Ne retourner K que si M1 valide (actuellement, K est toujours calculée et retournée)

3.2 Distinction sémantique "candidat" vs "établie"¶

Le plan d'implémentation §2.1 documente bien cette distinction :

"K' est une valeur candidate [...] La clé de session K n'est établie qu'après vérification réussie de M1"

Cette subtilité protocolaire n'était pas immédiatement évidente et a nécessité une relecture approfondie de RFC 5054.

4. Hypothèses révélées tardivement¶

4.1 Disponibilité Redis (H-1)¶

L'hypothèse "Redis disponible et opérationnel" n'a pas de fallback défini. En cas d'indisponibilité Redis, toute authentification SRP échoue silencieusement.

Recommandation : Ajouter health check Redis dans le endpoint /health et circuit breaker.

4.2 Vérification M2 côté client (H-6)¶

L'hypothèse "Client implémente vérification M2" n'est pas vérifiable côté serveur. Si le client ignore M2, l'authentification mutuelle n'est pas garantie.

Impact : Réduit le niveau de sécurité de "authentification mutuelle" à "authentification client uniquement".

4.3 Synchronisation horloges (H-3)¶

Le TTL session Redis (5 min) suppose des horloges synchronisées. Un décalage serveur > 5 min invaliderait toutes les sessions.

5. Invariants complexes¶

5.1 INV-3 : Clé de session après vérification¶

Complexité : ⭐⭐⭐ (⅗)

Cet invariant entre en tension avec l'algorithme SRP-6a lui-même. La solution requiert de distinguer clairement : - Calcul de K' (nécessaire pour vérifier M1) - Établissement de K (après M1 validé)

Le code actuel ne fait pas cette distinction explicitement.

5.2 INV-4 : Clé de session jamais persistée¶

Complexité : ⭐ (⅕)

Facile à garantir : variable locale dans scope fonction, pas d'appel à Redis/DB avec K.

5.3 INV-7 : Traçabilité¶

Complexité : ⭐⭐ (⅖)

L'infrastructure AuditService existante rendait l'implémentation straightforward. Seul point d'attention : ne pas logger d'éléments sensibles (M1, K).

6. Dette technique¶

Total dette : ~6h de travail

7. Risques résiduels¶

Risque résiduel global : Modéré — Acceptable après correction E-01.

8. Améliorations processus¶

8.1 Spécification¶

• Amélioration : Préciser dans la spec la distinction "calcul K'" vs "établissement K" pour lever l'ambiguïté INV-3.
• Template : Ajouter une section "Contraintes protocolaires" pour les protocoles crypto avec séquencement complexe.

8.2 Revue de code¶

• Amélioration : Checklist spécifique "timing secrets cryptographiques" pour les revues de code crypto.
• Outil : Ajouter règle SonarQube custom pour détecter les retours de clés avant validation.

8.3 Tests¶

• Amélioration : Ajouter tests négatifs explicites : "K ne doit PAS être dans le résultat si M1 invalide".

9. Enseignements clés¶

9.1 Pour ce projet¶

1. SRP-6a impose un séquencement contraint : K' doit être calculée pour vérifier M1, mais ne doit être "établie" (retournée/utilisée) qu'après. Cette subtilité doit être documentée et testée explicitement.

2. Les invariants "négatifs" sont plus subtils : "Ne PAS dériver K avant validation" est plus difficile à garantir que "tracer toutes les tentatives".

3. L'intégration audit NestJS est triviale : Le pattern Module/Service/Inject rend l'ajout de traçabilité quasi-automatique.

9.2 Pour les futurs développements¶

1. Documenter les tensions protocol/invariants : Quand un protocole impose un séquencement, le documenter explicitement dans le plan d'implémentation.

2. Tester les non-comportements : Ajouter des tests qui vérifient ce qui NE doit PAS se produire (ex: K non retournée si échec).

3. Distinguer calcul/établissement : Pour tout secret cryptographique, distinguer "valeur candidate calculée" de "valeur établie/utilisable".

10. Métriques¶

Fin du retour d'expérience PD-25.