I am giving away a shitty 128GB SSD, which was used with LUKS 2 for most of it’s lifetime. As far as I know, it’s good practice to secure-erase it, but I’m too lazy to reinstall the OS on it (I already did it once). Is it really needed?
You must log in or register to comment.
I think one TRIM cycle should make any data unrecoverable by all but the most determined. Feel free to correct me if i’m wrong though.
It you really care, throw this on a usb stick and sleep well. It replaces to old dban system, which has gone commercial. https://github.com/PartialVolume/shredos.x86_64
Do not dban an SSD.
SSDs do not physically store data the way platter drives do. It may reduce the lifespan of the drive.
There are other methods for securely erasing SSDs.
https://www.tomshardware.com/how-to/secure-erase-ssd-or-hard-drive
That’s quite right, which is why nwipe (the core tool of ShredOS) has a different mode for SSD vs HDD.
Everything that was luks encrypted is unrecoverable once you overwrite the luks header. Trying to guess the master key takes longer than the lifetime of the universe.
Just make sure that is gone and you are good. If you deleted all partitions and installed another (unencrypted) OS on the drive there is a very good chance the luks headers are gone for good.
Secure erase just drops the ssd controllers table of where logical blocks are in the physical memory and trims the disk. Which is good and you should do.
That means a person would have to address the memory directly with flying leads or a bed of nails or something. Or have special software that makes the controller tell them what’s on each physical block and then put that data together into a bunch of files.
If that worries you, do dd if=/dev/urandom of=/dev/<disk> before you secure erase.
Then everything on the drive will be random static before the secure erase drops the block table and trims, so even if someone uses magic power to read the block contents directly they just get to see static.
That has the benefit of speeding up the drive by resetting read fatigue at the expense of one layer of writes which is always worth it.
Ah, fun fact, dd won’t actually cover all the blocks since SSDs have reserve blocks and IIRC they do rotate which ones are in use vs which are not, to even out wear
Yes of course this will only rewrite some number of blocks that total the disks reported capacity. In the case that a person is worried about hidden blocks being preserved by a wear leveling algorithm they could just run the same command again and that would get em all.
Useless use of dd. cat or cp are better suited in this case.
That’s only true for some environments.
E: this is the first time I’ve read that blog post since it was published (or at least a long time ago) and there’s now a comment specifically referencing the actual behavior I observed in the wild when I tried to sub other things in for “normal” uses of dd:
Nobody says: 2016-12-30 at 15:17
cat /dev/cdrom > myfile.iso
Works
cat myfile.iso > /dev/cdrom
Won’t – dd allows you do handle writes in various block sizes, so if a device can’t handle a one-byte write, cat could well end up writing your byte followed by zeros (and because of where the pointer now is, do it again for the next byte).
Still, all your other points stand – nice piece.
While that comment was written seventy years ago, in this age of people with questionable intent, capability and integrity rewriting system tools in rust there’s no better time to linger thoughtfully over cp or cat or any number of other commands that begin with the letter “c” before grabbing the ol’ reliable footgun whose fifty years of script backwards compatibility ensure that no one can get their dd replacement accepted in normal use until it behaves as expected.
@JamesBoeing737MAX Overwrite your LUKS-Header and you’re good. After this just format in in ext4 and all is gone.
You don’t have to install anything on it, just connect it to a running PC and do a dd if=/dev/zero, that should be enough to get rid of any remnants directly accessible.
Unless you are part of a drug distribution organization, in that case just use a hammer, a microwave and a blowtorch.Not really great on SSDs, though. It’ll likely make them slower because now the controller thinks 100% of the memory is allocated. And some small percentage of the data will still be around, because they do overprovisioning.
Shouldn’t matter for OP, though. If they set up LUKS properly, there’s no way to decrypt the data.
But I mean secure wipe isn’t hard… It’s copy-pasting 2 more commands from the Arch wiki, compared to the dd command.
some small percentage of the data will still be around, because they do overprovisioning.
That’s why I wrote “directly accessible data”. You are certainly right that safely erasing all data on SSDs is hard to impossible to achieve, but so is the read access to it.
That means if we disregard the drug distribution or similar scenarios, should be enough for the normal person.But I mean secure wipe isn’t hard… It’s copy-pasting 2 more commands from the Arch wiki, compared to the dd command.
But it will take significantly longer (typically using /dev/random and multiple passes) without noticably increasing security for SSDs.
It will have also have the same possible write-speed-penalty issue as the zero-overwriting, but this won’t be OPs problem any more because he is selling the SSD.
I don’t think so. I did a secure erase on my Samsung SSD and I forgot how long it took, but I still remember being surprised how quick it was. I think it was quicker than overwriting the entire disk, even with zeros. I even double-checked whether it did it because it was done so fast. But yeah, it didn’t return any data after that.
I mean I’m generally not a big fan of all the compromises. Sure maybe most of it is deleted. Maybe it’s not that easy to recover the rest of it. Maybe there’s an easy tool out there… I mean the issue with it is, we have all kinds of personal data on our laptops. One nude left, or the tax filings document and you might be in trouble anyway, if you do some half-assed compromise. Maybe you’ll give it to a regular person and nothing will happen… But I think generally it’s not good advise to hand out to people. They might not be aware of all of the consequences, we might not know the full picture… And the exact phrasing is doing way too much heavy-lifting.
Luckily there’s a clever way. Use LUKS and encrypt your disk right from the start. (As OP did?!) That takes care of everything. And once you give it away, just discard all the blocks. Mainly as a service to the next person, because that’s going to make the drive fast again. Should also be the fastest option, since SSDs do TRIMs all the time and are optimized for it. Quicker than a dd over the entire drive.
Thing seems to be though, that OP did not use LUKS consistently, but mixed with unencrypted uses.
In this case, fast, file-oriented secure-erase (or just throwing away all the LUKS headers, if the remaining partition was encrypted) might miss the remnants of old unencrypted uses.
So, specifically in OPs case, I am not sure if there is another safe option than a full-device overwrite e.g. using dd.…if you follow it up with a secure discard of all of the remaining blocks.
You said that:
I am giving away a shitty 128GB SSD, which was used with LUKS 2 for most of it’s lifetime.
This leads me to assume that it is not now? Is this the case? If it still has LUK2 on it, you can run cryptsetup-erase on the luks2 container. This won’t wipe any unencrypted data, though.
One needs to be careful and avoid block level wipes wherever possible for SSD as this will wear it out quicker. Obviously, if you have sensitive data unencrypted, you may have to. Shred is your friend, here. It works on entire devices as well as individual files. The individual files option is preferable if you the sensitive data is at known locations.
Does shred work on journaling file systems?
deleted by creator
cat /dev/urandom > /dev/your-diskshould do it in your case. And in 99% of cases.this is just gonna cause useless wear on the ssd. only do this to hdds
I think you mean doing that for more than once has no extra effect on an SSD. Shouldn’t we overwrite the unencrypted content for at least once?
nope, i mean that’s just useless. (it does kinda do the job, but wears it down, and not as effective since SSDs aren’t really predictable because of wear leveling stuff and lie to the OS) there’s an ATA Secure Erase feature that can be used instead.
some relevant link https://grok.lsu.edu/article.aspx?articleid=16716
I’m assuming when you “reinstalled the OS” you just repartitioned the drive and installed normally without encryption for the person? If that’s the case then all your old data is encrypted and will be unrecoverable without your password and the LUKS header.
If however you reinstalled the OS within the already made LUKS partition and are giving them the password (for some reason) then yeah, you wanna secure erase it.
If you were selling on eBay or something I would still recommend a secure erase (they’re really quick on SSDs)
Most likely not. Did you have anything on it that you would even be concerned about someone else finding? Is anyone even likely to be curious enough to look?
Is anyone even likely to be curious enough to look?
Well, can only speak for me, but first thing I do.
I mean, you can never know which administrative scandal you might uncover…
I stop the moment I find private stuff, though.
Had that three or four times already, the only case I was considering doing something about it was a completely unsecured and unerased phone still containing a bunch of business emails that clearly were sensitive or even confidential stuff.
I just told the seller how he screwed up here, instead of making a bigger fuss out of it.Sure, but are you pulling out forensic analysis tools, or just checking what didn’t even get erased in the first place?
The devices in question all were fat formatted, for which it is quite easy to reconstruct most of the “deleted” content using readily available simple tools (which I did).
But that was some time in the past, nowadays most systems use some kind of base encryption, making it less likely to easily find something.
The phone, on the other hand, was just not doing a factory reset before selling it, but only deleting files (and missing stuff, like some mail folders) and not having a password-protection at all… 😬
