5 ms·

One thing I don't understand is, what prevents the FBI (or Apple or anyone else) from duplicating the contents of the iPhone in question to a virtual machine, t

One thing I don't understand is, what prevents the FBI (or Apple or anyone else) from duplicating the contents of the iPhone in question to a virtual machine, then trying the 10,000 possible 4-digit unlock combinations on virtual machines until they find the correct one? I assume that since this seems like a fairly easy solution that it's not possible, but what makes it not possible?

tbassetto 11y ago
Wouldn't your solution also duplicate the fact that the iPhone should erase its memory after 10 failed attempts?
- atourgates 11y ago
  Right, but my assumption is that you'd just be able to load up a new VM every 10 failed attempts.
ksk 11y ago
Just a guess :- Maybe the decryption needs to happen through means present on the device and not in any old VM. Maybe the decryption requires multiple keys :- the 4 digit code, a per-device key, a per-session key generated on every boot-up, etc. And they all could be stored such that they never leave the h/w making sniffing difficult.
vlod 11y ago
Not sure if 100% applies to the iPhone in question, but the secure enclave was designed to prevent this sort of thing. Here's an intro to it: https://www.mikeash.com/pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html https://www.mikeash.com/pyblog/friday-qa-2016-02-19-what-is-...
- jml7c5 11y ago
  This applies to later models of iPhone; the 5c doesn't have a secure enclave. All password attempt limiting and erasure of data is implemented by the operating system.
  - mikeash 11y ago
    The 5c still has the secret UID baked into the chip. The escalating artificial delays are implemented by the OS and can be circumvented, but the secret UID is designed to make it impossible to extract. Without that UID, then you're brute-forcing a 256-bit AES key, not a 4-6 digit passcode. Practically, the brute forcing can only be done on the actual iPhone.
- squeaky-clean 11y ago
  The iPhone in question doesn't have Secure Enclave, but has similar principles to it. Like others have said, the users password is entangled with a key unique to the phone, which can't be read through software. On iPhones with Secure Enclave, not only is the device-specific key stored there, but also the logic which keeps track of the number of and time between repeated failed attempts. On older iPhones, this logic is a part of iOS itself, hence why Apple is capable of overriding it with a modified iOS.
kec 11y ago
The users passcode is entangled with a key unique to the hardware of the phone to generate the actual key used to encrypt the device. The hardware key is implemented such that it's impossible to read out via software.
- deleted 11y ago
  [deleted]

tbassetto 11y ago

Wouldn't your solution also duplicate the fact that the iPhone should erase its memory after 10 failed attempts?

atourgates 11y ago
Right, but my assumption is that you'd just be able to load up a new VM every 10 failed attempts.

ksk 11y ago

Just a guess :- Maybe the decryption needs to happen through means present on the device and not in any old VM. Maybe the decryption requires multiple keys :- the 4 digit code, a per-device key, a per-session key generated on every boot-up, etc. And they all could be stored such that they never leave the h/w making sniffing difficult.

vlod 11y ago

Not sure if 100% applies to the iPhone in question, but the secure enclave was designed to prevent this sort of thing. Here's an intro to it: https://www.mikeash.com/pyblog/friday-qa-2016-02-19-what-is-the-secure-enclave.html https://www.mikeash.com/pyblog/friday-qa-2016-02-19-what-is-...

jml7c5 11y ago
This applies to later models of iPhone; the 5c doesn't have a secure enclave. All password attempt limiting and erasure of data is implemented by the operating system.
- mikeash 11y ago
  The 5c still has the secret UID baked into the chip. The escalating artificial delays are implemented by the OS and can be circumvented, but the secret UID is designed to make it impossible to extract. Without that UID, then you're brute-forcing a 256-bit AES key, not a 4-6 digit passcode. Practically, the brute forcing can only be done on the actual iPhone.
squeaky-clean 11y ago
The iPhone in question doesn't have Secure Enclave, but has similar principles to it. Like others have said, the users password is entangled with a key unique to the phone, which can't be read through software. On iPhones with Secure Enclave, not only is the device-specific key stored there, but also the logic which keeps track of the number of and time between repeated failed attempts. On older iPhones, this logic is a part of iOS itself, hence why Apple is capable of overriding it with a modified iOS.

kec 11y ago

The users passcode is entangled with a key unique to the hardware of the phone to generate the actual key used to encrypt the device. The hardware key is implemented such that it's impossible to read out via software.

deleted 11y ago
[deleted]