WebAuthn/FIDO2: Verifying U2F Attestation

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

1537

Abstract

ess taken from CTAP2 specification:</p><figure id="5be5"><img src="https://cdn-images-1.readmedium.com/v2/resize:fit:800/1*fGTOLx4qqmkR1UN06bk3Tw.png"><figcaption>Source: <a href="https://fidoalliance.org/specs/fido-v2.0-id-20180227/img/u2fcompat-makecredential.svg">https://fidoalliance.org/specs/fido-v2.0-id-20180227/img/u2fcompat-makecredential.svg</a></figcaption></figure><p id="3fb8">So in order to verify signature we need to reconstruct the original signatureBase buffer. To do that we need:</p><ul><li>application parameter — rpIdHash</li><li>challenge parameter — clientDataHash</li><li>keyHandle — credId</li><li>publicKey — a 65 byte ANSI encoded P256 public key</li></ul><p id="3011">To get rpIdHash, credId and publicKey we need to parse authData as we’ve talked about it in my “Verifying FIDO2 responses” blog. The only problem we have is that in FIDO2 we are working with COSE public keys, where in U2F they are ANSI encode. So to re-encode key, we need to extract x and y coefficients from COSE key and merge them together, prepending 0x04.</p> <figure id="940e"> <div> <div>

            <iframe class="gist-iframe" src="/gist/herrjemand/35d68e4f641fd3f79b44afe5223d1ea2.js" allowfullscreen="" frameborder="0" height="undefined" width="undefined">
          </div>
        </div>
    </figure></iframe></div></div></figure><p id="42e6">With that resolved, we can merge ReserveByte, RPIDHash, ClientDataHash, CredId and PublicKey into signature base. The

Options

n we can PEM encode certificate in x5c array, or extract the public key, and use it to verify the signature:</p> <figure id="66d0"> <div> <div>

            <iframe class="gist-iframe" src="/gist/herrjemand/8b093c82e9a09b4c4d36541cd72dc832.js" allowfullscreen="" frameborder="0" height="undefined" width="undefined">
          </div>
        </div>
    </figure></iframe></div></div></figure><p id="2caa">If you are planing to support metadata service, then you can find attestationCertificateKeyIdentifier by calculating the SHA1 of the subjectKey structure as described in method 1 of the section 4.2.1.2 of the <a href="https://tools.ietf.org/html/rfc5280#section-4.2.1.2">RFC5280</a>.</p><p id="afe4">If you like this post, you should read my horror story on <a href="https://readmedium.com/verifying-fido-tpm2-0-attestation-fc7243847498">verifying TPM2.0 attestation.</a></p><h1 id="19fb">License</h1><p id="dbc8">This article is licensed under <a href="https://creativecommons.org/licenses/by-nc-nd/4.0/">Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0)</a>. So you are free to read, share, etc. If you are interested in commercial use of this article, or wish to translate it to a different language, please contact ackermann(dot)yuriy(at)gmail(dot)com.</p><p id="1a5a">The code samples are licensed under <a href="https://gist.github.com/herrjemand/09492b2c6fc6c4ebc0d49b5942d4ec30">MIT license</a>.</p></article></body>

WebAuthn/FIDO2: Verifying U2F Attestation

Please note that this is an advance post, and requires prior understanding of the FIDO2 attestations. You can read more about them here.

Some of those who have done work with U2F before are confused by FIDO2 U2F attestations. Previously U2F attestations were raw buffer, and now it is fancy CBOR structs. How does one verify these attestations, you might ask?

Before we start, we need to look at original U2F attestations:

And now lets look at what you get from WebAuthn:

This is happening, because in FIDO2 we introduced CTAP1(U2F) to CTAP2 mapping. Here is a diagram of the process taken from CTAP2 specification:

So in order to verify signature we need to reconstruct the original signatureBase buffer. To do that we need:

application parameter — rpIdHash

challenge parameter — clientDataHash

keyHandle — credId

publicKey — a 65 byte ANSI encoded P256 public key

To get rpIdHash, credId and publicKey we need to parse authData as we’ve talked about it in my “Verifying FIDO2 responses” blog. The only problem we have is that in FIDO2 we are working with COSE public keys, where in U2F they are ANSI encode. So to re-encode key, we need to extract x and y coefficients from COSE key and merge them together, prepending 0x04.

With that resolved, we can merge ReserveByte, RPIDHash, ClientDataHash, CredId and PublicKey into signature base. Then we can PEM encode certificate in x5c array, or extract the public key, and use it to verify the signature:

If you are planing to support metadata service, then you can find attestationCertificateKeyIdentifier by calculating the SHA1 of the subjectKey structure as described in method 1 of the section 4.2.1.2 of the RFC5280.

If you like this post, you should read my horror story on verifying TPM2.0 attestation.

License

This article is licensed under Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International (CC BY-NC-ND 4.0). So you are free to read, share, etc. If you are interested in commercial use of this article, or wish to translate it to a different language, please contact ackermann(dot)yuriy(at)gmail(dot)com.

The code samples are licensed under MIT license.