Comment on Android phones will soon reboot if they’re locked for a few days

• n2burns@lemmy.ca ⁨21⁩ ⁨hours⁩ ago

  After a reboot all the data is encrypted and needs a pin/fingerprint to unlock.

  Just to clarify, it needs a PIN/password to unlock after reboot. Biometrics like fingerprint aren’t available until the device has been decrypted.

  source

  • truxnell@infosec.pub ⁨11⁩ ⁨hours⁩ ago

    Thanks for the clarification, I forgot that (somehow)

    source
• Sibshops@lemm.ee ⁨21⁩ ⁨hours⁩ ago

  Oh, this is actually a useful feature, then.

  source

  • truxnell@infosec.pub ⁨11⁩ ⁨hours⁩ ago

    Yeah, seems like its a move to follow apple after custom ROMS offering it as a security feature (Im on GrapheneOS and had it set for a while)

    source
• lol@discuss.tchncs.de ⁨19⁩ ⁨hours⁩ ago

  Why is a reboot necessary for that? Is it not possible to enter the same encrypted state the phone is in after a reboot without actually rebooting?

  source

  • Darkassassin07@lemmy.ca ⁨19⁩ ⁨hours⁩ ago

    Much of the data on your phone, including critical information that’s required to run the operating system and make the device function, is fully encrypted when the device is off/rebooted.

    While in this locked down state, nothing can run. You don’t receive notifications, applications can’t run in the background, even just accessing the device yourself is slow as you have to wait for the whole system to decrypt and start up.

    When you unlock the device for the first time; much of that data is decrypted so that it can be used, and the keys required to unlock the rest of the data get stored in memory where they can be quickly accessed and used. This also makes the device more vulnerable to attacks.

    There’s always a trade off between convenience and security. The more secure a system, the less convenient it is to use.

    source

    • WhyJiffie@sh.itjust.works ⁨5⁩ ⁨hours⁩ ago

      even just accessing the device yourself is slow as you have to wait for the whole system to decrypt and start up.

      that’s not true. the system does not decrypt itself in one go. it’ll just wait with part of the bottup process until you unlock your device, and then keeps the encryption keys in memory so that it can encrypt and decrypt anything when needed.

      and the purpose of the reboot is just to make sure that both the encryption key, and any data crumbs left in the memory get lost from there

      While in this locked down state, nothing can run.

      that’s not true either. for instance the system definetly runs with a couple of its components. but apps too can request to be able to work before unlock, like your alarm clock. but of course, apps that store data in the compartment accessible before unlock is not secure, however they can selectively store there only the most essential things needed to work (alarm time database and maybe used ringtones)

      source
    • lol@discuss.tchncs.de ⁨14⁩ ⁨hours⁩ ago

      I’m generally aware of all that, but I don’t see how it answers the question. Why can’t you just stop all app processes, unmount the relevant partition(s), clear any memory containing cryptographic keys etc. but not actually reboot?

      Rebooting just seems like a very roundabout, slow and inefficient way to get back to that initial state you describe.

      source

      • Darkassassin07@lemmy.ca ⁨12⁩ ⁨hours⁩ ago

        Rebooting just seems like a very roundabout, slow and inefficient way to get back to that initial state you describe.

        It’s exactly what the reboot process is designed to do; return you to that fully encrypted pre-boot state. There would be no purpose to implementing a second method that does the exact same thing.

        source
      • WhyJiffie@sh.itjust.works ⁨5⁩ ⁨hours⁩ ago

        its done that way because at a reboot all memory is lost, and it can’t happen that something slips through because there is a bug or some miscalculation

        source