6 ms·

+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 BACK

+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.

rhaps0dy 11y ago
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?
- gnoway 11y ago
  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."
germanier 11y ago
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. To be fair, they could have stated it explicitly.
- hasenj 11y ago
  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.
  - germanier 11y ago
    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.
  - andreyvit 11y ago
    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.
    - deleted 11y ago
      [deleted]
    - imh 11y ago
      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
superuser2 11y ago
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.
- pweissbrod 11y ago
  "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.
  - mikeash 11y ago
    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.
    - kobayashi 11y ago
      Would you expand upon this?
      - mikeash 11y ago
        Sure thing. 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: https://www.apple.com/business/docs/iOS_Security_Guide.pdf https://www.apple.com/business/docs/iOS_Security_Guide.pdf 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.

rhaps0dy 11y ago

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?

gnoway 11y ago
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."

germanier 11y ago

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. To be fair, they could have stated it explicitly.

hasenj 11y ago
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.
- germanier 11y ago
  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.
- andreyvit 11y ago
  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.
  - deleted 11y ago
    [deleted]
  - imh 11y ago
    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

superuser2 11y ago

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.

pweissbrod 11y ago
"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.
- mikeash 11y ago
  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.
  - kobayashi 11y ago
    Would you expand upon this?
    - mikeash 11y ago
      Sure thing. 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: https://www.apple.com/business/docs/iOS_Security_Guide.pdf https://www.apple.com/business/docs/iOS_Security_Guide.pdf 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.