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

Stavros Kousidis dabros.kuhsadas at web.de
Wed Feb 6 14:34:42 CET 2013

> The main problem (I see) with these analysis is that it usually
> take just part of the system (either SSD architecture or block encryption).
> But it is more complex system with several layer interfering, this
> interference can make the problem with ciphertext block copies worse
> but also decrease impact.
> An example (illustrative but I hope not completely wrong:)
> Imagine you have write pattern changing several consecutive 512 bytes
> sectors with some delay between writes.
> In theory, that's exactly case you are describing,
> you will get several copies inside SSD (on flash chips)
> because of wear leveling and similar techniques (do not forget
> internal garbage collection as well).
> In reality, it depends
> - Filesystem above uses large blocks as well (most common is page size 4k I think).
> The filesystem (and page cache) will send IO request only of this block (page)
> size, not 512 bytes sector. Depending on timing, you will see either
> several IOs or only just one (write-cache effect).
> - The transparent dmcrypt is using 512 bytes for encryption but it always
> encrypts the whole submitted IO before resending. (Let's ignore
> corner case with IO split because of lack or memory or storage restriction for now.)
> (Note dmcrypt has no own IO scheduler but it has internal queues for
> requests - so there is some delay in processing.)
> - The encrypted IO request is submitted to underlying device, where
> IO scheduler is responsible for real submission to device.
> And here it can be (and will be with exception of noop scheduler)
> merged into one big IO.
> - internal SSD architecture, and storage in general, have write-cache
> internally and will optimize writes as well.
> - storage (specifically SSD) uses hints for IO size, and every user
> in kernel should (or must) produce IOs restricted by these hints
> So, in this example you changed e.g. whole 4k page in several writes,
> but you cold see just one final IO! All it depends how the stack is
> configured and how filesystem is using Flush/FUA requests to sync
> IO in-flight.
> There is always some corner cases but I am trying to say that I am not
> sure if this problem is really so important in usual use cases.
> (As someone already mentioned, there are other attack vectors where the risk
> is probably higher.)
> But that said, yes I'm very well aware of this problem and I would
> like to have at least some analysis what's really going on in todays
> flash storage devices and how it is related to disk encryption security.
> So let's try to gather some data first.

That clarifies some things to me, and yes, I would also like to know what's happening inside those things. Especially since I have seen:

> > 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 random IVs. Leaves you with data expansion, since you have to
> > store the IVs, and a pain in the *** effort to implement this
> > reliably.
> Anything what need more space is problem (that includes data integrity,
> auth tags, whatever). And IMHO (pseudo-)random IV will cause more
> problems than it solves.

That's true. I just included it to mention a no-go.

> > 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)
> Yes, the work on deploying new cipher or encryption mode (either narrow or wide)
> for Linux block encryption starts in Linux kernel API.
> Send a patch to crypto kernel API list, get it in official kernel
> and dmcrypt/cryptsetup can start to use it.
> (But if there is any patent problem, no chance...)
> But do not forget one thing - while cryptsetup is always open to support
> wide range of algorithms, a huge user base is bound by standards which do not
> allow them to use anything else. That's why XTS is so widely used.

Ok that sounds reasonable (doable???). What exactly do you mean by a huge user base being bound by standards and to XTS?


More information about the dm-crypt mailing list