For quite a while I’ve been trying to figure out the whole truth about hardware encryption, data protection and keychain protection on iOS4 in combination with iPhone 3GS, iPhone 4 or iPad.
Starting with iPhone 3GS a hardware encryption chip is build into the device. Great! But what does it mean to me as a developer? How can I make use of all of this encrypting and masquerading?
First off, one needs to understand how all the encryption business works on iOS devices.
Best thing to do is to watch Episode 209: “Securing Application Data” from Apple’s WWDC 2010 conference (http://developer.apple.com/videos/wwdc/2010/) – note that you have to be a registered iOS developer to access the videos.
Next, navigate to http://anthonyvance.com/blog/forensics/ios4_data_protection/ and read the infos there.
Then understand the iOS devices’ different folders by going through this document
Now you’re set.
For me a few questions remained unanswered even after watching the video and reading dozens of articles on the web. I will try to answer them now as good as I can using my findings:
- The keychain allows defining a class “available when unlocked, this device only” which prevents a keychain record from getting transferred to another device using backup/restore. To my understanding there is nothing similar for files, or is there? How can I prevent FILE data being restored on another device?
- NSData allows storing files with protection and NSFileManager allows changing the security class of an existing file. I wonder if there are any disadvantages if I first store the file unencrypted and the use NSFileManager to change the class?
- If the user does not specify a PIN or passcode, there does not seem to be real protection. Does that mean, data is encrypted using the device key only, as introduced with the 3GS?
- If I change my PIN, what has to be re-encrypted by the OS? All of the encrypted files?
- Is there evidence that a PIN/or password protected device’s content which was protected using the “protect always” has been successfully hacked?
- My device contains files which are stored in encrypted format. If now I make a backupof my device in iTunes and do not select to encrypt and password protect that backup, are my backed up files still which were encrypted on the device still secure?
1. How can I prevent FILE data being restored on another device?
Easy answer: it is not possible as of iOS 4.2. The feature is available exclusively for the keychain. However it is possible to prevent data being backed up in the first place by putting it into the applications /Library/Caches folder. This folder won’t be included in the backup. Of course it won’t be restored to the device either. A usecase for this would be if you download sensitive documents from the web in your app, want to keep them local for offline viewing but want to make sure they will not be passed on to anybody else. If a restore is performed, the user will have to download once again.
An alternative option is to store the device’s unique ID in the filesystem and after restore compare it to the current device ID. If they don’t match, data cannot be accessed.
Or: store a flag in the keychain and set the security flag to allow restoring to “this device only”. If the flag is not there, deny access to files (or delete them). If it is there, you can be sure it is the device the files were written to originally.
2. Change security class after file has been created.
Apple’s document linked above says, one should set the encryption once the file has been created but does not have content yet. They do not tell if it is a performance issue or if it is a recommendation to keep the file protected all the time. So I cannot give a clear answer on that one. But if you don’t change classes constantly it should not matter. Looking at Episode 209, I would assume that only the file key is reencrypted using the new class which should not have a performance impact.
3. Is data secure if no passcode is defined?
Well, security is relative. Data will be encrypted using the device key only. According to this article (http://www.wired.com/gadgetlab/2009/07/iphone-encryption/), hacking it was easy back then with the 3GS and I think this is still true. So to keep data really secure, encourage your users to have a PIN on the phone or a passcode.
4. Change PIN – what will happen?
Only the keybag will have to be recreated. All files and file keys remain untouched. So changing the PIN is a really fast operation.
5. Has it been hacked?
iOS4 is using a variation of PBKDF2 (http://en.wikipedia.org/wiki/PBKDF2) with 50.000 (not 10.000 as Wikipedia states) iterations. As the device key is part of the encryption, decrypting can only be performed on the device itself which results in a significant low number of attack attempts per second. In addition the hacker has to break the device’s PIN/passcode first which is protected by increasing delays between each input trial. I have not found evidence that it has been hacked.
6. Backup & Restore
We only take encrypted files in account. Keychain has similar mechanism and even allows restore to “this device only” (see 1.). Assuming we have an encrypted file which is password/PIN protected on the device. A backup is made and the user specifies a password for the backup. Instead of encrypting using a combination of device ID and PIN, the backup is encrypted using a combination of device ID and backup password. To make it short: your data is secure. It can only go to another device if the password is entered. If however, no backup password is specified, the backup is encrypted using the device key only. Which seems to be easily hackable. So this is not a good thing to do. Encourage your users to pwd protect their backups.
One last note on the “Escrow” keybag: the desktop PC/Mac the iOS device is syncing with, contains an Escrow keybag which allows syncing the device without the user having to unlock it. Yikes…not good. This was introduced to improve usability. Apple says: if an attacker has the syncing desktop machine under control, he has probably all the valuable files already, so shit has already happened beforehand…well…In my opinion it should be an option. I would better like it to input my PIN everytime.