PD-99 — Plan d'implémentation¶

1. Découpage en composants¶

1.1 Composants UI (Frontend iOS)¶

1.2 Services (Frontend iOS)¶

1.3 State Management¶

1.4 Composants Backend (existants)¶

2. Flux techniques¶

2.1 Flux nominal : Connexion email + mot de passe¶

┌─────────────┐                    ┌─────────────┐                    ┌─────────────┐
│   Client    │                    │   Backend   │                    │    Redis    │
└──────┬──────┘                    └──────┬──────┘                    └──────┬──────┘
       │                                  │                                  │
       │  1. GET /auth/srp-params         │                                  │
       │─────────────────────────────────>│                                  │
       │  {N, g, version}                 │                                  │
       │<─────────────────────────────────│                                  │
       │                                  │                                  │
       │  2. Génère a (256 bits)          │                                  │
       │     A = g^a mod N                │                                  │
       │                                  │                                  │
       │  3. POST /auth/login/challenge   │                                  │
       │     {email, A}                   │                                  │
       │─────────────────────────────────>│                                  │
       │                                  │  4. Lookup user (email)          │
       │                                  │  5. Génère b, calcule B          │
       │                                  │  6. Store session ──────────────>│
       │  {salt, B}                       │                                  │
       │<─────────────────────────────────│                                  │
       │                                  │                                  │
       │  7. K_auth = Argon2id(pwd, salt) │                                  │
       │     x = SHA3-256(salt || K_auth) │                                  │
       │     u = SHA3-256(PAD(A)||PAD(B)) │                                  │
       │     S = (B - k*g^x)^(a+u*x) mod N│                                  │
       │     K = SHA3-256(S)              │                                  │
       │     M1 = SHA3-256(A || B || K)   │                                  │
       │                                  │                                  │
       │  8. POST /auth/login/verify      │                                  │
       │     {email, M1}                  │                                  │
       │─────────────────────────────────>│  9. Get session <────────────────│
       │                                  │ 10. Calcule S, K, M1_expected    │
       │                                  │ 11. Vérifie M1 === M1_expected   │
       │                                  │ 12. Génère JWT + M2              │
       │                                  │ 13. Delete session ─────────────>│
       │  {accessToken, M2}               │                                  │
       │<─────────────────────────────────│                                  │
       │                                  │                                  │
       │ 14. M2_expected = SHA3-256(...)  │                                  │
       │ 15. Vérifie M2 === M2_expected   │                                  │
       │ 16. Store JWT (SecureStore)      │                                  │
       │ 17. Unlock Master Key local      │                                  │
       │                                  │                                  │

2.2 Flux connexion facilitée (biométrie)¶

┌─────────────┐                    ┌─────────────┐
│   Client    │                    │  Keychain   │
└──────┬──────┘                    └──────┬──────┘
       │                                  │
       │  1. Prompt Face ID / Touch ID    │
       │─────────────────────────────────>│
       │  2. Validation biométrique       │
       │<─────────────────────────────────│
       │                                  │
       │  3. Récupère credentials chiffrés│
       │     (email + K_auth dérivée)     │
       │─────────────────────────────────>│
       │  {email, encryptedCredentials}   │
       │<─────────────────────────────────│
       │                                  │
       │  4. Déchiffre avec clé biométrie │
       │  5. Exécute flux SRP standard    │
       │     (challenge → verify)         │
       │                                  │

2.3 Flux erreur (uniforme)¶

Cas d'erreur possibles :
- Email inconnu
- Mot de passe incorrect
- Compte non validé
- Compte suspendu
- Erreur serveur

                    ┌──────────────────────────────┐
Tous les cas ──────>│  Délai aléatoire 50-150ms    │
                    │  + Réponse HTTP 401          │
                    │  + Message neutre identique  │
                    └──────────────────────────────┘

2bis. Diagrammes Mermaid¶

Graphe de dépendances des composants¶

