[dm-crypt] 'discard' as default

[dm-crypt] 'discard' as default

[Jonas Meurer]

[-- Attachment #1.1: Type: text/plain, Size: 2370 bytes --]

Hi list,

Starting with the upcoming release of Debian Buster, luks devices
created during installation will have the 'discard' option (trim feature
for flash devices) set in crypttab[1].

When Guilhem and me (we're the Debian cryptsetup maintainers) discussed
this topic, we agreed, that in general, having the discard option set
per default would be a nice thing to have. But we're unsure how to
implement it.

One option would be to simply add 'discard' to all crypttab examples and
document in README.Debian that we recommend to always add 'discard' as
crypttab option for new dm-crypt devices.

Buth then, *always* listing an option is somehow weird from a technical
perspective. If we want it to be the defualt, then it should be the
default without explicitely having to set it.

So we wonder whether you (cryptsetup upstream would consider to make
discard the default in cryptsetup, at least for LUKS devices.

[Certainly, enabling 'discard' for the LUKS device, isn't sufficient for
turning on trim support for the device. It might have to be enabled in
other block stack layers and filesystem still. But that's another topic
to be dealt with in downstream distributions like Debian.]

As far as we know, the main *negative* impact of enabling the trim
feature on flash devices is, that it might reveal information on which
parts of the disk are written and which are not, even if you first
filled the disk with random data[2]. To our knowledge, that's only a
problem if you need plausible deniability, wich LUKS doesn't provide anyway.

Our perspective is, that if you need plausible deniability, you have to
look into details anyway (it's hard to do plausible deniability right),
and people can still disable discard in those cases.

So what do you think about making 'discard' the default in cryptsetup
for LUKS? Would you consider doing so? If not, would you be fine with
cryptsetup in Debian defaulting to 'discard' nevertheless? Could you
imagine to add a compile-time flag for doing so? In any case, an option
to *disable* the default would be needed.

We're curious what you think about it :)

Kind regards,
 jonas, on behalf of the Debian cryptsetup team

[1] https://salsa.debian.org/installer-team/partman-crypto/merge_requests/2
[2] https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [dm-crypt] 'discard' as default

[Christoph Anton Mitterer]

On Sat, 2018-12-29 at 12:05 +0100, Jonas Meurer wrote:
> having the discard option set
> per default would be a nice thing to have.

It's not done per default for security reasons... and a system (dm-
crypt) whose primary purpose is security, should probably not default
to weaker security, thus imposing that on most (unknowing) users
without any further notice.

If someone really needs/wants the high performance he either doesn't
need/want security,... or sooner or later find it's way to dm-crypt's
options to pass through TRIM.

Would be sad if Debian, for no reason, deviates from the sane upstream
defaults.


Cheers,
Chris.

Re: [dm-crypt] 'discard' as default

[Christoph Anton Mitterer]

btw:

On Sat, 2018-12-29 at 12:05 +0100, Jonas Meurer wrote:
> So we wonder whether you (cryptsetup upstream would consider to make
> discard the default in cryptsetup, at least for LUKS devices.
I shall hope upstream doesn't decide so :-)


> As far as we know, the main *negative* impact of enabling the trim
> feature on flash devices is, that it might reveal information on
> which
> parts of the disk are written and which are not, even if you first
> filled the disk with random data[2].
I'd expect it to be also a problem for non-SSDs,... just imagine a
rogue chipset (on the bus, HDD, etc.) which intercepts the TRIMs with
their potentially valuable information.

>  To our knowledge, that's only a
> problem if you need plausible deniability, wich LUKS doesn't provide
> anyway.
AFAIK, this hasn't to do anything with plausible deniability (at least
not in the classic sense of "hidden encryption"), but rather that an
attacker might gain valuable information that can be used for further
attacks... and as always it's likely just our imagination which limits
these.

One could think of deletion patterns that (depending on their size)
give hint what is being deleted (what you might have meant by plausible
deniability?)... or perhaps it could eventually somehow help in
statistical attacks (maybe a regularly deleted file with more or less
known content)?


OTOH,... I'm not an expert cryptoanalyst... so others may have much
more knowledge about all this :)

Cheers!

Re: [dm-crypt] 'discard' as default

[Michael Kjörling]

On 2 Jan 2019 21:41 +0100, from calestyo@scientia.net (Christoph Anton Mitterer):
>> To our knowledge, that's only a problem if you need plausible
>> deniability, wich LUKS doesn't provide anyway.
> 
> AFAIK, this hasn't to do anything with plausible deniability (at least
> not in the classic sense of "hidden encryption"), but rather that an
> attacker might gain valuable information that can be used for further
> attacks... and as always it's likely just our imagination which limits
> these.
> 
> One could think of deletion patterns that (depending on their size)
> give hint what is being deleted (what you might have meant by plausible
> deniability?)... or perhaps it could eventually somehow help in
> statistical attacks (maybe a regularly deleted file with more or less
> known content)?

Pattern analysis (which is made far easier by TRIM pass-through) can
certainly tell an attacker which file system is likely in use on the
device, and give them an idea of how much data is likely there. I
don't remember where I saw it, but I did see a write-up by someone who
had created various major Linux file systems on otherwise blank
devices. The differences in data layout were _clearly_ visible.

With payload data added, the differences might be less obvious, but
they are still going to be there. A partition with a XFS file system
is going to look different from one with ext4, or ZFS, or something
else, even if the attacker can't tell _what's_ stored there.

The point of filling the partition with random data is to make this
kind of attack much harder to pull off.

Sure; which file system is in use might be basically public knowledge
anyway, and it _shouldn't_ give an attacker an advantage. But it's
information that the attacker doesn't _necessarily_ need to have, and
certainly information they don't need be fed on a silver platter (or
chip, as the case may be).

