Is This the FBI's 'New' Method for Unlocking the San Bernardino iPhone?

NAND flash chips used by the iPhone 5c

I recently wrote about how it should be perfectly feasible for the FBI to circumvent the San Bernadino iPhone's much-discussed auto-erase feature. And yesterday the FBI announced that they might have a way to get into the phone without compelling Apple to make any changes. While I have no reason to believe that my earlier blog post was their "third-party source" for this information, it seems likely that their approach will be something along the lines of what I described.

I've also been asked for a more detailed analysis of the attack I outlined. How long would it take? How much would it cost?

The bottom line is that for a functioning investigative agency with a team of experts and an active lab, it would probably take about 2 days. But even if they started from nothing, it would take the FBI (or anyone) no more than $50K and about a month to unlock this phone with the technique I proposed. Below are my rough estimates, with links and details explaining each step.

The fact that the FBI has taken so long to come around, and tried instead for a public fight in the courts suggests that they have been aiming for legal precedent, not for access to this one phone. They want the courts to empower them to compel tech providers to disable their own security measures, or even to force a tech provider to vouch for software that the provider knows has been deliberately weakened. That would be a disastrous precedent: it would reduce the security of tools the public depends on, leading to less privacy and greater risks for everyone.

If the FBI has any reasonably competent technicians on hand (and I believe they do), they knew about this technique long before yesterday. It wasn't even unknown to members of Congress: Representative Darrell Issa described a similar approach to FBI director James Comey at the Judiciary committee meeting earlier this month. The FBI has been pushing for disastrous legal precedent despite knowing that they have other avenues available. Do they think their legal power grab is more important than the public's privacy and security?

Here are the details:

Initial one-time setup

For an investigative agency that already has a functioning lab and skilled technicians, this would take very little time (an hour or two at most).

For an organization that is starting entirely from scratch: perhaps two weeks for ordering, shipping, familiarizing the team with the equipment, and doing trial runs on a few test iPhone 5c's, if the FBI has really never done this before.

Then the real testing of the passcodes would start.

In-loop passcode-testing

  • Startup time for iPhone 5C: ~30 seconds
  • Initial passcode check delay: tries 1 through 4: no delay; 5th try: 1 minute delay. (Subsequent attempts trigger progressively longer delays, all the way up to an hour between the 9th and 10th try. If the 10th try fails, and auto-erase is on, the effaceable storage is wiped, resetting the phone to its factory defaults. The total cumulative delay before wiping is 1 hour 36 minutes.)
  • Time to fully flash a 16GiB NAND chip with an external programmer capable of speeds of 5MB/s: about an hour

Although the passcode check delay is likely the longest part here, the chip can be swapped at any point. The failed-passcode count is likely stored on the chip for the iPhone 5c, so it should be reset to 0 after a swap. It would be most efficient to swap in a reflashed chip after the 5th failed attempt, before longer delays kick in, to minimize total delay. Trying 5 4-digit passcodes takes less than 20 seconds.

So if the passcode delay each loop is close to nothing, and the the startup time is only 30 seconds, the one-hour time to re-flash the chip is the limiting factor. Can we do better?

