slackhq
Improve PKCS11 documentation
PKCS11 support for nebula-cert is a welcome addition. Thank you for doing that! I humbly request that the same support be added to the nebula client.
With asymmetric crypto, the Achilles' heel is the private key. If the private key were to leak, the crypto is compromised. Because of this, storing the private key on non-volatile disk in plaintext is a bad practice. A far better solution is to generate a private key in hardware that cannot be exported. Then connectivity to the nebula mesh would only be possible if the node has access to the crypto hardware over PKCS11.
It does! Use a pkcs11 URL instead of a path to a public key. For example:
pki:
ca: /etc/nebula/cfg/ca.crt
cert: /etc/nebula/cfg/host.crt
key: pkcs11:object=nebula;token=my_nebula_key;type=private?module-path=/usr/lib/softhsm/libsofthsm2.so
Please let me know if you run into trouble! I've so far only tested with Yubikeys, SoftHSM, and a quirky Microchip "HSM".
This is excellent news! I must be blind. The only docs I saw that mentioned support for PKCS11 were all referencing nebula-cert. Thanks so much!
I've closed this thread, but if you don't mind, I do have a few quick follow up questions. Could you point me to the docs for generating a public key from a private key in hardware so that the public key can be signed by a CA?
Also, out of curiosity, what model was the Microchip HSM you'd tested?
I'm going to re-open this bc if you had to ask this, in my opinion, the docs are not good enough!
Could you point me to the docs for generating a public key from a private key in hardware so that the public key can be signed by a CA?
This will be HSM-specific unfortunately. Some HSMs actually store a public key, others make you retrieve it. Something like this will sometimes work:
pkcs11-tool --module /path/to/pkcs11/library.so \
--read-object --type pubkey \
--id <key_id> \
--output-file public_key.der
Then you need to convert that DER to a Nebula public key PEM. We don't have docs for this (another TODO!), but for P256, you want it to be, essentially, the PEM encoded form of 04XXXXXXXYYYYYYY where XXXXXXX is your X-coordinate and YYYYYYY is your Y.
It's my belief (please correct me if I'm wrong!) that most folks bothering to use PKCS11 with Nebula are doing it as part of a large enough effort to justify writing a program to deal with automating the "generate keys, extract pubkey, exchange (pubkey+some sort of authz token) with a backend to obtain a cert, bootstrap nebula" process. Because of that, the golang functions you would need are all there, but the command-line tooling is a little lacking.
Also, out of curiosity, what model was the Microchip HSM you'd tested?
I was using a Microchip TA100 (sadly all the docs for it are NDAed), but anything that uses Microchip's "cryptoauthlib" should work
It's my belief (please correct me if I'm wrong!) that most folks bothering to use PKCS11 with Nebula are doing it as part of a large enough effort to justify writing a program to deal with automating the "generate keys, extract pubkey, exchange (pubkey+some sort of authz token) with a backend to obtain a cert, bootstrap nebula" process. Because of that, the golang functions you would need are all there, but the command-line tooling is a little lacking.
You are not wrong. Having the functionality exposed in the command line tooling is preferable because it can speed up (at least to a small degree) prototyping and testing; however, it is not a hard requirement.
I appreciate you re-opening this. If there were some developer docs or something that would be a welcome change. I think you've at least got me started. Is there anything else I should know? Any pitfalls you've encountered that you can help me avoid?