Hacker News Reader

Comment by Sanddancer | Hacker News Reader

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

View on HN

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.. :-)

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.

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).

Stochastic process perhaps?

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.

Reply on news.ycombinator.com