[dm-crypt] keys in memory?

[dm-crypt] keys in memory?

[Kachler, Arie]

Hi all,

When a system has been configured and it's using encrypted LUKS partition(s), are they keys visible in memory?
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.

Arie Kachler

Re: [dm-crypt] keys in memory?

[Milan Broz]

On 01/13/2011 10:03 PM, Kachler, Arie wrote:
> When a system has been configured and it's using encrypted LUKS
> partition(s), are they keys visible in memory?

for active devices yes. if you run encryption on the main CPU
(and not in some special hw), the key must be visible in memory.

> 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.

if you have access to hypervisor, you have access to the full memory,
you have access to everything.

Milan

Re: [dm-crypt] keys in memory?

[Arno Wagner]

(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 

Re: [dm-crypt] keys in memory?

[Milan Broz]

On 01/14/2011 12:56 AM, Arno Wagner wrote:
>> 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.

just small addition to this:

To be exact for active dm-crypt device:

- there is plain copy of master key string in the internal struct
(dmsetup table --showkeys prints that)

- there is key inside crypto engine, it is usually
pre-processed key (in AES case it is the whole key schedule
tables, and this is easily detectable, even if it is partially
corrupted, see AES keyfinder which uses this trick
here http://citp.princeton.edu/memory/code/ )

- because now (2.6.38)  we have per-cpu crypto engine, key schedule
will be probably in all local cpu caches during ongoing encryption.

- there can be other important info which can help to key recovery,
like initialised ESSIV tfm etc

(These locations should be wiped after key wipe message which
luksSuspend uses btw.)

All tries to lock this in processor cache, obfuscate it
in memory etc will not help - it can just make the problem slightly
harder. (if there is not generic hw helping with that, though)

> On Linux, the memory image is accessible under /proc/kcore.

Not in all distributions have this enabled, IIRC RHEL5 has there
only ELF header, not the whole memory image available.
But if you are superuser, you can get memory image using simple kernel
module. Suspended VM stores it in file.
For the hypervisor is is even simpler.

Milan

Re: [dm-crypt] keys in memory?

[Kachler, Arie]

Thank you for taking the time to clear this up Milan.
Your responses were very helpful.

Arie

On Jan 14, 2011, at 3:53 AM, Milan Broz wrote:

> On 01/14/2011 12:56 AM, Arno Wagner wrote:
>>> 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.
> 
> just small addition to this:
> 
> To be exact for active dm-crypt device:
> 
> - there is plain copy of master key string in the internal struct
> (dmsetup table --showkeys prints that)
> 
> - there is key inside crypto engine, it is usually
> pre-processed key (in AES case it is the whole key schedule
> tables, and this is easily detectable, even if it is partially
> corrupted, see AES keyfinder which uses this trick
> here http://citp.princeton.edu/memory/code/ )
> 
> - because now (2.6.38)  we have per-cpu crypto engine, key schedule
> will be probably in all local cpu caches during ongoing encryption.
> 
> - there can be other important info which can help to key recovery,
> like initialised ESSIV tfm etc
> 
> (These locations should be wiped after key wipe message which
> luksSuspend uses btw.)
> 
> All tries to lock this in processor cache, obfuscate it
> in memory etc will not help - it can just make the problem slightly
> harder. (if there is not generic hw helping with that, though)
> 
>> On Linux, the memory image is accessible under /proc/kcore.
> 
> Not in all distributions have this enabled, IIRC RHEL5 has there
> only ELF header, not the whole memory image available.
> But if you are superuser, you can get memory image using simple kernel
> module. Suspended VM stores it in file.
> For the hypervisor is is even simpler.
> 
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt