• General
  • Does GOS shred files on deletion?

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:

    1. RAM is soldered to the board, so it can't be removed easily and quickly enough to attempt to get data that way.
    2. Android's bootloader won't boot to an image on an external drive. Sideloading is different, so I don't think even GOS devs could attempt that even with their signing keys.
    3. Keys aren't stored in memory for long enough to make this kind of attack feasible.
    4. Each file is encrypted with its own key, making this kind of attack mostly pointless.

    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.