Understanding how attestation response signature is constructed

[Akshay R]

Hi all,

I would like to understand how the attestation response signature is constructed and how to derive r and s values from the signature.

What data is actually being signed to produce the signature? Is it just the base64 encoded string value of the challenge or is there additional data being signed?

Any help would be much appreciated.

Thanks.

[Arshad Noor]

Akshay,

Within the open-source FIDO Server distribution is a tool we built to
simulate large-scale testing of FIDO transactions. You can find all the
code you need (in Java) to perform FIDO operations and even simulate all
kinds of failure conditions. The simulator code will show you how to
build out attestations:

https://sourceforge.net/projects/strongkeyfido/

Arshad Noor
StrongKey

On 6/11/24 11:46 PM, Akshay R wrote:
> Hi all,
>
> I would like to understand how the attestation response signature is

> constructed and how to derive *r* and *s* values from the signature.

>
> What data is actually being signed to produce the signature? Is it just
> the base64 encoded string value of the challenge or is there additional
> data being signed?
>
> Any help would be much appreciated.
> Thanks.
>

> --
> You received this message because you are subscribed to the Google
> Groups "FIDO Dev (fido-dev)" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to fido-dev+u...@fidoalliance.org
> <mailto:fido-dev+u...@fidoalliance.org>.
> To view this discussion on the web visit
> https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/24b5a468-d87d-4ecb-8541-623feb4a6275n%40fidoalliance.org <https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/24b5a468-d87d-4ecb-8541-623feb4a6275n%40fidoalliance.org?utm_medium=email&utm_source=footer>.

[Adam Langley]

On Wednesday, June 12, 2024 at 7:49:03 AM UTC-7 Akshay R wrote:

Hi all,

I would like to understand how the attestation response signature is constructed and how to derive r and s values from the signature.

If you're passing pubKeyCredParams that specify COSE algorithm -7 (the most common) then you'll get an ASN.1 DER ECDSA signature. This ASN.1 structure is defined here:

https://datatracker.ietf.org/doc/html/rfc5480#:~:text=s%20%20INTEGER%0A%20%20%20%7D%0A%0A%20%20%20%2D%2D%20ECDSA-,ECDSA%2DSig%2DValue%20%3A%3A%3D,-SEQUENCE%20%7B%0A%20%20%20%20%20r%20%20INTEGER

Note that the r and s values are variable-length encoded: you can't just extract 32-byte values from DER. (But most libraries accept ASN.1-encoded ECDSA signatures as it's the most common format.)

 

What data is actually being signed to produce the signature? Is it just the base64 encoded string value of the challenge or is there additional data being signed?

No, it's the authenticator data followed by the SHA-256 of the client data JSON. See the diagram here: https://www.w3.org/TR/webauthn-2/#sctn-authenticator-data:~:text=Let%20signature%20be%20the%20assertion%20signature%20of%20the%20concatenation 

Cheers

AGL