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

taiyi According to the information from Cellebrite, the Pixel 6 and later prevent them from doing a brute force via their time-based secure element throttling whether or not they use GrapheneOS. No other devices are successfully preventing them from doing this. If you want to prevent this even if they get a secure element exploit, use a strong diceware passphrase. This will become much more convenient soon via our 2-factor fingerprint unlock feature where you'll be able to use fingerprint+PIN for secondary unlock after first unlock instead of being able to unlock with only a fingerprint which is problematic.

They can exploit the stock Pixel OS either BFU or AFU but not GrapheneOS since late 2022. It doesn't mean that it will hold forever. We're continuing to improve security against these attacks and they're continuing to work on developing exploits. We've been making major improvements such as our new USB-C port control feature which have hopefully destroyed lots of their progress and forced them to essentially start over.

It should be kept in mind that mobile devices do not have encrypted memory yet, only non-cryptographically-secure scrambling at best, so it's theoretically possible for them to extract data directly from memory if the device is AFU although that won't give them the ability to unlock the device or get all data. If they developed the capability to arbitrarily modify memory, they could get it unlocked if it's AFU, without any direct OS/firmware exploits. Encrypted memory is a feature we hope gets added in the next couple years. There's still the attack vector of directly tampering with the SoC but it will raise the bar a lot.

    Nuttso "if we get a message with an attachment while the device is locked, we can't save it to the temporary directory because of NSFileProtectionComplete".

    You're correct the attachment is protected with only NSFileProtectionCompleteUntilFirstUserAuthentication. This is documented by forensic tools. On the other hand, I believe that the text database is protected with NSFileProtectionComplete because FFS extraction is needed for the text database.

    Unlike all of those other messengers, Signal encrypts its working databases. The encryption key is generated the first time the user signs in to Signal on the device. The key is then stored in the keychain, protected with a high protection class. Without that key one can only extract attachments (pictures, documents, voice messages etc.)
    https://blog.elcomsoft.com/2019/08/how-to-extract-and-decrypt-signal-conversation-history-from-the-iphone/

    Cellebrite claims that only FFS extraction gives whatsapp text database while the AFU extraction is enough for attachment. https://cellebrite.com/en/deep-dive-into-whatsapp/ 10:30

      DeletedUser115 It doesn't mean it will hold forever. The only defense against long term vulnerabilities is a strong diceware passphrase + BFU.

      GrapheneOS They can exploit the stock Pixel OS either BFU or AFU but not GrapheneOS since late 2022. It doesn't mean that it will hold forever.

      This is why I suggested that hardware bound key derivation iteration count should be published and increased to guard against BF by cryptography.

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

      [deleted]

      [deleted] You're correct the attachment is protected with only NSFileProtectionCompleteUntilFirstUserAuthentication. This is documented by forensic tools. On the other hand, I believe that the text database is protected with NSFileProtectionComplete because FFS extraction is needed for the text database.

      You are drawing the wrong conclusions. I have sent you the exact place in the code where the complete database is downgraded. They didn't split the database/storage, and use a public-private temporary key model. They just removed the maximum protection flag and moved on.

        • [deleted]

        • Edited

        Nuttso That's quite unfortunate. For Molly, is it possible to implement spliting the database/storage, and use a public-private temporary key model and protect the permanent database with a key that requires unlock in strongbox? Or if the user opt in to use the notification without any content preview or sender preview, enforce unlock for all keys except the notification token. I doubt many privacy conscious Molly users use message content preview anyway

          [deleted] yes ofc it is, but it doesn't make sense to implement it now. We didn't touch the data model at all. We will lose backup compatibility and we would need to do a lot more testing before releasing builds. We already have some ideas how this can be approached. But it's currently not possible with signals sever infrastructure.

            [deleted]

            Hi, you ar esaying that Cellebrite specifically claims they have been able to extract plaintext iPhone passcode (Instant Passcode Retrieval) from AFU iPhone since A11 and that they are able to dump Secure Enclave RAM since A11.

            Can you point me to some sources?

              Hi @Matthai,

              Thanks for posting the content of the article you wrote, but would it be possible to start a new discussion? I think it would be better to have a dedicated thread for your article. So, in the meantime, I'll remove it from this thread.

              • [deleted]

              Matthai

              Matthai Cellebrite specifically claims they have been able to extract plaintext iPhone passcode (Instant Passcode Retrieval) from AFU iPhone since A11

              yes, source https://postimg.cc/gxNXN4MK

              Matthai they are able to dump Secure Enclave RAM since A11

              Hathaway_Noa I uploaded all the necessary PDF files detailing their capabilities / release notes + how to use on the following link:

              https://easyupload.io/m/t94ht1

              With every new Cellebrite Premium / Inseyets updateI will upload the PDF files :)

              Because they're able to BF in BFU mode, it necessarily implies that they can bypass secure enclave's timing delay. This strongly implies that they have code execution on secure enclave because "the Secure Enclave Processor, starting with the A11 and S4, includes a memory-protected engine and encrypted memory with anti-replay capabilities"

                • [deleted]

                Nuttso But it's currently not possible with signals sever infrastructure.

                Why would the splitting the database/storage, and using a public-private temporary key model be incompatible with server infrastructure?

                Nuttso We will lose backup compatibility

                If splitting the database/storage, and using a public-private temporary key model is implemented, could this be merged upstream to signal? There should be no UX difference or any impact on existing signal users

                  [deleted]

                  Sorry, but I am not fully satisfied by this source. I believe you, but this just looks like a random picture posted somewhere on the internet. Do you have any source on Cellebrite's site or in their documents?

                    [deleted] yes, source https://postimg.cc/gxNXN4MK

                    I'm not sure anyone in their right mind could consider that an anonymously posted graphic with some words on it is a particularly reliable 'source'.

                    One thing I noticed that the page about iPads doesn't mention Instant Passcode Retrieval. That makes me wonder if iPad have something that makes it harder to pull off IPR or they just didn't spend enough time on them because iPhones are higher priority?

                    I was looking at their Android booklet again, for Pixel 6+ on Stock OS, BFU it says:

                    BFU Yes
                    BF No

                    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?

                      [deleted] Why would the splitting the database/storage, and using a public-private temporary key model be incompatible with server infrastructure?

                      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. The server needs to know where to route massages. It is possible to have encrypted credentials, but we need the compatibility on the server side to do it right.

                      [deleted] If splitting the database/storage, and using a public-private temporary key model is implemented, could this be merged upstream to signal? There should be no UX difference or any impact on existing signal users

                      That would be necessary before we could do it. Signal doesn't really care about the client.

                        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.