Webauthn signatures

[divarvel]

Webauthn is a specification describing an API allowing the use of public-key-based credentials by web applications. It is compatible with FIDO U2F. The keypair themselves can be stored on a physical device (yubi key), or in a secure way by the platform itself (eg on android it can be used in conjunction with biometric checks).

In the case of biscuit, webauthn could be used for block signatures, either for the authority block signature, or as an external signature for third-party blocks. One possible use-case would be to add a check on a token, which mandates a block signed by a specific webauthn key. Such a token would be effectively inert as long as a dedicated block is not added, with a signature from a webauthn keypair.

The goal of this issue is to propose a way to allow webauthn signatures in the biscuit specification. Some decisions need to be made wrt cryptographic primitives, so this warrants careful scrutiny by professionals.

Algorithm selection in biscuit

The biscuit spec has mechanisms in place to allow using different signature algorithms, even though only ed25519 is currently supported. Experience from JWT has been taken into account:

• the signatures themselves don't carry any algorithm information;
• the public key used to verify the signature is the one that carries information about the algorithm.

The goal is to prevent confusion, by not allowing the token to provide information about how to verify it. Only the public key does. In practice, the public key is either provided by the verification party, or by the token itself (where it is signed by the previous block key and thus cannot be tampered with). For third-party blocks, the public key is part of the block, and is also signed by the previous block key). Third-party block keys can be referenced from datalog, where the algorithm part is also mandatory.

This mechanism will let us reference webauthn keypairs with no risk of confusion with other algorithms. It will still be important to refer to such keys as webauthn keys, and not just referencing the underlying algorithm used by webauthn. The underlying algorithm used by webauthn still needs to be part of either the algorithm identifier itself or the public key itself.

This is only a preliminary exploration, not the actual plan and it might contain glaring issues

Proposed signature and verification flows

Credentials creation

This is outside of the scope of biscuit, the normal creation flow can be followed: https://www.w3.org/TR/webauthn-2/#sctn-api

Signature

The biscuit JS API acts as the relying party client part. This is where things differ from the usual webauthn flow, as the server won't directly provide a challenge. Instead, the challenge will be derived from the block that needs to be signed. In the existing biscuit signature algorithm, the signature input is: data_n + alg_n+1 + pubkey_n+1 ( alg_n+1, pubkey_n+1 is the public key of a randomly chosen keypair allowing to sign the next block).

In webauthn, this could be used as the challenge: https://www.w3.org/TR/webauthn-2/#sctn-cryptographic-challenges used when asking an authenticator for an assertion.

The webauthn spec requires that the challenge is at least 16 bytes long, and impossible to guess. Here the question is whether data_n + alg_n+1 + pubkey_n+1 can be used as the challenge. It is at least 32 bytes long, and pubkey_n+1 is random (but holding the token or any derived token gives access to this value, so it's not a private value either).

The assertion object returned by the authenticator can then be used as a block signature, along with the public key from authenticatorData.

Verification

The signed block signature can be verified with the public key.

Open questions

• webauthn supports several signature schemes, and uses COSE for algorithm selection. do we want to support this in biscuit, or do we hardcode webauthn support to a single algorithm?
• can data_n + alg_n+1 + pubkey_n+1 be used directly as the challenge data?
• can the token store directly the public key and signature parts of assertionData, or does it need to store the whole structure?