You can download the full resolution file here.

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.

I’ve wanted to install a solid-state drive (SSD) in my laptop for some time because of the dramatic boost in performance and responsiveness. However, I’ve been reluctant to buy one because I use full disk encryption (FDE) on my laptop, and I wasn’t sure how it would affect the speed of the SSD.

Unfortunately, there is not a lot of concrete information on the Web for the impact of FDE on SSD’s other than this gloomy blog post from November 2009. The author of this post used Utimaco Safeguard Enterprise to encrypt a Intel X25-M G2 160Gb SSD in a Dell Latitude E6400. Disappointingly, he found that with FDE, the SSD performed as slow or slower than the same laptop with an encrypted conventional hard drive. Clearly, in this scenario, there is little benefit to justify the cost of an SSD.

However, I use PGP 10 Whole Disk Encryption (WDE), one of the leading disk encryption products, which has just been updated with better support for SSD’s. I finally decided to purchase an SSD, and since I can’t find any other benchmarks for encrypted SSD online, I decided to perform my own.

The Setup

I have a Macbook Pro 17″ (Core 2 Duo; late 2009). It used to have a Seagate Momentus 7200 RPM drive, one of the faster conventional laptop hard drives on the market, and, as stated above, it was encrypted with PGP 10 WDE. As a baseline, I used Xbench to test how fast the drive performed.

Here are its scores:

Xbench Disk Test score: 36.64

Sequential 53.83

Uncached Write 73.59 45.18 MB/sec [4K blocks]

Uncached Write 52.87 29.91 MB/sec [256K blocks]

Uncached Read 37.01 10.83 MB/sec [4K blocks]

Uncached Read 67.64 33.99 MB/sec [256K blocks]

Random 27.77

Uncached Write 9.65 1.02 MB/sec [4K blocks]

Uncached Write 81.84 26.20 MB/sec [256K blocks]

Uncached Read 69.42 0.49 MB/sec [4K blocks]

Uncached Read 72.43 13.44 MB/sec [256K blocks]

I also performed some practical, “real-use” tests as follows:

Opening iTunes: 17 seconds

Opening Papers (PDF manager): 45 seconds

Opening VMWare Fusion and resuming a Windows XP VM with 512MB RAM: 50 seconds

Opening Microsoft Word: 24 seconds

Opening PASW 17 (SPSS): 24 seconds

Copying a 5.73 GB bzip file from one part of the hard drive to another: 4 minutes, 25 seconds.

Boot time from when the PGP passphrase is typed in to the OS X login screen: 1 minute, 16 seconds.

Login time from inputing password to when the Dock appears: 20 seconds

Time for start-up applications (Things, Skype (www.skype.com), and Snapz Pro X to load after inputing login password: 1 minute, 18 seconds.

All told, it took 2 minutes, 34 seconds to boot and load my start-up applications so I could begin using my computer normally.

The Unencrypted SSD

For comparison, I replaced the Seagate Momentus with a Crucial RealSSD, which as of April 2010, is one of the fastest SSD’s available.

Here are the same tests performed with the Crucial RealSSD unencrypted:

Xbench Disk Test score: 300.13

Sequential 184.15

Uncached Write 254.02 155.97 MB/sec [4K blocks]

Uncached Write 216.33 122.40 MB/sec [256K blocks]

Uncached Read 95.35 27.91 MB/sec [4K blocks]

Uncached Read 373.91 187.93 MB/sec [256K blocks]

Random 810.71

Uncached Write 1278.14 135.31 MB/sec [4K blocks]

Uncached Write 406.00 129.98 MB/sec [256K blocks]

Uncached Read 1578.45 11.19 MB/sec [4K blocks]

Uncached Read 947.85 175.88 MB/sec [256K blocks]

Dramatically faster. Here are some real-use comparisons:

Opening iTunes: 3 seconds

Opening Papers: 7 seconds

Opening VMWare Fusion: Loading Windows XP from suspend, 512MB RAM—7 seconds

Opening Word: 6 seconds

Opening PASW: 8 seconds

Copying the same 5.73 GB bz2 file: 52 seconds (five times faster than the encrypted hard drive).

Booting was as follows:

Boot time from Apple logo to the OS X login screen: 24 seconds.

Login time from inputing password to when the Dock appears: instantaneous

Time for start-up applications (Things, Skype, and Snapz Pro X) to load after inputing login password: 4 seconds.

The Encrypted SSD

Now with the tests of the encrypted hard drive and unencrypted SSD as baselines, I fully encrypted the 256 GB SSD using PGP 10 WDE. The process took two hours (which was in itself remarkably fast). Once the encryption process completed, I rebooted and ran the same tests again.

Xbench Disk Test score: 103.12

Sequential 65.10

Uncached Write 78.22 48.03 MB/sec [4K blocks]

Uncached Write 65.20 36.89 MB/sec [256K blocks]

Uncached Read 47.00 13.75 MB/sec [4K blocks]

Uncached Read 83.05 41.74 MB/sec [256K blocks]

Random 247.91

Uncached Write 370.32 39.20 MB/sec [4K blocks]

Uncached Write 120.49 38.57 MB/sec [256K blocks]

Uncached Read 1562.82 11.07 MB/sec [4K blocks]

Uncached Read 222.46 41.28 MB/sec [256K blocks]

As expected, the SSD is substantially slower using PGP WDE. However, it is still much faster than the encrypted 7200 RPM drive. Importantly, the uncached read times are still much faster (between 3 to 22 times faster). Probably for this reason, the user interface still feels very responsive and applications still open very quickly, with little perceptive difference from the unencrypted SSD:

Opening iTunes: 3 seconds

Opening Papers: 10 seconds

Opening VMWare Fusion—Loading Windows XP from suspend, 512MB RAM: 10 seconds

Opening Word—7 seconds

Opening PASW—9 seconds

Boot time was slower than the unencrypted SSD:

Boot time from when the PGP passphrase is typed in to the OS X login screen: 46 seconds.

Login time from inputing password to when the Dock appears: instantaneous

Time for start-up applications (Things, Skype, and Snapz Pro X) to load after inputing login password: 6 seconds.

However, when writing a large file to the disk it was painfully evident that the SSD was much slower in its encrypted state. As before, I copied the same 5.72 GB file:

Copying the same 5.73 GB bz2 file—3 minutes, 49 seconds seconds (three minutes slower than the unencrypted SSD, only a minute faster than the 7200 RPM hard drive).

Summary

Using PGP WDE 10, the SSD is still substantially faster than an encrypted 7200 RPM drive, especially for disk reads. For many tasks, the laptop still feels very fast and responsive (except when large files are written to disk). Therefore, there is value in going from an encrypted 7200 RPM drive to an encrypted SSD—the encrypted SSD is markedly faster.

However, it’s clear that the encrypted SSD is much slower than in its unencrypted form (by as much as two thirds, going by the overall Xbench score). By analogy, encumbering the SSD with FDE is like harnessing a champion racehorse to a plow. However, if you are interested in FDE, security is probably more important to you than raw speed anyway.

Update May 18, 2010:

The above tests show performance before and after encryption for the SSD, but not for the 7200 RPM drive. Robert Silvers, of Photomosaic.com, kindly provided these test results of his Seagate Momentous 7200 RPM drive before and after encrypting with PGP:

Without FDE:

Results 41.56
System Info
Xbench Version 1.3
System Version 10.6.3 (10D2094)
Physical RAM 4096 MB
Model MacBookPro6,1
Drive Type ST9500420ASG
Disk Test 41.56
Sequential 109.91
Uncached Write 121.18 74.40 MB/sec [4K blocks]
Uncached Write 130.87 74.05 MB/sec [256K blocks]
Uncached Read 73.57 21.53 MB/sec [4K blocks]
Uncached Read 144.78 72.77 MB/sec [256K blocks]
Random 25.62
Uncached Write 7.78 0.82 MB/sec [4K blocks]
Uncached Write 139.43 44.64 MB/sec [256K blocks]
Uncached Read 79.93 0.57 MB/sec [4K blocks]
Uncached Read 126.19 23.41 MB/sec [256K blocks]

Results 43.85
Disk Test 43.85
Sequential 58.90
Uncached Write 69.96 42.96 MB/sec [4K blocks] (42% decrease)
Uncached Write 56.13 31.76 MB/sec [256K blocks] (57% decrease)
Uncached Read 47.55 13.92 MB/sec [4K blocks] (35% decrease)
Uncached Read 67.69 34.02 MB/sec [256K blocks] (56% decrease)
Random 34.93
Uncached Write 12.67 1.34 MB/sec [4K blocks] (63% increase)
Uncached Write 93.32 29.87 MB/sec [256K blocks] (33% decrease)
Uncached Read 80.85 0.57 MB/sec [4K blocks] (0% change)
Uncached Read 80.05 14.85 MB/sec [256K blocks] (37% decrease)


About a 46% average loss in performance for 256K blocks.

And here are the results of the same drive using CheckPoint FDE 3.3 for Mac:

Disk Test 41.89
Sequential 53.51
Uncached Write 65.65 40.31 MB/sec [4K blocks]
Uncached Write 43.13 24.40 MB/sec [256K blocks]
Uncached Read 38.09 11.15 MB/sec [4K blocks]
Uncached Read 99.15 49.83 MB/sec [256K blocks]
Random 34.42
Uncached Write 11.57 1.22 MB/sec [4K blocks]
Uncached Write 136.74 43.78 MB/sec [256K blocks]
Uncached Read 82.63 0.59 MB/sec [4K blocks]
Uncached Read 96.35 17.88 MB/sec [256K blocks]

The results overall are slightly slower than those for PGP.

I have now officially started work as a full-time employee of Brigham Young University. This week I attended the university’s annual conferences, and it has me even more excited to be here. BYU is a special place.

This fall I will research full time (no teaching), but I will participate in ISYS 571 “Academic Research in IS”, the first part of BYU’s PhD preparation program. This class, taught by Dr. Paul Lowry, is essentially a first-year PhD seminar. It’ll be fun this fall to review the fundamental concepts of science, research design, and theory building.

]]> http://anthonyvance.com/blog/academics/at-byu/feed/ 0 http://anthonyvance.com/blog/forensics/iphone-encryption-follow-up/ http://anthonyvance.com/blog/forensics/iphone-encryption-follow-up/#comments Sat, 25 Jul 2009 05:09:15 +0000 Tony http://anthonyvance.com/blog/?p=593 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.

