[dm-crypt] Dmcrypt and hibernate key disclosure

[dm-crypt] Dmcrypt and hibernate key disclosure

[Aaron Lewis]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,
	If i hibernate with an device opened , before i resume , an image was
written on swap partition , will there be a problem with my secret key's
disclosure ?

	Just an off-line attack , if swap is not encrypted.

	And is there any suggestion for this special operation ? Because my
root partition is also encrypted , so i can't simply close that device
before hibernation took place.

	Thanks.

- -- 
Best Regards,
Aaron Lewis - PGP: 0xDFE6C29E ( http://keyserver.veridis.com )
Finger Print: 9482 448F C7C3 896C 1DFE 7DD3 2492 A7D0 DFE6 C29E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNJm75AAoJECSSp9Df5sKeyF8QAKPAqFwA389n8eBU0UJE0TkO
Y7pSyqP39NI+BSgBlWJIC8D8GzduHPkgmfwxGQs9vSzqI1sWWO9kOMqlmvv9BR42
OF9nz8nmkCjS7+RV6mOIe0J3khpbrDbFYyn/EbRmRG2qmHyLaVYS75DQuvMvCUNC
TTr1fO1dET/68kOfMFzSrh++9Nq/boeNjWqsvbUil5fi1IHuhzq2tyQD8SpaZY2x
eklhgK5WML/A9/o1rGVCyfQ+B+OQjgOe8CeIt4E77iLwBvTyy1xaoyxgjVKi+sZz
xE8gqHgRNY8wWa5uaWbNRwR7nDIfpscCnZcCs009FUMmQJN5woYArBWsdSeN+RpX
tLi0onz+k940SqFvXSzMkG3it+gyOCBo4JsceCTigtD0OBdJjPX6QadHQGOSDN8t
w21uDagTmj00aWXmAieo+gTkod2d9MC+MiO3QVIgl0XvxEggtB5HENe8rI1rbQvc
vmeXHrEX1rGppL06S4OsCU5Bixxnvttui6Y6aaPBoU3J1yER8icdAIB+fQUWcIDL
580Qn15DbsAuVaCPTVSU7mucqSOFsgYY9stPx+lnRRDhPT/uqFEebvgxLMavBv7k
jb/u6aoKBTfDux763jqZuwj6xGpADWyUBP0NWzRy7Vpi6Zvi5YEoSEmm9OzP0kwN
mKmgct2AKXZYNP998rBc
=CeTJ
-----END PGP SIGNATURE-----

Re: [dm-crypt] Dmcrypt and hibernate key disclosure

[Arno Wagner]

On Fri, Jan 07, 2011 at 09:40:09AM +0800, Aaron Lewis wrote:
> Hi,
> 	If i hibernate with an device opened , before i resume , an image was
> written on swap partition , will there be a problem with my secret key's
> disclosure ?
> 
> 	Just an off-line attack , if swap is not encrypted.
> 
> 	And is there any suggestion for this special operation ? Because my
> root partition is also encrypted , so i can't simply close that device
> before hibernation took place.
> 
> 	Thanks.

Did a Google search and ended up at something I said here some
time ago that did not really help ;-)

First, I do not know for sure how hibernation works. I never 
used it. What I could find out, is that hobernation does
shut down the computer and boots it up into an image of
the pre-hibernation state instead of going through the 
normal boot sequence.

As fas as I can tell, all suspend methods do store all 
used memory pages to swap, and that definitely includes 
the kernel pages with the disk encryption keys.

Now, with uncencrypted swap, that clearly exposes the keys.
There seems to be an option to encrypt swap with a temporary 
key that gets wiped after resume. This way the encryption keys
would be exposed during hibernation, but not after wakeup.
It seems that with the swsup hibernation method that may
be default behaviour. Some explanation here:

http://www.freesoftwaremagazine.com/articles/hibernate_linux


The other option would be to modify the resume process to
ask you for the passphrase to the swap partition. I don't 
know whether that is possible. It seems to me that there
is actually no software hook or script thet gets executed
during resume, but that it is a full kernel-internal
operation. I also see no reference to a possibility to pass
swap encryption keys to the kernel. In this case, there is 
no way around the exposure during hibernate.


I see a possible alternate way to do this. Use a virtualized
environment for your system and suspend that to a device 
encrypted by the base system. Then you can hibernate the 
virtualized system, do a normal shutdown and reboot of the 
base system, configure the encrypted filesystem and unsuspend 
the virtual machine from it. I do that with a virtual
machine for working on confidential data. More effort, but 
suspend to disk (=hibernation) and security do not really mix.

Arno
-- 
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] Dmcrypt and hibernate key disclosure

[Bryan Kadzban]

Arno Wagner wrote:
> The other option would be to modify the resume process to
> ask you for the passphrase to the swap partition. I don't 
> know whether that is possible.

In an initramfs, I bet it is, though I've never tried it.  Resuming from
hibernate is handled by writing the major:minor of the block device to
resume from into the /sys/power/resume file, and I would *guess* that
the device node can be a device-mapper child (such as dm-crypt or LVM
would create).

The issue would be whether the device-mapper setup would have to be the
same post-resume as it was pre-hibernate.  I expect it would have to be,
but this is no different from real filesystems; hibernate writes out all
of RAM, so the kernel recovers all of its pre-hibernate state exactly.
(Well, except things like the current time.)

Of course, whether any given distro's initramfs setup can actually do
this (assuming it's possible in the kernel) is a different story.  :-)

> It seems to me that there
> is actually no software hook or script thet gets executed
> during resume,

From hibernate, there is.  It's a normal bootup, including initramfs,
until some string gets written into /sys/power/resume.  There might be
restrictions on when this write can happen, but I'm sure they at least
allow some initramfs code to run.

From suspend, there is no hook I know of.  But suspend doesn't normally
write anything to disk either, so that's fine.

Re: [dm-crypt] Dmcrypt and hibernate key disclosure

[Arno Wagner]

On Thu, Jan 06, 2011 at 08:08:55PM -0800, Bryan Kadzban wrote:
> Arno Wagner wrote:
> > The other option would be to modify the resume process to
> > ask you for the passphrase to the swap partition. I don't 
> > know whether that is possible.
> 
> In an initramfs, I bet it is, though I've never tried it.  Resuming from
> hibernate is handled by writing the major:minor of the block device to
> resume from into the /sys/power/resume file, and I would *guess* that
> the device node can be a device-mapper child (such as dm-crypt or LVM
> would create).
> 
> The issue would be whether the device-mapper setup would have to be the
> same post-resume as it was pre-hibernate.  I expect it would have to be,
> but this is no different from real filesystems; hibernate writes out all
> of RAM, so the kernel recovers all of its pre-hibernate state exactly.
> (Well, except things like the current time.)

And it woyld need to exclude the swap-setup as well or atomically 
change it after reading the image. Bith would be fine for encrypted
swap.

> Of course, whether any given distro's initramfs setup can actually do
> this (assuming it's possible in the kernel) is a different story.  :-)

Indeed. But rolling your own initramfs is not really that difficult.
Or doing without it and just placing a boot-system on a partition
for that matter. I never used an initramfs in my standard 
installations, but I typically build a non-module kernel as well
or one with just modules that do not work well as compiled into
the kernel, such as some wireless drivers.

> > It seems to me that there
> > is actually no software hook or script thet gets executed
> > during resume,
> 
> From hibernate, there is.  It's a normal bootup, including initramfs,
> until some string gets written into /sys/power/resume.  There might be
> restrictions on when this write can happen, but I'm sure they at least
> allow some initramfs code to run.

Seems I misunderstood the respective kernel parameter then. 
Or it is an alternative to the mechanism you describe.
So writing to /sys/power/resume replaces the current system
with the suspended one?

If it is a normal boot, then hibernate (= suspend to disk) to 
encrypted swap and ask for the swap key before the replacement
and set it up via dm-crypt.

> From suspend, there is no hook I know of.  But suspend doesn't normally
> write anything to disk either, so that's fine.

I guess you mean "suspend to RAM" here. Anyways, experimenting
on this would nto be that difficult. One thing you would need to
verify is that the image in swap is actually encrypted with your
swap key. Given that at leas somet suspend-to-disk mechanisms encrypt
themself, this could be a bit tricky.

Arno
-- 
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] Dmcrypt and hibernate key disclosure

[Bryan Kadzban]

Arno Wagner wrote:
> On Thu, Jan 06, 2011 at 08:08:55PM -0800, Bryan Kadzban wrote:
>> The issue would be whether the device-mapper setup would have to be
>> the same post-resume as it was pre-hibernate.  I expect it would
>> have to be, but this is no different from real filesystems;
>> hibernate writes out all of RAM, so the kernel recovers all of its
>> pre-hibernate state exactly. (Well, except things like the current
>> time.)
> 
> And it woyld need to exclude the swap-setup as well or atomically 
> change it after reading the image. Bith would be fine for encrypted 
> swap.

True.

>>> It seems to me that there is actually no software hook or script
>>> thet gets executed during resume,
>> From hibernate, there is.  It's a normal bootup, including
>> initramfs, until some string gets written into /sys/power/resume.
>> There might be restrictions on when this write can happen, but I'm
>> sure they at least allow some initramfs code to run.
> 
> Seems I misunderstood the respective kernel parameter then. Or it is
> an alternative to the mechanism you describe. So writing to
> /sys/power/resume replaces the current system with the suspended one?

If you mean the "resume=" kernel command-line parameter, then I am
fairly sure it will be used by the kernel only in the absence of an
initramfs.  If an initramfs is present, the kernel will do nothing, and
the initramfs will need to support all options like resume= on its own.

(Writing to /sys/power/resume is how the initramfs would support the
resume= option, of course.)

> If it is a normal boot, then hibernate (= suspend to disk) to 
> encrypted swap and ask for the swap key before the replacement and
> set it up via dm-crypt.

Yeah, this is what the initramfs needs to do.  I don't think there's
much chance of the kernel doing it itself, especially in the presence of
multiple keyboard layouts.  :-)

