-
Notifications
You must be signed in to change notification settings - Fork 171
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
Comments
There's two problems with this:
An idea could be: we expose more utilities for making the 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. |
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?
👍
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
|
Yes. The idea would include rooting your identity in the root of the certificate chain instead of the ephemeral key. |
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. |
I don't think these issues are orthogonal: If we do an "identity revamp" we won't need to introduce a trait for |
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. |
@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". |
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:
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:
iroh_net::key::SecretKey
a trait containing onlypublic()
andsign()
(or using some of the traits from theed25519
crate)?SecretKey
to someInMemorySecretKey
struct, which is constructed.make_libp2p_extension
andsend_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.
The text was updated successfully, but these errors were encountered: