Cryptographic issues with SSD-technology and wide-block encryption modes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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:

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

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).

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.

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@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt

[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux