[dm-crypt] Memory location of the encryption key

[dm-crypt] Memory location of the encryption key

[Peter]

Hey!

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?

Happy day,
Peter

Re: [dm-crypt] Memory location of the encryption key

[Milan Broz]

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

Re: [dm-crypt] Memory location of the encryption key

[Arno Wagner]

On Mon, Feb 14, 2011 at 02:03:01PM +0100, Peter wrote:
> Hey!
> 
> 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?

I think there is some confusion: A cold-boot attack uses
the fact that many DRAM memory cells retain their state for seconds
or minutes after power is removed. The thing with memory cells
attenuating to what was stored in them over time is something
different.  

Complementing memory contents does not help against cold-boot 
attacks at all. It does help against the memory cells attenuating 
to their contents. Also note that the attenuation problem is 
typical for SRAM, while cold-boot attacks typically target DRAM. 
Also note that detectione memory attenuation can be quite difficult 
and may require you to take the memory chip through a large
number of measurements over different environmental conditions.

Finally, cold-boot attacks are used against PCs and similar
systems, while attenuation attacks are done against key-storage 
devices, like SRAM or FLASH-memory in chipcards.

This is not the whole story, of course.
 
There is basically nothing you can do against cold-boot attacks,
except overwrite memory contents in time. That requires attack
detection.

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] Memory location of the encryption key

[Hanno Foest]

On Tue Feb 15 10:54:35 CET 2011, Milan Broz wrote:

[Cold Boot attacks]
> 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).

Hi, sorry for the late reply... but I've been wondering if these attacks
- rebooting the device into some kind of imaging tool for retrieving the
  memory image with the encryption key - can't be prevented by storing
the key in a place in memory where it would be inevitably overwritten by
the contents of the boot media.

Obviously this wouldn't stop the kind of attacks where the cooled RAM is
being read in some kind of external device, but it would surely make
attacks more expensive.

Hanno

Re: [dm-crypt] Memory location of the encryption key

[Arno Wagner]

On Mon, Mar 14, 2011 at 11:16:55PM +0100, Hanno Foest wrote:
> On Tue Feb 15 10:54:35 CET 2011, Milan Broz wrote:
> 
> [Cold Boot attacks]
> > 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).
> 
> Hi, sorry for the late reply... but I've been wondering if these attacks
> - rebooting the device into some kind of imaging tool for retrieving the
>   memory image with the encryption key - can't be prevented by storing
> the key in a place in memory where it would be inevitably overwritten by
> the contents of the boot media.

That would be extremely difficult and relatively easy to circumvent,
e.g. by a PCI-E card that reads the memory and stops the boot
proccess before any data is loaded. Incidentally, a simple
way to kill the generic reset attack is to use a BIOS password and 
force a memory check.  

> Obviously this wouldn't stop the kind of attacks where the cooled RAM is
> being read in some kind of external device, but it would surely make
> attacks more expensive.

Indeed. One problem is that it is hard to know where the boot code
actually gets loaded to. A second problem is that it is rather
small (~100 bytes) and could possibly made smaller. That may be enough
to overwrite a key, but not a key-setup, i.e. the cipher with the key 
configured. Then there is the question of what to do if you have
more than one key.  

The simple way is to just have the BIOS erase the memory, and a memory
check does that. Obviously that is not enough. The "memory freezing
attack is also not very expensive, say < $1000.

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