📄 SPÉCIFICATION CANONIQUE CONTRACTUELLE¶

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

📌 EPIC
➡️ PD-189 — CRYPTO

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

1. Objectif¶

Définir de manière formelle, exhaustive et contractuelle les exigences relatives à la Phase 2 du processus d’authentification SRP-6a, incluant :

• la vérification cryptographique des preuves SRP-6a ;
• l’établissement d’une clé de session partagée entre le client et le serveur ;
• l’émission d’un jeton d’authentification (JWT) conditionnée à une authentification réussie.

Cette spécification fait loi. Toute implémentation doit s’y conformer strictement.

2. Périmètre / Hors périmètre¶

2.1 Périmètre¶

La présente spécification couvre exclusivement :

• la réception et le traitement des éléments cryptographiques de preuve SRP-6a ;
• la vérification de la preuve client conformément au protocole SRP-6a ;
• la dérivation d’une clé de session authentifiée ;
• la validation mutuelle client/serveur (preuve serveur) ;
• la génération d’un jeton JWT suite à une authentification réussie ;
• la gestion des erreurs liées à l’échec de la preuve SRP.

2.2 Hors périmètre¶

Les éléments suivants sont explicitement hors périmètre :

• la Phase 1 de l’authentification SRP (enrôlement, salt, verifier) ;
• la gestion du mot de passe côté client ;
• le stockage ou la rotation des clés de signature JWT ;
• la gestion de session long terme ou de refresh token ;
• l’autorisation (droits, rôles, permissions) ;
• toute alternative au protocole SRP-6a.

Toute règle non testable relevant de ces éléments est considérée hors périmètre.

3. Définitions¶

4. Invariants (non négociables)¶

Les règles suivantes sont non négociables :

1. Le serveur ne doit jamais connaître ni stocker le mot de passe utilisateur.
2. Toute authentification réussie doit résulter d’une preuve SRP-6a valide.
3. La clé de session ne doit être exposée, retournée ou utilisée hors vérification cryptographique qu’après vérification réussie de la preuve client.
4. La clé de session ne doit jamais être persistée.
5. Un jeton JWT ne peut être émis qu’après authentification SRP réussie.
6. Aucun élément d’échange SRP ne doit permettre la récupération du secret utilisateur.
7. Toute tentative d’authentification est traçable.

Chaque invariant doit être vérifiable par test ou audit.

5. Flux nominaux¶

5.1 Vérification de la preuve SRP¶

1. Le client transmet sa preuve SRP (M1) au serveur.
2. Le serveur récupère l’état de session SRP associé.
3. Le serveur vérifie la validité cryptographique de la preuve.
4. La preuve est considérée valide ou invalide.

5.2 Établissement de la clé de session¶

1. La preuve client est validée.
2. La clé de session est considérée établie et disponible pour l’étape courante uniquement.

5.3 Validation serveur et émission du token¶

1. Le serveur génère une preuve serveur (M2).
2. Le serveur émet un JWT représentant une authentification réussie.
3. Le serveur retourne au client la preuve serveur et le JWT.

5bis. Diagrammes Mermaid¶

5bis.1 Diagramme de sequence — Authentification SRP-6a Phase 2¶

Ce diagramme couvre les flux 5.1, 5.2 et 5.3. Les invariants references sont traces en annotations.

