Can the private keys be used for other cryptographic operations?

For example, can they be used to sign and encrypt data the client passes?

This goes beyond authentication, so it may be fair to consider it out of scope, given that "authn" is in the spec name! But I think being able to use the private keys more generally would open up very compelling functionality. For example, a web app could act like a mobile app in the sense that it could leverage device biometrics and secure mobile hardware to create, store, and use private keys.

This would be a major advance, since currently many uses of public key crypto that are theoretically compelling are practically infeasible because they require businesses to make users install mobile apps. Web apps are so much more usable because they don't need to be installed.

I looked all over the place to try to sort this out and didn't find anything, but maybe I'm just missing it. I thought maybe the WebAuthn extensions could fit this scenario? But I'm really not sure. There are many subtleties, like some key types not being suitable for encryption, etc.

[MasterKale]

Correct me if I'm wrong, but isn't this a usecase for the largeBlob extension?

https://w3c.github.io/webauthn/#sctn-large-blob-extension

...allows a Relying Party to store opaque data associated with a credential...

I thought that might be true, but when I read the details of largeBlob it seems tailored to adding a (relatively small) amount of data at registration to be stored in the authenticator. The use case in mind seems to be certificates.

What I'm hoping for is the ability to use the private keys for more (ideally all possible) cryptographic operations that key can be used for. Mobile apps can do this through the OS, e.g. an iOS app can trigger a Face ID check and then pass a bunch of data to the Secure Enclave to be signed, encrypt that data (with another key tied to the Secure Enclave, though not stored there because of technical subtleties), and receive the result back. It can also receive data encrypted with the public key and use the private key decryupt it. That sort of thing.

It's always seemed odd to me that web apps can't do this also, but it's because they don't expose access to key pair generation and usage the way mobile OSs do for mobile apps. WebAuthn seems like a partial step in this direction but maybe not a full step, unless there actually is a way to use the keys more generally.

[ve7jtb]

You can indirectly sign things bypassing something in as part of the challenge.

Given the primary use of the key is for authentication allowing the same key to be used to sign arbitrary data would allow a possible man-in-the-middle attacks if not carefully thought through.

We tried to add a KDF extension to WebAuthn in level 2 but there were questions about if that fell inside the working group's charter as that only mentioned authentication.

That may come back after our new charter as part of level 3.

We did add however add credBlob so a RP could store a 32byte value with a discoverable credential. That could be used to derive a key for signing or encrypting in the browser or RP.

Thanks @ve7jtb. Agreed that this does seem a bit fraught, would need to be done carefully as it's not the intended use case.

It seems that WebAuthn, WebCrypto, and similar specs are circling around the bigger topic of opening up cryptography using secure device hardware to web apps. I'm not sure why this has been commonplace for mobile apps for years but still isn't an option for web apps. It may not be possible to expand the scope of WebAuthn to include this, given how tightly coupled it is to the authentication use case, but I'm encouraged that level 3 might reintroduce broader usage of keys.

To me at least, it seems like a very natural and useful generalization. Perhaps another spec that encapsulates WebAuthn as one part.

[Firstyear]

Given that there is a desire for this functionality, and that it can be risky if done incorrectly, it would be better for us to describe a process to do it correctly and securely, rather than relying on people to "have a guess" at it and misusing the assertion process.

@Firstyear 100% agree. I would much rather follow a community vetted process than try to shoehorn WebAuthn into a solution it wasn't designed for. I do think it may be difficult, though, to expand the spec given how tightly coupled WebAuthn is to authentication, even in name.

How can we amplify this proposal for wider consideration?

