5 ms·

Law enforcement officials could, until recent iOS updates, unlock iPhones by brute-forcing passcodes with a device attached to the Lightning port. The phone was

Law enforcement officials could, until recent iOS updates, unlock iPhones by brute-forcing passcodes with a device attached to the Lightning port. The phone was likely not updated to the latest iOS builds. So wouldn't Apple be able to do the same?

eli 8y ago
The implication is that the police device uses a flaw unknown to Apple (lest they fix it). It is not normally supposed to be possible to brute force passcodes like that.
cc-d 8y ago
What measures are in place to prevent the FBI from imaging a phone, and then brute forcing every possible pin combination? Would these measures be able to stand up against a team of reverse engineers, with near unlimited resources, which I assume the FBI would be able to find for the task? Other avenues of gaining potentially useful data will be utilized as well. Does the FBI have access to data stored on Apple's cloud servers? What about the fingerprints of the suspect, or other methods of bioidentification?
- thisacctforreal 8y ago
  The pin code gets entagled with a unique per-device key Apple calls the UID, the combination is what encrypts the data on-device. Only the Secure Enclave has access to the UID, but only through silicon, it can't read the key bytes. The Cellebrite rigs do use the Secure Enclave to brute force, but they're acheiving roughly 1s/guess, and the theoretical fastest is 80ms because the Secure Enclave uses PBKDF2 iterations tuned for that time. If you have a long numeric passcode or an alphanumeric passphrase you can be confident your iPhone is secure when it's off.