Good cryptography design aims to give an attacker as little
information as possible about the underlying plaintext. Deviating from
that goal as a default should require an _awfully_ good reason.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)

Re: [dm-crypt] 'discard' as default

[Arno Wagner]

Well, I can understand that the maintainers want to give their
users the best experience and for security software that is 
always difficult to determine.

However, defaults _must_ be secure or you can simply do without
encryption in the first place. Encryption always decreases 
usability, there is no way around that. Those that prefer 
usability (speed, simplicity, etc.) will simply do without 
encryption and hope nobody attacks them.

Hence here is my recommendation: No TRIM in the defaults. 
Putting that in there would be really bad mindset-wise.

You can certainly add a statement prominently in the
documentation on how to add TRIM and that it will decrease
security. You can also add commented-out alternate configuration
lines with TRIM and a warning comment.

While you are it, you may also add a reference to FAQ 
Item 5.19 which discusses the security problems putting 
LUKS on an SSD or other solid-state drive.

Regards,
Arno




On Wed, Jan 02, 2019 at 21:57:41 CET, Michael Kjörling wrote:
> On 2 Jan 2019 21:41 +0100, from calestyo@scientia.net (Christoph Anton Mitterer):
> >> To our knowledge, that's only a problem if you need plausible
> >> deniability, wich LUKS doesn't provide anyway.
> > 
> > AFAIK, this hasn't to do anything with plausible deniability (at least
> > not in the classic sense of "hidden encryption"), but rather that an
> > attacker might gain valuable information that can be used for further
> > attacks... and as always it's likely just our imagination which limits
> > these.
> > 
> > One could think of deletion patterns that (depending on their size)
> > give hint what is being deleted (what you might have meant by plausible
> > deniability?)... or perhaps it could eventually somehow help in
> > statistical attacks (maybe a regularly deleted file with more or less
> > known content)?
> 
> Pattern analysis (which is made far easier by TRIM pass-through) can
> certainly tell an attacker which file system is likely in use on the
> device, and give them an idea of how much data is likely there. I
> don't remember where I saw it, but I did see a write-up by someone who
> had created various major Linux file systems on otherwise blank
> devices. The differences in data layout were _clearly_ visible.
> 
> With payload data added, the differences might be less obvious, but
> they are still going to be there. A partition with a XFS file system
> is going to look different from one with ext4, or ZFS, or something
> else, even if the attacker can't tell _what's_ stored there.
> 
> The point of filling the partition with random data is to make this
> kind of attack much harder to pull off.
> 
> Sure; which file system is in use might be basically public knowledge
> anyway, and it _shouldn't_ give an attacker an advantage. But it's
> information that the attacker doesn't _necessarily_ need to have, and
> certainly information they don't need be fed on a silver platter (or
> chip, as the case may be).
> 
> Good cryptography design aims to give an attacker as little
> information as possible about the underlying plaintext. Deviating from
> that goal as a default should require an _awfully_ good reason.
> 
> -- 
> Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
>   “The most dangerous thought that you can have as a creative person
>               is to think you know what you’re doing.” (Bret Victor)
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] 'discard' as default

[Milan Broz]

On 29/12/2018 12:05, Jonas Meurer wrote:
> Starting with the upcoming release of Debian Buster, luks devices
> created during installation will have the 'discard' option (trim feature
> for flash devices) set in crypttab[1].
> 
> When Guilhem and me (we're the Debian cryptsetup maintainers) discussed
> this topic, we agreed, that in general, having the discard option set
> per default would be a nice thing to have. But we're unsure how to
> implement it.

Hi,

we are already in this battle for several years, so there is the "upstream"
approach.

Just to understand my a little bit defensive approach, please read
  https://www.redhat.com/archives/dm-devel/2016-September/msg00061.html
  https://www.redhat.com/archives/dm-devel/2016-September/msg00065.html
  (and rest of threads)
(being in a group of crazy-anal security people, as it was named,
is actually an honor for me :-p)

So this is "the state of affairs":

- there will be no TRIM-enabled default inside kernel dm-crypt, definitely
  not for the current major dm-crypt module version (1.x.x)
  (reasons in the link above; but as you know, in Linux kernel anything can happen,
  so, for now, it is based on our discussion with DM maintainer)

- LUKS1 will never have TRIM as the default setting in cryptsetup.
  Some people build hidden disks with LUKS1 as a decoy system.
  Not even a compile switch, sorry.

- There is generic support for "discard" flag in crypttab (maintained
  by systemd/sysv), distros are free to use by default on installation.

  IOW this flags will activate LUKS1/2 device TRIM enabled.
  (We use this approach in Fedora already for some time.)

- LUKS2 has already persistent config flag to set TRIM as default per-device,
  with cryptsetup 2.1 we can change persistent setting even for already
  active device (code is in git already).
  (See --persistent option for luksOpen.)

- TRIM is not supported for integrity devices (LUKS2 with authenticated
  encryption), but this is still an experimental feature.

So in short for Debian - I think you should use the same way as for Fedora,
just add discard flag to crypttab during installation.

I would like to set LUKS2 format as default in 2.1 release, but it will
could still cause some problems :-)
But for TRIM support, it should help to solve the situation for the future.

