Question about forensics

throwawaymaybe

I used to believe that when something gets deleted, it can still be recovered, whether it was on an SSD or HDD, but now I've found out about TRIM on SSDs, where data gets unrecoverably erased soon after deletion.

My question is this: if someone gained total control over my GrapheneOS device, will they be able to recover messages that were deleted prior to them gaining access?

Johnnyloans

throwawaymaybe will they be able to recover messages that were deleted prior to them gaining access?

If you nessaging app has an in-app option for recently deleted messages or undelete, anyone could do it.

If not, the government or a forensics company could.

If it's very important, you could fill your storage 100%. Thatll probably get it. If its very important, then delete 30% of storage then fill it up to 100% again.

Then delete all of the nonsense files you used to fill up the storage.

Ssd trim won't help much.

If the phone is unlocked, they can access your phone.
AFU, maybe in a few years they can?
BFU, a decade or 2? maybe they could. Your guess is as good as mine.

raccoondad

throwawaymaybe but now I've found out about TRIM on SSDs, where data gets unrecoverably erased soon after deletion.

TRIM isn't a data deletion method, its a optimization feature for the SSD controller to be aware of what physical spaces are being used and not used more effectively.

SSDs have a secure erase method however, for Linux it can be called using hdparm or nvme-cli. Tools exist as well for windows.

koocmit

throwawaymaybe recovered

Just encrypt the drive and use a method that destroys the keys whenever you want to destroy access to the drive. Physical destruction is also a traditional advice, but I have yet to see encrypted drives cracked without user error (bad passwords, storing passwords in plain text IRL/somewhere else), etc.

throwawaymaybe

Oh, I just found out through more research that I was misled; TRIM doesn't securely erase data, though it makes it harder to recover.

Datasapiens

phone disk is just like any other drive, data can be recovered if not treated with special spices ( https://opensource.com/article/21/10/linux-tools-erase-data )
BUT
if you set a complicated password to your phone, data is in the 'container' and so much encrypted, it is impossible to access it with any forensic tools

Novalissoide

Johnnyloans nessaging app has an in-app option for recently deleted messages or undelete,

But the messaging app don't use brute-force to do this, it would use its keys.

schweizer

There are multiple threads in this forum about secure erase. I am no expert in this field but I have understood that every file is stored with an individual key. If you delete the file the key gets erased but the encrypted data remains. But it is unusable. Shredder tools do not work and are not neccessary. Please correct if I am wrong.

Novalissoide

schweizer Shredder tools do not work and are not neccessary.

I'm of the same notion here. From my non-expert understanding, the amount of brute-force needed to make any recovery of a file with no key under these file-systems, would be just a lost cause, and I'm not finding any proof of concept cases for any successful attempt. But again, I'm just a user reading the stuff I manage to find, and somewhat comprehend.

Vincent96

You'd want to run a Secure Erase like raccoondad said to destroy data permanently.

schweizer

raccoondad SSDs have a secure erase method however, for Linux it can be called using hdparm or nvme-cli. Tools exist as well for windows.

I just had to secure delete some SSDs from a desktop computer and I used those tools. sudo hdparm --security-erase This is incredibly fast because all they do is erase the keys. The method of overwriting sector by sector with zeros and/or random data like we did in the days of magnetic hard disks is obsolete with SSDs. @Vincent96 : Can you present such a secure erase app that is not sanke oil?

Johnnyloans

Vincent96 Secure Erase like raccoondad said to destroy data permanently.
schweizer secure delete some SSDs

We cannot run these commands on our phone.

I wrote about why this method isn't 100% safe:

Johnnyloans 1) ATA secure erase / nvme sanitize

Broken in most NAND controllers that storage manufacturers purchase.

"Even vendor-provided “secure erase” commands (e.g., ATA SECURITY ERASE UNIT) may not guarantee full physical sanitization: in 68% of tested NVMe drives (2023 NIST IR 8457 lab validation), residual data persisted"
-https://lifetips.alibaba.com/tech-efficiency/secure-erase-methods-probably-wont-work-on-your-solid-s

68% failure rate is unsafe to trust alone. GOS doesn't use this anyway to the best of my knowledge.