HICSS EndNote style

Update: Well, that didn’t take long. Two hours later and this post is the top hit when entering “hicss endnote style” into Google. It’s amazing how encompassing Google is.

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.]

Passphrases

Passphrases may not be an ideal security solution, but they are more secure and easier to remember and type than typical passwords. The fact is, passwords are the most prevalent form of authentication and they are not going away soon. Passphrases, then, usefully provide a more secure, easy-to-use alternative.

A friend of mine, Dr. Mark Keith of Arizona State University, demonstrated in a scientific study that passphrases are more secure and easier to remember than typical passwords. First, he showed that because the average person’s vocabulary consists of 3,000 words (a low estimate), a five-word passphrase is stronger than an 8-letter password using alphanumeric and special characters (3000^5 > 95^8).

He also showed that passphrases, although longer than passwords, are easier to remember and easier to use than passwords. The key is writing passphrases in standard written English, or what Keith et al. call “word processing mode” (WPM). Passphrases written in this way (like the passphrase above) are not only easier to remember, but they are also significantly easier to type and result in less login mistakes.

SSH Public Key Authentication

This one is more esoteric, but for a server administrator, SSH public key authentication is the model of security through simplicity. Rather than having to remember a password to various servers, a pair of public/private key files can be used to authenticate users instantaneously. Additionally, if a SSH public key is used in place of a password, password-guessing attacks cannot be used.