And maybe LUKS2 format (but not for LUKS1) should set TRIM flag by default,
really would like to see opinions here.

m.

p.s.
Sorry, I could not resist, just a small rant...

For the last few years, it seems the "storage performance" is the keyword
that everyone is using (even in academic papers now).
TRIM is just a small part of it.
It seems that security is often being deteriorated in time.

See for example the case of BitLocker enabled SED devices by default
(also watch recent 35c3 talk "Self-encrypting deception").
Some people tried a similar approach in dm-crypt, and I am happy we resisted
https://lkml.org/lkml/2018/5/28/1910 
but without the support of people that care about security, for how long?

Thanks to everyone who is helping here, even it is just an opinion in a mail
discussion! We will need your help, in the 2019 year more than ever. 

Milan

> One option would be to simply add 'discard' to all crypttab examples and
> document in README.Debian that we recommend to always add 'discard' as
> crypttab option for new dm-crypt devices.
> 
> Buth then, *always* listing an option is somehow weird from a technical
> perspective. If we want it to be the defualt, then it should be the
> default without explicitely having to set it.
> 
> So we wonder whether you (cryptsetup upstream would consider to make
> discard the default in cryptsetup, at least for LUKS devices.
> 
> [Certainly, enabling 'discard' for the LUKS device, isn't sufficient for
> turning on trim support for the device. It might have to be enabled in
> other block stack layers and filesystem still. But that's another topic
> to be dealt with in downstream distributions like Debian.]
> 
> As far as we know, the main *negative* impact of enabling the trim
> feature on flash devices is, that it might reveal information on which
> parts of the disk are written and which are not, even if you first
> filled the disk with random data[2]. To our knowledge, that's only a
> problem if you need plausible deniability, wich LUKS doesn't provide anyway.
> 
> Our perspective is, that if you need plausible deniability, you have to
> look into details anyway (it's hard to do plausible deniability right),
> and people can still disable discard in those cases.
> 
> So what do you think about making 'discard' the default in cryptsetup
> for LUKS? Would you consider doing so? If not, would you be fine with
> cryptsetup in Debian defaulting to 'discard' nevertheless? Could you
> imagine to add a compile-time flag for doing so? In any case, an option
> to *disable* the default would be needed.
> 
> We're curious what you think about it :)
> 
> Kind regards,
>  jonas, on behalf of the Debian cryptsetup team
> 
> [1] https://salsa.debian.org/installer-team/partman-crypto/merge_requests/2
> [2] https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html
> 
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt
> 

Re: [dm-crypt] 'discard' as default

[Christoph Anton Mitterer]

On Thu, 2019-01-03 at 09:10 +0100, Milan Broz wrote:
> And maybe LUKS2 format (but not for LUKS1) should set TRIM flag by
> default,
> really would like to see opinions here.

As mentioned already by Arno... it's a question of mindset:

Anyone who's making reasonable use (i.e. really wants it and knows what
he wants) of dm-crypt/cryptsetup wants security as primary goal.

And this is also the main purpose of dm-crypt/cryptsetup.

So IMO, unless there are extremely strong reasons (like: system
otherwise completely unusable for everyone), one shouldn't lower the
standards per default (but rather give "good" documentation so that
users decide, still with the warning that not all implications might be
understood).

Today it might seem difficult for an attacker to draw much information
out of deletion patters.
But we've had the same in countless other security disasters, where one
was only afterwards smarter.



If someone wants the extra performance (anyway on SSDs only) and values
that higher than security, he can still enable it manually or just go
without encryption.
But why should those, who want to use dm-crypt/cryptsetup as intended
suffer (per default) for those who anyway rather misuse it?




Cheers,
Chris.

Re: [dm-crypt] 'discard' as default

[Milan Broz]

On 03/01/2019 17:26, Christoph Anton Mitterer wrote:
> On Thu, 2019-01-03 at 09:10 +0100, Milan Broz wrote:
>> And maybe LUKS2 format (but not for LUKS1) should set TRIM flag by
>> default,
>> really would like to see opinions here.
> 
> As mentioned already by Arno... it's a question of mindset:
> 
> Anyone who's making reasonable use (i.e. really wants it and knows what
> he wants) of dm-crypt/cryptsetup wants security as primary goal.

Unfortunately this is not what I see from many "enterprise" customers.
Sometimes it seems that they just need to click the "encrypted" checkbox
to get signed paper with some nice certification...

But really, there are many situations where discard/TRIM really improves
performance and even allows to deploy some solutions with still
good threat model.

Imagine for example thin provisioned on-demand systems that use
FDE - discard here is the operation that signals deallocating  of used blocks.
Without it you cannot implement dynamically allocated storage on block level.
FDE can be used to improve guests isolation etc.

We can (and want) to support both sides, just default should be on the secure side.

Milan

Re: [dm-crypt] 'discard' as default

[Michael Kjörling]

On 3 Jan 2019 18:36 +0100, from gmazyland@gmail.com (Milan Broz):
> We can (and want) to support both sides, just default should be on
> the secure side.

I agree, there definitely are situations in which TRIM pass-through
coupled with FDE makes sense. (There are also situations in which
other security-reducing choices can make sense in conjunction with
FDE. That depends on the threat model.) But _reducing_ the security
should be a conscious, informed decision.

Give me secure defaults, and let me decide if I want to reduce
security in favor of other goals, including performance.

For an interactive installation (since the original question was in
the context of an OS installation), you can just ask the person
installing the system, while indicating that there may be security
disadvantages to allowing TRIM. Not really much different from how I
believe the Debian installer currently asks whether to overwrite a
LUKS backing device with random data (which has the downside of taking
a potentially significant amount of time during the installation).

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)

Re: [dm-crypt] 'discard' as default

[Christoph Anton Mitterer]

On Thu, 2019-01-03 at 18:36 +0100, Milan Broz wrote:
> Unfortunately this is not what I see from many "enterprise"
> customers.
> Sometimes it seems that they just need to click the "encrypted"
> checkbox
> to get signed paper with some nice certification...

Sure.. it's like with all the TOFU encryption we see nowadays...

But as you say these people/organisations just want some label on it,
they don't give a s*** about security.
And this is even the optimistic assumption... one must very well assume
that such people might have a malevolent agenda and just want to give
people a wrong sense of security (see the encrypt-everything-on-the-
web-thingy)


> But really, there are many situations where discard/TRIM really
> improves
> performance and even allows to deploy some solutions with still
> good threat model.

Sure,... but these people will likely stumble over it and can always
change a secure default if it fits their needs and threat model.

It's like with e.g. SSH, there may be use cases in which it's fine to
use one of the older less safe algos (e.g. SSHing to some old
iDRAC/etc. serial console interfaces, which are anyway in a fully
isolated management network)... but just because of that one should
make them default.


> We can (and want) to support both sides, just default should be on
> the secure side.

Absolutely. :-) Which is why my opinion would be to keep discarding
TRIMs even in the future and with LUKS2 per default.



Cheers,
Chris.

Re: [dm-crypt] 'discard' as default

[Arno Wagner]

On Thu, Jan 03, 2019 at 18:59:09 CET, Christoph Anton Mitterer wrote:
> On Thu, 2019-01-03 at 18:36 +0100, Milan Broz wrote:
> > We can (and want) to support both sides, just default should be on
> > the secure side.
> 
> Absolutely. :-) Which is why my opinion would be to keep discarding
> TRIMs even in the future and with LUKS2 per default.

I fully agree to that. Security requirements may vary (and I know
"those" enterprise customers very well...), but secure-by-default
is the right way to go. Lowering security is easy, basically 
anybody can do it. Increasing it is hard for most people and that
is why it needs to be already there and why lowering it needs to
be an active configuration decision. 

Regards,
Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] 'discard' as default

[Jonas Meurer]

