Use fido2 extension "hmac-secret" for encryption

[fhilgers]

Some fido2 keys (for example solokey1 and Yubikeys) support the HMAC Secret Extension.
According to the fidoalliance-spec (https://fidoalliance.org/specs/fido-v2.0-rd-20180702/fido-client-to-authenticator-protocol-v2.0-rd-20180702.html):

This extension is used by the platform to retrieve a symmetric secret from the authenticator when it needs to encrypt or decrypt data using that symmetric secret. This symmetric secret is scoped to a credential. The authenticator and the platform each only have the part of the complete secret to prevent offline attacks. This extension can be used to maintain different secrets on different machines.

One can create a credential and the Fido key returns a key handle. This key handle can be used in combination with a salt to get a shared secret (I am not 100% sure that this is exactly how it works, but something like that). This key handle in combination with the salt always creates the same secret from the Fido key.

It is of course not as secure as having the keys only on a Yubikey and letting the Yubikey perform all the decryption work (never exposing the private key to the public), but it should be more secure than just having the private keys lying around. If I am not mistaken, one could instead just store the key handle on the device (which is useless without the Fido key).

One example which already uses this mechanism is systemd-cryptenroll, which implemented this in systemd version 248 (https://lists.freedesktop.org/archives/systemd-devel/2021-March/046289.html) (fido2 for luks).
KeePass has support Yubikeys HMAC-SHA1 Challenge-Response (https://support.yubico.com/hc/en-us/articles/360013779759-Using-Your-YubiKey-with-KeePass) which is something similar (at least I think so) and is also discussing (keepassxreboot/keepassxc#3560) to implement the fido2 hmac-secret extension.

I think this could be implemented as a plugin (like the yubikey plugin), which makes it possible to create a recipient (can be just the derived public key from the shared secret) and a private key (which is just the handle in this case). I am not quite sure what to do with the salt. One could either not store it and use it as another form of security measure (key handle + hardware key + password which gets hashed and used as salt) or just store it with the identity if the security of the Fido key is enough.

If you think this is insecure please let me know. I just thought that this would be a neat way to get a bit more security without fiddling around with pkcs#11/piv or openpgp smartcards, which are quite a pain to use. Fido keys are also quite cheap and very handy for other stuff.

[olastor]

@fhilgers There's https://github.com/riastradh/age-plugin-fido , but I've also gave it a shot and created https://github.com/olastor/age-plugin-fido2-hmac/ , which uses a slightly different design and adds support for PINs.

I think this could be implemented as a plugin (like the yubikey plugin), which makes it possible to create a recipient (can be just the derived public key from the shared secret) and a private key (which is just the handle in this case). I am not quite sure what to do with the salt. One could either not store it and use it as another form of security measure (key handle + hardware key + password which gets hashed and used as salt) or just store it with the identity if the security of the Fido key is enough.

The design I chose I tried to summarize here. It doesn't use public keys (explicitly) at all and stores the credential ID inside the recipient string (or alternatively in a separate identity). I am not sure about whether your idea using asymmetric crypto would be feasible in combination with "hmac-secret". Afaik the shared hmac secret for the hmac operation doesn't leave the device. I also thought about ways to encrypt not requiring the device to be present, but came to the conclusion that with the hmac-secret extension it's not possible.

Edit: I mixed up the shared secret vs. hmac secret (in the spec: "CredRandomWithUV/CredRandomWithoutUV") in the original response. The shared secret seems to be used when the platform communicates with the authenticator.