graph TD
    subgraph UI["Composants UI"]
        LS[LoginScreen.tsx]
        BLP[BiometricLoginPrompt.tsx]
        LF[LoginForm.tsx]
        PD[PasswordDisclaimer.tsx]
        AEM[AuthErrorMessage.tsx]
    end

    subgraph Services["Services"]
        SRP[srp.ts]
        API[api.ts]
        KD[keyDerivation.ts]
        STO[storage.ts]
        BIO[biometric.ts]
    end

    subgraph State["State Management"]
        UA[useAuth.ts]
        UAS[useAuthStore.ts]
        UB[useBiometric.ts]
    end

    subgraph Backend["Backend existant"]
        AC[auth.controller.ts]
        SS[srp.service.ts]
        SSS[srp-session-store.service.ts]
    end

    subgraph Infra["Infrastructure"]
        RED[(Redis)]
    end

    LS --> LF
    LS --> PD
    LS --> AEM
    LS --> BLP
    LS --> UA

    BLP --> UB
    BLP --> BIO

    LF --> UA

    UA --> SRP
    UA --> API
    UA --> KD
    UA --> STO
    UA --> UAS

    UB --> BIO
    UB --> STO

    API -->|HTTP| AC
    AC --> SS
    SS --> SSS
    SSS --> RED

    SRP -.->|Argon2id| KD
    BIO -.->|SecureStore| STO

Diagramme de séquence : connexion SRP-6a nominale¶

sequenceDiagram
    actor U as Utilisateur
    participant LS as LoginScreen
    participant UA as useAuth
    participant KD as keyDerivation.ts
    participant SRP as srp.ts
    participant API as api.ts
    participant AC as auth.controller.ts
    participant SS as srp.service.ts
    participant SSS as srp-session-store
    participant RED as Redis

    U->>LS: Saisit email + mot de passe
    LS->>UA: login(email, password)

    Note over UA,API: Phase 1 — Challenge
    UA->>API: GET /auth/srp-params
    API->>AC: getSrpParams()
    AC-->>API: {N, g, version}
    API-->>UA: {N, g, version}

    UA->>SRP: generateEphemeral()
    SRP-->>UA: {a, A}

    UA->>API: POST /auth/login/challenge {email, A}
    API->>AC: challenge(email, A)
    AC->>SS: createChallenge(email, A)
    SS->>SSS: storeSession(sessionId, {A, b, B, v})
    SSS->>RED: SET srp:session:id TTL=300s
    RED-->>SSS: OK
    AC-->>API: {salt, B}
    API-->>UA: {salt, B}

    Note over UA,SRP: Phase 2 — Dérivation + Preuve
    UA->>KD: deriveKauth(password, salt)
    Note right of KD: Argon2id(pwd, salt)<br/>OWASP params
    KD-->>UA: K_auth

    UA->>SRP: computeProof(A, B, K_auth, salt)
    Note right of SRP: x = SHA3-256(salt || K_auth)<br/>u = SHA3-256(PAD(A)||PAD(B))<br/>S = (B - k·g^x)^(a+u·x) mod N<br/>K = SHA3-256(S)<br/>M1 = SHA3-256(A || B || K)
    SRP-->>UA: {M1, K}

    Note over UA,API: Phase 3 — Verify
    UA->>API: POST /auth/login/verify {email, M1}
    API->>AC: verify(email, M1)
    AC->>SSS: getSession(sessionId)
    SSS->>RED: GET srp:session:id
    RED-->>SSS: {A, b, B, v}
    AC->>SS: verifyProof(session, M1)
    Note right of SS: Calcule S, K, M1_expected<br/>Vérifie M1 === M1_expected
    SS-->>AC: {M2, jwt}
    AC->>SSS: deleteSession(sessionId)
    SSS->>RED: DEL srp:session:id
    AC-->>API: {accessToken, M2}
    API-->>UA: {accessToken, M2}

    Note over UA,SRP: Phase 4 — Authentification mutuelle
    UA->>SRP: verifyServer(A, M1, K, M2)
    Note right of SRP: M2_expected = SHA3-256(A||M1||K)<br/>Vérifie M2 === M2_expected
    SRP-->>UA: OK

    UA->>STO: storeToken(accessToken)
    UA->>UAS: setMasterKey(K_master)
    UA-->>LS: Authentifié
    LS-->>U: Navigation écran principal

Diagramme de séquence : connexion facilitée (biométrie)¶

