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

Nuttso 128-bit entropy is the standard value for extreme overkill that's secure far into the future. It doesn't really make sense to generate a random passphrase with more than 128-bit entropy. The amount of entropy is a different thing from the size of the derived key encryption key. The useful reason for security levels above 128-bit is because algorithms get broken in ways that substantially reduce their security. 256-bit cipher which experiences a quite extreme break can still end up providing more than 128-bit security, thus still preserving indefinitely overkill security in practice. This is why using AES256 instead of AES128 makes sense, but generating a 256-bit entropy passphrase / seed phrase which just gets fed into a key derivation algorithm to derive arbitrary length keys really doesn't make sense.

Significantly lower than 128-bit security is still considered secure and is just below the standard for extreme overkill that most people have settled on as making sense. Since passphrases go through key derivation adding a substantial work factor, passphrases with 90-bit entropy such as 7 diceword words or 18 lowercase letters/numbers are still highly secure and don't depend on hardware security features to prevent brute forcing. If you really want, you can raise that to 128-bit for extreme overkill but it is substantially more inconvenient and not really giving you real world benefits.

On the other hand, something like a 64-bit entropy passphrase is not secure against brute forcing if the attacker can bypass the hardware security features. Passphrases below around 90-bit entropy can still be secure if the secure element is compromised but if both the secure element and hardware bound key derivation are bypassed, there's a serious problem.

If the secure element isn't compromised, a random 6 digit PIN is secure against brute forcing. This is the kind of scenario in the original post where they exploit the OS and then need to exploit the secure element to bypass the brute forcing, leaving them needing a rare/sophisticated kind of exploit for the secure element firmware.

    GrapheneOS Based on the post itself, what you're asking is about the security of encryption for a device that's at rest not security of the OS itself

    Yeah I assumed this is the actual question also.

    GrapheneOS 128-bit entropy is the standard value for extreme overkill that's secure far into the future.

    Good to know.

    The security posture against law enforcement seizing the phone (the OP attack scenario) hinges on the key feature that grapheneOS has that no other OS natively does,... the ability to reboot the phone if no successful login after X hours.

    This puts the phone, "at rest" as the developers above state.
    This means no user apps are running to be exploited (so nothing like that Firefox exploit could even be possible). Plus all of that full encryption and secure element that was discussed above.

    A seizure of the phone is likely to happen when the phone is not at rest, giving law enforcement a certain amount of time. They will probably fail to exploit if the user has set a short time out for the automatic reboot.

    My question is this....
    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?

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

      Very intriguing question, so I checked it out.

      Short answer without citing the code and stuff, no, I don't believe they can spoof time from anywhere to make the reboot not happen. It appears the system clock has an internal timer, one that starts at boot. The auto reboot feature basically tells the phone to reboot when the phone's internal timer has reached n milliseconds, i.e. milliseconds since boot + auto reboot interval in milliseconds.

      Anyway, here's the stuff I found if you're curious:

      The method to reboot uses elapsedRealtime() (doc), sets an alarm using setExactAndAllowWhileIdle() (doc), which uses the type ELAPSED_REALTIME_WAKEUP (doc), which basically means use the internal system timer for the alarm, not the normal seconds since unix epoch.

        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]

            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]

                    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]

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

                      • [deleted]

                      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]

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