From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mail.saout.de (Postfix) with ESMTP for ; Thu, 19 May 2011 10:52:21 +0200 (CEST) Message-ID: <4DD4DA3C.90303@redhat.com> Date: Thu, 19 May 2011 10:52:12 +0200 From: Milan Broz MIME-Version: 1.0 References: <20110518152417.15529442@Haruhi.lan.labor-bochum.net> <1305755598.15947.2.camel@hidalgo> <4DD4C126.3030709@redhat.com> <1305792110.9280.4.camel@oban> In-Reply-To: <1305792110.9280.4.camel@oban> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Subject: Re: [dm-crypt] DM-Crypt resistance against Cold Boot Attacks List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Yves-Alexis Perez Cc: dm-crypt@saout.de 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