Le Trusted Runtime Primitive

Ce que c’est

Le Trusted Runtime Primitive est la fondation du substrat EEI. C’est un module d’infrastructure embarqué à l’intérieur de l’user-land de votre application — votre app de banque mobile, le firmware de votre terminal d’acquéreur, le service shell de votre kiosque. Pas un SDK à câbler ; pas un service à appeler. Une couche runtime qui se trouve sous ce que vous livrez.

Le TRP est ce qui implémente la runtime coherence : la propriété selon laquelle le chemin d’exécution de l’appareil est observable, ordonné, et signé entre l’utilisation du credential et la réception réseau. L’article sur Runtime coherence décrit la propriété ; celui-ci décrit le module qui la produit.

Comment ça marche

Le TRP enveloppe chaque appel qui sort du code managé de l’application :

• syscalls — la frontière entre l’user-space et le kernel
• libc — la bibliothèque C standard (open, read, write, mmap, …)
• la bibliothèque framework — l’API runtime principale de la plateforme (framework Java sur Android, Foundation/UIKit sur iOS, équivalents sur POS / SoftPOS / SST)

En s’interposant sur ces couches, le TRP voit ce que l’app fait réellement au runtime — pas ce que son code source dit qu’elle devrait faire. Depuis ce point d’observation, nous surveillons en continu l’incohérence runtime : une séquence qui ne correspond pas à ce qu’un runtime de confiance produirait à ce point du flow. Un debugger attaché, un accessibility service rejouant les inputs utilisateur, une bibliothèque injectée appelant dans le framework là où le code applicatif ne le ferait jamais, un pattern de syscall caractéristique d’une famille de malware connue — chacun remonte comme signal signé au prochain événement.

La surveillance continue tourne sur les téléphones Android les plus bas de gamme que nous supportons, sur les terminaux POS d’agent banking en 2G/3G, sur les kiosques bancaires à CPU contraint. La performance n’est pas une fonctionnalité que l’opérateur active ; c’est une précondition pour que le substrat existe.

Pourquoi c’est plus dur à contourner

Deux décisions architecturales élèvent le coût de l’évasion du TRP :

• Runtime coherence, pas des règles de détection. Nous ne faisons pas tourner un ensemble fini de checks “si tu vois X, alerte” qu’un adversaire peut énumérer et éviter. Nous vérifions si la séquence d’appels est intérieurement cohérente avec un runtime de confiance — une propriété plus difficile à raisonner et plus difficile à falsifier.
• Policy découplée. Le TRP signe. Le moteur de policy de l’opérateur décide. Un adversaire qui apprend qu’un signal spécifique déclenche un decline ne peut pas simplement supprimer ce signal et passer : la même evidence est lue par la gateway, l’émetteur, la plateforme de litiges, et l’investigateur post-auth, chacun avec sa propre policy. Il n’y a pas de check unique à désactiver.

La combinaison — observation type cohérence plus policy côté opérateur — est ce qui rend le TRP plus dur à contourner qu’un runtime qui exécute une liste de règles fixe et renvoie un verdict.

outcomes

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

• Capturer l'environnement utilisateur à l'instant de l'action

  Abus d'accessibility-service, attaques d'overlay, debugger attach, frameworks d'instrumentation dynamique, substitution de bibliothèque — tout remonte comme signaux signés au prochain événement.

• Attraper les dernières familles de malware sans mises à jour de règles

  Les checks de cohérence observent la séquence que le runtime produit — pas une liste statique d'indicateurs. Les nouveaux malwares qui produisent une exécution incohérente remontent, même avant que leur signature ne soit publiée.

• Réconcilier contre le chemin côté appareil, pas contre l'inférence

  Les transactions disputées se résolvent contre une séquence signée d'événements d'exécution — pas un jugement de crédibilité entre logs backend et réclamation porteur.

• Appliquer un trust différencié au signing hardware-bound vs software-bound

  Même forme d'evidence, trust basis différent déclaré explicitement. Votre moteur de policy pondère le basis ; vous arrêtez de traiter 'device approved' comme un bit unique.

• Onboarder de nouvelles populations d'appareils sans intégration par-OEM

  Le TRP abstrait le TEE / Secure Enclave / Strongbox / HSM sous-jacent. Votre équipe ne livre pas une intégration par release plateforme.

• Passer de posture-au-point-de-contrôle à cohérence-à-l'exécution

  Les services d'attestation plateforme existants vous disent si un appareil était sain à un moment. Le TRP vous dit que le chemin entre les points de contrôle était cohérent.

properties

Ce que vous obtenez quand vous l'embarquez

• ·01 In-process, in-app

  Embarqué à l'intérieur de l'user-land de l'application. Pas d'agent out-of-band, daemon, ou service à gérer pour votre équipe plateforme.

• ·02 Enveloppe syscall, libc, framework

  Le TRP s'interpose sur les trois couches qu'une app traverse pour faire quoi que ce soit d'observable. La cohérence est vérifiée à la frontière de l'appel, pas inférée depuis les outputs.

• ·03 Continu, pas basé sur des points de contrôle

  Le runtime signe à chaque événement significatif — utilisation de credential, biométrie, assemblage de payload, soumission de requête — pas seulement aux appels d'attestation.

• ·04 Invariants d'identité cross-plateforme

  L'evidence signée a la même forme sur Android, iOS, POS, SoftPOS, SST. Un seul vérificateur gère l'estate entier.

• ·05 La déclaration du trust basis est explicite et machine-readable

  Hardware-bound, TEE-backed, software-resident — chacun déclaré dans le token. Les opérateurs appliquent la policy au basis déclaré, jamais à l'inférence.

• ·06 Cinq classes de signaux

  device.integrity · runtime.environment · code.integrity · binding.status · network.identity. Le signal model déclare ce qui est observé, pas comment c'était acquis.

• ·07 Testé à l'échelle sur appareils bas de gamme

  La surveillance continue tourne sur environ 13 000 configurations matérielles Android incluant des téléphones 1 Go RAM et des estates 2G/3G. La performance est une précondition, pas un paramètre de tuning.

• ·08 Découplé de la policy

  Le TRP signe ; l'opérateur décide. Il n'y a pas de check unique qu'un adversaire peut désactiver — la même evidence est lue par la gateway, l'émetteur, le litige, et l'investigateur, chacun avec sa propre policy.

Ce qu’il ne fait pas

Le TRP n’implémente pas de policy. Il ne décline pas les transactions. Il ne score pas le risque. Il produit un Evidence Token qui voyage avec la transaction ; ce que l’opérateur en fait — bloquer, autoriser, pondérer, logger — est la décision de l’opérateur. Cette séparation est délibérée, et c’est l’un des principes du substrat.

Pourquoi c’est dur

Un runtime portable plateforme qui enveloppe les appels syscall, libc, et framework ; tourne en continu sans casser l’application hôte ; produit la même forme d’evidence sur environ 13 000 configurations matérielles Android, iOS, terminaux POS, et estates SST ; et survit aux partitions, à la variance de disponibilité du TEE, et au drift d’API plateforme spécifique aux fournisseurs — c’est l’investissement d’ingénierie derrière la spec. La spécification est l’artefact ; la faire tourner à l’échelle est la moat.

Où en lire plus

La spécification complète du TRP — interface de wrapping d’appels, mesure runtime, observation de syscall, déclaration de trust basis, frontière du threat model — vit dans YEI-001 §5, partagée avec les régulateurs et partenaires qualifiés sous NDA.

Demander la spécification YEI-001 →