Apple is talking about source code, the FBI is talking about a signed binary. I'm fairly certain Apple has the technical ability to create a signed binary that only executes on a single phone.
More importantly, once "GovtOS" (as Apple's filing calls it) is developed -- even if the government is billed $800K for the privilege -- each subsequent writ will be much less expensive to fulfill, creating a tidal wave of LEO requests to unlock phones. So Apple wants to head this off right now, because otherwise the floodgates will open.
Apple has said that for legal reasons, it may be forced to keep the code permanently and will have to secure it permanently out of concern for future legal/court obligations specific to this case.
In support of this, someone forwarded me a very interesting article written by someone who creates forensic software for a living. The legal requirements surrounding the creation of a software tool for forensic purposes, which this proposed effort requested by the government might fall under, are nothing less than herculean in scope.
I'm sure defense counsel would want to be able to verify that it isn't modifying file access times, or deleting data, or planting data, or otherwise disturbing evidence when the update is put in.
If Apple had designed the iPhone to require user authentication before updating the software/firmware then they wouldn't be in this mess and they would not be able to comply with the court order short of hacking/jailbreaking the phone. If the pin was required to be entered before installing new software on the phone then the FBI would first need to know the pin to load GovOS on the phone so they would not be able to crack the pin using this method. And once Apple patches their software to require user authentication before installing updates they will no longer be able to comply with any similar type of request.
It's a pretty good bet that China, Russia, the NSA, and other state security agencies have access to Apple's source code (not by Apple providing it to them, but by having pwned an employee's laptop). If Apple creates the source code to do this, these state agencies will be a digital signature away from being able to crack any iPhone that ends up in their physical possession. This applies even if Apple deletes the source code soon after providing the binary to the FBI, since it will have been siphoned off the corp network while under development.
> "It's a pretty good bet that China, Russia, the NSA, and other state security agencies have access to Apple's source code (not by Apple providing it to them, but by having pwned an employee's laptop). If Apple creates the source code to do this, these state agencies will be a digital signature away from being able to crack any iPhone"
In the scenario you lay out, these security agencies are incapable of writing their own modifications to iOS, even though they possess the source to iOS.
Absolutely ridiculous. If they can steal the source and signing key, they certainly have access to the technical expertise to do it themselves.
I mean christ, exactly how complicated do you think this pin timeout logic is? If they can hire sufficiently skilled hackers, they can certainly hire sufficiently skilled developers.
The security of the system lies in the secrecy of the signing key. If they can meet that bar, they can surmount any other obstacle.
My understanding is that when you install iOS on an iPhone, an Apple server signs the OS as part of a challenge-response protocol. The challenge includes a unique device ID, and I believe the signed iOS is only installable on a device with that ID. http://www.saurik.com/id/12 has more details.
Think about this in the context of jailbreaking to understand why such a facility exists. Apple doesn't want users to install their own modifications to iOS, and they also don't want users to install old versions of iOS that have vulnerabilities that would allow people to modify the OS.
One way you could implement something like this is to have a public/private keypair within the device and have updates encrypted with the public key; then design the device to only run an OS that it could decrypt with its private key. To do this well, you would need a TPM that did not allow the private key to leave the device, nor to be reset.
All iOS software updates, even the normal ones, bear a digital signature that incorporates the device's UDID. The bulk of the software update is the same for all devices, but Apple must generate a new signature for each device using Apple's private signing key.
I don't know if Apple has any specific capability as part of the firmware verification, but even if they didn't they could just put something like this early in the boot process:
if (unique_device_id != SAN_BERNARDINO_DEVICE_ID) {
halt();
}
If this code must be signed to execute then it can't be modified to work on another device without Apple signing it again.
This assumes there's a unique device ID that is known to the FBI and can't be tampered with. Maybe the serial number or IMEI?
My understanding is that phone thieves routinely change the IMEI by desoldering and replacing a chip. If this weren't the case, I think it would be fairly easy for detectives to call up the person currently in possession of any given stolen iPhone.
It looks like there's something called a UDID which is a SHA-1 hash of a bunch of identifying information. So, difficult to fake even if you can twiddle the source values or swap in new chips.
Except they have the shooter's phone, which has the identifying information which results in the correct UDID. To get the same UDID on another phone they just need to change the source values to the same values as in the shooter's phone. The fact that it's a cryptographic hash doesn't really help here, assuming they can change all the source values at will.