[-- Attachment #1.1: Type: text/plain, Size: 7823 bytes --]

Hi Milan, hi list,

first, sorry for starting this thread and then not responding for such a
long time. I simply didn't find the time as I'm to busy with other
projects at the mmoment.

Milan Broz:
> On 29/12/2018 12:05, Jonas Meurer wrote:
>> Starting with the upcoming release of Debian Buster, luks devices
>> created during installation will have the 'discard' option (trim feature
>> for flash devices) set in crypttab[1].
>>
>> When Guilhem and me (we're the Debian cryptsetup maintainers) discussed
>> this topic, we agreed, that in general, having the discard option set
>> per default would be a nice thing to have. But we're unsure how to
>> implement it.
> 
> we are already in this battle for several years, so there is the "upstream"
> approach.
> 
> Just to understand my a little bit defensive approach, please read
>   https://www.redhat.com/archives/dm-devel/2016-September/msg00061.html
>   https://www.redhat.com/archives/dm-devel/2016-September/msg00065.html
>   (and rest of threads)

Interesting read (Linus' rants left aside). Thanks for the links.

> So this is "the state of affairs":
> 
> - there will be no TRIM-enabled default inside kernel dm-crypt, definitely
>   not for the current major dm-crypt module version (1.x.x)
>   (reasons in the link above; but as you know, in Linux kernel anything can happen,
>   so, for now, it is based on our discussion with DM maintainer)

Seems totally reasonable to me, given that it would put truecrypt hidden
containers at risk.

> - LUKS1 will never have TRIM as the default setting in cryptsetup.
>   Some people build hidden disks with LUKS1 as a decoy system.
>   Not even a compile switch, sorry.

I see. And since there's no sticky options in LUKS1, there's no way to
enable discard only for *new* LUKS volumes. So I can follow your
reasoning why you don't want to enable discard for LUKS1 per default.

> - There is generic support for "discard" flag in crypttab (maintained
>   by systemd/sysv), distros are free to use by default on installation.
> 
>   IOW this flags will activate LUKS1/2 device TRIM enabled.
>   (We use this approach in Fedora already for some time.)

Yep, that's what Debian Installer will do starting with the release of
Buster as well.

> - LUKS2 has already persistent config flag to set TRIM as default per-device,
>   with cryptsetup 2.1 we can change persistent setting even for already
>   active device (code is in git already).
>   (See --persistent option for luksOpen.)

That's great news!

> - TRIM is not supported for integrity devices (LUKS2 with authenticated
>   encryption), but this is still an experimental feature.
> 
> So in short for Debian - I think you should use the same way as for Fedora,
> just add discard flag to crypttab during installation.

Yep, we do. See the linked merge request to partman-crypto from my
initial mail. But that way, we have a somewhat inconsistent situation:
wihle the installer defaults to add 'discard' to new LUKS devices,
that's not the case for user-generated LUKS devices. That's why I
brought up the topic here in the first place.

I think, we should just adjust the docs of the Debian cryptsetup package
and explain to users that they should always give the 'discard' option
to new devices if they don't have a good reason to not do so (i.e. have
hidden volumes inside the volume, have to hide whether there's data
written to the volume or want to protect against access patterns being
leaked).

> I would like to set LUKS2 format as default in 2.1 release, but it will
> could still cause some problems :-)
> But for TRIM support, it should help to solve the situation for the future.
> 
> And maybe LUKS2 format (but not for LUKS1) should set TRIM flag by default,
> really would like to see opinions here.

I would be much in favour of you doing this.

I see that the discard option has security implications. Absolutely.
Whether those are minor or major is debatable. My take on this is, that
the tradeoff is acceptable and for the vast majority of users
neglectable. On the other side, having fstrim working per default even
on encrypted volumes is a huge advantage.

In general, I don't believe that choosing the most secure option without
taking other aspects into account is always just right. Sometimes,
accepting a small tradeoff towards usability can help a lot. It lowers
the barrier to use cryptographical software. And users who care about
more sophisticated attack vectors and want to put security first, are
still free to change their settings.

Cheers
 jonas


> p.s.
> Sorry, I could not resist, just a small rant...
> 
> For the last few years, it seems the "storage performance" is the keyword
> that everyone is using (even in academic papers now).
> TRIM is just a small part of it.
> It seems that security is often being deteriorated in time.
> 
> See for example the case of BitLocker enabled SED devices by default
> (also watch recent 35c3 talk "Self-encrypting deception").
> Some people tried a similar approach in dm-crypt, and I am happy we resisted
> https://lkml.org/lkml/2018/5/28/1910 
> but without the support of people that care about security, for how long?
> 
> Thanks to everyone who is helping here, even it is just an opinion in a mail
> discussion! We will need your help, in the 2019 year more than ever. 
> 
> Milan
> 
>> One option would be to simply add 'discard' to all crypttab examples and
>> document in README.Debian that we recommend to always add 'discard' as
>> crypttab option for new dm-crypt devices.
>>
>> Buth then, *always* listing an option is somehow weird from a technical
>> perspective. If we want it to be the defualt, then it should be the
>> default without explicitely having to set it.
>>
>> So we wonder whether you (cryptsetup upstream would consider to make
>> discard the default in cryptsetup, at least for LUKS devices.
>>
>> [Certainly, enabling 'discard' for the LUKS device, isn't sufficient for
>> turning on trim support for the device. It might have to be enabled in
>> other block stack layers and filesystem still. But that's another topic
>> to be dealt with in downstream distributions like Debian.]
>>
>> As far as we know, the main *negative* impact of enabling the trim
>> feature on flash devices is, that it might reveal information on which
>> parts of the disk are written and which are not, even if you first
>> filled the disk with random data[2]. To our knowledge, that's only a
>> problem if you need plausible deniability, wich LUKS doesn't provide anyway.
>>
>> Our perspective is, that if you need plausible deniability, you have to
>> look into details anyway (it's hard to do plausible deniability right),
>> and people can still disable discard in those cases.
>>
>> So what do you think about making 'discard' the default in cryptsetup
>> for LUKS? Would you consider doing so? If not, would you be fine with
>> cryptsetup in Debian defaulting to 'discard' nevertheless? Could you
>> imagine to add a compile-time flag for doing so? In any case, an option
>> to *disable* the default would be needed.
>>
>> We're curious what you think about it :)
>>
>> Kind regards,
>>  jonas, on behalf of the Debian cryptsetup team
>>
>> [1] https://salsa.debian.org/installer-team/partman-crypto/merge_requests/2
>> [2] https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html
>>
>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> https://www.saout.de/mailman/listinfo/dm-crypt
>>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt
> 



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [dm-crypt] 'discard' as default

[Christoph Anton Mitterer]

On Thu, 2019-01-31 at 00:11 +0100, Jonas Meurer wrote:
> explain to users that they should always give the 'discard'
> option
> to new devices if they don't have a good reason to not do so

It's sad to see Debian giving bad advise to users, especially several
people said here upon being questioned, that it should be vice-versa…
i.e. using the more secure setting unless one has a good reason not to.

> I see that the discard option has security implications. Absolutely.
> Whether those are minor or major is debatable. My take on this is,
> that
> the tradeoff is acceptable and for the vast majority of users
> neglectable.

I cannot see that this has been anywhere proven by solid and extensive
crpytoanalysis.
Instead, past has always shown that even small leakage of information
can be a huge attack surface.

If it was 20 years ago, the question would have probably been:
 Can we enable compression without risk?
And the answer would have been:
 It's not clear whether it can be abused, but rather don't to it.
Then:
 Well let's still to it.
Then:
 CRIME and BEAST attacks. Oops.


> On the other side, having fstrim working per default
> even
> on encrypted volumes is a huge advantage.

I wonder what advantage it is for someone who deliberately decides to
use dm-crypt, to possibly weaken just this.


Well just my two cents. :-)

Re: [dm-crypt] 'discard' as default

[Jordan Glover]

On Saturday, February 2, 2019 10:37 PM, Jonas Meurer <jonas@freesources.org> wrote:
>
> I see that the discard option has security implications. Absolutely.
> Whether those are minor or major is debatable. My take on this is, that
> the tradeoff is acceptable and for the vast majority of users
> neglectable. On the other side, having fstrim working per default even
> on encrypted volumes is a huge advantage.
>
> In general, I don't believe that choosing the most secure option without
> taking other aspects into account is always just right. Sometimes,
> accepting a small tradeoff towards usability can help a lot. It lowers
> the barrier to use cryptographical software. And users who care about
> more sophisticated attack vectors and want to put security first, are
> still free to change their settings.
>

You are right that there is a tradeoff and we should seek the balance between
security and performance. The problem is that 'performance people' tend to
overplay their arguments without providing any data to support that claims.
TRIM has greatest advantages for very small capacity flash storage which may be
found on tablets. I wonder how many of them run Debian or any other distro with
LUKS. Raising storage capacities and technological advancement of ssd/nvme disks
make TRIM more and more irrelevant thus enabling it for encrypted devices is as
neglectable for performance as disabling it is for security. So please don't
frame it as cancer cure vs painkiller.

Jordan

Re: [dm-crypt] 'discard' as default

[Michael Kjörling]

On 31 Jan 2019 00:11 +0100, from jonas@freesources.org (Jonas Meurer):
> I think, we should just adjust the docs of the Debian cryptsetup package
> and explain to users that they should always give the 'discard' option
> to new devices if they don't have a good reason to not do so (i.e. have
> hidden volumes inside the volume, have to hide whether there's data
> written to the volume or want to protect against access patterns being
> leaked).

I disagree. Certainly a note could be added that adding the 'discard'
option can improve performance, and the choice to do so can be offered
during interactive installation, _but_ with a clear warning that
depending on the threat model, it may improve performance at the cost
of security, and that those who desire the best security should leave
discard disabled, whatever exact choice that means given the specific
selection of choices provided.

Frankly, people in general, even those who value security, in my
experience have only the vaguest sense of an idea about threat
modelling, even in the physical space (let alone digital). Those
people are exactly the ones who are most likely to do something like
turn on LUKS during system installation, set a reasonably strong
passphrase (because they understand that turning on encryption
improves security, and that a longer or more random passphrase equals
better security) and _not_ understand or realize that they _also_ need
to take active steps to turn off "discard". I doubt many people would
even reflect on metadata leakage due to storage location patterns in
use. And _they shouldn't need to_ consider such things; again,
_reducing_ security should be the active choice, not _improving_
security, even if the specific threat seems somewhat far-fetched
today. Spectre and Meltdown also seemed far-fetched, to the extent
that such attacks were even considered, only a few years ago; now they
(and their ilk) are on the minds of a lot of very smart people both
trying to exploit them, and trying to mitigate them without completely
ruining performance. The difference is, we didn't actually envision
out-of-order speculative execution to leak information, since it was
supposed to be purely internal to the CPU with no observable side
effects; here, we can actually _see_ a benefit to the more secure
choice (that of by default not allowing TRIM pass-through), in that it
reduces metadata leakage. Metadata _is_ data, even when it's "only"
metadata about metadata. It's turtles all the way down.

In the words of BCP 188:

> Those developing IETF specifications need to be able to describe how
> they have considered [pervasive monitoring], and, if the attack is
> relevant to the work to be published, be able to justify related
> design decisions. This does not mean a new "pervasive monitoring
> considerations" section is needed in IETF documentation. It means
> that, if asked, there needs to be a good answer to the question "Is
> pervasive monitoring relevant to this work and if so, how has it
> been considered?"
> 
> In particular, architectural decisions, including which existing
> technology is reused, may significantly impact the vulnerability of
> a protocol to PM. Those developing IETF specifications therefore
> need to consider mitigating PM when making architectural decisions.
> Getting adequate, early review of architectural decisions including
> whether appropriate mitigation of PM can be made is important.
> Revisiting these architectural decisions late in the process is
> very costly.

While Debian's installer defaults for LUKS hardly constitutes an IETF
specification, I believe that the advice of BCP 188 is still worth
heeding.


> I see that the discard option has security implications. Absolutely.
> Whether those are minor or major is debatable. My take on this is, that
> the tradeoff is acceptable and for the vast majority of users
> neglectable. On the other side, having fstrim working per default even
> on encrypted volumes is a huge advantage.

Such was, to a large extent, the reasoning also about speculative
execution. Not so these days, _after_ someone figured out a way to
exploit it as a weakness and turned the idea of doing so from a
curiosity to a pretty big issue.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
  “The most dangerous thought that you can have as a creative person
              is to think you know what you’re doing.” (Bret Victor)

Re: [dm-crypt] 'discard' as default

[Arno Wagner]

Incidentally, just to put this whole mess into perspective,
(and top-posting, because the text has gotten too long)
the current wisdom is still that you should _not_ put LUKS
on FLASH storage in the first place because that is a 
very hard to quantify risk. You should put it on classical
spinning disk where an overwrite goes to the same sector
as the original data. I bet no installer gives that warning 
to users in the first place. I find it a bit sad that the 
false god of performance seems to trump everything, and 
that its disciples are so blind not to even give warnings
anymore what potentially negative effects folowing their
creed has. 

Specrte and Meltdown are indeed nice examples why that can 
backfire damatically. Security, like most good engineering,
is about redundancy. You cut a bit here and a bit there and
suddenly you are nacked. Not good at all.

Regards,
Arno


On Sun, Feb 03, 2019 at 15:23:42 CET, Michael Kjörling wrote:
> On 31 Jan 2019 00:11 +0100, from jonas@freesources.org (Jonas Meurer):
> > I think, we should just adjust the docs of the Debian cryptsetup package
> > and explain to users that they should always give the 'discard' option
> > to new devices if they don't have a good reason to not do so (i.e. have
> > hidden volumes inside the volume, have to hide whether there's data
> > written to the volume or want to protect against access patterns being
> > leaked).
> 
> I disagree. Certainly a note could be added that adding the 'discard'
> option can improve performance, and the choice to do so can be offered
> during interactive installation, _but_ with a clear warning that
> depending on the threat model, it may improve performance at the cost
> of security, and that those who desire the best security should leave
> discard disabled, whatever exact choice that means given the specific
> selection of choices provided.
> 
> Frankly, people in general, even those who value security, in my
> experience have only the vaguest sense of an idea about threat
> modelling, even in the physical space (let alone digital). Those
> people are exactly the ones who are most likely to do something like
> turn on LUKS during system installation, set a reasonably strong
> passphrase (because they understand that turning on encryption
> improves security, and that a longer or more random passphrase equals
> better security) and _not_ understand or realize that they _also_ need
> to take active steps to turn off "discard". I doubt many people would
> even reflect on metadata leakage due to storage location patterns in
> use. And _they shouldn't need to_ consider such things; again,
> _reducing_ security should be the active choice, not _improving_
> security, even if the specific threat seems somewhat far-fetched
> today. Spectre and Meltdown also seemed far-fetched, to the extent
> that such attacks were even considered, only a few years ago; now they
> (and their ilk) are on the minds of a lot of very smart people both
> trying to exploit them, and trying to mitigate them without completely
> ruining performance. The difference is, we didn't actually envision
> out-of-order speculative execution to leak information, since it was
> supposed to be purely internal to the CPU with no observable side
> effects; here, we can actually _see_ a benefit to the more secure
> choice (that of by default not allowing TRIM pass-through), in that it
> reduces metadata leakage. Metadata _is_ data, even when it's "only"
> metadata about metadata. It's turtles all the way down.
> 
> In the words of BCP 188:
> 
> > Those developing IETF specifications need to be able to describe how
> > they have considered [pervasive monitoring], and, if the attack is
> > relevant to the work to be published, be able to justify related
> > design decisions. This does not mean a new "pervasive monitoring
> > considerations" section is needed in IETF documentation. It means
> > that, if asked, there needs to be a good answer to the question "Is
> > pervasive monitoring relevant to this work and if so, how has it
> > been considered?"
> > 
> > In particular, architectural decisions, including which existing
> > technology is reused, may significantly impact the vulnerability of
> > a protocol to PM. Those developing IETF specifications therefore
> > need to consider mitigating PM when making architectural decisions.
> > Getting adequate, early review of architectural decisions including
> > whether appropriate mitigation of PM can be made is important.
> > Revisiting these architectural decisions late in the process is
> > very costly.
> 
> While Debian's installer defaults for LUKS hardly constitutes an IETF
> specification, I believe that the advice of BCP 188 is still worth
> heeding.
> 
> 
> > I see that the discard option has security implications. Absolutely.
> > Whether those are minor or major is debatable. My take on this is, that
> > the tradeoff is acceptable and for the vast majority of users
> > neglectable. On the other side, having fstrim working per default even
> > on encrypted volumes is a huge advantage.
> 
> Such was, to a large extent, the reasoning also about speculative
> execution. Not so these days, _after_ someone figured out a way to
> exploit it as a weakness and turned the idea of doing so from a
> curiosity to a pretty big issue.
> 
> -- 
> Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
>   “The most dangerous thought that you can have as a creative person
>               is to think you know what you’re doing.” (Bret Victor)
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> https://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] 'discard' as default

