hmac-secret extraction without stored information

[Meri3252]

There is a nice PoC for using hmac-secret with the libfido2 tools here: https://gist.github.com/joostd/ef34e52d17bbf546977ff8cfd61f38cd?permalink_comment_id=4885976
Based on that I was wondering how it could be possible to extract the hmac-secret value by providing nothing but the relying party that requests the secret.

The PoC above would require the storage of certain values, like a credential id, assertion challenge and a salt. I do not want to store any of that, I only want to retrieve a hmac-secret that was once registered on the fido2-token without providing anything but the relying party aka domain name that the target secret is associated with. Is this possible? Could I use empty assertion challenge and salt values without violating security?

My goal is to use a fido2-token to extract the secret for other applications, by providing nothing but the application name as relying party.

[LDVG]

Hi,

The RP ID, hmac-secret salt(s), and Credential ID are required to be able to retrieve a consistent secret. You can omit the Credential ID if you use discoverable credentials. The client data (challenge) should not be stored.

Hope this helps,
Ludvig

[Meri3252]

Would it be valid to use a non random value as a salt?
Like a hash made from a simple string like sha256("my hmac-secret application salt")

This is what the W3C example does here: https://github.com/w3c/webauthn/wiki/Explainer:-PRF-extension

I have not found any information about the salt being required at all, so it should be possible to either use an empty salt or one made of public information, correct? Or are there any obvious weaknesses that result from this?

[LDVG]

Hi,

Would it be valid to use a non random value as a salt?

Yes, that's one way of constructing the salt. The specification(s) do not require a random value.

I have not found any information about the salt being required at all, so it should be possible to either use an empty salt or one made of public information, correct?

The CTAP hmac-secret extension (and libfido2) expect either 32 or 64 bytes of salt. WebAuthn's PRF extension also requires at least a salt, but note that the client will pass it through a hash function before ultimately communicating it to the authenticator (see client processing steps in the previous link).

Or are there any obvious weaknesses that result from this?

I would say that the security properties are mostly bound to your application of the PRF output.

[Meri3252]

I would say that the security properties are mostly bound to your application of the PRF output.

It would be used as a key for AES-GCM which uses an additional salt on its own for encryption.

One concern is that the specification explicitly mentions the prevention of offline attacks, though I still dont know what exactly they are referring to in this context. https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html#sctn-hmac-secret-extension

[LDVG]

One concern is that the specification explicitly mentions the prevention of offline attacks, though I still dont know what exactly they are referring to in this context.

The specification is referring to that the authenticator and platform each only have a portion of the input needed to reconstruct the full secret; neither can compute the full secret without the other.