“It may be possible to read the device’s memory using electron microscopy techniques and import it into a virtual machine”
Explain this a bit more if you can.
Explain this a bit more if you can.
The goal is to decrypt the phone's flash memory. The phone uses a dedicated AES encryption chip to encrypt/decrypt the memory. The 256-bit key is built by tangling together several sources, including the user's passcode, the device's unique ID (set during manufacture and not recorded), and an anti-replay counter. See Apple's iOS Security White Paper.
So, it would seem, if you know the unique ID and the replay counter, and the software algorithms used to combine then, you should be able to set up a brute-forcing environment external to the device, in which you try passcodes until you hit the right one.
Using the Apple hardware, it takes 80 milliseconds to try a key (they deliberately made the algorithm inefficient). 80 ms is fast for a human, but an eternity for brute-forcing. Even so, to try all four-digit passcodes takes only 14 minutes. To try all six-digit passcodes takes 100 times as long, or about a day. However, to try all 16-character alphanumeric codes takes 1.5e21 years. So, success depends on whether Farook was lazy and went for a 6-digit code, really lazy with a 4-digit code, or diligently chose a long pass phrase.
It's worth noting that, if you are able to do the brute forcing without having to use the actual phone, you should be able to achieve a substantial boost, by (1) porting the algorithm to faster hardware and (2) running many copies of the algorithm in parallel. Sounds like a job for Bluffdale.
Of course, this all depends on recovering the phone's burned in keys and replay counter from a system without a debugging interface. There are ways of doing that, but they are difficult and risk destroying the target. Here's a paper on the topic by two engineers at Chipworks, a Canadian reverse-engineering company.