iOS 5 Device Identifier

The obvious problem one encounters when storing the ID on the pasteboard is security. A "man-in-the-middle" attack is the first problem which comes to mind. Conceivably, some nasty iOS developer could simply overwrite or change the ID stored in the pasteboard causing havoc for all the apps on the device. iOS 5 Device Identifier solves this problem via a few methods:

1. Believe in the goodness of iOS developers. Seriously, there isn't anything completely "secure" iOS 5 Device Identifier can do. Since you have the source, you can do whatever the code does. If there are more evil iOS devs than I originally thought (which I doubt), I will change the encryption algorithms and distribute iOS 5 Device Identifier as a static library which will make it more difficult to view my encryption methods. Obviously, like DRM, no solution is perfect, it all depends on the evil inside of our hearts. Of course, if any developer manages to figure out the encryption method even in the static library, they're probably a bad-ass coder and not motivated to be a complete jerk.

2. Security by obscurity. OK, not the best technique in the book (does it even count as a technique?), but is one of our best options in this situation. Basically, iOS 5 Device Identifier uses a special method for naming custom pasteboards so that you'd have to read the source code to know how it generates the names. iOS 5 Device Identifier also keeps around 5 clipboards which it uses in case one of the clipboards is invalid or tampered with. Since you can't explicitly list all the pasteboards via the UIPasteboard class, this method adds a decent layer of protection. Mainly it just stops another developer from accidentally overwritten the unique ID.

3. Full AES encryption of unique identifier. In other words, the attacker would have to know how we generate our key to properly change the ID. If we don't have the ID cached and must look to the pasteboard, we will always verify that the decrypted ID has the correct form, etc. Again, if the attacker is determined enough he can easily figure out how iOS 5 Device Identifier generates the encryption key. If this becomes an issue, I'll simply release a new algorithm but as a static library which should reduce the problem.

4. Per-app caching. Seems obvious but once we find the existing ID from the global pasteboard or generate one ourselves, we cache it in NSUserDefaults. Since NSUserDefaults are sandboxed, this "ID caching" ensures the ID is now un-changeable.

Security Conclusion

Unless there is some really evil iOS developer out there, iOS 5 Device Identifier is about as secure as is reasonably possible. There is also really only one attack point which is the pasteboard. However, since the app grabs the ID from the pasteboard only once then caches it, the probability of shenanigans is fairly low.

You may have seen many other open-source solutions around the web which use the MAC address as the new unique ID. Unfortunately, this technique has a few downsides; the most prominent being the fact that the MAC address can actually change and thus render different IDs for different apps.

Unlike this solution, iOS 5 Device Identifier creates a unique ID using CFUUID which is identical in form to the device identifier. It then saves it to UIPasteboard and NSUserDefaults to ensure the single device ID is immutable.

Did I mention iOS 5 Device Identifier is simple?

[[UIDevice currentDevice] uniqueIdentifier]

and you're done. iOS 5 Device Identifier is a complete drop-in replacement for the current UIDevice method.

• Globally unique ID per device (not app specific)
• Drop-in replacement for existing API
• IDs are exactly the same form, length, etc., as current device IDs
• Secure by obfuscating pasteboards, encrypting, and verifying when decrypting
• Efficient; after initial fetch from pasteboard the library caches in NSUserDefaults
• Lightweight: one file, one category
• Network effect is cool. The more apps that use this the more identified devices we'll have.