PD-262 — Specification Review (v2)¶
Statut des ecarts v1¶
| Ecart v1 | Objet | Statut v2 |
|---|---|---|
| E-01 | Tests TC-INV-* sans scenario GIVEN/WHEN/THEN | RESOLU — 5 scenarios ajoutes en §5.1 |
| E-02 | TC-NR-02 sans scenario | RESOLU — scenario detaille ajoute en §6.1 |
| E-03 | Frontiere purge vs blobs chiffres ambigue | RESOLU — definitions §3.1, CA-15, TC-NOM-12 |
| E-04 | Mecanisme persistance lockout non specifie | RESOLU — §3.6, Keychain kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly |
| E-05 | "Operations sensibles" non defini | RESOLU — definition §3.1 |
| E-06 | Algorithme hash device_id_pseudo non specifie | RESOLU — SHA-256(identifierForVendor.uuidString UTF-8) |
| E-07 | Protection stockage lockout contre auto-corruption | RESOLU — first_launch_clean, ERR-09, reconstruction boot |
| E-08 | Feature flag QA vecteur contournement | RESOLU — build flag compile non mutable runtime |
| E-09 | Sequence non atomique MONITORED->LOCKED_PERSISTENT | PARTIELLEMENT RESOLU — ERR-10 ajoute, mais voir E-12 ci-dessous |
| E-10 | Duplication TC-NOM-09 / TC-ERR-01 | RESOLU — TC-NOM-09 fusionne, TC-ERR-01 supprime |
| E-11 | Retry purge non borne | RESOLU — max 3 retries, 1s intervalle, TC-ERR-11 |
Ecarts identifies (v2)¶
E-12 — Fenetre crash entre purge et ecriture lockout : absence de marqueur write-ahead¶
Type : Hypothese dangereuse Reference : Spec §5 Flux F3, §3.6, ERR-10, INV-262-09 Description : Le flux F3 specifie la sequence : (1) detection, (2) TAMPERED_SESSION, (3) purge immediate, (4) lockout affiche, (5) LOCKED_PERSISTENT. Le flag lockout_persistent_flag est ecrit a l'etape 5. Si le process est tue entre les etapes 3 et 5, la purge a partiellement efface des donnees mais aucun marqueur persistant n'existe pour detecter cet etat au redemarrage. Au boot, first_launch_clean=true (de l'installation originale) et lockout_persistent_flag absent = etat interprete comme nominal. La spec dit "etat transitoire incomplet interprete en LOCKED_PERSISTENT" (§3.6) mais ne specifie pas quel observable permet de detecter un etat transitoire incomplet sans marqueur write-ahead. ERR-10 contractualise le resultat attendu mais pas le mecanisme de detection. Impact : Fenetre de contournement par kill de process pendant la purge. Donnees partiellement purgees mais app relancee en mode nominal. Gravite : Majeur
E-13 — Bootstrapping first_launch_clean : "app deja initialisee" non defini operationnellement¶
Type : Ambiguite Reference : Spec §3.1 (premier lancement clean), §3.6, ERR-09 Description : §3.6 dit "si lockout_persistent_flag est absent ET first_launch_clean est absent alors que l'app est deja initialisee, fail-closed". La condition "app deja initialisee" n'est pas definie operationnellement. Sur un vrai premier lancement, ni lockout_persistent_flag ni first_launch_clean n'existent encore. Comment le module distingue-t-il "premier lancement reel" de "donnees effacees par attaquant" ? Si first_launch_clean est le marqueur d'initialisation lui-meme, sa creation initiale est un bootstrapping non contractualise. Si un autre indicateur (base locale, fichiers app) sert de discriminant, il n'est pas identifie dans la spec. Impact : Risque de fail-closed au premier lancement reel, ou inversement de bypass par suppression selective du marqueur. Gravite : Majeur
E-14 — TC-INV-02 : paradoxe de testabilite JS bypass vs environment gating¶
Type : Non testable Reference : Tests §5.1 TC-INV-02, Spec INV-262-07, INV-262-02 Description : TC-INV-02 suppose "Couche JS instrumentee pour retarder/inhiber l'affichage lockout" sur un build ou le module est actif. INV-262-07 impose que le module est inactif en DEBUG. Instrumenter le runtime JS sur un build RELEASE/TESTFLIGHT sans jailbreak ni Frida est non trivial. Avec jailbreak ou Frida, le module detecterait la compromission avant que l'instrumentation JS ne soit en place. Le scenario est auto-contradictoire dans la matrice d'environnements contractualisee. Un build QA avec flag compile pourrait servir de vehicule de test, mais TC-INV-02 ne le precise pas. Impact : INV-262-02 (native authority) repose sur un test dont la faisabilite n'est pas demontree dans les contraintes d'environnement. Gravite : Majeur
E-15 — Cause "primaire" en detection concurrente : critere de selection non defini¶
Type : Ambiguite Reference : Spec ERR-07, Tests TC-ERR-07 Description : ERR-07 dit "conserver cause primaire + causes secondaires en audit local si disponible". Le critere de selection de la cause primaire (premier signal temporel ? ordre predetermine ? severite ?) n'est pas contractualise. TC-ERR-07 verifie l'unicite du lockout et la retention de la cause primaire mais ne specifie pas comment la "cause primaire" est determinee. Impact : Deux implementations pourraient rapporter des reason_code differents pour le meme scenario de detection concurrente. Gravite : Mineur
E-16 — Pas de test pour le bootstrapping nominal du premier lancement¶
Type : Incoherence Spec<->Tests Reference : Spec §3.6 (premier lancement clean), Tests §3 TC-NOM-01 Description : TC-NOM-01 teste le cold start sur "device reel non compromis" mais suppose l'app deja fonctionnelle (etat MONITORED). Aucun test ne couvre le scenario de tout premier lancement ou first_launch_clean doit etre cree et ou ni lockout ni initialisation prealable n'existent. Le chemin bootstrapping (aucune donnee -> creation first_launch_clean -> MONITORED) n'est pas couvert. Impact : Le chemin d'initialisation le plus fragile (aucune donnee locale) n'est pas valide par un test. Gravite : Mineur
Synthese¶
| Gravite | Nombre |
|---|---|
| Bloquant | 0 |
| Majeur | 3 |
| Mineur | 2 |
Les 11 ecarts v1 sont resolus (10 completement, 1 partiellement). Les 5 ecarts v2 portent sur : (1) l'absence de marqueur write-ahead pour detecter un crash pendant la purge (E-12, majeur), (2) le bootstrapping de first_launch_clean sans definition operationnelle de "app deja initialisee" (E-13, majeur), (3) le paradoxe de testabilite du bypass JS dans les contraintes d'environnement (E-14, majeur), et deux mineurs sur la selection de cause primaire et l'absence de test bootstrapping.