sequenceDiagram
    participant C as Client
    participant S as Serveur (Auth)
    participant Store as Session Store
    participant JWT as JWT Service

    Note over C,S: [INV-1] Le serveur ne connait jamais le mot de passe

    C->>S: POST /auth/srp/verify { srpSessionId, M1 }
    activate S

    S->>Store: Recuperer session SRP (srpSessionId)
    alt Session inexistante ou expiree
        Store-->>S: null / expired
        Note right of S: [INV-7] Tentative tracee
        S-->>C: 401 Unauthorized (session invalide)
    else Session valide
        Store-->>S: { A, b, B, v, salt, ... }

        Note over S: Flux 5.1 — Verification preuve client
        S->>S: Calculer S = (A * v^u)^b mod N
        S->>S: Calculer K = H(S) (cle de session)
        S->>S: Calculer M1_expected = H(H(N)^H(g), H(I), salt, A, B, K)
        S->>S: Comparer M1 == M1_expected

        alt M1 invalide
            Note right of S: [INV-7] Echec trace
            S->>Store: Invalider session SRP
            S-->>C: 401 Unauthorized (preuve invalide)
        else M1 valide
            Note over S: Flux 5.2 — Cle de session etablie
            Note right of S: [INV-3] K disponible uniquement apres M1 valide
            Note right of S: [INV-4] K jamais persistee

            Note over S: Flux 5.3 — Validation serveur + emission token
            S->>S: Calculer M2 = H(A, M1, K)
            Note right of S: [INV-6] Aucun element ne revele le secret

            S->>JWT: Emettre JWT (userId, claims)
            Note right of JWT: [INV-5] JWT emis uniquement apres SRP OK
            JWT-->>S: token

            S->>Store: Supprimer session SRP (usage unique)
            Note right of S: [INV-2] Auth = preuve SRP valide

            S-->>C: 200 OK { M2, jwt }
        end
    end

    deactivate S

    C->>C: Verifier M2 (validation mutuelle)

5bis.2 Diagramme d’etat — Cycle de vie d’une session SRP¶

La session SRP traverse au minimum 4 etats, du demarrage en Phase 1 jusqu’a sa destruction apres Phase 2.

stateDiagram-v2
    [*] --> CREATED : Phase 1 complete (A, B, salt echanges)

    CREATED --> VERIFYING : Reception M1 (preuve client)
    Note right of CREATED : [INV-3] K non disponible

    VERIFYING --> VERIFIED : M1 valide — K etablie
    Note right of VERIFIED : [INV-2] Preuve SRP valide
    Note right of VERIFIED : [INV-4] K ephemere, non persistee

    VERIFYING --> FAILED : M1 invalide
    Note right of FAILED : [INV-7] Echec trace

    VERIFIED --> CONSUMED : JWT emis + session detruite
    Note right of CONSUMED : [INV-5] JWT conditionne a SRP OK

    CREATED --> EXPIRED : TTL depasse
    Note right of EXPIRED : [INV-7] Tentative sur session expiree tracee

    FAILED --> [*] : Session invalidee
    CONSUMED --> [*] : Session supprimee
    EXPIRED --> [*] : Session purgee

6. Cas d’erreur¶

Les situations suivantes doivent être explicitement gérées :

• preuve SRP invalide ;
• session SRP inexistante ou expirée ;
• incohérence des paramètres cryptographiques ;
• tentative de réutilisation d’une preuve ;
• erreur lors de la dérivation de la clé de session ;
• erreur interne lors de la génération du JWT.

Chaque cas d’erreur doit produire une réponse déterministe, contrôlée et traçable.

7. Critères d’acceptation (testables)¶

• Une preuve SRP valide conduit à une authentification réussie.
• Une preuve SRP invalide empêche toute émission de JWT.
• La clé de session n’est jamais persistée.
• Aucun secret utilisateur n’est exposé ou dérivable.
• Une tentative d’authentification invalide est traçable.
• La preuve serveur permet au client de vérifier l’authenticité du serveur.

8. Scénarios de test (Given / When / Then)¶

Scénario 1 — Authentification réussie¶

Given une session SRP valide et une preuve client correcte
When la preuve est vérifiée
Then la clé de session est établie et un JWT est émis

Scénario 2 — Preuve invalide¶

Given une preuve client incorrecte
When la vérification est effectuée
Then l’authentification échoue et aucun JWT n’est émis

Scénario 3 — Session SRP expirée¶

Given une session SRP expirée
When une preuve est reçue
Then l’authentification échoue explicitement

9. Hypothèses explicites¶

• La Phase 1 du protocole SRP-6a est correctement implémentée.
• Le système dispose des paramètres cryptographiques SRP requis.
• Les échanges réseau sont protégés au niveau transport.
• Le système est capable de journaliser des événements de sécurité.

10. Points à clarifier¶

Les éléments suivants doivent être explicitement définis avant implémentation :

1. Durée de validité maximale d’une session SRP.
2. Politique exacte de génération et de durée de vie du JWT.
3. Claims obligatoires contenus dans le JWT.
4. Niveau de journalisation attendu pour les échecs SRP.
5. Exigences réglementaires ou normatives applicables.

Fin de la spécification canonique.