combining HW solutions with noise_sv2

[plebhash]

This discussion presents potential directions for integrating hardware-backed security into Stratum V2's Noise Protocol implementation to enforce provable and sound guarantees around:

• Sv2 Connection Confidentiality
• Sv2 Connection Integrity
• Sv2 Server Authenticity

It is grounded in a review of PR #2283 ("Noise SV2 Hardening"), which closes 7 issues found by Project Loupe on noise_sv2 crate across:

• memory hygiene
• nonce reuse
• RNG quality
• buffer recovery

The PR hardens the security baseline for pure SOFTWARE-based integrations of noise_sv2 crate.

Any pure SOFTWARE implementation must hold key material in readable memory while it operates, so no software hardening can defend in-use secrets against an attacker with live memory access. Hardening bounds the exposure window and closes the forensic vectors.

But only HARDWARE isolation moves selected secrets out of RAM entirely — and only for the secrets it actually keeps inside.

---

This discussion asks: where could HARDWARE raise the bar even further, and how would noise_sv2 need to adapt?

Three hardware directions are explored:

Direction	What it solves	Which hardening theme it relates to
TRNG — hardware entropy source	Ephemeral-key unpredictability	CWE-338: CryptoRng enforcement
TPMs / Secure Elements — hardware-backed key stores	Long-term key confidentiality + erasure	non_secure_erase on long-term keypairs
TEEs — hardware-isolated execution	Key-material isolation from the host/hypervisor	Memory hygiene (defense in depth)

Each direction is additive, not a replacement — the PR's software hardening remains necessary for secrets that must leave the hardware boundary.

Note: generated with help from Kimi K3 plus DeepSeek V4 Pro (both on high reasoning mode), with PR #2283 and sv2-spec loaded into the context window, guided by SRI core contributor @plebhash

Note: this Discussion is organized in threads, which should evolve around specific topics. Please avoid starting a new thread if your comment is directly related to a specific topic that already has a dedicated thread. Otherwise there's no point in using Github Discussions and this is just a Github Issue.

[plebhash]

1 · TRNG — Hardware True Random Number Generator

Context from the review

PR #2283 enforces rand::CryptoRng on every key-generation constructor. Before the PR, Responder::new_with_rng and Initiator::new_with_rng accepted any rand::Rng — a StepRng (deterministic counter) would compile silently. The fix makes the invariant compile-time: if your RNG isn't cryptographically suitable, the code won't build.

The trait bound doesn't dictate how the RNG obtains entropy — only that it promises cryptographic quality. This is the seam where hardware TRNGs fit.

What TRNG hardware gives you

Many embedded platforms — ARM Cortex-M, ESP32, STM32, RISC-V MCUs — ship dedicated TRNG peripherals. These circuits sample physical entropy (thermal noise, ring oscillators, avalanche breakdown) and produce raw bitstreams. They do not require an OS; they're accessible from bare-metal no_std — exactly the use case that noise_sv2's new_with_rng API was designed for.

How to wire it correctly

A TRNG produces raw entropy (biased, limited bitrate, possibly blocking). It is not a CSPRNG in itself. The correct pattern:

Hardware TRNG → seed a CSPRNG (e.g., ChaCha12Rng) → pass to `noise_sv2`

The TRNG seeds the CSPRNG; the CSPRNG stretches the entropy deterministically and uniformly. The CSPRNG implements CryptoRng and gets passed to Responder::new_with_rng / Initiator::new_with_rng.

What already works today: if your platform's rand crate implementation (getrandom → custom backend) reads from a hardware entropy source, or if you write a CryptoRng impl that wraps your TRNG-seeded CSPRNG, noise_sv2 accepts it out of the box — zero changes to the crate.

Open questions for the community

• Should noise_sv2 ship a reference CryptoRng implementation backed by a TRNG-seeded ChaCha CSPRNG, targeting common no_std MCU targets?
• What is the minimum set of embedded platforms where TRNG hardware is sufficiently common to justify in-tree support vs. leaving it to the integrator?

[plebhash]

2 · Hardware-backed key stores and cryptographic coprocessors — TPMs and Secure Elements

Context from the review

