The two most interesting insights I got from this article are that:
(1) SSDs are good for privacy for average users since
they are cleaning up dirty blocks in the background.
However, IMO, privacy-conscious users who are running a daily
free-space wipe, a conventional hard disk is superior
because it guarantees that all dirty blocks are erased.
A free-space wipe on an SSD can't guarantee that reserved or
remapped blocks get erased.
(2) He says, "Somewhat counter-intuitively, information deleted
from certain types of encrypted volumes (some configurations of
BitLocker, TrueCrypt, PGP and other containers) may be easier to
recover ... if the investigator knows either the original
password or binary decryption keys for the volume".
If you delete a file in your encrypted volume (but don't do a
free-space wipe inside your encrypted volume), then someone who
knows your key could potentially recover that file.
But that's always been true -- it's true for both SSD and
conventional drives.
What I think the author is saying is that someone who use an encrypted
volume doesn't benefit from the SSD's cleaning of dirty blocks
in the background because the entire encrypted volume looks like
it's in use to the SSD controller.
But I don't see how he concludes that it's "easier".
You lose the benefit of the SSD's garbage collection, but to recover a
deleted file from inside an encrypted volume (assuming you have the
user's key) is neither easier nor more difficult with an SSD vs. a
conventional disk.
> When Bitlocker is first configured on a partition, the entire partition is read, encrypted and written back out. As this is done, the NTFS file system will issue Trim commands to help the SSD optimize its behavior.
On Linux systems, you can configure LUKS encrypted volume to use trim[1], but there are additional consequences you need to consider before doing that[2].
Regarding point #2, I think "may be easier to recover" means easier than if it weren't encrypted for the reason you stated (the blocks are in use and won't be trimmed), not easier than on a conventional drive.
> A free-space wipe on an SSD can't guarantee that reserved or remapped blocks get erased.
I think most controllers implement a secure erase feature that guarantees the data have been erased from NAND.
> the entire encrypted volume looks like it's in use to the SSD controller
I have always wondered how encrypted volume worked on an SSD. It seems this will lead to serious performance issues due to ineffective garbage collection.
Yes, a secure erase of the entire disk. That does not help with erasing the free space (a free-space wipe). Erasing the free space can't be done purely at the controller level since the controller can't tell which blocks are free and which used.
But you can image the logical filesystem on the SSD, do the free-space wipe, and then restore the image to the wiped SSD. If you could find a way to automate on a Mac with FileVault then you'd be popular.
Wait, what? The whole point of wiping free space is to prevent file recovery tools from doing a low level scan of the drive and retrieving deleted data, since a delete doesn't actually zero out the space, it just marks it as available for reuse.
But you don't know whether the blocks are actually being over written or if they've been marked as bad or if the information is in slack space or etc.
"Pointless" was too strong. "Not secure" would have been better.
EDIT--
More specifically, most utils don't tell you that they don't touch slack space unless you search the forums. See, for example, CCleaner which lists a few limitations of CCleaner's free space wipe, but which makes no mention of slack space.
Thing is, that depends on the filesystem. I know that the usual shred commands don't work all that great on Ext4 due to journalling and such, but Microsoft actually provides[1] a first party tool to do it on NTFS (at the file level) to handle those edge cases.
Apple provides[2] a built-in free space nuking tool as well.
That leaves sector reallocation by the disk controller, but doesn't that only happen if data can't be properly written in the first place anyways?
> > A free-space wipe on an SSD can't guarantee that reserved or remapped blocks get erased.
>
> I think most controllers implement a secure erase feature that guarantees the data have been erased from NAND.
yes, ata secure erase, which guarantees erasure of the entire drive (excluding vendor specific areas)
(1) SSDs are good for privacy for average users since they are cleaning up dirty blocks in the background.
However, IMO, privacy-conscious users who are running a daily free-space wipe, a conventional hard disk is superior because it guarantees that all dirty blocks are erased. A free-space wipe on an SSD can't guarantee that reserved or remapped blocks get erased.
(2) He says, "Somewhat counter-intuitively, information deleted from certain types of encrypted volumes (some configurations of BitLocker, TrueCrypt, PGP and other containers) may be easier to recover ... if the investigator knows either the original password or binary decryption keys for the volume".
If you delete a file in your encrypted volume (but don't do a free-space wipe inside your encrypted volume), then someone who knows your key could potentially recover that file. But that's always been true -- it's true for both SSD and conventional drives.
What I think the author is saying is that someone who use an encrypted volume doesn't benefit from the SSD's cleaning of dirty blocks in the background because the entire encrypted volume looks like it's in use to the SSD controller.
But I don't see how he concludes that it's "easier". You lose the benefit of the SSD's garbage collection, but to recover a deleted file from inside an encrypted volume (assuming you have the user's key) is neither easier nor more difficult with an SSD vs. a conventional disk.