Notes on Apple’s Ordered Intrusion of the San Bernardino iPhone

Robert Graham of Errata Security:

The second hurdle is that the phone asks for a passcode during an update. I updated my old iPhone 5 to verify this. Right between the update steps, it asked for the passcode. I’m not sure who asked for it. Was it the older iOS version, preventing an update? Or was it the new iOS version, asking to verify the new update. In the first case, it’s not something Apple can change, but in the second case, it’s something Apple can fix to comply with the FBI’s request.

I was using iTunes. Apparently, there are other tools out there (used for repair shops and factories) that are more efficient, and which may be able to bypass a security check.

I’m more interested in the moral and legal precedents this case is setting, but the technical angle is fascinating. Maybe it’s possible to decrypt the onboard storage because it’s an older phone, but Apple began doing full-device encryption back with the iPhone 3GS and made it more robust with each generation. The secure enclave in iPhones 5S and newer was a significant leap forward, but I wouldn’t be surprised if this was technically unfeasible.

One small correction, though:

Lastly, the older iOS 8 defaulted to 4 digit passcodes, and merely a long delay (but not erasure) between attempts. There’s a good chance this is how the phone was configured. Which means that an intern with the phone will eventually be able to decrypt it.

The original article specifically states that the iPhone in question was the owner’s work phone, so it’s not unlikely that there was a managed profile on it mandating erasure after ten attempts.

Update: The headline of this link has been updated for clarity.