In PR #2283, the Responder holds three keypairs — a (the authority key, the pool's long-term identity, used to sign each handshake), s (the static key, the handshake ECDH key that a signs), and e (the ephemeral key, per-session) — and wipes them via secp256k1's non_secure_erase on drop. This writes zeroes through a C-level barrier, but the function's own name admits that compiler copies may survive.

The authority key a is the most sensitive. It is loaded once and held in process memory for the pool's entire lifetime, and it is the root of trust that signs each handshake's static key s (sv2-apps builds every Responder from the authority keypair). If a leaks, an attacker can impersonate the pool to any miner indefinitely. s and e, generated per connection, are shorter-lived. Note that non_secure_erase runs only on drop — a core dump of a live process captures the bytes regardless, so erasure at shutdown does not protect a running server.

TPM vs. secure element: the relationship

A secure element (SE) is the broad category: a tamper-resistant chip that generates and stores keys internally and performs cryptographic operations without ever exposing private material. A TPM is a standardized kind of secure element, specified by the Trusted Computing Group, with a well-defined API (the TPM2_* commands), a defined storage hierarchy, and a role in platform integrity.

What distinguishes a TPM from a generic secure element is the surrounding ecosystem: PCRs (platform configuration registers) that hash the boot chain, measured boot, sealing (binding a key to a specific PCR state so it unseals only if the platform booted as expected), a standardized API, and remote attestation (a signed quote of the PCR values a remote party can verify). These matter more for proving what platform a key lives in than for per-message crypto.

What hardware-backed key storage gives you

The device generates the key inside the chip. The private key never exists in system RAM, never appears in a core dump, and is never exportable. Cryptographic operations — ECDH, ECDSA sign — happen inside the device, not in software.

For noise_sv2, the relevant operations are:

• Key generation: TPM2_CreatePrimary or TPM2_Create generates an ECDH key pair bound to the TPM's storage hierarchy. The private key is wrapped by the TPM's storage root key and never exposed.
• ECDH: TPM2_ECDH_ZGen performs an ECDH key exchange using the resident private key, outputting the shared-secret Z point. The host receives only that ephemeral Z point, already expired by the time the handshake finishes.

The generalized noise_sv2 design point

Today, Responder::new(a: Keypair, …) receives the static key as a secp256k1::Keypair — raw bytes, in RAM:

pub fn new_with_rng<R: rand::Rng + rand::CryptoRng + ?Sized>(
    a: Keypair,          // ← byte array in process memory
    cert_validity: u32,
    rng: &mut R,
) -> Box<Self>

The temptation is to add a TPM-specific constructor like new_with_tpm. That would be a mistake, for two reasons. First, TPM is one member of a family — a new_with_tpm API bakes in one vendor's command set and leaves every other secure element (and HSMs) out. Second, it couples the protocol crate to a hardware-specific command-marshalling layer (tss-esapi, TPM2_* command numbers), which is exactly the platform-support concern a protocol crate should avoid.

The cleaner design is a capability-oriented abstraction: a non-exportable handle to a key, plus a provider that performs the cryptographic operations noise_sv2 needs without ever exporting private material:

/// Performs handshake operations against keys the caller cannot see.
trait HandshakeKeyProvider {
    /// ECDH between the provider-resident static key (`s`) and `peer_public`,
    /// returning the shared-secret Z point (never the private key).
    fn ecdh(&mut self, peer_public: &[u8; 32]) -> Result<[u8; 32], Error>;
    /// Sign the handshake's signature message with the authority key (`a`).
    fn sign(&mut self, msg: &[u8]) -> Result<Signature, Error>;
    // + key-identity / attestation accessors as needed
}

A full responder needs both operations: ecdh with the static key s, and sign with the authority key a. Of the two, a is the more valuable to hold in hardware — it is the long-term identity, and signing is a standard TPM/SE/HSM operation; s is generated per connection and shorter-lived. A constructor such as Responder::new_with_key_provider would take a HandshakeKeyProvider instead of a raw Keypair: a TPM implementation calls TPM2_ECDH_ZGen (for s) and TPM2_Sign (for a); a secure-element implementation calls the vendor equivalents; and the existing secp256k1 path remains the default software implementation and the fallback.

