ShredOS – Secure disk erasure/wipe(github.com)
github.com
ShredOS – Secure disk erasure/wipe
https://github.com/PartialVolume/shredos.x86_64
12 comments
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.
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.
When a new key is generated, how can you be certain that the old key is securely deleted?
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.
You have to trust the SSD firmware. And if you don’t, just add your own layer of encryption and manage the key yourself.
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.
> There’s an easier way - use full disk encryption with a TPM. Data effectively erased upon destruction of TPM key.
Assuming you can trust the drives to actually encrypt:
* https://news.ycombinator.com/item?id=18382975
Assuming you can trust the drives to actually encrypt:
* https://news.ycombinator.com/item?id=18382975
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.
What happens when the encryption is broken in the future? I feel like relying solely on the key isn’t good enough.
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.
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.
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?
> What happens when the encryption is broken in the future?
Your great, great grandchildren will be embarrassed of the websites you visited.
Your great, great grandchildren will be embarrassed of the websites you visited.
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.
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.
From the nwipe (what this uses) page:
>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: ...
https://github.com/martijnvanbrummelen/nwipe
The ShredOS page suggests the use of hdparm for SSDs but things are fairly complicated:
* https://github.com/martijnvanbrummelen/nwipe/blob/master/ssd...
>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: ...
https://github.com/martijnvanbrummelen/nwipe
The ShredOS page suggests the use of hdparm for SSDs but things are fairly complicated:
* https://github.com/martijnvanbrummelen/nwipe/blob/master/ssd...
These days I'd just take a hammer to a dead SSD and smash the chips to powder.
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.
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...
Hammer sounds easier to verify the destruction worked.
> https://github.com/martijnvanbrummelen/nwipe/blob/master/ssd...
Yeah:
> 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.
Yeah:
> 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.
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)
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.
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.
DBAN for a new generation. This is pretty cool. So far DBAN is still getting the job done for me, but this looks like a solid replacement.
I don't think DBAN works on SSDs. The inner workings of the device tricks DBAN into thinking it is zeroing out parts of the drive but it is not.
That and the fact that SSDs hold back part of the usable storage for optimizations means DBAN can't even seen the whole drive.
That and the fact that SSDs hold back part of the usable storage for optimizations means DBAN can't even seen the whole drive.
Neither does nwipe:
https://news.ycombinator.com/item?id=42568171
https://news.ycombinator.com/item?id=42568171
> PRNG Stream - Fills the device with a stream from the PRNG.
How are you going to explain to the TSA officer that the disk does not contain encrypted data?
How are you going to explain to the TSA officer that the disk does not contain encrypted data?
There is no way to prove that random data is not actually encrypted data. This is a feature called plausible deniability
"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."
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."
Does TSA ever inspect hard drives at the bit level?
Imagine being lectured on entropy by a TSA agent with an electron microscope.
If you care, do a final pass with zeroes.
(IMHO the very concept is obsolete in the era of SSDs & SMR.)
(IMHO the very concept is obsolete in the era of SSDs & SMR.)
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.
I always wondered what is the difference between OS level secure erasure and software level secure erasure?
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.
It's 2024, and you have:
https://grok.lsu.edu/Article.aspx?articleid=16716
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.
nvme format -s1 /dev/nvme0n1
https://grok.lsu.edu/Article.aspx?articleid=16716
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.
I was just wondering what NVME used in place of HDPARM since they’re PCIE. I forgot about the nvme utility!