2

In iOS apps, Apple goes to a lot of trouble to keep applications from creating a stable identifier for a specific device. For example, in iOS >= 5 they no longer allow apps to get the hardware-tied UDID from UIDevice -uniqueIdentifier and instead exposes a value that changes between app installs in UIDevice -identifierForVendor. They also seem to put unwritten restrictions on the advertising ID, and allows the user to zero it out by enabling a "limit ad tracking" option.

However, as I've been working on an app that needs to identify the install to our servers, I noticed that there is a rather simple way to identify a device uniquely until a wipe occurs or a user manually edits their keychain.

When creating a SecureElement-backed private key, that key is stored in the HSM while the public part of the key is stored in the keychain. The keychain entries are associated with a specific bundle ID and are not removed when the the associated app is uninstalled. Also, HSM policies can be applied when creating the key that allow tying access to the key to a specific user's biometric identity.

Any time the app is reinstalled, it will have access to this hardware-linked identity which can be used to strongly identify the device and the user.

Why would Apple make this oversight, what are the security and privacy implications, and what can a user do to protect their privacy without having to manually manage the keychain?

Edit: Another interesting note, this actually can be used with app group keychain sharing in order to track a device and user's biometric identity across different applications deployed by the same vendor (FB, whatsapp, FB messenger, Instagram, etc. could easily be using this).

More Edit: After further research, it seems that there actually is no way for a user to edit their keychain to remove these persistent identities. Further, since the entry can be restricted in access to the originating app, there is no way to make a tool (i.e. another app) that would give a user an interface to remove the entries.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.