Add support for custom bytes in Wax.Challenge struct

[armanm]

This PR adds support for supplying custom bytes when creating a %Wax.Challenge{} struct.

This enhancement is significant because these bytes (referred to as "cryptographic challenge" in the Passkey standard) are signed by the authenticator, with the signature returned as part of the AuthenticatorAssertionResponse.signature.

The practical value is that this signature creates a cryptographic connection between the passkey and the provided bytes, serving as strong proof of an activity. For example, in our workflow where passkey presentation is required before performing a legal action, we can use the resulting signature as irrefutable proof that a user has taken a very specific action.

[tanguilp]

Hi, and thanks for the PR!

2 questions:

• do you mean that's the hash of the document that is passed as a challenge? I think I already read about this use-case
• out of curiosity, do you need to handle timestamping? If so how do you do it?

Gonna take a look at your PR today.

[armanm]

• do you mean that's the hash of the document that is passed as a challenge? I think I already read about this use-case

That's correct. We intend to add the passkey signature as metadata to the PDF and therefore must calculate the document digest from the content section of the PDF.

• out of curiosity, do you need to handle timestamping? If so how do you do it?

Sadly our solution does not include time stamping that's equivalent to how they work in signed PDFs. Ideally we would sign PDF docs using a proper document signing certificate which gives you a green tick on the signature panel in Acrobat Reader but sadly they are expensive to buy, have to be renewed every year and have hard storage requirements. There are PDF signing services too but their cost also does not scale for us.

I'm now sharing my own opinion – my understanding of the timestamp in signed PDFs is to show it happened while the certificate was valid and helps to validate the document years after its signing certificate is expired. When signing documents with passkeys, timestamps may not matter as Passkeys never expire – they either exist in an authenticator or they don't. I could be truly wrong about what I'm sharing here 😂 please don't quote me on it.

[tanguilp]

That's correct. We intend to add the passkey signature as metadata to the PDF and therefore must calculate the document digest from the content section of the PDF.

Thing is the specification seems to explicitly prohibit that: https://www.w3.org/TR/webauthn-3/#sctn-cryptographic-challenges

We'll have to dig it further, as you can't make such changes to a security library without proper security analysis. Feel free to give me as much as input as you can (articles, libraries already supporting it...).

I could be truly wrong about what I'm sharing here 😂 please don't quote me on it.

Fair enough, it was really out of curiosity :)

[armanm]

I agree, you raised an important point about the WebAuthn specification and potential security implications. So I'll elaborate on the nuanced considerations:

The WebAuthn specification indeed emphasizes the importance of using unique, random challenges to prevent replay attacks in authentication scenarios. However, our use case presents an interesting edge case where we're looking to create a cryptographic binding between a user's passkey and a specific document.

While the standard session authentication flow should be done using random challenges, our approach aims to leverage the passkey as a form of document-specific signature. This differs from traditional authentication in that we're essentially using the passkey as a cryptographic attestation mechanism for a specific resource.

I know at least one project that does something similar. The banana-passkey-eoa project provides an interesting precedent for our approach. However, your point is well-taken that we cannot casually modify a security library without thorough analysis.

The other point to make is whether the proposed changes make it easy to make mistakes that were previous impossible. I don't believe is that is the case – there are existing opportunities for challenge reuse:

• in the window between Challenge.new/1 call in the server and passing the challenge to WebAuthn in the browser the user can mishandle things or
• manually override bytes via manipulation of a %Challenge{} struct

Thanks for referencing the other locations to update the docs. I will add them too.

EDIT

One more thought. I am not sure if Wax is currently doing anything to prevent replay attacks. I presume the challenge needs to be persisted in a more permanent basis to detect reuse 🤔

[tanguilp]

A clearer test would be:

challenge = Challenge.new(...)

assert challenge.bytes == "abcd"

[tanguilp]

Additional resources:

• https://developers.yubico.com/WebAuthn/Concepts/Using_WebAuthn_for_Signing.html
• https://security.stackexchange.com/questions/211072/is-it-possible-to-use-webauthn-for-digitally-signing-documents-in-the-browser
• WebAuthn and Web Payments -- Transaction Confirmation, 3DS2, SRC, etc. w3c/webauthn#1396

Please consider adding it to the security considerations I just updated

[tanguilp]

@armanm any update? Did you see my comments? :)