+1. If it is possible to push software updates to a "locked" phone then is this not tantamount to remote code execution with root privileges, and hence the BACKDOOR ALREADY EXISTS?
"Locked" seems like an improper term for such a scenario.
I applaud apple for appealing this case to the public however there is a HUGE HUGE difference between "we can't unlock" and "we shouldn't unlock". This distinction will likely be lost on the general public unfortunately.
Nowhere in this letter they say that it's possible and it seems very carefully worded to avoid stating that. They say, if it were possible they wouldn't do it anyway. That's an important legal and moral distinction.
It's stated very clearly that they can push an update to an already existing device that would make it possible to retrieve "encrypted" data from said device.
If the data was truly encrypted, the concept of pushing an update or creating a master key would not be possible.
They state that they can push an update that makes brute-forcing possible by disabling software-enforced delays between attempts.
Apple's security PDF says that the iteration count is calibrated so that one attempt takes 80ms in hardware, so that's the hard limit on the brute forcing speed, regardless of any updates Apple releases.
This means that a long alphanumeric passphrase is secure, but a 6-digit passcode could be broken in half a day, and a 4-digit passcode would take just a dozen minutes.
It's so weird how hard it is for the brain to handle exponential growth. I was amazed that a 4-digit password can be cracked so quickly at 80ms a pop, but you're right. Just for the hell of it, here's how long it would take for different length passcodes for digits, digits plus letters (case insensitive), and digits plus letters (case sensitive):
# characters [0-9] [0-9a-z] [0-9a-zA-Z]
1 0.8 seconds 2.9 seconds 5 seconds
2 8 seconds 1.7 minutes 5.1 minutes
3 1.3 minutes 1 hour 5.3 hours
4 13 minutes 1.6 days 2 weeks
5 2.2 hours 8 weeks 2.3 years
6 22 hours 5.5 years 140 years
7 1.3 weeks 200 years 9 thousand years
8 13 weeks 7 thousand years 550 thousand years
9 2.5 years 260 thousand years 34 million years
10 25 years 9 million years 2 billion years
According to Snowden, the NSA can brute force at the speed of over a trillion guesses a second, of course, they would need to be able to disable other security features first.
Ok, I read the entire thing once again. Nowhere in there do they state that they can comply with the request, only the consequences that would result if it were possible. In fact they say they "even put that data out of our own reach".
If it is stated very clearly, can you quote me a sentence?
In the security guide linked here it seems possible for this iPhone model but not later ones.
Edit: According to the discussion below Apple can ship updates to the secure enclave. I don't know if that's possible to a locked phone.
The word "push" appears nowhere in their letter. There is no way (in evidence) of "pushing" anything to the locked phone OTA. Physical access as a requirement? Sure, there's likely some way to get something onto the phone. But any DFU or JTAG-enabled update (likely the only vectors available on a passcode-protected device) would not be able to gain access to any appreciable fraction of the data on the phone, since doing so would invalidate the keys.
I wouldn't be surprised (It isn't stated in their iOS security doc) if the key generation uses a hash of the system files as part of a seed for the entropy source used for keys, though that's pure speculation on my part.
Edited for clarity regarding "push" vs physical access.
No, they state clearly that this is what the court ordered them to do. That doesn't mean it is possible. The court doesn't care whether something is possible or not.
That doesn't sound all correct. Assuming the phone holds an encryption key that can read/write local data, a software update could simply command it to decrypt all data and save it as a copy.
A device containing an encryption key that's just protected by a software password check would be absolutely useless. Part or all of the encryption key (maybe even the IV) is derived from the phone passphrase, this is why you can't just pop the NVRAM off a phone and try to find the key.
No. The word "remote" is not applicable to an attack that only works with physical possession of the device.
As far as I'm aware there is no known technique to prevent someone with physical access, a bunch of engineers, and the code signing keys from replacing firmware.
"locked" is a relative term. Anything encrypted can be broken with enough effort. But that is the semantic difference between leveraging a back door and brutally busting open the front door. I want a device where there is no back door. I hope you can appreciate that difference.
The iPhones with an A7 or later CPU should be secure against this. This whole thing is only an issue because the phone in question is an iPhone 5C, which uses an older CPU without the "secure enclave" system.
If it only applies to older iPhones, why did Cook write, "this software ... would have the potential to unlock any iPhone in someone’s physical possession"? (emphasis mine)
Because it's likely that it wouldn't end with "unlock this 5C" -- it would eventually extend to the government forcing Apple to either stop providing the additional security features in its newer models, or find ways to ship something that looks kinda like the security feature but isn't really.
Drawing the line in the sand at "the government can't force us to hack this guy's phone this time" thus ends up being "can't force us to provide features to hack anyone else's phone down the line".
I don't know. Either Cook is confused or I am. From everything else I've read, it's Cook. If I'm the one who's confused, then Apple really dropped the ball.
Starting with the A7 CPUs, the iPhone CPU has a "secure enclave" which is basically a miniature SoC within the SoC. The secure enclave has its own CPU with its own secure boot chain and runs independently of the rest of the system. It runs a modified L4 microkernel and it does all of low-level key management.
The secure enclave contains a unique ID burned into the hardware. This ID can be loaded as a key into the hardware AES engine, but is otherwise designed to be completely inaccessible. Assuming AES is secure, that means the key can be used to encrypt data but can't be extracted, not even by the supposedly secure software running in the secure enclave. This key is then used to generate other keys, like the ones used to encrypt files. That means you can't extract the flash memory, connect it to a computer, and then try to brute force it from there. Or rather you can, but you'll be brute forcing a 256-bit AES key, not a 4-digit PIN, making it effectively impossible.
One of the secure enclave's tasks is taking a PIN (or fingerprint) and turning it into the encryption key needed to read the user's files. The main system just hands off the user's code to the secure enclave, and gets back either a key or a failure. The escalating delays with successive failures and wipe after too many failures are both done in the secure enclave. That means that updating the device's main OS won't affect it.
All of this is discussed in Apple's security guide here:
The one open question is software updates for the secure enclave. According to that guide, its software can be updated. Does that mean it can be updated with code that removes the restrictions and allows brute-forcing passcodes? The guide doesn't address how the updates work.
My guess, based on how meticulous Apple is about everything else, is that updates are designed to make this scenario impossible. The secure enclave must be unlocked to apply an update, or if updated without unlocking it wipes the master keys. This would be pretty simple to do, and it would fit in with the rest of their approach, so I think it's likely that this is how it works, or something with the same effect.
So after having asked you to expand upon the topic, I ended up reading a few articles on the matter. While they were all very thorough and informative, your summary above was by far the clearest and most succinct. Thanks very much!
You probably meant "this is tantamount". Otherwise, I don't understand what you're saying. Are you claiming the backdoor already exists, or that it does not?
Parent was asking a question, "is this not tantamount to x?" With the expected answer being "no, this is not not tantamount to x" which reduces to "yes, this is tantamount to x."
In this case, the intended answer/conclusion/implication is "yes, this is."
"Locked" seems like an improper term for such a scenario.
I applaud apple for appealing this case to the public however there is a HUGE HUGE difference between "we can't unlock" and "we shouldn't unlock". This distinction will likely be lost on the general public unfortunately.