linux-kernel - Re: [TuxOnIce-devel] RFC: Suspend-to-ram cold boot protection by encrypting page cache

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 02 Jul 2009 07:14:14 +0200
From:	U Kuehn <ukuehn@....org>
To:	Jeremy Maitin-Shepard <jeremy@...emyms.com>
CC:	"Rafael J. Wysocki" <rjw@...k.pl>,
	tuxonice-devel@...ts.tuxonice.net, linux-kernel@...r.kernel.org
Subject: Re: [TuxOnIce-devel] RFC: Suspend-to-ram cold boot protection by
 encrypting page cache

Hi Jeremy,

Jeremy Maitin-Shepard wrote:
> "Rafael J. Wysocki" <rjw@...k.pl> writes:
> 
>> What is the particular attach scenario you'd like to prevent
> 
> The standard cold boot attack, which basically allows the attacker to
> obtain a copy of the data in RAM.  System is powered on.  RAM is
> optionally cooled.  RAM is then quickly removed from the original
> machine, placed in another machine, and copied.  See
> http://en.wikipedia.org/wiki/Cold_boot_attack
> 
> The wikipedia page links to this Youtube video that nicely demonstrates
> the attack:
> 
> http://www.youtube.com/watch?v=JDaicPIgn9U
> 
> The cooling helps to preserve the data for longer, but is not always
> even necessary.  Special hardware is not even needed.  Depending on
> whether the BIOS clears the memory during the POST, it might also be
> possible to do the attack on the same machine (i.e. without having to
> move the RAM into another machine) by rebooting it and booting from
> e.g. a CD-ROM or USB drive.
> 

This attack scenario essentially attacks the standard assumption that
memory contents is _immediately_ lost once power to the RAM is removed.

Essentially, the same problems arise whether the machine is suspended to
RAM or is just left on, with some screen saver or something similar in
place. So if the machine is snatched out of your hands it is still
running...

That's the reason why I personally prefer suspend-to-disk over
suspend-to-ram. Of course, if you have encryption in place, e.g. for you
home partition, it is necessary that the swap space is encrypted so that
the system state is protected during suspend-to-disk.

The approach to encrypt the memory contents during suspend-to-ram seems
to be a very fundamental change in the kernel, in order to protect
against a very specific attack. And unfortunately it helps only against
an cold-boot attack that happens during suspend-to-ram. It does not
protect against the attack taking place when the machine is just "on".

Just my 2c.

With best regards,
Ulrich

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/