PROPOSAL: Add support for general (hardware backed) cryptographic signatures and key exchange

[ghost]

BACKGROUND AND CONTEXT
See this previous issue thread: Can the private keys be used for other cryptographic operations?.
tl;dr:

• WebAuthn currently supports cryptographic signatures only for authentication. The signed data are challenges randomly generated by relying parties (RPs).
• WebAuthn is unique in that the cryptography it supports can leverage secure hardware — both hardware embedded in devices through platform authenticators and external hardware keys. This is different than all other web cryptography options (e.g. WebCrypto), which provide no standardized access to hardware. Hardware provides far stronger security guarantees than cryptography done in the browser.
• There's a desire from the community for general hardware backed cryptographic signatures and key exchange, which could be used for a wide range of applications far beyond authentication (see below for examples). It's conceivable to use WebAuthn as it stands to enable some version of this (e.g. by passing a hashed document instead of a random challenge to be signed, to enable document signing), but such use is far from what the spec was intended for and complicates the security model (e.g. because the hashed document is deterministic, not random).
• Hardware backed key exchange (e.g. ECDH) can enable more secure encryption, since a symmetric encryption key can be encrypted with an asymmetric key stored in hardware.
• In terms of leveraging device hardware (e.g. the Secure Enclave in an iPhone), there's a puzzling gap between mobile and web. Mobile apps can easily leverage the hardware for general cryptography (including general signatures and key exchange) using the device OS. But web apps have no such ability. Achieving feature parity between cryptography on mobile and web would greatly simplify development of new apps and make achieving widespread adoption far easier.

PROPOSAL
Add support for general cryptographic signatures and key exchange, backed by either hardware native to the device or an external hardware key. This is a simple extension of the current WebAuthn spec, which supports hardware backed signatures but only over randomly generated challenges for purposes of authentication. The user experience can closely match both current WebAuthn implementations and mobile app cryptography flows:

• The user is prompted to pass a platform authenticator check (e.g. Face ID on an iPhone) or insert a security key (e.g. a Yubikey). The check can create a "session" during which the user doesn't have to pass additional checks (e.g. 10 minutes od not needing to do Face ID again), with the limiting case being a session of zero duration so the user has to pass a check for every cryptographic function call.
• (Behind the scenes:) The RP triggers the hardware to create an asymmetric key pair (ideally with some control over the algorithm/curve).
• (Behind the scenes:) The RP passes data to the hardware to be signed. The hardware signs the data with the private key, never exposing it to the RP, and returns the result. Or, the RP triggers key exchange (e.g. using ECDH).

So, from the user's perspective, it's as simple as e.g. passing a biometric check. Everything else is invisible. This is exactly how mobile apps leverage hardware backed cryptography today.

USE CASES
This proposal amounts to enabling more secure cryptographic signatures and key exchange, so the use cases include the vast array of applications of those cryptographic methods! For example:

• All current and future Web3 dApps, which rely on signatures for every operation
• Document signing
• Encrypted cloud data storage
• Secure peer-to-peer messaging
• Data integrity protection
• Transaction non-repudiation
• Symmetric encryption protected by asymmetric signing

And on and on...

DIFFICULTIES

• The name "WebAuthn" reflects its current, more narrow scope (authentication). It may be difficult to extend the spec to include use cases beyond authentication without changing the name.
• WebCrypto, which major browsers implemented several years ago, has a much broader scope that includes general web cryptography, as its name suggests. (Though, as noted above, it does not standardize any hardware access.) In an ideal world, we might add the WebAuthn spec to the WebCrypto spec and keep the more understandable name "WebCrypto", but it may be too challenging to bridge the gap at this point.

[akshayku]

I can understand Web3 dApps and Document signing, but I couldn't understand how all other use cases can be solved via raw signatures.

For example, can you explain "Symmetric encryption protected by asymmetric signing" use case?

[ghost]

@akshayku My mistake. I was implicitly assuming that key exchange like ECDH would be included also, since that was part of the discussion in the other issue thread I linked to. But I forgot to add that explicity here. I changed the title and text of the proposal to reflect this.

For extra clarity, what I mistyped as "symmetric encryption protected by asymmetric signing" I meant to be "symmetric encryption protected by asymmetric encryption". In this model, data is encrypted with a symmetric key, which is itself encrypted with an asymmetric key, thereby achieving the usability of symmetric and the security of asymmetric. This is already standard for mobile apps (e.g. see the iOS documentation here), since mobile OSs provide key exchange like ECDH. In this way, even though the iOS Secure Enclave and Android Secure Element only support ECC keys, which have no direct encryption functionality, it's possible to use them for asymmetric backed encryption.

So, this proposal would help achieve feature parity between mobile and web apps around cryptography, and it should enable the use cases mentioned above.

[Firstyear]

I think to keep this really focused there should be a clear distinction between if this is for:

• Data Verification - The client hashes the data, and then the hash is signed in an extension to assert that the extra data is as it was known on the client.
• Signature Creation - An extension exists that allows arbitrary data to be signed by this private key (or an associated derived key). It's worth noting due to the use of the key directly, this has implications based on which key types (ecdsa, rsa etc) are used and the ability of the RP to consume these signatures.

Both of these types have their use and have both been requested in the former thread. We have had one request for the ability to provide a verification of data from a camera (the first suggestion), and another about using the keys for signing arbitrary data for other cryptographic applications (the second).

As previously mentioned, there are also potential security risks to the second due to the use of the key in arbitrary ways.

