Threat model

Pourquoi un threat model étroit

Un threat model qui prétend défendre contre tout ne défend contre rien en pratique. Le substrat est délibérément étroit. Il adresse les menaces que la couche d’exécution côté appareil peut crédiblement observer et signer — et déclare la frontière au-delà de laquelle le trust que nous offrons ne s’étend pas.

Le résultat est un modèle qu’un CISO peut revoir en détail, dont il peut accepter la frontière, et qu’il peut intégrer dans sa propre threat library — plutôt qu’une revendication marketing qui doit être qualifiée en privé.

outcomes

Ce que cela vous permet de faire aujourd'hui que vous ne pouviez pas avant

• Passer une revue de threat-modelling CISO sur les revendications du substrat

  Chaque menace dans le périmètre se mappe à un signal mesurable ; chaque menace hors-périmètre est nommée avec la couche à laquelle elle appartient. Il n'y a pas de revendications floues à défendre en revue de sécurité.

• Composer avec le reste de votre stratégie de defence-in-depth

  Services d'attestation matérielle, intégrité du build pipeline, sécurité backend — chacun possède une couche. Le substrat nomme la couche qu'il possède, donc les combiner est de l'ingénierie, pas de la négociation.

• Distinguer les événements d'intégrité signés des décisions de policy

  Chemin, ordre, key binding, continuité de hash — ce sont des questions d'intégrité auxquelles le substrat répond. L'intention de l'utilisateur — le porteur a-t-il été contraint ? — est une question de policy pour votre risk engine. La frontière est explicite.

• Raisonner sur ce qui est observable vs ce qui est présumé

  Quand un régulateur demande 'comment détecteriez-vous X ?', la réponse est soit 'nous le signons', soit 'nous le déclarons hors-périmètre, et voici la couche qui le possède'. Pas d'inférence, pas de gaps silencieux.

• Appliquer la policy au trust basis déclaré, pas à un état appareil inféré

  Hardware-bound, software-resident — le runtime le déclare. Vous pondérez vos décisions en conséquence, sans deviner.

Dans le périmètre — surfacé comme evidence

Compromission au niveau application

Attaques d’overlay, abus d’accessibility-service, applications repackagées, bundles modifiés, runtime hooking. Le TRP observe celles-ci directement — overlays à l’instant de l’input, accessibility services à l’enregistrement, repackaging au lancement de l’app. L’Evidence Token signé les déclare.

Manipulation user-space

Debugger attach, injection runtime, frameworks d’instrumentation dynamique (Frida, Substrate, etc.), substitution de bibliothèque. Ceux-ci remontent comme signaux runtime-environment au prochain événement signé, avec une spécificité suffisante pour que l’opérateur applique la policy.

Interférence d’exécution

Adversaires triggered, dormants, et par injection contre la couche d’evidence elle-même. Le substrat valide la détection d’interférence d’exécution, pas la simple présence statique d’une menace. C’est ce autour de quoi nos tests runtime adversariaux dans notre pipeline de développement sont construits.

Fabrication et replay

Un événement signé qui ne fait pas partie d’une hash chain cohérente casse la vérification. Un événement rejoué avec la même combinaison tctx et seq qu’un événement déjà vu est rejeté avec une raison spécifique. Les événements fabriqués sans signatures hardware-bound valides échouent à l’étape ·02 du pipeline de vérification.

Intégrité de flow autonome (paiements agentiques)

Quand un agent autonome — un wallet orchestré par LLM, un agent de paiement récurrent automatisé, un pattern de dépense fleet-of-things — pilote un paiement, EEI signe le flow agent en quatre étapes comme une séquence hash-linked : propose → consent → initiate → confirm. Chaque étape enregistre ses conditions, son trust basis, et référence le hash de l’étape précédente. Menaces spécifiques couvertes :

• Omission d’étape. Un agent qui initiate sans étape consent signée casse la chaîne à la vérification — la raison de rejet identifie l’étape manquante explicitement.
• Falsification de payload de consent. Les conditions signées de l’étape consent (cap montant, ensemble destinataires, fenêtre temporelle) font partie de la hash chain ; toute étape ultérieure qui dépasse ces conditions échoue la vérification.
• Re-binding vers une identité agent différente. Si une clé de signature différente produit l’étape confirm que celle qui a produit l’étape consent, la déclaration de trust basis change mid-chain et le moteur de policy de l’opérateur voit la discontinuité inline.
• Décisions d’agent rejouées. Même tctx + même séquence d’événements agent qu’un flow déjà vu est rejeté à l’étape ·06 de la vérification.

Ce qui n’est pas couvert : prompt injection à la couche d’input LLM (un LLM peut toujours être trompé pour produire une étape propose qui a l’air légitime sur un input adversarial) ; substitution de modèle à la couche d’inférence opérateur ; compromission de l’agent cloud. Ce sont les domaines LLM-supply-chain et inference-platform de l’opérateur. EEI signe l’exécution de l’agent — ce qu’il a fait et dans quel ordre — pas l’intention de l’agent. Les deux composent : les défenses prompt-injection de l’opérateur gouvernent ce que l’agent décide ; EEI signe si la décision a été exécutée cohéremment contre l’état runtime de l’appareil.

Hors-périmètre — déclaré, pas silencieusement ignoré

Compromission au niveau kernel

Un appareil dont le kernel a été compromis est, par définition, hors du trust que le TRP peut déclarer. Nous ne prétendons pas défendre contre cela — nous le traitons comme un échec de trust plateforme. Les opérateurs qui exigent une défense à cette couche devraient associer le substrat à des services d’attestation matérielle qui opèrent à l’intérieur du secure element.

Compromission supply-chain

