Software erasure is no good on modern hardware, it pulls too many tricks internally and the data could easily stick around in a region of NAND not accessible. There’s an easier way - use full disk encryption with a TPM. Data effectively erased upon destruction of TPM key.
This is often how secure erase is implemented on SSD (though they often don't use TPMs). Encrypting data transparently on the controller, then regenerating the key on erasure request, turning the data on disk into useless bits.
Of course this comes with the risk that someone exploits the firmware and extracts the key, rendering secure erase useless, but in most cases that's good enough.
How do you be certain that ShredOS or any other component does its job? You can always physically burn the drive, but make sure you actually watch it turn to slag.
Drives which support doing this in hardware have a block just for storing the key. Because it’s not often rewritten, it doesn’t need to go in the pool of blocks that can get remapped.
I usually encrypt with LUKS and then delete the headers (and then physically destroy the disk). Don’t remember where I read about it, but been doing that for a while.
If that's in your threat model, fill the disk with random bytes.
This works on the economic argument that if you could easily recover data from a disk that's been rewritten, drive manufacturers would exploit that already to increase storage.
If your threat model includes attackers who bypass the firmware to read overwritten data, you are probably boned several other ways.
It is usually quicker to just zero the disk instead of random bytes, just because the randomness pool might be scarce in a system. This can save hours when clearing a large and fast disk, like a SSD. /dev/zero usually has much more throughput than /dev/random.
Of course this matters less on slow disks, where the bottleneck is the writing speeds anyway.
Many SSDs transform all-zero sector writes into a simple TRIM/DISCARD to reduce flash wear, so overwriting with pseudorandom data from /dev/urandom is likely more secure.
I don't understand why this question is asked in any context. What if an asteroid is on a collision course with Earth? What if Jesus comes back? What if the yeti is real?
Or whoever that has quantum computer in the near future. Encryption is just a cat and mouse game it is before long someone will figure out to decrypt it.
There is currently no reason to believe quantum computers will make breaking symmetric encryption like AES-256 any more practical than it is today. At best, grovers algorithm can modestly reduce the search time for brute forcing, but it's still brute force.
Asymmetric algorithms like RSA are the ones you should be worrying about, and I can't imagine any reason someone would do disk encryption with an asymmetric algorithm.
>In the current form nwipe does not sanitize solid state drives (hereinafter referred to as SSDs) of any form (SAS / Sata / NVME) and / or form factor (2.5" / 3.5" / PCI) fully due to their nature: ...
I haven't found a technical whitepaper on it but supposedly NAND/NOR flash goes void immediately when reaching a certain high temperature below the melting point of copper. Something about putting a blow torch to the chips for a brief moment...
Startup idea: Industrial portable just drill-holes-to-you-device-if-needed & then just-add-water data-erasure bags (single-use, safe to throw away). Would save lots of equipment weight.
> Given that the support for sanitization is optional and not a mandatory aspect of the respective standards the support accross vendors can vary largely. The following table does not claim or warrant to be complete, it is highly advised to always validate the information with the manufacturer:
It'd be nice if the INCITS/SATA/SAS folks could make it mandatory.
“In the current form nwipe does not sanitize solid state drives (hereinafter referred to as SSDs) of any form (SAS / Sata / NVME) and / or form factor (2.5" / 3.5" / PCI) fully due to their nature: SSDs, as the transistors contained in the memory modules are subject to wear, contain in most cases additional memory modules installed as failover for broken sectors outside of the host accessible space (frequently referred to as "overprovisioning") and for garbage collection.”
Interesting and that they don’t mention Enhanced Security Erasure; that SATA command would take care of the broken sectors and firmware reserved sectors. HDPARM is capable of issuing the command if the SSD/HDD supports it and HDPARM is the tool they seem to be using. Not sure what they are using for NVME though as they use PCIE…not SATA commands.
Maybe sedutil from OPAL?
Anywho, tor most drives whether SSD, HDD or NVME you can ‘erase’ it by simply setting and deleting my the KEK and UEK but to securely erase you want to do security enhanced erase data command that runs locally in the drive and is independent of the OS.
I was told absolutely secure disk erasure is actually no longer needed on SSDs due to TRIM.
It however _is_ absolutely necessary for magnetic media (HDD even when supported by SSD, and tape).
But in both cases, if you want to be _absolutely_ sure nobody can read data from a drive after parting with it use Bitlocker (Windows), FileVault (Mac) or LUKS/dm-crypt (Linux/BSD)
Pretty cool UX, however it seems to follow the approach to overwrite data once or multiple times.
As far as legends on the high magic of contemporary flash memory goes, you would want to simply tell your SSD/NVMe to secure erase the drive instead of writing data yourself. ShredOS doesn‘t seem to implement this.
"Alright ma'am, you claim this here device contains encrypted data? If you don't mind, we'll keep you here until you provide us with the password."
and meanwhile in an alternate universe
"So you say that this device just happens to contain a bunch of random data? That sounds mighty suspicious. We'll keep you here until our technicians have taken a look at it. Get comfy, it'll be a while."
Barebones alternative for *nix people: just "dd" random data over the entire disk. A single pass suffices because there is no such thing as "gleanable history" on the sectors of magnetic storage - nor for flash storage, but the complexity of spare/reserved memory blocks on SSDs may result in data escaping the procedure.
If any data "escapes" the full disk overwrite on an SSD, is it still somehow readable from software? Or would it require disassembly of the drive and specialized tools?
You won't be able to read those blocks in any normal way. I don't know if the specialized set of "block remap/reassign" commands in SCSI, or in S.M.A.R.T, can be used to reach the blocks.
Is this very different from using a bootable Linux distribution from a disc or USB drive to then wipe a disk drive? And as someone else pointed out here, with solid-state drives being more popular these days, these techniques are not sufficient.
If you are refering to EFI/BIOS level secure erase, it's for hardware-encrypted storage and the function merely replaces the current master key such that the current data becomes irretrievable.
how hard is it to just flip bits on every single available memory? Is it because you have to use the manufacturer's black box controllers and you don't really know if they actually do what you asked?
Yes, that's exactly what the problem with flash storage is. A single pass of overwriting all nominal storage is pretty close to wiping the entire disk - the spare blocks are limited in number - but with SSDs there's just no easy way to know what may be left behind on eventual bad blocks that have been replaced by spares. So-called "hybrid" HDDs that are fronted by a small SSD to give the impression of faster writes are subject to these complications as well.
The "DoD style" erase commands no longer provide adequate security for highly virtualized I/O devices like SSDs where blocks may be remapped as spares out of the directly accessible range and thus skipped by the pass. In fact, the DoD itself stipulates only physical destruction of hard drives is acceptable, and many bases have secure warehouses where old drives are stocked awaiting destruction.
reply