iOS Counter Forensics: Encrypting SMS and Other Crypto-Hardening

As I explained in a recent blog post, your iOS device isn’t as encrypted as you think. In fact, nearly everything except for your email database and keychain can (and often is) recovered by Apple under subpoena (your device is either sent to or flown to Cupertino, and a copy of its hard drive contents are provided to law enforcement). Depending on your device model, a number of existing forensic imaging tools can also be used to scrape data off of your device, some of which are pirated in the wild. Lastly, a number of jailbreak and hacking tools, and private exploits can get access to your device even if it is protected with a passcode or a PIN. The only thing protecting your data on the device is the tiny sliver of encryption that is applied to your email database and keychain. This encryption (unlike the encryption used on the rest of the file system) makes use of your PIN or passphrase to encrypt the data in such a way that it is not accessible until you first enter it upon a reboot. Because nearly every working forensics or hacking tool for iOS 6 requires a reboot in order to hijack the phone, your email database file and keychain are “reasonably” secure using this better form of encryption.

While I’ve made remarks in the past that Apple should incorporate a complex boot passphrase into their iOS full disk encryption, like they do with File Vault, it’s fallen on deaf ears, and we will just have to wait for Apple to add real security into their products. It’s also beyond me why Apple decided that your email was the only information a consumer should find “valuable” enough to encrypt. Well, since Apple doesn’t have your security in mind, I do… and I’ve put together something you can do to protect the remaining files on your device. This technique will let you turn on the same type of encryption used on your email index for other files on the device. The bad news is that you have to jailbreak your phone to do it, which reduces the overall security of the device. The good news is that the trade-off might be worth it. When you jailbreak, not only can unsigned code run on the device, but App Store applications running inside the sandbox will have access to much more personal data they previously didn’t have access to, due to certain sandbox patches that are required in order to make the jailbreak work. This makes me feel uneasy, given the amount of spyware that’s already been found in the App Store… so you’ll need to be careful what you install if you’re going to jailbreak. The upside is that , by protecting other files on your device with Data-Protection encryption, forensic recovery will be highly unlikely without knowledge of (or brute forcing) your passphrase. Files protected this way are married to your passphrase, and so even with physical possession of your device, it’s unlikely they’d be recoverable.

Note:  If you’re using a PIN or a weak passphrase on an iPhone 4 or older, it’s almost guaranteed that it can be brute-forced. My own forensic imaging tools (which I provide to law enforcement) can do this. There are presently a number of other tools to brute force your PIN, and a few that will attempt a number of different attacks on your passphrase, so while this technique will make forensic recovery much more difficult, it ultimately depends on the strength of your passphrase. At the moment, it does not appear any of these brute forcing tools work on the iPhone 4S or iPhone 5, and Apple has not demonstrated any willingness to perform such techniques for law enforcement. It is possible, still, that using a weak passphrase (or a PIN) could be brute forced at one level or another, so if you’re going to go to the trouble of implementing this technique, I suggest you at least use a strong passphrase.

Lets get the one caveat out of the way: since whatever files you encrypt will be encrypted (and unreadable) on a reboot, if you’re going to reboot your phone, you need to type your PIN or your passphrase in before you’ll be able to use those files again, which also means your phone won’t be able to receive texts until you enter your passphrase after rebooting. You don’t have to do this every time the phone locks, just when you first reboot it. Most people do this without even thinking about it anyway, so it’s not that big of a deal. This is the kind of security we have with our desktop machines already.

So how do we enable better encryption for a file? This simple snip of source code below shows how Apple’s file manager is called to set the NSFileProtectionComplete bit on a file:

#import <CoreFoundation/CoreFoundation.h>
#import <Foundation/Foundation.h>
#include <stdio.h>
#include <stdlib.h>
int main(int argc, const char *argv[]) {
 if (argc < 2) {
 fprintf(stderr, "usage: %s [filename]", argv[0]);
 exit(EXIT_FAILURE);
 }
[ [ NSFileManager defaultManager ] setAttributes:
 [ NSDictionary dictionaryWithObject: NSFileProtectionCompleteUntilFirstUserAuthentication
 forKey: NSFileProtectionKey ]
 ofItemAtPath: [ NSString stringWithUTF8String: argv[1] ] error: nil ];
}

If you want to compile this yourself with Xcode, just run:

$ export SDK_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk
$ export ARM_PATH=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/
$ ${ARM_PATH}/arm-apple-darwin10-llvm-gcc-4.2 -o protect protect.m -lobjc -framework Foundation -framework CoreFoundation -isysroot ${SDK_PATH}

I’ve created a precompiled version of this binary in a zip archive here:  protect.zip

This file contains two binaries, protect, and protect_full. The “full” version can be used to protect certain files so that they are encrypted EVERY TIME the device is locked, instead of just on reboot. Be very careful when using the “full” version, as your device needs to be able to access files such as your SMS database even when the device is locked, otherwise you won’t get them. For most system files, I recommend the protect binary. The only difference is that the “full” version uses NSFileProtectionComplete, whereas the standard version uses NSFileProtectionCompleteUntilFirstUserAuthentication.

Once you’ve compiled (or extracted) the binary, copy protect over to a jailbroken device and install it in /usr/bin (or wherever you like). To activate data-protection encryption to any file, make sure the device is UNLOCKED, then simply invoke the program. The following commands will protect the SMS database with data-protection encryption:

# protect /var/mobile/Library/SMS/sms.db
# protect /var/mobile/Library/SMS/sms.db-shm
# protect /var/mobile/Library/SMS/sms.db-wal

Once you’ve finished protecting these, and any other files you want better encrypted, safely power down the device and restart it. You can verify that data-protection has been added to these files by leaving the device locked when it restarts, then use iProxy and SSH to SSH to the device across your USB:

desktop:~ $ iproxy 2222 22
desktop:~ $ ssh -l root 127.0.0.1 -p 2222
iPhone:~ root# cat /var/mobile/Library/SMS/sms.db
cat: sms.db: Operation not permitted

Now unlock your device, and try it again. The file’s guts should get dumped to your screen. Other files that you may want to encrypt in this fashion can be found in /var/mobile/Library.

Note that you’ll need to protect each file individually (this simple program does not understand the * wildcard).  You can do this easily with a find recipe.

iPhone:~ root# find /var/mobile/Library/Safari -exec protect {} \;

You may also opt to encrypt specific photos or other media found in the /var/mobile/Media directory. Note that this won’t protect any newly created photos or music; you’ll have to explicitly protect them once created.

Here’s a little bash script I put together that covers most of the real sensitive data: protect.sh

That’s it! It sounds really simple, and it is. There’s no practical reason Apple couldn’t have turned on their higher end encryption scheme for these files, but now you can do it on your own.

Comments are closed.