From Establishing Your App’s Integrity:
What stops a compromised/fake app instance to pretend to run on 'not supported' device, report that to the app server and that way circumvent App Attest completely?
Is there any way for the app server to verify this 'not supported' claim received from the app instance?
Not all devices can use the App Attest service, so it’s important to have your app run a compatibility check before accessing the service. If the user’s app doesn’t pass the compatibility check, gracefully bypass the service. You check for availability by reading the isSupportedproperty:
Code Block let service = DCAppAttestService.shared if service.isSupported { // Perform key generation and attestation. } // Continue with server access.
You change the behavior of both your app, as shown above, and your server — which can no longer require assertions — when you find that the service isn’t supported.
What stops a compromised/fake app instance to pretend to run on 'not supported' device, report that to the app server and that way circumvent App Attest completely?
Is there any way for the app server to verify this 'not supported' claim received from the app instance?
As you note, a compromised app may remove the call to the App Attest service, preventing the service from being used.
The absence of the attestation when your service expects it may be used by the service as a risk signal.
The App Attest framework is supported on iOS/iPad OS 14 and later for devices that have a SEP. As adoption of iOS 14 increases the absence of the attestation will provide an increasingly strong risk signal.
It is also critical to follow the full verification procedure on your service to ensure any attestation received has not been manipulated.
The absence of the attestation when your service expects it may be used by the service as a risk signal.
The App Attest framework is supported on iOS/iPad OS 14 and later for devices that have a SEP. As adoption of iOS 14 increases the absence of the attestation will provide an increasingly strong risk signal.
It is also critical to follow the full verification procedure on your service to ensure any attestation received has not been manipulated.