Hardware-backed SecretKey for endpoint identity (TPM 2.0 / Secure Enclave): seeking architectural guidance

[Ryujiyasu]

Hi n0 team,

The FAQ explicitly invites people with "specific needs around key types" to open a discussion, so here's mine. To be clear up front: I'm not asking for pluggable curve types. The Ed25519 commitment makes sense to me. I'm asking how to plug a hardware-bound signer in behind the existing Ed25519 identity.

The use case

Multi-institutional confidential computation transport — concretely, hospitals participating in a threshold-FHE computation, where each institution's iroh endpoint identity needs two properties beyond what filesystem-stored keys provide:

1. The endpoint ID corresponds to a key the institution can attest is bound to specific hardware.
2. Filesystem compromise (root escalation, backup theft, decommissioned disk) doesn't allow an adversary to impersonate the endpoint.

Today the secret key lives on disk (or in IROH_SECRET env var in the workshop examples). For this threat model that's not sufficient — the private key needs to live in a TPM 2.0, Apple Secure Enclave, or Android StrongBox, where signing is an oracle and extraction is physically impossible.

This overlaps in motivation (not mechanism) with the FROST blog post: "the device itself has a key share, but that alone is insufficient." Hardware binding is a different way to make a single key uncompromisable. It's also adjacent in spirit to #3168 (authorization) — both are about strengthening the trust basis of an Endpoint, but at different layers: that one asks "who is allowed to connect," this one asks "where does the identity actually live."

What I've already built

I maintain hyde, an MIT-licensed crate on crates.io that wraps TPM 2.0 (via tss-esapi) and exposes hardware-bound Ed25519 sign/verify where the key never leaves the TPM. So the signer side exists. The question is what shape of integration with iroh ages well.

What I'm seeing in the API

From reading iroh-base and the Endpoint::builder().secret_key(...) flow:

• SecretKey is a concrete struct holding an in-process ed25519_dalek::SigningKey. Sign/verify is synchronous and in-memory.
• The secret is consumed at three call sites I'm aware of: (a) the raw-public-key TLS handshake (v0.34+), (b) signing pkarr records for address publication, (c) authentication in the relay protocol.
• All three currently assume sync, in-process signing.

The recent rename from Discovery to AddressLookup and the introduction of EndpointHooks suggest the team is actively reshaping the extension surface around Endpoint. A SignerBackend trait would sit naturally alongside these — same kind of extension point, same connection-lifecycle layer.

TPM signing is the opposite shape: an async IPC to a hardware device, ~10–100ms per op. Fine for handshakes and pkarr republishes, almost certainly wrong for any per-packet path. From what I've read I don't think there is one at this layer, but please correct me.

The questions I'd like guidance on

1. Trait extraction. Would you be open in principle to SecretKey being backed by a trait (something like SignerBackend) that the in-memory implementation also implements? Or do you prefer this to live entirely outside, with adapter types feeding into the existing SecretKey? I can see arguments either way and want to follow your aesthetic before drafting anything.

2. Async signing. If a trait, should sign be async? rustls's SigningKey is sync but its cert resolver path isn't, so there's at least one boundary that could absorb async. Has the team thought about this for unrelated reasons?

3. Hot paths. Could you point me to the call sites where SecretKey::sign is actually invoked? I want to verify none of them are on a path that would make 10–100ms hardware signing structurally unworkable.

4. Relationship to FROST. The threshold-signing post effectively builds an external co-signer protocol on top of iroh. Is there appetite for the signer abstraction itself — not TPM-specific — to live in iroh-base, so FROST, TPM, HSMs, and remote-signing services can all plug in via one shape? Or do you see those as application-layer concerns by design?

5. Prior art check. I searched Discussions and recent issues and didn't find an existing thread on this specific topic, but happy to be redirected if there's prior art I should engage with first rather than starting fresh.

What I plan to do regardless

Ship iroh-hyde as an external crate against the current API, whatever shape that requires. Happy for it to stay external indefinitely — the goal of this discussion is to make sure the adapter ages well, not to push anything into core.

