The Trusted Runtime Primitive

What it is

The Trusted Runtime Primitive is the foundation of the EEI substrate. It is an infrastructure module embedded inside your application’s user-land — your mobile banking app, your acquiring terminal’s firmware, your kiosk’s service shell. Not an SDK to wire up; not a service to call. A runtime layer that sits underneath what you ship.

The TRP is what implements runtime coherence: the property that the device’s execution path is observable, ordered, and signed between credential use and network receipt. The article on Runtime coherence describes the property; this one describes the module that produces it.

How it works

The TRP wraps every call that crosses out of the application’s managed code:

• syscalls — the boundary between user-space and the kernel
• libc — the standard C library (open, read, write, mmap, …)
• the framework library — the platform’s main runtime API (Java framework on Android, Foundation/UIKit on iOS, equivalents on POS / SoftPOS / SST)

By interposing on those layers, the TRP sees what the app actually does at runtime — not what its source code says it should do. From that vantage point we continuously monitor for runtime incoherence: a sequence that does not match what a trusted runtime would produce at this point in the flow. A debugger attached, an accessibility service replaying user input, an injected library calling into the framework where the app code never would, a syscall pattern characteristic of a known malware family — each surfaces as a signed signal on the next event.

The continuous monitoring runs on the lowest-end Android handsets we ship to, on agent-banking POS terminals over 2G/3G, on bank kiosks with constrained CPU. Performance is not a feature the operator opts into; it is a precondition for the substrate to exist.

Why this is harder to bypass

Two architectural decisions raise the cost of evading the TRP:

• Runtime coherence, not detection rules. We are not running a finite set of “if you see X, alert” checks that an adversary can enumerate and avoid. We are checking whether the sequence of calls is internally consistent with a trusted runtime — a property that is harder to reason about and harder to fake.
• Decoupled policy. The TRP signs. The operator’s policy engine decides. An adversary who learns that one specific signal triggers a decline cannot simply suppress that signal and pass through: the same evidence is read by the gateway, the issuer, the dispute platform, and the post-auth investigator, each with their own policy. There is no single check to disable.

The combination — coherence-style observation plus operator-side policy — is what makes the TRP harder to bypass than a runtime that runs a fixed rule list and returns a verdict.

outcomes

What this lets you do today that you couldn't before

• Capture the user's environment at the moment of action

  Accessibility-service abuse, overlay attacks, debugger attach, dynamic-instrumentation frameworks, library substitution — all surface as signed signals on the next event.

• Catch the latest malware families without rule updates

  Coherence checks observe the sequence the runtime is producing — not a static list of indicators. New malware that produces incoherent execution surfaces, even before its signature is published.

• Reconcile against the device-side path, not against inference

  Disputed transactions resolve against a signed sequence of execution events — not a credibility judgment between backend logs and a cardholder claim.

• Apply differentiated trust to hardware-bound vs software-bound signing

  Same evidence shape, different trust basis declared explicitly. Your policy engine weights the basis; you stop treating 'device approved' as a single bit.

• Onboard new device populations without per-OEM integration

  The TRP abstracts the underlying TEE / Secure Enclave / Strongbox / HSM. Your team doesn't ship one integration per platform release.

• Move from posture-at-checkpoint to coherence-at-execution

  Existing platform-attestation services tell you whether a device was healthy at one moment. The TRP tells you the path between checkpoints was coherent.

properties

What you get when you embed it

• ·01 In-process, in-app

  Embedded inside the application's user-land. No out-of-band agent, daemon, or service for your platform team to manage.

• ·02 Wraps syscall, libc, framework

  The TRP interposes on the three layers an app crosses to do anything observable. Coherence is checked at the call boundary, not inferred from outputs.

• ·03 Continuous, not checkpoint-based

  The runtime signs at every significant event — credential use, biometric, payload assembly, request submission — not only at attestation calls.

• ·04 Cross-platform identity invariants

  The signed evidence has the same shape across Android, iOS, POS, SoftPOS, SST. One verifier handles the entire estate.

• ·05 Trust-basis declaration is explicit and machine-readable

  Hardware-bound, TEE-backed, software-resident — each declared in the token. Operators apply policy to the declared basis, never to inference.

• ·06 Five signal classes

  device.integrity · runtime.environment · code.integrity · binding.status · network.identity. The signal model declares what is observed, not how it was acquired.

• ·07 Low-end-device tested at scale

  Continuous monitoring runs on roughly 13,000 Android hardware configurations including 1 GB RAM handsets and 2G/3G estates. Performance is a precondition, not a tuning parameter.

• ·08 Decoupled from policy

  The TRP signs; the operator decides. There is no single check an adversary can disable — the same evidence is read by gateway, issuer, dispute, and investigator, each with their own policy.

What it does not do

The TRP does not implement policy. It does not decline transactions. It does not score risk. It produces an Evidence Token that travels with the transaction; what the operator does with it — block, allow, weight, log — is the operator’s decision. This separation is deliberate, and it is one of the principles of the substrate.

Why this is hard

A platform-portable runtime that wraps syscall, libc, and framework calls; runs continuously without breaking the host application; produces the same evidence shape across roughly 13,000 Android hardware configurations, iOS, POS terminals, and SST estates; and survives partition, TEE-availability variance, and vendor-specific platform-API drift — that is the engineering investment behind the spec. The specification is the artefact; running it at scale is the moat.

Where to read more

The full specification of the TRP — call-wrapping interface, runtime measurement, syscall observation, trust basis declaration, threat model boundary — lives in YEI-001 §5, shared with regulators and qualifying partners under NDA.

Request the YEI-001 specification →