Question about the Limitations of Forensics on Device-Encrypted Data

seryu9

So, I know that all file content and filenames (with exceptions for Direct Boot) are encrypted with my credentials. And I know that metadata like file sizes and filesystem structure are not, so if my files are downloaded from the public Internet or other places that an adversary can reference, they can confirm which files are on my phone if there's any vulnerability in the Titan M2 or fastboot they can exploit to get that metadata. However, from my intuition, it seems like there might be a few things I could possibly do to at least reduce the risk of this before GrapheneOS implements the pre-boot authentication option. Can anyone tell me if I'm onto something?

I heard that the file sizes that are device-encrypted aren't exact. They're rounded up to the nearest 4KiB. While this would allow the identification of larger files, if I only kept a few or several related files each under 1MiB in a folder, I could get away with not having those files identified. Furthermore, for a larger number of such files, perhaps I could introduce some junk files in the folder to make it harder for an adversary. Is what I heard correct?
While deleting files doesn't wipe their content from a device, simply reserving the space they take for new files, can it remove their reference from the filesystem? Could preventing the files from being identified be as simple as moving them to offline, block-encrypted storage and then "deleting" them from the phone?
Lastly, what if I were to modify the files such that they were different from their original size, and/or move them into different folders? Could forensics analysts without my credentials be able to tell the files' original sizes and locations?

ryrona

seryu9 I heard that the file sizes that are device-encrypted aren't exact. They're rounded up to the nearest 4KiB.

I actually think the true file sizes in bytes are not credential encrypted in any way. Only file names and file data. Where did you hear they are rounded?

seryu9 While deleting files doesn't wipe their content from a device, simply reserving the space they take for new files, can it remove their reference from the filesystem?

The reference from the filesystem is removed, but this does not mean file data or even file metadata is deleted from the physical storage device. Flash storage makes all kinds of deletion very unreliable.

seryu9 Could preventing the files from being identified be as simple as moving them to offline, block-encrypted storage and then "deleting" them from the phone?

No, probably not. You need to factory default your device to get rid of metadata such as file modification dates and file sizes and such. The factory default should wipe the device encryption key in a secure way, even if I am not certain how this is actually done on a technical level, since apparently weaver isn't used for this.

seryu9 Lastly, what if I were to modify the files such that they were different from their original size, and/or move them into different folders? Could forensics analysts without my credentials be able to tell the files' original sizes and locations?

Possibly, if you had the original files on your phone at one point in time. Otherwise not.

seryu9

ryrona

ryrona I actually think the true file sizes in bytes are not credential encrypted in any way. Only file names and file data. Where did you hear they are rounded?

Funny as it may sound, I thought I heard it from the GrapheneOS account in a reply to you in the first thread you brought this topic up. I might be misremembering though. That thread seems to be gone now.

ryrona You need to factory default your device to get rid of metadata such as file modification dates and file sizes and such.

Seems like I best have a profile with a PIN code set at the ready for typing in a short duress PIN.

This is probably speculative in nature, but how rare do you think it would be for an exploit to exist that could bypass the device encryption at this point? From what it appears, the most recent one the GrapheneOS project knows about is the one from April 2024. Do you think they'd be any rarer than full exploit chains for GrapheneOS itself?

grayway2

Very interesting. Let me know if you happen to stumble upon the video again.

grayway2

I don't remember the video but a mobile device forensic analyst explained that with each new android version it was more and more complicated to retrieve deleted data to the point that a physical extraction was useless to get deleted stuff from the phone because of how encryption is implemented. Something about each files having an unique encryption key that was overwritten after the correspondent file was deleted.

ryrona

seryu9 Funny as it may sound, I thought I heard it from the GrapheneOS account in a reply to you in the first thread you brought this topic up. I might be misremembering though. That thread seems to be gone now.

I don't remember anything like that being mentioned. Since the tracking of occupied and free space on the file system works on block level, maybe 4 kiB blocks as you say, technically, the exact file size in bytes could be encrypted. I have just not heard of that actually being done. And I actually faintly recall being able to see the exact file sizes when I was poking around on a userdebug build, even if the file names and file data was still encrypted and inaccessible in plaintext. I don't think the exact file sizes in bytes are credential encrypted at all.

seryu9 This is probably speculative in nature, but how rare do you think it would be for an exploit to exist that could bypass the device encryption at this point?

No idea. I don't even know how device encryption is actually implemented, ie how the encryption key is actually derived. I have tried to get some answers from GrapheneOS team about this, but haven't got any. And Google documentation about device encryption doesn't seem to mention this as far as I can see.

I assumed device encryption was implemented using an encryption key released by the secure element (Titan chip) upon successfully attested boot by pre-authenticated CPU. This is usually how device encryption is implemented in other contexts. But GrapheneOS team told me that the secure element is not involved at all, but that it still is implemented in another secure way, but didn't go into any details of what that would be.

If it were the secure element chip, an adversary would need to break the security of that chip, or the pre-authenticated CPU, which would be pretty hard. Google's Titan chips seems to be able to withstand all attacks for several years after initial device release. But since that apparently isn't how it is implemented, I don't know.

I would love for GrapheneOS team to tell me how it is implemented, or someone else to link to any actual documentation about where the root of trust for the device encryption is. But it seems even the GrapheneOS team feels making the metadata credential encrypted too is the way to go. For my own threat model, I am assuming device encryption is effectively no encryption at all, until I have got an actual technical explanation of how it is implemented, and why it provides security.

grayway2 I don't remember the video but a mobile device forensic analyst explained that with each new android version it was more and more complicated to retrieve deleted data to the point that a physical extraction was useless to get deleted stuff from the phone because of how encryption is implemented. Something about each files having an unique encryption key that was overwritten after the correspondent file was deleted.

seryu9 Very interesting. Let me know if you happen to stumble upon the video again.

Yeah, I would also be very interested in this. Securely erasing things from flash storage is usually not easy to do, although technically it could be implemented, at some performance overhead and extra wear, by the SSD itself. All I know is that all file specific encryption keys are only stored on the SSD, in the filesystem data, not in any by-me-known securely erasable storage, so if it is implemented in a secure way, it is in the SSD itself.