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

61–69 of 69 posts

Re: The bumpy road towards iPhone 5c NAND mirroring

#61

Post by abalone »

rasz_pl wrote: post #55
abalone wrote: post #29

Earlier quoted context omitted.

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.

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.

Re: The bumpy road towards iPhone 5c NAND mirroring

#62

Post by abalone »

Sanddancer wrote: post #21
xt00 wrote: post #10

Earlier quoted context omitted.

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

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.

Re: The bumpy road towards iPhone 5c NAND mirroring

#63

Post by rtpg »

shabble wrote: post #56
rtpg wrote: post #54

Earlier quoted context omitted.

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?

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.

Re: The bumpy road towards iPhone 5c NAND mirroring

#64

Post by dogma1138 »

gizmo686 wrote: post #39
dogma1138 wrote: post #16

Earlier quoted context omitted.

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…

Perhaps the FBI had a valid reason for not doing NAND mirror [0]. However, I maintain that it is incompetent for the FBI director to testify before congress on the case and not be prepared with a basic answer to why the most obvious technical answer would not work. Similarly, with him saying in a press conference that it would not work. Of course, the FBI director does not need to know this level of detail about ever…

[0] Although, I would argue, in cases where no alternative exists, if the FBI policies prevent NAND mirroring, they should be revisited. Even if it has the potential to be destructive, they would only be destroying otherwise unusable information.

Eh? no, destructive methods are a big no-no, this isn't a dichotomy.

The information ins't unusable, they can try force apple to unlock the phone, or wait until some one else comes that can do it without using a destructive method.

You can't destroy evidence because you can't do anything with it at the given time.

Re: The bumpy road towards iPhone 5c NAND mirroring

#65

Post by dogma1138 »

bogomipz wrote: post #49
dogma1138 wrote: post #11

Earlier quoted context omitted.

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?

Like any other DMA exploit through the USB host or any other DMA enabled data connector/port.

Cellebrite has a few of them I know of a few for MediaTek chipsets that work through the USB host and the camera connector.

This isn't any different than the DMA "skeleton keys" for PCs and Macs that work via firewire/thunderbolt/pcie/expresscard/PCMCIA etc.

Re: The bumpy road towards iPhone 5c NAND mirroring

#66

Post by serendipitous »

xt00 wrote: post #59
rtpg wrote: post #54

Earlier quoted context omitted.

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 gene…

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

Re: The bumpy road towards iPhone 5c NAND mirroring

#67

Post by colejohnson66 »

ramblenode wrote: post #30
Sniffnoy wrote: post #8

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!

For those who don't have a PDF viewer in their browser it's also quite annoying to have to download the paper just to see what it's about.

What modern browsers don't support PDF? (besides lynx)

Re: The bumpy road towards iPhone 5c NAND mirroring

#68

Post by Relys »

xt00 wrote: post #45
Sanddancer wrote: post #21

Earlier quoted context omitted.

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…

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

Re: The bumpy road towards iPhone 5c NAND mirroring

#69

Post by xt00 »

Relys wrote: post #68
xt00 wrote: post #45

Earlier quoted context omitted.

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…

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.. :-)
Post reply on HN