Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The bumpy road towards iPhone 5c NAND mirroring

arxiv.org

Post reply on HN
Print view View original

51–60 of 69 posts

Re: The bumpy road towards iPhone 5c NAND mirroring

#51

Post by [deleted] »

dogma1138 wrote: post #16
gizmo686 wrote: post #12

Earlier quoted context omitted.

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.

Well for the FBI NAND mirroring might not be a solution. In the article the author mentions that this technique can effectively damage the flash memory because you can get effectively into a state where you are causing wear due to writes. In theory you can scale this up and copy the contents of memory into an FPGA which emulates NAND (both logically and physically) or just hold multiple copies on different chips but…

[deleted]

Re: The bumpy road towards iPhone 5c NAND mirroring

#54

Post by rtpg »

firebones wrote: post #41
gizmo686 wrote: post #38

Earlier quoted context omitted.

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?

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.

Re: The bumpy road towards iPhone 5c NAND mirroring

#55

Post by rasz_pl »

abalone wrote: post #29
sigmar wrote: post #22

Earlier quoted context omitted.

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

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…

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

Re: The bumpy road towards iPhone 5c NAND mirroring

#56

Post by shabble »

rtpg wrote: post #54
firebones wrote: post #41

Earlier quoted context omitted.

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

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…

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?

Re: The bumpy road towards iPhone 5c NAND mirroring

#57

Post by Declanomous »

rtpg wrote: post #54
firebones wrote: post #41

Earlier quoted context omitted.

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

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…

Stochastic process perhaps?

Re: The bumpy road towards iPhone 5c NAND mirroring

#58

Post by nickpsecurity »

lisper wrote: post #44
tikhonj wrote: post #36

Earlier quoted context omitted.

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.

Im not saying it has to be done a certain way. Im saying my college required the paper to have margins, a title, etc. Im surprised most of them dont require a date of any kind on the document sonewhere. They could write the year in Size 8 in upper-right corner in light grey and that would be better than many in my collection. ;)

Re: The bumpy road towards iPhone 5c NAND mirroring

#59

Post by xt00 »

rtpg wrote: post #54
firebones wrote: post #41

Earlier quoted context omitted.

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

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…

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.

Re: The bumpy road towards iPhone 5c NAND mirroring

#60

Post by opello »

dogma1138 wrote: post #16
gizmo686 wrote: post #12

Earlier quoted context omitted.

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.

Well for the FBI NAND mirroring might not be a solution. In the article the author mentions that this technique can effectively damage the flash memory because you can get effectively into a state where you are causing wear due to writes. In theory you can scale this up and copy the contents of memory into an FPGA which emulates NAND (both logically and physically) or just hold multiple copies on different chips but…

> In theory you can scale this up and copy the contents of memory into an FPGA ...

In practice it would have to be in external memory (DDR, flash, etc.) that the FPGA would use to back transactions because FPGAs don't have 32GB of memory capacity. Problems then become meeting bus timings that may very well be tuned for the PCB layout.

Post reply on HN