You’re telling me that android keeps keys in memory for its entire uptime?
There is a data protection class that is like what you're describing, but it is not used super-widely, the one most commonly used is exactly what is being described and makes data available after first unlock.
https://developer.apple.com/documentation/security/ksecattra...
What baffles me is that lock-screen is a system wide critical application and should in no way rely on this method.
iOS lock screen in theory shouldn't only respond to cryptographic validation from the secure enclave.
Some keys are, but not the ones that are the issue here.
I've even seen conditions where iOS devices reboot and still retain keys.
The only key that sometimes gets retained at reboot is the SIM unlock.
From what I gather the more secured keys should be discarded 10 seconds after lock screen event. Lower security keys stay in memory to allow background activity.
Encryption on ios, if i understand correctly, is on a per file basis. There is thus no "mount" event to look for and it should provide no value to use a less secured key if you do not intend to run on background because decryption is supposed to happen on the fly.
PS: Also if I remember correctly pressing down the emergency sequence (holding power + volume up) discard ALL keys instantly and unlock require the passphrase as if you just rebooted. Emergency call don't need to be issued just initiated (must hold 10 sec or confirm on screen to make the actual emergency call).
If you receive a phone call while locked presumably the phone can still access the address book to display the contact name and photo?
And music playing apps can presumably access their database of music to play songs whilst the phone is locked?
Just so you know, this is true on an iPhone, but NOT if the phone has NEVER been unlocked since reboot. If you get an SMS/call in this state, it will just show the number. It can't read the address book.
The music playing is a different story
Yes. I've known that for quite some time, and yet I keep forgetting considering how stupid this feels [1] . Google provides "lockdown" button which is supposedly more secure (I think it's recommended for journalists?)... Well it doesn't evict keys either. Only eviction is to reboot.
[1] It feels stupid because there had been a LOT of work to move from FDE to FBE and to allow two states of data encryption and telling apps to support both of them. Doing all this work just to be able to store incoming SMS and to display wallpaper on first lockscreen...?
I actually find this incredible. I am familiar with iPhone security but not android and had naively assumed Google probably did a better job on the non-UX aspects.
Your camera example is not at all convincing of anything special going on, since that's also the camera behavior of other OS's (like Android) that don't purge the keys. That's far more easily implemented as just a basic app policy than some security system that yanks the file system out from underneath running processes.
Full disk encryption is only useful on a laptop if the device is powered down fully.
It is hard to fix this too, because almost no background desktop processes behave well when they are suddenly unable to write to the disk.
Even if you solved that, your password manager has keys in memory, your browser has cookies in memory, etc etc.
"If your Mac has the T2 Security Chip (recent Intel-based Macs) or uses an Apple silicon chip (M1 family and future), security is significantly improved. The Secure Enclave in both systems uses encrypted memory, and has exclusive control over FileVault keys. The Intel CPU or the Application processor (M1) never sees the keys, and they are never stored in regular (unencrypted) RAM. Due to this, an attacker would only be able to extract encrypted keys (which can't be decrypted), and only if the system failed to prevent the DMA attack in the first place. These protections make it a lot safer to leave your Mac asleep."
The only safe encryption is on a powered down device.
It doesn't seem unsolvable, as long as sleep (closing lid) suspends all activity.
(lock with background activity is different, lets discuss the sleep case)
I would think it would have to be while the device is mounted and OS locked, but surely if you dismount a secondary disk/container the key is purged?