Re: [dm-crypt] Encrypt all partitions with dm-crypt

[Arno Wagner <arno@wagner.name>]

On Sat, Sep 08, 2012 at 06:39:07PM +0200, Heinz Diehl wrote:
> On 08.09.2012, Arno Wagner wrote: 
> 
> > So? You miss the point: If swap can be securely encrypted
> > independently, this decreases overall system complexity and
> > hence increase security.
> 
> If swap is created on installation, encrypted with the same 
> passphrase as the rest of the system, and just gets opened while
> booting, it is clearly _less_ complex than having it created on every 
> single (re)boot, incl. generating a new passphrase. 
> You simply boot, enter the passphrase and you're done.

It is not. The complexity is lesser because a single system 
doing two different things is basically always more complex 
than two systems doint the things individually. It may not
appear to be from the code, but design, architecture and 
security analysis are part of the system and they definitely 
get more complex. This poses for example an incresed risk to 
get it wrong., also on any changes.

The user-interface may be more complex though. Decreased risk
of user errors and decreased user inconvenience are the only 
possible advantages of having one thing do two very different
tasks. It is not in this case as one task (swap encryption) 
does not require user interaction but is completely autonomous.

One important paradigm in secure system design is to automatize
anythign that can be automatized without decreasing security.
For swap, automatizing encryption increases security.

What you seem to miss is that swap encryption and data encryption 
are two very different things. One protects data potentially
leaked from memory and one protects data at rest. Memory
needs more protection, as there can be a lot of sensitive
data in there that never makes it to disk. 

True, it sometimes requires design errors or system 
shortcommings. Some examples: 

- Neither Firefox nor Opera lock any memory when an SSL 
  connection is active. (Suspected this a long time, but just 
  checked. It is in the  VmLck field in /proc/<pid>/status.)
  This means SSL session keys will not be protected against 
  swapping and the same for anything sent or received over SSL.

- Upgrade the last item. Say you use Tor for something secret. 
  Same risk.

- The same is likely true for any chat application.  
 
> > For example, swap encryption done
> > this way will not be subject to any problems with weak 
> > passwords.
> 
> If you use weak passphrases, you have a substantial problem which goes
> far beyond the fact of automatic swapspace generation/encryption on
> boot vs. singe passphrase setup. 

But if you only encrypt wap, this problem will not be present
with a random key at all.

> Your whole system would be prone to
> brute force / dictionary attacks. Assuming your swap passphrase is
> randomly generated at boot-time, your swapspace would be secure, while
> the rest is not. That makes no sense to me.

Swap needs more protection than data at rest. The reason is that
the risk to swap is data-leakage from main memory. There can be 
things in swap that never make it to data storage.

> > And yes, it is possible that there are things in swap that
> > cannot be found in the data partitions. Swap encryption 
> > solves a different problem than data partition encryption.
> 
> You're right, I don't get the point. Really.
>  
> > That other encryption could be insecure on the system is
> > immaterial, swap can (and should) be solved on its own.
> 
> Frankly, nobody would try to attack swap on a fully encrypted system
> in the first place. If an attacker thinks it's worth the effort, where
> would he/she think are most of the relevant data? I strongly guess it
> would be the root and/or the home partition.

Oh, yes, a competent attacker would very much like to look
at swap as well, in particular if it is free anyways (only one
passphrase for everything). In autonomous swap encryption, the 
attacker has to spent likely more effort to get at swap. Which 
is appropriate as it may need more protection anyways, depending 
on attacker model.

> > And, as I have pointed out, there are reasons to want swap
> > encryption even when noting else on the system is encrypted,
> > so the independent approach needs to be engineered anyways.
> 
> I agree in this situation, just I don't understand why one would do
> that when all the rest is unencrypted. It's more likely that the
> various /tmp direcories will contain leaked sensitive data, or that 
> sensitive data is dumped to disk under a crash or system fault. 

That is rather unlikely. It also only happens on crashes, so 
the user will know. And it requires misconfiguration. And it 
is subject to the permission system. Nothing of that is true 
for swap.

> Even
> the randomly generated passphrase could leak/be dumped, because the
> root partition will be mounted before the swap is generated.

It could basically only leak to swap. And that is not a problem 
with a random key. It may be with a non-random one.

Now, all this is not a make-or-break item in most scenarios.
Dping swap encryption with a static key is not massively less
secure than doing it with a random key in most scenarios.

But if you want to do it right, then swap gets encrypted 
automatically with a one-time random key (that may even get 
regenerated periodically) and data gets encrypted with a user 
supplied key or a key that is protected by a user-supplied 
passphrase.

Arno
-- 
Arno Wagner,    Dr. sc. techn., Dipl. Inform.,   Email: arno@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