SecureUDID is no longer supported

With the release of iOS 6 last year, Apple made great strides towards offering a powerful, secure UDID replacement. Now that iOS 6 makes up the vast majority of active iOS usage and in concert with Apple's official deprecation of the UDID, it is time to retire SecureUDID as well. We recommend using Apple's iOS 6 vendor and advertising identifiers instead. Check out our other Crashlytics Labs projects.

Finally, a UDID
solution that's secure
and respects privacy.
Crashlytics is pleased to announce
Here's the Story
What is SecureUDID?

SecureUDID is an open-source sandboxed UDID solution aimed at solving the main privacy issues that caused Apple to deprecate UDIDs.

SecureUDIDs have the following attributes:

  1. Developers can still differentiate between devices as if they were still using a UDID, but only within their own code (including SDKs, like ad or analytics networks).
  2. User privacy is protected since developers are fundamentally prevented from accessing the same UDID as another developer. This greatly limits the scope of any potential leaks.
  3. End-users can globally opt-out of SecureUDID collection across all applications and services that use it.
How do I use it?

#import "SecureUDID.h"
NSString *domain = @"com.example.myapp"
NSString *key = @"difficult-to-guess-key"
NSString *udid = [SecureUDID UDIDForDomain:domain usingKey:key];
// The returned udid is a 36 character (128 byte + 4 dashes)
// string that is unique for that domain, key, and device
// tuple.

Cross-app identification
Distinguish devices
Allow end-user opt-out
Secure: accessible by domain only
Who is behind SecureUDID?

The team at Crashlytics wanted to address the UDID situation in a way that adhered to privacy concerns. Crashlytics wanted to contribute this back to the community.

Will my app get rejected for using SecureUDID?

No, we respect the privacy of users, and the UDIDs are not global. This gives the developer the same benefits as Apple's UDID without exposing the user to privacy issues. SecureUDIDs use no private APIs.

Can an Ad Network or Analytics network use SecureUDID?

Absolutely. Just simply incorporate SecureUDID into your framework that you distribute and you will be able to generate UDIDs across all your apps. So, if you're an ad network with 50,000 apps, you will be able to get UDIDs on all of them once you incorporate SecureUDID into your SDK. The UDIDs are secure and private and do not present a risk to the end user.

What about OpenUDID?

OpenUDID was an initial early responses to Apple's deprecation of UDIDs and our very own Sam Robbins was its second contributor. OpenUDID is fundamentally flawed. Establishing a single identifier per device, like OpenUDID, is fundamentally no different than a MAC address or Apple's UDID - the privacy concerns remain. We did a clean rewrite from scratch and built SecureUDID with privacy in mind. SecureUDID is feature-parity with OpenUDID but also sports better privacy and security.

Can I use SecureUDID with other UDID frameworks, like OpenUDID?

Yes, SecureUDID does not conflict with any other UDID implementation or framework.

What about Android?

We chose to initially implement SecureUDID on iOS, but the concepts can be applied equally to Android, Windows Phone, and other platforms. We welcome contributions!

How can I get involved?

Fork the crashlytics/secureudid project on GitHub, file issues, implement fixes, and submit pull requests!

Technical Overview
What is needed to create a SecureUDID?

Creating a SecureUDID requires a domain and a key. Both values can be any arbitrary string, however, we strongly recommend the following:

  • Domain: Your app's bundle identifier, or another reverse-DNS string. For example, "com.example.myapp"
  • Key: A difficult-to-guess string, used for encryption.
What's the purpose of the key?

Domains are, in all likelihood, guessable by a third-party. Keys make it much more difficult for a third-party to decrypt your identifier. Because they ultimately live in your application's binary, you should not consider them to be guaranteed confidential.

How are SecureUDIDs stored?

On iOS, SecureUDIDs are stored on a series of persistent UIPasteboards, which are maintained across app restarts, device reboots, and OS or app upgrades. Importantly, these pasteboards are accessible by all applications, so SecureUDIDs for a given key-domain pair are accessible from anywhere.

Wait. How are SecureUDIDs actually secure, then?

To ensure that no other domain could poke around and access the SecureUDID of another, they are encrypted using AES-128 before being stored. Since both the domain and the key are required to decrypt this value, only the owner can access them.

How is this different from a hardware-based identifier?

While unlikely, it is technically possible for two distinct devices to report the same identifier, and for the same device to report different identifiers. Consider this carefully in your application. Here is a list of situations where this identifier will not exhibit the uniqueness/persistence of a traditional UDID.

  • The user has opted-out of the SecureUDID system, in which case you will receive a well-formed string of zeroes.
  • Device A is backed up and then restored to Device B, which is an identical model. This is common when someone breaks their phone, for example, and is likely desirable: you will receive Device A's SecureUDID.
  • The SecureUDID data is removed, via user intervention, UIPasteboard data purge, or by a malicious application.
  • The SecureUDID backing store becomes corrupt.
  • All SecureUDID applications are uninstalled from a device, followed by a UIPasteboard data purge.

To protect against the latter case, SecureUDID leverages multiple pasteboards (up to SUUID_MAX_STORAGE_LOCATIONS), creating one for each distinct domain/app that leverages the system. As such, the permanence of SecureUDIDs increases exponentially with the number of apps that use it.

Why are so many pasteboards required?

SecureUDID leverages persistent UIPasteboards to persistently store its data. UIPasteboards marked as 'persistent' have the following attributes:

  • They maintain their values across application relaunches, device reboots, and OS upgrades.
  • They are destroyed when the application that created them is deleted from the device.

To protect against the latter case, SecureUDID leverages multiple pasteboards (up to SUUID_MAX_STORAGE_LOCATIONS), creating one for each distinct domain/app that leverages the system. As such, the permanence of SecureUDIDs increases exponentially with the number of apps that use it.

Usage Overview
How is SecureUDID licensed?

SecureUDID is available under the permissive MIT open-source license.

Can the same SecureUDID be accessed from multiple applications?

Yes, but only if you specify the same domain and key.

As an end-user, how do I opt-out?

The SecureUDID app is coming soon to the App Store. The app displays which applications are accessing SecureUDIDs, when they last did so, and permits the user to opt-out of the SecureUDID system. When a user opts out, all SecureUDIDs on that device are destroyed and new ones are no longer created.

Why isn't the code to opt-out included in the SecureUDID repository?

The SecureUDID application will also be open-source and available in a separate repository, so the code will be available. We elected to separate the opt-out (and, more importantly, the opt-in) code into a different repository to reduce the temptation for SecureUDID clients to ("accidentally") opt-in the end-user before accessing a SecureUDID, which would defeat the purpose. Sure, someone could copy the requisite code into their app to work around this, but That Would Be Evil.

Can the deletion of an app result in the loss of another app's UDID?

No. The persistence mechanism has been architected so that the deletion of any one app will, worst case, result in the loss of only that app's SecureUDID.