5 ms·

Anyone else a little surprised that apples security feature here is so easy to sidestep? I'd have thought, in the least, that any such keys were stored in the m

Anyone else a little surprised that apples security feature here is so easy to sidestep? I'd have thought, in the least, that any such keys were stored in the main processor without external read/write capabilities.

brk 11y ago
No, I'm not that surprised. I think this feature is intended to protect your personal data from the casual iPhone thief or to minimize risk if you lose/forget your iPhone somewhere. I don't think it was intended to be a secure-from-governments kind of features.
- deleted 11y ago
  [deleted]
- hollander 11y ago
  Guess again - it is! It's a work in progress, and on the 6S it has improved a lot with the secure enclave in its own chip. It seems it will get even better, with encryption in the icloud as well. The SE uses a different key for each app, so even if you can decrypt one key, you only get data from one app.
Titanous 11y ago
The feature exists to protect against less sophisticated attacks. It's not necessary, as setting a long alpha-numeric passphrase will mitigate brute force attacks.
nickysielicki 11y ago
It's a cheap phone from a couple years ago. This world is moving fast.
eridius 11y ago
FWIW, it's not easy to bypass on devices with TouchID. The Secure Enclave manages the process there, and it's designed to be resistant to tampering so you can't use this trick with it.
- mikeash 11y ago
  It looks likely that the Secure Enclave has no storage of its own, so this same attack would still apply. What would make you secure here is having a password sufficiently long and complex to make brute forcing infeasible. Touch ID facilitates that by making it practical to use the device even with a strong password set. But if you have a four or six-digit passcode set on such a device, then this technique should still work fine.
  - eridius 11y ago
    I haven't done much research on this, but I thought the secure enclave actually did contain the key in question? I know the secure enclave enforces the 10 tries rule (and the timeout between tries), which suggests that the secure enclave is responsible for destroying the key when the rule is violated.
    - mikeash 11y ago
      As far as I know there's no official word on this. I say that it probably has no storage based on a couple of things: First, the iOS security guide makes no mention of any storage besides the flash. When it discusses key erasure, it's always about Effaceable Storage, which according to the guide is a dedicated area of NAND flash. Second, Apple says that the attack the FBI wants them to carry out could be made against all iPhones. If the Secure Enclave had its own storage, it would be trivial to have it wipe the device if the SE software was updated without a passcode, which would defeat the requested attack. It's possible that the SE has its own storage and Apple just didn't use it this way, of course. Or whoever said this on behalf of Apple could just be wrong that the more recent phones are vulnerable. The SE does enforce the escalating timeouts, and probably the wipe after ten tries, but that wipe could just be the SE telling the Effaceable Storage to erase the key.
      - eridius 11y ago
        The SE doesn't wipe when it's updated without a passcode because that would completely remove the ability to fix devices that get stuck at the "Connect to iTunes" screen without wiping it. And a non-trivial number of devices end up in that state every time Apple releases an OS update, so maintaining the ability successfully recover from this state without wiping the device is important. They can't just add a passcode entry to that screen because that screen is rendered by iBoot, which has no idea how to handle touch input or any of the other prerequisites for doing passcode entry (it can barely even draw that "Connect to iTunes" screen). And they can't add the passcode entry to iTunes without making it possible to send passcodes over the wire, which is exactly what the FBI has asked Apple to implement (well, that and disabling the wipe-after-10-failures bit). That said, you can bet that Apple is working on a fix for this for future devices. Some way for the Secure Enclave to know that the update was authorized by the user even if the device was subsequently bricked by the update and then recovered. With the ability to maintain proof of authorization even after the device is bricked, they can then make the SE wipe itself if it's updated without authorization.
DrJokepu 11y ago
…yet it's clearly more than enough to stop the FBI.
jonknee 11y ago
Not at all, I think it's pretty great that they're encrypted by default. Plus, newer iPhones are even more secure (with the dedicated Secure Enclave).

brk 11y ago

No, I'm not that surprised. I think this feature is intended to protect your personal data from the casual iPhone thief or to minimize risk if you lose/forget your iPhone somewhere. I don't think it was intended to be a secure-from-governments kind of features.

deleted 11y ago
[deleted]
hollander 11y ago
Guess again - it is! It's a work in progress, and on the 6S it has improved a lot with the secure enclave in its own chip. It seems it will get even better, with encryption in the icloud as well. The SE uses a different key for each app, so even if you can decrypt one key, you only get data from one app.

Titanous 11y ago

The feature exists to protect against less sophisticated attacks. It's not necessary, as setting a long alpha-numeric passphrase will mitigate brute force attacks.

nickysielicki 11y ago

It's a cheap phone from a couple years ago. This world is moving fast.

eridius 11y ago

FWIW, it's not easy to bypass on devices with TouchID. The Secure Enclave manages the process there, and it's designed to be resistant to tampering so you can't use this trick with it.

mikeash 11y ago
It looks likely that the Secure Enclave has no storage of its own, so this same attack would still apply. What would make you secure here is having a password sufficiently long and complex to make brute forcing infeasible. Touch ID facilitates that by making it practical to use the device even with a strong password set. But if you have a four or six-digit passcode set on such a device, then this technique should still work fine.
- eridius 11y ago
  I haven't done much research on this, but I thought the secure enclave actually did contain the key in question? I know the secure enclave enforces the 10 tries rule (and the timeout between tries), which suggests that the secure enclave is responsible for destroying the key when the rule is violated.
  - mikeash 11y ago
    As far as I know there's no official word on this. I say that it probably has no storage based on a couple of things: First, the iOS security guide makes no mention of any storage besides the flash. When it discusses key erasure, it's always about Effaceable Storage, which according to the guide is a dedicated area of NAND flash. Second, Apple says that the attack the FBI wants them to carry out could be made against all iPhones. If the Secure Enclave had its own storage, it would be trivial to have it wipe the device if the SE software was updated without a passcode, which would defeat the requested attack. It's possible that the SE has its own storage and Apple just didn't use it this way, of course. Or whoever said this on behalf of Apple could just be wrong that the more recent phones are vulnerable. The SE does enforce the escalating timeouts, and probably the wipe after ten tries, but that wipe could just be the SE telling the Effaceable Storage to erase the key.
    - eridius 11y ago
      The SE doesn't wipe when it's updated without a passcode because that would completely remove the ability to fix devices that get stuck at the "Connect to iTunes" screen without wiping it. And a non-trivial number of devices end up in that state every time Apple releases an OS update, so maintaining the ability successfully recover from this state without wiping the device is important. They can't just add a passcode entry to that screen because that screen is rendered by iBoot, which has no idea how to handle touch input or any of the other prerequisites for doing passcode entry (it can barely even draw that "Connect to iTunes" screen). And they can't add the passcode entry to iTunes without making it possible to send passcodes over the wire, which is exactly what the FBI has asked Apple to implement (well, that and disabling the wipe-after-10-failures bit). That said, you can bet that Apple is working on a fix for this for future devices. Some way for the Secure Enclave to know that the update was authorized by the user even if the device was subsequently bricked by the update and then recovered. With the ability to maintain proof of authorization even after the device is bricked, they can then make the SE wipe itself if it's updated without authorization.

DrJokepu 11y ago

…yet it's clearly more than enough to stop the FBI.

jonknee 11y ago

Not at all, I think it's pretty great that they're encrypted by default. Plus, newer iPhones are even more secure (with the dedicated Secure Enclave).