Compatibility caveat: secp256k1 is not universal

A hard constraint worth flagging early: noise_sv2 uses secp256k1 for both handshake ECDH and the authority signature. Many TPMs and secure elements support only a restricted set of curves — commonly NIST P-256, sometimes P-384/521 — and may not support secp256k1 at all. A HandshakeKeyProvider integration only works where the device can actually do secp256k1 ECDH and ECDSA. Where it cannot, the options are a different curve (a protocol change, not a local one) or accepting that those devices cannot host the static key. This is a real, protocol-level compatibility boundary, not a detail.

HSMs: the server/fleet-scale sibling

At the other end of the scale, HSMs (hardware security modules) provide the same non-exportable-key model for servers and fleets. They are relevant to a pool's key lifecycle — generating, storing, rotating, and auditing the long-term authority key and static key — but their per-command latency and cost typically make them a poor fit for per-handshake ECDH at high connection rates. The natural division: an HSM holds and rotates the long-term keys; a HandshakeKeyProvider abstracts whatever actually performs the handshake operations.

What hardware-backed key stores do NOT solve (and why the PR is still needed)

These devices generally lack chacha20poly1305 support — they offer AES, SHA, HMAC, ECC, RSA. The session keys temp_k1/temp_k2 and the AEAD framing still run in software in host memory. The PR's zeroize_bytes, erase-on-drop, and nonce-isolation all remain necessary for these ephemeral transport keys.

They also introduce a blocking boundary: TPM commands are slow (milliseconds per operation), while noise_sv2 is currently synchronous. Accepting blocking calls is fine — handshakes are infrequent relative to data frames — but it shapes the API.

Prior art and tooling

• Linux: /dev/tpm0 and the tpm2-tss / tpm-tools stack
• Rust: tss-esapi crate for TPM2 command marshalling
• Reference: TPM 2.0 spec Part 3, Section 13.2 (TPM2_ECDH_ZGen)
• Secure elements: GlobalPlatform SE specifications; vendor SDKs (e.g., mobile SEs)
• HSMs: PKCS#11 / KMIP APIs

Open questions

• Should noise_sv2 define a HandshakeKeyProvider / KeyHandle trait in-tree, with secp256k1 as the default software implementation, or leave the abstraction to consumers?
• Which TPMs/secure elements actually support secp256k1 ECDH? An inventory is needed before any integration is promised.
• Is ECDH-over-TPM acceptably fast in practice? Benchmark data needed.
• Should Initiator also gain a provider-backed variant (for client-side identity keys in authenticated Noise patterns like XK)?

[plebhash]

3 · TEEs — hardware-isolated execution for Noise secrets

Context from the review

The PR's memory hygiene changes trace every copy of key material through the handshake and wipe the ones within reach: HKDF temp keys, ECDH outputs, HMAC pads, cipher-key locals. But it honestly documents what it cannot reach:

• Registers and spilled stack slots — the compiler owns these.
• The concat() heap temp in hkdf_2 — a 33-byte heap allocation holding a copy of out_1 (which, in the final HKDF call, is a transport session key). Dropped without wiping.