- eugeniub 8y ago
  As thisacctforreal mentioned, both the PIN and the device UID are used to generate the actual encryption key. Even if someone were to get access to the UID, the amount of processing to generate an encryption key for each PIN possibility would be costly, so it may be the case that simply bruteforcing would take prohibitively long. I know that on an iOS device itself, if passcode attempt limits didn't exist, it takes a whole 90 milliseconds to check each passcode. That's only 10 passcode attempts a second, and if the passcode is sufficiently long, it could take years.
  - simcop2387 8y ago
    It's trivially parallelized if you've got the data and the device uid extracted. Combined with more powerful cpus, it could easy end up 10k pins per second if you can try to decrypt it (or verify it) externally. Combine that with most people's lackluster pin selection and length you've probably got the ability to unlock a phone in a few minutes to hours. EDIT: removed bad math
    - eugeniub 8y ago
      You'd have to have a very powerful CPU for a 1000-fold increase over a modern iPhone.
      - simcop2387 8y ago
        Not as much as you might think, the iPhone is going to be doing a single decryption and checking action per attempt. If this takes 90 milliseconds because it's also going out to the secure chip to do the key derivation with the device uid so that the cpu and main ram never sees all the information to derive the full key on it's own then once you have both of those pieces of information (as was stated in this hypothetical) then you've eliminated the slow communication and slower processor involved. This could easily mean you can now do the derivation of the key in a much quicker fashion (I'd be surprised if it's not 10s to 100s of microseconds). But that's assuming that the bulk of the time isn't being spent on something like a modern key derivation function from the user's pin which is quite possibly a bad assumption (nobody knows these details outside Apple as far as I know). So let's say it's that, we've now got maybe 80ms of real cpu time on the iphone (not counting the communication to secure chip). This is still going to just be one core of the iphone's cpu doing this (no parallel KDFs that I'm aware of) and it's still trivially parallelizable. I don't know exact specs but lets say a modern intel cpu is going to be only 4x faster at this KDF because apple put in special cpu hardware to help accelerate it and other crypto operations. Now we multiply that by however many cores we can get (RAM isn't going to be an issue here even if it's a memory safe KDF, on a real computer or server we can always add more, terabytes if needed). So at this point we've got ~10-12 checks per second (80ms) times 4 for just the single core speedup, and then we can multiply that by the number of cores/threads we can throw at it, 256 wouldn't be too hard to get at (amd 2x epyc 64 core cpus). That gets us to 10240-12284 password checks per second. Even if that 4x is 2x or 1.5x it's still relatively easy to just throw some more servers at it since the actual check is so trivial to do in parallel. This would be very easy to be within a state actor or even a large corporation's budget if they had the need. That's why Apple is so hard on making the secure chip they use for the encryption and holding the device uid. It's really the only thing that can keep that from being within a $10k-15k budget to break a bad passcode/pin. If they aren't using a modern KDF that has memory safety, branch safety, and other defenses in it then all the above goes out the window since you can now throw some really cheap GPUs and do it in parallel at a scale that's even more insane. Have a look at some of the GPU benchmarks for John the Ripper https://openwall.info/wiki/john/GPU https://openwall.info/wiki/john/GPU
- jlgaddis 8y ago
  > What measures are in place to prevent the FBI from imaging a phone, and then brute forcing every possible pin combination? In short, physics. It's not the PIN they'd have to brute force, but the encryption key... and that's where physics comes in.

eli 8y ago

The implication is that the police device uses a flaw unknown to Apple (lest they fix it). It is not normally supposed to be possible to brute force passcodes like that.

cc-d 8y ago

What measures are in place to prevent the FBI from imaging a phone, and then brute forcing every possible pin combination? Would these measures be able to stand up against a team of reverse engineers, with near unlimited resources, which I assume the FBI would be able to find for the task? Other avenues of gaining potentially useful data will be utilized as well. Does the FBI have access to data stored on Apple's cloud servers? What about the fingerprints of the suspect, or other methods of bioidentification?

thisacctforreal 8y ago
The pin code gets entagled with a unique per-device key Apple calls the UID, the combination is what encrypts the data on-device. Only the Secure Enclave has access to the UID, but only through silicon, it can't read the key bytes. The Cellebrite rigs do use the Secure Enclave to brute force, but they're acheiving roughly 1s/guess, and the theoretical fastest is 80ms because the Secure Enclave uses PBKDF2 iterations tuned for that time. If you have a long numeric passcode or an alphanumeric passphrase you can be confident your iPhone is secure when it's off.
eugeniub 8y ago
As thisacctforreal mentioned, both the PIN and the device UID are used to generate the actual encryption key. Even if someone were to get access to the UID, the amount of processing to generate an encryption key for each PIN possibility would be costly, so it may be the case that simply bruteforcing would take prohibitively long. I know that on an iOS device itself, if passcode attempt limits didn't exist, it takes a whole 90 milliseconds to check each passcode. That's only 10 passcode attempts a second, and if the passcode is sufficiently long, it could take years.
- simcop2387 8y ago
  It's trivially parallelized if you've got the data and the device uid extracted. Combined with more powerful cpus, it could easy end up 10k pins per second if you can try to decrypt it (or verify it) externally. Combine that with most people's lackluster pin selection and length you've probably got the ability to unlock a phone in a few minutes to hours. EDIT: removed bad math
  - eugeniub 8y ago
    You'd have to have a very powerful CPU for a 1000-fold increase over a modern iPhone.
    - simcop2387 8y ago
      Not as much as you might think, the iPhone is going to be doing a single decryption and checking action per attempt. If this takes 90 milliseconds because it's also going out to the secure chip to do the key derivation with the device uid so that the cpu and main ram never sees all the information to derive the full key on it's own then once you have both of those pieces of information (as was stated in this hypothetical) then you've eliminated the slow communication and slower processor involved. This could easily mean you can now do the derivation of the key in a much quicker fashion (I'd be surprised if it's not 10s to 100s of microseconds). But that's assuming that the bulk of the time isn't being spent on something like a modern key derivation function from the user's pin which is quite possibly a bad assumption (nobody knows these details outside Apple as far as I know). So let's say it's that, we've now got maybe 80ms of real cpu time on the iphone (not counting the communication to secure chip). This is still going to just be one core of the iphone's cpu doing this (no parallel KDFs that I'm aware of) and it's still trivially parallelizable. I don't know exact specs but lets say a modern intel cpu is going to be only 4x faster at this KDF because apple put in special cpu hardware to help accelerate it and other crypto operations. Now we multiply that by however many cores we can get (RAM isn't going to be an issue here even if it's a memory safe KDF, on a real computer or server we can always add more, terabytes if needed). So at this point we've got ~10-12 checks per second (80ms) times 4 for just the single core speedup, and then we can multiply that by the number of cores/threads we can throw at it, 256 wouldn't be too hard to get at (amd 2x epyc 64 core cpus). That gets us to 10240-12284 password checks per second. Even if that 4x is 2x or 1.5x it's still relatively easy to just throw some more servers at it since the actual check is so trivial to do in parallel. This would be very easy to be within a state actor or even a large corporation's budget if they had the need. That's why Apple is so hard on making the secure chip they use for the encryption and holding the device uid. It's really the only thing that can keep that from being within a $10k-15k budget to break a bad passcode/pin. If they aren't using a modern KDF that has memory safety, branch safety, and other defenses in it then all the above goes out the window since you can now throw some really cheap GPUs and do it in parallel at a scale that's even more insane. Have a look at some of the GPU benchmarks for John the Ripper https://openwall.info/wiki/john/GPU https://openwall.info/wiki/john/GPU
jlgaddis 8y ago
> What measures are in place to prevent the FBI from imaging a phone, and then brute forcing every possible pin combination? In short, physics. It's not the PIN they'd have to brute force, but the encryption key... and that's where physics comes in.