PD-264 — Scénarios de test de référence¶

Préambule (périmètre de test)¶

Environnement de référence :
CI rapide avec TSA mock RFC 3161 déterministe (fixtures figées).
Nightly avec TSA qualifiée réelle + archivage probatoire.
Préconditions communes :
Base de données initialisée avec schéma timestamp_tokens et contrainte d'unicité sur nonce.
Journal append-only et pipeline Merkle actifs.
Outils disponibles : openssl, suite Prolog RFC 3161.
Convention :
nonce_A = valeur binaire fixe de 16 octets (hex fixture).
nonce_B = autre valeur binaire fixe de 16 octets.
Toute vérification est réalisée sans hypothèse implicite, sur artefacts horodatés et traçables.

1) Matrice de couverture INV/CA -> TC¶

Exigence	Test(s) de couverture
INV-264-01	TC-264-01, TC-264-08
INV-264-02	TC-264-02, TC-264-04
INV-264-03	TC-264-03, TC-264-04
INV-264-04	TC-264-07
INV-264-05	TC-264-05, TC-264-06
INV-264-06	TC-264-02, TC-264-03, TC-264-05
INV-264-07	TC-264-02, TC-264-03, TC-264-05
INV-264-08	TC-264-09
INV-264-09	TC-264-04, TC-264-14
INV-264-10	TC-264-14
INV-264-11	TC-264-04, TC-264-05

| INV-264-envelope-encryption | TC-264-18 |

| INV-264-12 | TC-264-11 |

| INV-264-13 | TC-264-19 | | CA-264-01 | TC-264-01 | | CA-264-02 | TC-264-02 | | CA-264-03 | TC-264-03 | | CA-264-04 | TC-264-04 | | CA-264-05 | TC-264-05, TC-264-06 | | CA-264-06 | TC-264-02, TC-264-03, TC-264-05, TC-264-19 | | CA-264-07 | TC-264-02, TC-264-03, TC-264-05, TC-264-13, TC-264-19 | | CA-264-08 | TC-264-04 | | CA-264-09 | TC-264-14 | | CA-264-10 | TC-264-15 | | CA-264-11 | TC-264-16 | | CA-264-12 | TC-264-17 |

2) Scénarios de test de référence¶

TC-264-01 — Requête sans nonce refusée¶

Prérequis : requête RFC 3161 sans champ nonce.
Action : soumettre la requête au flux probatoire (point d'entrée de l'automate).
Résultat attendu : refus explicite (fail-closed) ; état REQUEST_EMITTED non atteint ; aucun effet persistant ; confirmation que la requête n'entre pas dans le cycle d'états (garde d'entrée).
Couvre : INV-264-01, CA-264-01.

TC-264-02 — Réponse TSA sans nonce rejetée¶

Prérequis : requête valide émise avec nonce_A ; réponse mock sans nonce.
Action : injecter la réponse dans la phase validation.
Résultat attendu : transition RESPONSE_RECEIVED -> RESPONSE_REJECTED ; aucune écriture DB ; aucun append audit/Merkle.
Couvre : INV-264-02, INV-264-06, INV-264-07, CA-264-02, CA-264-06, CA-264-07.

TC-264-03 — Réponse TSA avec nonce mismatch rejetée¶

Prérequis : requête avec nonce_A ; réponse avec nonce_B.
Action : valider la réponse.
Résultat attendu : rejet déterministe ; motif mismatch ; aucun effet persistant (DB/audit/Merkle).
Couvre : INV-264-03, INV-264-06, INV-264-07, CA-264-03, CA-264-06, CA-264-07.

TC-264-04 — Réponse TSA avec nonce identique inédit acceptée¶

Prérequis : requête avec nonce_A inédit ; réponse RFC valide avec nonce_A.
Action : exécuter la validation complète.
Résultat attendu : RESPONSE_RECEIVED -> RESPONSE_ACCEPTED -> TOKEN_PERSISTED ; nonce stocké en BYTEA 16 octets ; token DER structurellement valide.
Couvre : INV-264-02, INV-264-03, INV-264-05, INV-264-09, INV-264-11, CA-264-04, CA-264-08.

TC-264-05 — Rejeu : nonce déjà persisté rejeté (voie métier)¶

Prérequis : un token déjà accepté avec nonce_A existe.
Action : tenter d'accepter une nouvelle réponse portant nonce_A.
Résultat attendu : rejet avec motif duplication ; pas de nouvelle ligne timestamp_tokens ; pas d'append audit/Merkle.
Couvre : INV-264-05, INV-264-06, INV-264-07, INV-264-11, CA-264-05, CA-264-06, CA-264-07.

TC-264-06 — Défense en profondeur : collision concurrente et unicité DB¶

Prérequis : deux validations concurrentes utilisent le même nonce inédit.
Action : lancer les deux tentatives simultanément.
Résultat attendu : exactement une acceptation ; l'autre rejetée (unicité effective) ; aucun état incohérent.
Couvre : INV-264-05, CA-264-05.

TC-264-07 — Vérification usage primitive temps constant + contrôle statistique¶

Prérequis :
Implémentation instrumentée pour confirmer l'appel à crypto.timingSafeEqual (ou primitive équivalente approuvée).
Deux lots de mesures (equal, mismatch) de N = 100000 comparaisons chacun, après warm-up de 5000.
Infra stable (même machine, même charge, CPU pinning si disponible).
Action :
Vérifier par test unitaire/intégration que la primitive de comparaison en temps constant est utilisée.
Mesurer les durées des deux lots et exécuter Welch t-test bilatéral + Mann-Whitney U.
Calculer Cliff's delta.
Si échec statistique, relancer une seule fois sur infra stable (CPU isolé).
Résultat attendu :
Usage de la primitive validé.
p_ttest >= 0.01 ET p_mwu >= 0.01 ET |Cliff's delta| < 0.147.
En cas de deuxième échec consécutif : verdict ESCALADE et audit obligatoire de fuite temporelle ; test bloquant pour Gate 8 (non bloquant Gate ⅗).
Conclusion : aucun écart corrélé exploitable détecté dans le protocole défini (si critères atteints).
Couvre : INV-264-04.

TC-264-08 — Génération nonce par CSPRNG uniquement¶

Prérequis :
Génération de nonce activée.
Accès aux sources applicatives et à une commande d'analyse statique (grep/AST) en CI.
Action :
Vérifier statiquement que la génération nonce appelle crypto.randomBytes(16) (Node.js) ou un équivalent CSPRNG explicitement documenté.
Vérifier statiquement l'absence de Math.random() dans le chemin de génération.
Exécuter un test d'intégration générant un échantillon (ex. N >= 10000) et mesurer :
- taille exacte de chaque nonce (16 octets) ;
- distribution des octets via test du Chi² (uniformité de premier ordre).
Résultat attendu :
Observable code : preuve de l'usage CSPRNG (crypto.randomBytes(16) ou équivalent approuvé) sur le chemin effectif.
Observable runtime : 100% des nonces à 16 octets.
Observable statistique : test Chi² non rejeté au seuil alpha = 0.01.
Absence de générateur pseudo-aléatoire non cryptographique.
Couvre : INV-264-01.

TC-264-09 — Immutabilité post-insertion du nonce¶

Prérequis : token accepté et persisté avec nonce_A ; accès SQL direct à la base de test.
Action :
Simuler un vecteur d'attaque de contournement applicatif par accès DB direct.
Exécuter UPDATE timestamp_tokens SET nonce = :nonce_B WHERE id = :id_token.
Résultat attendu : modification refusée par le trigger d'immutabilité hérité PD-55 (erreur SQL explicite) ; valeur initiale inchangée ; trace d'échec présente.
Couvre : INV-264-08.

TC-264-10 — Automate : transitions autorisées uniquement¶

Prérequis : flux nominal complet.
Action : exécuter REQUEST_EMITTED -> RESPONSE_RECEIVED -> RESPONSE_ACCEPTED -> TOKEN_PERSISTED.
Résultat attendu : transitions autorisées acceptées sans transition parasite.
Couvre : INV-264-06 (ordre de validation avant persistance).

TC-264-11 — Automate : transitions inverses interdites¶

Prérequis : états atteints en nominal/rejet.
Action : tenter chaque transition interdite décrite par la spécification :
RESPONSE_ACCEPTED -> RESPONSE_RECEIVED
RESPONSE_REJECTED -> RESPONSE_RECEIVED
TOKEN_PERSISTED -> RESPONSE_ACCEPTED
RESPONSE_ACCEPTED -> RESPONSE_REJECTED
RESPONSE_REJECTED -> RESPONSE_ACCEPTED
Résultat attendu : refus systématique ; aucun rollback d'état ; aucune altération de données.
Couvre : INV-264-12.

TC-264-12 — Non-régression PD-55 : chemin accepté conserve l'intégration probatoire¶

Prérequis : réponse conforme acceptée.
Action : exécuter le flux jusqu'à agrégation Merkle/ancrage.
Résultat attendu : comportement PD-55 inchangé pour un token valide ; traçabilité complète intacte.
Couvre : non-régression fonctionnelle.

TC-264-13 — Non-régression PD-55 : chemin rejeté sans effet de bord¶

Prérequis : réponse rejetée (absence nonce ou mismatch).
Action : observer pipeline probatoire post-rejet.
Résultat attendu : aucune entrée append-only, aucune inclusion Merkle, aucun ancrage indu.
Couvre : INV-264-06, CA-264-07, non-régression fonctionnelle.

TC-264-14 — Interopérabilité : vérification `openssl ts -verify`¶

Prérequis : token accepté et artefacts de vérification disponibles.
Action : lancer openssl ts -verify sur token accepté.
Résultat attendu : vérification réussie sans erreur ASN.1/DER.
Couvre : INV-264-09, INV-264-10, CA-264-09.

TC-264-15 — Vérification formelle Prolog à 18/18¶

Prérequis : règles RFC 3161 chargées ; cas PD-264 intégrés.
Action : exécuter la suite formelle.
Résultat attendu : score final 18/18 (aucune règle restante en échec).
Couvre : CA-264-10.

TC-264-16 — CI rapide déterministe (mock TSA RFC)¶

Prérequis : pipeline CI ; fixtures mock versionnées.
Action : exécuter la suite de tests contractuels PD-264.
Résultat attendu : résultats déterministes/reproductibles ; mêmes verdicts à exécution répétée.
Couvre : CA-264-11.

TC-264-17 — Nightly TSA qualifiée réelle + archivage probatoire¶

Prérequis : job nightly ; accès TSA qualifiée.
Action : exécuter la vérification réelle puis archiver le token.
Résultat attendu : token vérifié et archivé avec métadonnées probatoires horodatées.
Couvre : CA-264-12.

TC-264-18 — Vérification de non-applicabilité envelope-encryption (PD-264)¶

Prérequis : exécution d'un flux complet PD-264 (accepté et rejeté) avec traçabilité applicative activée.
Action : auditer les artefacts temporaires produits par PD-264 et vérifier l'absence de secrets cryptographiques de type clé/fragment/DEK/ReKey dans ce périmètre.
Résultat attendu : confirmation documentée que l'invariant INV-264-envelope-encryption est NON APPLICABLE ; le nonce est traité comme donnée probatoire non secrète (mémoire transitoire puis stockage contractuel).
Couvre : INV-264-envelope-encryption.

TC-264-19 — Crash entre ACCEPTED et PERSISTED : atomicité transactionnelle¶

Prérequis : mécanisme de fault injection permettant un crash contrôlé autour du commit DB et observation DB + append-only + Merkle après redémarrage.
Action :
Cas A : déclencher RESPONSE_RECEIVED -> RESPONSE_ACCEPTED, injecter un crash avant commit, redémarrer, inspecter les artefacts.
Cas B : injecter un crash après commit DB et avant append-only/Merkle, redémarrer, observer le rattrapage asynchrone.
Résultat attendu :
Cas A : absence de token persisté ; absence d'append-only/Merkle ; état cohérent (rollback).
Cas B : token persisté présent et valide ; append-only/Merkle éventuellement absents immédiatement après redémarrage mais rattrapés par le worker de réconciliation PD-55 (idempotence, absence de doublon).
Couvre : INV-264-13, CA-264-06, CA-264-07.

3) Tests de non-régression (PD-55)¶

