PD-174 — Auto-lock configurable avec effacement du cache sensible (iOS)¶

Références¶

• EPIC : MOBILE-IOS
• JIRA : PD-174
• Repo(s) concernés : mobile-ios

Objectif¶

Renforcer la sécurité de l'application iOS en implémentant un mécanisme de verrouillage automatique configurable, déclenché par l'inactivité utilisateur et/ou le passage en arrière-plan, avec effacement systématique des données sensibles mises en cache.

Description fonctionnelle¶

L'application iOS doit se verrouiller automatiquement après une période d'inactivité configurable par l'utilisateur ou lors d'un passage en arrière-plan.

Lors du verrouillage automatique :

• l'utilisateur est redirigé vers l'écran de déverrouillage existant (PIN et/ou biométrie) ;
• l'accès aux écrans protégés est bloqué tant que l'app n'est pas déverrouillée ;
• les données sensibles temporairement stockées sont effacées afin d'éviter toute exposition en cas d'accès non autorisé.

Le comportement de verrouillage doit être transparent pour l'utilisateur, sans fuite d'informations sensibles à l'écran ou en mémoire.

Périmètre¶

Inclus¶

• Verrouillage automatique après un délai d'inactivité configurable (ex. 30s, 1 min, 2 min, 5 min, 10 min).
• Option permettant de déclencher le verrouillage lors du passage de l'application iOS en arrière-plan.
• Redirection vers l'écran de déverrouillage existant (PIN / biométrie).
• Effacement des données sensibles en cache à chaque verrouillage automatique.
• Conservation sécurisée de la préférence de délai de verrouillage.
• Interface de configuration dans les paramètres de sécurité de l'application iOS.

Exclu¶

• Portage ou implémentation Android.
• Modification du flux de login initial.
• Synchronisation cloud des préférences de verrouillage.
• Gestion MDM/MAM ou politiques de sécurité imposées par iOS.
• Modification du mécanisme de déverrouillage existant (PIN / biométrie).

Contraintes¶

• Sécurité
• Aucune donnée sensible ne doit rester accessible après un auto-lock.
• Aucun log ne doit contenir d'informations liées au PIN, à la biométrie ou aux délais de verrouillage.

• L'accès aux écrans protégés est strictement interdit tant que l'app n'est pas déverrouillée.

• Performance

• Le mécanisme de timer ne doit pas dégrader les performances UI.

• Le verrouillage ne doit pas provoquer de crash ni de boucle de navigation.

• UX

• Toute interaction utilisateur valide doit réinitialiser le délai d'inactivité.
• Aucun affichage fugitif de données sensibles ne doit apparaître lors du lock/unlock.

• Le déverrouillage doit être fluide et cohérent avec l'expérience existante.

• Compatibilité iOS

• Respect du cycle de vie iOS (foreground / background).
• Utilisation conforme des mécanismes iOS de protection écran et données.

Hypothèses¶

• Un écran de déverrouillage (PIN / biométrie) existe déjà dans l'application iOS.
• Les mécanismes de cache (mémoire, SecureStore, cache UI) sont identifiables et peuvent être invalidés de manière ciblée.
• Les préférences utilisateur peuvent être stockées localement de manière sécurisée sur iOS.
• L'application iOS permet de détecter de manière fiable l'inactivité utilisateur et les transitions d'état.

Invariants de sécurité¶

Flux nominaux¶

FN-01 : Verrouillage par inactivité¶

1. L'utilisateur cesse d'interagir avec l'application.
2. Le timer d'inactivité s'écoule jusqu'au délai configuré (INV-01).
3. L'application déclenche le verrouillage (INV-03).
4. Les données sensibles en cache sont effacées (INV-02).
5. L'utilisateur est redirigé vers l'écran de déverrouillage (INV-06).
6. L'accès aux écrans protégés est bloqué.

FN-02 : Verrouillage par passage en arrière-plan¶

1. L'utilisateur bascule l'application en arrière-plan.
2. Le verrouillage est déclenché immédiatement (INV-04).
3. Les données sensibles en cache sont effacées (INV-02).
4. Au retour en foreground, l'écran de déverrouillage est affiché (INV-06).