If there's interest in upstreaming a signer trait later, I'd be glad to draft a PR proposal once the abstraction is validated by ≥2 real backends (TPM + e.g. ssh-agent or a remote KMS).

Thanks for the FAQ note that opened this door, and for the FROST post — that's what convinced me this is the right project to engage on this topic.

[matheus23]

First of all, thank you for this well-written and thoughtful discussion post!

• Trait extraction. Would you be open in principle to SecretKey being backed by a trait (something like SignerBackend) that the in-memory implementation also implements? Or do you prefer this to live entirely outside, with adapter types feeding into the existing SecretKey? I can see arguments either way and want to follow your aesthetic before drafting anything.

I'd be somewhat hesitant on introducing this trait. We've changed a lot of things in the past couple of months, but we're now starting to stabilize our choices in the upcoming iroh 1.0 release. This doesn't mean a SignerBackend trait would be out of the question for iroh 1.x - after all - it would be an addition.
That said, I don't think you'd necessarily want this.

• Async signing. If a trait, should sign be async? rustls's SigningKey is sync but its cert resolver path isn't, so there's at least one boundary that could absorb async. Has the team thought about this for unrelated reasons?

Making it async would be nice because then e.g. browser could make use of WebCrypto-backed non-extractable keys.
That said, I'm not sure all call sites run in async contexts. E.g. there might be some rustls trait implementations that are fully synchronous and wouldn't allow asynchronous signing. Someone would have to check for these.

• Hot paths. Could you point me to the call sites where SecretKey::sign is actually invoked? I want to verify none of them are on a path that would make 10–100ms hardware signing structurally unworkable.

You listed them well, and I don't know any more off the top of my head right now. So yes: QUIC handshake/the rustls raw-public-key certificate, address lookup service signing of publishing records (pkarr as of now), and the iroh-relay authentication handshake.

• Relationship to FROST. The threshold-signing post effectively builds an external co-signer protocol on top of iroh. Is there appetite for the signer abstraction itself — not TPM-specific — to live in iroh-base, so FROST, TPM, HSMs, and remote-signing services can all plug in via one shape? Or do you see those as application-layer concerns by design?

