YinkoShield
Briefing

plateforme

Un module d'infrastructure dans votre app. Un signal signé dans votre stack. Votre policy, intacte.

YinkoShield s'exécute comme module d'infrastructure embarqué en user-land de votre application — pas un SDK développeur à wirer, mais un runtime platform-portable qui observe et signe l'exécution à l'instant de l'action. Vous consommez l'evidence là où elle vous sert. Votre policy reste où elle est.

livré aujourd'hui

Modules opérationnels sur le même SDK que le cœur EEI.

14%

DNS Racer

Récupération d'échecs de session liés au DNS sur les écosystèmes cellulaires. Compatible reverse-billing.

SIGNED

Screenshot Watermark

Capture tamper-evident pour le traçage support et l'evidence de litiges.
livraison

Un module. Trois surfaces de consommation. Policy découplée.

  1. ·01

    Embarquer le module runtime

    Module d'infrastructure embarqué en user-land de votre application. Tourne in-process ; observe l'exécution ; signe l'evidence avec une clé liée au matériel. Platform-portable sur Mobile, POS, SoftPOS, et SST.

  2. ·02

    Choisir un canal de consommation

    HTTP header, OpenTelemetry span, ou ISO 8583 DE 48. Les propriétés de l'Evidence Token sont identiques quel que soit le canal qui le porte.

  3. ·03

    Appliquer votre propre policy

    YinkoShield ne décide jamais. Votre risk engine, votre plateforme de litiges, ou votre substrat d'audit combine le signal signé avec son contexte business — conditionnel, contextuel, écrit par vous.

  4. ·04

    Tester à l'échelle avec Signal Lab

    Un dashboard hébergé avec des scénarios scriptés et un CSV bulk replay (~53 000 événements sur 1 000 appareils simulés). Démontre le substrat sans installation sur votre infrastructure.

canaux d'intégration

Le canal de consommation est une décision d'intégration, pas une décision de confiance.

Les propriétés cryptographiques de l'Evidence Token sont identiques quel que soit le canal qui le porte. Choisissez celui qui s'aligne sur votre chemin d'autorisation existant.

[ integration channels · the channel is an integration decision, not a trust decision ] EVIDENCE TOKEN Minimal ~200 bytes Standard ~300 bytes + threat events SDK only full detail · in-process ·01 HTTP header X-YinkoShield-Evidence custom request header Minimal or Standard token REST authorization paths ·02 OpenTelemetry span attribute alongside existing telemetry Minimal or Standard token no extra integration layer ·03 ISO 8583 DE 48 · BER-TLV ~216 bytes in DE 48 Minimal or Standard token acquirer / scheme paths ·04 SDK API direct getEvidence() · threat events in-process, on the device tokens + full threat detail superset · no transit needed channels 01–03 · same token, same signature, same verifier · channel 04 · the same plus threat events
Channels 01–03 carry the Evidence Token (Minimal or Standard profile) — identical cryptographic semantics across all three. Channel 04 is the SDK API direct path: it surfaces the same tokens in-process, plus the full threat-events stream with detail that the network channels don't carry.

·01 HTTP header

Header de requête custom. Aucune modification du body de requête. Compatible avec n'importe quelle API d'autorisation REST.

X-YinkoShield-Evidence
POST /v1/payments/authorize HTTP/1.1
Content-Type: application/json
X-YinkoShield-Evidence: eyJhbGci
  OiJFUzI1NiIsImtpZCI6Ii4uLiIs
  InR5cCI6IkpXUyJ9...

{ "amount": "4200.00",
  "currency": "ZAR",
  "merchant_id": "..." }

·02 OpenTelemetry

Token et données de signaux émis comme attributs de span OTel à côté de votre télémétrie existante. Pas de couche d'intégration supplémentaire.

otel span attribute
from opentelemetry import trace

tracer = trace.get_tracer(__name__)
with tracer.start_as_current_span(
    "payment.authorize"
) as span:
    span.set_attribute(
        "execution_evidence",
        token,
    )

·03 ISO 8583

Embarqué dans DE 48 / DE 124 / DE 125 via une enveloppe BER-TLV 0xF0. ~216 octets au total dans DE 48 pour le Minimal Profile.

DE 48 · BER-TLV
F0 81 D4   -- outer TLV  (212 bytes)
  01 01 01 -- version = 0x01
  02 01 01 -- profile = Minimal
  03 81 CC -- JWS token (204 bytes)
    65 79 4A 68 62
    47 63 69 4F 69
    ...

·04 SDK API direct

Consommation in-process. Le code applicatif appelle le SDK directement pour récupérer le token signé — pas de canal de transit nécessaire. Pour de la télémétrie custom, des risk engines in-process, ou du logging local.

sdk · in-process
// Kotlin / Swift / equivalent
val ev = YinkoShield.getEvidence(
  ctx = paymentContext
)

