-
-
Notifications
You must be signed in to change notification settings - Fork 181
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
Apple AppAttest Attestations can fail due to incorrect comparison of credential public key with subject public key of credCert #552
Comments
Ahhh, good find @rorydpayne. We're in the midst of landing a large PR, so a PR to fix this would be accepted after we've managed to merge #531 |
Just FYI: #531 has now been merged. |
@rorydpayne I'm open to reviewing a PR that adreses this! |
Oh goodie, the IEEE P-1363 vs ASN.1 problem again, just backwards! |
Ok, so my knee jerk reaction was to think this was IEEE P-1363 vs ASN.1 encoding issue. This is because of heartburn from previous issues with
When dealing with a structure like that, the However, in the case at hand, So what's going on here? Of the samples provided, the second one is the one with the issue, so let's tear that apart and see what we've got. First, let's take that attestation object over to CyberChef to base64 decode and turn into hex. If we take the output of that over to cbor.me and plug it into the right pane, we can get the stuff we're looking for, which is Those are:
and
Breaking down
Since
Now if we take that
So that's
Removing the colons and turning that public key into a string, we get our
The leading
The top line is the X-coordinate, the bottom line the Y-coordinate, both 32 bytes in length. If we compare the coordinates from Based on the language found in RFC9053, CBOR Object Signing and Encryption (COSE): Initial Algorithms, section 7.1.1 Double Coordinate Curves for the EC key type, definition for the x-coordinate:
It is my opinion that the generator of |
I wanted to know how we could have caught such an issue. We actually would have caught this if you attempted to use If you try to validate the
|
Great find @aseigler! |
In some instances AppAttest attestation objects fail to validate when they should succeed. The final validation in
Apple.VerifyAsync
compares the values of the attested credential data subject public key with the public key value of the credCert in the x5c and can produce a false negative in the form of aFido2VerificationException
.As far as I can tell, the problem emerges because on the one hand a
CredentialPublicKey
is constructed from aCborMap
when parsing attested credential data. On the other aCredentialPublicKey
is constructed from anX509Certificate2
. For anX509Certficate2
with anECDsa
public key, the exported parameters will always containX
andY
coordinates asbyte[]
values with a fixed length (e.g. 32 bytes for P-256 etc). When parsing the attested credential data, the same EC coordinates can end up being represented withbyte[]
values of varying length instead of being padded out to a fixed key length. Thus comparing the encoded values of eachCredentialPublicKey
instance we can produce a false negative.The issue can be reproduced in a test like this one using two AppAttest attestations as inputs.
The text was updated successfully, but these errors were encountered: