. Does hold the decryption keys in RAM after it's locked? Source: securephones.io/#Chx1.p4 particularly the point about "Limited benefit of encryption..." Can this be fixed or is it an architectural problem with Android? News story:
Conversation
See grapheneos.org/faq#encryption. It's not an architectural limitation of Android. It's a limitation of the device being able to function when locked.
The end session feature can be used to logout of a secondary profile and purge the keys from memory and hardware.
2
4
Filesystem-based encryption allows Android to provide per-user-profile encryption keys. That enables support for ending the session of profiles, at least for secondary profiles. Ending the owner profile session without reboot would be possible but it'd basically be a soft reboot.
1
1
Ending the owner profile session would have to end all other sessions, soft reboot the OS and then purge the keys. It's semantically the same as rebooting, but it would be non-trivial to implement correctly. End session for secondary profiles is far more useful and works already.
1
"In particular, Android provides no equivalent of Apple’s Complete Protection (CP) encryption class, which evicts decryption keys from memory shortly after the phone is locked." is not true. This functionality is provided via Android's hardware-backed keystore API.
The "Large attack surface" point in comparison to iOS is nonsense. It doesn't make sense. Android is developed as a single source tree. This is spinning open source and forking existing projects rather than everything being Android-specific as a negative thing. It's really not...
1
Android is developed as a single source tree. It takes responsibility for all of the third party projects it incorporates into the OS and they're cohesively developed as part of Android. The authors aren't familiar with how it's developed, and are also clearly biased against it.