It's likely we won't add that to iroh-base, unless it is used by iroh itself. I recommend having a think through what that would mean for stabilizing iroh-base: iroh-base is re-exported in iroh itself, so anything in iroh-base needs to be 1.0, including its dependencies that are exposed (or we need to be really careful about pinning them to a specific version, similar to what we're doing with rustls 0.23.X).
All of this is to say: It is much easier to have this in an external crate & to get others to adopt the same signing trait so stuff can become interoperable.

---

In general, for the use case you mention, I'd recommend a different design more similar to HTTP auth headers:

• Use ephemeral EndpointIds for devices
• Accept all Initial connection attempts from any EndpointId.
• Once a connection attempt has been made, do an authentication (and ideally authorization?) check: The connecting endpoint should sign the ephemeral EndpointId (and some other info, should you want authorization or revocation or time-based revocation) with their handware-backed identity.
• You might be able to use the Endpoint hook system to enforce this authentication check. It's possible this would need some modifications in iroh-gossip or iroh-blobs, should you want to use these iroh protocols to be able to configure setting a pre-connection-attempt middleware/hook.

[Ryujiyasu]

Thanks @matheus23 — this is the kind of redirect I was hoping for. The "auth as a post-connection step" framing makes more sense than what I proposed.

Restating to confirm I've understood:

• Transport identity stays as a normal in-memory ephemeral SecretKey — fast handshake, freely rotatable.
• Hardware-bound institutional identity lives entirely above the transport: the connecting endpoint signs (challenge, ephemeral EndpointId, optional time/revocation claims) with the TPM-held key after the connection is established.
• An EndpointHooks middleware gates the connection on verification before any protocol traffic flows.

This kills the 10–100ms-on-handshake problem, which was my biggest concern. It also means iroh-hyde should be re-framed as a hyde-iroh-auth middleware crate targeting the public EndpointHooks surface rather than touching SecretKey at all.

Two clarifying questions before drafting:

1. Pre-protocol gating granularity. You mentioned iroh-gossip / iroh-blobs might need modifications to support a pre-connection-attempt middleware. Is the current state that EndpointHooks can reject a peer before iroh-level protocol negotiation, but not before a protocol implementation has started exchanging frames? If so, is there a tracking issue I should follow / contribute to, or is this still pre-design?

2. Authentication signal surface. Is there an idiomatic place today for a hook to attach "this peer is authenticated as institution X" metadata that downstream protocol code can read, or would I be inventing that channel? Want to avoid building something that conflicts with a planned API.

I'll build the first cut externally against current iroh and post back here with a link once it's running end-to-end with a real TPM on one side. No expectation of upstream adoption — the goal is to validate the shape against a second backend (probably ssh-agent for portability) before revisiting whether anything trait-shaped is worth proposing.

Thanks again for engaging in detail.

[matheus23]

Yeah your understanding is correct.

1. Pre-protocol gating granularity. You mentioned iroh-gossip / iroh-blobs might need modifications to support a pre-connection-attempt middleware. Is the current state that EndpointHooks can reject a peer before iroh-level protocol negotiation, but not before a protocol implementation has started exchanging frames? If so, is there a tracking issue I should follow / contribute to, or is this still pre-design?

Endpoint hooks are sufficient for rejecting invalid endpoints before they get to be processed by iroh-gossip or iroh-blobs.
However, iroh-gossip and iroh-blobs have higher-level APIs for initiating connections. These APIs won't send the auth token/signature as first thing, which is what the endpoint hook will expect. So essentially:

• Endpoint hooks are only for the accepting side, but on that side it will fully cover iroh-gossip/iroh-blobs use cases
• The initiating side has no equivalent to the endpoint hooks, so that either needs dedicated support in iroh-gossip/iroh-blobs or some other mechanism in iroh.

[Ryujiyasu]

Thanks, that clarifies the asymmetry well.

To restate the constraint: EndpointHooks covers the accepting side fully (including iroh-gossip / iroh-blobs), but the initiating side has no equivalent — protocol-level "send auth as first frame" requires either dedicated support in those protocols or a separate iroh mechanism.

For my use case (hospital ↔ hospital, mutual auth required), that means the first cut likely has to:

• Use the public EndpointHooks for the accepting half on each side.
• For the initiating half, drive a hand-rolled protocol over Connection directly (skipping iroh-gossip / iroh-blobs initially), where the first uni-stream message is the auth assertion.

That gives me a working hyde-iroh-auth end-to-end without asking iroh-gossip / iroh-blobs for new APIs. If the design holds up, I can come back with a more concrete proposal for initiating-side hooks rather than speculating now.

One re-ask on the question you didn't get to:

Authentication signal surface. Is there an idiomatic place today for a hook to attach "this peer is authenticated as institution X" metadata that downstream code can read?

Not blocking — I can stash it in app state keyed by NodeId for the prototype — but if there's a planned shape (e.g. extension fields on Connection, or hook-set context map), I'd rather build against that.

Going to start coding now and report back with a runnable example. Thanks again.

[Frando]

There is EndpointHooks::before_connect which runs for any outgoing connection before the connection is even started. This will also run for iroh-blobs and iroh-gossip outgoing connection, and can be used to send a handshake over a separate ALPN before starting the actual connection.

See the auth-hook example for an implementation of this pattern. In this example, the echo protocol doesn't know anything about authentication, same as with iroh-blobs or iroh-gossip.

[Ryujiyasu]

Thanks @Frando — that's the missing piece. before_connect + separate-ALPN handshake means I don't need to skip iroh-gossip / iroh-blobs after all, and mutual auth becomes symmetric (both sides hook into the same point).

Updated mental model:

• Accepting side: EndpointHooks accept hook runs the auth-ALPN responder, verifies the institutional signature, gates the underlying protocol.
• Initiating side: EndpointHooks::before_connect opens an auth-ALPN connection first, signs the challenge with hyde, then lets the original outgoing connection proceed (or aborts on failure).
• The main protocol (echo / iroh-blobs / iroh-gossip / custom) stays completely auth-agnostic, exactly like the auth-hook example.

I'll work through the auth-hook example before drafting hyde-iroh-auth. Discussion's converged from my side — will come back with a link to a runnable end-to-end demo. Thanks both for the rapid back-and-forth.

[Ryujiyasu]

Following up with a link, as promised. First cut is built and running: https://github.com/Ryujiyasu/iroh-hyde-auth

It came out exactly as the thread converged on. Transport identity stays a normal in-memory ephemeral SecretKey; the hardware-bound institutional identity lives entirely above the transport and is exchanged over a separate auth ALPN, gated by EndpointHooks. The application protocol (echo in the examples, and by construction iroh-blobs / iroh-gossip) needs zero changes. Thanks @Frando for pointing at the auth-hook example — the structure carried over directly.

How it works

• A separate auth ALPN runs a challenge–response. The initiator signs (DOMAIN, nonce, its ephemeral EndpointId, timestamp) with the institutional key; the acceptor rebuilds the transcript from the QUIC-authenticated remote_id and verifies it against a roster. Binding to the ephemeral EndpointId is what stops a relay / MITM from replaying a captured assertion onto a session it doesn't control.
• before_connect on the initiator runs the handshake before the first application dial (cached per peer); after_handshake on the acceptor rejects application connections from peers that haven't authenticated.
• Signatures are ML-DSA (FIPS 204) via hyde, with the seed TPM-sealed — post-quantum, since the institutional identity is long-lived.
• There's also a mutual variant: both peers prove and verify in one exchange (role-separated transcripts to block reflection), for peer-to-peer trust like hospital ↔ hospital.

On the two questions I had

1. Gating granularity — after_handshake plus the separate-ALPN pattern was sufficient. The application protocol never sees an unauthenticated peer, and I didn't need to touch iroh-gossip / iroh-blobs at all. The auth-hook example fully answered this for my case.
2. Auth-signal surface — I ended up inventing the channel: the hook and the auth protocol share an in-process set keyed by EndpointId, and gating happens at the hook, so downstream protocols read nothing auth-specific. If there were ever an idiomatic place to attach "peer authenticated as institution X" connection metadata I'd happily move to it, but the shared-set approach is self-contained for now.

Second backend (portability) — done. There's an ssh-agent backend (ed25519 via a running agent) behind the same InstitutionalSigner / InstitutionVerifier traits. Hooks, roster, wire protocol, and transcript binding are identical; only the signature scheme differs. That's the validation I wanted that the shape isn't hyde-specific.

Status (being precise) — it runs end-to-end over loopback in tests (two real endpoints, relay + discovery disabled), validated with the software hyde backend and the ssh-agent backend. The TPM backend is the default and compiles, but I haven't done the real-TPM hardware bring-up yet — that's the remaining step before I'd call it validated on silicon.

One small note for anyone following the same pattern: the auth handshake has to dial the full EndpointAddr that before_connect hands you, not just the EndpointId — otherwise the auth connection can't resolve the peer when discovery is disabled.

No expectation of upstream changes (completely understand the 1.0 freeze) — posting the link as a reference point, per the plan. Thanks again @matheus23 and @Frando for the detailed steer.

[Ryujiyasu]

Quick update closing the one open item from my last post: the TPM backend is now validated end-to-end on a real hardware TPM (TCTI=device:/dev/tpmrm0), not just the emulator — hyde's full tss-esapi path (primary key, sealed ML-DSA seed, unseal + sign) plus the gated echo handshake all pass on actual silicon. I kept a swtpm path too for CI where there's no TPM.

So the shape holds on hardware, with a second (ssh-agent) backend behind the same InstitutionalSigner / InstitutionVerifier traits. Nothing upstream needed. Repo updated.

[domenkozar]

I'd highly recommend using https://secretspec.dev/ (disclaimer: I'm the author) so any provider can be used. There's a Rust crate at https://crates.io/crates/secretspec

That gives you flexbility in the span of clouds, personal computers, etc.