FN-03 : Déverrouillage¶

1. L'écran de déverrouillage est présenté.
2. L'utilisateur s'authentifie (PIN ou biométrie).
3. L'état passe à déverrouillé, le timer d'inactivité redémarre (INV-01).
4. L'utilisateur retrouve l'accès aux écrans protégés.

FN-04 : Configuration du délai¶

1. L'utilisateur accède aux paramètres de sécurité.
2. Il sélectionne un délai parmi les options (30s, 1 min, 2 min, 5 min, 10 min).
3. La préférence est stockée localement de manière sécurisée.
4. Le nouveau délai s'applique immédiatement au timer courant.

Diagrammes¶

Diagramme d'états -- Cycle de verrouillage¶

Le cycle de vie de l'application comprend 4 états distincts. Les transitions respectent les invariants INV-01 (reset timer), INV-03 (pas de double-lock) et INV-04 (lock immédiat en background).

stateDiagram-v2
    [*] --> UNLOCKED : Lancement app / Authentification réussie

    UNLOCKED --> LOCKING : Timer expiré (INV-01)\nou Background (INV-04)
    UNLOCKED --> UNLOCKED : Interaction utilisateur\n[reset timer] (INV-01)

    LOCKING --> LOCKED : Cache effacé (INV-02)\n+ Navigation bloquée (INV-06)
    LOCKING --> LOCKING : [guard] Déjà en cours (INV-03)

    LOCKED --> UNLOCKED : PIN / Biométrie valide
    LOCKED --> LOCKED : Tentative échouée

    note right of LOCKING
        Etat transitoire :
        1. Effacement données sensibles
        2. Masquage UI (INV-06)
        3. Redirection LockScreen
    end note

    note right of UNLOCKED
        Timer actif :
        Chaque interaction
        remet le compteur a zero
    end note

Diagramme de séquence -- Verrouillage par inactivité (FN-01)¶

Ce diagramme détaille l'orchestration entre le hook d'activité, le store de sécurité, le cache sensible et la navigation lors d'un verrouillage par expiration du timer.

sequenceDiagram
    participant U as Utilisateur
    participant UA as useUserActivity
    participant AL as useAutoLock
    participant SS as useSecurityStore
    participant C as Cache sensible
    participant N as Navigation

    U ->> UA : Dernière interaction
    UA ->> SS : update lastActivityAt

    Note over AL : Timer vérifie toutes les 10s

    AL ->> SS : now - lastActivityAt > timeout ?
    SS -->> AL : true (délai expiré)

    AL ->> SS : isLockingRef = true (INV-03)
    AL ->> C : clearSensitiveData() (INV-02)
    C -->> AL : Données effacées
    AL ->> SS : lock()
    SS ->> N : Afficher LockScreen (INV-06)
    N -->> U : Ecran de déverrouillage

    U ->> N : PIN / Biométrie
    N ->> SS : unlock()
    SS ->> AL : Reset timer (INV-01)
    AL -->> U : Accès restauré

Diagramme de séquence -- Verrouillage par arrière-plan (FN-02)¶

Ce diagramme illustre le verrouillage immédiat lors du passage en arrière-plan (INV-04), sans attente du timer d'inactivité.

sequenceDiagram
    participant OS as iOS (AppState)
    participant AL as useAutoLock
    participant SS as useSecurityStore
    participant C as Cache sensible
    participant N as Navigation

    OS ->> AL : AppState = "background" (INV-04)
    AL ->> SS : isLockingRef = true (INV-03)
    AL ->> C : clearSensitiveData() (INV-02)
    C -->> AL : Données effacées
    AL ->> SS : lock()

    Note over OS : Utilisateur revient

    OS ->> AL : AppState = "active"
    AL ->> SS : isLocked ?
    SS -->> AL : true
    SS ->> N : Afficher LockScreen (INV-06)

Cas d'erreur¶

Liens documentaires¶

• Architecture :
• Mobile iOS Security Architecture
• EPIC :
• MOBILE-IOS
• Sécurité :
• Politique de gestion des données sensibles côté client iOS