Dmcrypt and hibernate key disclosure
-----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-----
Quoted 5 lines · Aaron Lewis
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 ?
Quoted 7 lines
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
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
Quoted 3 lines · Arno Wagner
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. :-)
Quoted 3 lines
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.
Quoted 11 lines · Bryan Kadzban
Quoted 3 lines · Arno Wagner
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/resumefile, and I would *guess* that the device node can be a device-mapper child (such as dm-crypt or LVM would create).
Quoted 5 lines
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.
Quoted 2 lines
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.
Quoted 8 lines
Quoted 3 lines
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.
Quoted 2 lines
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
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 10 lines · Bryan Kadzban
Quoted 3 lines · Arno Wagner
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/resumefile, 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 :)
Quoted 2 lines
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.
Quoted 8 lines
Quoted 3 lines
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-----
Quoted 11 lines · Arno Wagner
Quoted 6 lines · Bryan Kadzban
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.
Quoted 10 lines
Quoted 6 lines
Quoted 2 lines
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/resumereplaces 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.)
Quoted 3 lines
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. :-)
Quoted 4 lines
Quoted 2 lines
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.
Quoted 3 lines
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.)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 8 lines · Bryan Kadzban
Quoted 7 lines · Arno Wagner
Quoted 6 lines
Quoted 2 lines
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.
Quoted 8 lines
Quoted 3 lines
Seems I misunderstood the respective kernel parameter then. Or it is an alternative to the mechanism you describe. So writing to
/sys/power/resumereplaces 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-----
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
Quoted 2 lines
Quoted 1 line · Arno Wagner
On Thu, Jan 06, 2011 at 08:08:55PM -0800, Bryan Kadzban wrote:
[...]
Quoted 19 lines
Quoted 3 lines
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
[email protected]
http://www.saout.de/mailman/listinfo/dm-crypt
Quoted 6 lines · Aaron Lewis
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
Quoted 11 lines · Richard
Quoted 6 lines · Aaron Lewis
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
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 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
Quoted 13 lines · Arno Wagner
Quoted 11 lines · Richard
Quoted 6 lines · Aaron Lewis
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.
Quoted 6 lines
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
Quoted 10 lines · Milan Broz
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.
Quoted 3 lines
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.
Quoted 4 lines
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
Quoted 9 lines · Richard
Quoted 3 lines · Milan Broz
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.)
Quoted 3 lines
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.)
Quoted 1 line
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