[dm-crypt] Cryptographic issues with SSD-technology and wide-block encryption modes

Arno Wagner arno at wagner.name
Wed Feb 6 11:32:39 CET 2013


On Wed, Feb 06, 2013 at 11:06:11AM +0100, Stavros Kousidis wrote:
> > An HTML attachment was scrubbed...
> > URL: <http://www.saout.de/pipermail/dm-crypt/attachments/20130206/89e2ec35/attachment.html
> > [http://www.saout.de/pipermail/dm-crypt/attachments/20130206/89e2ec35/attachment.html]>
> 
> Oops, forgot about the HTML web interface. Here's the plain text:
> -------------------------------------------------------------------------------

Ah, thanks. I was just about to complain. 
 
> Dear Arno, dear Milan,
> 
> I have seen that you are well aware of the SSD-technology drawbacks from a cryptographic viewpoint, e.g.
> 
> http://www.saout.de/pipermail/dm-crypt/2012-August/002665.html
> http://asalor.blogspot.de/2011/08/trim-dm-crypt-problems.html
> 
> One essential issue that concerns full disk encryption on SSDs, that I
> have not seen in a mail discussion here so far (might be there and I
> simply missed it), is the distribution of an uncontrollable amount of
> copies of SSD-page contents (~4096 Bytes) where only a limited number of
> blocks (~16 Bytes) have changed.  This is initiated by local changes in
> userspace data and technically due to the complex nature of the flash
> translation layer (mainly wear leveling techniques), the narrow-block
> encryption modes (here: XTS) and sector-wise constant IVs.  In
> Cipher-block chaining mode the position where a bit-flip happened is
> visible in principle.

I am aware of that issue. However, XTS mode should lead to a full sector
(512 Bytes) chage even if only one bit is changed. That is the whole
point of modes like XTS, EME, etc.

> A countermeasure to those history-building SSD-mechanisms is to blur what
> is written to the flash device by forcing a multi-sector-wide change when
> a bit changes (preferrably: multi-sector = size of file system blocks). 
> There are two concrete realizations of that strategy that I know of:

I think you just have to live with it at this time. It is not a severe
vulnerability in most situations. And it will not build up to badly, at
some time the blocks get re-used. The amounth of spares/write pool
in SSDs seems to be shrinking as well.

> 1) Use random IVs. Leaves you with data expansion, since you have to store
> the IVs, and a pain in the *** effort to implement this reliably.

It is. It also breaks the dm-model as additional accesses
are required. Not an option, I think.

> 2) Add a (claimed patent free) wide-block mode like TET or HEHfp (see
> articles below) from the Hash-Encrypt-Hash family to the Crypto-API and
> change the dmcrypt crypto engine to handle variable block sizes instead of
> always operating on 512 Bytes of data (compare the discussion:
> http://www.saout.de/pipermail/dm-crypt/2011-April/001667.html)

I will have a look at the articles, but I think this is not
really an option either, agen because of mismatch with the
dm-layer. 
 
> Another (great) advantage of those wide-block modes is their inherent
> 1/2*MAC functionality due to the intended collision avoidance in the
> encryption layer that is built in by the universal hash pre- and
> post-processing („1/2“ for: not a MAC but more than no MAC at all).

> Since you maintain the code I would like to know your opinion on this and
> if there is a chance to pursue such a project.

That would be Milan. I am just the volunteer that does the documentation.
Milan actually gets paid for real work on cryotsetup.

Arno

> 
> Best
> Stavros
> 
> P.S.: You can search the web for the above mentioned articles:
> 
> TET: Shai Halevi, „Invertible universal hashing and the TET encryption mode“
> HEHfp: Palash Sarkar, „Improving upon the TET mode of operation“
> 
> Those are instances of the hash-encrypt-hash family introduced by Naor and Reingold in „A pseudo-random encryption mode“. Halevi discusses the intellectual-property issues et the end of his article.
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno at wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
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 mailing list