One of the FBI’s Major Claims in the iPhone Case Is Fraudulent

“We have enormous computing power in the US government, but we need to be able to bring it to bear without the phone killing itself.”
                                  - FBI Director James Comey, March 1, 2016.

In the FBI’s court order requesting Apple's assistance in unlocking the work iPhone 5c used by the San Bernardino shooter, the bureau's first and most urgent demand is that Apple disable the iPhone's “auto-erase” security feature. This feature (which is not enabled by default on most iPhones) protects user data on a device from would-be snoops by wiping the phone after 10 failed passcode attempts. This protects you and me from thieves trying to guess our passcodes and access our data for identify theft, for example.

But the truth is that even if this feature is enabled on the device in question, the FBI doesn't need to worry about it, because they can already bypass it by backing up part of the phone (called the “Effaceable Storage”) before attempting to guess the passcode. I'll go into the technical details (which the FBI surely already knows) below.

How the FBI describes the “auto-erase” feature

Let's look at how the FBI describes the situation. The court order's first and most urgently phrased request is to ask Apple to “bypass or disable the auto-erase function whether or not it has been enabled.”

A few days after the court order was issued, but before Apple had formally responded, the government filed a strongly worded motion to compel, which contained this description of the feature:

The FBI has been unable to make attempts to determine the passcode to access the SUBJECT DEVICE because Apple has written, or “coded,” its operating systems with a user-enabled “auto-erase function” that would, if enabled, result in the permanent destruction of the required encryption key material after 10 failed attempts at the [sic] entering the correct passcode (meaning that, after 10 failed attempts, the information on the device becomes permanently inaccessible)…

In sum, the government seeks the ability to make multiple attempts at determining the passcode without risk that the data subject to search under the warrant would be rendered permanently inaccessible after 10 wrong attempts.

To add urgency to their attempt to compel Apple to abuse their software signing keys, the FBI is painting a picture of “permanently inaccessible” data. But if its agents are doing their job, that's just not the case.

How the “auto-erase” feature actually works

Here's where the technical details come in. The iPhone protects its user's data with a complex hierarchy of cryptographic keys. Some data is protected by multiple keys. Imagine a pile of letters and photos placed inside a locked box, with the box itself placed inside a locked filing cabinet. You'd have to have keys to the filing cabinet and the box to read any of the letters or see any of the photos. If either of these keys is destroyed, the letters and photos are lost forever.

When iOS decides to wipe out user data because the passcode guess limit has been reached (or for any other reason), it doesn’t actually erase all the data from its underlying storage; that would actually take several minutes. Instead, it just destroys one of the keys that protects the data, rendering that data permanently unreadable. The key that is erased in this case is called the “file system key”—and (unlike the hardwired “UID” key that we discussed in our previous blog post) it is not burned into the phone’s processor, but instead merely stored in what Apple calls “Effaceable Storage,” which is just a term for part of the flash memory of the phone designed to be easily erasable. Apple's iOS Security Guide explains:

