196 lines
6.7 KiB
Markdown
196 lines
6.7 KiB
Markdown
+++
|
|
title = 'HowTo wipe SSD'
|
|
date = 2024-12-12
|
|
image = 'https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2Fi.imgflip.com%2F5fold8.jpg&f=1&nofb=1&ipt=57d5a7bd95d2cf08d7a126d00926f244038b58c47a130479233bd079c024a6f9&ipo=images'
|
|
+++
|
|
|
|
|
|
|
|
If you are using SSD and want to securely wipe it (so no one can recover data), then you are in a trouble since it isn't as easy as with [HDD](/tech/howto_wipe_hdd_101) thou faster. <!--more-->
|
|
|
|
> Warning: Be *really* sure that you are wiping correct drive. If you are doing it in script, then find your drive in `/dev/disk/by-id` since linux can change `/dev/sdX` after reboot
|
|
|
|
> By the way. You can't just wipe individual file on SSD, it won't be removed securely.
|
|
|
|
## Level 1 - blkdiscard
|
|
|
|
```sh
|
|
blkdiscard -v /dev/SSD
|
|
```
|
|
|
|
### Verify
|
|
|
|
```sh
|
|
echo 3 > /proc/sys/vm/drop_caches
|
|
cmp /dev/zero /dev/SSD
|
|
# expected result: EOF on /dev/SSD
|
|
```
|
|
|
|
pros:
|
|
- Just works on any SSD
|
|
- Done in a blink of an eye
|
|
- Scriptable (just add `-f`)
|
|
|
|
cons:
|
|
- Not secure, data still can be recovered.
|
|
`blkdiscard` will tell SSD to wipe blocks, SSD should put them to TRIM queue and wipe them *later*. It can't be secure and we don't trust SSDs manufacturer with that.
|
|
|
|
## Level 2 - SATA Secure Erase / NVMe SES
|
|
|
|
### SATA
|
|
|
|
```sh
|
|
hdparm -I /dev/SSD
|
|
```
|
|
In a buttom part, 'Security' section
|
|
|
|
```sh
|
|
# IF ' frozen' - we need to unfreeze it by putting PC in sleep for a few seconds
|
|
echo -n mem > /sys/power/state
|
|
# or - systemctl sleep
|
|
# check if it frozen
|
|
hdparm -I /dev/SSD
|
|
# if it still frozen - repeate sleeping/waking until it's not. #TODO is there any other better way???
|
|
```
|
|
|
|
```sh
|
|
# IF 'not frozen' - we will set up temporary password 'p' (don't change) for a drive to issue secure erase command
|
|
hdparm --user-master u --security-set-pass p /dev/SSD
|
|
# Check to see if the password is set correctly and that security is now enabled
|
|
hdparm -I /dev/SSD
|
|
# In 'Security' section now should be ' enabled' and 'Security level high'
|
|
```
|
|
|
|
```sh
|
|
# Finaly erase drive
|
|
# If the drive DOES support Enhanced Security Erase:
|
|
hdparm --user-master u --security-erase-enhanced p /dev/SSD
|
|
# If NOT:
|
|
hdparm --user-master u --security-erase p /dev/SSD
|
|
# After reset password should be disabled automatically
|
|
hdparm -I /dev/SSD
|
|
```
|
|
|
|
In case if you get error when tried to wipe and want to disable password:
|
|
```sh
|
|
sudo hdparm --user-master m --security-erase NULL /dev/SSD
|
|
# if didn't worked try --security-disable
|
|
# also try with --user-master u
|
|
```
|
|
|
|
|
|
pros:
|
|
- Should work on most SATA SSDs
|
|
|
|
cons:
|
|
- You can't be sure that it is secure wipe if you paranoid enough or against NSA.
|
|
When you issue Secure Erase, SSD controller should instantly wipe all memory banks by just giving power on them. If you don't trust your SSD's manufacturer, then it isn't sufficient.
|
|
If your drive is SED (self-encrypting drive), then it should remove cryptographic key instead of wiping memory banks making proccess faster
|
|
- Complicated. Hard to add in a script
|
|
- Drive must be directly attached to SATA (no USB, RAID controller or NVME SSD...)
|
|
- Long, expect it to take up to a hour
|
|
|
|
### NVMe
|
|
|
|
```sh
|
|
sudo nvme format /dev/nvmeSSD --ses=1
|
|
# Or if you have SED (self-encrypting drive)
|
|
sudo nvme format /dev/nvmeSSD --ses=2
|
|
```
|
|
|
|
pros:
|
|
- Should work on most recent NVMe SSDs
|
|
- Scriptable
|
|
|
|
cons:
|
|
- Same as in SATA - You can't be sure that it is secure wipe if you paranoid enough or against NSA.
|
|
Drive's firmware decide how exactly it should be erased (e.g., zeroing, random data overwrite)
|
|
In case of `--ses=2` and SED drive - it will remove crypto keys what is going to be fast
|
|
- Long, expect it to take up to a hour
|
|
|
|
## Level 3 - dd/shred + blkdiscard
|
|
|
|
```sh
|
|
dd bs=1M status=progress if=/dev/urandom of=/dev/SSD
|
|
# or - shred -v -n 1 /dev/SSD
|
|
|
|
blkdiscard -v /dev/SSD
|
|
```
|
|
|
|
### Verify
|
|
|
|
```sh
|
|
echo 3 > /proc/sys/vm/drop_caches
|
|
cmp /dev/zero /dev/SSD
|
|
# expected result: EOF on /dev/SSD
|
|
```
|
|
|
|
pros:
|
|
- Just works on any SSD
|
|
- Scriptable
|
|
|
|
cons:
|
|
- Long, expect it to take up to a hour
|
|
- Security - complicated. `dd/shred` aren't a guaranteed to securely wipe entire SSD. The issue is a complexity of a SSDs:
|
|
wear leveling, garbage collection, logical/physical data mapping, TRIM during proccess... They all make `dd/shred` arent reliable to securely wipe entire SSD, some parts of a drive still can be recovered.
|
|
If you trust enough your drive manufacturer and drive didn't containe any important information, then just use SATA Secure Erase / NVMe SES.
|
|
|
|
## Level 4 - paranoia
|
|
|
|
Well, if you paranoid enough to wipe device for sure, then we are combining stuff above in extreme maner (your disk should be like 3 times overwritten)
|
|
|
|
```sh
|
|
shred -v -n 1 /dev/SSD
|
|
echo 3 > /proc/sys/vm/drop_caches
|
|
blkdiscard -v /dev/SSD
|
|
echo 3 > /proc/sys/vm/drop_caches
|
|
|
|
# !!!ISSUE SATA Secure Erase / NVMe SES!!!
|
|
|
|
echo 3 > /proc/sys/vm/drop_caches
|
|
|
|
# We will do random data wipe once again by encrypting 0s and verifying encrypted 0s later
|
|
cryptsetup open --type plain --cipher aes-xts-plain64 /dev/SSD cryptyourssd
|
|
# Pass:Three unicorns went into a bar and got stuck in the door frame
|
|
badblocks -b 4096 -t 0 -s -w -v /dev/mapper/cryptyourssd
|
|
|
|
# Power off your PC and boot it again
|
|
# Open drive again
|
|
cryptsetup open --type plain --cipher aes-xts-plain64 /dev/SSD cryptyourssd
|
|
# Pass:Three unicorns went into a bar and got stuck in the door frame
|
|
|
|
# verify that you did good
|
|
cmp /dev/zero /dev/mapper/cryptyourssd
|
|
# expected result: EOF on /dev/mapper/cryptyourssd
|
|
```
|
|
|
|
pros:
|
|
- tranquility knowing that drive is wiped
|
|
- you still have a working drive!
|
|
|
|
cons:
|
|
- The longest, expect it to take a few hours
|
|
- You need to understand what you are doing
|
|
|
|
## Level 5
|
|
|
|
<!--  -->
|
|
{{< rawhtml >}}
|
|
<video width=100% controls autoplay loop>
|
|
<source src="https://i.imgur.com/q2ZIwQ7.mp4" type="video/mp4">
|
|
Your browser does not support the video tag.
|
|
</video>
|
|
{{< /rawhtml >}}
|
|
(If you cant see a video, then the answer is - physical destruction)
|
|
|
|
{{< source >}}
|
|
https://superuser.com/questions/1284450/quickest-way-to-wipe-an-ssd-clean-of-all-its-partitions-for-repartitioning-in-li
|
|
https://unix.stackexchange.com/questions/681521/securely-erase-ssds-the-whole-ssd
|
|
https://grok.lsu.edu/Article.aspx?articleid=16716
|
|
https://superuser.com/questions/1671399/remove-unknown-ata-password-with-hdparm
|
|
https://unix.stackexchange.com/questions/659931/how-secure-is-blkdiscard
|
|
https://superuser.com/questions/1530363/how-to-securely-erase-an-nvme-ssd
|
|
https://serverfault.com/questions/147759/dd-vs-secure-erase-for-reconditiong-ssds
|
|
{{< /source >}}
|
|
|