One of the problems we deal with a lot at AppBlade is understanding why apps fail to install. This may seem simple but it turns out to be fairly complex. At its base is the iOS security model, which needs to ensure that you’ve been given access to install an application on your specific device.

The simple approach and the one used by several other competitive services, and formerly AppBlade, is to collect the UDID (your device’s unique hardware identifier) from a provisioning profile and then store a cookie in the web-browser. This sounds simple and actually works, until iCloud and device backups come into the picture. If you receive a new device and restore it from an iCloud backup the cookies are also restored, while great for usability of most web services, it can cause a lot of pain when you need to know the exact device; the launch of new iPhone models cause a lot of headaches for services like AppBlade.

iCloud, eating all our cookies
iCloud, eating all our cookies

You can kludge fix this by looking at the user-agent string but this isn’t really a robust solution. What if you broke your screen and got the same exact model, with the same exact version of iOS installed? Triggering re-registration on user-agent change won’t help here. If we can’t rely on your device cookies, what can we rely on? The answer is based in Apple’s enterprise security guidelines.

Say you get hired at a large enterprise with a strict network access policy, often they’ll have you go through a process in which you cryptographically enroll your devices with the corporate network, email server, etc. While not the exact use-case, all of our end-conditions are met—AppBlade needs a way to identify an exact device in a way that is not backed up and can’t be easily forged; Simple Certificate Enrollment Protocol or SCEP will do the trick.  The SCEP protocol has been implemented in iOS for a couple years now, but isn’t common outside of the mentioned case of provisioning a device for enterprise network access. We use it as a sort of cryptographic “reverse cookie,”  instead of the server generating a token and asking the browser to  hold onto it we ask the browser to generate a unique token (actually an RSA key pair.) The browser then signs every request with an SSL certificate based off this. Since the certificate is generated on and associated with the specific device it will not migrate on to a new device with iCloud; furthermore, it’s stored on the device keychain and the private key is never disclosed to anyone (including AppBlade) so it’s much more secure.

We can also use this technology to secure your client side data, tell if devices are still enrolled in your corporate policies, and revoke access; we’ll have more on additional uses of this technology in future blog posts, so stay tuned.

 

Learn more about AppBlade

Comments are closed.