[Christoph Anton Mitterer]

On Sun, 2019-02-03 at 18:34 +0100, Arno Wagner wrote:
> Specrte and Meltdown are indeed nice examples why that can 
> backfire damatically. Security, like most good engineering,
> is about redundancy. You cut a bit here and a bit there and
> suddenly you are nacked. Not good at all.

Well Debian has unfortunately a not so short history in sometimes doing
rather questionable things in terms of security (*cough* openssl
*cough*). ;-)

But I guess this wrong mindset how to deal with security, i.e. not even
letting stuff that is targeted fully towards security have that as
priority can be found everywhere.
One would have expected that eventually something is learned from
history (spectre and meltdown are best examples), but apparently this
is not the case.

Anyway, guess there is nothing more upstream can/should do about
this... it's good to have an option to enable TRIM (for those who
deliberately want it) and it's good that it's not the default.
If distros choose to possibly weaken security, it's up to them and
unfortunately their users.


Cheers :-)

Re: [dm-crypt] 'discard' as default

[Arno Wagner]

On Sun, Feb 03, 2019 at 18:57:42 CET, Christoph Anton Mitterer wrote:
> On Sun, 2019-02-03 at 18:34 +0100, Arno Wagner wrote:
> > Specrte and Meltdown are indeed nice examples why that can 
> > backfire damatically. Security, like most good engineering,
> > is about redundancy. You cut a bit here and a bit there and
> > suddenly you are nacked. Not good at all.