riskEngine.evaluate(ev)
auditLog.record(ev)
customSink.emit(ev)
vérificateurs de référence

Sovereign verification — n'importe qui avec une clé publique.

Pas d'endpoint YinkoShield requis au moment de la vérification. L'opérateur stocke les clés publiques et valide les signatures ES256 — exactement comme pour n'importe quel PKI standard.

contrat vérificateur · huit étapes

  1. ·1

    Parser le JWS

    Header.payload.signature ; exiger alg=ES256, kid présent. Rejeter alg=none.

  2. ·2

    Résoudre la clé

    Lookup kid dans le key store de l'opérateur ; un re-fetch via canal mutually-authenticated.

  3. ·3

    Vérifier la signature

    ES256 sur BASE64URL(header).BASE64URL(payload). Tout échec cryptographique rejette.

  4. ·4

    Valider les claims

    Champs requis présents ; kid header = kid payload ; UUIDs bien formés.

  5. ·5

    Vérifier la fraîcheur

    ts dans la fenêtre définie par l'opérateur (recommandé ±5 minutes).

  6. ·6

    Contrôle de replay

    (did, tctx, event_name, seq) absent du dedup store partagé et atomique.

  7. ·7

    Sequence regression

    Événements de retry : seq doit excéder tous les seq antérieurs pour le même tctx.

  8. ·8

    Niveau de confiance

    Résolu depuis l'Evidence Record si récupéré ; software_layer sinon. Déclaré, jamais inféré.

Conformance cross-langage : le même token se vérifie de la même façon dans chaque langage, sinon l'un d'eux est cassé. Lire l'article (EN) →

modèle de signaux

Ce que l'appareil déclare. Pas comment il l'observe.

Le modèle de signaux déclare ce qui est observé, pas comment c'est acquis. Les détails d'implémentation — détection d'abus de l'accessibility-service, détection d'overlay, hooking, debugger attach — restent dans le runtime, pas dans la spec.

Signal Ce qu'il observe
device.integrity État d'intégrité au boot — un appareil reflashé échoue à la vérification dès la première transaction.
runtime.environment Environnement d'exécution — émulateur détecté ; déclaré dans l'evidence.
code.integrity Signature du code applicatif — un 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 — un SIM swap en cours de transaction est visible au retry.
modèle opérationnel

Primitive client-only. Pas de backend vendor dans le chemin. Engagements bilatéraux.

Le substrat a la même forme opérationnelle quel que soit le client : rien ne remonte vers YinkoShield, l'opérateur possède chaque clé, et l'adoption est une conversation de procurement, pas un abonnement.

  • ·01

    Modèle opérationnel

    Le runtime est livré comme module embarqué dans l'application de l'opérateur. Le vérificateur tourne dans la stack de l'opérateur contre les clés publiques stockées par l'opérateur. Pas d'endpoint YinkoShield dans le chemin de vérification. Pas de licence check au runtime. Pas de télémétrie que l'opérateur n'a pas demandée.

  • ·02

    Où cela ne s'applique pas

    EEI exige un host runtime — une application mobile, un firmware POS, ou un service shell SST — où le Trusted Runtime Primitive peut être embarqué. Les flows USSD-only, les flows SMS-only, et tout canal sans runtime installable sont hors-périmètre par construction. Pour les opérateurs de mobile-money, le canal app (le wallet que les utilisateurs installent) est dans le périmètre ; le short-code USSD qui tourne à côté ne l'est pas. Les deux coexistent ; EEI signe le côté app.

  • ·03

    Forme d'engagement

    Les engagements démarrent par un briefing technique — typiquement 60 minutes avec les responsables autorisation, fraude, et plateforme côté opérateur. Une évaluation cadrée suit, contre les données et seuils de risque de l'opérateur. Le pricing est un forfait annuel pour la primitive — sur demande, scopé à l'estate. Pas de metering par événement au runtime ; pas de licence beacon ; pas de télémétrie d'usage vers YinkoShield.

  • ·04

    Ce que l'opérateur possède

    Les clés (enregistrées par l'opérateur, ne quittent jamais le TEE de l'appareil à la génération). La vérification (l'opérateur fait tourner le vérificateur ; la spec est le contrat). La policy (le risk engine de l'opérateur combine les signaux signés avec son contexte business). La data (pas de PII dans l'evidence ; le ledger ne quitte pas l'appareil sans demande explicite de l'opérateur).

Pour le sommaire de la spec, le contrat de vérificateur, et la filiation standards — lire la page Spécification.

modules

Modules opérationnels sous le cœur EEI.

Capacités réelles, en production, qui opèrent à côté du cœur EEI. Pas l'argument architectural — des fonctionnalités opérationnelles pour des besoins adjacents.