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
- Select and purchase hardware (see below for the details of the hardware needed)
- Desolder the phone’s NAND flash
- Solder in a test socket for easy replacement
- Read out NAND flash with a low-level hardware reader and back it up
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.
