Hi Alban, On Sat, Apr 14, 2012 at 02:23:23AM +0100, alban bernard wrote: > Hi, > > I carefully read that page > http://asalor.blogspot.fr/2011/08/trim-dm-crypt-problems.html to > understand the basics behind the main security problem involved by trim > commands. Simple ideas came to my mind, but I need to submit them to know > how they fail (or by any chance how they may succeed). > > From what I understand, TRIM commands are used to say to the SSD > controller: "these sectors are discarded, so you can erase them at any > time chosen by you rather than waiting an explicit rewrite from me". So, > from a crytographic point of view, using TRIM commands is like replacing > deleted files by "zero" files in a totally uncontrolled manner. This > breaks the main purpose of cryptography: hiding as much things as > possible. Well, it does not quite "break" it. The correct terminology is that you have an information leak where filesystem-discarded blocks (by TRIM) can be identified by an attacker with low effort Well, low "cryptoanalytic effort", actually. For a "break", you would actually have to have real information end up on the raw block device, but in most situations, the information content of the TRIM information will be small. There are scenarios though: Assume you have never TRIMed and a large file gets deleted. Then an attacker can determine the size of that file, but rounded up to the block size. For a file in the 1GB range that would man (asuming 512B sectors, even though filesystem block are typically larger), that the total file sizte is 30 bit, of which the first 21 are leaking. While that is information, it is pretty fuzzy and requires pretty special conditions to be visible in the first place. A second scenario would arise if some malicious software that can write only the encrypted device wishes to signal to the outside. Then a "0" could be a low number of TRIMed blocks and a "1" copuld be a high number. Both can be achieved by wrinting alot of data or deleting a lot of data. Repeated action and observer access to only the encrypted data to transfer more bits. While this may be a concern, it is a pretty bizzare scenario. And the same can be achieved by changing sector contents, as the observer-part of the attacker _can_ detect changes in the on-disk data. The Design "error" is of course that the raw device is told about some things that should only be visible after decryption. > After TRIM commands, the SSD controller erases blocks whenever he wants > after receiving the command. Thus, it seems to not inform us back where > those blocks are remapped in its LBA translation table (not sure about > that). It does not, but forensic analysis may be able to extract some sort of log or trace from the device. > > So, what about running TRIM commands only in certain cases: on-demand / by > sectors / ... ? The overall purpose being: > - to limit the TRIMed space on device > - to control the TRIMed pattern (spread it randomly as much as possible) The information leakage is very small. If it is a concern, then TRIM must never be used. If not, TRIM can be used in unlimited fashion. It is a standard security trade-off. Your options can in some circumstances decrease the information lekage, but they will not so so reliably (comments below), and hence do not reduce the worst-case. But the risk-analysis that form the basis of the decision to allow TRIM or not has to use the worst-case as there is no basis for forming an average-case and an attacker may be able to provoke the worst-case scenario. > Here the naive things: > - send on-demand TRIM commands based on device write access rate and > remaining free space Can leak information just as well, will be fuzzier in only some cases. > - keep a table of TRIMed blocks or just their total size (send TRIM > commands only below a certain size limit threshold) See above. > - send TRIM commands on randomly chosen deleted blocks only (not all > deleted blocks) Selecting them randomly would here mean "selecting them in a cryptographically secure random way". This violates KISS as it would be pretty complex and suddently you have information to protect by hard crypto in the filesystem layer that is not designed for this. If the goal of an attacker is to recognize some specific action the attacker designed before (e.g. malware accessing the device in a pattern), this may still be visible. > - write garbage to fill some TRIMed "blanks" (less than a threshold > critical to ssd performance) "garbage" would again need to be "cryptographic garbage". I am not even sure this is possible. And you still can deduce that blocks are actually deleted, as they show up as deleted in the SSD's internal tables, so the effect is only higher attacker effort, but the leackage stays exactly the same. > - randomize device usage pattern when choosing blocks to TRIM (hide > filesystem) I don't quite understand how that could work, do you mean to have a random mapping between encrypted and hysical secors? That would kill performance a lot worse than not using TRIM in the first place. > Let me know if it could lead to real life solution. Any criticism > appreciated. Well, I think you do understand the problem, but not quite its implications. It really is a case of "secure, fast, cheap, pick any two". If security is your primary concern, then do not use TRIM. The SSD can still to garbage collection (well, garbage compaction really) but only with the spare capacity it reserves for that. Leads to a bit of performance decrease, depending on the SSD. My advice would be to decide how important the postential data leakage is (depending on the application) and then do with or without TRIM entirely. The default should be no TRIM though as it is really a decision by the user to make the system less secure for a performance gain. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
