Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for "apple" attestation format #184

Closed
kennep opened this issue Aug 19, 2020 · 13 comments
Closed

Support for "apple" attestation format #184

kennep opened this issue Aug 19, 2020 · 13 comments

Comments

@kennep
Copy link
Contributor

kennep commented Aug 19, 2020

I notice that iOS 14 beta and beta versions of macOS use the "apple" attestation format, which does not seem to be documented anywhere.

There are some speculation on how this format would look like here:
https://github.com/sbweeden/fido2viewer/blob/master/fidotools.js#L2349
... which links to
https://developer.apple.com/documentation/devicecheck/validating_apps_that_connect_to_your_server
.. which mentions this page with root certificates
https://www.apple.com/certificateauthority/private/
... one of which is https://www.apple.com/certificateauthority/Apple_WebAuthn_Root_CA.pem

Is provisional support for the "apple" attestation format something you would be interested in having in the library, and would you welcome a PR on it? Or would you rather wait until it is officially documented?

@aseigler
Copy link
Collaborator

I was planning on adding it, but I was waiting for documentation which I thought was going to arrive a month ago. At a glance, it looks really, really simple, like easier than either of the Android formats.

@mackie1001
Copy link
Contributor

I'm wondering if it'd be over engineering to make attestation formats pluggable? If other formats do appear in future it'd be possible to package them up as separate nuget packages and easily add them to existing applications without waiting for a core library release. Format implementations could then also benefit from from dependency injection too and do smart stuff like fetch remote certificates, use caching services etc. It would also allow people to provide their own "null" implementation to unblock themselves temporarily.

I'm keen to have support ready to go for when iOS 14 is released so happy to help out.

@abergs
Copy link
Collaborator

abergs commented Aug 27, 2020

@mackie1001 I think that's a good idea.

@mackie1001
Copy link
Contributor

@abergs I've got a long rainy weekend coming up so I'll look to have a PR raised within the next few days.

I'll keep an eye on the Apple documentation and this issue: w3c/webauthn#1453 for any movement regarding how to actually implement the verification too. If it is anything like DeviceCheck/AppAttest then it looks simple like @aseigler says.

@aseigler
Copy link
Collaborator

I'm wondering if it'd be over engineering to make attestation formats pluggable? If other formats do appear in future it'd be possible to package them up as separate nuget packages and easily add them to existing applications without waiting for a core library release. Format implementations could then also benefit from from dependency injection too and do smart stuff like fetch remote certificates, use caching services etc. It would also allow people to provide their own "null" implementation to unblock themselves temporarily.

I'm keen to have support ready to go for when iOS 14 is released so happy to help out.

I've been working on a refactor of the attestation verification code to make it much more closely match the WebAuthn spec, which should make this effort considerably simpler as well.

@mackie1001
Copy link
Contributor

@aseigler what is the scope of those refactorings? Are they internal to each AttestationFormat or are you making structural changes? If the latter it may be worth me branching from that refactoring branch.

@aseigler
Copy link
Collaborator

It's definitely structural, making each format verifier return an attestation type and trust path, and then handling chain validation against metadata/policy one way instead of separately per format. Hopefully that makes sense...I will get the refactor branch up soon.

@aseigler
Copy link
Collaborator

@mackie1001 check https://github.com/abergs/fido2-net-lib/compare/AttestationInterface

@yackermann
Copy link
Contributor

You guys are some Sherlocks *)

@abergs
Copy link
Collaborator

abergs commented Sep 18, 2020

You guys are some Sherlocks *)

@kennep @mackie1001 and @aseigler really are Sherlocks. I mean, the TPM pr they got running hurts my head...

@aseigler
Copy link
Collaborator

aseigler commented Oct 7, 2020

Format came out last night: https://pr-preview.s3.amazonaws.com/alanwaketan/webauthn/pull/1491.html#sctn-apple-anonymous-attestation

Initial implementation here: 0d6410c

Borrowed initial test data from webauthn4j/webauthn4j@9a7260b#diff-b16de03d04ad98253ba2011fc88e755f

@yackermann
Copy link
Contributor

@aseigler
Copy link
Collaborator

This is in for V2.0

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants