[dm-crypt] keys in memory?
arno at wagner.name
Fri Jan 14 00:56:02 CET 2011
(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
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
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 Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno at 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
More information about the dm-crypt