The A6 processor has fused a different 256-bit code into each device, which, when convoluted with the passcode, creates the actual encryption key.
In March I had written a column asking, “Could test and measurement crack Farook’s iPhone?” Syed Farook, along with his wife, was the San Bernardino terrorist who killed 14 people and injured 22 others at a holiday celebration. His iPhone 5c was recovered, but was protected by a password. In the March column I proposed a method to “crack” the phone, that is, gain entry.
Here’s a short recap of the situation. The default passcode for the iPhone 5c is four numeric digits, so 10,000 possible combinations. The phone will allow 10 attempts before permanently deleting the key to ever get inside. So, law enforcement has a 0.1% chance of entering the phone by guessing, and a 99.9% chance of never seeing the contents. Never. As I wrote, "You better be a good guesser."
Figure 1: Here is a photo of the iPhone 5s passcode screen. iPhone 5c does not support Touch ID, but is otherwise the same. You get 10 attempts at the passcode before the phone’s data is gone forever. You better be a good guesser.
I proposed the scheme below:
Step 1: Read the contents of all flash memory on Farook’s iPhone, either by unsoldering the components, or via ICT (In-Circuit Test or serial ports such as JTAG). This is the test and measurement-centric portion of this plan. The data is encrypted, so it is still worthless.
Step 2: Purchase 1,000 iPhone 5cs and 1,000 of each memory chip. Program the memory to have the exact same data as in Farook’s.
Step 3: Unsolder the memory chips in the 1,000 iPhones. Replace them with those programmed with Farook’s data.
Step 4: You now have 1,000 copies of Farook’s iPhone. All 10K passcodes can be tried, 10 per iPhone. The password will be cracked within a day.
However, I was stymied on one specific aspect of the plan. In my studies of the iPhone encryption method, I found that Apple had built a crypto engine onto its A6 processor between main memory and flash. By executing the 256-bit encryption algorithm in hardware, Apple allows at-speed access to memory. But, and this is key, each A6 has fused a different 256-bit code into each device, called the UID (Unique ID). That code, when convoluted with the user’s passcode, creates the actual encryption key. The UID is created randomly, there are no records of the UID, and it cannot be read through any port.
The net of this is that the above scheme won’t work. Even if you enter Farook’s passcode, it won’t unlock the phone if the UID is different, which it is on all the copy phones. I solicited ideas from the readers on how to get around this. Most discussion centred on finding the UID by performing a destructive autopsy of the A6 processor, but even this is problematic. What then? If you could program that UID into A6 processors, you could then replace all processors in all 1,000 copy phones (as has been done with the flash memory). But to do so, you need access to Apple’s processor fab line. Alternatively, you could use supercomputers to try all convolutions of the UID and passcodes. This is a different forensic approach from getting a working iPhone.
The bottom line, we didn’t source any ideas that I felt were achievable. And then a researcher from the University of Cambridge came up with an ingenious approach, and demonstrated it successfully on an iPhone 5c. Click ahead to find the answer to this riddle…