First things first. The so-called Siri "vulnerability" that was widely reported this week is a dumb non-issue created by journalists seeking sensationalist headlines. A simple setting disables the ability to use Siri without unlocking the phone rendering the whole issue moot. What the sensationalists fail to take into account is that the iPhone is a consumer device. Most consumers don't even use a passcode. The obvious default setting for Siri in this case, as one of the attractive new USPs of the iPhone 4S, is to allow use even when the phone is locked - I don't think you can fault Apple for this.
Now on the other hand, things need to change when these consumer devices are allowed in an enterprise. Exchange Active Sync (EAS) or Mobile Device Management (MDM) software should be used to apply minimum security policies, which should always include a complex passcode of more than 4 characters, auto wipe on multiple failed passcode attempts and, of course, disabling Siri without unlock (this latter capability would required MDM, since it is not available in EAS). There are many other security settings that should be addressed too, but the main one is the passcode.
Once the passcode is enabled, Data Protection is turned on. Now, Data Protection is NOT full disk encryption, although encryption IS turned on globally. However, you should assume that it only encrypts data in applications that support the Data Protection APIs (this is an over simplification, but the details are too complex for a blog post and are the subject of an Analysis Brief that will be available shortly to NSS subscribers).
Out of the box, that is the iOS Mail client, for example. Other commercial apps will support Data Protection too, though these are few and far between right now - GoodReader is one of the best known. Others include USB Disk Pro, mobilEcho and the Box.net iOS client. There are several more, but not enough of them given that these capabilities have been available since the pre-release of iOS4, and we are now on iOS5!!! This continues to be a sore point with me as many developers make a big deal out of pushing their apps as business-class, yet spend more time making nice UIs and not enough securing the data that they are supposed to be protecting. Bear in mind that these apps will typically be used to access corporate documents, in many cases storing locally on the device outside the control of corporate IT. That data needs to be encrypted.
With apps that support Data Protection, you have an additional layer of encryption on the iOS device. If you have a passcode set on the iPhone and you turn on Data Protection in GoodReader, all of the docs stored in the GoodReader sandbox will be encrypted in the same way as data stored by the Mail app. You can even have some data in the clear and restrict encryption to certain files or folders.
So far so good, but what about those “researchers” that have written about the fact that jailbreaking an iOS device or connecting one to Ubuntu will provide access to all data on that device? Yes, unfortunately it is possible to jailbreak an iOS device and completely bypass the passcode. There are other ways to bypass the passcode too (such as that issue with Ubuntu). Because of the way iOS implements the Data Protection capability, once the passcode is entered or bypassed, all of the data on the device that is not protected by Data Protection APIs specifically is unencrypted on the fly.
Therefore, if someone jailbreaks my iPhone they will be able to access all of the documents stored in the ReaddleDocs or PDF Expert sandbox because the iPhone will decrypt on the fly as the data is accessed. However, if they try to access my Mail data or anything stored in the GoodReader sandbox, they will only see encrypted data. Same thing goes for items stored in the keychain. Anything stored in the clear will be accessible when a device is jailbroken. Anything written using Data Protection APIs will remain encrypted.
Only by entering the passcode can that encrypted data become available. This is an important distinction that needs to be understood. Jailbreaking/bypassing the passcode DOES NOT BREAK iOS ENCRYPTION - it merely bypasses the basic protection on the device. Anything stored using Data Protection APIs WILL REMAIN ENCRYPTED EVEN FOLLOWING JAILBREAK.
There is no way to brute force the passcode off-device since it is tied to the hardware. If you have auto-wipe turned on, too many attempts to brute force the key on-device will result in a wipe. One nasty problem is that you CAN do brute force attempts on-device without triggering auto-wipe by bypassing the UI APIs that ask for the passcode, so that is why security-conscious folk need to ensure they use a longer, complex, alphanumeric passcode that will resist brute force attempts.
So there you have it. Could Apple’s encryption scheme be better? Yes, of course it could. There are some caveats, and I would have preferred it to be full-device encryption, or at least to have a central document storage area that is always encrypted by default. However, my opinion is that iOS devices are perfectly acceptable and secure enough for corporate use PROVIDING they have a sensible security policy applied, Data Protection is turned on, a complex passcode is used and any sensitive data is ONLY stored within apps that support Data Protection APIs. Corporate users should always ask iOS developers if their app supports Data Protection and avoid those that do not.
The Sophos post and original Fraunhofer research, and any others spouting similar opinions, can be dismissed with a simple analogy, since they appear to assume Data Protection is not being used - if that is really the case, it is like leaving your keys in the ignition and locking the door, then complaining when someone smashes the window and drives off with your car!
I am taking a significant number of inquiries from NSS client each week on this subject, proving that it remains confusing for many. I hope this helps a little. In addition, as I mentioned earlier, there are a couple of NSS Labs Analysis Briefs in the works covering iOS Data Protection and other security issues facing corporate users of consumer devices. These will be available to subscribers only. Follow me on Twitter (@bwalder) to keep informed as new research is released.
Subscribe to:
Posts (Atom)
Posts
