All of lore.kernel.org
 help / color / mirror / Atom feed
From: Milan Broz <mbroz@redhat.com>
To: Yves-Alexis Perez <corsac@debian.org>
Cc: dm-crypt@saout.de
Subject: Re: [dm-crypt] DM-Crypt resistance against Cold Boot Attacks
Date: Thu, 19 May 2011 11:36:04 +0200	[thread overview]
Message-ID: <4DD4E484.7090503@redhat.com> (raw)
In-Reply-To: <1305796496.9280.10.camel@oban>

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)

Milan

  reply	other threads:[~2011-05-19  9:36 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-18 13:24 [dm-crypt] DM-Crypt resistance against Cold Boot Attacks Philipp Deppenwiese
2011-05-18 21:53 ` Yves-Alexis Perez
2011-05-19  7:05   ` Milan Broz
2011-05-19  8:01     ` Yves-Alexis Perez
2011-05-19  8:52       ` Milan Broz
2011-05-19  9:14         ` Yves-Alexis Perez
2011-05-19  9:36           ` Milan Broz [this message]
2011-05-18 22:03 ` Arno Wagner
2011-05-19  1:36   ` Kraktus
2011-05-19  1:37     ` Kraktus
2011-05-19  6:01     ` 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=4DD4E484.7090503@redhat.com \
    --to=mbroz@redhat.com \
    --cc=corsac@debian.org \
    --cc=dm-crypt@saout.de \
    /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.