• Announcements

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

de0u Thank you for your reply!

Reading https://grapheneos.org/faq#encryption

The owner profile is special and is used to store sensitive system-wide operating system data. This is why the owner profile needs to be logged in after a reboot before other user profiles can be used.

I was hoping that some key material for secondary user profiles would be stored in the Owner profile and encrypted with the Owner passphrase. I guess that is not really the case, would be good to get an official confirmation from GrapheneOS team.

If we assume that secondary profiles encryption key is based solely on 1) User lock method (6-digit PIN in my example) and 2) Secret in secure element that it won't release until supplied correct 1) or compromised. If this is how it works and no further secret from the Owner profile is needed, it does sound like a compromised secure element would lead to brute-forcing PIN and decryption of the secondary profile data. Now the question is whether device has to be disassembled to perform this attack?

  • de0u replied to this.

      DeletedUser115 Now the question is whether device has to be disassembled to perform this attack?

      I don't believe so (which is why I wrote "etc."). Compromising hardware security via an exploit is also theoretically possible.

        DeletedUser115 I was hoping that some key material for secondary user profiles would be stored in the Owner profile and encrypted with the Owner passphrase. I guess that is not really the case, would be good to get an official confirmation from GrapheneOS team.

        Ok, I went and searched harder.

        @DeletedUser115, I believe you received an official answer to this question, or to a very similar question, a year ago: https://discuss.grapheneos.org/d/5274-is-second-user-profile-encrypted-also-by-first-user/9 That is, I believe the answer received then to the two-part question you posed then works out to "Both #1 and #2 are false".

        If a question still remains in light of that answer, might it be possible to phrase it differently so it is clear which part(s) are not yet addressed?

            de0u I believe you received an official answer to this question, or to a very similar question

            Thank you for digging it up! I do remember that discussion, but the rationale given there included:

            While it is true that currently Owner has to be unlocked before attempts on secondary user profiles can be made, it isn't out of the question for AOSP to change that behavior in the future if they regard it as a limitation, which they likely do (from a UX standpoint and considering the fact that multiple users are meant to be used by individual people, having to have the owner present before you can unlock your own profile after a reboot isn't great).

            It's understood that it's safer not to rely on the Owner profile for protecting data on secondary profiles. But I am curious if Owner passphrase adds any additional protection to secondary profiles as of now, not taken into account any possible change in AOSP in the future.

            For context, the reason I am asking it is remembering a second (or more) random passphrases for secondary user profiles is a lot of cognitive load for an older lady like me lol.

            • de0u replied to this.

                DeletedUser115 It's understood that it's safer not to rely on the Owner profile for protecting data on secondary profiles. But I am curious if Owner passphrase adds any additional protection to secondary profiles as of now, not taken into account any possible change in AOSP in the future.

                Based on the previous official statement, I believe that as of now in order to unlock a secondary profile's data it is necessary to first unlock the owner profile or else to brute-force the secondary PIN/passphrase given an image of the storage, and/or to compromise some part of the hardware security.

                But I think it's pretty clear that as of now a strong owner passphrase does not increase the strength of a weak secondary-profile PIN if one assumes a well-resourced attacker who has an exploit or is willing to disassemble a device. Thus I believe the answer to your core question is "no".

                Some people might wish it were "yes" (e.g., you) and some people are glad it's "no" (people who hope someday there will be a way to boot straight to a non-admin profile, perhaps for a child). But it does appear that the present answer is "no".

                DeletedUser115 For context, the reason I am asking it is remembering a second (or more) random passphrases for secondary user profiles is a lot of cognitive load for an older lady like me lol.

                How necessary this might be depends on one's goals and threat model. If one has genuinely important data (perhaps multiple banking apps) in a secondary profile, a strong key may be necessary. How strong depends on one's presumed attackers and how much it's worth to keep the secondary profile secure. If the secondary profile has access to just one bank account containing one month's shopping money, auto-filled monthly by a different bank, maybe a medium-length PIN is enough.

                    DeletedUser115 Or, TL;dr: if one assumes the attacker is weak (restricted to treating the device as a black box and interacting with it via the regular login windows), as of now a strong owner passphrase probably provides substantial protection to the secondary profile BFU even if the secondary profile credential is weak. But if one assumes a well-resourced attacker, a strong owner passphrase provides close to zero added protection against a weak secondary-profile PIN.

                    Since you have mentioned scenarios involving the secure element being compromised, that sounds like the "well-resourced attacker" part of the space, thus I think the "close to zero added protection" answer applies.

                      Pixel6-8 in table3, AFU support says FFS YES as well as BF NO, does this table mean that even if I don't provide the unlock code to the law enforcement agency, if the device is in the locked state of AFU, they can get and analyse the complete system image through cellebrite and extract the application information from it?

                        DeletedUser115

                        According to the dev team, grapheneos is a modification built on top of AOSP, and if the original system can be breached, I don't think a modification built on top of the original system is safe either.

                            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.

                                            DeletedUser115
                                            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