Open EvilBit opened 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.
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.
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.
Is there any news re that, any update or estimation or blocker or new insights?
Time is the main blocker.
But I have written TPM software for the past year which is knowledge that can be reused here.
Support for TPM keys: https://github.com/Foxboron/sbctl/commit/bdf2c637d54dc9cc45442cadc8015f933d7c1e9c
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.
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.
This may be helpful for adding PKCS#11 support https://github.com/smallstep/crypto/tree/master/kms
I'm not super hyped about smallstep/crypto
as it has a CLA and it would prevent me from contributing towards it.
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)
I'd rather use go-piv
directly :) Thanks for looking into this!
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.
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 :)
The whole reason why I'm pushing this is because the pkcs11 support in efitools segfaults
sbsigntools
should still work? But yes, none of C stuff is well maintained.
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.
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
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).