5 ms·

This is not really true. The secure enclave is a separate computer. It doesn't get software updates. > possibly with the addition of a judicially compelled fin

This is not really true. The secure enclave is a separate computer. It doesn't get software updates. > possibly with the addition of a judicially compelled fingerprint scan or PIN brute force to get the encryption key out of whatever on-device escrow it's stored in This is the whole problem. The keys are in the SE. You can't brute force the PIN because the SE rate-limits attempts (and that rate limiting cannot be overridden by an OS update because the SE is not run by the OS). If you can get a fingerprint scan then all bets are obviously off, but then you don't need Apple at all.

ajross 11y ago
Is that really true? The enclave's firmware is in ROM and non-upgradeable? I'd always assumed it got a signed blob like everything else does. Obviously it's possible to design a system like that, I just haven't seen it reported anywhere that it actually works like that. Edit just to be clear: the requirement really is that the firmware be stored in a ROM somewhere, probably on the SoC. That's a lot of die space (code storing a fully crypto engine isn't small) to dedicate to this feature. Almost certainly what they did is put a bootstrap security engine in place that can validate external code loaded from storage. And if they did, that code can be swapped by the owner of the validation keys at will, breaking the security metaphor in question.
- d_theorist 11y ago
  I'm not claiming it is in ROM or that it is not upgradeable if you are Apple and have physical access to the device. I'm not sure on that point. What I think must be the case is that Apple can't remotely upgrade the SE firmware as part of its iOS update mechanism. Although, to be perfectly honest, I have not seen this explicitly documented.
  - ajross 11y ago
    So... it sounds like you more or less agree with me. Apple can comply with this court order and open your secure device. We just differ as to whether they can do it over the air. (FWIW: OTA firmware updates are routine in the industry. I've worked on such systems professionally, though not for Apple.)
- hannibalhorn 11y ago
  According to a former apple engineer that worked on this stuff, the enclave's firmware is indeed a signed blob: https://twitter.com/JohnHedge/status/699882614212075520 https://twitter.com/JohnHedge/status/699882614212075520 The key thing would be for it to lose all stored keys on update when the current passphase has not been provided, and it sounds like that may not currently be the case. Maybe in this case, Apple could comply, but a simple tweak would make it impossible in the future?
  - ajross 11y ago
    But "on update" isn't really the issue. If the code can be swapped underneath it, how does it know an "update" took place? Again you're in the situation where all of that process would have to be managed by hardware, when what is really happening is that the enclave is a computer running signed software that can be replaced.
    - andromeduck 11y ago
      Having the hardware require both the signature to pass as well as a valid PIN/fingerprint can't be that difficult. Die space is cheap nowadays, especially stuff that doesn't need to be on all the time because of the death of Dennard scaling.
    - hannibalhorn 11y ago
      Sure, but the signed firmware could be written to delete any stored keys when it accepts an update and the phone's passphrase has not been provided. That's assuming that it manages it's own update process, has the firmware securely stored within it's own die, etc. It's entirely possible ... but only Apple really knows. I would not actually be shocked if they originally did wipe out stored info on firmware update, but had some issues with people updating their phone and losing everything, so they ifdef'd that particular bit out in the name of usability.
      - ajross 11y ago
        But... the firmware is stored in external storage. How does it even detect that an update was performed? You're saying that if the hardware had affirmative control over all the secure storage (e.g. the RPMB partitions on eMMC, etc...), then it could have been written to do this blanking. Well, yeah. But then you'd have a system that couldn't be updated in the field without destroying the customer data (i.e. you'd have a secure boot implementation that couldn't receive bug fixes at all). It's a chicken and egg problem. You're handling the problem of the "iPhone" not being a 100% snoop-and-tamper-proof device by positing the existence of an "interior" snoop-and-tamper-proof device. But that doesn't work, because it's turtles all the way down. Ultimately you have to get to a situation where there is a piece of hardware (hardware on a single chip, even) making this determination in a way that has to be 100% right from the instant the devices go out the door. And that's not impossible, but it's asking too much, sorry. We're never going to get that.
- tlrobinson 11y ago
  The "bootstrap security engine" could store a hash of the blob in it's secure flash storage, and only update the hash if the user enters their pin, then reload the firmware blob. If the stored hash and blob hash ever don't match on boot, wipe the keys.
zabuni 11y ago
The device in question does not have a secure enclave. It's a 5c.
- d_theorist 11y ago
  But it's more interesting to think about the case where the phone does have a secure enclave.
  - conradev 11y ago
    and yet it would be less interesting to consider if the password was a "six-character alphanumeric passcode with lowercase letters and numbers" because even if the software rate-limiting was disabled with a rogue firmware update, the PBKDF2 or similar iteration count makes brute-forcing impractical. > A large iteration count is used to make each attempt slower. The iteration count is calibrated so that one attempt takes approximately 80 milliseconds. This means it would take more than 51⁄2 years to try all combinations of a six-character alphanumeric passcode with lowercase letters and numbers (Page 12 of https://www.apple.com/business/docs/iOS_Security_Guide.pdf https://www.apple.com/business/docs/iOS_Security_Guide.pdf).
  - bluesaunders 11y ago
    In that case, they could just bring the phone down to the morgue and unlock it with touch id.
    - mef 11y ago
      Touch ID requires the passcode after reboot or timeout. They'd need to do it very quickly.
    - lololomg 11y ago
      If the phone is rebooted or if 48 hours have passed since the last passcode was entered, the touch ID can't be used to unlock the phone.
    - katbyte 11y ago
dntrkv 11y ago
Fingerprint scan really isn't enough though since after a restart, iPhones require the password to be entered.
- mentat 11y ago
  Because fingerprints are not sufficient to generate / recover KEKs from.

ajross 11y ago

Is that really true? The enclave's firmware is in ROM and non-upgradeable? I'd always assumed it got a signed blob like everything else does. Obviously it's possible to design a system like that, I just haven't seen it reported anywhere that it actually works like that. Edit just to be clear: the requirement really is that the firmware be stored in a ROM somewhere, probably on the SoC. That's a lot of die space (code storing a fully crypto engine isn't small) to dedicate to this feature. Almost certainly what they did is put a bootstrap security engine in place that can validate external code loaded from storage. And if they did, that code can be swapped by the owner of the validation keys at will, breaking the security metaphor in question.

d_theorist 11y ago
I'm not claiming it is in ROM or that it is not upgradeable if you are Apple and have physical access to the device. I'm not sure on that point. What I think must be the case is that Apple can't remotely upgrade the SE firmware as part of its iOS update mechanism. Although, to be perfectly honest, I have not seen this explicitly documented.
- ajross 11y ago
  So... it sounds like you more or less agree with me. Apple can comply with this court order and open your secure device. We just differ as to whether they can do it over the air. (FWIW: OTA firmware updates are routine in the industry. I've worked on such systems professionally, though not for Apple.)
hannibalhorn 11y ago
According to a former apple engineer that worked on this stuff, the enclave's firmware is indeed a signed blob: https://twitter.com/JohnHedge/status/699882614212075520 https://twitter.com/JohnHedge/status/699882614212075520 The key thing would be for it to lose all stored keys on update when the current passphase has not been provided, and it sounds like that may not currently be the case. Maybe in this case, Apple could comply, but a simple tweak would make it impossible in the future?
- ajross 11y ago
  But "on update" isn't really the issue. If the code can be swapped underneath it, how does it know an "update" took place? Again you're in the situation where all of that process would have to be managed by hardware, when what is really happening is that the enclave is a computer running signed software that can be replaced.
  - andromeduck 11y ago
    Having the hardware require both the signature to pass as well as a valid PIN/fingerprint can't be that difficult. Die space is cheap nowadays, especially stuff that doesn't need to be on all the time because of the death of Dennard scaling.
  - hannibalhorn 11y ago
    Sure, but the signed firmware could be written to delete any stored keys when it accepts an update and the phone's passphrase has not been provided. That's assuming that it manages it's own update process, has the firmware securely stored within it's own die, etc. It's entirely possible ... but only Apple really knows. I would not actually be shocked if they originally did wipe out stored info on firmware update, but had some issues with people updating their phone and losing everything, so they ifdef'd that particular bit out in the name of usability.
    - ajross 11y ago
      But... the firmware is stored in external storage. How does it even detect that an update was performed? You're saying that if the hardware had affirmative control over all the secure storage (e.g. the RPMB partitions on eMMC, etc...), then it could have been written to do this blanking. Well, yeah. But then you'd have a system that couldn't be updated in the field without destroying the customer data (i.e. you'd have a secure boot implementation that couldn't receive bug fixes at all). It's a chicken and egg problem. You're handling the problem of the "iPhone" not being a 100% snoop-and-tamper-proof device by positing the existence of an "interior" snoop-and-tamper-proof device. But that doesn't work, because it's turtles all the way down. Ultimately you have to get to a situation where there is a piece of hardware (hardware on a single chip, even) making this determination in a way that has to be 100% right from the instant the devices go out the door. And that's not impossible, but it's asking too much, sorry. We're never going to get that.
tlrobinson 11y ago
The "bootstrap security engine" could store a hash of the blob in it's secure flash storage, and only update the hash if the user enters their pin, then reload the firmware blob. If the stored hash and blob hash ever don't match on boot, wipe the keys.

zabuni 11y ago

The device in question does not have a secure enclave. It's a 5c.

d_theorist 11y ago
But it's more interesting to think about the case where the phone does have a secure enclave.
- conradev 11y ago
  and yet it would be less interesting to consider if the password was a "six-character alphanumeric passcode with lowercase letters and numbers" because even if the software rate-limiting was disabled with a rogue firmware update, the PBKDF2 or similar iteration count makes brute-forcing impractical. > A large iteration count is used to make each attempt slower. The iteration count is calibrated so that one attempt takes approximately 80 milliseconds. This means it would take more than 51⁄2 years to try all combinations of a six-character alphanumeric passcode with lowercase letters and numbers (Page 12 of https://www.apple.com/business/docs/iOS_Security_Guide.pdf https://www.apple.com/business/docs/iOS_Security_Guide.pdf).
- bluesaunders 11y ago
  In that case, they could just bring the phone down to the morgue and unlock it with touch id.
  - mef 11y ago
    Touch ID requires the passcode after reboot or timeout. They'd need to do it very quickly.
  - lololomg 11y ago
    If the phone is rebooted or if 48 hours have passed since the last passcode was entered, the touch ID can't be used to unlock the phone.
  - katbyte 11y ago

dntrkv 11y ago

Fingerprint scan really isn't enough though since after a restart, iPhones require the password to be entered.

mentat 11y ago
Because fingerprints are not sufficient to generate / recover KEKs from.