Since it’s stored on the device, this key is not used to maintain the confidentiality of data; instead, it’s designed to be quickly erased on demand (by the user, with the “Erase all content and settings” option, or by a user or administrator issuing a remote wipe command…. Erasing the key in this manner renders all files cryptographically inaccessible.

The file system key is like the key to the filing cabinet in our example: a small thing that is easy to destroy, which disables access to the rest of the information.

Why the FBI can easily work around “auto-erase”

So the file system key (which the FBI claims it is scared will be destroyed by the phone’s auto-erase security protection) is stored in the Effaceable Storage on the iPhone in the “NAND” flash memory. All the FBI needs to do to avoid any irreversible auto erase is simple to copy that flash memory (which includes the Effaceable Storage) before it tries 10 passcode attempts. It can then re-try indefinitely, because it can restore the NAND flash memory from its backup copy.

Here's a picture of the front and back of main circuit board inside the iPhone 5c:

iPhone interior

Image credit:

The large chip on the front marked A6 is the processor -- a custom chip designed by Apple specifically for its devices. It contains the CPU, BootROM, RAM, crypto engines, Apple's public signing key (used to verify software updates), and the UID key (see our previous blog post).

The largest chip on the back (outlined in red above) is the NAND flash, where all the data is stored, including both the encrypted filesystem and the Effaceable Storage.

The FBI can simply remove this chip from the circuit board (“desolder” it), connect it to a device capable of reading and writing NAND flash, and copy all of its data. It can then replace the chip, and start testing passcodes. If it turns out that the auto-erase feature is on, and the Effaceable Storage gets erased, they can remove the chip, copy the original information back in, and replace it. If they plan to do this many times, they can attach a “test socket” to the circuit board that makes it easy and fast to do this kind of chip swapping.

If the FBI doesn't have the equipment or expertise to do this, they can hire any one of dozens of data recovery firms that specialize in information extraction from digital devices.

NAND flash storage is an extremely common component. It's found in USB thumb drives, mobile phones, portable music players, low-end laptops—pretty much every portable device. Desoldering a chip from the circuitboard is straightforward enough that there are many clips on YouTube showing the practice, and reading and writing a bare NAND chip requires a minor investment in hardware and training that the FBI has probably already made.

What's really going on here?

If this generally useful security feature is actually no threat to the FBI, why is it painting it in such a scary light that some commentators have even called it a “doomsday mechanism”? The FBI wants us to think that this case is about a single phone, used by a terrorist. But it's a power grab: law enforcement has dozens of other cases where they would love to be able to compel software and hardware providers to build, provide, and vouch for deliberately weakened code. The FBI wants to weaken the ecosystem we all depend on for maintenance of our all-too-vulnerable devices. If they win, future software updates will present users with a troubling dilemma. When we're asked to install a software update, we won’t know whether it was compelled by a government agency (foreign or domestic), or whether it truly represents the best engineering our chosen platform has to offer.

In short, they're asking the public to grant them significant new powers that could put all of our communications infrastructure at risk, and to trust them to not misuse these powers. But they're deliberately misleading the public (and the judiciary) to try to gain these powers. This is not how a trustworthy agency operates. We should not be fooled.

View comments (193)
Read the Terms of Use


Reading a flash is easy. It's nothing more than a memory bank. Remove it, copy it. Once you have a million copies of this phone's flash contents, you can attack at your leisure.

Is there some magical feature about this flash that prevents its being copied, something hidden from designers over the last few decades?

I've pulled flash out of devices and read their contents with a programmer more than once. I have no idea how to interpret the contents, because it's not necessary. It's just hex code.

But I can make copies, each and every one identical. Millions of copies. Each copy can undergo a unique attack. Ten tries doesn't work, shit-can it and grab another copy. Try again until you get it right. Using 4 digit code attacking would take less than 15 minutes with a laptop and the right interrogating code. Try it sometime.


Snowden understands just fine. Those failure responses can easily be blocked so that there wouldn't be a delay. This is not difficult if you know what you are doing. This is not about getting into this phone, it is about forcing the tech industry to become good little slaves of the intelligence community.


Nope. All code entry has to be done on the device itself, there's no way to duplicate the UID which is one half of the encryption key. You could have a million nand copies but you'd still need to put each one into that single iPhone over 1100 times then punching in a 4 digit code over a 1 hour and 36 minute period because of the built in time delay. The nand copies would cut down on wear and tear tho. And later iPhones has the 1 hour delay built into the secure enclave so restarting doesn't reset the timer. So each further code entry after the first nine has a delay of a hour each. Your nine code entries after that takes 9 hours each cycle. 416 days to break each iPhone. Snowden doesn't know what he's talking about and neither does the ACLU.


Where do they keep the counter that would trigger the key wipe when 10 is reached? If it's not on the NAND flash memory then how would it help by restoring a copy of the memory? In other words, how does the counter reinitialize to 0?

Daniel Kahn Gillmor

Thanks for highlighting the efficiency concerns. You're right that the devil is in the details here, but proper engineering would reduce that amount of time to 2 days (for an experienced, well-resourced team) or a month (for a new team starting from scratch). I've described the details here:


Gosh what else is new ? Government using terrorist excuse to take away liberties... where have I seen this before ?

It reminds me of a nice quote from an old president.

Any society that would give up a little liberty to gain a little security will deserve neither and lose both.

That is the aim of the government though... enslave humanity for the elite...

But its easier calling me a tinfoil probably ;-)

The average sheep likes these ad hominem attacks.


... "That is the aim of the government though... enslave humanity for the elite..."
Yes, it has always been so. The game of chess is not played for the sake of the pawns.


Very well explained. Thank you.


In addition any A7 cpu or later based iPhone (5s and later) the delay timer is enforced by the secure enclave so it doesn't reset to 60ms when restarted. Any attacker would be waiting 1 hour between each try for the rest of the 9,991 attempts(416 days). And I bet for the next iOS update Apple will enforce the device wipe in the secure enclave. So if the device gets 10 wrong entries that will be stored in the secure enclave so even if the nand is reflashed as soon as the device is restarted it will wipe the nand before it even gets to the passcode entry. And/or it just sits there and does a manual wipe of everything, restart and it just continues where it left off. That would render brute force attempts and chip decapping useless as the encrypted data would be gone, not just scrambled.


congrats for this "eye-opener" !!!


Stay Informed