W3C home > Mailing lists > Public > public-webauthn@w3.org > May 2021

[webauthn] PROPOSAL: Add support for general (hardware backed) cryptographic signatures (#1608)

From: certainlyNotHeisenberg via GitHub <sysbot+gh@w3.org>
Date: Tue, 04 May 2021 16:20:36 +0000
To: public-webauthn@w3.org
Message-ID: <issues.opened-875624294-1620145235-sysbot+gh@w3.org>
certainlyNotHeisenberg has just created a new issue for https://github.com/w3c/webauthn:

== PROPOSAL: Add support for general (hardware backed) cryptographic signatures ==
**BACKGROUND AND CONTEXT**
See this previous issue thread: _[Can the private keys be used for other cryptographic operations?](https://github.com/w3c/webauthn/issues/1595#issuecomment-831572141)._
**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 signatures 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](https://www.w3.org/TR/WebCryptoAPI/)), 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, 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).
- General hardware backed signatures also enable more secure encryption, since a symmetric encryption key can be signed by 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 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, 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.

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, so the use cases include the vast array of applications of cryptographic signatures! 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](https://www.w3.org/TR/WebCryptoAPI/#use-cases), 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.

Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1608 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 4 May 2021 16:20:38 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:43 UTC