random-scripts/fido2-hmac
2022-12-22 15:33:23 +01:00
..
hmacfido.py merge from previous repos 2022-12-22 15:12:24 +01:00
README.md finish readme 2022-12-22 15:33:23 +01:00

Required packages

fido2

What it does

This script is a simple shell menu for working with fido2 hmac-secrets. When you run it you get 3 options.

  • list
  • create
  • sign

This script does not work with resident keys so a seperate file called keys.json will be created to store the key id's. It is mostly optimized for Windows but does not work with the Webauthn API so you need to run with administrator privileges to contact the CTAP API.

hmac-secret what is it?

This extention to standard FIDO2 (I believe it's required but am not sure) supports shared secrets for use with offline devices like password vaults or disk encryption(cryptenroll). This is because the use of symmetric encryption which always needs to use the same key.

How does it work

Shared secret: The key which is generated which then can be used by an application, this will (usually, see note) always be the same

SALT1: Random string required and stored on disk by the application, it does not have to be kept secret but it is preffered.

SALT2: Random string optional and also stored on disk. This can aid changing SALT1 so it's not always the same.

  • You create a credential on the key as usual with a user and relying party but with the extension enabled. Now you have a secret key stored on the device which cannot leave it.

  • A SALT1 is generated by the computer and stored on disk. When the application wants the shared secret it passes SALT1 to the key which in turn computes the shared secret with HMAC and the private key on the security key.

  • The shared secret computed by HMAC is passed to the computer. This means that the private part is always on the key. And if you lose it or reset it the shared secret will be lost forever. The same is for SALT1, if that is lost the shared secret cannot be recomputed.

The HMAC should always be the same if the same SALT1 is passed to the key. But the shared secret may change based on the parameters used to generate it, like when requiring or discouraging user verification. This process is secure because the communication between the key and computer is also secured by DH.

There is always the possibility for malware to snatch the shared secret because it's always known and stored in the computers memory until cleanup or a reboot.