> 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: http://static.usenix.org/events/fast11/tech/full_papers/Wei.pdf > > 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? Stavros _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
