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 Encla…
How would one provision a secure enclave at fabrication time? What does that even mean?
I'm surprised the post was not unflagged. HN team wanna ring in?
When posts say "flagged", that means they crossed some threshold of user flags. The moderators didn't flag it.
Though it would never happen, would love an investigative piece that followed up on who flagged it, their background, why they flagged it, and what they have to say now.
I'm sure all the "experts" who were so vocal about how wrong you were will speak up now and admit they were wrong. Happens all the time around here. ;)
This is because many people don't care and/or switch to autopilot and double-down on their wrong point instead of being able to switch to a position where they can rationalize alternative answers and admit they are wrong. It is quite frustrating to deal with these people[0].
Oh I find it so aggravating when I don't have a date. It seems like most academic papers I found on interesting security and programming stuff didn't have dates. I had to pull them off Citeseerx or the school's site. You'd think it would be a requirement in the style guides given importance of when something was published for relevance or context. I've never heard an explanation for why this isn't so. I do appreciate…
Conference papers include a copyright notice with the name (and year) of the conference. Papers that aren't published at conferences (preprints, technical reports... etc) don't have any standard format for this. Sometimes (especially for preprints) it's left out in expectation of adding the copyright notice in a future version, sometimes it's left out because the document is in a very preliminary stage and hasn't bee…
You don't need a standard format. You just need to put "DRAFT - [today's date]" somewhere in the document.
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
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.
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 Encla…
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.
It would have cost the agencies a lot more though (contracting fees), I highly doubt they'd have the technical capabilities to handle this. But it just goes to show that they didn't really reach out and were simply using it as a means to push their backdoor agenda. :(
What worse is that they (or at least Comey) explicitly said that NAND mirroring does not work. When he was testifying before Congress, we was asked by several Congress people about NAND mirroring and (if I remember correctly) said that the technical experts had looked into it. This is either gross incompetence or outright perjury.
Yea they definitely just wanted the GovtOS from Apple. Basically would allow them to hack somebody's phone without them knowing. Whereas requiring them to disassemble the phone it would be more prone to error and take more time to do.
A note -- if you're linking to arXiv, it's better to link to the abstract ( https://arxiv.org/abs/1609.04327 ) rather than directly to the PDF. From the abstract, one can easily click through to the PDF; not so the reverse. And the abstract allows one to do things like see different versions of the paper, search for other things by the same authors, etc. Thank you!
You can also see when the paper was submitted.
The first four digits of arXiv papers links are the year and month of submission (to the arXiv). Just from this link I can tell that this was submitted in September 2016.
No one with the slightest technical background thought the phone was uncrackable, maybe not directly by the FBI but by pretty much any 3rd party contractor that does even basic flash data recovery. The FBI was looking to set a precedent in order to be able to gain easy access to phones that could be also used by law enforcement, a local sheriff's department is less likely to be able to contract it out for every case…
Can you explain how the "USB DMA exploit" works? Also how would you run this exploit on the phone if you were locked out of it?
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.
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?
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.