Hacker News Reader

Comment by CGamesPlay | Hacker News Reader

Probably useful to mention this in the comments here: this works for the 5c, but not the 6 and beyond, due to the addition of the Secure Enclave.

View on HN

So the secure enclave must have an embedded flash inside the processor that includes the pin code attempt counter -- meaning that writing to the external flash would not happen at all right?

From what Apple's released on how iPhone security works [1], it sounds like such keys are still written to external flash, just in a much more low-level way. So there may be a theoretical way to do this attack on a more recent iphone, but you'd have to do a lot more reverse engineering to figure out a few layers of undocumented proprietary protocols.

[1] https://www.apple.com/business/docs/iOS_Security_Guide.pdf

From skimming the paper, :

"Each Secure Enclave is provisioned during fabrication with its own UID (Unique ID) that is not accessible to other parts of the system and is not known to Apple. When the device starts up, an ephemeral key is created, entangled with its UID, and used to encrypt the Secure Enclave’s portion of the device’s memory space.

Additionally, data that is saved to the file system by the Secure Enclave is encrypted with a key entangled with the UID and an anti-replay counter. "

This sounds like the secure enclave chip has a secret key, and all of its uses of external memory are encrypted using said key. This sounds like one would either need to break the crypto system itself, or compromise the secure enclave co-processor.

How would one provision a secure enclave at fabrication time? What does that even mean?

Most likely it's a fuse type thing. It literally is a one time programmable fuse that is set by some subroutine. Basically you execute that function and bam you get back some key that says that it worked. You try to execute again and the fuses have already been set and the key is the same. Many ICs have built in one time programmable memories or fuses to be used during provisioning. Such as to set a MAC address on a Ethernet chip or wifi chip. It's literally burned into the chip in the factory and cannot be changed. It's a one time thing and does not change after reboot or anything.

In chip manufacturing, there's a way to make a "random" pattern on a chip, unknown even to the manufacturer. So a part of the SoC is random, but can be read by other parts. That becomes the random ID.

Imagine it like taking that piece of paper to give lottery numbers, throwing a couple darts on it, and then using that as the ID. Except the dart throwing happens in a way where you can't actually control/see the result during manufacturing.

There's a term for this that eludes me.

I'm curious what this process would be. My understanding was they'd typically have a small section of write-once fuses/PROM, and then some final process step to permanently program an ID into that area. That would mean the process to do so could possibly be recorded (or compromised), so I'm interested if there's a fabrication technique to reliably create random ROM sections.

Do you have any more info?

https://en.m.wikipedia.org/wiki/Physical_unclonable_function it's called a physically unclonable function.

The page is a bit obtuse, honestly I might have misunderstood a part of it.

Stochastic process perhaps?

I kind of doubt they would use some process like this for the iPhone, they probably program it in to avoid ID collisions. Yea I'm also curious if there is some name for this scheme where it generates some random pattern, I haven't heard of it myself and I previously worked in the semiconductor device world. Not saying it doesn't exist, just haven't heard of it. There are plenty of random sources that are used to generate a random bit such as thermal noise or clock jitter etc, but that is a single bit that you would then need a circuit to read that bit over and over to generate a random string like a UUID, and you would need some sort of statistics that would prove that that UUID that you generate over a finite time (probably a few milliseconds) is not highly self-correlated.

The UID is 256-bit. With a proper random number generator you don't do anything additional to avoid collisions. Hardware random number generators are standard for crypto processors like the secure enclave and there are standard tests used to test the output of a RNG for problems like the one you're talking about (e.g. the NIST test suite).

