YinkoShield
Briefing

architecture

Le dossier architectural d'execution evidence.

EEI est une architecture en couches. Ci-dessous : les primitives, la propriété qu'elles implémentent, et l'investissement d'ingénierie qui fait tourner le substrat à l'échelle.

le substrat en un coup d'œil

Cinq couches. Deux nous appartiennent. Sept primitives entre elles.

La pile complète fait cinq couches — le matériel au sol, la politique au sommet. EEI couvre les couches 02 et 03 : le Trusted Runtime Primitive et l'Execution Evidence Layer. Les trois autres sont adjacentes — informatives ici, possédées ailleurs. Cliquez sur n'importe quelle primitive pour la déplier sur place ; plusieurs primitives d'une même couche peuvent rester ouvertes en même temps. Ou tout déplier pour tout lire en ligne. La numérotation des couches suit YEI-001.

Couche 05 policy / decision systems · hors périmètre EEI

Issuer · Network · Processor · Edge · Plateforme de litiges

Consomment l'evidence, possèdent toute l'enforcement. EEI ne décide pas.

Couche 04 platform attestation · complémentaire, pas remplacée

Android Play Integrity · iOS DeviceCheck · TPM · StrongBox attestation

L'attestation établit le checkpoint. La runtime coherence établit ce qui s'est passé entre les checkpoints.

Couche 03 · core execution evidence layer · ce qui voyage et comment c'est vérifié
·03

Evidence Token

[ evidence token · jws compact · es256 ] ·01 header alg · kid · typ . ·02 payload claims · signals · hash chain . ·03 signature ES256 [ two profiles — same cryptographic semantics ] Minimal Profile ~200 bytes device-id · attestation · intent hash fits inside ISO 8583 DE 48 Standard Profile ~300 bytes + signal class · network identity HTTP / OTel · forensic richness
JWS compact, ES256, inline with each request. Two byte-budget profiles — same verifier code path.

L'Evidence Token est une structure JWS compact, signée ES256, embarquée inline avec chaque requête. Deux profils : Minimal (~200 octets, tient dans ISO 8583 DE 48) et Standard (~300 octets, contexte inline plus riche).

Mêmes propriétés cryptographiques, même chemin de vérification, budgets d'octets différents. Le canal est une décision d'intégration ; le token est une décision de confiance.

Lire l'article (EN) →
·04

Local Evidence Ledger & Commander

[ local evidence ledger · commander channel ] device · on-device storage ·01 sign hash: 0xa3… ·02 sign prev: 0xa3… ·03 … append-only commander module decrypts signed-and-encrypted commands replies with signed forensic responses no infrastructure in the loop · pgp-analogous device key · operator key · sovereign operator encrypted command signed response forensic, attributable device-resident, hash-linked, sovereign — no third-party in the forensic path
The ledger is on the device. The Commander gives operators a signed channel to it without putting any third party in the path.

Chaque événement signé est ajouté à un ledger hash-linked résident sur l'appareil. Un tampering sur n'importe quel maillon casse la chaîne de manière visible. Le ledger ne quitte pas l'appareil.

Le module Commander est le canal forensique contrôlé par l'opérateur dans ce ledger — commandes chiffrées en entrée, réponses signées en sortie. Analogue à PGP : la clé opérateur autorise, la clé device répond, pas de tiers dans la boucle.

Lire l'article (EN) →
·05

Zero Trust Bootstrap Protocol

[ zero trust bootstrap protocol · first init ] device ·01 generate keypair at first initialisation, in-TEE private stays in TEE public leaves once ·02 register public key over operator-controlled onboarding channel YinkoShield is not in this path public key only operator backend stores registered public key indexed by device id verifies any future evidence independently — sovereign private key never leaves · public key registered once · no key-escrow
Private key stays in the device's secure element. The operator registers the public key once and verifies all future evidence with it.

À la première initialisation, l'appareil génère une keypair à l'intérieur de son trusted execution environment. La clé privée n'en sort jamais. La clé publique est enregistrée sur le backend de l'opérateur via un canal d'onboarding contrôlé par l'opérateur — un chemin qui ne nous inclut pas.

À partir de cet instant, l'opérateur possède le matériel de vérification. La sovereign verification est une propriété que le bootstrap établit.

Lire l'article (EN) →
·06

Sovereign Verification

[ sovereign verification · no third-party in path ] device signs evidence evidence token jws · es256 operator verifier python · javascript · go · java 8-step verification pipeline uses registered public key no network call to YinkoShield PKI public keys YinkoShield · not in this path
Any party with the registered public key verifies independently. No YinkoShield endpoint, no licence check, no runtime dependency.

N'importe quelle partie disposant de la clé publique enregistrée vérifie l'evidence indépendamment — exactement comme pour n'importe quelle signature PKI standard. Pas d'endpoint YinkoShield dans le chemin de vérification, pas de licence check, pas de dépendance runtime.

Des vérificateurs de référence existent en Python, JavaScript, Go, et Java. Le pipeline en huit étapes — parse, key resolution, signature, claims, freshness, replay, sequence regression, trust level — est le même dans chaque langage.

Lire l'article (EN) →
Couche 02 · core trusted runtime primitive · là où la signature se produit
·02

Trusted Runtime Primitive

