From: Milan Broz <mbroz@redhat.com>
To: Peter <peter@alpha-force.net>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] Memory location of the encryption key
Date: Tue, 15 Feb 2011 10:54:35 +0100 [thread overview]
Message-ID: <4D5A4D5B.4000807@redhat.com> (raw)
In-Reply-To: <20110214140301.b373bee9@citadel.alpha-force.net>
On 02/14/2011 02:03 PM, Peter wrote:
> I've been reading Gutmann's paper on data remanence, which says that
> if some data is kept in the same memory location for very little time
> (1 second), the possibility for recovery of this data is very low,
> because the data had not yet had the time to change the relevant
> physical properties used in cold boot attacks. My question is, does
> dm-crypt change the memory location of encryption key every second?
> Does dm-crypt rewrite the memory location of the key when removing an
> active mapping? What other cold boot attack mitigation techniques the
> dm-crypt does?
Hi,
(I guess you are talking about - quite old - paper named
"Data remanence in semiconductor devices", right?
Then the mandatory reading is http://citp.princeton.edu/memory/ )
In short - dmcrypt doesn't rewrite key and change location every
few seconds and I hope it never will be doing such things.
The "hard" version of Cold Boot is using cooling chips to low
temperature (-50C and lower) the 1 second is no longer true
in this case.
Moreover, this attacks also include "platform reset" attack when
you simply reset device and store memory image, because the power
was still present, there is no memory loss (except few pages
for image tool).
The only possibility here is physical security of machine with
active key in memory.
Any obfuscation of key in memory will not help, only
it complicates attack a little bit.
Maybe you know the story of another full disk encryption system
where they are trying to do such crazy things (inverting key
in memory every few moments)?
When you attack such system using short power down with
following reboot and collecting memory image, you sometimes get
partially corrupted image (some bits already lost its state).
But because there was inverted key stored, it helps you
to _recover_ key instead of hide it.
I am not saying that it is all wrong...
just this known thing applies here:
"If you let you machine out of your sight, it is no longer your machine."
You simply must provide physical security of machine while mapping
is active. (When deactivating mapping the key is wiped of course.)
What dm-crypt does instead is to provide controlled way how to freeze
dm-crypt device in safe state (no key in memory) without need
to completely shutdown system.
In userspace you can access this using luksSuspend and luksResume commands.
(device is simple suspended and all keys from memory are wiped so
that platform reset attack will not succeed here. It is not 100% solution
because there can be still some plaintext data in memory but no encryption
key).
Milan
next prev parent reply other threads:[~2011-02-15 9:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-14 13:03 [dm-crypt] Memory location of the encryption key Peter
2011-02-15 9:54 ` Milan Broz [this message]
2011-02-15 15:42 ` Arno Wagner
-- strict thread matches above, loose matches on Subject: below --
2011-03-14 22:16 Hanno Foest
2011-03-14 23:15 ` Arno Wagner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D5A4D5B.4000807@redhat.com \
--to=mbroz@redhat.com \
--cc=dm-crypt@saout.de \
--cc=peter@alpha-force.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.