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

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

[Philipp Deppenwiese]

[-- Attachment #1: Type: text/plain, Size: 555 bytes --]

Hi,

a guy from a germany university impelemented an AES-NI with resistance
against Cold boot attacks and timing attacks. Maybe it's usefule to
modify the dm-crypt code.

http://www1.informatik.uni-erlangen.de/tresor/

Greetz Philipp

-- 


	   Philipp Deppenwiese<Scientific
	   Assistant> Institute for Internet Security -
	   if(is) University of Applied Sciences
	   Gelsenkirchen
	   https://www.internet-sicherheit.de		


GPG Fingerprint: 

64E4 0F3D E2EC B70D 7468  6356 3FBA F0E7 D814 27AB


















[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Yves-Alexis Perez]

[-- Attachment #1: Type: text/plain, Size: 423 bytes --]

On mer., 2011-05-18 at 15:24 +0200, Philipp Deppenwiese wrote:
> a guy from a germany university impelemented an AES-NI with resistance
> against Cold boot attacks and timing attacks. Maybe it's usefule to
> modify the dm-crypt code. 

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.

Regards,
-- 
Yves-Alexis

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

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

[Arno Wagner]

From the paper, TRESOR is a Linux kernel patch, hence not something
that would be added to cryptsetup, but the kernel. 

Arno

On Wed, May 18, 2011 at 03:24:17PM +0200, Philipp Deppenwiese wrote:
> Hi,
> 
> a guy from a germany university impelemented an AES-NI with resistance
> against Cold boot attacks and timing attacks. Maybe it's usefule to
> modify the dm-crypt code.
> 
> http://www1.informatik.uni-erlangen.de/tresor/
> 
> Greetz Philipp
> 
> -- 
> 
> 
> 	   Philipp Deppenwiese<Scientific
> 	   Assistant> Institute for Internet Security -
> 	   if(is) University of Applied Sciences
> 	   Gelsenkirchen
> 	   https://www.internet-sicherheit.de		
> 
> 
> GPG Fingerprint: 
> 
> 64E4 0F3D E2EC B70D 7468  6356 3FBA F0E7 D814 27AB
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 



> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
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] DM-Crypt resistance against Cold Boot Attacks

[Kraktus]

Looks like, in theory at least, it could be use be used for other
encryption algorithms too, like Twofish or Serpent.

I hope the hardware specifics would still be practical with Twofish.
From what I've read, Serpent and Ridjindael are already broken.
http://www.schneier.com/crypto-gram-0209.html#1
http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html
http://www.schneier.com/blog/archives/2009/07/another_new_aes.html

On 18 May 2011 22:03, Arno Wagner <arno@wagner.name> wrote:
> From the paper, TRESOR is a Linux kernel patch, hence not something
> that would be added to cryptsetup, but the kernel.
>
> Arno
>
> On Wed, May 18, 2011 at 03:24:17PM +0200, Philipp Deppenwiese wrote:
>> Hi,
>>
>> a guy from a germany university impelemented an AES-NI with resistance
>> against Cold boot attacks and timing attacks. Maybe it's usefule to
>> modify the dm-crypt code.
>>
>> http://www1.informatik.uni-erlangen.de/tresor/
>>
>> Greetz Philipp
>>
>> --
>>
>>
>>          Philipp Deppenwiese<Scientific
>>          Assistant> Institute for Internet Security -
>>          if(is) University of Applied Sciences
>>          Gelsenkirchen
>>          https://www.internet-sicherheit.de
>>
>>
>> GPG Fingerprint:
>>
>> 64E4 0F3D E2EC B70D 7468  6356 3FBA F0E7 D814 27AB
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>
>
> --
> 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
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

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

[Kraktus]

On 19 May 2011 01:36, Kraktus <kraktus@googlemail.com> wrote:
> Looks like, in theory at least, it could be use be used for other
> encryption algorithms too, like Twofish or Serpent.
>
> I hope the hardware specifics would still be practical with Twofish.
> From what I've read, Serpent and Ridjindael* are already broken.
> http://www.schneier.com/crypto-gram-0209.html#1
> http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html
> http://www.schneier.com/blog/archives/2009/07/another_new_aes.html

*Rijndael. Sorry, can't type today.

> On 18 May 2011 22:03, Arno Wagner <arno@wagner.name> wrote:
>> From the paper, TRESOR is a Linux kernel patch, hence not something
>> that would be added to cryptsetup, but the kernel.
>>
>> Arno
>>
>> On Wed, May 18, 2011 at 03:24:17PM +0200, Philipp Deppenwiese wrote:
>>> Hi,
>>>
>>> a guy from a germany university impelemented an AES-NI with resistance
>>> against Cold boot attacks and timing attacks. Maybe it's usefule to
>>> modify the dm-crypt code.
>>>
>>> http://www1.informatik.uni-erlangen.de/tresor/
>>>
>>> Greetz Philipp
>>>
>>> --
>>>
>>>
>>>          Philipp Deppenwiese<Scientific
>>>          Assistant> Institute for Internet Security -
>>>          if(is) University of Applied Sciences
>>>          Gelsenkirchen
>>>          https://www.internet-sicherheit.de
>>>
>>>
>>> GPG Fingerprint:
>>>
>>> 64E4 0F3D E2EC B70D 7468  6356 3FBA F0E7 D814 27AB
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>> _______________________________________________
>>> dm-crypt mailing list
>>> dm-crypt@saout.de
>>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
>>
>> --
>> 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
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
>>
>

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

[Arno Wagner]

I have severe doubts as to its practical usefullness and 
security. It blocks CPU registers. That means if you 
want to do two ciphers or even only two keys, you may
be out of luck or (worse) insecure as the registers
get dumped somewhere. I also have my doubts whether these
registers really do not get read and stored to memory.

Without reading the paper in detail, I think this is a 
specialized tool for a scenario where you need to prevent
exactly one cipher with exactly one key from being written 
to RAM. That does not scale at all and may cause problems 
in other places. 

It looks like a neat bit of research though.

Arno


On Thu, May 19, 2011 at 01:36:02AM +0000, Kraktus wrote:
> Looks like, in theory at least, it could be use be used for other
> encryption algorithms too, like Twofish or Serpent.
> 
> I hope the hardware specifics would still be practical with Twofish.
> From what I've read, Serpent and Ridjindael are already broken.
> http://www.schneier.com/crypto-gram-0209.html#1
> http://www.schneier.com/blog/archives/2009/07/new_attack_on_a.html
> http://www.schneier.com/blog/archives/2009/07/another_new_aes.html
> 
> On 18 May 2011 22:03, Arno Wagner <arno@wagner.name> wrote:
> > From the paper, TRESOR is a Linux kernel patch, hence not something
> > that would be added to cryptsetup, but the kernel.
> >
> > Arno
> >
> > On Wed, May 18, 2011 at 03:24:17PM +0200, Philipp Deppenwiese wrote:
> >> Hi,
> >>
> >> a guy from a germany university impelemented an AES-NI with resistance
> >> against Cold boot attacks and timing attacks. Maybe it's usefule to
> >> modify the dm-crypt code.
> >>
> >> http://www1.informatik.uni-erlangen.de/tresor/
> >>
> >> Greetz Philipp
> >>
> >> --
> >>
> >>
> >> ?? ?? ?? ?? ??Philipp Deppenwiese<Scientific
> >> ?? ?? ?? ?? ??Assistant> Institute for Internet Security -
> >> ?? ?? ?? ?? ??if(is) University of Applied Sciences
> >> ?? ?? ?? ?? ??Gelsenkirchen
> >> ?? ?? ?? ?? ??https://www.internet-sicherheit.de
> >>
> >>
> >> GPG Fingerprint:
> >>
> >> 64E4 0F3D E2EC B70D 7468 ??6356 3FBA F0E7 D814 27AB
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> >> _______________________________________________
> >> dm-crypt mailing list
> >> dm-crypt@saout.de
> >> http://www.saout.de/mailman/listinfo/dm-crypt
> >
> >
> > --
> > 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
> > _______________________________________________
> > dm-crypt mailing list
> > dm-crypt@saout.de
> > http://www.saout.de/mailman/listinfo/dm-crypt
> >
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
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] DM-Crypt resistance against Cold Boot Attacks

[Milan Broz]

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).

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

Anyway, it must be accepted into kernel crypto layer first.

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?)

Milan

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

[Yves-Alexis Perez]

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.
> 
> 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?
> 
> Anyway, it must be accepted into kernel crypto layer first.

I'm not even sure it'll be submitted though.
> 
> 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).

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.

Regards,
-- 
Yves-Alexis

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

[Milan Broz]

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

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

[Yves-Alexis Perez]

On jeu., 2011-05-19 at 10:52 +0200, Milan Broz wrote:
> 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.

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)?
> 

> >> 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?

No, I meant the “changes needed” :)

> 
> ... 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?

No idea. Just to be clear, I'm in now way associated to that paper, I
just found it interesting after seeing the first mail in thread and
wanted to add my views about the suppossingly needed changes to
dm-crypt. But looking at their website and the papers I didn't see
anything about submitting the patch upstream. It might not be acceptable
to use the debug registers in mainline kernel though.

> > 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.)

Note that I'm not sure it's a good idea to use encryption in a guest
anyway, at least not to protect from the host.

Regards,
-- 
Yves-Alexis

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

[Milan Broz]

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