How AppAttest works ?

Question

Sheezen OP

Created Jun ’21

Replies 1

Boosts 0

Views 1k

Participants 2

Hello,

I am currently learning about how App Attest works and there are a few things I don't understand.

First of all for the certificates of the attestation provided by Apple. Once verified, they attest that the associated customer has a genuine Apple device. What is meant by a genuine Apple device, a non-jailbroken device or simply a device that was produced by Apple? In addition I do not see how these certificates work, how they attest to the authenticity of the device, what they contain?

Then regarding the appId, is it kept in the Secure Enclave? Because if not, a super-user could very well modify the application and then go and modify the appId to put back the original.

Also, can a user use the AppAttest API without going through my application, in order to produce false certificates for example.

Regarding assertion formation for requests, let's imagine that the user does not have a login. The query may possibly be stored on the device in the meantime, will the assertion have already been bound or not?

Finally, since the key pair does not survive the reinstallation of the application. Is there any way to block a device that is suspected of having fraudulent activity?

Thank you for your attention!

Boost

Answer 1

azw OP

Jun ’21

What is meant by a genuine Apple device -> that means the device has a certificate signed by a CA that chains up to Apple's App Attest Root CA. The appId is stored in your certificate and in each assertion. Super user can modify app id all he wants, he can't modify it in the certificate where Apple put it in on their (Apple's) servers. can a user use the AppAttest API without going through my application, in order to produce false certificates for example - the premise is that Apple keeps their Root CA private keys secure. If those were ever to be compromised then the answer would be yes. However, if that were to happen there would be much bigger issues all up.

Regarding assertion formation for requests, let's imagine that the user does not have a login -> if the user does not have a login, don't generate said assertion? it's pretty simple.

Is there any way to block a device that is suspected of having fraudulent activity -> that implementation detail is entirely up to your application code.

0