NR-264-01 : TC-264-12 valide que le flux probatoire nominal hérité (persistance -> Merkle -> ancrage) reste intact.
NR-264-02 : TC-264-13 valide qu'un rejet nonce n'introduit aucun effet de bord dans append-only/Merkle/ancrage.
NR-264-03 : TC-264-09 + TC-264-11 valident la conservation de l'immutabilité et des interdictions de retour d'état.
NR-264-04 : conservation de la rétention existante (10 ans, hors changement PD-264) vérifiée par non-altération de configuration.

NR-264-05 : TC-264-19 valide qu'un crash avant commit ne laisse aucun état partiellement accepté.

Justification d'exhaustivité : ces 5 NR couvrent les 3 interfaces PD-55 impactées par PD-264 (persistance, append-only, agrégation Merkle) ainsi que les 2 propriétés transversales (immutabilité et transitions d'états). Les interfaces non impactées par PD-264 (ancrage blockchain, rétention 10 ans) sont hors scope de modification et ne nécessitent pas de NR dédiée additionnelle.

4) Tests d'interopérabilité (`openssl ts -verify`)¶

Référence : TC-264-14.
Critère de succès :
Vérification openssl réussie sur token accepté.
Aucune erreur de structure DER/ASN.1.
Traçabilité de la commande, des entrées et de la sortie conservée dans les artefacts de test.

