Open colemickens opened 2 years ago
Good question! kbs2
uses age
for both the key itself and for key wrapping, so we'd probably need to make the wrapping code more flexible to support PKCS#11.
I'm not too sure what the status of PKCS#11 compatibility with age is; the only thing I could find is this: https://github.com/kula/age-pkcs11
OTOH, you should be able to "use" a hardware security key with kbs2
currently, assuming that it supports both password slots and exposes itself via the standard USB HID Keyboard interface. That's not as secure as keeping the entire wrapping key uniquely on the hardware device, but it's a step up.
There's also rage-yubikey but it's (based on the name) a bit vendor specific compared to generic PIV / PKCS11, plus it does its own per-"file" wrapping but maybe that's a natural fit if you're already delegating all of the wrapping/handling to age.
OTOH, you should be able to "use" a hardware security key with kbs2 currently, assuming that it supports both password slots and exposes itself via the standard USB HID Keyboard interface. That's not as secure as keeping the entire wrapping key uniquely on the hardware device, but it's a step up.
I'm trying to figure out if I'm overly paranoid, but I really like that my current setup involves no wrapping or risk of the inner key being exposed... still thinking about it. (open to feedback)
I'm interested in continuing to use a hardware security key to primarily protect my passwords and am looking at migrating formats from password-store as well as move to a Rust tool.
Do you think it's reasonable to provide a backend that uses PKCS11, either directly, or for key wrapping?