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

taiyi That simply isn't true. The entire purpose of GrapheneOS is to add security and privacy features and hardening on top of AOSP. It's the entire reason it exists.

This very thread contains proof that explains that Cellebrite has capabilities on stock, but doesn't have those same capabilities on GrapheneOS. Please take a look at the post again, particularly the attached images.

    matchboxbananasynergy
    I'm a Chinxxx, and my threats mode against goverment law enforcement. Thanks to GFW's help for Chinxxx people and the Chinxxx government's suppression of freedom of speech, Chinxxx have a lot of experience with security and anonymity in the online part of the world.
    In this case, if my goal is to keep law enforcement from securing a local device if I refuse to provide the unlock code when they want to check the phone, which do you think is a better choice, GrapheneOS or iphone?

      taiyi In either case, make sure to use a strong diceware passphrase and keep the device in BFU mode as much as practical.

      GOS on a Pixel 6+ device seems better in terms of security than a latest iPhone with latest iOS but both options are very good.

        [deleted] On iOS, Signal chat database on iOS uses NSFileProtectionComplete. Only FFS yields Signal database on iOS not AFU extraction.

        That's wrong. Signal iOS is using "NSFileProtectionCompleteUntilFirstUserAuthentication".

        Link

        Even when the temp directory is originally created with NSFileProtectionComplete, they downgrade the security to NSFileProtectionCompleteUntilFirstUserAuthentication because:
        "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".

        Link

        It works the same as on Android. You need the key from the keystore to be able to read Molly's database even when authentication is not enforced.

          evalda
          Thanks!
          I have set the device to reboot every 10 minutes and used a password that I think is long enough. According to the chart grapheneOS also prevents BF (Brute-Force, if I understand BF correctly).

            taiyi GOS does prevent BF at the time of writing. It doesn't mean it will hold forever. The only defense against long term vulnerabilities is a strong diceware passphrase + BFU.

              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

                  evalda 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?