What is hmac-secret good for?

[Nicolas Stalder]

Hi,

I'm with SoloKeys, we (believe we) recently implemented the hmac-secret extension (https://github.com/solokeys/solo/pull/149), upon which I realized I don't understand what it's good for. Can anyone explain? The only hint I can find is that "this enables offline scenarios".

Thanks,

Nicolas

[Thomas Duboucher]

Hi,

It enables offline login on an AAD-joined Windows 10 device, i.e. when the attestation for login has to be verified locally because the AD is not available.

Any more details will require someone from Microsoft to explain exhaustively their authentication procedure.

Best regards,

--
Thomas Duboucher

[Arshad Noor]

But, with the proper implementation on operating system platforms, the HMAC secret extension can be used to login into the operating system with a FIDO2 Authenticator even when the computer is off-line.

There are other use-cases as well, but I haven't had time to study the extension in detail.

Arshad Noor
StrongKey

[Thomas Duboucher]

I prototyped around using hmac-secret to derive key material for
LUKS/eCryptfs, but that was a horrible idea: hmac-secret does not
require user verification, so holding the authenticator is enough to
retrieve the key material.

Which is why I'll be interested at some point to know how hmac-secret
fits in Microsoft's platform design. :)

Best regards,

> --
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fido-dev+u...@fidoalliance.org
> <mailto:fido-dev+u...@fidoalliance.org>.
> To post to this group, send email to fido...@fidoalliance.org
> <mailto:fido...@fidoalliance.org>.
> Visit this group at
> https://groups.google.com/a/fidoalliance.org/group/fido-dev/.
> To view this discussion on the web visit
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/8f0319c6-96d7-eb5d-6d3a-9df7405cd8e5%40strongkey.com
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/8f0319c6-96d7-eb5d-6d3a-9df7405cd8e5%40strongkey.com?utm_medium=email&utm_source=footer>.


--
Thomas Duboucher

[Nicolas Stalder]

Thank you all for the replies so far.

It would certainly be great to understand how Microsoft actually intends to use hmac-secret in their workflow; from your comments I understand the extension originates with them.

However. Given it's the first and currently only extension, I'd simply like to understand:

- what is the functionality that this extension adds?

- what is the motivation for adding it as non-vendor extensions.

In my understanding, of the spec:

- there is a salt (actually two...)

- the authnr has a CredRandom which only it knows?

- the client and authenticator communicate using sharedSecret for authenticated encryption, ensuring the the client-authnr communication is proper

- the client HMAC's the salt

- the RP receives it

But then what? What is the point in HMAC-ing an RP-supplied salt with a key nobody else knows?

I must be missing something :)

It would be great to have these points addressed here and even in the spec itself.

Thanks!

[Thomas Duboucher]

Hi Nicolas,

The idea is to deterministically generate crypto material (up to 512
bits) from a secret stored on a secure device and tied to an account.

Nothing more. Once you get around this, everything else is details. :)

- The DH key agreement and the encryption afterward ensures the
generated key material cannot be eavesdropped (opportunistic encryption).
- The HMAC act as a one way function, i.e. it is impossible from a salt
and a hmac-secret to compute the credRandom.

Also, this is not the only extension. It is the only extension defined
in CTAP2, because it only involves the platform and the authenticator.
Extensions are usually defined in WebAuthn because they involve the RPs.

Best regards,

> --
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fido-dev+u...@fidoalliance.org
> <mailto:fido-dev+u...@fidoalliance.org>.
> To post to this group, send email to fido...@fidoalliance.org
> <mailto:fido...@fidoalliance.org>.
> Visit this group at
> https://groups.google.com/a/fidoalliance.org/group/fido-dev/.
> To view this discussion on the web visit

> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/7bf5ec9f-8451-4f67-9408-44f2f431b43b%40fidoalliance.org
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/7bf5ec9f-8451-4f67-9408-44f2f431b43b%40fidoalliance.org?utm_medium=email&utm_source=footer>.

--
Thomas Duboucher

[Nicolas Stalder]

Ah... Enlightenment achieved. Thanks, Thomas!