Security expert: iPhone password hack shows flawed security model

A recently revealed attack can open up the contents of an iPhone password …

News of a successful attack that almost instantly gives full access to an iPhone's password keychain made its way around the Web on Thursday after Germany's Fraunhofer Institute for Secure Information Technology revealed the exploit to IDG News Service. While the fact that hackers could access a device's keychain in such a short time certainly sounds alarming, the attack isn't entirely new, and is actually a product of Apple's "DRM approach" to security, one iOS security expert told Ars.

Fraunhofer SIT's exploit first relies on physical access to an iPhone, so an attacker has to get your iPhone away from you before digging in. In most cases like this, you would likely want to use Apple's (now free) remote wipe feature in order to protect your data, but remote wipe is easily thwarted by removing the device's SIM card. Any attacker sophisticated enough to decrypt the keychain will know this trick.

Once an attacker has your phone, he could use any of the commonly available jailbreaks to install an SSH server, install a keychain hacking script, and collect the decrypted password information.

Part of what makes the attack relatively trivial is that the cryptographic key used for the keychain is stored on the iPhone. Once a device is jailbroken, hackers can use iOS's built-in APIs to access and decrypt certain passwords—including those for network access and e-mail accounts—stored in the keychain. From there, passwords from VPN access or e-mail accounts can be further used to gain more passwords, or e-mail accounts can be used to request password resets for a number of online services.

But while Fraunhofer SIT's particular methods may be new, accessing the keychain and other encrypted information on a jailbroken iPhone has been possible for some time. iPhone forensics expert Jonathan Zdziarski told Ars that similar exploits have been around since about the time of the introduction of the iPhone 3G.

"Several dev teams have been able to easily deduce Apple's encryption keys for the keychain; it just hasn't been widely advertised," Zdziarski said. The "new" part of Fraunhofer SIT's attack, however, leverages Apple's APIs to access the keychain instead of other methods.

The real problem, according to Zdziarski, is that Apple hasn't yet fully implemented a truly secure environment for iOS. "Apple has—since introducing encryption—been relying on their DRM know-how, and just erasing the label that says 'DRM' and calling it 'security,'" he explained. "The problem with this is that DRM only makes things a little more difficult for hackers."

"Real security relies on the strength of the key, and the secrecy of the key," Zdziarski continued. "And as long as the keys are all stored on the iPhone and don't rely on a user password, they can easily be compromised."

Zdziarski said that he believes Apple is pushing to make the iPhone compliant with security standards set forth in Federal Information Processing Standard 140-2 (FIPS 140-2). When that happens, government and enterprise users can be less wary about iPhone security issues. "But at the end of the day," he said, "Apple will need to abandon their DRM approach if they want true security, as opposed to just some fancy marketing strategies."

94 Reader Comments

The Fraunhofer guys are spot on, but what has been reported by other sources by and large ignores the detail in their report, which is worth reading.

iOS 4 devices mark data objects as being in one of a variety of Data Protection classes (by metadata).

The passcodes and other info that the researches were able to read via this exploit is all data that is sitting in the "ProtectionNone" class. Their report confirms that data in the "AfterFirstUnlock" and "FullProtection" classes is still unreadable.

The issue is that far too much data and passwords are being put in the "ProtectionNone" class, both by Apple and 3rd Party Developers.

Basically the way it works is :

