I am not blocked after 5 attemps
"After 5 failed attempts, chip will add 30 second delay before next guessing attempt is allowed."
Claims made by forensics companies, their capabilities, and how GrapheneOS fares
Grkrz Are they legitimate attempts? Trying to enter a 2 digit PIN when the minimum is 4 doesn't count as an attempt.
[deleted]
Matthai You can cross reference with @GrapheneOS 's post https://grapheneos.social/system/media_attachments/files/112/462/760/076/651/069/original/abb6bfdb2d3cbc6a.png They referenced IPR here. You can also ping @Hathaway_Noa He has access to the complete capacity list.
[deleted]
Nuttso Doing that would only make sense, if we manage to not expose the account credentials unencrypted, that are necessary to identify the account and be able route the messages to it.
For the google play notification version, the push notification token can be secured with NSFileProtectionCompleteUntilFirstUserAuthentication along with the temporary pending database to allow content preview while the permanent database can be secured with NSFileProtectionComplete.
Or if no message preview was required, everything except this push token can be secured with NSFileProtectionComplete because no message needs to be downloaded until the app was unlocked. This way, the only thing exposed in AFU is the push token which cannot be used to decrypt any past or future messages.
I'm not too familiar with the web socket implementation. But I assume only some sub-key is used for authentication rather than the master key? So only this key can be secured with NSFileProtectionCompleteUntilFirstUserAuthentication. Furthermore, even if the profile master key were to be compromised, it would still maintain forward secrecy if the chat database was protected with NSFileProtectionComplete
[deleted]
- Edited
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.
[deleted] 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.
That’s another possibility. My thinking was it must be unlikely cellebrite can attack the device over usb with the data pins disabled by it being in restricted mode. It seems the usb attack surface should be somewhere between non existent and very small. Possibly it’s a different vuln via Bluetooth or something?
Cellebrite may not be inclined to highlight how restricted the feature is - I didn’t see where they said the timing is a range where was that? If so it hints your idea has merit re overwriting memory. Seems like a really basic bug though :(
[deleted]
Bozo That’s another possibility. My thinking was it must be unlikely cellebrite can attack the device over usb with the data pins disabled by it being in restricted mode. It seems the usb attack surface should be somewhere between non existent and very small. Possibly it’s a different vuln via Bluetooth or something?
I believe it's usb based because it stated to plug all devices to premium as soon as possible to do IPR.
Bozo I didn’t see where they said the timing is a range where was that?
Forensic examiners have been discussing this in the cellebrite private community. It's not a precise time but definitely way longer than one hour.
final BFU Yes and BF No: Can BFU extraction but not brute force to unlock the device.
Thank you for explaining it, it makes much more sense now 🌷
matchboxbananasynergy ok that works 😁, thank you for clarification.
Thank you for the response.
GrapheneOS We do still recommend people who need their data secure indefinitely use a strong passphrase
One thing that I am curious about is if it would be possible to increase the key derivation complexity to further frustrate an offline brute-force attack if desired by the users threat model (i.e similar to --iter-time with LUKS). Or is it a matter of the Titan chip doing it internally better than host CPU ever could and the number of iterations or if it is adjustable is unavailable?
[deleted]
Finally!!! I just tested the feature and it works perfect. Thank you GrapheneOS developers!!!
popsicleman The scrypt parameters can be increased but the final key derivation happens in the TEE via hardware-bound key derivation that's meant to prevent offloading it to a server farm even if the TEE firmware is exploited. It's not the secure element doing it but rather the TEE to take advantage of the SoC cryptographic hardware performance. We haven't looked into the precise details of this on current generations. We can't change the parameters for that at the moment. We can only increase scrypt time and memory, and bear in mind it runs on every unlock.
@matchboxbananasynergy I just saw the threadlock on the PG forum. I didn't know about the MSAB marketing video until I saw the PC Mag article you linked. Can you point me to where the video is currently being mirrored? I'd like to keep it for posterity.
Agility8200 You're likely to find it if you search for "MSAB Monday wasted" or something similar on Yandex. MSAB realized they messed up and tried to scrub it, but they couldn't do it completely. The video is archived regardless, but that's where someone can find it on the Internet at the moment.
matchboxbananasynergy Thank you I will have a look.
Suppose I have a Pixel 8 Pro (latest GrapheneOS) seized by law enforcement in an authoritarian country.
Suppose I told them the password for the owner profile but not the password for the second profile (for confidential use).
I have two questions here.
1 Can they run an FFS extraction on the Cellebrite or Grayshift device to access the second profile?
2 After the device is returned, do I need to put the device in Airplane mode before hitting the password to counteract GrayKey's Hide UI, and on top of that, once I revert to stock OS and install GrapheneOS again?
TitanMPro 2, I doubt this is necessary but I would revert that to stock, chuck it away and get another phone. If I was in a situation where that scenario happened, and I was worried that the oppressive regime would add some kind of spyware, there is no way I would feel comfortable using the phone again. No doubt thats overkill and a factory wipe would solve any issues but I would still feel watched.
TitanMPro 2 After the device is returned, do I need to put the device in Airplane mode before hitting the password to counteract GrayKey's Hide UI, and on top of that, once I revert to stock OS and install GrapheneOS again?
When they handed it to me, I would restart it instantly. After that I would factory reset it and sell it.
Realistically you are probably safe if you just restart it. I doubt GrayKey can survive Verified Boot.
One question is whether it is possible to confirm whether the password given is a duress password.
My understanding is that after the system is running, the system program detects the duress password and executes an operation to destroy the data in the security chip.
If the system is not running, remove the security chip and simulate the system to input the password to the security chip. If it is a duress password, the security chip will return a password error, and the duress password will be exposed.
If the attacker knows that the mobile phone system is GrapheneOS, he will know that the password handed over may be a duress password, and thus perform such a test.
I am not sure whether the security chip has a function like environmental detection. Only when the system is detected to be intact will subsequent operations be performed. If there is such a function, then add a middleman in the communication link between the system and the security chip, normal operations are allowed to pass, and operations such as destruction are directly discarded, which can also prevent the key in the chip from being destroyed.