• General

  • What is current GrapheneOS's security strength compared to iPhone circa 2016?

Graphite unwat

How is this timeout coded? Is it based on system time that can be manipulated with network time (NTP)?
Can law enforcement simply stand up a fake mobile network and spoof the time so that the OS always believes the timeout has not been reached?

It's based on a proper monotonic timer, not real time. Timers for intervals of time should never be based on real time. GrapheneOS also doesn't trust time from the cellular network and doesn't use unauthenticated NTP. One of the features provided by GrapheneOS is that we use HTTPS-based network time which provides authentication and also more precision than the AOSP approach to fetching time despite being HTTPS-based instead of NTP.

https://grapheneos.org/features#other-features

        GrapheneOS
        Thank you. Found this based on your explanation.
        https://developer.android.com/reference/android/os/SystemClock

        elapsedRealtime() and elapsedRealtimeNanos() return the time since the system was booted, and include deep sleep. This clock is guaranteed to be monotonic, and continues to tick even when the CPU is in power saving modes, so is the recommend basis for general purpose interval timing

        I assume this is the clock used.

          Thank you everyone for commenting :) Very interesting.

          GrapheneOS ,
          You said:

          "This is the reason you must log into Owner before other users."

          Are you saying that if a user wanted to show someone only their decoy profile, they would have to log into their master Owner profile first? Wouldnt that be dangerous/compromising?

              • [deleted]

              • Post #18

              Intellectual2
              The owner profile would be locked the same way as it would be if you used only one profile.

              So if you showed anyone your "decoy" profile, to actually get into the owner profile, you or the person that you are showing it to would need to switch users first and than provide password to the owner profile.

                So in this thread we talked about lengthy passwords.
                I believe & also someone else commented too about how troublesome it would be to have to remember & to enter that lengthy 90 to 128 bit passphrase every single time one logs in. Here is an idea I've had for a long time, which is to create an encrypted peripheral login shell GUI, that you log into, which uses like a one character or even five character passphrase. Then the 2nd later that you log into, has countless files, of random code, many gigabytes of it, maybe some decoy pdfs also, or txt files or jpg photos, program files,etc.
                And you either use a file itself, drag & drop it into the real 90 to 128 bit password box, use the file itself as the passphrase or key, or alternatively you search in this random code files for a searchphrase, like "swordfish7", then that will bring you to a section buried in these millions of lines of random code/gigabytes, & right after that word swordfish7, indented & easily selectable/copy pastable, is a 90 to 128 bit passphrase, and it looks just like the millions of code surrounding it. Its not hiding a needle in a haystack, its hiding a needle in a stack of other needles. This is by far the best way to store passwords I believe, that I know of, but I am not nearly as trained or experienced as any of the experts commenting here.

                I also think fingerprint recognition is a bad idea, as this method is particularly vulnerable to some government's legal right to force/order/compel you to provide your fingerprint to unlock, or a non government adversary may use your fingerprint by force. Whereas a password can be forgotten(plausibly deniability), or it can be considered violating The Fifth Amendment right to protection from being compelled to incriminate oneself. The different courts across the US have disagreed with each other about this, but its much better than a fingerprint. The only thing better is plausible deniability with a hidden/decoy LUKS or veracrypted OS, or linux based phone can provide?

                Or maybe grapheneOS's decoy profiles offer plausible deniability? is there a way to hide the Owner/real profile? and only show the decoy profile?

                  Intellectual2 https://github.com/GrapheneOS/os-issue-tracker/issues/28 This will help with adding an extra layer to fingerprint unlock as a second factor.

                  You could have your secure passphrase as the primary unlock method (will need to be used after a reboot etc.) but use a combo of PIN + Fingerprint as a second factor, instead of just fingerprint.

                      matchboxbananasynergy Thanks Mr. Banana! :) But what are the benefits of this?
                      I see that with a fingerprint, it might make it even more difficult to hack into, a bruteforce approach wouldnt even work with a fingerprint unlock? But is your method quicker? (compared to typing a 90 to 128 bit password) as that is what my last comment was getting at. Not sure what you were replying to, my post, or my last comment. Of course scanning a fingerprint will be quicker, but will it be as secure? how many bits would the secure passphrase be initially for example?

                          Intellectual2 You said that a long passphrase is inconvenient. I agree. You have to use it when the phone is in BFU mode (after a reboot), and you can use a fingerprint after that.

                          However, you mentioned that fingerprints can be risky if the government can compel you to use your fingerprint to unlock the phone. If your second factor is not just a fingerprint but a combination of both a PIN and a fingerprint, you now have the resilience of an impossible to brute force password for when the phone is in BFU mode (7 word diceware passphrase) as well as a very secure yet easy way to unlock the phone in your everyday usage (6 digit PIN + fingerprint).

                          I hope that makes sense. If not, let me know.

                              • [deleted]

                              • Post #23

                              matchboxbananasynergy combo of PIN + Fingerprint as a second factor,

                              It would be nice to have this option.

                                matchboxbananasynergy . If your second factor is not just a fingerprint but a combination of both a PIN and a fingerprint, you now have the resilience of an impossible to brute force password for when the phone is in BFU mode (7 word diceware passphrase) as well as a very secure yet easy way to unlock the phone in your everyday usage (6 digit PIN + fingerprint).

                                Independent of PIN+fingerprint as an option, what about having brief fingerprint-only unlocking with a timeout? So I could unlock with just a fingerprint for 90 seconds, then fingerprint & PIN until the reboot timer goes off.

                                  Does GrapheneOS/Android support unlocking the phone with a hardware key via FIDO2 or similar?

                                    2 months later

                                    • [deleted]

                                    • Post #26

                                    de0u The government phones are less secure than the pixel with grapheneos, but the government communications are.

                                      • [deleted]

                                      • Post #28

                                      BIRDIE Of course it's super secure. Even the linux kernel is maintained unlike other systems. No need to watch youtube videos, the GrapheneOS website itself is a bible. When I need information I look at the GOS website or the WHONIX website. Nothing else

                                        • [deleted]

                                        • Post #29

                                        BalooRJ It is the titan chip that partly manages the unlocking.

                                          a month later

                                          IMHO a default GrapheneOS install is more secure than default iOS install simply because the former has much less attack surface. The iPhone comes preinstalled with a ton of services through which people can reach the phone and attempt to exploit: imessage, icloud photos, apple music, find my iphone, homekit, calendar invites... Safari the browser is also notoriously easier to exploit than Chromium.

                                            Titan_M2 iMessage in particular proves to be a common channel for delivering exploits. If you have to use iOS for some reason and have a high threat model, I'd suggest disabling iMessage, Facetime, MMS and not using Mail app. Enable lockdown mode too.

                                                • [deleted]

                                                • Post #33

                                                DeletedUser115 I agree, the problem is that in France the lockdown mode has been translated as "isolation mode", which has nothing to do with it. I might as well tell you that when I advised my wife's parents to activate it for their own safety, they didn't want to. So I don't think Apple wants to make any more of an effort than that when it comes to security, and I think that if there's one device you shouldn't buy, it's the iPhone.

                                                    [deleted] and I think that if there's one device you shouldn't buy, it's the iPhone.

                                                    I think it depends on your usage and threat model. Average Joe's data is probably more secure on an iphone than on a cheap android phone. There are many more incidents with malware infested apps in the play store compared to Apple's App store. In my experience, old people or less tech savvy people prefer the UX of an iphone. Things just work there, for the better or worse, if you happen to have more than one apple device in your household (Mac, TV, iPad) - AirDrop, screen syncing, sharing wifi password. Almost no configuration required.

                                                    Sure, then there are the iMessge zero-clicks so disabling that would mitigate the risk.

                                                    But as with most other online devices, if you keep your sanity and find the strength to resist the urge to play the umpteenth reiteration of some dumbed down mobile game or camera app, I think the average user is golden even with an iphone.