>> From suspend, there is no hook I know of.  But suspend doesn't
>> normally write anything to disk either, so that's fine.
> 
> I guess you mean "suspend to RAM" here.

Yes, to RAM.  Should have been more explicit.

> Anyways, experimenting on this would nto be that difficult. One thing
> you would need to verify is that the image in swap is actually
> encrypted with your swap key.

The last time I tried this (at least 3 years ago, but I don't remember
when exactly), I had a dm-crypted partition with an LVM PV in it, and
that PV had one LV for the rootfs and a second for swap.  Hibernate and
resume (to and from the swap LV) worked fine with the proper initramfs
support.

I didn't verify that the data was encrypted, but I think it'd be hard to
have LVM in between swap and dm-crypt, and have the data go through LVM
but not dm-crypt.  (I believe that it went through LVM because it worked
after resume, and who knows where the blocks got stuck by the LVM layer.)

Re: [dm-crypt] Dmcrypt and hibernate key disclosure

[Heiko Rosemann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/08/11 05:45, Bryan Kadzban wrote:
> Arno Wagner wrote:
>>>> It seems to me that there is actually no software hook or script
>>>> thet gets executed during resume,
>>> From hibernate, there is.  It's a normal bootup, including
>>> initramfs, until some string gets written into /sys/power/resume.
>>> There might be restrictions on when this write can happen, but I'm
>>> sure they at least allow some initramfs code to run.
>>
>> Seems I misunderstood the respective kernel parameter then. Or it is
>> an alternative to the mechanism you describe. So writing to
>> /sys/power/resume replaces the current system with the suspended one?
> 
> If you mean the "resume=" kernel command-line parameter, then I am
> fairly sure it will be used by the kernel only in the absence of an
> initramfs.  If an initramfs is present, the kernel will do nothing, and
> the initramfs will need to support all options like resume= on its own.

This might be implementation dependend (there is more than one
suspend-to-disk-option for linux). If a resume2= parameter is present
for tuxonice, the initramfs "only" needs to write "1" to
/sys/power/tuxonice/do_resume.

Regards,
Heiko


- -- 
eMails verschlüsseln mit PGP - privacy is your right!
Mein PGP-Key zur Verifizierung: http://pgp.mit.edu

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0oUCYACgkQ/Vb5NagElAWmfwCeLfsTTpZpJEabKq8VeYSG2Ln2
PPgAoJuAQEluPGKHCiYXWKYAF7ShAdUU
=tKBj
-----END PGP SIGNATURE-----

Re: [dm-crypt] Dmcrypt and hibernate key disclosure

[iggy]

I can verify that this works currently.

I am using Ubuntu 10.10 in the following setup:

Truecrypted windows partition.

Truecrypted data partition.

cleartext boot partition with intiramfs.

dmcrypt partition w/ LVM containing swap & root.

Suspend and hibernate both work dandy, and the only unencrypted place the
system could put the hibernate file (/boot) doesn't have enough free space
for that, by several times over.  Not that it would try to put it there
anyway.

Maybe I missed something, but why was there a suspicion that this might
not work?

-Iggy


> Arno Wagner wrote:
>> On Thu, Jan 06, 2011 at 08:08:55PM -0800, Bryan Kadzban wrote:
[...]
>> Anyways, experimenting on this would nto be that difficult. One thing
>> you would need to verify is that the image in swap is actually
>> encrypted with your swap key.
>
> The last time I tried this (at least 3 years ago, but I don't remember
> when exactly), I had a dm-crypted partition with an LVM PV in it, and
> that PV had one LV for the rootfs and a second for swap.  Hibernate and
> resume (to and from the swap LV) worked fine with the proper initramfs
> support.
>
> I didn't verify that the data was encrypted, but I think it'd be hard to
> have LVM in between swap and dm-crypt, and have the data go through LVM
> but not dm-crypt.  (I believe that it went through LVM because it worked
> after resume, and who knows where the blocks got stuck by the LVM layer.)
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] Dmcrypt and hibernate key disclosure