The basic issue with using an external memory is that you simply become a man in the middle and control what is happening the whole way. There is not some sort of magic "more low level way" available on flash ICs.. The flash device on any apple device can be fully emulated either by an FPGA or a special high speed setup that still has the flash IC attached to it. When the magic command comes in to write the value to store how many attempts have occurred you respond as if the value was written correctly but then don't actually write it. Assuming the block of memory that is being written is encoded with a particular checksum that is also including some checksum that was calculated on the local copy inside the secure enclave then the main problem we would run into would be that the secure enclave may store some value like that checksum in its memory locally in flash. So when you go to attempt the next passcode it reads the previous checksum from the external nand flash IC and sees that you are using the correct checksum, but the value you stored for the attempt counter does not sum up properly. So basically you would also need to reverse engineer their checksum process to screw up some other value to make the checksum add up properly. The alternative as I suggested is to just store the actual attempt counter in the internal flash of the main A8 or whatever processor in the secure enclave. That way it forces the hacker to have to be a much more sophisticated user and take more risk to damage the chip to basically completely remove the chip, FIB it to cut down to the proper layer--if apple was smart they would bury the flash for the secure enclave under a bunch of important metal routing that would be super difficult to get around, then even a super sophisticated nation state actor would be highly challenged to do this modification.. Desoldering the flash IC and soldering in an interposer that has an FPC that connects to an FPGA that is purpose built for this setup could be done in like 30 mins or less. So if apple wants to make this scheme difficult to do, they should embed it deep inside the main processor and not rely upon the external flash at all.

Great description. You remind me of Joe Grand (L0pht Heavy Industries), Joe FitzPatrick (NSAPlayset), Hector Martin (fail0verflow) and Micah Scott (scanlime). All are brilliant Electric Engineers with a security background. Do you have an EE degree too? Anyways, thanks for the detailed explanation. :)

Ha thanks--quite a nice set of compliments there! Yea, you figured me out, I'm an EE who grew up as a wannabe hacker.. :-)

No, it does not rely on "undocumented proprietary protocols". The document you link clearly states that external flash contents are encrypted with a key that resides in the secure enclave, entangled with the user passcode. Furthermore the secure enclave has guards against brute forcing the passcode with an escalating time delay.

What's different in more recent phones (>=A7 processor) is the secure enclave enforces that time delay, as opposed to the operating system, which is the reason why this brute force attack works on the 5c/A6.

There's a feature provided by a fair number of flash chips called a "Replay Protected Memory Block" or RPMB. The idea is that you provision your flash chip with a secret shared only with the secure enclave (presumably stored on fuses in the secure enclave) and then you can use that key to read and write a small block of storage on the flash chip.

It's "replay protected" because the crypto prevents an attacker from replaying old contents of the chip back to the secure element.

If Intel ever stopped mucking around with SGX licensing policy, SGX + RPMB would be a really nice combination on laptops.

This is contradicted within the linked research:

>The same approach could be applied to the newer models of iPhone. The same type of LGA60 NAND chips are used up to the iPhone 6 Plus. Any attacker with sufficient technical skills could repeat the experiments. Newer iPhones will require more sophisticated equipment and FPGA test board

The iOS security guide would appear to contradict this:

https://www.apple.com/business/docs/iOS_Security_Guide.pdf

> On devices with an A7 or later A-series processor, the delays are enforced by the Secure Enclave. If the device is restarted during a timed delay, the delay is still enforced, with the timer starting over for the current period.

This is not super specific, but would imply that the secure enclave has its own storage.

They are wrong. The A7 added a hardware passcode attempt counter that would defeat their method.[1]

And that's not all. With the introduction of Touch ID, Apple has shifted to 6 digit passcodes as the standard. The authors note that their method would not work so well, even if they had infinite time:

"Given six attempts per each rewrite this method would require at most 1667 rewrites to find a 4-digit passcode. For a 6-digit passcode it would require over 160 thousand rewrites and will very likely damage the Flash memory storage."

If you want to decrypt the modern iPhone you'd probably have to try to poke inside of the secure enclave with an SEM or something. And then you're getting into the realm of hardware defenses against this kind of intrusion, like physical self-destruction when probed.. not sure if Apple's doing anything there but it's crazy stuff.

[1] https://www.apple.com/business/docs/iOS_Security_Guide.pdf (page 12)

You dont need to constantly rewrite flash, you can emulate it with fpga. In-Circuit eprom emulation is old as a rock.

That's a fair point, but it's not the method they used, and even if it were feasible to implement the secure enclave passcode attempt counter would still render it ineffective.

The secure enclave was added in the 5S

Reply on news.ycombinator.com