[Cryptography] The Quantum of Security Was: Speeding up Linux disk encryption

[Phillip Hallam-Baker]

On Mon, Apr 12, 2021 at 1:05 PM Kent Borg <kentborg at borg.org> wrote:

> There are a *whole* lot of threats that full disk encryption does not
> address, and they need to be addressed.
>
Yes but how far do we have to go down the rabbit hole to deliver something
that provides a useful quantum of security?

I don't know of anyone who has proposed anything as wide in scope as the
Mesh. But I get far more complaints about the lack of direct consideration
against end-point compromise than people suggesting the scope should be
narrower.

I don't do endpoint compromise precisely because it is a never ending
problem. No, signing the operating system is not a full protection against
rootkits. Rootkits can live in the firmware of your graphics cards, your
network cards and many other places. If the endpoint is compromised, the
user is hosed and detecting and recovering from that is not my problem.

Whole disk encryption is like IPSEC, it provides a particular quantum of
security but a rather limited one. It provides protection against laptops
being stolen from cars, data being breached through hard drives being sold
on EBay and allows a box to be checked on the auditor's list.

It is a limited but useful quantum of security. Other measures fail to make
a useful quanta. Forcing users to include a capital and a digit in their
password does absolutely nothing useful, it actually reduces security since
all they do is change password to Password1 so only 8 of the 9 characters
are contributing.


There are some controls that are easily defeated because they do not
provide a sufficient quantum of security and other times when a piffling
objection to the lack of a PERFECT SOLUTION means we overlook the good.

For example: If employees are dealing with sensitive documents like
patents, customer data etc. surely these should all be encrypted by default
so only authorized employees have access. We have known how to do that for
30+ years. We have better ways of doing that today but we could encrypt
every document with S/MIME in a really flexible way that doesn't impact end
users. I call this problem Confidentiality Control and I believe it is a
useful quantum of security.

Why don't we do it? Well Alice who is authorized might communicate the data
to Mallet. So lets make sure that cannot possibly happen by completely
redesigning the operating system to make it Trustworthy and then rewrite
the apps so they stop Alice disclosing the document. And that is the whole
CRM/DRM tar baby which we all know is impossible. Except of course that DRM
does actually provide a very useful quantum of security to industries whose
concern in protecting revenues from copyright content which is not actually
a confidentiality issue at all.


When I started doing crypto we would ask where the right place to do
encryption is. I now know that is the wrong question because there isn't
one right answer. For communications, I want to encrypt at the transport
level and the message level. For storage I want to encrypt the disk and
also the individual data files on the disk. And in some cases I might want
to encrypt folders as well. And I also want to automatically create copies
of all my data so that if I lose one disk, there is always another copy.
And I want to automatically notarize all data so that I can detect
integrity attacks, etc. etc.

We need a yardstick to distinguish an appropriate concern that a control
does not provide a meaningful quantum of security with a piffling objection
that the control does not deliver the kitchen sink.

Some ways of distinguishing:

* What is the cost of the proposed attack vector?
* Does the control provide meaningful mitigation even if it is not 100%
effective?
* What proportion of uses are affected by the stated vulnerability?
* If there was a solution to the identified vulnerability, would the
control still be needed?
* If someone proposed a solution for the proposed vulnerability would
someone object that the issue addressed by this vulnerability would remain?

Raising the cost of an attack is a valid security control. The main reason
I wrote the DotCrime Manifesto was simply that I was fed up of having to
wade through dozens of irrelevant objections when trying to discuss a
particular control. I could simply answer 'I explained how to address that
in my book'.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210412/375ec337/attachment.htm>