[...]
 
> Anyway, guess there is nothing more upstream can/should do about
> this... it's good to have an option to enable TRIM (for those who
> deliberately want it) and it's good that it's not the default.
> If distros choose to possibly weaken security, it's up to them and
> unfortunately their users.

I agree on that one. All we can reasonably do is warn. 
Although being a security expert does feel like being
a climate scientists sometimes....

Regards,
Arno
-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

[dm-crypt] 'discard' as default

[Jonas Meurer]

[-- Attachment #1.1: Type: text/plain, Size: 2374 bytes --]

Hi list,

Starting with the upcoming release of Debian Buster, luks devices
created during installation will have the 'discard' option (trim feature
for flash devices) set in crypttab[1].

When Guilhem and me (we're the Debian cryptsetup maintainers) discussed
this topic, we agreed, that in general, having the discard option set
per default would be a nice thing to have. But we're unsure how to
implement it.

One option would be to simply add 'discard' to all crypttab examples and
document in README.Debian that we recommend to always add 'discard' as
crypttab option for new dm-crypt devices.

Buth then, *always* listing an option is somehow weird from a technical
perspective. If we want it to be the defualt, then it should be the
default without explicitely having to set it.

So we wonder whether you (cryptsetup upstream would consider to make
discard the default in cryptsetup, at least for LUKS devices.

[Certainly, enabling 'discard' for the LUKS device, isn't sufficient for
turning on trim support for the device. It might have to be enabled in
other block stack layers and filesystem still. But that's another topic
to be dealt with in downstream distributions like Debian.]

As far as we know, the main *negative* impact of enabling the trim
feature on flash devices is, that it might reveal information on which
parts of the disk are written and which are not, even if you first
filled the disk with random data[2]. To our knowledge, that's only a
problem if you need plausible deniability, wich LUKS doesn't provide anyway.

Our perspective is, that if you need plausible deniability, you have to
look into details anyway (it's hard to do plausible deniability right),
and people can still disable discard in those cases.

So what do you think about making 'discard' the default in cryptsetup
for LUKS? Would you consider doing so? If not, would you be fine with
cryptsetup in Debian defaulting to 'discard' nevertheless? Could you
imagine to add a compile-time flag for doing so? In any case, an option
to *disable* the default would be needed.

We're curious what you think about it :)

Kind regards,
 jonas, on behalf of the Debian cryptsetup team

[1] https://salsa.debian.org/installer-team/partman-crypto/merge_requests/2
[2] https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]