[dm-crypt] simple ideas addressing ssd TRIM security concern
arno at wagner.name
Sun Apr 15 03:26:45 CEST 2012
On Sat, Apr 14, 2012 at 11:22:15PM +0100, alban bernard wrote:
> --- On Sat, 4/14/12, Arno Wagner <arno at wagner.name> wrote:
> > The Design "error" is of course that the raw device is told
> > about
> > some things that should only be visible after decryption.
> In a way, TRIMing leads to the same situation as not writing garbage
> before device encryption.
> > 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.
> In case the user chooses the performance trade-off, an option to maximize
> security is still interesting to him. I agree with you, a layer that
> cryptographically randomize TRIMed blocks while limiting information
> leakage is not a key point to decide to allow TRIM or not (the worst case
> is still possible), but it is still important to have the option from the
> user perspective.
I do not agree. Most users will not understand what they are doing
and an option that increses performance while seemingly still having
high-security (as there is this "additional measure") will just
mislead them. And there is no way to "maximize security" when TRIM
is active. The way to maximize security is to not use TRIM.
> > > - 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.
> I meant to randomly distribute TRIMed blocks across the device by choosing
> to not TRIM contiguous blocks of some files. E.g. when a big file is
> deleted, allow TRIM only on a randomly chosen set of its blocks limited to
> about 1 percent of its size. The 99 percent of it would stay unTRIMed on
> the device.
That would have very little benefit, while still having the same
worst-case information leakage.
> So, these ideas could only limit the information leakage that could be
> used by an attacker.
No. They would not limit anything. They would decrease the probability of
accidental leaks of a higher amount of data, but the worst-case stays
> To complete my understanding, if the device is
> completely used (no more free space), an attacker could not benefit of any
> leakage from TRIMed space. So, there is a relation between information
> leakage rate and amount of TRIMed space. A question rises to me: does an
> amount of TRIMed space exist to keep performance and still harden
> crypto-analysis in a controllable manner?
No. You can only decrease probabilities, but not amount leaked in the
worst case. Crypto is very hard. Using worst-case scenarios is
necessary to be sure of an analysis.
To put it in another way, if performance is important enough to
you to compromise security, then there is a high probability that
you will break security. It happens all the time by developers that
do not know what they are doing.
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