• Announcements

  • Claims made by forensics companies, their capabilities, and how GrapheneOS fares

Joined just to post about this!

Instant password retrieval on iPhone
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.

Obviously there’s at least two flaws for IPR to even work in the first place (usb vulnerability and then being able to dump the passcode from somewhere which is very weird).

Secure Enclave timing delay
Apple’s platform guide says the delay is about 80ms and is due to iterations rather than a timer. Not sure which models this came in on but it seems to be at least from iPhone 12. Perhaps “supersonic” in their marketing material just means -12 attempts per second with a smart list of passcodes and no regular reboots required. Also clearly the secure storage component 2 (counter lockboxes) in iPhone 12 and above have put an end to brute forcing from then on.

My take on the slides is that iPhone 12 and above, on any iOS version, is safe if lockdown mode is on, or if lockdown mode is off is safe if it’s been an hour since the last lock or is put into sos mode (or rebooted and in bfu obviously). That said I hope they find and fix the IPR vulnerabilities…

    Bozo

    Can’t seem to edit it again and want to post a correction..

    Apple’s platform guide says it takes about 80ms to entanglement the passcode with the device UID and is due to iterations rather than a timer. Separately there are escalating timers for repeated failed passwords. 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.

    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.

        @DeletedUser115 A BFU extraction doesn't mean a typical extraction when the device is BFU, rather it is a special type of extraction to get a limited amount of data available by a device in BFU state. It's a weird misnomer and it could be more specific. If a forensics tool can brute force a device successfully from BFU, then they are performing an Unlocked extraction since they unlocked the device first.

        With BFU you're booting into the operating system to decrypt it. A very small footprint of the OS is encrypted by the device and not by a user's own credentials.

        A BFU extraction is to extract that particular data. Usually it provides very limited information about the OS and other device-encrypted data like app APKs (user/app data cannot be seen, only that the app is installed on a profile)

        As described in the document they have a method of extracting that data for the stock OS, but not GrapheneOS.

        DeletedUser115 What does it mean? I am reading "BF No" as secure element time limiter is holding up and prevents them brute forcing all possible PIN combinations.

        If that's the case, what does "BFU Yes" mean? How they can extract the data in BFU state without knowing the PIN and without an ability to brute force it?

        BFU Yes and BF Yes: Can extract the limited BFU- available data and could brute force the device to try and turn it Unlocked. Whatever the 'Unlocked' extraction capabilities are on the table follows afterward, but obviously you should expect it to be FFS.

        BFU Yes and BF No: Can BFU extraction but not brute force to unlock the device.

        AFU state in Cellebrite documents mean the device is in AFU state but is not unlocked / consent. If there is no BF support but AFU locked support is available, it implies a device has an exploit that can bypass. Example of this could be old lockscreen bypass vulnerability or iPhone IPR if there is no bruteforcing required for it.

            I am not blocked after 5 attemps
            "After 5 failed attempts, chip will add 30 second delay before next guessing attempt is allowed."

              Grkrz Are they legitimate attempts? Trying to enter a 2 digit PIN when the minimum is 4 doesn't count as an attempt.

                  • [deleted]

                  • Post #94

                  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]

                    • Post #95
                    • 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.

                    • Bozo replied to this.

                              [deleted]

                              [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]

                                    • Post #97

                                    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.

                                    • Bozo replied to this.

                                          [deleted]

                                          Thanks for the reply. In that case, ouch. It seemed almost too bad to be true :(

                                          And yes agree it’s on the usb side then.

                                            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 🌷

                                              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]

                                                  • Post #102

                                                  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.