Issue with DCAppAttestService for offloaded app

Hi,

When calling generateAssertion on DCAppAttestService.shared, it gives invalidKey error when there was an update for an offloaded app.

The offloading and reinstall always works fine if it is the same version on app store that was offloaded from device, but if there is an update and the app tries to reuse the keyID from previous installation for generateAssertion, attestation service rejects the key with error code 3 (invalid key) for a significant portion of our user. In our internal testing it failed for more than a third of the update attempts.

STEPS TO REPRODUCE:

  1. install v1 from app store
  2. generate key using DCAppAttestService.shared.generateKey
  3. Attest this key using DCAppAttestService.shared.attestKey
  4. Send the attestation objection to our server and verify with apple servers
  5. Generate assertions for network calls to backend using DCAppAttestService.shared.generateAssertion with keyID from step 2
  6. Device offloads the app (manually triggered by user, or automatically by iOS)
  7. A new version v2 is published to App Store
  8. Use tries to open the app
  9. Latest version is download from the App Store
  10. App tries to use the keyID from step 2 to generate assertions
  11. DCAppAttestService throws invalidKey error (Error Domain=com.apple.devicecheck.error Code=3)

Step 7 is critical here, if there is no new version of the app, the reinstalled v1 can reuse the key from step 2 without any issues

Is this behaviour expected? Is there any way we can make sure the key is preserved between offloaded app updates?

Thanks

Answered by Engineer in 823783022

The issue with the keys not working when an app is offloaded/reloaded and when an app is restored from backup (or migrated to a new device) is known. It has to do with the backed up key information no longer matching the on device information after a restore.

The AppAttest team is aware of this, and is working on a solution in an upcoming iOS release.

In the meantime, the workaround is to follow the standard guidance when encountering key errors, and to generate a new key and attest it.


Argun Tekant /  DTS Engineer / Core Technologies

Interesting.

Do you try to generate a new key after getting the "invalid key" error? What happens?

I tried to use AppAttest for a long time but it always failed in some impossible-to-debug way for a small minority of users, and eventually I gave up on it. I'm not sure if I ever considered this scenario. One problematic situation that I did worry about was when a user replaced their device and set up the new device from a backup of the previous one; it would get the key ID from the old device and fail.

Accepted Answer

The issue with the keys not working when an app is offloaded/reloaded and when an app is restored from backup (or migrated to a new device) is known. It has to do with the backed up key information no longer matching the on device information after a restore.

The AppAttest team is aware of this, and is working on a solution in an upcoming iOS release.

In the meantime, the workaround is to follow the standard guidance when encountering key errors, and to generate a new key and attest it.


Argun Tekant /  DTS Engineer / Core Technologies

we bind the user to the attestation key

Don't do that :-(

Issue with DCAppAttestService for offloaded app
 
 
Q