Bozo One of the slides (if legit) underlines that this is a time sensitive feature. I suspect that this feature exploits the phone via usb/lightning and the time sensitivity is due to usb restricted mode. So when the phone is in usb restricted mode, IPR is not possible. USB restricted mode starts an hour after certain events like locking the device. If lockdown mode is enabled, usb restrictions are immediate after locking the device. It also activates when doing the button combination to enter sos mode.
This is a good guess but unfortunately no, IPR can bypass USB restricted mode. Because 1. AFU extraction has no time limit, which means that Cellebrite for sure can defeat USB restricted mode already 2. Most users would have usb restricted mode without the one hour delay In addition, if it’s been more than 3 days since a data connection has been established with an accessory, the device will disallow new data connections immediately after it locks. This is to increase protection for users that don’t often make use of such accessories. 3. Cellebrite stated that the timing was a range rather than a precise one hour number.
I speculate that the time sensitivity and uncertainty is due to memory being overwritten. Even with secure enclave code execution, the plaintext passcode shouldn't be recovered if Apple had implemented it correctly. Because only the passcode verifier value i.e hash of (passcode + salt) is saved by the Secure Storage Component. However, Cellebrite specifically claims they can get iPhone plaintext passcode, suggesting AP RAM or Secure Enclave RAM is not clearing iPhone passcode properly after user input.
Bozo Possibly, “supersonic” in cellebrite’s marketing material means -12 attempts per second by avoiding the escalating delay part but is still stuck with the 80ms iteration part.
You're correct. The normal BF can bypass secure enclave's delay but takes significantly longer. This is also why I'm strongly pushing the iteration count increase in Pixel and GrapheneOS.
[deleted] I feel this is a critical last line of defense and this is the only timing delay enforced by cryptography instead of code integrity albeit on processors with smaller attack surface. The Supersonic BF on iPhone has almost the same speed as the 80ms theoretical hardware key derivation speed quoted by Apple. This means all other secure enclave based mitigations have been bypassed and the only line of defense against a truly unlimited speed brute force is this cryptography enforced iteration count. Perhaps @GrapheneOS team can ask Pixel team to publish this data and increase the timing delay to at least Apple's 80ms standard, which has negligible user impact
Bozo Also clearly the secure storage component 2 (counter lockboxes) in iPhone 12 and above have put an end to brute forcing by hard limiting passcode attempts to 10 in a way that hasn’t been worked around by Cellebrite.
Yes, the attack surface of the secure storage component 2 seems to be small enough compared to the secure enclave and is holding strong. However, with IPR, it's almost useless.