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

Milan Broz mbroz at redhat.com
Thu May 19 11:36:04 CEST 2011

On 05/19/2011 11:14 AM, Yves-Alexis Perez wrote:
>> 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.
> I don't know enough dm-crypt arch, but aiui from the paper, everytime
> you use the crypto-api to do stuff, it'll use the key in CPU debug
> registers and not the dummy key. Do you mean cryptsetup resize doesn't
> use the crypto-api (and will thus fail)?

cryptsetup (including resize command) works through DM API (dm-ioctl)
to setup dmcrypt, Only dmcrypt internally uses crypto-api.

(Cryptsetup resize will simple create the whole table again,
submitting key from userspace. This exercise will disappear
with the new table format.)
So it doesn't read key from crypto-api directly but thought that
DM mapping table.

There is already mechanism which ensures that all buffers with key
are wiped when working with dm-ioctl.
So this only slightly extends the window when is the key in memory
(during initial setting).

(Except that mentioned internal dmcrypt structure with plain key -
key is set through crypto-api for tpm _and_ also stored here.)

If you see how luksSuspend (aka key wipe message works):
- it suspends device to stop IO
- it wipes internal dmcrypt key buffer
- it wipes tfm keys through crypto-api (for block cipher, ESSIV etc)
(there is tfm per cpu in recent kernels as well)


More information about the dm-crypt mailing list