Recently, I had the opportunity to speak to representatives at Good Technologies, the company that provides secure encrypted containers on mobile devices and patented many components of the BES employed by RIM for the Blackberry. To preface, I was enticed for the meeting after being told that our choice for MDM left "our data unprotected and could possibly be compromised".
In understanding Good's approach to BYOD and data encryption, the key (pardon the pun) was that Good did not use iOS encryption functions, but provide their own encryption technology, which includes integration of "BES-like" services for challenge/token response. When I asked why iOS encryption functions were not considered safe (at least by Good), the answer provided was "google Apple DFU mode". So, I did (actually our solution architect, Jim Joseph, did).
So what is DFU mode and what is it's relevance to this conversation? To understand this requires an understanding of how Apple devices function at an operating system level. A zip file that contains boot loaders, kernel, system SW, libraries, built-in apps, etc. is the assembly of iOS itself. The boot sequence of iOS does require authorization through a "chain of trust", including RSA signatures that checks components in a specific order. All root certificates for signature check are contained within the bootRom, which is the first call on powering the device.
iOS devices have 3 modes of operation - Normal, Recovery, and DFU.
In Normal mode, the BootRom initializes and loads the low-level boot loader (LLB) by verifying its signature. LLB signature checks and loads the stage 2 boot loader (iBoot). iBoot signature checks the kernel & device tree and kernel signature checks all the user applications.
In DFU mode, the BootRom signature checks the second level boot loaders (iBSS, iBEC). Boot loader signature checks the kernel and kernel signature checks the Ramdisk. This is what occurs during an iOS update.
So the trick in DFU mode is to load a custom Ramdisk that allows us full access to the filesystem of the device. To do this, you have to bypass all the signature checks of iBSS and iBEC. In the chain of trust boot sequence, if one link is compromised, full control is possible on the following links, including the RAMdisk. There are plenty of articles on jailbreaking and developing RAMdisks.
Once you are able to get to the filesystem, you need to get past the encryption of the files. Since iOS 4, every file is encrypted with its own unique encryption key tied to particular iOS device. Additionally, a data protection mechanism adds another layer of encryption that does not give access to the protected files & keychain items when the device is locked. Bottomline - Even in DFU mode, you have to break the passcode lock to get to access to the files.
Data protection is the combination of using hardware based encryption along with a software key. Every iOS device contains a special piece of hardware (AES processor) which handles the encryption with a set of hardcoded keys (UID, GID). OS running on the device cannot read the hardcoded keys but it can use the keys generate by UID (0x835 and 0x89B) for encryption and decryption. Software key is protected by a passcode and is also used to unlock the device every time the user wants to make use of the device.
Passcodes are validated at two levels on an iOS device - at the springboard and at the kernel. Springboard is protected from bruteforce attack by policies (like passcode attempts and device wipe) where kernel attacks are not. So at the kernel level, such as DFU mode, bruteforce is possible.
However in iOS, to make bruteforce attacks less practical, the user passcode is directly tied to the HW UID key. This means that bruteforce attacking must be done on the device.
To give you an idea of the vulnerability of a bruteforce attack at the kernel level, please note the following:
How does Good avoid this? Because Good stores all relevant data in its own encrypted container that requires you to access keys and authentication through the "BES" like server, the only way to decrypt the data is to connect. As soon as this is done, wipe policies can be enforced. With iOS encryption only, you would need to do all of the steps provided above (on a Mac, no Windows) and then wait for the bruteforce attack to complete. For a standard 8 character alphanumeric password, this could be over 13,000 years.
There are still pros and cons outside data access vulnerabilities, allbeit small (8 years to crack a 5 character alphanumeric passcode in DFU mode). The downside of Good's containerization is you can't use native applications for things like email. Applications must utilize Good's encryption SDK in order to share data between them.
Or....
You can force users to enter an 8-character alphanumeric passcode and use traditional MDM policies, maintaining access to all their documents, sharing documents between any application available in the appstore, corporate or public, but beware the potential 13,000 years it would take to unlock the filesystem in DFU mode.
Either one works. Just depends on which one your organization is comfortable with.
For more detail on DFU mode and custom RAMDisk install procedures, check out the following link:
http://securityxploded.com/demystifying-iphone-forensics-on-ios5.php
Labels: Apple, DFU mode, Good, iOS Encryption, MDM, security