From a security perspective, there are very compelling reasons to open up secure device hardware to web apps. For anyone who's interested, I'd suggest checking out this Pomcor blog post and presentation. As they say, "Use of cryptography in web apps has been hindered by the problem of where to store cryptographic keys." Without access to secure device hardware (that's more general than the auth-only approach of WebAuthn), the only options are fundamentally insecure. How tragic! Imagine how much more powerful the web would be if hardware backed cryptography were available to web apps, especially with the rise of web 3 decentralized systems.

Anyway, now I'm just advocating ;) but would love fellow advocates to help push the cause forward!

[equalsJeffH]

From a security perspective, there are very compelling reasons to open up secure device hardware to web apps. ... "Use of cryptography in web apps has been hindered by the problem of where to store cryptographic keys."

Yes, this is a long-recognized but apparently really-tough-to-address problem. The more general Web Crypto API is likely what you want for your use cases, rather than WebAuthn, although layering WebCrypto on top of hardware-based crypto+storage facilities is presently not standardized.

FYI/FWIW, there is an existing, relevant, tho apparently dormant, Hardware-backed Security Services Community Group, whose unfinished draft report takes a stab at a WebCrypto-linked Secure Credential Storage API.

update 21-Apr-2021: see also #1595 (comment) below regarding the proposed PRF webauthn extension.

[rlin1]

Allowing a PublicKeyCredential private key to sign arbitrary data structures has an impact on the security model.
It makes keys "unrestricted", see https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-metadata-statement-v2.0-id-20180227.html#dictionary-metadatastatement-members

[Firstyear]

@rlin1 That's fine, but I think that the standard needs to not only express what it can do, but also advise on what it can not and make constructive links to things like the webcrypto api or others that are able to solve this problem. IE in the section about assertion it should clearly state that the nonce should not be used to sign arbitrary data, should reference the links you provide, and give reasons.

[nuno0529]

From FIDO Security Requirement spec, at least it does not limit the private keys' usage for FIDO message only on L1/L2 levels authenticator, link.
But by the metadata spec link from @rlin1, it's FIDO server's call to support this kind of authenticator or not.

FYI/FWIW, there is an existing, relevant, tho apparently dormant, Hardware-backed Security Services Community Group, whose unfinished draft report takes a stab at a WebCrypto-linked Secure Credential Storage API.

@equalsJeffH Yes, thanks for highlighting this here. I also stumbled across this dormant group and spec draft. This spec and another one I found have just an author or two — unfortunately seems that they never went anywhere.

@rlin1 Interesting about the isKeyRestricted property. The fact that this is an option maybe suggests the spec authors wanted to leave open use cases beyond authentication? @Firstyear Perhaps using one restricted key for authentication only and another unrestricted key for other cryptographic operations would address part of your concern. Unfortunately, WebCrypto isn't really a comparable solution. It does enable more general cryptography but not tied to the device hardware, which makes it vulnerable to malware, physical takeover, etc.

@nuno0529 Are you saying that because the metadata can be arbitrary, signing data for purposes other than simple authentication is allowed by the spec?

[serianox]

@certainlyNotHeisenberg Allowing a cryptographic key for several use/algorithms is a _bad idea_™ and has led to various _catastrophic failures_™ through unexpected protocol/algorithms interactions. As an example, this is why in both PGP and X.509 certification, signature, and authentication are three separate usages for keys.

In addition to all the specifications previously mentioned, there's also Web API For Accessing Secure Element that was intended for your use case, but ultimately wasn't kept by w3c due to the lack of interest at the time.

@serianox Yes, I totally agree and know what you're getting at. But I didn't mean that a single key would be used for multiple functions. Each key could be used for only a single function, and the algorithm could be chosen specifically for that function.

So, for example, one key could be used for authentication á la WebAuthn, and a separate one could be used for signing data. Maybe these two keys could be directly connected somehow, but they'd be at least indirectly connected by virtue of being stored in the secure hardware of the same device, only accessible to a user passing through the platform authenticator of that device (e.g. Face ID on an iPhone).

The goal I have in mind is enabling the same sort of hardware backed crypto for web apps that mobile apps already have. And that seems very doable if web apps have similar access through the browser that mobile apps have through the OS. It just hasn't been done yet.

Thanks for linking to this — I hadn't come across this one. Too bad that it went dormant!

[agl]

From the call of 2021-04-21:

The PRF extension, if approved and implemented, would allow a secret key to result from a WebAuthn operation. That key could be used with WebCrypto to encrypt/authenticate external data at will. The WG is interested if there are any similar use cases that would not be satisfied by the PRF extension.