Un build pipeline qui a été compromis avant que l’application ne soit livrée est de la responsabilité de l’opérateur à défendre. Code-signing, provenance SBOM, builds reproductibles — ce sont les contrôles pertinents. Une fois l’application sur l’appareil, le TRP mesure ce qu’il voit ; il ne peut pas remonter à travers le build.

Infiltration backend

La vérification du substrat est sovereign — c’est-à-dire qu’elle fonctionne sans YinkoShield dans le chemin — mais elle ne peut pas défendre le backend de l’opérateur. Un attaquant avec accès admin au backend qui consomme l’evidence peut l’ignorer. C’est le domaine de sécurité d’infrastructure de l’opérateur.

Ingénierie sociale de l’utilisateur

Un utilisateur qui a été trompé pour autoriser une transaction est un utilisateur que le runtime a correctement observé. L’Evidence Token enregistre toujours exactement ce qui s’est exécuté ; ce que l’utilisateur avait l’intention de faire est une question de policy pour le risk engine de l’opérateur, pas une question d’intégrité pour le substrat.

properties

Ce que vous obtenez quand le modèle est dans votre defence-in-depth library

• ·01 Frontière étroite et déclarée

  Les menaces dans le périmètre et les menaces hors-périmètre sont toutes deux énumérées. Rien n'est silencieusement ignoré.

• ·02 Quatre classes de menaces in-scope

  Compromission au niveau application · manipulation user-space · interférence d'exécution · fabrication et replay. Chacune remonte comme un signal spécifique, pas comme un score agrégé.

• ·03 Quatre classes de menaces out-of-scope

  Compromission au niveau kernel · compromission supply-chain · infiltration backend · ingénierie sociale de l'utilisateur. Chacune est nommée avec la couche qui la possède.

• ·04 Méthodologie de validation adversariale

  Testée contre des attaques triggered, dormantes, et par injection contre la couche d'evidence elle-même — pas seulement la présence statique de menace.

• ·05 Signé-ou-déclaré, jamais inféré

  Le substrat soit produit de l'evidence sur une menace (signé), soit la nomme comme hors-périmètre (déclaré). Pas de troisième option silencieuse.

• ·06 Frontière auditable

  Un régulateur ou un CISO peut revoir ce que le substrat revendique et ce qu'il ne revendique pas — sans documentation propriétaire, juste la spec.

• ·07 Composable avec l'attestation matérielle

  Le TRP nomme la frontière à l'user-space ; pour les garanties au niveau kernel, l'opérateur associe le substrat à des services d'attestation plateforme. Les deux couches ne se chevauchent pas.

Pourquoi c’est la réponse honnête

Une plateforme qui prétendrait adresser tout cela ne survivrait pas à la revue d’un régulateur. Une plateforme qui mappe explicitement quelles menaces tombent dans le périmètre, lesquelles tombent ailleurs dans la stratégie defence-in-depth de l’opérateur, et où sont les frontières — c’est la plateforme qui se fait approuver.

Comment le modèle s’inscrit avec ce que vous faites déjà tourner

Le threat model dans THREAT_MODEL.md de YEI-001 est structuré pour s’insérer dans la defence-in-depth library existante de l’opérateur — pas à côté. Là où une catégorie ou frontière se mappe à un framework ou régime existant, le framework est nommé ; là où elle ne le fait pas, la couche est déclarée explicitement.

• STRIDE · Le tableau de menaces de la spec est une analyse orientée STRIDE. Spoofing (substitution de clé au re-fetch), Tampering (altération de payload de token, altération d’enregistrement de ledger), Repudiation (l’evidence signée sous clé appareil supporte la non-répudiation de la réclamation, pas de l’intention), Information Disclosure (discipline PII, risque de quasi-identifiants), Denial of Service (limites de taille, allowlist d’header, negative-cache de dedup), Elevation of Privilege (algorithm-confusion : ES256 uniquement, allowlist d’header).
• EMV 3-D Secure · L’authentification scheme et EEI sont orthogonales sauf si le programme de l’opérateur lie explicitement les résultats. L’evidence est complémentaire, pas un substitut aux résultats CAVV / 3DS.
• ISO 8583 · Transport pour l’Evidence Token via DE 48 (ou DE 124 / 125) à l’intérieur d’une enveloppe BER-TLV 0xF0 — un champ existant, pas un nouveau.
• POPIA · NDPR · DPA 2019 · DPA 2012 · LPDP · Loi 09-08 · RGPD · La conformance producteur exige le profil de privacy strict (device_id pseudonymisé ou omis ; tctx non liable à une personne physique sans consentement explicite ; pas de logging brut de paires (device_id, tctx) sans une base de traitement légale documentée). La même posture strict satisfait la POPIA §11 (Afrique du Sud), la NDPR (Nigeria), la DPA 2019 (Kenya), la DPA 2012 (Ghana), la LPDP (Côte d’Ivoire), la Loi 09-08 (Maroc), la DPA Maurice, et le RGPD pour les sujets européens. La spec est appliquée ; la checklist de conformance producteur dans YEI-001 nomme chaque régime explicitement pour qu’un DPO opérateur puisse mapper les contrôles aux exigences locales sans inférer.
• PCI DSS, certification scheme de paiement, admissibilité juridictionnelle · Hors-périmètre. La spec ne remplace explicitement pas ces éléments. Le programme de l’opérateur possède le mapping de chargeback reason-code, le linkage 3DS-outcome, et l’admissibilité de l’evidence en litige sous le droit local.

Où en lire plus

Le threat model complet — y compris les catégories adversariales formelles, la méthodologie de validation, et les conditions de frontière — vit dans le THREAT_MODEL.md de YEI-001, partagé avec les régulateurs et partenaires qualifiés sous NDA.

Demander la spécification YEI-001 →