tee-sim — a SIMULATED TEE / secure element

A small, standalone, runnable program that behaves like a Trusted Execution Environment / secure element — it holds a non-exportable device key, issues hardware-style attestation quotes, and signs presentation bindings — but is a software simulation, not real hardware. It exists so the rest of the system (notably identity-attribution/crates/idattr-device) can be exercised end-to-end against a callable, runnable device, without a phone or a secure element on the bench.

It is wire-compatible with idattr-device v1: quotes and bindings produced here verify under that crate's verify_attestation / verify_binding. A pinned known-answer vector proves this in both repos (see Interop below).

⚠️ This is a SIMULATION — it is NOT a real TEE

Every "secure" property here is simulated in ordinary software:

• The device key and the attestation root are ordinary in-process Ed25519 keys, sealed to a plain local JSON file that anyone can read. There is no secure element, no hardware key isolation, and no genuine non-exportability — the simulator merely declines to expose the private keys through its own API (init/attest/bind never return them), mirroring a real SEE's surface.
• The attestation root is self-generated, not a vendor root (Google / Knox / Apple / TPM).

A quote from this simulator proves nothing about genuine hardware and must never be accepted as a real attestation in production. Genuine attestation requires a real secure element (e.g. Android StrongBox/TEE via the scarcity-device-client, a TPM, or Apple's Secure Enclave) with the vendor attestation root verified off-device. This simulator only exercises the API flow and the verifier's checks; the verifier interface is identical, so real quotes drop straight in.

Build

cargo build --release      # binary at target/release/tee-sim
cargo test                 # round-trip, rejection paths, and the known-answer vector

Use (callable CLI)

# provision + seal an enclave (random keys; or pass --dk-seed-hex/--root-seed-hex/--measurement-hex)
tee-sim init

tee-sim info                                   # device_pub, measurement, attestation_root, device_cert
tee-sim attest   --nonce <challenge>           # -> attestation quote (JSON)
tee-sim bind     --nonce <challenge> --transcript <presentation>   # -> device binding (JSON)
tee-sim device-cert                            # -> the commitment an issuer binds into a credential

# verify a quote/binding (JSON on stdin or via --in), fail-closed; exits non-zero on REJECTED
tee-sim attest --nonce c | tee-sim verify-attest --nonce c --root-hex <root> --measurement-hex <meas>

tee-sim selftest                               # full flow + replay/tamper/wrong-device rejection
tee-sim demo                                   # narrated end-to-end
tee-sim kat                                    # print the deterministic known-answer vector

Use (runnable HTTP service)

tee-sim init
tee-sim serve --addr 127.0.0.1:8645
# GET /info
# GET /attest?nonce=<hex>
# GET /bind?nonce=<hex>&transcript=<hex>
# GET /device-cert

/info always reports "simulation": true.

What it does (the model)

• Attestation — Attestation { measurement, device_pub, nonce, non_exportable, signature }. The platform root signs the canonical body DOMAIN ‖ measurement ‖ device_pub ‖ non_exportable ‖ len(nonce) ‖ nonce.
• verify_attestation (fail-closed): non-exportable, fresh nonce, measurement on the allowlist, valid root signature.
• device_cert_commitment(device_pub, measurement) — the issuer embeds this in a credential to name the enrolled device.
• bind / verify_binding — the device signs SHA-256(DOMAIN ‖ nonce ‖ transcript); the verifier checks the attestation, the binding signature under the attested key, and that the attested device matches the credential's device_cert.

Interop with idattr-device

The two implementations are independent but share the exact byte layouts (domains idattr-device/attestation|binding|device-cert/v1, length-prefix conventions, Ed25519). Because Ed25519 is deterministic (RFC 8032), a fixed (dk_seed, measurement, root_seed, nonce, transcript) yields fixed signatures. That known-answer vector is pinned here (tee-sim kat and the known_answer_vector_is_stable test) and again in identity-attribution/crates/idattr-device (interop_kat_from_tee_sim_verifies), where the simulator's signatures are checked under that crate's verifier. If either side changes the wire format, the interop test fails. See identity-attribution/docs/ARCHITECTURE.md.