Simon Says – Musings of a Technology CTO

This weeks (potential) major fail goes to Apple for the iPhone 3GS security. As reported by Wired and others, it seems the new 3GS encryption touted by Apple in their “iPhone Security Overview” isn’t so secure after all.

The offical description of the new feature sounds pretty good:

iPhone 3GS offers hardware-based encryption. iPhone 3GS hardware encryption uses AES 256 bit encoding to protect all data on the device. Encryption is always enabled, and cannot be disabled by users.

But this excellent 2nd video demonstration by Jonathan Zdziarski shows plainly that there could be something very flawed about it.

Jonathon shows one of the architectural limitations of mobile platforms – you need the device to have a fail-safe hardware recovery mechanism (otherwise you could kill the hardware with bad software), but that opens the door to exploiting loader hacks, in his case, his subversion of the boot loader recovery mechanism to  zero out the password data.

On PC’s, this attack can be mitigated with full disk encryption where the (pre-boot) authentication details are used to decrypt the drive encryption key prior to the OS (stored encrypted) getting to boot – this is obviously very difficult to do on a phone as it’s expected to be on all the time, and rarely goes through the OS boot phase – how many of you actually ever turn your phone off, even when flying?

Jonathon’s demo is designed to prove the theory that disabling or zeroing the pin should render existing data on the device inaccessible, because it’s encrypted and the encryption is related to the device pin. A solid theory indeed.

His (abridged) flow was:

1. create some data (pictures)
2. set pin on iPhone
3. restart
4. use a loader hack on the phone to zero pin
5. reboot phone and create some new data
6. backup phone with iTunes and show the recovered new data AND old data is not protected

I can understand data stored after the key being zeroed would be in plain text on the backups, but surely the before-hack data should now be inaccessible as it should be encrypted with a (now lost) key related to the iPhone pin?

This is what Jonathon’s demo proves is not happening.

If it’s indeed possible to access all the data on the iPhone after zeroing the pin, both original and new, that indeed is a nasty flaw in the protection architecture. It would infer that there’s no relationship between the pin itself and the data encryption key. That data encryption key should by all rights be stored at least encrypted with the pin (PKCS5+salt), or better still stored in some tamper-proof hardware which can provide a hardened retry path (like a TPM or smart card chip). Doing anything which breaks the relationship between PIN and key should cause all data protected with it to be inaccessible – much like resetting a Windows user’s password can render all their EFS encrypted data inaccessible.

Storing the key on the device and just using

is (entered password == stored password)

is just plain silly, and I truly hope ( as a devoted iPhone user) Apple comes up with a good explanation as to what’s going on here and what we are all missing. Hey, if they want help making it bullet proof, I, and McAfee Data Protection would love to work with them.

PS – For those who’ve been using the iPhone for a while – do you remember the famous pin-bypass trick (now fixed) which let you get at the contacts, mail, web etc back in the days of iPhone2.02 and before? Simply, by double-hitting the home button when it was set to show “favorites”, you could then navigate to other apps.

This is much the same as the old Windows trick of using the HTML Help application to start other apps (it has a file browser, and from there, you can open any file you like, be it a help file or not).

PPS – If you’re thinking of dumping your iPhone and going to a BlackBerry, you might be interesting in the little fiasco happening in the UAE at the moment – It seems that the state-controlled telco Etisalat distributed a nice little performance enhancement “patch” to all BlackBerry users, which in fact contained SS8’s forensic interception client. Zensay Labs wrote a nice paper on what the patch does, but simply it allows Etisalat to ask the phone to forward emails you send back to them, thus bypassing the usual email protection methods which make interception of BlackBerry traffic difficult.