[ trusted runtime primitive · wraps · monitors · signs ] application code your banking app · POS firmware · kiosk shell TRP — wrapping & coherence ·01 framework library Java framework / Foundation / UIKit ·02 libc open · read · write · mmap · exec ·03 syscall boundary user-space ↔ kernel OS · device hardware TEE · Secure Enclave · HSM · Strongbox continuous coherence check ·a observe every wrapped call, in order ·b measure runtime state · environment · trust basis ·c check coherence does this sequence match a trusted runtime? ·d sign JWS · ES256 · hardware-bound key loop · every event SIGNED EVIDENCE TOKEN to operator · with the transaction runtime coherence + decoupled policy no single check to disable · same evidence read at multiple control points runs on: Android · iOS · POS · SoftPOS · SST · ~13,000 hardware configurations · including 1 GB RAM, 2G/3G estates
The TRP wraps every call that crosses out of the application — at the framework, libc, and syscall layers — and runs a continuous coherence check. Each event is signed and emitted with the transaction. Same module across mobile, POS, and SST.

Une seule primitive platform-portable s'exécute en user-land de votre application — Android, iOS, POS, SoftPOS, SST. Elle observe l'exécution au niveau syscall, mesure le runtime, déclare sa base de confiance, et signe l'evidence avec une clé liée au matériel.

Le TRP est le substrat sur lequel toutes les autres pièces reposent. C'est ce qui transforme un événement signé en témoin, pas en simple affirmation.

Lire l'article (EN) →
·01

Runtime Coherence

[ runtime coherence · the interval between action and receipt ] today — backend infers what happened from the receipt user taps Pay action begins on device network receipt backend acknowledges silent gap · no infrastructure observes this with execution evidence — each step in the interval is signed, hash-linked, and reconstructable user taps Pay action begins ·1 runtime measured ·2 biometric ok ·3 payload hashed ·4 request signed network receipt + signed evidence four hash-linked events · one signed record · the interval is reconstructable sequence · ordering · device state · trust basis · all preserved
Today, the interval between a user action and the network's acknowledgement is a silent gap. Runtime coherence makes that gap a signed sequence — measurable, ordered, and reconstructable.

Les systèmes back-end prouvent la réception. Les credentials prouvent l'identité au moment de l'usage. Entre les deux se trouve le chemin d'exécution côté appareil — historiquement silencieux, la partition dans laquelle les adversaires opèrent.

Runtime coherence est la propriété qui ferme cet écart — la propriété délivrée par le TRP : une séquence signée, hash-linked, d'événements d'exécution, ordonnés, attribuables, et reconstructibles. L'article de fond traite l'argument architectural en entier.

Lire l'article (EN) →
·07

Threat Model

[ threat model · in scope · out of scope ] in scope → surfaced as evidence application-layer compromise overlay, accessibility abuse, hooking user-space manipulation repackaging, runtime injection, debug attach execution interference triggered, dormant, injection adversaries fabrication / replay unsigned events, mismatched hash chain out of scope · declared kernel-level compromise treated as platform-trust failure supply-chain compromise build-pipeline trust is the operator's domain backend infiltration covered by your own infrastructure security social-engineering of the user policy domain — evidence still records what executed
The model is deliberately narrow. We don't claim what we cannot defend — and what is out of scope is declared, not silently ignored.

Le TRP défend contre la compromission au niveau applicatif, la manipulation user-space, l'injection runtime, et la fabrication ou le replay d'événements. Ces menaces remontent comme evidence — pas comme défaillances silencieuses.

Ce contre quoi le TRP ne défend pas — compromission au niveau kernel, supply-chain, infiltration backend — est déclaré, pas ignoré silencieusement. Un modèle étroit et honnête est le seul qui survit à la revue d'un CISO.

Lire l'article (EN) →
Couche 01 matériel de l'appareil · hors périmètre YinkoShield

TEE · Secure Enclave · HSM · Strongbox · TPM

Le sol matériel sur lequel on s'appuie — borne la confiance que l'on déclare.

pourquoi ce n'est pas déjà dans votre stack

L'écart est un coût d'ingénierie, pas un manque de prise de conscience.

Execution evidence demande de faire tourner une infrastructure qui ne vit pas dans les organisations d'ingénierie paiements standards. Trois capacités doivent exister ; nous avons passé treize ans à les construire.

  • ·01

    Populations d'appareils fragmentées

    Environ 13 000 configurations matérielles Android distinctes aujourd'hui. La couche d'abstraction matérielle a été extraite de l'exploitation ; la spec est l'artefact.

  • ·02

    Chaos engineering sur la partition

    Simulation réseau, pression mémoire, interruption d'exécution. La cohérence du ledger sous partition n'est pas testable en CI standard — infrastructure dédiée maintenue en interne.

  • ·03

    Tests adversariaux sur le runtime

    Attaques triggered, dormantes, et par injection contre la couche d'evidence. Nous validons la détection d'interférences d'exécution, pas la simple présence statique d'une menace.

C'est ce qu'il en coûte pour faire tourner execution evidence en production. C'est pourquoi ça n'existe pas déjà dans votre stack.

spécification

YEI-001 est partagée avec les régulateurs et partenaires qualifiés sous NDA.

La spécification complète, les checklists de conformance, le threat model, et l'extension agentic-payment sont disponibles sur demande. Les vérificateurs de référence en Python, JavaScript, Go, et Java les accompagnent.

Demander l'accès à la spécification