Re: [dm-crypt] keys in memory?

[Arno Wagner <arno@wagner.name>]

(Milan: Have seen your answer, but this is something I
 feel rather strongly about, so I have to elaborate.)

On Thu, Jan 13, 2011 at 04:03:20PM -0500, Kachler, Arie wrote:
> Hi all,
> 
> When a system has been configured and it's using encrypted LUKS
> partition(s), are they keys visible in memory? 

Not necessarily directly, but the cipher key-setup is.
There is no way to avoid that with software encryption.
So it may require some days to work out how the cipher
key configuration looks in memory and it is possible
(depending on key set-up) that the original key cannot 
actually be reconstructed, but decryption will be possible
with just a mamory image. 

On Linux, the memory image is accessible under /proc/kcore.
Make a copy of that and it requires only a bit of work and
some sample encrypted data to find the keys.

> The question is relevant when deploying these types of partitions to a
> cloud provider, where the provider's hypervisor has access to all vms'
> memory. Any insight into this will be greatly appreciated.

The cloud provider has low-effort access to all your keys
in memory. It may also swap them out to disk if you are
unlucky. If you need confidentiallity, you need to control
the storage, hardware, OS, application and possibly network 
yourself, cloud computing cannot ever give you that. There 
are some efforts underway to try to change that, but what 
I saw so far has no chance of succeeding. I have so far not
seen any reasonable idea to get around this problem and I 
suspect it is fundamentally infeasible in a real clound
setting. I guess you can get grant money and publications 
with this though, if none of the reviwers understands IT 
security.

One way to explain this to a non-expert (which I guess is the
situation you are in) goes like this: 

- The cloud provider can copy, store and resume running 
  vm images without the vm user knowing. 
- The clound provider can become root on any image.
- Hence the cloud provider can copy your running VM in full, 
  including storage, can run it in some test-bed, become root in
  that test-bed and can then access any mapped decrypted partition
  at its leisure without you having the slightest chance of even 
  finding out an attack took place.
- As a consequence, the cloud provider can get at any and all 
  data processed in the clound without the data owners
  ever having a chance of noticing. These attacks do not require 
  significant effort.

That is not the whole story, of course. In some VM technologies
the above operations require a bit more effort and are not part
of the standard functionality. For example, it may be required 
add a key to the ssh trusted keys file for root and allow
ssh root login. This is a matter of minutes.

Assume you have no technological security against your cloud
provider at all. 

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

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