Re: [dm-crypt] DM-Crypt resistance against Cold Boot Attacks

[Milan Broz <mbroz@redhat.com>]

On 05/19/2011 10:01 AM, Yves-Alexis Perez wrote:
> On jeu., 2011-05-19 at 09:05 +0200, Milan Broz wrote:
>> On 05/18/2011 11:53 PM, Yves-Alexis Perez wrote:
>>> If you read the paper, you'll noticed there's nothing to change to
>>> dm-crypt, as the cypher is registered in the Crypto-API, it can be used
>>> directly.
>>
>> TBH dmcrypt keeps its own copy of key (because key it is still part
>> of the device-mapper mapping table so it must be available for
>> status commands).
> 
> In that case it'll be the “dummy” key.

The logic now works that table line received from dmcrypt
is directly usable - cryptsetup uses that e.g. for resize.
Replacing the key with zeroes or something will break this.

(Note that tools for scanning memory scan for pre-calculated
AES key, not for this "plain hexa string" dmcrypt pattern,
I had some simple modification for testing luksSuspend - which
must wipe all these keys.

I had also idea to build this scanner as directly grub
loadable image - to demonstrate that most of distributions
are not able to properly shutdown system if root fs running from
encrypted disk and after "clean" reboot key is still in memory.
Finally, dracut/systemd has already idea of "shutdown pivot_root"
which allows decomposing of root devices properly - thus shutting
the dmcrypt properly and wiping the key.)

>> So there are some changes needed but basically technicaly unrelated
>> to that patch.
>> (This will hopefully change with new mapping table format soon.)
> 
> Needed for what?

You mean new table format?

Currently the table format is fixed (and parsing hardcoded
in various tools) so cannot be extented.
I have several reasons to define new format (of course it will
be used only with new tools, is still must support old format).

- encryption key, once set, should be not easily accessible from
the outside of module, (FIPS is even stricter here btw).
So I want to set encryption key only though message and remove it
from new mapping table. (This even allows other source for key -
like internal kernel keyring or so.)
(See "dmsetup table --showkeys" here for demonstration of problem.)
The mechanism is already in place for luksResume command.

- any extension for table like optional discard support or
online reencryption helpers need aditional parameters - and
the table is not extensible (other DM targets use "parameter"
count field so parameter count is not fixed but not dmcrypt)

... etc.

>>
>> Anyway, it must be accepted into kernel crypto layer first.
> 
> I'm not even sure it'll be submitted though.

So it is just academic exercise for conferences?

>> IMHO I think that without strong hw support these implementation
>> will have some problems but it is good that someone works on such
>> things.
>> (E.g. how it works if it is not bare hw but virtualized system?)
> 
> For the AES-NI one, if the hypervisor supports it (they tested on KVM)
> yes (though the vm registers are stored in the host ram anyway).

Yes, that was my point. (AES-NI works for guests but bare hw has
of course limited hw resources.)

> If you're interested, I found that the two papers were quite clear and
> quick to read, so it might be a good idea to read them.

Sure, I will read them.

Thanks,
Milan