[Heiko Rosemann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/07/11 05:08, Bryan Kadzban wrote:
> Arno Wagner wrote:
>> The other option would be to modify the resume process to
>> ask you for the passphrase to the swap partition. I don't 
>> know whether that is possible.
> 
> In an initramfs, I bet it is, though I've never tried it.  Resuming from
> hibernate is handled by writing the major:minor of the block device to
> resume from into the /sys/power/resume file, and I would *guess* that
> the device node can be a device-mapper child (such as dm-crypt or LVM
> would create).

I do not know about the details like what needs to be copied in which
stage, but I can confirm that this works with tuxonice: Add to your
initramfs a call to cryptsetup luksOpen enc-swap before initiating the
resume process from /dev/mapper/enc-swap. I know this because this is
the setup I have been using for the last couple of years :)

> Of course, whether any given distro's initramfs setup can actually do
> this (assuming it's possible in the kernel) is a different story.  :-)

I have recently tried out archlinux and it is pretty easy to add such a
hook there. They also support udev inside their initramfs, so using a
keyfile on a specific USB device to unlock your swap is also quite easy.
(Using gentoo, I have been running into a lot of trouble with
compatibility issues between udev and busybox-modprobe - used in my
initramfs - lately)

It is also no big deal if you just unlock *all* encrypted partitions
before initiating the resume process, but it does not need to be done.

>> It seems to me that there
>> is actually no software hook or script thet gets executed
>> during resume,
>
> From hibernate, there is.  It's a normal bootup, including initramfs,
> until some string gets written into /sys/power/resume.  There might be
> restrictions on when this write can happen, but I'm sure they at least
> allow some initramfs code to run.

Well, most of my initramfs runs before initiating resume :)

Regards,
Heiko
- -- 
eMails verschlüsseln mit PGP - privacy is your right!
Mein PGP-Key zur Verifizierung: http://pgp.mit.edu

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk0m7hgACgkQ/Vb5NagElAW3CQCcCxtTN/UmI5XAYZfLaRqBv7QV
adIAn3U2NysZEES9ZlIzr4AvG9I9NUB5
=cHRj
-----END PGP SIGNATURE-----

Re: [dm-crypt] Dmcrypt and hibernate key disclosure

[Richard]

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

On Fri, Jan 07, 2011 at 09:40:09AM +0800, Aaron Lewis wrote:
> Hi,
> 	If i hibernate with an device opened , before i resume , an image was
> written on swap partition , will there be a problem with my secret key's
> disclosure ?
> 
> 	Just an off-line attack , if swap is not encrypted.

swap must be encrypted. Works nicely on Fedora, one boot partition and a big 
encrypted dm0 device with several LVM partitions on top of it.


Richard

---
Name and OpenPGP keys available from pgp key servers


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [dm-crypt] Dmcrypt and hibernate key disclosure

[Arno Wagner]

On Tue, Jan 11, 2011 at 01:08:16AM +0100, Richard wrote:
> On Fri, Jan 07, 2011 at 09:40:09AM +0800, Aaron Lewis wrote:
> > Hi,
> > 	If i hibernate with an device opened , before i resume , an image was
> > written on swap partition , will there be a problem with my secret key's
> > disclosure ?
> > 
> > 	Just an off-line attack , if swap is not encrypted.
> 
> swap must be encrypted. Works nicely on Fedora, one boot partition and a
> big encrypted dm0 device with several LVM partitions on top of it.
> 

Well, if you are not asked for the swap encryption key on
wakeup, basically everything is open. That would be a rather 
obvious implementation error though.

If you get asked, then it depends on the implementation, but
they do have the right idea.

Arno
-- 
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] Dmcrypt and hibernate key disclosure

[Milan Broz]