Verification is much easier to provide as an extension, where the client (browser) can simple pre-hash the data, then the hash is signed through the extensions. My initial suggestion is that data verification be the first step since it is the simpler of the two to provide, and has the least risk with regard to the usage of the key. There is much more thought needed for the second IMO.

[ghost]

@Firstyear Are these enough different though? The hash is just some data to be signed. It's somewhat more constrained given the output format of the hash, but it's still variable data. It might actually be easier to implement general signature creation, for which a special case is signing a hash.

As for security concerns around general signatures, there are almost certainly well established best practices that mitigate them. The features I'm describing are standard for mobile apps (both iOS and Android) and have been for many years. The goal is really just to mirror the same functionality for web apps.

One simple solution would be to create multiple keys and use one for authentication and another for general signatures. I doubt this is necessary though because, as far as I know, no such scoping is required for the hardware backed keys mobile apps use.

[Firstyear]

@Firstyear Are these enough different though? The hash is just some data to be signed. It's somewhat more constrained given the output format of the hash, but it's still variable data. It might actually be easier to implement general signature creation, for which a special case is signing a hash.

There are security concerns about key-usage from webauthn for arbitrary data, so having the hash as an extension while still requiring the nonce/challenge would help make this an interface that "can not be held incorrectly".

Additionally, some applications have cryptographic requirements to what signatures they will accept, which is why signatures vs verification should be seperate.

EDIT:

To clarify: Arbitrary data signatures created by the asymmetric key are a very different case to having an extension for data verification, where the extension input (the hash of the data) would be signed by the in the current assertion process. That's why they are seperate things and the data verification today is a path of least resistance because there is very little work to add the extension that takes the hash (plus some work on the client/browser to hash the data first).

Whereas for arbitrary data signatures over data that would require a completely seperate input to the authenticator and it's verification process to access it's key material to perform the signature. Inputing arbitrary data into an extension also is likely not viable since if you were to want to sign say ... 10MB of data, then it's unlikely your authenticator has the RAM capacity to perform that operation.

[ghost]

@Firstyear Got it. I was confused about your distinction between verification and signatures, since of course the verification itself is a signature. But given your edit section, I understand what you mean. Agreed that it's lower hanging fruit to expand the current authentication flow to also accept an optional hash of data (together with a nonce for entropy). I'm all for this.

I do still think that arbitrary data signatures are a far more powerful feature however, so I hope that part of the proposal does not get lost.

(On memory considerations, yes there would of course be some constraints. The data can't be totally arbitrary. But hopefully these constraints can be made as minimal as possible.)

[equalsJeffH]

The WebAuthn WG discussed this today 5-May-2021 during our regularly-scheduled meeting. The WG's consensus is that the Web Authentication WG's charter and specification is focused on user authentication for websites and that we are respectfully declining this invitation to expand the WG's scope to include providing "support for general (hardware backed) cryptographic signatures and key exchange".

You may wish to explore taking your needs and use cases to more appropriate groups, for example the existing, relevant Hardware-backed Security Services Community Group, whose draft report "Hardware Based Secure Services features" takes a stab at WebCrypto-linked APIs.

[cybercent]

@certainlyNotHeisenberg I think you got everyone confused by adding a bunch of use cases that are not related to authentication.

The raw cryptographic signature is needed for authentication, not signing documents, that is not covered by Webauth.

@Firstyear we only need to sign using asymmetric algorithms (ECDSA p256) a small piece of data. There is no verification needed. Also nonces are always present in the data to be signed, they are required to prevent replay attacks.

@equalsJeffH the need is cryptographic signatures, web3 are websites. They don't use a database as a backend, but they are still websites.

[cybercent]

@equalsJeffH please ask anyone in the working group doubting why this is needed to go to this website https://foundation.app and try to log in.

[Firstyear]

@Firstyear we only need to sign using asymmetric algorithms (ECDSA p256) a small piece of data. There is no verification needed. Also nonces are always present in the data to be signed, they are required to prevent replay attacks.

Webauthn allows ECDSA p256R1, ECDSA p384R1, ECDSA p521R1, RSA with a combination of hash and padding schemes, EdDSA, and probably more.

You don't know what algorithms an authenticator may have (but you can select authenticators at webauthn registration based on this). I think for your use case, you may find it unviable/unworkable given the focus of webauthn for authentication over production of arbitrary key signatures, and you may be better to investigate CTAP or other interactions directly (see openssh and how they use ctap for key storage).

[cybercent]

@Firstyear we only need to sign using asymmetric algorithms (ECDSA p256) a small piece of data. There is no verification needed. Also nonces are always present in the data to be signed, they are required to prevent replay attacks.

Webauthn allows ECDSA p256R1, ECDSA p384R1, ECDSA p521R1, RSA with a combination of hash and padding schemes, EdDSA, and probably more.

You don't know what algorithms an authenticator may have (but you can select authenticators at webauthn registration based on this). I think for your use case, you may find it unviable/unworkable given the focus of webauthn for authentication over production of arbitrary key signatures, and you may be better to investigate CTAP or other interactions directly (see openssh and how they use ctap for key storage).

@Firstyear ECDSA p256 was an example, p384, p512 can also be used, others too.
Webauthn has a pubKeyCredParams option with an alg param, which allows me to filter on what algorithm I want to use.

[ghost]

@equalsJeffH Sorry to hear it, but I understand. Thanks for bringing it up in the group meeting.

I've posted a similar proposal in WebCrypto Issues (here) — maybe that's a better home. I'll consider doing the same with the hardware services group you mentioned, though it looks as though it's been dormant for five years or so.