App attest api returns "DCErrorInvalidKey 3" invalidKey error for some of the users

Hi, App Attestation API "attestKey(:clientDataHash:completionHandler" returns "DCErrorInvalidKey 3" for some of the users. We have checked for first reason regarding if generated key is already been attested, we are generating new key and challenge every time. Could you please provide more details regarding more details for second reason "The App Attest service rejects the key."

https://developer.apple.com/documentation/devicecheck/dcerror/3585177-invalidkey

Post not yet marked as solved Up vote post of mahashis Down vote post of mahashis
485 views

Replies

for some of the users

Which users? Is this in production? Maybe App Attest is doing its job correctly and not working for users who have hacked your app.

we are generating new key and challenge every time.

What exactly do you mean by that? It's important not to generate new keys too often, as that can look suspicious.

Here is one scenario to consider:

  1. You generate a key and register successfully. You store the key ID in the filesystem.
  2. The user replaces their device and restores your app on the new device.
  3. When your app first runs on the new device, it has the key ID that it saved in the filesystem on the old device, but the new device doesn't have that key, so App Attest fails.

(I've asked previously about best practice for where to store the key ID, but I don't have a good answer.)

If "which users?" turns out to be "users who have replaced their device", or "users who have restored their device from a backup", then something like this could be the cause.

  • These are production users. We have checked these are legitimate users and their device is not jail broken as well. And after some several failures, strangely we got success for for some of them failed ones.

    We are trying to generate new keys only when it fails while calling "attestKey(:clientDataHash:completionHandler". So, What are the best practices we can follow in this case? We are using UserDefaults to save them right now which does not seem secure what's your thought on this?

Add a Comment