[App Check] Migrate AppAttestKeyIDStorage from UserDefaults to Keychain

[andrewheard]

Updated FIRAppAttestKeyIDStorage to use the Keychain as its underlying storage instead of NSUserDefaults. Since we use kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly in GULKeychainUtils, this means that the key IDs will not be migrated to new devices when restoring from backup.

Context: "The keys that you generate remain valid through regular app updates, but don’t survive app reinstallation, device migration, or restoration of a device from a backup." -- Start over on reinstallation

#no-changelog

[paulb777]

After discussion, we decided to put on hold while investigating a more targeted approach based on a specific error message.

[umairalitail]

@andrewheard, is this PR related to this issue? #11926

[jostster]

@andrewheard, is this PR related to this issue? #11926

Yes it is related and could solve it. However, I think the ideal approach would be to leave in the UserDefaults and like @paulb777 mentioned is target a specific error message to reset the key like my work around does.

[andrewheard]

@andrewheard, is this PR related to this issue? #11926

Yes it is related and could solve it. However, I think the ideal approach would be to leave in the UserDefaults and like @paulb777 mentioned is target a specific error message to reset the key like my work around does.

@umairalitail As @jostster said, this is related and could solve the issue in some scenarios (e.g., device migration) but it's unclear, at least to me, that it would resolve the issue in all scenarios (e.g., app reinstallation on same device). I'm holding off on this PR in favour of handling the specific DCError codes, e.g., DCErrorInvalidInput (code 2) and DCErrorInvalidKey (code 3), that we've been seeing in error reports.

[jostster]

@andrewheard, is this PR related to this issue? #11926

Yes it is related and could solve it. However, I think the ideal approach would be to leave in the UserDefaults and like @paulb777 mentioned is target a specific error message to reset the key like my work around does.

@umairalitail As @jostster said, this is related and could solve the issue in some scenarios (e.g., device migration) but it's unclear, at least to me, that it would resolve the issue in all scenarios (e.g., app reinstallation on same device). I'm holding off on this PR in favour of handling the specific DCError codes, e.g., DCErrorInvalidInput (code 2) and DCErrorInvalidKey (code 3), that we've been seeing in error reports.

Would it make sense to also make the resetAttestation public so developers could reset in other rare use case scenarios?