this post was submitted on 15 May 2024
513 points (97.4% liked)
Technology
60073 readers
2973 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related content.
- Be excellent to each another!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, to ask if your bot can be added please contact us.
- Check for duplicates before posting, duplicates may be removed
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
That's not entirely correct, and I would expect a tech news site to know but ig not.
It's true with spinny's since they store data magnetically on the platter with 1s and 0s, but SSDs store data on the NAND as a held charge. If there's a charge in the block it's a 1 if there's no charge it's a 0.
With spinny's, when a file gets marked as "deleted" the residual magnetic 1s and 0s will remain on the platter until eventually overwritten like they say
But with SSDs, when a file gets marked "deleted" then within no more than a few minutes TRIM comes along and ensures the charge on the NAND is released (Which means that data is gone, permanently) for that data, there's no residuals to worry about like with spinny's and is in fact necessary to ensure decent lifespans.
ETA: Link to a study from last year on this
This is dependent on the TRIM schedule. It could be size based (execute a TRIM when 50% of the blocks are used).
It could be or maybe the SSD has its own on-firmware TRIM schedule, but all major OS's execute a TRIM on a time based schedule no longer than every 10-15 minutes.
Afaik the default for windows 10 is weekly via disk defragmenter, and that assumes it recognizes the drive as an ssd. I've had drives cloned to ssds that retain the hdd flag and had to setup a 3rd party tool that actually saw it properly and would trim as expected.
11 might have reigned that in... but probably not.
Perhaps, but this is unrelated. The magnetic charges may still be there, but if the reference to the content is deleted, how is the filesystem meant to know what file is there? This seems really suspicious to me.
TRIM works outside the filesystem, it does not care about 99.9% of it, the only part it cares about is if there is a reference in filesystem to the block charges. No reference == data to be released
There's most certainly residuals, I've accidentally deleted then installed Windows on top of a bunch of my game saves. I found some random file recovery application and let it run for awhile. Guess what? Nearly everything was readable despite the fact it got wiped and then had a whole windows install.
NAND also experiences minor permanent damage on writes. Actually clearing the NAND involves a write as the charge has to be forced out (a write of 0s)
This can happen when TRIM is disabled
Here's a study published last year I read that goes through this exact thing
Non PDF link
Edit: corrected links
I doubt that the firmware is doing an overwrite of TRIMmed data. Rather, I expect it's marking it as having been TRIMmed, and so can report that it's zeroed to higher layers. If a higher layer queries the firmware for its content, sure, they might get zeroes returned. But if you can modify the firmware or otherwise bypass it, you may be able to get at the underlying media.
There is also the "bad block" issue, where storage media can take blocks -- which may contain readable data -- out of use, so that higher layers cannot access them. That applies to rotational drives and it looks like SSDs do the same thing. Again, might require bypassing or modifying the firmware to get direct access. But there can be data leaked there.
I also wouldn't be terribly surprised if there is lingering information even after zeros are written to an SSD that might be recoverable if you could directly access the media, though I'm not familiar with the situation there. That is the case for rotational drives -- the drive platter itself is "analog", doesn't just store a discrete string of ones and zeroes at the physical level. I once knew a cryptographer who was working on quantifying that leakage for rotational drives.
Now, attacking some of that is a pain and probably not a concern, but there are some cases where it might be a target. I once knew a professor who used to work at the Department of Defense, and he'd talk about their disposal process for rotational drives:
Drive has N random overwrites.
Drive gets passed through a rock-crusher device.
Remains get put in an acid bath.
I don't know what they did if Step 1 couldn't be completed due to drive failure. Maybe they were allowed to skip that step in that case.
That being said, probably most people don't have to worry about the same level of resources being aimed at them.
EDIT: Step 1 might have been a degauss rather than an overwrite. Either way, it was definitely just aiming to twiddle bits, not physically destroy the drive. I'm trying to remember a conversation from a couple decades back...
TRIM is garbage collection and is a part of the wear leveling system. The whole point of TRIM is to have the SSD only hold the charge it needs too for still in use (i.e. not deleted) data. It's the charge that damages blocks over time, so to extend lifespans it clears everything not needed. It's not overwriting data for security or anything per se, but rather just a result of its longevity processes
Now, I'm sure there are cheap no name SSD controllers out there with ineffective TRIM operations that just lie about the operation, but any controller worth its salt is gonna have proper TRIM.
Part of that process is to move the data to another block and release the charge to prevent further damage, it's possible the block is damaged in such a way that it won't even release the charge, but if that's the case it's incredibly unlikely to be readable.
Yea it's possible, but now you're in the needing x-ray machines, powerful microscopes, full clean room labs and people with extensive, specific skill sets which means $$$$$$$$$$$$$$$$$$$$ or in other words, state level budgets range. 99.99999% of people will be fine
I'm pretty sure that that is not correct.
The limiting factor is the number of writes. The reason that TRIM enhances life by facilitating wear leveling is that it lets the firmware know that the block no longer has useful data, so it can be returned to the pool used for wear-leveling. Without that, the firmware doesn't know whether or not it can switch the physical block used to represent a given logical location and safely overwrite the existing contents of that new block.
Ah I see the disconnect, TRIM doesn't live in the OS outside of the firmware, TRIM is part of the controller firmware and is exposed as an ATA command for the OS to utilize
The study I have linked in my original comment goes more in-depth
Yes, I know.
I'm on a phone, and it only partly showed up.
Direct PDF link
I mean, I read the PDF, the problem was the viewer bogging down.
googles
This sounds like what I expected:
https://superuser.com/questions/1060831/triming-as-alternative-to-securely-erasing-a-ssd
EDIT: I took a look at your PDF on a desktop. While it's pretty light on the specifics of how they tested that the data was present, nothing there talks about anything below the OS level. My expectation is that what they did for their test was try to do reads from the device at the OS level and see whether it returned zeroes. They aren't going to look below that. If they were interfacing with the drive at a firmware or below level, I'd expect them to have mentioned it, as it'd be a significant amount of additional work. And they don't list relevant information like model number, much less firmware revision on the drive.
This is a complete digression but do you know if there is a consumer hardware that can be reliably erased? I'm trying to make something behave as an affordable HSM. If I could store a key encrypted at rest and be able to actually delete it, that would work for me.
Like, to create a hardware keystore? No, I don't, sorry. If I wanted one myself, I'd probably just buy an existing one and hope that they did things correctly. :-)