Building a WebAuthn protocol response for a credentials creation request, relying on standards such as the Web Cryptography API, CBOR, JSON Web Key among others.

On the second post of this series we will construct a valid WebAuthn protocol response for a credentials creation request, relying on standards such as the Web Cryptography API, Concise Binary Object Representation, JSON Web Key among others.

On the previous post we set out to build a Chrome Extension that emulates a Hardware Authentication Device (HAD) and created the foundation for the whole project.

Today we will breakdown the different parts of the protocol and the role they play. We will work on each one of them separately so we grasp their purpose and guarantees and finalize with the proper response.

Disclaimer

I cannot emphasize enough that this project by no means replaces a Hardware Authentication Device. The use of this extension is aimed exclusively at development, testing and debugging. If you use it in a production environment, do so at your own risk. We will elaborate on the guarantees (and lack of) that this project provides on the last post of the series.

Building the Attestation Object

Webauthn is a challenge-response protocol which can take advantage of asymmetric key pairs to replace password-based authentication.

What does that actually entail? How does the protocol solve the problem of proving that you are who you say you are?

There are two major parts to the challenge portion of the protocol:

• The challenge: self explanatory at first, but it is crucial to understand that this challenge is generated by the web application, i.e. the Relying Party. This gives confidence to the server that our response is actually aimed at them and not some other web application. This protects us against some attack vectors such as Replay Attacks.
• The Relying Party ID: This is provided by the server too and enforced by the browser. This provides some guarantees to the client that it is authenticating against the right web application and not some malicious intermediary, i.e. Man-in-the-middle attacks.

Now that we know the basics of the challenge, it is our objective to produce a valid response, named "Attestation Object".

The attestation object is divided in three sections:

• Authenticator Data: This holds all the information that we, the authenticator, want to share with the relying party.
• Format: Will always be "packed".
• Attestation Statement: Signature over the challenge (plus a few other bits), and the certificate of the HAD if applicable.

Attestation Statement