YinkoShield
Briefing

glossaire · référence

Chaque terme, défini une seule fois.

Vocabulaire-marque canonique pour la catégorie Execution Evidence Infrastructure. Mêmes définitions sur le site, dans la spécification YEI-001, dans les briefings partenaires, et dans la documentation client. Si un terme apparaît ici, il apparaît seulement ici.

Catégorie

Execution Evidence Infrastructure · EEI

article complet →
La catégorie. La couche de preuve liée au terminal pour les paiements numériques — signe ce que le runtime a fait à l'instant de l'action, contre un ledger append-only résident sur l'appareil, vérifiable avec une clé publique seule.

Runtime coherence

article complet →
La propriété que le substrat implémente : le chemin d'exécution de l'appareil est observable, ordonné, et signé entre l'utilisation du credential et la réception réseau. La couche de partition manquante de l'infrastructure de paiement.

Couche témoin

Synonyme en langage clair utilisé en briefing client. EEI témoigne ; l'opérateur décide. Le substrat est le témoin, l'Evidence Token est le témoignage, le ledger est la déposition.
Primitives

Trusted Runtime Primitive · TRP

article complet →
La fondation du substrat EEI. Un module d'infrastructure embarqué dans l'user-land de l'application opérateur qui enveloppe les syscalls, libc, et les appels framework ; observe la runtime coherence ; signe le résultat avec une clé liée au matériel.

Local Evidence Ledger

article complet →
L'enregistrement append-only et hash-linked résident sur l'appareil de chaque événement signé. Toute falsification d'un maillon casse la chaîne visiblement. Le ledger ne stream pas hors de l'appareil.

Commander

article complet →
Le canal forensique contrôlé par l'opérateur dans le ledger. PGP-analogue : la clé opérateur signe les commandes chiffrées ; la clé appareil les reçoit, exécute la requête, signe la réponse. Aucun tiers dans la boucle.

Zero Trust Bootstrap Protocol · ZTBP

article complet →
Le protocole de génération de clés. À la première init, l'appareil génère une paire de clés à l'intérieur de son TEE. La clé privée ne quitte jamais ; la clé publique est enregistrée auprès du backend opérateur via un canal qui n'inclut pas YinkoShield.
Artefacts

Evidence Token

article complet →
L'enregistrement signé et hash-linked d'un événement d'exécution. JWS-compact, ES256, ~200 octets (Minimal Profile) ou ~300 octets (Standard Profile). Voyage inline avec la transaction ; vérifiable avec une clé publique seule.

Evidence Record

L'enregistrement plus complet stocké dans le ledger appareil que le `sig_ref` de l'Evidence Token pointe. Récupéré via le canal Commander pour investigation forensique ; pas requis pour la vérification inline.
Propriétés

Sovereign verification

article complet →
La vérification d'un Evidence Token requiert trois choses : le token, la clé publique enregistrée, et une implémentation de vérificateur. Aucune de ces trois n'implique YinkoShield. Une panne YinkoShield n'interrompt pas la vérification.

Trust basis

Propriété déclarée-pas-inférée de chaque Evidence Token. L'un parmi `hardware_backed`, `hardware_bound`, `execution_proof`, `compromised_device`, ou `software_layer`. L'opérateur pondère la policy contre le basis déclaré.
Champs du token

tctx

Transaction context. Corrèle les retries du même contexte d'exécution — la suppression de doublons arrête d'être une heuristique et devient un output du vérificateur.

did

Device identifier. Pseudonyme (SHA-256 de la clé publique de l'appareil) ; jamais PII.

kid

Key identifier. Résout quelle clé publique stockée par l'opérateur vérifie ce token.

boot_id

Identifiant de session boot. Détecte les flows interrompus par redémarrage et les discontinuités de cycle de vie.

eid · seq

Event identifier et numéro de séquence par appareil. Avec `did, tctx, event_name`, ils forment la clé de dedup atomique pour la protection contre le replay.

sig_ref

Référence à l'Evidence Record correspondant dans le ledger appareil — `ledger_seq` plus segment id, ou un URI `yks-ledger://` plus content hash.
Classes de signaux

device.integrity

État d'intégrité de boot. Un appareil re-flashé échoue la vérification à la première transaction.

runtime.environment

Environnement d'exécution. Émulateur détecté, debugger attaché, framework d'instrumentation — déclaré dans l'evidence.

code.integrity

Signature du code applicatif. APK repackagé remonte comme `software_measured`.

binding.status

Si la clé de signature est liée au matériel — TEE-backed vs. software-bound, déclaré.

network.identity

Continuité d'identité SIM et réseau. SIM swap mid-transaction visible au retry.
Standards

JWS · ES256

RFC 7515 JWS Compact Serialization avec signature ECDSA P-256 + SHA-256. L'enveloppe de l'Evidence Token.

ISO 8583 DE 48

Élément de données privé du rail carte. Porte l'Evidence Token via une enveloppe BER-TLV `0xF0` — choisie spécifiquement parce qu'elle ne conflicte pas avec les sous-éléments Mastercard ou Visa.

EMV / EMV 3DS

Adjacent et orthogonal à EEI. Les résultats d'authentification scheme (CAVV / 3DS results) se lient aux événements EEI seulement quand le programme d'un opérateur le dit explicitement.

STRIDE

Méthodologie de threat-modelling utilisée dans le `THREAT_MODEL.md` de YEI-001 pour le tableau in-scope-vs-residual-risk.

POPIA §11

Régime de protection des données sud-africain. La conformance producteur pour les consommateurs sud-africains exige le profil de privacy *strict* — pas de logging brut `(device_id, tctx)` sans une base de traitement légale documentée.
Modèle opérationnel

Profil d'intégration

L'un parmi trois : `iso8583-de48-minimal` (rails carte, budget DE 48 serré), `mobile-wallet-retail` (Standard Profile plus riche quand la bande passante le permet), `agent-assisted-channel` (événements distincts pour client vs agent).

Vérificateur de référence

L'une des quatre implémentations indépendantes de YEI-001 §6 — Python, JavaScript, Go, Java. La cross-conformance fait partie de CONFORMANCE.md ; le même token se vérifie de la même façon dans chaque langage, ou l'un d'entre eux est cassé.

Pipeline en huit étapes

article complet →
Le contrat de vérification : parse JWS · resolve key · verify signature · validate claims · enforce freshness · replay check · sequence regression · trust level. Chaque étape échoue en mode fermé ; les rejets sont diagnosticables, pas anonymes.

Profil de privacy

`strict` ou `default`. `strict` est requis pour les consommateurs sud-africains sous POPIA §11 — identifiants d'appareil pseudonymes, pas d'accumulation de quasi-identifiants, pas de logging brut `(device_id, tctx)`.

Pour le vocabulaire normatif complet, demandez la spécification YEI-001.

Actuellement partagée avec les régulateurs et partenaires qualifiés sous NDA.

Demander l'accès à YEI-001