Primarily, when an SSD slowly fails the sector replacement allotment has already bled data into read-only areas of the drive. As a user, there is no way to reliably scrub that data.
If the drive suddenly bricks, the warranty service will often not return the original hardware... and just the password protection on an embedded LUKS key is not great.
There are effective disposal methods:
1. shred the chips
2. incinerate the chips
Wiping/Trim sometimes doesn't even work if the Flash chips are malfunctioning. =3
Note 10000 GPUs can brute force passwords rather quickly (a pre-sharded search space is fast), and key exfiltration for targeted individuals/firms still happens.
Options like modern TPM include anti-brute force features, but has other attack surfaces. Everyone has their own risk profile, and it is safer to assume if people want in... they will get in sooner or later. ymmv =3
This is exceptionally poor advice. This is why TPM exists. Unfortunately adoption is low with the Linux crowd because they still believe the misinformation from 20 years ago.
TPM collocates a physical key on the same host, incurs its own set of trade-offs with failures or physical access in dormancy, and requires trusting yet another vendor supply chain. There are always better options, but since the Intel Management Engine can access TPM... such solutions incur new problems. Privilege escalation through TPM Sniffing is also rather trivial these days.
Have a great day. =3
Nowadays you use the fTPM built inside the CPU. And if you don't trust the CPU maker, well, you have bigger problems.
On Intel & AMD, both have a "hidden core" (i.e., a 4-core processor is really a 5-core processor), and they run proprietary, closed-source operating systems that literally no one outside of Intel or the NSA has any idea what they do.
We do know it has full access to the fTMP, RAM, and Network.
We also know that the NSA has a special contract to obtain Intel processors with the IME disabled... Why would they want that if the processors were trustworthy[1]?
[1] https://web.archive.org/web/20170830201623/https://hardocp.c...
The best plans simply don't require secrecy. ymmv
Have a glorious day =3
Securely erasing flash drives with a threat model of "someone will dump the raw data of the chips" is only fully solvable for self-encrypting drives where you can replace the key. Even if you can issue a block-erase for every single block of the device, block erase doesn't always succeed on NAND.
Tools like dban stopped working once firmware sector re-mapping chips on modern storage became common. If you see the reported spare replacement count drop on your older s.m.a.r.t reports, than partial sectors may no longer be accessed from the OS without vendor specific forensic software. =3
In this case, the other posts suggesting a hammer is not sarcasm. =3
Physical destruction as the only sure way? When your hardware is stolen, good luck physically destroying it.
> blkdiscard: /dev/nvme0n1: BLKSECDISCARD ioctl failed: Operation not supported
I've got a USB-to-NVME adapter that exposes the NVME namespaces as SCSI disks. `blkdiscard` did not work with these by default, however it worked fine after I changed the `provisioning_mode` attribute of the disk.
This can be done by identifying the SCSI device ID of the disk (lsscsi) and then changing it with:
# echo unmap > /sys/class/scsi_disk/a:b:c:d/provisioning_mode
This is absolutely not to be used as an alternative to a real 'sanitize' operation directly sent to the NVME controller. If you actually need to securely erase your data, and the drive dosesn't support the sanitize operation, then you should physically shred the drive and demand a refund from the retailed (goods as sold are not fit for purpose).
Overall, I've found dealing with nvme a frustrating experience. In theory it's nice to have NVME controller firmware be responsible for executing commands from the host (sanitize! change LBA size! underprovision by 30%!) but in practice, it's complete hit or miss whether controllers support a command or will reject it, or maybe they claim to support it but it doesn't work because the controller firmware is buggy shit.
I would like to have raw NAND devices and have the kernel be in charge of everything, but sadly that wouldn't work for Windows so we're stuck in proprietary firmware hell.
Most modern motherboards, on boot, will block "security operations" on a drive where the security password is set to the default (because it hasn't been manually set by the end-user). They do this to prevent malware from being able to set a password on a drive that hasn't had its password set. (Malware could set the password and I believe configure the drive to effectively brick it.)
But many (probably most) motherboards fail to correctly block "security operations" on a suspend/resume. This is bug 2, and makes suspend/resume often an effective workaround for a drive with bug 1, as well as a theoretical opportunity for malware to easily inflict damage on all drives that support "security operations".
So one generally ends up stuck and unable to securely erase their drive when it has bug 1 and is installed on a motherboard without bug 2. In this case, you have to hope your motherboard has a feature in its BIOS to, on next boot, not block security operations. Otherwise you're stuck and need to find another motherboard if you want to sanitize your drive, or hope that a firmware update for your drive resolves bug 1.
The full details are in this comment on a Github issue from 2016: https://github.com/linux-nvme/nvme-cli/issues/84#issuecommen... . It was one of the most rewarding bugs I've had the fortune to get to the bottom of. We were extra motivated to fully understand it when we moved to a new SSD benchmarking test system that turned out to not have bug 2: https://pcpartpicker.com/forums/topic/460000-an-ssd-that-can...
locked/frozen during boot
until the drive has been power-cycled
Which in theory should free all of the blocks on the flash.
Really hard to find good documentation on this stuff. Doesn't help that 95% of internet articles just say "overwrite with zeroes" which is useless advice
[edit] sanitize runs on the controller level while format works on the namespace level. So I suppose formatting won't touch any pages not allocated to a namespace.
I wish there was _any_ way to find out which NVME controllers supported which operation before you buy them!
The block device you see is an abstraction provided by the SSD controller. In reality, the flash capacity is larger. Pages are swapped out for wear leveling. If a block goes bad, it'll be taken out of commission, and your data may hide in there.
All of this happens on the SSD controller. The kernel doesn't know. You have no way to directly erase or modify specific blocks.
*Okay, there are raw NAND flash chips without controllers, but that is not you're working with when you have a SSD or flash drive. If you do have a raw flash chip, you can more directly control flash contents.
But that doesn't even overwrite the visible drive space; you can do a simple PoC to demonstrate that Windows won't get to all the mapped blocks. And that still hasn't gotten to the overprovisioned blocks and wear leveling issues that the article references.
You could use the BIOS or whatever CLI tool to tell the drive to chuck its encryption key, but are you sure that tool meets whatever compliance requirements you're beholden to? Are you sure the drive firmware does?
So they went with paying a company to shred the drives. All of them. It's disgustingly wasteful.
I heard of similar issues with early nvme drives.
Every organization with good security hygiene requires physical destruction of SSDs. Full stop, end of negotiation, into the shredder it goes.
Not that it matters much, with the prices of SSDs skyrocketing people are moving back to mechanical disks.
blkdiscard is just a TRIM command, the data remains there.
A few years ago (2020?) I also learned that ssd firmware can be buggy when I bricked multiple really expensive enterprise ssd (samsung?)....by running trim. lol.
Flash looks like a simple array of blocks, but under the hood there is a controller that allocates writes to different pages. You need to tell the controller to erase all pages if you want to guarantee data destruction.
I have a few comments to make:
1)
Erase operation is in fact a succession of two commands: ATA Security Erase Pepare and ATA Security Erase Execute. No other command can be sent between these two, so any disk access by the OS after the first command would cause the second to fail.
2)
ATA Security commands are usually blocked ("frozen") after boot if the drive has no password or was password-unlocked. That means the drive will not accept commands to set/change password or erase until power-cycled. That is a full power cut, not just a reset-drive command.
This feature prevents a virus from passwording or erasing your drive. Yes, it can still crypto-lock or erase your drive via ordinary disk writes, but that takes hours for the whole drive, while ATA Security Erase or setting a password takes a millisecond or so.
The ATA Security Freeze command is sent to the drive either by the BIOS/UEFI (my BIOS didn't do this, but probably all laptops have it as part of their BIOS/UEFI Security features), by a BIOS module (my desktop BIOS didn't have it), by the operating system as part of drive encryption features, or by an antivirus. Also, the drive firmware may have a timer to automatically freeze ATA Security commands after a timeout if it doesn't receive the explicit command from the host.
Power cycling by putting the system to sleep and then wake up will NOT work, because if the drive is locked with a password, it needs to be unlocked BEFORE the firmware/ACPI gives control back to the operating system. Otherwise, the OS would no longer be able to access the disk after wake up. So, the BIOS/UEFI/ACPI, if it supports ATA Security at all, will automatically freeze ATA Security commands again during wake-up, just as it did during cold boot.
In conclusion, the dive must be physically unplugged from power and then hot-plugged. Or start the computer without it, and hot-plug it after boot.
3)
Many (most?) USB adapters don't support ATA commands at all. They'll just emulate a USB mass storage with no direct access to the drive. What you need is an adapter that supports UAS (USB Attached SCSI). And even then, I'm not sure ATA Security commands have a SCSI equivalent so they can be translated.
The best option here is to hot-plug into a real SATA port on the motherboard or PCI/PCIe controller. NOT via USB.
If you insist on erasing the data, overwrite the entire contents of the drive twice with random data.
Doing it twice will blow away any cached as well (probably).