search

smallstep / certificates

🛡️ A private certificate authority (X.509 & SSH) & ACME server for secure automated certificate management, so you can use TLS everywhere & SSO for SSH.
https://smallstep.com/certificates
Apache License 2.0
6.36k stars 415 forks source link

TKey integration #1820

Open jpds opened 2 months ago

jpds commented 2 months ago

Hello!

Issue details

I'd like to have step-ca integrate with the Tillitis TKey: https://tillitis.se/products/tkey/ - so that this open hardware can be used as a root-of-trust HSM for step-ca, including directly deriving the key for the authority certificate on the hardware itself: https://tillitis.se/blog/2023/03/31/on-tkey-key-generation/

The device itself does not present a PKCS#11 interface, but rather has device apps uploaded to it over a serial port - https://github.com/tillitis/tkeyclient is a Go package that handles this.

Another blocker would be that the upstream signer app only supports Ed25519 (which of course is not supported by browsers for certificates): https://github.com/tillitis/tkey-device-signer/issues/6

maraino commented 2 months ago

Hi @jpds, I haven't tested this using a TKey, but as a TKey has an ssh-agent, you can sign keys using our sshagentkms. For example, I can create self-signed certificate using my GitHub key present in the agent:

$ step certificate create --kms sshagentkms: --key sshagentkms:mariano@overlook.local --profile self-signed --subtle mariano@overlook.local mariano.crt
Your certificate has been saved in mariano.crt.

This requires the use of step-kms-plugin.

hslatman commented 1 month ago

Hey @jpds, we've discussed this issue internally, and are open to suggestions. As @maraino pointed out, you probably can already use it with SSH certificates, and I suppose it could be used as an SSH CA too.

For X509 the matter is indeed different. It sounds like it could work for Ed25519 already, but we'd be limited to a single key, or would have to provide an USS. The https://github.com/tillitis/tkeysign package looks usable, but it would need to be wrapped to fit our existing interfaces for signing (i.e. our KMS implementations). And as you pointed out, it would be nicer if the TKey supported at least ECDSA.

jpds commented 1 month ago

Hey folks, so this is how to generate a self-signed certificate from the key derived on a TKey with a particular USS:

$ set SSH_AUTH_SOCK $XDG_RUNTIME_DIR/tkey-ssh-agent/sock
$ step certificate create --kms sshagentkms: --key sshagentkms:TKey --profile self-signed --subtle user@test.local user.crt

I can generate a CSR with:

$ step certificate create --kms sshagentkms: --key sshagentkms:TKey --csr boo.crt boo.csr

However, I wasn't able to take a second TKey (which would ultimately be plugged into a server box) and use that to sign a CSR request from the first TKey. The sign command doesn't appear to take --key sshagentkms::

$ step certificate sign --kms sshagentkms: --key sshagentkms:TKey ...
...
flag provided but not defined: -key

Looking at https://smallstep.com/docs/tutorials/ssh-certificate-login/ - I also cannot see a way to "use a root key that's derived from a USS on the second TKey" - it appears only Azure is supported:

$ step ca init --ssh --kms sshagentkms:
invalid value 'sshagentkms:' for flag '--kms'; options are azurekms
hslatman commented 1 month ago

Hey @jpds, it looks like we don't currently support signing a CSR with a CA key in a different KMS directly. Our KMS plugin gets invoked for certain KMSs if --kms is provided: https://github.com/smallstep/step-kms-plugin?tab=readme-ov-file#signing-certificates-with-step, so I think that should work in your use case.

You're correct that step ca init doesn't support all KMSs directly. However, you should be able to initialize the CA, and then alter the ca.json to make use of any KMS our libraries support.