By using multiple chips in rotation (they're about $20 apiece), the NAND can be flashed in parallel to the reboot-and-check-passcode work. That is, you can swap the NAND chip with a fresh one between tries, and re-flash the chips you're not using while one of them is in use testing passcodes.

A device like this can flash at least 4 chips concurrently, with the operator popping them in as they need to be rewritten. This means that on average, a fresh NAND chip would become available about every 15 minutes. With two such devices in operation at once and 8 spare chips, a freshly-programmed NAND chip would be available every 7 or 8 minutes. And it keeps scaling up: the more hardware thrown at the problem, the faster the process becomes until the next NAND chip is ready in less than the time it takes to boot the phone and try 5 passcodes.

An even quicker approach requiring fewer chips and fewer flash programmers would be to only re-flash the parts of storage that change between attempts (the record of the number of failed passcode tries, or the wiped effaceable storage), rather than the full 16GiB. But doing that requires more detailed analysis of what's going on in the filesystem, and if the FBI doesn't have the technical sophistication to do that, they can just use the simpler full-chip flash approach with more chips that I am describing.

What would the workflow look like?

Once the setup was done, here's what would happen, repeatedly:

  • A chip finishes flashing
  • It gets popped into the phone's socket
  • The phone is booted
  • The next 5 passcodes are tried by hand (until the first delay kicks in)
  • The phone is powered off
  • Chip is returned to the queue for re-flashing
  • Wait for the next chip to complete flashing

With enough chip programmers running concurrently and an efficient team working together, each cycle could take about 70 seconds total:

  • 20 seconds to swap the chip
  • 30 seconds to boot the phone
  • 20 seconds to try 5 passcodes

For an inexperienced team with only a half-dozen chip programmers available, the whole cycle still shouldn't take more than 10 minutes.

How much would it cost?

Most of the hardware cost for this would go to the programmers and the chip-specific sockets needed, much of which a well-equipped forensics lab would probably already have. But even if they're starting from scratch, it's still less than $10K to be able to program 4 chips concurrently. Only one flash reader is needed (no more than $3K), and the test socket is about $100. Heat guns, clamps, desoldering tools, ventilators, etc, would all come in well under $1K. They should probably also throw in a dozen spare iPhone 5c handsets to practice on at $200 apiece.

So starting from zero, an ill-equipped FBI wouldn't need to spend more than $50K total for the hardware, and almost all of these costs could be amortized against any similar devices the FBI had a warrant to investigate.

For staff time and training, the cost would probably be significantly more than the hardware. But they've likely already spent more than that on lawyers. The proposed attack is not a particularly expensive operation for an organization on the scale of the FBI.

How long would it take?

Once the initial setup is done, how long would it take to guess the iPhone's passcode? We know from the FBI's report that the device has a 4-digit PIN, which means that there are only 10,000 possibilities to try.

At 70 seconds for every 5 passcodes for a team working around the clock, and assuming that the passcode used is the very last one tried, that's:

(10000/5) × 70 sec = 14000 seconds = ~39 hours

For the slower, less-equipped, inexperienced team that takes 10 minutes per 5 passcodes, it would still be relatively quick:

(10000/5) × 10 min = 20000 min = ~2 weeks

Chances are, the right passcode wouldn't be the very last one they tried, so they shouldn't need to take the full amount of time. But then again, we should let the poor FBI sleep some of the time, so these estimates seem fair.

So for a functioning, well-equipped, already trained team, we're talking about two days total (a few hours setup, plus 39 hours of testing). And for a novice approach, starting from zero, we're still talking no more than a month (two weeks of setup, plus two weeks of testing).

They've had the phone since December 3, 2015, and it's now the middle of March, well over 14 weeks later.

What have they been doing all this time?

What does this mean for the rest of us?

Note that none of these steps are particularly difficult, or in any way limited to the FBI. If you have an iPhone (or any other device) with encrypted storage protected by a short, testable passcode, then anyone with $50K, a few weeks of time, and physical access to your device should be able to get access to your data, even if you have a feature like auto-erase turned on.

This is why a stronger passcode for your personal device is an important part of any real-world information security. If you're responsible for data that shouldn't leak to political or legal adversaries, economic rivals, identity thieves, or, uh, Gary, then making sure that your passcode is significantly stronger than 4 digits is critically important. A random 8 digit passcode would last a few hundred years against the attack outlined in this article (though it might fall much more quickly against more sophisticated attacks). Of course, you also need to ensure that your device is encrypted, and that you have enabled whatever other reasonable safety features your platform offers. The devices we carry today contain tremendous amounts of information, and much of it is sensitive not just to the person carrying it, but to other people as well: your contacts: co-workers, friends, lovers, family.

What about hardware security?

Some newer versions of the iPhone have a special hardware feature called a "Secure Enclave", which moves some of these protections (like retaining the timeout/delay between failed passcodes) into the processor in ways that may not be easily defeatable by backing up the storage as I've described here. Other hardware vendors have similar features under different names like SecureBoot, TPM, SGX, or Knox. But many of these features can themselves be bypassed by the device manufacturer without the knowledge of your passcode, so they may not be as reliable as one would like.

I'll write more about hardware-backed security and who it protects in a future article.

View comments (11)
Read the Terms of Use

Anonymous

Great article

Anonymous

Devices like this clear the crypto keys, which they keep on-die with the processor. Dumping flash gives you encrypted nonsense if the keys are gone, and interacting with the keys is supposed to be doable only via on-chip operations, with no means of extracting the keys.

Daniel Kahn Gillmor

The on-die keys (the UID and GID) for the A6 are write-once, not re-writeable or erasable. they're burned (GID) or fused (UID) into the processor at manufacturing time, and never change for the lifetime of the chip.

the effaceable storage is off-die, either in the NAND flash (for many models) or possibly in an external EEPROM for some of the more recent models. The fact that these chips can be backed up and restored cleanly is what allows this technique to work.

see "What about the replay attack?" in https://marcan.st/2016/03/untangling-ios-pin-code-security/
and see page 34 of http://esec-lab.sogeti.com/static/publications/11-hitbamsterdam-iphonedataprotection.pdf

Anonymous01

RE to: Daniel Kahn Gillmor

The reference links to see "What about the replay attack" refers to the iOS 4 NAND layout, the one link that is provided that outlines the data wipe function is based on IOS4. The link is from lab.sogeti.com.

What I find troubling is that a fair amount of technical individuals have described the clone chip process, but none have actually proven the concept. It seems to me that someone in the business would have tried this technique and stated for a fact that it works. The cost of the proof of concept is one iPhone, a chip reader and software to copy the raw data from the chip and back and the time to do it.

Set a four digit pin, try 10 times forcing the failure, reimage the chip then try entering the correct passkey. If the phone works and you can read all of the data on the phone (obviously put some data on the phone) then the problem is solved.

Then the question is; why didn't the FBI try this on the other phones they say need unlocked? Seems to me that this issue should have been solved before long before the San Bernardino shooting occurred if all it took was cloning the disk. I would also think that Apple would have tried this technique as part of their quality assurance tasks.

Anonymous

This is a follow up to a previous post I made regarding link lab.sogeti.com/static/publications/11-hitbamsterdam-iphoneda...

That same document is contained in Exhibit 17 of the DECLARATION OF STACEY PERINO IN SUPPORT OF GOVERNMENT’S REPLY IN SUPPORT OF MOTION TO COMPEL AND OPPOSITION TO APPLE INC.’S MOTION TO VACATE ORDER that is part of the court record pertaining to the Motion to Compel Apple to unlock the phone.

So it seems that the FBI is well aware of what you're referencing so I'm baffled as to why someone could conclude "The fact that these chips can be backed up and restored cleanly is what allows this technique to work."

Is Daniel Kahn Gillmor therefore stating that the FBI has full knowledge of what to do, but is just to ignorant to actually do it? The FBI not only has some pretty good employees working for them, they have some of the very best IT security firms under contract. Cellebrite has been mentioned in the news lately, but guess what? The company is also mentioned in STACEY PERINO's DECLARATION. Exhibit 18 is Cellebrite's manual titled; Cellebrite Physical Extraction Manual for iPhone & iPad and dated July 3rd, 2011. Both document reference iPhones up to iPhone 4.

I find it difficult to believe that the FBI has all of this knowledge/documentation, all of these companies under contract yet they didn't ask the simple question of mirroring the NAND and none of these companies volunteered mirroring as a viable solution. They know how to hack an iPhone 4, been there done that, yet they are somehow clueless regarding the iPhone 5c.

I've got to believe that Apple and their partners asked this question and ran a test on an exemplar phone and it didn't work. Otherwise the FBI has lied to the U.S. District Court in sworn declarations, that's perjury. So what about Comey and his testimony before Congress when he basically stated that the FBI has exhausted all means known to them. Was that a lie made under oath?

Anonymous

Your method seems fairly fast for a one-off, but if the FBI were going to do this a lot I would think it's not too hard to create something out of RAM+FPGA that would attach to that flash socket and would emulate a NAND flash chip. It would run faster, and could be "instantly" restored to the original state (as read from the original flash), instead of swapping another flash chip. In fact that failed-passcode count could be reset after every 4th try.

Daniel Kahn Gillmor

I suspect you're right that such an emulator would be an even more convenient approach once it was set up -- you could shave off the time it takes to physically swap the chip, and you'd run less of a risk of hardware failure or misaligned access.

These sorts of emulators already exist for other platforms:

http://wiki.laptop.org/go/ROM_Emulators_for_OLPC

It wouldn't surprise me to learn that they already exist for the type of chip used in this particular hardware, or if they don't already exist, an experienced manufacturer could provide them.

Tania

I was very pleased to uncover this great site. I wanted to thank you for your time due to this wonderful read!! I definitely loved every bit of it and I have you saved as a favorite to look at new information in your web site.
http://www.juegosfriv2017.link/

Anonymous

So now they can get in and see your stuff . They can then open up and put stuff there that's not yours and say it is . If they don't like you well good luck .

Anonymous

One of the best posts on this topic I’ve read in a while. Quality information like this keeps me reading. Thanks. Love all the ideas at the end of this post. promoocodes.com/coupons/godaddy/

Pages

Stay Informed