Category Archives: forensics

Limitations of Data Protection in iOS 4

Data Protection at work in iOS 4

Apple’s recently released iOS 4 provides enhanced “data protection”, but there is very little on the web now that explains what this really means. In this post I clarify what data protection is and what some of its limitations are.

What Data Protection Is

First of all, it’s important to note what encryption capability the iPhone already had (which I discussed here. The release of the iPhone 3GS (and later iPod Touch 3rd Generation) brought hardware-based full disk encryption (FDE) to the iPhone. This was designed to accomplish one thing: instantaneous remote wipe. While the iPhone 3G had to overwrite every bit in flash memory (sometimes taking several hours), disk wiping on the 3GS worked by simply erasing the 256-bit AES key used to encrypt the data.

Unfortunately, disk encryption on the iPhone did little beyond enabling remote wipe. Mobile forensicator Jonathan Zdziarski found that the iPhone OS automatically decrypts data when a request for data is made, effectively making the encryption worthless for protecting data.

So I was curious to learn what encryption improvements were made in iOS 4. Apple calls its new encryption scheme “data protection”, a substantial improvement in security design. Data protection has the primary advantage of using the user’s passcode or password to derive a key that is used to encrypt data on the device. When the phone is locked or turned off, the key is immediately erased, making data secured on the device inaccessible.

Limitations of Data Protection

The details of how data protection works are described in Apple’s recently released videos from its world-wide developers conference (see Session 209 “Securing Application Data”). This information is protected by an NDA, but I’ll summarize at a high level five basic limitations.

First, to make data encryption work a user must have an iPhone 4, iPhone 3GS, or iPod Touch 3rd Gen (previous iPhones don’t support hardware encryption). Importantly, 3GS users who upgrade to iOS must restore the device as the iOS 3 file system doesn’t support the new data protection scheme. The steps to do this are described here.

Second, files are encrypted individually by software classes that implement data protection. This means that developers must deliberately choose to use data encryption in their apps, otherwise data is unprotected. Currently, Apple says that so far only Mail is setup to use data encryption, although they say they will eventually bring data encryption to other applications. This means that even with data encryption enabled, text messages, contacts, photos, web history—in short, everything else—is left unprotected.

Third, a user must use a passcode or password. The strength of the password is up to the user, which is generally a good thing for forensicators.

Fourth, to mitigate the threat of a brute force attack, the file encryption requires a key generated by the device itself, in addition to the key derived from the user’s password. This slows brute forcing because the encryption key generation process is slow by design: the iPhone 4 takes about 50 milliseconds to derive the key once the user submits a password. This means an attacker can guess only about 20 passwords per second.

This might not sound like much of a speed reduction, but this actually compares well with software-based encryption products. By comparison, I’ve used AccessData’s Password Recovery Toolkit to guess up to 900,000 passwords a second for encrypted Microsoft Office files. Encrypted PGP files allow about 900 password guesses per second.

Fifth, a weakness in the data protection system is something called the “Escrow Keybag”, which is a collection of keys necessary to decrypt every file on the device without requiring the user’s password. This was done to allow computers to sync with the iPhone without asking the user for the password.

This was a deliberate trade-off to enhance user experience. Apple’s rationale was that if the PC containing the escrow keybag was obtained, an attacker most likely already had the user’s important data anyway. For forensicators, this means that if a user’s computer is obtained along with the iPhone, it will be much easier to decrypt the user’s protected data.

Updated August 6, 2010: Elcomsoft has announced that its iPhone Password Breaker tool can recover iPhone keychains (probably the escrow keybag) from password-protected iPhone backups.

Summary

Currently, data protection in iOS 4 is still limited. Apps must be updated to use data protection and currently only Mail does so. All other data can be easily obtained without the users password.

Even so, data protection in iOS 4 represents a significant improvement over encryption in iOS 3. It is clear that Apple is striving to iteratively improve security on the iPhone, which is a good thing.

In the meantime, it looks like forensicators won’t have to worry too much about getting the data they need off of an iPhone.

iPhone 3GS Encryption Follow-up

I wrote last month about the new hardware encryption feature of the iPhone 3GS, which some have claimed provides the iPhone with “enterprise-class security”. However, now that the iPhone 3GS has been out for a month, Jonathan Zdziarski, author of iPhone Forensics, has shown that the encryption on the 3GS is much weaker than suspected.

In this Wired article and associated Youtube videos, Jonathan shows that while the iPhone’s disk is encrypted, the kernel decrypts the data when it is requested by widely-available open source tools. Jonathan will also demo how this works in an O’Reilly Media webcast on July 29th.

This is pretty laughable security. It is essentially encryption in name only. This is a good example of why it is not enough for a device or software to correctly implement a secure encryption algorithm (in this case AES 256). All other aspects of the system must be designed securely.

I love my iPhone 3GS for its refined UI experience and third-party applications, but it’s clear that security has relatively little emphasis in the iPhone’s ongoing development.

The iPhone 3GS and Forensics: Encryption Changes the Game?

One of the new iPhone 3GS features that has received little attention this week is hardware encryption. However, from a forensics standpoint, this is probably the most significant feature of the new update. The feature is buried at the bottom of this “more features” page:

Phil Schiller also briefly mentions this feature at 1:52 of the Apple keynote.

Why Encryption on the iPhone Matters

Encryption on the iPhone matters to businesses because the iPhone can store potentially sensitive information. Among other things, forensics investigators can recover the following from iPhones (from iPhone Forensics by Jonathan Zdziarski):

  • Keyboard caches containing usernames, passwords, and nearly everything typed on the iPhone.
  • Screenshots of the last state of an application before the home button is pressed to return to the main menu.
  • Deleted images.
  • Deleted calendar entries and contacts.
  • A record of the last 100 calls made.
  • Viewed Google Maps images and directions.
  • Browser history and caches, even when deleted.
  • Deleted email messages.
  • Deleted voicemail.
  • Pairing records establishing which computers the iPhone was synced with.

You might think that extensive forensics experience and knowledge of the iPhone operating and file system is needed to recover this data. However, several specialized forensics tools, such as Paraben‘s Device Seizure and the Sixth Legion‘s Wolf, have automated this forensics process and can recover sensitive data from iPhones in seconds.


So it is understandable that encryption on the iPhone is a highly requested feature by corporations, according to Phil Schiller. Hardware-based encryption on the iPhone could effectively nullify forensics work on the iPhone.

Remote Wipe: A Potential Weakness

However, one potential weakness in the iPhone encryption scheme is how the encryption key is stored, and is related to another new iPhone 3GS feature, instantaneous remote wipe:

According to Schiller, hardware encryption on the iPhone 3GS enables instantaneous remote wipe. Apparently, rather than overwriting every bit as does the iPhone 3G, a remote wipe on the iPhone 3GS only overwrites the hardware encryption key, rendering all data on the iPhone unintelligible. This explains why if you later recover your iPhone 3GS, you can restore your data by enabling your MobileMe account on the iPhone, which apparently downloads the hardware encryption key to the iPhone, making the data on the iPhone readable again.

Although this feature is convenient, it does pose a potential security problem. If the hardware encryption key is hidden in the iPhone file system without being encrypted itself, then a forensics investigator could find the key and decrypt data on the iPhone. And forensics tools like a faraday cage will prevent the iPhone from receiving a remote wipe command, lengthening the window to find the encryption key indefinitely.

Of course this would require specialized knowledge of the iPhone and cryptography, but that is exactly what forensics firms like Paraben and Sixth Legion have. And their expertise is encapsulated and automated in tools like Device Seizure and Wolf, extending this ability to more general users.

So while hardware encryption on the iPhone 3GS is an interesting development, unless the encryption key is itself somehow encrypted, it will be a matter of time before the forensics community learns a way to find the key and make forensic analysis of the iPhone 3GS possible.

[Update June 14, 2009: Jonathan Zdziarski of iPhone Forensics left an insightful comment below.]

Demonstrating Memory Remanence with OS X

In my forensics class this Monday I will talk about the disk encryption attack that Princeton researchers published in April of this year. The attack exploits the fact that data remains in RAM for up to several minutes after power to the computer is turned off. Rather than all memory being erased immediately, data in RAM quickly decays as time goes on. The Princeton research team showed that sensitive information such as passwords and disk encryption keys can be recovered from RAM after a machine is powered off. You can see a video of this attack here.

To demonstrate this attribute of RAM to my class, I will follow the simple experiment described here, but adapted to OS X:

1. Unlike other versions of Unix, as of the Intel processor switch OS X no longer has a device file for physical RAM. However, the kernel still supports such a device file. To reenable the device file for physical RAM, pass this kernel option to the boot loader as follows:

sudo nvram boot-args="kmem=1"

To verify that this kernel option was passed, type:

nvram -p | grep boot-args

You should see the following line:

boot-args	kmem=1

Note: to later remove this boot argument, type:

sudo nvram boot-args=""

2. Reboot your machine and verify that you now how a /dev/mem device file.

3. Open a terminal window, type “python” to enter the Python interpreter and enter these commands:
ram = ""
while True: ram += "MYPASSWORD"

4. The Python interpreter will run until physical RAM is so full that it cannot contain one more “MYPASSWORD” string. You can visually show students that RAM is filling up by showing the RAM pie chart in Activity Monitor. After waiting a few minutes after initiating the python command, immediately shutdown the computer by holding down the power button.

5. Wait a few seconds or minutes, depending on how much RAM decay you want to allow.

6. Turn the computer back on, open a terminal window, and type this command:

sudo cat /dev/mem > /tmp/ramdump.txt

This step will take a minute or two depending on how much RAM you have installed. Eventually the file will be as large as the amount of RAM installed. In my case, this command yields a 2 GB file.

The command will terminate with this error:

cat: /dev/mem: Bad address

This indicates that all of the contents of RAM have been copied to the /tmp/ramdump file.

7. Type the command,

grep -a MYPASSWORD /tmp/ramdump.txt

This command should then display many instances of the string “MYPASSWORD”, demonstrating that some data has remained in RAM even after power to the computer was turned off.

LinEn Network Acquisition using VMware Fusion for OS X

VMWare Fusion

For those who use EnCase for forensic analysis, a powerful and convenient means of acquiring digital evidence is over the network using Linen, a Linux-based version of EnCase Acquisition. Linen is run off of a Linux boot disk on the target computer serves the an evidence file to EnCase running on the forensic examiners computer over the network. EnCase is a Windows application, but network acquistions can be successfully performed using VMware Fusion for Mac with the following configuration.

For my setup, I have a MacBook running VMWare Fusion 2.0b1 and OS X 10.5.3. I’m running Windows XP as a VM with EnCase 6.11 installed.

Note: Because Mac’s can intelligently sense and correct the Ethernet connection when one computer is connected directly to another, a cross-over cable is not required.

1. Boot the target machine using Helix or another Linux live CD that contains LinEn.

2. Once at the Linux command line, type:

ifconfig eth0 10.0.0.1 netmask 255.0.0.0

3. On the Mac, change the IP address to 10.0.0.50 and subnet mask 255.0.0.0

4. Confirm that the Mac and PC can both ping the other.

5. On the Mac, edit the VMware Fusion boot script (/Library/Application Support/VMware Fusion/boot.sh), lines 676-681 as follows:


#"$LIBDIR/vmnet-bridge" -d /var/run/vmnet-bridge-vmnet0.pid vmnet0 en0
#"$LIBDIR/vmnet-bridge" -d /var/run/vmnet-bridge-vmnet0.pid vmnet0 en0
# Bridge to the primary host network interface (which can change over time).
"$LIBDIR/vmnet-bridge" -d /var/run/vmnet-bridge-vmnet0.pid vmnet0 ''
;;

Change to:


#"$LIBDIR/vmnet-bridge" -d /var/run/vmnet-bridge-vmnet0.pid vmnet0 en0
"$LIBDIR/vmnet-bridge" -d /var/run/vmnet-bridge-vmnet0.pid vmnet0 en0
# Bridge to the primary host network interface (which can change over time).
#"$LIBDIR/vmnet-bridge" -d /var/run/vmnet-bridge-vmnet0.pid vmnet0 ''
;;

6. restart VMware fusion

sudo "/Library/Application Support/VMware Fusion/boot.sh" --restart

4. Change the VMware Fusion network mode to Bridged networking

5. Boot the Windows XP VM and change the Windows VM IP to 10.0.0.2 and subnet mask 255.0.0.0

6. The target machine running Linux should now be able to ping the Mac and the Windows VM and vice versa.

7. Run Linen from the Linux Live CD on the target machine

8. From EnCase, acquire over a network cable.

PGP Whole Disk Encryption comes to OS X


Yesterday PGP announced the availability of their Whole Disk Encryption (WDE) product for OS X next month. Although disk encryption products for the Mac currently exist (like TrueCrypt and FileVault), these solutions only encrypt part of a hard drive, such as a user’s home directory.

Full disk encryption (which is what WDE provides), on the other hand, encrypts every bit on a hard drive—in used or free space. This is important, because forensics products such as EnCase and FTK are very good at finding traces of sensitive information in unused disk space and temporary files like the swap. With full disk encryption, EnCase and FTK are ineffective if an encrypted machine is powered off.

Another reason why PGP WDE for Mac is exciting is because PGP is a highly respected security company and it’s WDE has been tested by the National Institute of Standards and Technology (NIST) to meet its Federal Information Processing Standard 140-2 (FIPS 140-2). Both the reputation of PGP and the FIPS-140 certification indicate that encryption algorithms employed in WDE have been implemented correctly. This is crucial because even secure encryption algorithms can be easily broken if implemented poorly.

Full disk encryption is a great tool for any organization to protect sensitive information. In the next year, Georgia State University will require that PGP Whole Disk Encryption be installed on every laptop, workstation, or server that stores sensitive information. If every organization followed a similar policiy, privacy breaches would not be the almost-weekly security farce that they are today.