[dm-crypt] simple ideas addressing ssd TRIM security concern
arno at wagner.name
Sat Apr 14 06:15:11 CEST 2012
On Sat, Apr 14, 2012 at 02:23:23AM +0100, alban bernard wrote:
> 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
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
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
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)
> - 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
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
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 Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno at wagner.name
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
More information about the dm-crypt