Live data from Hacker News

Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

techdirt.com

1–10 of 364 posts

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#2
> Apple ... will probably have little time to debug or test it overall, meaning that this feature it is being ordered to build will almost certainly put more users at risk.

Eh? They are not being asked to install it to the public at large, just one phone.

Of all reasons to object, this reason makes little sense.

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#3
So if I get this right, they want to (1) disable the delete feature after x retries (therefore enabling unlimited retries) and (2) enable to submit tries via a connector/wifi, bluetooth (therefore enabling a bruteforce approach). What good is an encrypted filesystem in that scenario?

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#4
Remember, this is an iPhone 5C, which doesn't have Touch ID or the Secure Enclave; the security model for this phone is significantly different from that of more recent iPhones.

On phones with a Secure Enclave, the wipe-on-failures state is managed in the coprocessor (which runs L4), and is not straightforwardly backdoor-able.

If you're worried about the police brute-forcing your phone, enable Touch ID and set a passcode that is approximately as complex as the one on your computer.

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#5
post #3

So if I get this right, they want to (1) disable the delete feature after x retries (therefore enabling unlimited retries) and (2) enable to submit tries via a connector/wifi, bluetooth (therefore enabling a bruteforce approach). What good is an encrypted filesystem in that scenario?

Plenty of good if you have a reasonable passphrase and the vendor hasn't been compelled to assist.

"Can only try 10 times" isn't anything guaranteed by encryption. My laptop has an encrypted partition, but an attacker can brute-force it at will. Even if I had software to say "only let it happen 10 times, then erase the partition" the whole drive could just be cloned. That's why I have a 20+ character passphrase.

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#6
post #4

Remember, this is an iPhone 5C, which doesn't have Touch ID or the Secure Enclave; the security model for this phone is significantly different from that of more recent iPhones. On phones with a Secure Enclave, the wipe-on-failures state is managed in the coprocessor (which runs L4), and is not straightforwardly backdoor-able. If you're worried about the police brute-forcing your phone, enable Touch ID and set a pass…

Wouldn't Apple (or the manufacturer) know the key of the security enclave?

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#7
post #3

So if I get this right, they want to (1) disable the delete feature after x retries (therefore enabling unlimited retries) and (2) enable to submit tries via a connector/wifi, bluetooth (therefore enabling a bruteforce approach). What good is an encrypted filesystem in that scenario?

Plenty of good if you have a reasonable passphrase and the vendor hasn't been compelled to assist. "Can only try 10 times" isn't anything guaranteed by encryption. My laptop has an encrypted partition, but an attacker can brute-force it at will. Even if I had software to say "only let it happen 10 times, then erase the partition" the whole drive could just be cloned. That's why I have a 20+ character passphrase.

Apple goes way out of their way to avoid scenarios where they can be compelled to subvert iOS security. For instance, see pg44+ of the iOS security white paper:

https://www.apple.com/business/docs/iOS_Security_Guide.pdf

... the HSMs that manage the escrow scheme for credentials stored in iCloud are themselves rigged to blow up on 10 failed tries, and, not only that, but the code that implements that process is burned into the HSMs and the keys Apple would need to change that logic have been destroyed.

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#8
post #4

Remember, this is an iPhone 5C, which doesn't have Touch ID or the Secure Enclave; the security model for this phone is significantly different from that of more recent iPhones. On phones with a Secure Enclave, the wipe-on-failures state is managed in the coprocessor (which runs L4), and is not straightforwardly backdoor-able. If you're worried about the police brute-forcing your phone, enable Touch ID and set a pass…

Wouldn't Apple (or the manufacturer) know the key of the security enclave?

No. From Apple's iOS security guide[1]:

> The device’s unique ID (UID) and a device group ID (GID) are AES 256-bit keys fused (UID) or compiled (GID) into the application processor and Secure Enclave during manufacturing. No software or firmware can read them directly; they can see only the results of encryption or decryption operations performed by dedicated AES engines implemented in silicon using the UID or GID as a key. Additionally, the Secure Enclave’s UID and GID can only be used by the AES engine dedicated to the Secure Enclave. The UIDs are unique to each device and are not recorded by Apple or any of its suppliers. ... Integrating these keys into the silicon helps prevent them from being tampered with or bypassed, or accessed outside the AES engine. The UIDs and GIDs are also not available via JTAG or other debugging interfaces.

Even for older devices like the iPhone 5C, if the owner chose a good passphrase, I doubt it can be decrypted with Apple's help.

1. From the section on Encryption and Data Protection. Starts on page 10: https://www.apple.com/business/docs/iOS_Security_Guide.pdf

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#9
post #4

Remember, this is an iPhone 5C, which doesn't have Touch ID or the Secure Enclave; the security model for this phone is significantly different from that of more recent iPhones. On phones with a Secure Enclave, the wipe-on-failures state is managed in the coprocessor (which runs L4), and is not straightforwardly backdoor-able. If you're worried about the police brute-forcing your phone, enable Touch ID and set a pass…

Wouldn't Apple (or the manufacturer) know the key of the security enclave?

Nope. The keys are personalized to the device at manufacture and, according to Apple, not retained.

Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone

#10
post #7

Earlier quoted context omitted.

Plenty of good if you have a reasonable passphrase and the vendor hasn't been compelled to assist. "Can only try 10 times" isn't anything guaranteed by encryption. My laptop has an encrypted partition, but an attacker can brute-force it at will. Even if I had software to say "only let it happen 10 times, then erase the partition" the whole drive could just be cloned. That's why I have a 20+ character passphrase.

Apple goes way out of their way to avoid scenarios where they can be compelled to subvert iOS security. For instance, see pg44+ of the iOS security white paper: https://www.apple.com/business/docs/iOS_Security_Guide.pdf ... the HSMs that manage the escrow scheme for credentials stored in iCloud are themselves rigged to blow up on 10 failed tries, and, not only that, but the code that implements that process is burned…

Informative. Thanks!
Post reply on HN