Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone
1–10 of 364 posts
Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone
#2Eh? 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
#3Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone
#4On 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
#5So 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?
"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
#6Remember, 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…
Re: Apple ordered to bypass auto-erase on San Bernadino shooter's iPhone
#7So 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.
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
#8Remember, 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?
> 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
#9Remember, 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
#10Earlier 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…