Is it possible to encrypt arbitrary data using the WebAuthn keys?
Peter Saxton
Arshad Noor
never intended to be used for encryption.
Notwithstanding that, there is an HMAC extension in the CTAP2 part of
the FIDO2 protocol that may or may not be useful to you:
https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html#sctn-hmac-secret-extension
What I don't know is which Authenticators support this capability -
given that it is an extension, I don't think it is mandatory for FIDO
Certified Authenticators to support it.
Arshad Noor
StrongKey
Ackermann Yuriy
--
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.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/66693bcb-c7e1-cd78-6129-e7f888aa6f9a%40strongkey.com.
Arshad Noor
"9.1. HMAC Secret Extension (hmac-secret)
Extension identifier
hmac-secret
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."
On 3/25/20 6:32 AM, Ackermann Yuriy wrote:
> HMAC secret does not allow to set custom key, nor to export key. It is
> only use for key roll authentication.
>
> So no. No encryption, only authentication.
>
> Yuriy Ackermann
> FIDO, Identity, Standards
> skype: ackermann.yuriy
> twitter: @herrjemand <https://twitter.com/herrjemand>
> medium: @herrjemand <https://medium.com/@herrjemand>
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/66693bcb-c7e1-cd78-6129-e7f888aa6f9a%40strongkey.com.
>
> 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
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CALRyZMrycuxEbdcvbMYOEEnape9_q4%3Dpz%2Bp0MFEZgwp%2Bx8%2B8%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
Emil Lundberg
Either way, no browser is currently exposing the hmac-secret
extension to web RPs, and I don't know of any intention to start
doing so.
Arshad Noor
computer platform can leverage that extension if they wanted to.
What would be helpful for the ecosystem is for Authenticator
manufacturers to indicate whether they support the extension or not, as
well as to provide a FIDO Alliance reference implementation (in source
form) that exercises the protocol.
We can definitely use the extension - that's one reason why I agreed to
its inclusion when Microsoft proposed it - but even if it is unsupported
in browsers, it would be helpful to know which Authenticators had it
implemented and whether FIDO Alliance had a test tool to exercise the
extension.
Arshad Noor
StrongKey
On 3/25/20 9:17 AM, 'Emil Lundberg' via FIDO Dev (fido-dev) wrote:
> Either way, no browser is currently exposing the hmac-secret extension
> to web RPs, and I don't know of any intention to start doing so.
>
> Emil Lundberg
>
> <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/0ce5d638-2ec6-2343-ae16-8a628449fa4f%40yubico.com?utm_medium=email&utm_source=footer>.
Ackermann Yuriy
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/825c1b0b-fcf3-10bb-88cb-4466e869794a%40strongkey.com.
Fan DANG
在 2020年3月25日星期三 UTC+8下午4:53:08，Peter Saxton写道：
Arshad Noor
Thanks for the link and for instigating me to read the definition in detail (finally), Yuriy. I should have read this a long time ago, but better late than never.
I stand by my assertion that the output(s) returned by the Authenticator, as described by the specification, can indeed be used for encryption/decryption on the platform. In fact, I don't see any reason why even browsers cannot expose an API for business application developers (like Peter Saxton, the original poster - and StrongKey - since we are in the encryption business too, besides strong-authentication) to leverage this capability. I can see some very interesting use-cases that would allow for innovation, as well as solve some privacy compliance problems for companies (GDPR, CCPA, etc.)
In the specification:
-----------------
...
-
The authenticator generates one or two HMAC-SHA-256 values, depending upon whether it received one salt (32 bytes) or two salts (64 bytes):
-
output1:
HMAC-SHA-256(CredRandom, salt1) -
output2:
HMAC-SHA-256(CredRandom, salt2)
-
-
The authenticator returns output1 and, when there were two salts, output2 encrypted to the platform using sharedSecret as part of "extensions" parameter:
-
One salt case:
"hmac-secret": AES256-CBC(sharedSecret, IV=0, output1 (32 bytes)) -
Two salt case:
"hmac-secret": AES256-CBC(sharedSecret, IV=0, output1 (32 bytes) || output2 (32 bytes))
-
-----------------
the HMAC operation performed by the Authenticator, is a standard
mechanism for diversifying secret keys to arrive at a new opaque
blob of bytes that can then be used for whatever purpose the blob
is capable of. The HMAC'd blob of bytes are returned back to the
platform as an encrypted blob (encrypted by the shared key: sharedSecret derived in the ECDH key-exchange).
Since the platform knows the shared key (sharedSecret),
it can decrypt the blob, get output1
(and output2 if included), transform
it into whatever object it needs and use it for whatever purposes
it needs. At this point, there is no requirement that the platform
do anything specific with that blob it got back - it can do
anything it wants with it.
I am surprised however, that there is no mention that
Authenticator manufacturers should protect CredRandom (which is
generated during an authenticatorMakeCredential (when hmac-secret
is set to true). The platform cannot protect salt1 or salt2 - it
has to store these salts somewhere on the platform if it wants to
decrypt a previously encrypted object. But, if an attacker manages
to get CredRandom from the Authenticator, combined with salt1
(and/or salt2), the attacker could potentially decrypt whatever
the platform decrypted.
That said, as long as the Authenticator does not release
CredRandom as cleartext, I don't see why browsers should not
enable access to the hmac-secret outputs through a WebAuthn API.
The content is scoped to the relying party, and can be generated
only with the precise Authenticator. And, if there are business
use-cases that can be solved by making the hmac-secret visible to
relying party applications, then I don't see why this innovation
is not being enabled.
|
|
408.331.2000 |
Thomas Duboucher
The credRandom are considered Authenticator Security Parameters (ASPs)
and as such MUST be protected (see FIDO Authenticator Security
Requirements, §2.1.1 - §2.1.3).
Best regards,
Le 28/03/2020 à 11:24, Arshad Noor a écrit :
> Thanks for the link and for instigating me to read the definition in
> detail (finally), Yuriy. I should have read this a long time ago, but
> better late than never.
>
> I stand by my assertion that the output(s) returned by the
> Authenticator, as described by the specification, can indeed be used for
> encryption/decryption on the platform. In fact, I don't see any reason
> why even browsers cannot expose an API for business application
> developers (like Peter Saxton, the original poster - and StrongKey -
> since we are in the encryption business too, besides
> strong-authentication) to leverage this capability. I can see some very
> interesting use-cases that would allow for innovation, as well as solve
> some privacy compliance problems for companies (GDPR, CCPA, etc.)
>
> In the specification:
>
> -----------------
> ...
>
> The authenticator generates one or two HMAC-SHA-256 values,
> depending upon whether it received one salt (32 bytes) or two salts
> (64 bytes):
>
> o
>
>
> o
>
> output2: |HMAC-SHA-256(CredRandom, salt2)|
>
> *
> The authenticator returns output1 and, when there were two salts,
> output2 encrypted to the platform using sharedSecret
>
> One salt case: |"hmac-secret": AES256-CBC(sharedSecret, IV=0,
> output1 (32 bytes))|
>
Thomas Duboucher
John Bradley
--
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.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/66693bcb-c7e1-cd78-6129-e7f888aa6f9a%40strongkey.com.