Automatic Backup

Backup is not typically thought of as a security measure, but it is probably the most important means to protect data from threats, malicious or accidental. The best way to back up data is also the simplest: routinely backing up data using automatic backup software. My favorite offline backup solution is Time Machine, which seamlessly backs up everything in the background, without any user involvement. Automatic backups is probably one of the simplest measures on this list, but also likely yields the most security for data.

Some solutions—aside from the initial expense in time and money to set them up—require virtually no compromise in convenience. In fact, some may even make tasks more efficient or add functionality. Below are three examples.

Password Manager

Passwords are not elegant. To be worth anything they must be hard to guess, which usually makes them hard to remember. To make matters worse, users are often required to change their passwords on a regular basis, like every 90 days.

But the Web is the worst part. A typical user might have 15-30 user accounts that each require a password. Perniciously, most users soon tire of mentally maintaining a portfolio of unique passwords and relent to using the same password for every web site account. It has been said that the easiest way to steal passwords is to create an online service that requires a password. Whatever password a new user submits is most likely the same password for a dozen other online services.

The way to stop this wheel of pain is to use a password manager. A password manager is software that securely stores all of your passwords. Instead of having to remember 30 or more passwords, with a password manager you only need to know one—the password that unlocks the password manager.

Because so many passwords people must remember are for web sites, the best password managers integrate with web browsers. Using a password manager, logging into a website requires no thought—a simple keystroke retrieves the password from the password safe and fills in the username and password fields. When creating a new account at a website, the password manager generates a password for you so you don’t have to waste any thought coming up with a unique, unguessable password.

My favorite password manager is 1Password for OS X. It has saved me a lot of time and grief. Life is too short to manage passwords.

Full Disk Encryption

Another elegant security solution is disk encryption, which encrypts part or all of a hard disk. It is probably the most transparent security solution on this list because aside from entering in a password, the user is unaware that data is encrypted—there is almost no perceptible slow-down in performance. And, once encrypted, you don’t have to worry about losing your hard drive or protecting certain documents. All of your data are protected all of the time. I currently use PGP Desktop 9.10 for Mac.

VPN

I’ve done a lot of traveling in the last few months and so have used a lot of public Internet access points at airports, hotels, and other locations. Public Internet access points are not always securely configured. In some hotels for example, it is possible to sniff or eavesdrop on the Internet traffic of other guests at the hotel accessing the Internet. This is an easy way to collect passwords and other information.

One elegant solution to this problem is a VPN, or Virtual Private Network. The purpose of a VPN is to create a secure connection through an untrusted network to a trusted one. For example, my VPN creates a secure, encrypted connection to Georgia State University, no matter where I am in the world. All my traffic first is sent to GSU’s network, which I trust, and from there it continues unencrypted to sites I wish to access.

A VPN is elegant because once the VPN connection is established, all traffic is encrypted seamlessly in the background. You can access the Internet as you normally would, but now all of your Internet traffic is encrypted and safe from eavesdroppers.

My favorite VPN client is Shimo. Not only does it support a wide variety of VPN types, it is dead simple. Creating a VPN connection, even with CISCO VPN’s, only takes one button click. Plus, if I suspend my laptop while a VPN connection is active Shimo will automatically create a new VPN connection when the laptop wakes.

It turns out that you can’t. But you can tunnel RSYNC over SSH which works like a charm. This tip is posted in numerous places online, but my SSH setup at home is slightly different, so I have to modify the SSH option as follows:

rsync --human-readable --partial --progress --rsh="ssh -l username -p 2012"
domain.name:/path/to/file .

This just points out again how great a program SSH is. Its uses are truly multitudinous. It’s like the swiss army knife of UNIX commands.