When a file is deleted, is it fully shredded?
I know GOS has full device encryption, but what mitigation does it have against smth like cold boot attack?
When a file is deleted, is it fully shredded?
I know GOS has full device encryption, but what mitigation does it have against smth like cold boot attack?
avidgrapher When a file is deleted, is it fully shredded?
No, it does not. If an attacker knows your PIN/passphrase and have physical access to the phone, they can theoretically recover a deleted file.
On the other hand deleting a user profile wipes all its data with no availability to recover.
avidgrapher When a file is deleted, is it fully shredded?
No. It doesn't have to be because of how everything is encrypted.
avidgrapher I know GOS has full device encryption, but what mitigation does it have against smth like cold boot attack?
This I'm not sure of, so take this with a grain of salt. I don't think it's possible for four reasons:
From: https://source.android.com/docs/security/features/trusty
On devices with a TEE implementation, the main processor is often referred to as “untrusted”, meaning it cannot access certain areas of RAM, hardware registers, and write-once fuses where secret data (such as, device-specific cryptographic keys) are stored by the manufacturer. Software running on the main processor delegates any operations that require use of secret data to the TEE processor.
Some cherry-picked and related stuff from https://grapheneos.org/faq#encryption
The advantage of filesystem-based encryption is the ability to use fine-grained keys rather than a single global key that's always in memory once the device is booted.
Disk encryption keys are randomly generated with a high quality CSPRNG and stored encrypted with a key encryption key. Key encryption keys are derived at runtime and are never stored anywhere.
A unique key is derived using HKDF-SHA512 for each regular file, directory and symbolic link from the per-profile encryption keys, or the global encryption key for non-sensitive data stored outside of profiles.
The UFS storage chips on these devices, and similarly SSD's on computers, do not work the same way as magnetic drives. You can't just read unallocated space. Anything that has been trimmed has been zeroed out / reset on the physical chip itself and deallocated. The memory visible to the operating system isn't even physically contiguous on the device, rather it is remapped by the UFS controller. If you try to do a read on an unallocated space, the UFS controller will just spit back zeros rather than taking the time to read back the content of the previously allocated memory locations. It works in this way for reasons of performance and wear leveling, but is also beneficial in terms of security, since at some point, the memory becomes unreadable, even without shred OR encryption.
Now it doesn't necessarily do this fully on every deletion, because the file doesn't necessarily fill a full trimmable block, but you get the idea I'm sure.