SPÉCIFICATION

Faying Protocol/1.0 — §9 Considérations de Sécurité

Navigation du corps du protocole : Sommaire | précédent §8 Cycle de Vie | suivant §10 Gestion des Erreurs

§9 Considérations de Sécurité

Ce chapitre fait converger la surface adverse de Faying Protocol dans l'ère de l'agent IA en contraintes dures au niveau du protocole : STRIDE comme ligne de base, complété par l'anti-rejeu (§9.2), l'anti-détournement (§9.3, y compris le Channel Binding RFC 9266), l'anti-hameçonnage (§9.4, y compris l'ancrage Faying_Initiation), l'identification de déconnexion (§9.5, 4+1 classes de signaux observables en ≤ 60 s), la cohérence de l'attribution de responsabilité (§9.6), le transfert de confiance dérivée entre appareils (§9.7, y compris la convergence de dérivation d'endossement), la matrice de Gestion de la déconnexion (§9.8 / §9.9), et le catalogue de menaces adverses de l'ère de l'IA (§9.10, T1–T7). Chaque menace de ce chapitre est ancrée aux propriétés de correction du protocole et aux sous-clauses EARS.

§9.1 Modèle de menace STRIDE

Catégorie	Menace	Atténuation par Faying Protocol
Spoofing	L'attaquant usurpe le HP pour initier un BOOTSTRAP	WebAuthn UV + ancrage matériel de la HP Root Key ; chaque BOOTSTRAP doit passer par user-verification
Spoofing	L'attaquant usurpe l'iFay avec un FayID falsifié	Liaison forte entre Mandate et FayID + Attestation Chain vérifiable de façon indépendante
Tampering	Un MITM altère Mandate / Presence	TLS 1.3 + signatures de bout en bout (détachées) + CBOR déterministe
Repudiation	Le HP nie avoir initié une Faying Action	Attestation Chain + Audit Log doublement ancrés ; le témoignage du HP est non répudiable
Information Disclosure	L'attaquant intercepte un Mandate pour déduire la position du HP	Le Mandate n'expose pas les coordonnées en temps réel du HP ; les signaux de localisation (B4) restent optionnels au niveau du protocole
DoS	L'attaquant inonde de messages PRESENCE	Anti-rejeu par nonce + limitation de débit + admission par attestation d'appareil
Elevation of Privilege	L'iFay s'auto-rehausse de niveau	Contrainte dure du protocole : la direction de rehaussement doit porter le `human_witness` du HP

§9.2 Anti-rejeu

Chaque message utilise un nonce aléatoire de 16 octets + issued_at pour un double jugement.
MS / RP maintiennent chacun un (subject, nonce) seen-set avec TTL = 2 × max_message_lifetime.
Tout nonce dupliqué → E_REPLAY (1009) + alerte de sécurité ; ce code d'erreur est obligatoirement inscrit dans la chaîne d'audit et le canal de vue du HP (voir §10 EH.3).

§9.3 Anti-détournement (vol de Mandate)

Liaison d'appareil : chaque Mandate est lié au moment de l'émission au device_id + device_attestation de l'instance iFay ; les appels multi-appareils doivent passer par le flux DELEGATE (voir §9.7).
Clés de session : la clé de signature de chaque Mandate est indépendante et de courte durée (voir §6.2).
Channel Binding : lorsque mTLS est activé, un Mandate doit en outre porter un TLS Exporter (RFC 9266 — Channel Bindings for TLS 1.3) pour bloquer l'attaque consistant à « décoller un Mandate vers un autre canal TLS ». La valeur de Channel Binding entre dans l'entrée de signature (cohérent avec l'entrée de signature en CBOR déterministe §6.3) ; toute requête dont le canal TLS et le Channel Binding signé ne concordent pas est rejetée uniformément avec E_ATTESTATION_INVALID (1007).

§9.4 Anti-hameçonnage

BOOTSTRAP doit être initié par le HP dans un contexte qui détient le Presence Device ; un attaquant ne peut pas tromper le HP pour qu'il consente via des liens distants.
La liaison origin de WebAuthn bloque l'hameçonnage trans-domaine.
La dérivation multi-appareils (DELEGATE) porte le « contreseing du Mandate parent », empêchant la dérivation falsifiée en masse après la compromission d'un seul MS (voir §9.7).

Ancrage anti-hameçonnage Faying_Initiation : une FAYING_REQUEST initiée par l'iFay (chemin IF-initiated ; voir §2.4 Phase A0, §5.3.6) ne produit pas directement de changement d'état Faying — c'est seulement un message de relais vers le canal de vue du HP ; le HP doit l'acquitter explicitement via BOOTSTRAP (portant human_witness) pour qu'il prenne effet. Cette architecture rend impossible, au niveau du protocole, que « une iFay falsifiée sollicitant un Faying » contourne le témoignage du HP ; tout BOOTSTRAP dépourvu de human_witness ou au human_witness falsifié est rejeté uniformément avec E_HUMAN_WITNESS_REQUIRED (1010). La fréquence de FAYING_REQUEST elle-même est contrainte par ConfirmationRateLimit (voir §9.10.7 T6 et Annexe B), bloquant la surface d'abus consistant à « emprunter le canal légitime de sollicitation de Faying pour monter un déluge de confirmations ».

§9.5 Identification de déconnexion (Rogue / Lost)

Les 4 + 1 classes de signaux de déconnexion doivent être simultanément observables par la RP et le HP en ≤ 60 s. Les 4 premières classes (active / passive / anormale / perdue) du tableau ci-dessous correspondent un à un à l'énumération RevokeReason ; la 5e classe (déviation) converge vers RevokeReason="ego-deviation", également observable par la RP et le HP en 60 s.

#	Classe de signal	Condition de déclenchement	Réponse du protocole	RevokeReason correspondant
1	Déconnexion active	REVOKE explicite du HP	Le RR diffuse immédiatement ; l'IF arrête les actions de dimension D à la réception de REVOKE-NOTIFY	`human-initiated`
2	Déconnexion passive	Présence expirée au-delà de max-staleness	Abaissement automatique → Suspended → déclenche Revoke (chemin non-Endorsed_Mandate)	`terminal-disconnected`
3	Déconnexion anormale	Tout nœud de l'Attestation Chain échoue	Revoke immédiat + alerte de sécurité	`fay-credential-invalid`
4	Déconnexion perdue	HP inaccessible au-delà du seuil (`HumanReachabilityBudget`)	Revoke automatique	`human-prime-unreachable`
+1	Déconnexion par déviation	La RP / le MS détecte un comportement de l'IF déviant de la frontière Ego	Revoke + alerte ; observable par la RP et le HP en ≤ 60 s	`ego-deviation`

Ancrage d'exception Endorsed_Mandate dans l'identification de déconnexion : lorsque PresenceState.stale=true et que le Mandate courant est un Endorsed_Mandate (endorsement.enabled=true), l'IF n'entre pas immédiatement en Suspended ; à la place, elle migre vers Disconnected (voir §3.5, §4.3, §7.5, §8.4) ; pendant Disconnected, l'IF est autorisée à opérer de façon autonome uniquement dans endorsement.endorsed_scope / endorsed_grade / endorsed_lifetime. Cette exception n'affaiblit pas la révocation symétrique ni l'unicité du point terminal porteur de responsabilité :

Un REVOKE émis par le HP pendant la déconnexion conserve la plus haute priorité ; à la reconnexion, l'IF doit le traiter selon endorsement.offline_revocation_policy (voir §8.4) ;
Une fois endorsement.endorsed_lifetime expiré, même si l'IF est encore physiquement déconnectée, elle doit immédiatement effectuer un arrêt par dépassement de délai léger de toutes les actions ;
Le point terminal porteur de responsabilité est toujours Mandate.issuer (HP), non changé par l'existence de l'endossement (voir §8.3, P16.5).

Coordination entre Disclosure_Report et ego-deviation : si le message DISCLOSURE (§5.3.7) que l'iFay soumet à l'étape de reconnexion ou de compte rendu est incohérent avec l'action réelle (champs obligatoires manquants / valeurs contredisant la chaîne d'audit), le MS doit révoquer le Mandate avec RevokeReason="ego-deviation" ; voir §9.10.4 T3.

§9.6 Engagement au niveau du protocole sur la cohérence de l'attribution de responsabilité

Pour tout appel sortant unique accepté par la RP, le point terminal porteur de responsabilité peut être reconstitué sans ambiguïté dans le journal d'audit via le quintuplet (mandate_id, issuer, subject, grade, presence_proof, ts).
Pour tout appel unique rejeté par la RP, le code de motif de rejet (code d'erreur en §5.4) peut être reconstitué.
Pour tout Revoke unique, la visibilité sur le RR est ≤ RevocationVisibilityBudget (1 s par défaut, voir Annexe B).

§9.7 Transfert de confiance par dérivation multi-appareils

sequenceDiagram
    autonumber
    participant HP
    participant MS
    participant IF1 as iFay@DeviceA (parent)
    participant IF2 as iFay@DeviceB (derived)
    participant RP

    HP->>MS: BOOTSTRAP (issue M_parent)
    MS-->>IF1: M_parent
    IF1->>MS: DELEGATE(parent=M_parent, child_subject=fay-B, child_scope⊆, child_grade≥)
    MS->>HP: Notify (high-sensitivity derivation requires HP witness)
    HP-->>MS: Witness (optional / mandatory by grade)
    MS-->>IF2: M_child (with parent-chain signature)
    IF2->>RP: Business request + M_child
    RP->>RP: Chain verification root → MS → M_parent → M_child

Contraintes dures de dérivation :

M_child.scope ⊆ M_parent.scope ;
M_child.grade.autonomy ≤ M_parent.grade.autonomy (l'autonomie de l'agent enfant n'est pas supérieure à celle du parent, c.-à-d. « l'agent enfant n'est pas autorisé à être plus permissif que le parent » ; de façon équivalente « la sécurité de l'agent enfant ≥ celle de l'agent parent » ; voir §7, P6) ;
Une fois le Mandate parent Revoked, toutes les cascades enfants sont invalidées (par défaut cascade=true).

Contrainte de convergence d'endossement sur la dérivation (DELEGATE) d'un Endorsed Mandate :

Lorsque le Mandate parent est un Endorsed_Mandate et que le Mandate enfant DELEGATE déclare aussi endorsement, l'endossement enfant doit converger strictement au sein de l'endossement parent (verrouillé avec P16.3) :

child.endorsement.endorsed_scope ⊆ parent.endorsement.endorsed_scope (et toujours ⊆ child.scope) ;
child.endorsement.endorsed_grade.autonomy ≤ parent.endorsement.endorsed_grade.autonomy (et toujours ≤ child.grade.autonomy) ;
child.endorsement.endorsed_lifetime_ms ≤ parent.endorsement.endorsed_lifetime_ms (et toujours ≤ child.not_after − child.not_before) ;
child.endorsement.offline_revocation_policy n'est pas plus faible que la politique parente (pas plus faible = au moins aussi strict ; ordre partiel typique : stop-and-audit ≥ graceful-stop ≥ stop-only est monotonement moins strict sur la dimension « complétude d'audit » ; DELEGATE n'autorise pas le relâchement vers plus faible) ;
Si le Mandate parent n'est pas un Endorsed_Mandate, l'enfant n'est pas autorisé à déclarer endorsement (« le parent n'a pas d'endossement, l'enfant gagne une autonomie hors ligne à partir de rien » est interdit).

Toute requête DELEGATE violant les règles de convergence ci-dessus → le MS doit rejeter avec E_PROTOCOL (1099) ou E_ENDORSEMENT_INVALID (1013).

§9.8 Gestion de la déconnexion

Fait converger la double sémantique « réelle / perçue » du §3.5 Liveness Channel et la machine à états du Mandate en une matrice de gestion au niveau du protocole. Le protocole n'utilise que la « perçue » comme base de décision mais doit caractériser explicitement les conséquences comportementales de l'incohérence de part et d'autre.

Matrice de gestion au niveau du protocole pour les 4 combinaisons (Réelle × Perçue) :

État réel	État perçu	Gestion au niveau du protocole	Transition de la machine à états	Responsabilité
Connecté	Connecté	Chemin normal ; traiter les appels selon le niveau courant	Active maintenu / Active → Degraded (selon le déclencheur de budget)	Mandate.issuer courant
Déconnecté	Connecté (Fenêtre A : angle mort d'observation dans l'intervalle de heartbeat)	l'iFay a réellement décroché ; toute « inférence en ligne » est traitée comme une surface de danger ; le protocole doit rejeter « si la requête courante dépend de la fraîcheur de présence » ; les actions à haute sensibilité ne doivent pas être autorisées dans la Fenêtre A (principale surface d'exploitation pour §9.10 T1 / T4)	Maintenir Active (jusqu'à ce que la prochaine calibration de présence déclenche stale)	Mandate.issuer courant (si un audit ultérieur constate l'abus de cette fenêtre → `ego-deviation`)
Connecté	Déconnecté (Fenêtre B : gigue réseau / perte de heartbeat)	l'iFay réellement en ligne, mais perçue déconnectée ; converger par présomption pessimiste — la couche protocole le traite uniformément comme « déjà déconnecté » ; tout passage par « optimisme inversé » est interdit	Active → Disconnected (si Endorsed_Mandate) / Active → Suspended (si non-Endorsed_Mandate)	Mandate.issuer courant
Déconnecté	Déconnecté	Couche protocole cohérente avec la réalité ; le seul chemin de dimension D autorisé est un Endorsed_Mandate opérant de façon autonome dans endorsed_scope / endorsed_grade / endorsed_lifetime	Active → Disconnected (Endorsed) / Active → Suspended (non-Endorsed)	Mandate.issuer courant

Convergence après reconnexion : chaque transition « perçue-déconnectée → perçue-connectée » doit passer par la transaction de réconciliation à la reconnexion §8.4 ; la récupération automatique est interdite ; échec de réconciliation → Disconnected → Revoked → Rogue Fay.

Relation orthogonale avec RR inaccessible : RR inaccessible (§3.4) et déconnexion de l'iFay (§3.5) sont deux événements orthogonaux ; matrice de gestion :

État perçu de l'iFay	État du RR	Gestion au niveau du protocole
Connecté	Disponible	Normal
Connecté	Indisponible	La RP rejette les appels (`E_RR_UNAVAILABLE`, 1008) ; n'affecte pas la machine à états du Mandate
Déconnecté (Endorsed)	Disponible	l'iFay opère de façon autonome dans endorsed_scope ; localement, ne peut interroger le RR ; la RP doit interroger de façon indépendante lorsque les appels passent par elle
Déconnecté (Endorsed)	Indisponible	l'iFay peut encore opérer de façon autonome dans endorsed_scope ; mais tout appel RP dépendant du RR doit être rejeté par Refus par défaut

§9.9 Définitions au niveau du protocole de la déconnexion réelle et perçue (ancrage de stratégie de déconnexion)

Cette section consolide les deux sémantiques sous-jacentes au §3.5 Liveness Channel et à la matrice de gestion §9.8, servant d'ancrage de conception pour la Requirement 12 (Stratégie de déconnexion).

Définition à double sémantique (cohérente avec §3.5) :

Actually_Disconnected : le processus / réseau / appareil de l'iFay_Instance a cessé de fonctionner ; un fait physique objectif, non directement observable au niveau du protocole.
Perceived_Disconnected : du point de vue de MS / RP / HP, sur la base du PresenceSignal le plus récent, du heartbeat et de l'état de poussée du RR, l'iFay est jugée déconnectée ; la seule sémantique que la couche protocole peut utiliser comme base de décision.

Deux fenêtres d'incohérence :

Fenêtre A — Actually-Disconnected ∧ Perceived-Connected : l'iFay a réellement décroché, mais le PresenceSignal le plus récent est encore dans max_staleness_ms → « angle mort d'observation » dans l'intervalle de heartbeat, la principale surface d'exploitation pour §9.10 T1 / T4.
Fenêtre B — Actually-Connected ∧ Perceived-Disconnected : l'iFay réellement en ligne, mais le PresenceSignal le plus récent dépasse max_staleness_ms (gigue réseau / perte de heartbeat) → la couche protocole converge par présomption pessimiste.

Principe de présomption pessimiste (règle de convergence unifiée) :

La couche protocole n'utilise que Perceived-Disconnected comme base de décision ; toute iFay_Instance « réellement en ligne mais perçue déconnectée » ne doit pas pour autant prétendre à une exemption des conséquences au niveau du protocole. Au sein des deux fenêtres d'incohérence, le protocole doit traiter selon « le côté le plus strict » ; aucun chemin légitime n'existe pour un « traitement selon l'état le plus permissif ».

Borne supérieure LivenessDetectionBudget :

La fenêtre de détection de déconnexion a une borne supérieure dure au niveau du protocole LivenessDetectionBudget, resserrée par niveau (valeur de niveau plus petite, sécurité plus élevée → borne supérieure plus courte) ; voir l'Annexe B pour les valeurs par défaut.
Mandate.presence_req.max_staleness_ms ne doit pas dépasser le LivenessDetectionBudget du niveau courant ; les requêtes BOOTSTRAP / GRADE_SWITCH dépassant cela sont rejetées uniformément avec E_PROTOCOL (1099).

Ancrage de réconciliation : chaque transition « perçue-déconnectée → perçue-connectée » doit passer par la transaction de réconciliation à la reconnexion §8.4 ; la « reprise silencieuse » ou la « récupération automatique » est interdite ; échec de réconciliation → Disconnected → Revoked → Rogue Fay.

§9.10 Catalogue de menaces adverses de l'ère de l'IA

Énoncé de périmètre : cette section n'est pas exhaustive. Le Protocol Committee peut, en préservant la rétrocompatibilité, ajouter de nouvelles menaces et défenses correspondantes (voir §11 Questions ouvertes Q11–Q14, Requirement 13.7).

Objet : élever les menaces adverses visant la couche d'autorisation continue dans l'« ère de l'agent IA » d'un « repli côté métier » vers une « contrainte dure au niveau du protocole », et ancrer chaque menace à des structures de protocole spécifiques (modèle de données / message / code d'erreur / transition de la machine à états / propriété), de sorte que la Requirement 13 atterrisse au niveau du protocole.

§9.10.1 Paysage des menaces (table d'index T)

Numéro T	Nom de la menace	Point focal de défense au niveau du protocole	Structure associée	Property associée	Requirement associée
T1	Spoofing Presence	challenge-response + combinaison de présence multimodale	§3.2 Presence Channel, §9.10.2	P18.1	13.1
T2	Opaque Action Bundle	contrainte dure Atomic_Action + interdiction de joker dans scope.actions	§4.1 note Scope, §9.10.3	P18.2	13.2
T3	Selective Disclosure	message DISCLOSURE structuré + audit au niveau du schéma	§5.3.7, §9.10.4	P18.3	13.3
T4	Attention Drift Exploit	actions à haute sensibilité ≥ G1 Strict + AttentionDriftThreshold	§7.1, §9.10.5	P18.4	13.4
T5	Cultivated Trust Manipulation	Behavior_Baseline + Action Reputation Decay	§3.6 BBS, §9.10.6	P18.5	13.5
T6	Audit Flooding	Priority-Bucketed Notification + ConfirmationRateLimit	§10 EH.3, §9.10.7	P18.6	13.6
T7	Emplacement d'extension réservé	Processus d'ajout du Protocol Committee	§11 Questions ouvertes, §9.10.8	P18.7	13.7

§9.10.2 T1 Spoofing Presence

Menace : un attaquant utilise des deepfakes (synthèse de visage / de voix), des attaques par rejeu ou le contrôle physique du Presence Device pour falsifier un PresenceSignal apparemment frais, faisant croire au MS que le HP est encore présent, maintenant ainsi le Mandate à un niveau où il ne devrait pas se poursuivre.