Hacker News Reader

Comment by caymanjim | Hacker News Reader

I'm too lazy to find a link for it, but last time I read about Cellebrite, they were cloning the data and simply trying unlock codes in sequence until one worked. They could restore the cloned data before each try, or possibly do it on custom hardware or an emulator, and start with a fresh copy each time, so they never triggered "erase after 10 failures". It's a pretty straightforward approach, but it doesn't scale well. Works for targeted cracking of high-value targets.

View on HN

This is not true. You cannot just clone the data and run passcodes against it, because the data is not encrypted by your passcode. Instead, each file on iOS 11 is encrypted with a different AES 256-bit key, and cracking even one 256-bit key through exhaustive search is thought to be out of reach of humankind (https://security.stackexchange.com/questions/6141/amount-of-...). The file keys are wrapped by, among other things, the device's Unique ID, a 256-bit key generated by the Secure Enclave, and accessible only to the Secure Enclave, not any other hardware or software running on an iOS device.

In the end, the only options are: bruteforcing passcodes on the original device while attempting to trick the device into allowing more than 10 failures, or prying open the Secure Enclave to obtain the Unique ID — both options a lot more complicated than just cloning the data and trying passcodes on it.

or prying open the Secure Enclave to obtain the Unique ID

People have been cracking secure coprocessors of the type used in payment cards, TPMs, and the like for a long time, dare I say even those which were designed to a higher level of security than Apple's. The fact that there is an entire phone attached to it doesn't make much of a difference, but the technology behind this (FIB, microprobing, etc.) has been steadily dropping in price and increasing in availability for a long time.

Fwiw, Apple has a $100k bounty on this type of exploit (pulling secrets from the secure enclave).

But Cellebrite apparently makes millions off of its service, so the economic incentives are still on their side.

I understand what you're saying here: why share the fact they've broken the SE for $100k when they can keep making millions.

But if they cracked the SE, and kept that fact to themselves, they would be making even more money because every government on the planet would be coming to them. This is provided they kept it to themselves.

It would mean a significant spike in the number of phones being cracked and people being arrested/charged/hung/etc. This would be a statistic that would jump off the charts and trigger Apple to essentially develop a solution straight away.

The only way this would work is if they had cracked the SE and are doing an Enigma: keeping it top secret and only cracking very high profile targets with the technology, which I guess is possible.

keeping it top secret and only cracking very high profile targets with the technology

Of course. The "big guns" are not to be used lightly, as the saying goes.

> This would be a statistic that would jump off the charts and trigger Apple to essentially develop a solution straight away.

How, though? If the only information Apple has is that their SE scheme is broken, how is that supposed to help them develop a solution?

The risky.biz podcast proposed a solution, half seriously and half in jest, offer 50 million for the bug bounty. It would destroy the working relationships and trust of the group of people that is required to come up with multi stage exploits, and apple has the cash to do that once or twice.

This argument gets made really often. Consider that bug bounties and blackhat talks disclosing bugs both exist and are extremely popular. Not everyone wants to be a drug dealer. Cellebrite hardly has a monopoly on hardware research.

I'm sure companies, like the one in the article, will pay substantially more for them.

> but the technology behind this (FIB, microprobing, etc.) has been steadily dropping in price

Isn't it more of a cat and mouse? The defences also drop in price and increase in availability?

As usual, old tech is becomes vulnerable. Hopefully most people will get the chance to upgrade to the latest and greatest before attacks get too easy and destroy the old device.

I wonder what Chris Tarnovsky is up to these days...

I think he got the the idea right. Yes, you need the secret key burned into the CPU to decrypt anything, and yes, you can't easily extract the keys. but his claim is that by fully restoring the flash storage (presumably where the retry counter is stored), it's possible to bypass the "erase data after 10 failed attempts" policy by constantly resetting the counter back to its original state. It might take a while (you might have to go through the boot process each time, but for a 6 digit pin and 30 seconds each attempt, it's still less than a year.

That doesn’t work as well because the counter is kept in the Secure Enclave so it’s not part of the flash contents. Also the exponential delay in attempts is enforced by the enclave.

Previous iOS versions used to have some small window where you could race and power off after trying a passcode but before the enclave had incremented the counter, but that bug was fixed long ago. Maybe there are others unknown bugs of similar kind

>That doesn’t work as well because the counter is kept in the Secure Enclave so it’s not part of the flash contents

I skimmed the secure enclave documentation at https://www.apple.com/business/docs/iOS_Security_Guide.pdf (page 5, 14, 15), and I can't find anything to confirm that.

"On devices with Secure Enclave, the delays are enforced by the Secure Enclave coprocessor." Page 15

It was also confirmed explicitly during the Q&A at the blackhat talk in 2016, which I believe is on YouTube.

>It was also confirmed explicitly during the Q&A at the blackhat talk in 2016, which I believe is on YouTube.

doesn't look like it. https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-De...

That’s not the apple talk. Apple gave a talk specifically about hardware security in the iPhone.

Edit: this one. https://youtu.be/BLGFriOKz6U

Edit 2: the question was asked at 47:20

It makes the most sense that it's in the Secure Enclave. Once you have control of the counter, you can run through the passphrase space in no time.

Only if the pass’phrase’ is a short numeric code. iOS also allows a normal password.

> constantly resetting the counter back to its original state

I wouldn't rule out some kind of electrical glitching attack.

That’s essentially the method used to bypass smart card processors.

>In the end, the only options are: bruteforcing passcodes on the original device while attempting to trick the device into allowing more than 10 failures, or prying open the Secure Enclave to obtain the Unique ID — both options a lot more complicated than just cloning the data and trying passcodes on it.

If I'm understanding correctly, obtaining the unique ID would simply mean the strength of the AES key becomes the point of failure? (So a strong password means FBI doesn't get in)

You will still be trusting Apple to securely use your entire password rather than always truncating it to, say, 3 characters, and/or "backing up" some or all of it to their cloud - things that are rather difficult to independently verify.

That’s not quite what the person above said. They said that the data would be pulled off the phone - in its encrypted form - then restored to make the phone forget the number of attempts.

I think the Secure Enclave has independent built-in mechanisms for keeping track of the number of times things have happened though.

How does the Secure Enclave store all of those AES keys? I am guessing that the keys aren't random and are regenerated in order to do decryption, so "all" an attacker needs to do is break the key generation process, not the keys themselves.

Is there no chance that Apple and/or the FBI have the list of phone serial numbers and matching AES key?

(If that sounds sarcastic it's not meant to, genuine question as I don't know much a about this stuff!).

The key that is mentioned is only part of what you need to decrypt the data. The point of the secret key is to prevent an offline attack; you need to get the device to combine passwords or codes with the secret key to get the encryption key. That way the device can enforce speed nd maximum number of attempts.

Doesn't scale well? Are you assuming you cannot run this parallel?

As far as I can remember, that was the proof of concept which ended up emerging for the 5C crack a few years ago, and I don’t see any reason the methods would’ve changed.

The iPhone 5C could be attacked this way because it didn't contain the Secure Enclave that shipped as part of the A7 chip. Attacks on devices with the A7 (or newer chips) would be novel.

Reply on news.ycombinator.com