[dm-crypt] Cryptsetup and SSD
arno at wagner.name
Sat Aug 11 04:01:23 CEST 2012
On Fri, Aug 10, 2012 at 05:49:49PM +0200, antispam06 at sent.at wrote:
> How reliable can be the full disk encryption on a SSD, given the
> methods emplyed by the drive to prolounge the drive's life?
Reliabilility is not an issue. An issue is how reliable you can wipe
an encrypted partition. With dm-cryot: Same as ordinray data, i.e.
if you overwrite it it is gone, if it goes into the free-pool, it
is still there. Hence on an SSD, protecting the key is your only
With LUKS: Here the question becomes if the anti-forensic stripes
are depeted in key-change or on header-wipe. Basically, if just
one 512B sector for each used keyslot is zeroed, you should be
pretty secure. Keyslot size for default parameters is just
128k for XTS mode 256k. That may mean they end up completely
in an SSD block. And that in turn may mean they do not get
wiped at all, although SSD-blocks put into the "free" pool
should be zeroed very soon, otherwise there is no point to that
pool. SSD blocks can also go into the "defect" pool, but that
should be rather rare.
That said, if you want to be more secure, a ATA "secure erase
unit" command should erase everything, including free and defect
blocks, but YMMV as vendors may not implement that command
Larger key-slots would also help, but cryptsetup does not
support setting them on luksFormat (yet) and you would have to
set them to large enough to be sure they do not end up in
the "free" or "defect" pool. For example, for a 240GB SSD,
you would need to use key-slots > 16GB in size. That may
be beyond what the libraries for cryptsetup can handle.
Just out os curiosity, I made a version of cryptsetup with
LUKS_STRIPES set to 400000 (i.e. 12MB keyslot size) and that
seems to work, including failure to open when I change a bit
towards the end. But I have no idea what the upper limit
on LUKS_STRIPES is.
Here is what I would recommend: If you can protect the password,
use plain dm-crypt, or LUKS without management features (i.e.
do not change the password). If you cannot protect the password,
do not use an SSD. Or use LUKS with the header detached and
stored in a raw partition on a conventional HDD (via the
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno at wagner.name
GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
One of the painful things about our time is that those who feel certainty
are stupid, and those with any imagination and understanding are filled
with doubt and indecision. -- Bertrand Russell
More information about the dm-crypt