How do I securely erase data on an NVMe SSD without physically destroying it? Is it true that the guttman method is BS and only 1 pass is needed?
How do I securely erase data on an NVMe SSD without physically destroying it?
Falling into your wing while paragliding is called 'gift wrapping' and turns you into a dirt torpedo pic.twitter.com/oQFKsVISkI
— Mental Videos (@MentalVids) March 15, 2023
You cannot. Secure destruction of data means complete physical distruction.
And by complete you probably mean grinding it to dust and burning it. Having even a thumbnail sized piece is recoverable
There is no other way. You should have used fulldisk encryption.
You best bet is to encrypt your disks, that way it doesn't matter.
nvme format --ses=2 /dev/nvmeX
if your shit is dumb, you can specify the namespace/zone instead of the entire NVMe chardev.
There is no guarantee that all cells will be overwritten thanks to their internal firmware moving blocks to permanent storage for wearleveling.
the whole point of NVMe and ATA Secure Erase(tm) is that all data written to media is stored symmetrically encrypted and the controller decrypts it. after a secure erase, the controller is told to "forget" the key it used and it generates a new one. While I agree it's still dubious if it actually "forgets" the key, no one has proved it doesn't and unlike ATA Secure Erase, at least NVMe requires you explicitly ask for it, where the command code 1 for erase is not so obvious and "implementation defined."
as others itt have said, using your own FDE scheme from the start.
Black boxes are always a big hazard when talking about security. Firmware can and will have bugs that will eventually fuck some people over. Open source fulldisk encryption is the closest thing we have on provable security
>How do I securely erase data on an NVMe SSD without physically destroying it? Is it true that the guttman method is BS and only 1 pass is needed?
You don't even need that. You simply have to send a secure erase command which will reset the MEK on your drive and hence makes the data inaccessible.
Stop talking about things you don't understand. OPs question is about destroying data. All SED vulerabilities that have been found so far are not applicable to a scenario where secure erase was induced because the MEK would be gone. Without the MEK the data cannot be decrypted again.
So you would think, but true security does not rely on obscurity. Giving OP bad advice about maybes is not good. There is no proven way to destroy data on black boxes you've already written to without physically destroying it.
Are you fucking stupid or something? TCG Opal capable drives always write data encrypted. AES is AES (let's ignore block modes) and if the MEK is gone (Secure Erase), you cannot restore the data unless AES gets cracked, regardless of firmware bugs. And just because something is open source, doesn't mean it's safe. Take 7z for example. That shit was there for YEARS until someone realized that that stupid bydlo misimplemented the initialization vector. I would even go so far and claim that hardware encryption is safer than software encryption and before you start linking articles (which you haven't read and understood) to me about how SEDs have been compromised, yes I know all about it. Crucial actually fucked up the TCG Opal implementation on their very old drives which were basically the first implementations. Proper TCG Opal over (not over ATA security) on Samsung drives for example has not been cracked to this day.
http://www.privust.com/sedlies/ makes very good points.
.
OP there you go https://www.crucial.com/support/articles-faq-ssd/methods-for-erasing-an-ssd. If you don't have a Crucial SSD you can also use sedutil (linux ships this by default) and do a PSID revert.
*by the way. I use hardware encryption (sedutil with TCG Opal capable drive) + software encryption (LUKS + dmcrypt).
It very much matters if your firmware implementation of AES is flawed. If it's unobservable we don't even have the chance to make sure it's working, you simply have to take them at their word. There have been instances where hardware encryption has gone bust before. You'd be a fool to buy a promise.
this, if you put clear text data into proprietary things, software or hardware, there is no secure way of getting rid of it but moving up to the physical layer and destroying the thing. anything else is just trusting potentially glowie backdoored technology.
>There have been instances where hardware encryption has gone bust before.
No they have not. Maybe fucking finish reading my post instead of acting like an illiterate nagger. Have you actually read the paper (https://www.ieee-security.org/TC/SP2019/papers/310.pdf)? I have.
Let me sum up what has actually happened:
- Crucial completely fucked up (ignoring standards) in their very first interations of SSDs. Bear in mind that this was more than 10 years ago when SSDs were new. I don't know why anyone would buy an SSD from that cheap ass manufacturer anyway.
- In SOME drives SED over ATA-security was breached because there was a default master key for these drives. If the user set his own master password or disabled master passwords (ATA_SEUCIRTY_MODE=MAX) there was no way to access the data even if you were dumb enough to use it over ATA-Security. TCG Opal was NEVER intended in being used over ATA-Security.
- To this date, no Samsung or any other drive of a serious manufacturer drive was breached if TCG Opal was used properly.
Humans have not changed. They will always make mistakes, and I will not believe for a second that 'this time it'll work', unless it can actually be proven, which you can't on a proprietary device. The only choice is to practice fulldisk encryption in software
>The only choice is to practice fulldisk encryption in software
No it is not the only way. Actually hardware encryption (if open source) would be WAY more secure than software encryption because the encryption key never leaves the storage device.
Have you even read the article I linked it
? I guess not because you're a zoomer homosexual who thinks he has it all figured out. Do you realize that when you're using software encryption, your encryption key resides in your RAM? If you're on Windows that key is already compromised. Now you might say "bbut muh Linux". Doesn't matter because if you're using an Intel or AMD CPUs it's already compromised as well. With Spectre, your encryption key could have been sniffed over a fucking BROWSER regardless of your operating system. Well at least Bitlocker has TPM which makes things more difficult.
Ideally you'd use opel hardware all around, and POWER workstations are available for pretty penny, hopefully RISC-V becomes more mainstream. RAM encryption has been a thing for very long time now, excluding desktop for some msrket segmentation reason.
>It very much matters if your firmware implementation of AES is flawed.
The cipher itself is pretty much always copy&pasted. You can fuck up by using bad block modes and even then it's VERY difficult to restore data. Where most fail is properly implementing key derivation but that is irrelevant in the case of secure erase because the key would be gone.
glowie here, you can't
we're gonna find your cp anon
And even if you can't, you can always claim you did and can whoever you deem a threat to you anyway, no need to go all csi miami on autists on LULZ
>gutsman method?