• General
  • Exploit of device after first unlock to obtain data that isn't at rest

  • [deleted]

GrapheneOS Yes please file such an issue. THX.

    [deleted] We've reported it already and expect it to be resolved quickly due to active exploitation of the lack of reset attack mitigation (firmware zeroing memory on reset/shutdown). The fastboot mode vulnerability may be hard to find but they'll likely dedicate some resources to it. Fixing the fastboot mode vulnerability isn't very important if they add reset attack mitigation.

      GrapheneOS Thank you once again for your replies to myself and the others in this thread with a great amount of detail, that are also very understandable and logical. You've increased my knowledge and awareness of a few things here.

      And thank you for filing an issue on this also and once again improving our security and privacy in so many ways. Looking forward to the duress feature once you're happy it's ready to be released

      GrapheneOS Does this mean that if the phone has been unlocked (not BFU) and they click reset (or wasted triggers) and then they hold volume down, that fast boot would still be AFU and not secure?

      Where does the Auto-Reboot function work? If the device is in fastboot mode, I presume the auto reboot would not work? ie they can leave it in the fastboot mode AFU

      krayo If you post your email or something I can contact you, I will do that.

        12 days later

        One more reason to use molly with unified push and generic notifications with locked db.

        I was always under impression that AFU + physical access is game over given a determined adversary. Was I wrong?

          evalda you were absolutely right

          Hathaway_Noa They can bypass secure element by booting into the fastboot mode when the phone has been previously in AFU, after that they dump the RAM since the RAM hasn't been cleared yet and bruteforce the keys giving them a password.

          It's weird that they are able to brute force the password like that because of 2 reasons:

          1. A flagship device with an SE also comes with a hardware inline crypto engine (ICE) that stores data encryption keys during the runtime of the OS. So they may see plain text data in the RAM dump but seeing keys in memory goes against the the purpose of having an ICE.

          2. Let's assume they can see sub-keys in memory dump. But this alone is not enough to brute force the credentials. It is because they need to decrypt the Synthetic Password first which is only possible with the active cooperation of Weaver and Strongbox Keymaster.

            I think the Synthetic Password is being kept in plain-text in the memory dump which I think is accidental because once its participation to decrypt CE keys completes during BFU to AFU state transition, it's no longer required by the LockSettingsService so it should be released from the memory.

          GrapheneOS It could be used to flash another verified boot, enable debugging features, etc.

          Is this prevented in GrapheneOS? And if not, what are the implications of a adversary messing with this stuff? Will it be reverted on reboot, or presist until I factory reset the device?

          2 months later
          a month later