The PR answers this with zeroize_bytes (volatile writes the compiler can't elide), then falls back on process isolation for the copies it can't reach. Hardware-isolated execution challenges that fallback.

"TEE" is the umbrella term

A TEE (Trusted Execution Environment) is any hardware-isolated execution domain that can hold secrets and run trusted code while an untrusted host OS or hypervisor runs alongside it. The term covers a family of designs with different boundaries. One clarification up front: "Secure Enclave" is a specific Apple product — the security coprocessor/key manager in Apple silicon — not a generic synonym for the category. Throughout this section, "TEE" is the umbrella term, and the family splits by where the isolation boundary is drawn and what runs inside it.

Endpoint TEEs and secure-world designs

On the endpoint — the downstream side of Sv2, the miner, the proxy, the device — the relevant designs are:

• ARM TrustZone: partitions the CPU into a secure world and a normal world. A world bit plus a memory-partitioning controller (TZASC/TZMA) divides memory into secure and non-secure regions. The secure world runs its own small OS — OP-TEE, TF-M, QSEE — and its own "trusted applications." Normal-world software (the rich OS, any app) cannot read or write secure-world memory. Note what is not happening: TrustZone does not, by default, encrypt memory; isolation is access control.
• Apple Secure Enclave: a dedicated coprocessor on Apple SoCs that owns its keys and performs limited operations (key generation, ECDH, signature) on request. It is TrustZone-like in spirit — an isolated, purpose-built secure environment — despite the "Secure Enclave" name.

Endpoint TEEs are the natural home for a downstream role's long-term identity keys (for example, the client-side static key in an authenticated Noise pattern like XK), and for any secret the miner must keep while an untrusted rich OS runs around it.

Server confidential-computing TEEs

On the server — the upstream side of Sv2, the pool — the relevant designs are confidential-computing TEEs. Here the boundary is drawn differently, and memory is encrypted:

• Intel SGX: a process-level enclave. The enclave runs inside a normal process, but its pages live in encrypted EPC memory the OS/hypervisor cannot read. The enclave can prove its identity and code to a remote party via remote attestation.
• Intel TDX and AMD SEV-SNP: a confidential VM boundary. The isolation unit is a whole virtual machine, encrypted and attestable, protecting guest memory from the hypervisor.

These are the natural home for a pool's authority signing key (a) and responder static key (s), protecting them from a compromised kernel or hypervisor on the pool's own hardware.

Practical integration routes

• Lift-and-shift: run noise_sv2 inside a TEE without modifying its source. Gramine (SGX) runs the unmodified native binary via a libOS; Enarx runs a WebAssembly build inside a confidential VM (SGX/SEV). The handshake + transport crypto run in isolated memory; the application outside shuttles ciphertext frames. Both are usable today.
• Native port: noise_sv2 compiled for a specific TEE SDK (the SGX SDK, or a TrustZone trusted application), exposing calls for handshake_init, handshake_step, split_transport, encrypt_frame, decrypt_frame. The TransportEncryptState and TransportDecryptState live inside the trusted domain.

What TEEs do — and do not — give you

TEEs reduce exposure to the untrusted host/hypervisor: secrets held inside cannot be read by a compromised OS, a debugger, or a memory dump of the host. This is a genuine hardening improvement, but it is not a substitute for zeroization:

• Zeroization remains defense in depth. Any secret copied outside the trusted boundary — and transport keys inevitably are, for line-rate AEAD — is back in plain memory, so the PR's zeroize_bytes remains necessary for them.
• TEEs do not eliminate side channels. Cache, page-fault, and timing side channels have repeatedly been shown to leak enclave/secure-world secrets.
• TEEs do not eliminate trusted-code bugs. A bug inside the trusted domain is as dangerous as one outside it; the TEE shrinks the set of code that can touch the secret and raises the cost of exploitation.
• TEEs do not eliminate I/O and boundary exposure. Every byte that crosses the world/ECALL/VM boundary is in plaintext on at least one side. The boundary interface itself is attack surface.

Attestation: a clarification

TrustZone does not lack attestation, but it lacks a universal, SGX-like attestation ecosystem. Intel SGX ships a quoting enclave and an attestation service as a coherent product. TrustZone's equivalent is fragmented: Arm PSA (Platform Security Architecture) provides an attestation framework, but real-world deployments lean on device-specific trust chains — provisioning performed by the silicon vendor, whose keys ultimately control what the secure world can claim. For Sv2, this means: do not assume a portable "prove my TEE to the remote party" primitive exists across platforms; the trust chain is platform-specific.

Open questions

• Should noise_sv2 ship a reference TrustZone trusted application (OP-TEE / TF-M) wrapping the handshake, or leave the world boundary to integrators?
• Does Sv2 need a client-authenticated Noise pattern (XK) before endpoint TEEs become worthwhile for miners?
• Is a Gramine-based lift-and-shift guide sufficient, or does noise_sv2 benefit from a native SGX abstraction in-tree?
• What is the concrete AEAD throughput inside an SGX enclave with chacha20poly1305? Would it meet stratum's frame rate requirements for a large pool?
• Should noise_sv2 consider a feature = "tee" gate that moves transport into TEE-resident types as an optional compilation mode?