Vote 2020 graphic
Everything you need to know about and expect during
the most important election of our lifetimes

Apple's Got a Huge Waiting List of Cops Who Need iPhones Cracked

Illustration for article titled Apples Got a Huge Waiting List of Cops Who Need iPhones Cracked

It's no secret that the police aren't very good at breaking into encrypted iPhones, but they've been asking Apple for help. A lot of help. According to reports by CNET the government asks for so much help that the "please decrypt this iPhone for me" waiting list is at least seven weeks long.

Advertisement

Law enforcement is getting increasingly fond of performing forensic analysis on mobile devices that were involved in crimes, but pulling it off ain't easy. According to a search warrant affidavit CNET dug up, an ATF agent spent three months last summer "[attempting] to locate a local, state, or federal law enforcement agency with the forensic capabilities to unlock [an iPhone 4s]" before he turned to Apple. But the turnaround was far from zippy and took a couple months.

Advertisement

It's not impossible to brute force into an encrypted iPhone. If the pin is just four or five digits, it can be done in under an hour with specialized tools, but passcodes nine or ten digits long take years. Apple's got a better trick, though. What it is isn't exactly clear, but it's in high demand. Seven weeks is better than nothing, but you can bet that list is only going to keep getting longer unless Apple shares its goodies. [CNET]

Share This Story

Get our newsletter

DISCUSSION

kinglycitrus
KEEP IT CLEAN™

Okay, I don't know how these stories keep popping up, but as far as I can tell, they're almost completely false. Let me state this as clearly as I can: The iPhone encrypts all data, but unless an iOS application uses Apple's "Data Protection" API, its data is essentially as secure as if it were stored in plain text. The only built-in iOS app that utilizes this functionality is Mail.app. Thus: your text messages, call logs, browsing history, photos, notes, calendars, and voice memos are trivial to decrypt. This is because iOS stores the keys to the non-Data-Protection portions of the filesystem in plaintext. There is a reason for the encryption, however. When you perform a remote or on-device ("reset all settings") wipe, these keys are removed completely, rendering the whole system inaccessible. The point of the hardware encryption is to enable effective, quick remote wipe- very important for businesses.

Most third-party applications also do not utilize the API either, because A) implementing it takes a bit of work, and most developers see it as unnecessary because their users do not know or care and B) it has some drawbacks, including the fact that Data Protection-enabled portions of app storage cannot sync to iCloud. If an app does use the API, the security of the storage is still reliant on the strength of the user's password, as it is very easy to dump the iPhone's entire storage to disk and crack it off-device, per standard data forensics practice. There are limits on the cracking speed imposed by the iPhone's hardware encryption chip, but they can be circumvented in this fashion.

I'm an iPhone owner, by the way, which is why I bothered to actually research this information. Here's the best summary I've found, current as of iOS 5 and the iPhone 4S. If police departments are asking Apple to help them decrypt iPhones, it must be because they A) do not access to a computer forensics department, or B) cannot afford/have not purchased the readily-available forensics toolsets that have this functionality built in.

Android's encryption functionality, meanwhile, is a little better: if you have a phone running Android 4.0 or later (or a tablet running 3.0 or later), you can use the built-in encryption functionality, which is based on Linux's dm-crypt. It is entirely software-based encryption, so it relies entirely on the strength of your device password, which is limited by default to 16 characters. This app purports to be able to change the cryptfs password independently of the device password (and presumably, increase the 16-character limit to 64, but I'm not sure about that and don't have an Android device to test it with). Just like a computer utilizing dm-crypt, the encryption keys are stored in RAM on Android- meaning that if a competent forensics department gets ahold of a device while it is still running, it's pretty easy for them to get into the whole filesystem.