How do you protect your users' sensitive data? -- iOS

What would you think of someone who spent [an enormous amount of money] and installed industrial/military grade locks throughout his house, and then put a spare key under the doormat in front of the house? And what then would you say about someone who spent [another enormous amount of money] and installed an alarm system, and then put the unlock code on a post-it note on the face of the alarm system control panel? I can imagine most people wouldn't think highly of such a foolish person. There may even be expletives involved...

So then, what would you think if I told you the file system and every file on an iOS solid state disk (NAND flash storage) is encrypted using hardware-based AES-256? Your first impression might be pretty favorable. However, the disk itself (and its HFS journal) is encrypted with one key (the EMF! key), and then the vast majority of files are encrypted with another key (the Dkey) -- and these two keys are stored on the NAND in plain sight in Block 1 (PLOG). D'oh!

No worries, you say -- your device is locked using a passcode. So there! Well, it turns out that an attacker with physical access to your device can put it into DFU mode (Device Firmware Upgrade -- although I admit I thought it meant something else when I first learned about it) and boot via USB cable using a RAMdisk, easily created on a Mac using Xcode. Once booted, the attacker can access and steal all those files that are encrypted using the Dkey.

To be fair, not every file on an iOS device is encrypted using the Dkey. Notable exceptions to this are the user's email, and any file created by an app where "Complete" file protection is used. The device's keychain database also isn't quite as easy to to decrypt.

Most of those exceptions are encrypted using a key that is derived from the device's Unique IDentifier (UID) and the user's passcode. On the vast majority of consumers' iOS devices, that passcode is a 4-digit PIN. Not to worry, the good folks at Sogeti have provided us with a set of tools that can, among other things, brute force guess all 10,000 PINs and then decrypt most of the rest of the data.

Sounds pretty grim, doesn't it? For more reading on this, see Jonathan Zdziarski's excellent book "Hacking and Securing iOS Applications: Stealing Data, Hijacking Data, and How to Prevent It".

As a consumer, there are a few things you can do. As an enterprise, you can deploy a Mobile Device Management (MDM) solution and, among other things, enforce strong passcodes and such.

But, as a developer, you're not so lucky. As a developer, you cannot assume your customers will be smart enough to use a strong passcode. No, developers must assume the lowest common denominator in order to protect their customers' data adequately. And remember, the OWASP Mobile Security Project ranks a lost or stolen device as the number one risk faced by mobile consumers.

That means that for information exceeding simple consumer grade sensitive data, you must not rely on Apple's built-in file protections to protect your customers' data. There are a few alternatives, of course. We can make use of Apple's CCCrypt Library and make use of all that crypto hardware ourselves -- and stay in control of the crypto keys ourselves. (See Apple's sample CryptoExercise code for an example of how to do this -- it's a bit dated, but you'll get the basics.) We can also use third party libraries like SQLcipher to create encrypted databases where, once again, we control the crypto keys ourselves.

The common denominator in both of these approaches is control of the crypto keys. It's also the toughest (by far) problem to solve in using cryptography securely.

We'll be discussing these options, of course, at our upcoming Mobile App Sec Triathlon in San Jose, California, on 5-7 November. We hope you'll come join us, and let's discuss different approaches to tackling this enormously important and difficult problem.

Cheers,

Ken van Wyk