search

Foxboron / sbctl

:computer: :lock: :key: Secure Boot key manager
MIT License
1.45k stars 80 forks source link

Support for hardware tokens / HSMs (OpenPGP, PKCS#11, etc.) #84

Open EvilBit opened 3 years ago

EvilBit commented 3 years ago

A configurable key storage backend (plain files, OpenPGP smartcard, PKCS#11 token/HSM, etc.) would greatly benefit the underlying security model of sbctl and would enable integration into larger PKI infrastructures.

Relying on open standards would enable advanced scenarios, like signing with a remote HSM conditional on prior remote attestation of current system state using a local TPM (i.e. DRTM-based TCB attestation).

Foxboron commented 3 years ago

This is on my todo. Before a 1.0 release I want native TPM support and go-piv support for yubikey at a minimum. But not sure about PKCS#11 and other engines yet.

I do have a TPM backed signing tool for go-uefi written to test how this would work with sbctl. https://github.com/Foxboron/go-uefi/blob/morten/tpm/cmd/gotpm/main.go

My only usage so far is to store the private key material, but if there are other ideas we can play around with please do share.

EvilBit commented 3 years ago

This is on my todo.

Nice :) Any specifics on how one can support you with that?

Before a 1.0 release I want native TPM support and go-piv support for yubikey at a minimum. But not sure about PKCS#11 and other engines yet.

From my understanding of the competing crypto standards, PKCS#11 seems to be the most widely supported one - from tokens and smartcards for personal use, to professional HSMs. You can even use a TPM via PKCS#11, or (remote) software-based HSM implementations like SoftHSM or NetHSM. AFAIK the YubiKey PIV is also accessed via PKCS#11.

Foxboron commented 3 years ago

Any specifics on how one can support you with that?

Well, join me and hack on crazy go-uefi stuff and figure out the abstractions. Test sbctl git master brache. Find issues. If I ask for feedback please engage!

All of this is me hacking a bit when I feel like it and get inspiration between all my other FOSS duties. So things are going to grow slowly :) But my goal is to have a 1.0 out in a month of two.

From my understanding of the competing crypto standards, PKCS#11 seems to be the most widely supported one - from tokens and smartcards for personal use, to professional HSMs. You can even use a TPM via PKCS#11, or (remote) software-based HSM implementations like SoftHSM or NetHSM. AFAIK the YubiKey PIV is also accessed via PKCS#11.

Yes, but I'd prefer native support where possible. PKCS11 is fine for a general "if no other options exist", but I'd strive for native options when possible.

mirko commented 4 months ago

Is there any news re that, any update or estimation or blocker or new insights?

Foxboron commented 4 months ago

Time is the main blocker.

But I have written TPM software for the past year which is knowledge that can be reused here.

Foxboron commented 1 month ago

Support for TPM keys: https://github.com/Foxboron/sbctl/commit/bdf2c637d54dc9cc45442cadc8015f933d7c1e9c

mirko commented 1 month ago

Support for TPM keys: bdf2c63

That's great news, thanks a lot for your effort on this! Any chance of also having more generic support for e.g. pkcs#11 tokens? Given almost all common hardware tokens can be addressed via pkcs#11 one way or another, the (design-)limits TPM comes with and external hardware tokens can be removed / only entered when needed, I think it would be a major step forward.

Foxboron commented 1 month ago

Any chance of also having more generic support for e.g. pkcs#11 tokens?

Yes, whenever I feel like working on it and/or learning PKCS#11.

scj643 commented 1 month ago

This may be helpful for adding PKCS#11 support https://github.com/smallstep/crypto/tree/master/kms

Foxboron commented 1 month ago

I'm not super hyped about smallstep/crypto as it has a CLA and it would prevent me from contributing towards it.

scj643 commented 1 month ago

We could also use https://github.com/ThalesGroup/crypto11 and https://github.com/go-piv/piv-go/tree/v2 (we can only use go-piv once v2 is actually published)

Foxboron commented 1 month ago

I'd rather use go-piv directly :) Thanks for looking into this!

scj643 commented 1 month ago

I'd rather use go-piv directly :) Thanks for looking into this!

There is an issue with go-piv and the fact that it won't work with new yubikeys with firmware 5.7 until v2 is released. Crypto11 also has an issue of not having a release since 2021.

Foxboron commented 1 month ago

There is an issue with go-piv and the fact that it won't work with new yubikeys with firmware 5.7 until v2 is released.

This is a solveable problem.

Crypto11 also has an issue of not having a release since 2021.

This probably isn't a solveable problem :)

scj643 commented 1 month ago

The whole reason why I'm pushing this is because the pkcs11 support in efitools segfaults

Foxboron commented 1 month ago

sbsigntools should still work? But yes, none of C stuff is well maintained.

scj643 commented 1 month ago

I am working on PKCS11 support right now. I can use Crypto11 and have it get the keys based on the cert data when they were generated by sbctl or externally.

scj643 commented 1 month ago

sbsigntools should still work? But yes, none of C stuff is well maintained.

Also no it won't because all the tools target OpenSSL 1 and not OpenSSL 3