Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow using iroh with other signers #2355

Open
flokli opened this issue Jun 9, 2024 · 7 comments
Open

Allow using iroh with other signers #2355

flokli opened this issue Jun 9, 2024 · 7 comments

Comments

@flokli
Copy link

flokli commented Jun 9, 2024

I'd like to use iroh with other signers, which are not a private ed25519 key living in the host memory, but "external signer".

Some examples include:

  • FIDO tokens
  • Cloud HSM/Key vault things
  • Smartcards (PKCS#11 3.0)

We probably don't want to implement any of these in iroh itself (at least not for starters), but allow others to "bring their own signers".

Proposal:

  • make iroh_net::key::SecretKey a trait containing only public() and sign() (or using some of the traits from the ed25519 crate)?
  • move the existing SecretKey to some InMemorySecretKey struct, which is constructed.
  • update the two consumers (make_libp2p_extension and send_client_key when I checked) to be generic (or use dynamic dispatch). It seems this is not in the path for each packet, so maybe dynamic dispatch is fine.

This will be an API change, but so might #1908 be too - so it might make sense to batch this together.

@matheus23
Copy link
Contributor

There's two problems with this:

  • I'm not sure we want to do an HSM access/Smartcard read or yubikey user interaction every time SecretKey is used in iroh for performance reasons.
  • It'd need some thought on how such an API can be supported in an FFI context

An idea could be: we expose more utilities for making the SecretKey used in iroh more ephemeral by allowing to pass in self-signed certificate chains.
You'd then throw away the ephemeral key after shutdown and re-generate it on startup.
And you can sign the ephemeral key on startup outside iroh with a hardware-backed key and thus generate a self-signed certificate chain.

That said, this needs some thought in terms of threat model. If an online attacker can access the ephemeral key from memory and the certificates don't practically expire or aren't really revocable, it's as good as if we didn't have any certificate chains. If the certificate chains expire, this needs some extra thought on how to provide new certificates to iroh every time they do. If the certificates can be revoked, there needs to be some thought on how revocations are stored.


It'd be helpful to look into how other projects solve this. I know AWS's CloudHSM for example take over the whole TLS connection establishment.

@flokli
Copy link
Author

flokli commented Jun 17, 2024

There's two problems with this:

* I'm not sure we want to do an HSM access/Smartcard read or yubikey user interaction every time `SecretKey` is used in iroh for performance reasons.

I'd expect using these things for key storage would need to be configured explicitly, so it'd be some kind of opt-in. How bad is the performance penalty? I'd assume it'd only run when establishing a new connection, not after that?

* It'd need some thought on how such an API can be supported in an FFI context

👍

An idea could be: we expose more utilities for making the SecretKey used in iroh more ephemeral by allowing to pass in self-signed certificate chains. You'd then throw away the ephemeral key after shutdown and re-generate it on startup. And you can sign the ephemeral key on startup outside iroh with a hardware-backed key and thus generate a self-signed certificate chain.

This would be a very big change in architecture. Right now, the ed25519 key "becomes your identity", and cycling through these on every startup mandates solving the whole PKI-related questions you wrote.

The proposal in here already effectively prevents key material from being stolen/copied 1, by putting it into some smartcard/HSM, without change in protocol.

Rotating these keys, and using a PKI and certificates to establish which keys to trust is something some setups might want, and can be done on top of it, at a lower cadence (so maybe it's fine if the identities change) - but generally I see that an orthogonal issue.

Footnotes

  1. If we ignore the possibility of the smartcard physically getting stolen and someone knowing/guessing the pin, of course ;-)

@matheus23
Copy link
Contributor

This would be a very big change in architecture. Right now, the ed25519 key "becomes your identity", and cycling through these on every startup mandates solving the whole PKI-related questions you wrote.

Yes. The idea would include rooting your identity in the root of the certificate chain instead of the ephemeral key.

@flokli
Copy link
Author

flokli commented Jun 25, 2024

I feel these two things are a bit orthogonal to each other. I can understand you don't want to deal with this issue before that's being implemented, but there should probably be a separate tracking issue for the whole identity revamp.

@matheus23
Copy link
Contributor

I don't think these issues are orthogonal: If we do an "identity revamp" we won't need to introduce a trait for SecretKey in the iroh codebase.
Perhaps I misunderstand your use-case though. What's your end goal? Why do you want to move the key out of working memory? Does your threat model include that a malicious actor with working memory access? Do you want to be able to recover from such a compromise or do you want to protect from such a compromise completely?

@flokli
Copy link
Author

flokli commented Jun 25, 2024

I don't want to have key material on disk, primarily. Which is why it'd be nice for these to be living in the TPM, bound to some PCRs, or using FIDO/PIV.

@ramfox ramfox moved this to 📋 Backlog in iroh Jul 10, 2024
@rklaehn
Copy link
Contributor

rklaehn commented Oct 10, 2024

@flokli this is not going to work for all things, but I think we are going to attempt making at least the signing more flexible. I have recently played around with FROST, see https://github.com/rklaehn/frosty . There will be a blog post in the near future about this as well.

We are probably going to keep PrivateKey put pass the discovery traits a "signer" instead of always taking a private key. This is to support the use case where you don't have the private key but just "a means to sign".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Development

No branches or pull requests

3 participants