The command typically does more than deleting keys. I can't speak on all controllers.
Erasing keys is enough for 99.9999% of people, however:
https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later

You'll notice my original reply is to raccoondad, who should know better by now, but his name is captain Ahab as it turns out.

schweizer The method of overwriting sector by sector with zeros and/or random data like we did in the days of magnetic hard disks is obsolete with SSDs.

I have an entire explanation on this:

Johnnyloans Overwrite the entire drive

Let's give a generous 10% over-provision. I completely fill the drive and thus--actually--destroy 91% of the data (1/1.1=0.91). I delete files, wear-leveling kicks in, and I fill it again.

raccoondad: "You are mistaking unencrypted HDD wiping concepts like DoD 5220.22-M"

No, I am simply leveraging mathematical truths in our favor.
A U B >= A
(realistically, "=" shouldn't be there)

Layered security right? My approach will surely be safer than simply deleting a key and there’s little to sacrifice--no harm done.

If you have a method for retrieving data that's been overwritten, please apply for a patent at your earliest convenience.

raccoondad

schweizer Can you present such a secure erase app

Android comes with one, recovery mode -> factory reset :p

Same idea as secure erase assuming a proper secure element is in place

Vincent96

schweizer I was referring to desktop usage.

raccoondad

Johnnyloans You'll notice my original reply is to raccoondad, who should know better by now

Childish behavior, get over yourself. Don't interact with me again

Johnnyloans

raccoondad

Hey man, if you're gonna come off so strong--swearing--out of the gate at least have the grace to admit when you're wrong. Otherwise you're gonna get clowned on.

I'm done now. :)

Novalissoide

I see a couple of questions intertwined, in this thread;

One about updated P8+ GrapheneOS device assuming advanced adversary confiscated at AFU, and the Titan holding. Pin and or passphrase wisely chosen and not compromised.

One about updated P8+ GrapheneOS device assuming advanced adversary confiscated at BFU, and the Titan believed to be breached. Pin and or passphrase wisely chosen and not compromised.

One about updated P8+ GrapheneOS device assuming advanced adversary confiscated after Duress feature successfully initialised and performed by user.

One about what information from a previous OS could possibly remain on a freshly properly installed GrapheneOS device assuming confiscated by advanced adversary, say in a fully unlocked state for clarity.

One about desktop, external drives, 'shredding', 'harvest now decrypt later', how this relates to our GrapheneOS devices in any way if any.

And one about the amount of brute force needed to recover any file after the key is gone, is this even a thing?

schweizer

@Novalissoide The OP used the term full control. For me that can only be the unlocked device. Then it does not matter much if the secure element is breached or not. And because they were asking about deleted messages we must assume the device is not factory reset or overwritten with a freshly installed OS. Additionally we do not talk about a deleted file but about a modified database. Messages in messengers are typically stored in a database. So none of your options :-)

The biggest loophole is that when you delete a message in a messenger app the space in the database is usually not freed immediately. It is just marked as free to the app while the database file remains the same size. Since the adversary has access to the encryption keys I guess it would be relatively easy to recover the deleted database entries. There are commands that clean up the database but this consumes quite a bit of battery so the apps rarely do it.

The safe delete mechanism of Android come only to play when you delete the database by clearing all user data of the app. Then the encryption key gets deleted. If you can trigger a TRIM command the data will additionally be physically deleted. But you have little control over the TRIM command. It is usually done once per day in an idle phase while charging. You can trigger TRIM with ADB over USB.

Novalissoide

schweizer database is usually not freed immediately

No difference in this OS? I'm just trying to figure this out.

https://grapheneos.org/features#clearing-sensitive-data-from-memory

schweizer

Novalissoide I fear not. It is the individual apps that control the database file. Usually some SQL stuff. If the database file remains its size the normal OS memory management does not apply. All the app developers want their battery usage to be low so to my knowledge even security oriented apps like Threema do not vacuum their database on a regular basis.

As the OS has root permission it could theoretically detect database files and vacuum them in idle state while charging. But I assume they consider this risky. At least I have not seen any documentation that would say they do.