[dm-crypt] SSD disks and cryptsetup-reencrypt
corsac at debian.org
Thu Jun 13 07:51:41 CEST 2013
On jeu., 2013-06-13 at 01:43 +0200, Matthias Schniedermeyer wrote:
> On 13.06.2013 00:30, Arno Wagner wrote:
> > That said, unless you have high-resource attackers to defend
> > against, with something like, say, 8 complete-disk re-encryptions
> > you should be relatively secure. But don't blame me if it turns
> > out you are not.
> Or use one of the newer SSDs that take "the easy way" for secure
> At last one or more of the current generation controller chips encrypt
> the contents by default (even without enabling FDE), as the controller
> has to do some form of scrambling anyway as high-entrophy is better for
> the flash cells(*). So at least one does AES256 encryption always. When
> you secure erase such a SSD they typically just generate a new key and
> not actually erase the flash-cells.
Actually they still need to erase the cells, at least as part of the
garbage collection, since at one point they will be reused. And when you
do a secure erase, the few seconds needed to erase all the cells doesn't
really matter, I guess.
That said, nobody knows exactly what the firmware do.
> The unknown is if they "drop" the
> old key in a secure way, but if they do there is no way to decrypt older
> content even if you desolder the flash-chips.
> Also you have to have to hope that key generation is really random. That
> is something that can't really be proven (only disproven), so personally
> that is not something i could rely on.
And one needs to know how it is linked to the ATA password, too.
> So i classify it as a "nice to
> have", if it works it is a line of defense otherwise it is "nothing".
Yeah, right now I don't think I'd trust a self-encrypting SSD and would
put luks on top of it anyway. Note that you lose some performances here
since those SEDs work way better on compressible data.
> Problem is i can't remember which one(s) do(es) that, and it's bed time.
SandForce (now LSI) controllers. Which can be found in OCZ and some
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 490 bytes
Desc: This is a digitally signed message part
More information about the dm-crypt