[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Wiping an unencrypted SSD in preparation for encryption



On 6/10/21 9:31 PM, David Wright wrote:
I'm about to install buster or bullseye on a newly acquired laptop
with an SSD (a first for me). I'm intending to clean (zero or
randomise) the entire drive with dd before I start, and am
interested in any pitfalls with that.

I will also encrypt the new /home partition, but for the remaining
partitions I need to decide whether to add mount's discard option,
or use a weekly systemd trim, or leave it entirely up to the garbage
collection in the SSD device itself (which is an nvme THNSN5512GPUK
TOSHIBA, presumably an OEM model supplied for this HP Spectre).

The machine has 16GB of memory, so I wasn't intending to use swap.
(It won't have to hibernate, and if push came to shove, there's
always the possibility of setting up a swapfile or a ramdisk.)

Background:

The July 2017 system was pre-installed with Windows 10.

I have copied the entire disk to external spinning rust, and can
mount partitions from this image. It's difficult to foresee my ever
wanting to reload and run this Windows system.

The drive has unencrypted information on it, either in existing files,
or in deleted/overwritten/whatever ones (though I think that is
irrelevant to the method for erasing them).

I don't work for the CIA, so "basic" erasure methods are sufficient,
ie so-called logical and digital sanitisation, but not analogue
sanitisation/purging. I'm just encrypting stuff like personal bank
records etc, and not looking for anything like plausible deniability.

Cheers,
David.


You want to command the SSD controller to do a "secure erase". The manufacturer should provide a utility for this, but it will likely require Windows. In years past I have found Linux CLI utilities to do secure erase. STFW for details.


I would then make a decision between BIOS/MBR or UEFI/GPT. I prefer the former so that I can boot system images in the older machines in my SOHO LAN. Eventually we will all be using the latter.


I would then install Debian using the Debian Installer, choose manual partitioning, and partition the SSD as follows:

1.  Create a 1 GB unencrypted partition with ext4 and mount it at /boot.

2. Create at least a 1 GB encrypted (dm-crypt) swap partition. I experimented with no swap in the past and found that the systems were unstable when free memory was low.

3. Create a small (I use 13 GB) encrypted (LUKS) ext4 partition and mount it at / (root).


Once Debian is installed, I would take a raw binary image of the system drive for backup, reboot into single-user mode, login as root, create a fourth partition, create a LUKS key, chmod the key to 0400, put a LUKS container into the 4th partition using the key, add an entry to /etc/crypttab for the fourth partition using the key, open the LUKS container, put an ext4 filesystem inside the LUKS container, move aside the old /home subdirectory, add an /etc/fstab entry to mount the new ext4 filesystem at /home, mount the new /home, copy the old /home contents into the new /home, reboot into multiuser mode, and verify everything. I would then take another raw binary image for backup. It would be best to do this before you log in to any unpriviledged accounts, so that /home contains few or no directories or files.


I don't bother with the 'discard' option in /etc/fstab, but perhaps I should. The fstab(5) and mount(8) manual pages are unclear if 'discard' applies to swap or ext4. Beware that adding 'discard' to /etc/fstab boot, swap, and/or root entries could break boot. If you want trim, one option might be to run fstrim(8) periodically.


David


Reply to: