US judge in California directs Apple to help FBI break into cell phone | Hacker News Reader

US judge in California directs Apple to help FBI break into cell phone

twitter.com

31 pointsJarred14 comments

It's important to realize that Apple cannot be seen as voluntarily handing over data. Sometimes this is as simple as "Yes we can help, but please force us to". That saves them from PR damage and potential liability.

This was also the basis for several of the warrantless phone collection cases, according to the leaks. One or more of the major telcos was eager to cooperate, but politely asked that they be "forced" to. The FISA court was happy to oblige.

They'll have to go to the Supreme Court in order to to appear not to be volunteering.

I think there are bigger repercussions than just PR and potential liability. If they do it once, then they will be asked again to. This also means that "hackers" can use that same method to get around the security.

Apparently the judge is ordering Apple to essentially disable all features that prevent or slow down brute-forcing, updates and quotes here: https://www.techdirt.com/articles/20160216/17393733617/no-ju...

Why don't the investigators review video of Farook's work to see if they can make out the pattern of his phone pin?

Unless its running iOS 7 or earlier, good luck with that one.

Why? I'm no particular expert on iOS internals but ultimately the data on the disk is encrypted with a pretty weak (often just 4 digit) key. Shouldn't that be pretty trivial to brute force?

Is there something I'm missing?

Page 11 of the iOS Security Guide should help explain a lot: https://www.apple.com/business/docs/iOS_Security_Guide.pdf

The user passcode is combined with the UID Key embedded in the Secure Enclave to create an encryption key used for the filesystem (Apple calls this "tangling"). That means you can only crack the key for the filesystem as fast as the Secure Enclave lets you crack it, since every guess is composed of Passcode+Secure_Enclave_Access.

And boy, does the Secure Enclave not like to go fast. Every incorrect guess gets fed back to the SE and it gets slower and slower until you can only try 1 guess an hour or, if the user set it, total device erasure after a certain number of failed attempts. See the table on page 12 of the iOS Security Guide.

This is why disk crypto on iOS is far better than comparable alternatives on Android. Having a hardware crypto chip with a key embedded at manufacture time on every single phone they produce is something that only Apple can really do.

The top poster is correct: in iOS7 and prior there were many default apps that did not use the Data Protection API (aka file encryption). Post-iOS7, most default apps and many 3rd party apps have defaulted to using Data Protection. This means you get very little if you're trying to forensically acquire a disk, as the FBI is, without access to the phone passcode.

Sidenote: My company released a crypto abstraction library for interacting with the Secure Enclave last week. It lets mobile app developers instruct the SE to create an ECC private key on their behalf and then sign things with it. This way, you can make passwordless authentication and device binding on iOS possible for your app, potentially improving UX, increasing security, and simplifying your server-side code. Check it out at https://www.passwordlessapps.com -- we couldn't have made these kinds of security guarantees without the Secure Enclave. We'll eventually support Android, but we'll have to give up some security benefits to do so.

EDIT: I've been informed the device in question is an iPhone 5C (no TouchID == no Secure Enclave). This should make things a lot simpler for the FBI. Now I actually do wonder why they're having trouble?

That's good info, but the device in question is an iPhone 5C. The 5C uses the A6 SoC, which has no secure enclave. I'm not 100% sure what security features it does have, but it sounds as if Apple could load a custom version of iOS that lacks the erasure feature. Even then, decryption is not certain. Files are encrypted with a combination of the passcode and the SoC's unique key.[1] That means unlock attempts have to be done on the phone hardware. If you imaged the device for parallel cracking, you'd need to figure out the 256-bit AES key in addition to the passcode.

Still, a 4-digit PIN would certainly be broken. An 8-digit PIN would probably take months to crack (100ms * 10^8 == 116 days). An actual passphrase? Good luck.

1. See the Encryption and Data Protection section of Apple's 2014 iOS security guide, starting on page 9 of https://s3.amazonaws.com/s3.documentcloud.org/documents/1302...

Oh interesting! I didn't realize that iPhones had this kind of secure hardware. It still seems to me that it might be possible to bypass this though ya definitely much harder. Reading the linked doc.

Thanks!

Can you break the Secure Enclave physically and read out the key embedded?

I think you have it right. They are looking for a way to try PINs until they are in without the feature being invoked that wipes the phone after X incorrect PIN entries.

I can't think of a technical reason why this shouldn't be possible.

IOS 8 does not allow a 4 digit key IIRC. And it has rate limiting against brute force enumeration.

iOS 8 and 9 allow four digit passcodes. I've got one myself.

Reply on news.ycombinator.com