blog: Where does your trust live? Cryptographic soundness and the TEE trade

[heeckhau]

Important

Merge #62 (companion post on public verifiability) first — this post links to it.

Summary

New blog post examining Peer's move from zkTLS to a TEE (AWS Nitro Enclaves) for payment verification.

• Not an integrity argument: on-chain both approaches end at the same signed attestation, and against a single attestor a TEE can even raise the integrity bar.
• A privacy argument: with zkTLS the credential never leaves the user's device; with a TEE it is decrypted inside the operator's hardware, and the confidentiality rests on an attestation signature rather than on structure.
• Walks through the attest, then encrypt pattern, what client-side attestation checks do and don't settle, and the "three anchors" framing (operator's word / hardware / structure).
• Closes with the speed question: current proxy-mode benchmarks (~1.6s) vs the thirty-second figure, and SpeakUp as the cryptographic path forward.

Includes light/dark figures for the plaintext boundary and three-anchors diagrams.

[0xSachinK]

Thanks for the thoughtful writeup. I agree with the high-level distinction here: zkTLS and TEE-TLS put trust in different places. A few counterpoints / clarifications from the Peer side:

1. The right critique is not "Peer/operator sees credentials." In the TEE flow, the client verifies a fresh Nitro attestation and then encrypts session material to a key bound to the attested enclave. The plaintext is processed inside Nitro enclave memory for a bounded verification request; it is not exposed to the EC2 host/operator under the Nitro threat model.

2. The "attacker binds their own key to the expected measurement" scenario is a catastrophic break of Nitro remote attestation or the trusted root / measurement binding. That is a valid general TEE trust assumption to call out, but it is not a Peer-specific operator failure mode. Under the advertised model, an operator cannot swap in its own key and still pass client verification.

3. A TEE here is not just a "signature from a chip." The enclave performs the payment-platform request, validates the response against the expected payment details, and only then emits the payment attestation. On-chain, both systems end in a delegated attestor signature, but the TEE changes what it takes for the signer to lie.

4. The latency comparison should be made at the end-to-end production flow level. The ~30s number came from the deployed user path we replaced. A standalone proxy-mode benchmark is useful, but it is not a full comparison of browser/mobile capture, proving, network round trips, failure rate, and p95/p99 completion.

I would phrase the Peer position as: TEE-TLS is not the same formal privacy model as zkTLS. It is a pragmatic trust shift: user secrets move from "never leave the device" to "only enter a remotely attested enclave that the operator cannot inspect." Reasonable people can prefer the zkTLS model, but "privacy is just an operator promise" or "Peer can see credentials" is not accurate.