Re: Wiping an unencrypted SSD in preparation for encryption
On Thu 10 Jun 2021 at 23:43:12 (-0700), David Christensen wrote:
> 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.
>
> 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.
Yes, I guess the difficulty with using Windows would be that I don't
think it can erase itself while running the program.
Others' suggestions:
Jeremy: the referenced article seems to apply to SSDs that are SATA,
whereas this one is NVMe.
Glenn: the same article warns that DBAN is not designed for SSDs.
songbird, Andrew: the pre-existing data is not all ours, so it
might include others' personal data (mainly education, but could
be personnel material, given in confidence), so I feel the moral
need to erase it with at least a best attempt.
I need to investigate what's talked about in
StorageUtilities311_Manual_ENG.pdf that Toshiba can allegedly
supply as bootable media.
Polyna-Maude: You *seem* to be suggesting that I encrypt on a
file-by-file basis rather than the whole of /home. That can't
work because you don't know a priori whether an incoming file
is sensitive or not … and you'd always being having to make
decisions.
Either that, or you're overinterpreting what I wrote: I don't
encrypt partitions other than /home and swap. Home, obviously,
and swap because you have no control over what gets put there.
Besides, if swap gets used (beyond certain static uses that
I've read about, but never experienced), speed is already up
the spout. I either kill browsers, or the OOM killer might
do some culling.
> 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've already made that switch to GPT (with one exception for an
ancient, hardly used now, laptop. However, I don't burn my bridges,
and always leave a BIOS Boot partition (unformatted) in place:
con: 3MB wasted; pro: alignments of 4MB throughout the drive.
But in any case, I'm not sure about booting Grub on an SSD from the
BIOS, because AIUI Grub uses sector addresses to find its core.img,
and AIUI sectors get shuffled around by the SSD controller. OTOH,
booting with UEFI is carried out entirely through files found via
their filesystems, and the sector-shuffling doesn't affect that.
> 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.
I don't encrypt root, so I don't bother with (1).
I think I will create (2), but leave it unused for the time being.
I actually use the trick described here to LABEL my random-key
swap with a tiny filesystem on my other machines:
https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption
> 3. Create a small (I use 13 GB) encrypted (LUKS) ext4 partition and
> mount it at / (root).
I'm more generous, at 29GB.
> 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.
That's quite close to my method for /home. However, I unlock /home
*after* booting, by logging in as a pseudo-user whose home directory
is at /var/local/home/<username>. This means that I can wake a
machine, unlock /home with a passphrase, and then log in, all done
remotely.
> 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.
It's odd that mount(8) only mentions discard under the fat heading,
but ext4(5) does document it, and warns against it on the grounds
of insufficient testing. Also I haven't yet understood the interaction
of TRIM/discard with LUKS, so I think I'll leave it out, and just
watch out for any trouble.
Thanks for all the comments made.
Cheers,
David.
Reply to: