After a reboot all the data is encrypted and needs a pin/fingerprint to unlock.
So if it’s stolen (or feds get it) a planned reboot resets it to a highly secure state that is much more difficult to hack into than when it’s just locked from timeout.
Edit: removed fingerprint, corrected below.
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.
lol@discuss.tchncs.de
on 15 Apr 21:12
nextcollapse
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 partitions, 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. Is there something e.g. the bootloader does that cannot be replicated on a running phone and is essential for securing it again after the first unlock?
Darkassassin07@lemmy.ca
on 15 Apr 22:21
nextcollapse
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.
WhyJiffie@sh.itjust.works
on 16 Apr 05:49
collapse
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
WhyJiffie@sh.itjust.works
on 16 Apr 05:47
collapse
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)
jws_shadotak@sh.itjust.works
on 15 Apr 13:11
nextcollapse
It makes it harder for law enforcement or others to access the phone without knowing the pin
And from my reading, helps secure against a situation where an police officer (AKA attacker in the US apparently…) coerces you to unlock the phone (or perhaps even just takes it off you in a locked, but active state), and stores it in a faraday bag with a charger.
They do that to keep it ‘alive’ so their experts can break in - a dead-mans reboot can help circumvent even that (as it will just reboot and restore itself to an encrypted rest state, which is much harder to attack)
M154nthr0p3@lemmy.world
on 15 Apr 13:12
nextcollapse
This podcast goes into the reasons that rebooting a locked phone can improve security.
[The 404 Media Podcast] How Apple is Locking Out Cops #the404MediaPodcast
podcastaddict.com/…/185990070 via @PodcastAddict
My take is, it’s harder to unlock/hack a phone when it is in the locked state after booting up. This state is somehow different than the booted locked state.
Why, is above my understanding.
MegaUltraChicken@lemmy.world
on 15 Apr 13:54
collapse
Basically, the tools that LE uses to unlock devices uses exploits that require the device to be in what’s called an AFU (after first unlock) state. The data on the device is encrypted prior to that first unlock after you boot. If the device is in a BFU state (before first unlock) Cellebrite/Greykey (by far the primary tools used in this space) basically hit a wall.
sem@lemmy.blahaj.zone
on 15 Apr 16:46
nextcollapse
Elsewhere in the thread they explain because decryption takes time, they don’t cycle it every time you lock your phone by default. Not sure if there’s more to it.
twice_hatch@midwest.social
on 15 Apr 18:13
collapse
The time needed for key derivation aka key stretching may be a factor, but also in the BFU state I think apps don’t run and you don’t get notifications, since most of the files are still locked
the custom ROM I use (CalyxOS) already has it, and you can customise how long the device has to be locked for the reboot to occur, anywhere from 1 to 72 hours.
neomachino@lemmy.dbzer0.com
on 15 Apr 19:11
nextcollapse
I was gonna say I thought this had been the case forever. I don’t use this feature but I recall seeing it on pretty much every custom ROM I’ve used over the last few years.
rc__buggy@sh.itjust.works
on 15 Apr 19:46
nextcollapse
Mine is set for 12 hours. I never sleep that long and if it does reboot I don’t care.
timbuck2themoon@sh.itjust.works
on 15 Apr 23:05
collapse
Thanks for this. Didn’t even know it was an option.
Yes. Directly if you have root, or with a workaround where you bring up the power menu and then use either virtual keyboard commands or the AutoInput plugin to tap the reboot button.
Don’t some system updates require a reboot as well? Would be nice if this applied updates as part of this cycling.
prettybunnys@sh.itjust.works
on 15 Apr 20:43
nextcollapse
NGL I’m shocked they weren’t doing this already, I seem to recall it being mentioned some android devices did this already when iOS added it last year(?)
At least some of the more security oriented ones?
WhyJiffie@sh.itjust.works
on 16 Apr 05:34
collapse
I seem to recall it being mentioned some android devices did this already when iOS added it last year(?)
calyx os (it has better timing options still), graphene os, and it seems from another comment that oneplus too
Mine already reboots every night. It’s a setting I can change on my OnePlus.
I enabled it long ago. A reboot will also kill anything that is running in your memory like a page mining crypto or a virus that has not yet gotten to your file system yet. Or at least I’d like to think so…
Anyways, the reboot also insured that if my phone is ever taken from me, after 24 hours max they will have to both enter my PIN and my phone security code. I wish them good luck. There’s not much interesting stuff on my phone, but that does not mean I want everyone to have free access too it.
threaded - newest
I’m not a phone person. What benefit does this provide?
After a reboot all the data is encrypted and needs a pin/
fingerprintto unlock. So if it’s stolen (or feds get it) a planned reboot resets it to a highly secure state that is much more difficult to hack into than when it’s just locked from timeout. Edit: removed fingerprint, corrected below.Oh, this is actually a useful feature, then.
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)
Just to clarify, it needs a PIN/password to unlock after reboot. Biometrics like fingerprint aren’t available until the device has been decrypted.
Thanks for the clarification, I forgot that (somehow)
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?
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.
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 partitions, 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. Is there something e.g. the bootloader does that cannot be replicated on a running phone and is essential for securing it again after the first unlock?
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.
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
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
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)
It makes it harder for law enforcement or others to access the phone without knowing the pin
And from my reading, helps secure against a situation where an police officer (AKA attacker in the US apparently…) coerces you to unlock the phone (or perhaps even just takes it off you in a locked, but active state), and stores it in a faraday bag with a charger. They do that to keep it ‘alive’ so their experts can break in - a dead-mans reboot can help circumvent even that (as it will just reboot and restore itself to an encrypted rest state, which is much harder to attack)
This podcast goes into the reasons that rebooting a locked phone can improve security.
[The 404 Media Podcast] How Apple is Locking Out Cops #the404MediaPodcast podcastaddict.com/…/185990070 via @PodcastAddict
My take is, it’s harder to unlock/hack a phone when it is in the locked state after booting up. This state is somehow different than the booted locked state.
Why, is above my understanding.
Basically, the tools that LE uses to unlock devices uses exploits that require the device to be in what’s called an AFU (after first unlock) state. The data on the device is encrypted prior to that first unlock after you boot. If the device is in a BFU state (before first unlock) Cellebrite/Greykey (by far the primary tools used in this space) basically hit a wall.
Elsewhere in the thread they explain because decryption takes time, they don’t cycle it every time you lock your phone by default. Not sure if there’s more to it.
The time needed for key derivation aka key stretching may be a factor, but also in the BFU state I think apps don’t run and you don’t get notifications, since most of the files are still locked
Thank you for elaborating.
If you set it up with a password it makes it harder for people who shouldn’t have access to it to read your stuff
the custom ROM I use (CalyxOS) already has it, and you can customise how long the device has to be locked for the reboot to occur, anywhere from 1 to 72 hours.
Same with GrapheneOS.
I was gonna say I thought this had been the case forever. I don’t use this feature but I recall seeing it on pretty much every custom ROM I’ve used over the last few years.
Mine is set for 12 hours. I never sleep that long and if it does reboot I don’t care.
Thanks for this. Didn’t even know it was an option.
Can this be done with Tasker?
I think so but it would take root or some kinda of workaround I think.
Yes. Directly if you have root, or with a workaround where you bring up the power menu and then use either virtual keyboard commands or the AutoInput plugin to tap the reboot button.
I reinstalled tasker again yesterday but then uninstalled it when it wouldn’t work without giving it perms to draw over other apps.
I use automate instead.
Don’t some system updates require a reboot as well? Would be nice if this applied updates as part of this cycling.
NGL I’m shocked they weren’t doing this already, I seem to recall it being mentioned some android devices did this already when iOS added it last year(?)
At least some of the more security oriented ones?
calyx os (it has better timing options still), graphene os, and it seems from another comment that oneplus too
Mine already reboots every night. It’s a setting I can change on my OnePlus.
I enabled it long ago. A reboot will also kill anything that is running in your memory like a page mining crypto or a virus that has not yet gotten to your file system yet. Or at least I’d like to think so…
Anyways, the reboot also insured that if my phone is ever taken from me, after 24 hours max they will have to both enter my PIN and my phone security code. I wish them good luck. There’s not much interesting stuff on my phone, but that does not mean I want everyone to have free access too it.