"FullProtection" is only able to be decrypted if the phone is currently unlocked"AfterFirstUnlock" is only able to be decrypted following a reboot , so long as the phone has been unlocked once ( and is likely specifically intended to counter this kind of approach demonstrated for accessing data , but clearly isn't being used enough )"ProtectionNone" is intended for items that need to be able to be decrypted while the phone is locked

If everything was in "AfterFirstUnlock" by default, you'd need to unlock your phone once after you rebooted it for it to get access to secure services like WiFi etc. That doesn't seem too onerous.

So in short, Apple's actually already has the mechanism in place to deal with this, its just they've been lazy or somewhat misguided about using it in their own applications and services as widely as perhaps they should ( as a user of the device, you can't opt in for forcing the above behaviour, nor can it be set by policy on the device globally ).

3rd party solutions for PIM data like Good and Sybase maintain their own encrypted containers to secure corporate email/contact/calendars and aren't impacted negatively by the issues illustrated by Fraunhofer.

Jailbreaking is always going to go around in circles with hackers - its just installing a root kit, and all mobile phones are vulnerable to that. Phone vendors will patch bugs and stop it for periods of time, but so long as the phone firmware trusts the USB cable, its going to be possible.

Apple can't even protect their customers from common thieves with their existing method.

If you do a remote wipe you lose ownership and any tracking ability. To me that's a really bad implementation that's likely a result of their security method. Why can't I keep ownership and remotely delete all the other data? Where it retains the lock and my ability to track it.

Actually I wouldn't want to lock it if I could delete my data if it's an iPad/touch

Why can't I keep ownership and remotely delete all the other data? Where it retains the lock and my ability to track it.

... and track it even if a new SIM is swapped in. If it's on a cellular network, it should be identifiable by serial number. Maybe that's too much to ask depending on how cellular networks operate, I don't know, but it would sure put a crimp in the value of a stolen phone.

Why can't I keep ownership and remotely delete all the other data? Where it retains the lock and my ability to track it.

... and track it even if a new SIM is swapped in. If it's on a cellular network, it should be identifiable by serial number. Maybe that's too much to ask depending on how cellular networks operate, I don't know, but it would sure put a crimp in the value of a stolen phone.

This is exactly what already happens. Every GSM handset is uniquely identifiable to the network by its IMEI. If your phone is stolen, then you can get that IMEI put on a blacklist so that it won't work on any network (don't know how geographically limited this is, though), and 'phone recycling' companies typically check this as well.

The Fraunhofer guys are spot on, but what has been reported by other sources by and large ignores the detail in their report, which is worth reading.

iOS 4 devices mark data objects as being in one of a variety of Data Protection classes (by metadata).

The passcodes and other info that the researches were able to read via this exploit is all data that is sitting in the "ProtectionNone" class. Their report confirms that data in the "AfterFirstUnlock" and "FullProtection" classes is still unreadable.

The issue is that far too much data and passwords are being put in the "ProtectionNone" class, both by Apple and 3rd Party Developers.

Basically the way it works is :

"FullProtection" is only able to be decrypted if the phone is currently unlocked"AfterFirstUnlock" is only able to be decrypted following a reboot , so long as the phone has been unlocked once ( and is likely specifically intended to counter this kind of approach demonstrated for accessing data , but clearly isn't being used enough )"ProtectionNone" is intended for items that need to be able to be decrypted while the phone is locked

If everything was in "AfterFirstUnlock" by default, you'd need to unlock your phone once after you rebooted it for it to get access to secure services like WiFi etc. That doesn't seem too onerous.

So in short, Apple's actually already has the mechanism in place to deal with this, its just they've been lazy or somewhat misguided about using it in their own applications and services as widely as perhaps they should ( as a user of the device, you can't opt in for forcing the above behaviour, nor can it be set by policy on the device globally ).

3rd party solutions for PIM data like Good and Sybase maintain their own encrypted containers to secure corporate email/contact/calendars and aren't impacted negatively by the issues illustrated by Fraunhofer.

Jailbreaking is always going to go around in circles with hackers - its just installing a root kit, and all mobile phones are vulnerable to that. Phone vendors will patch bugs and stop it for periods of time, but so long as the phone firmware trusts the USB cable, its going to be possible.

GREAT. Now THIS is a useful answer.It certainly sounds, based on what you have said, that this is NOT an issue of design, but of implementation, and that it could fairly easily be modified if Apple feels that is (perhaps optionally, for secure customers) worth the hassle.

Apple does market the iPhone as secure and it seems that due to the image of the company and the reverence the public holds if their CEO they are believed by the public. Added to this, in the early days at least one police security spokesman and a number if other news sites proclaimed the iPhone with it's browser the only secure way to do Internet banking. I didn't look into it but I guess I assumed it to be secure too. They really need to do all they can to make it as secure as they are portraying, but also they all need to educate the public that they need to secure their smartphone with all their valuable data, and not live in ignorance.

Even WM 6.5 allows you to take a call without unlocking the device (matter of fact the answer and end keys are the only two keys that function during a call as any other key brings you right to the login screen if your device is locked). Even if you try to plug the device into a usb port, you are still prompted for a password and the dvice shows up as not functional.

BTW using that Security Focus webbsite only shows 2 vulnerablilites for WM 6.5 so obviously security can be implimented and still retain functionality... having full device encryption that actually works is nice....