On 01/11/2011 10:11 AM, Arno Wagner wrote:
> On Tue, Jan 11, 2011 at 01:08:16AM +0100, Richard wrote:
>> On Fri, Jan 07, 2011 at 09:40:09AM +0800, Aaron Lewis wrote:
>>> Hi,
>>> 	If i hibernate with an device opened , before i resume , an image was
>>> written on swap partition , will there be a problem with my secret key's
>>> disclosure ?
>>>
>>> 	Just an off-line attack , if swap is not encrypted.
>>
>> swap must be encrypted. Works nicely on Fedora, one boot partition and a
>> big encrypted dm0 device with several LVM partitions on top of it.
>>
> 
> Well, if you are not asked for the swap encryption key on
> wakeup, basically everything is open. That would be a rather 
> obvious implementation error though.
> 
> If you get asked, then it depends on the implementation, but
> they do have the right idea.

Sorry I do not follow this thread but Fedora uses by default 
(= "encrypt the whole system" checkbox in installer) unencrypted
boot partition (where initramdisk resides) and LUKS encrypted PV on
the second partition, on top of it is root and swap LVs.
(So the whole system is encrypted except boot initramfs.)

The same is quite common in other distros too.

During boot, initramfs must ask for passphrase to PV, the same for hibernate
(suspend to disk - ram image is stored to swap partition LV).

What is not safe is suspend to RAM. Maybe someone should start to use
luksSuspend to at least clear encryption key from memory but it is not
as easy implement as it seems:)

Btw do not afraid of LVM in this scheme - mapping is just linear, so
the only mapping operation in kernel is adding offset and switching device
so there should be no measurable performance problem (there is no cache
or so).

Milan

Re: [dm-crypt] Dmcrypt and hibernate key disclosure

[Richard]

On Tue, Jan 11, 2011 at 11:31:37AM +0100, Milan Broz wrote:

> Sorry I do not follow this thread but Fedora uses by default 
> (= "encrypt the whole system" checkbox in installer) unencrypted
> boot partition (where initramdisk resides) and LUKS encrypted PV on
> the second partition, on top of it is root and swap LVs.
> (So the whole system is encrypted except boot initramfs.)
> 
> The same is quite common in other distros too.
> 
> During boot, initramfs must ask for passphrase to PV, the same for hibernate
> (suspend to disk - ram image is stored to swap partition LV).

to sum up, I am quite pleased with Fedora in this respect. Makes full system
encryption including safe hibernation as trivial as checking a checkbox during
installation.

> What is not safe is suspend to RAM. Maybe someone should start to use
> luksSuspend to at least clear encryption key from memory but it is not
> as easy implement as it seems:)

surely luksSuspend would make it safer but still complete RAM would be left
unprotected which can be a lot of information. Did anyone look inot encrypting
RAM before suspend?

As it is now it is also not trivialy broken - getting the filesystems would 
involve breaking screen saver locking, breaking in through network or other 
interfaces or freezing the computer to retrieve and examine ramchips. 
Otoh chances are not bad that the average adversary upon seeing a locked session 
will just do a stupid reboot and loose every chance to hack into it.

> Btw do not afraid of LVM in this scheme - mapping is just linear, so
> the only mapping operation in kernel is adding offset and switching device
> so there should be no measurable performance problem (there is no cache
> or so).

seems dm or something else is slow enough that id does not matter at all.

Richard

---
Name and OpenPGP keys available from pgp key servers

Re: [dm-crypt] Dmcrypt and hibernate key disclosure

[Milan Broz]

On 01/11/2011 05:35 PM, Richard wrote:
> On Tue, Jan 11, 2011 at 11:31:37AM +0100, Milan Broz wrote:

>> What is not safe is suspend to RAM. Maybe someone should start to use
>> luksSuspend to at least clear encryption key from memory but it is not
>> as easy implement as it seems:)
> 
> surely luksSuspend would make it safer but still complete RAM would be left
> unprotected which can be a lot of information. Did anyone look inot encrypting
> RAM before suspend?

That's not probably easily done and I think it is not worth to try - simple
use hibernation here.
(Of course if there is support in hw it is easy.)

> As it is now it is also not trivialy broken - getting the filesystems would 
> involve breaking screen saver locking, breaking in through network or other 
> interfaces or freezing the computer to retrieve and examine ramchips.

Just reset and boot memory dumper, chances that you get the encryption key are
very high (memory dumper uses just few pages and BIOSes do not wipes memory
during reboot). It is quite easy.
(of course you can disable USB/PXE/CDROM boot etc but in principle it is still problem.)

> seems dm or something else is slow enough that id does not matter at all.

LVM (linear mapping) will not slow down it, with comparison to encryption
time for remapping is completely insignificant.
If you have some strange numbers, report a bug and add your configuration description,
but I know how the kernel works - there is really nothing complex on this path.
Usually problem is with some misaligned devices - but this can happen even with partitions.

Milan