5) Tests de sécurité (timing attacks, CSPRNG, unicité)¶

Timing attacks : TC-264-07 (usage obligatoire d'une primitive temps constant + validation statistique avec protocole alpha=0.01, N=100000, |Cliff's delta|<0.147).

Escalade timing : en cas d'échec statistique, rerun unique sur infra stable puis escalade/audit obligatoire si second échec ; blocage applicable à Gate 8.
CSPRNG : TC-264-08 (source cryptographique obligatoire, exclusion explicite des PRNG non cryptographiques).

Observable CSPRNG : preuve statique d'usage crypto.randomBytes(16) (ou équivalent documenté), contrôle runtime de longueur 16 octets, et test Chi² sur échantillon.
Unicité / anti-rejeu : TC-264-05 et TC-264-06 (métier + contrainte DB en défense en profondeur).

Envelope-encryption : TC-264-18 (constat de non-applicabilité au périmètre nonce PD-264, absence de secrets temporaires concernés).

6) Verdict de testabilité¶

Exigence	Statut	Justification
INV-264-01	TESTABLE	Vérifiable via cas de refus sans nonce + audit de génération.
INV-264-02	TESTABLE	Vérifiable par injection de réponse sans nonce.
INV-264-03	TESTABLE	Vérifiable via mismatch déterministe `nonce_A`/`nonce_B`.

| INV-264-envelope-encryption | NON APPLICABLE | Hors périmètre PD-264 : aucun artefact secret temporaire (clé/fragment/DEK/ReKey) n'est manipulé ; le nonce n'est pas un secret cryptographique. |

| INV-264-12 | TESTABLE | Vérifiable par exécution exhaustive des 5 transitions interdites (TC-264-11). |

| INV-264-13 | TESTABLE | Vérifiable par fault injection pré/post-commit : rollback sans persistance avant commit, puis persistance DB valide et rattrapage asynchrone append-only/Merkle après commit (TC-264-19). |

Conclusion testabilité : couverture complète INV/CA assurée par les scénarios ci-dessus ; l'ancien absolu sur le temps constant est remplacé par une obligation de moyen testable, et INV-264-envelope-encryption est explicitement classé NON APPLICABLE au périmètre PD-264.