sequenceDiagram
    actor U as Utilisateur
    participant BLP as BiometricLoginPrompt
    participant UB as useBiometric
    participant BIO as biometric.ts
    participant STO as storage.ts
    participant UA as useAuth

    U->>BLP: Appui bouton biométrie
    BLP->>UB: authenticateWithBiometric()
    UB->>BIO: promptBiometric()
    BIO->>BIO: Face ID / Touch ID
    alt Biométrie réussie
        BIO-->>UB: success
        UB->>STO: getSecureCredentials()
        Note right of STO: Keychain protégé<br/>par biométrie
        STO-->>UB: {email, encryptedKauth}
        UB->>UB: déchiffre credentials
        UB->>UA: login(email, K_auth)
        Note over UA: Exécute flux SRP standard<br/>(cf. diagramme nominal)
        UA-->>BLP: Authentifié
        BLP-->>U: Navigation écran principal
    else Biométrie annulée / échouée
        BIO-->>UB: failure
        UB-->>BLP: cancelled
        BLP-->>U: Retour écran login classique
    end

3. Mapping invariants vers mecanismes¶

Note : INV-03 (aucun humain ne peut connaître le mot de passe) et INV-10 (login = acte engageant) sont des exigences de gouvernance non testables par les scénarios applicatifs (cf. spec).

4. Mapping criteres d'acceptation vers mecanismes¶

5. Mapping tests vers mecanismes et observables¶

6. Gestion des erreurs¶

6.1 Message d'erreur unique (conformite spec ERR-01/02, CA-07, CA-09)¶

Texte exact obligatoire pour tout echec d'authentification :

La connexion a échoué. Vérifiez vos informations et réessayez.

Ce message unique est affiché pour tous les cas suivants, sans distinction :

6.2 Cas particulier : biometrie (ERR-03)¶

6.3 Principe d'indiscernabilite (conformite INV-09, ERR-01/02)¶

Aucun code d'erreur distinct n'est expose ni loggue de maniere a permettre une inference.

6.4 Logging securise et non-discriminant¶

// AUTORISÉ - Log unique non discriminant
logger.info('auth.login.attempt', {
  emailHash: sha256(email),
  success: false,  // Seule information : succès ou échec
  timestamp: Date.now()
});

// INTERDIT - Logs discriminants
logger.info('auth.login.failure.invalid_email', ...);    // JAMAIS
logger.info('auth.login.failure.wrong_password', ...);   // JAMAIS
logger.info('auth.login.failure.account_suspended', ...); // JAMAIS

Conformite CA-07/CA-09/INV-09 : Aucun element observable (message, code, timing, log) ne permet de distinguer la cause de l'echec.

7. Impacts securite¶

7.1 Risques identifies¶

7.2 Mitigations implementees¶

7.3 Journalisation securite¶

7.4 Conformite¶

8. Hypotheses techniques¶

9. Points de vigilance (risques, dette, pieges)¶

9.1 Risques techniques¶

• Latence SRP : 2 requêtes séquentielles + Argon2id (~500ms). Prévoir UX loading approprié.
• Expo Go vs EAS : Argon2id non disponible en Expo Go. Tester en build EAS.
• Biométrie iOS : Comportement différent Face ID vs Touch ID. Tester les deux.
• Session Redis : Si Redis down, login impossible. Prévoir fallback ou circuit breaker.

9.2 Dette technique identifiee¶

• Mode démo avec auth locale : à supprimer avant production.
• Refresh token non implémenté : JWT unique avec expiration.
• Rotation credentials biométrie : non planifiée.

9.3 Pieges a eviter¶

• Ne jamais logger le mot de passe, même partiellement.
• Ne jamais différencier les messages d'erreur selon le cas.
• Ne jamais permettre la biométrie sans auth initiale préalable.
• Toujours vérifier M2 côté client (authentification mutuelle).
• Toujours zeroize les buffers contenant des secrets après usage.

9.4 Limites connues¶

• JavaScript : strings immutables, zeroize limité pour K_auth string.
• Expo SecureStore : 2KB max par clé, suffisant pour credentials.
• Biométrie : contournable si device jailbreaké.

10. Hors perimetre¶

Document généré selon le template PD-XX-plan.md