SecureSuspendToRam - Revision history

Fnord: Undo revision 45954 by IgAZwmawpK (talk)

2015-01-01T00:28:36Z

Undo revision 45954 by IgAZwmawpK (talk)

← Older revision		Revision as of 17:28, 31 December 2014
Line 1:		Line 1:
	{{Template:OutOfDate}}		{{Template:OutOfDate}}
	~~[[File:Past1.jpg]]~~
	~~[[File:Past2.jpg]]~~
	~~[[File:Present1.jpg]]~~

	== Introduction ==		== Introduction ==

IgAZwmawpK at 21:16, 30 December 2014

2014-12-30T21:16:03Z

← Older revision		Revision as of 14:16, 30 December 2014
Line 1:		Line 1:
	{{Template:OutOfDate}}		{{Template:OutOfDate}}
			[[File:Past1.jpg]]
			[[File:Past2.jpg]]
			[[File:Present1.jpg]]

	== Introduction ==		== Introduction ==

AlSweigart at 06:33, 8 February 2011

2011-02-08T06:33:18Z

← Older revision		Revision as of 23:33, 7 February 2011
Line 1:		Line 1:
			{{Template:OutOfDate}}

	== Introduction ==		== Introduction ==

Ioerror: /* Implementation goals */

2009-05-19T05:19:15Z

Implementation goals

← Older revision		Revision as of 22:19, 18 May 2009
Line 13:		Line 13:
	* We intend to create a reasonable suspend to ram mode that can resist effective Cold Boot Attacks.		* We intend to create a reasonable suspend to ram mode that can resist effective Cold Boot Attacks.
	* We intend to implement this with the current Linux kernel.		* We intend to implement this with the current Linux kernel.
	* We intend to have nothing interesting in memory.		* We intend to have nothing interesting in memory other than a shim to decrypt the memory and the encrypted memory itself.
	* We do not intend to have the system have any sort of integrity proof, this is protection against forensic analysis and other types of theft.		* We do not intend to have the system have any sort of integrity proof, this is protection against forensic analysis and other types of theft.

Ioerror at 05:17, 19 May 2009

2009-05-19T05:17:32Z

← Older revision		Revision as of 22:17, 18 May 2009
Line 11:		Line 11:
	== Implementation goals ==		== Implementation goals ==

	We intend to create a reasonable suspend to ram mode that can resist effective Cold Boot Attacks.		* We intend to create a reasonable suspend to ram mode that can resist effective Cold Boot Attacks.
	We intend to implement this with the current Linux kernel.		* We intend to implement this with the current Linux kernel.
	We intend to have nothing interesting in memory.		* We intend to have nothing interesting in memory.
	We do not intend to have the system have any sort of integrity proof, this is protection against forensic analysis and other types of theft.		* We do not intend to have the system have any sort of integrity proof, this is protection against forensic analysis and other types of theft.

			== Implementation details ==

			* Current work includes understanding how ACPI suspend works in the most current Linux Kernel

Ioerror at 04:59, 19 May 2009

2009-05-19T04:59:21Z

← Older revision		Revision as of 21:59, 18 May 2009
Line 1:		Line 1:
			== Introduction ==

	Currently in Gnu/Linux it is not possible to securely suspend a computer (such as a laptop) to RAM. When we say that suspend is not secure, we mean that it is possibly to read out meaningful data in various ways. This readout of memory may happen after the suspend state has been initiated or upon un-suspending. The canonical example of this type of attack is the [http://en.wikipedia.org/wiki/Cold_boot_attack Cold Boot Attack].		Currently in Gnu/Linux it is not possible to securely suspend a computer (such as a laptop) to RAM. When we say that suspend is not secure, we mean that it is possibly to read out meaningful data in various ways. This readout of memory may happen after the suspend state has been initiated or upon un-suspending. The canonical example of this type of attack is the [http://en.wikipedia.org/wiki/Cold_boot_attack Cold Boot Attack].

Line 6:		Line 8:

	Generally, we'd like to have the entire kernel (and thus not need to know which parts have say, key bits) possibly excepting the ACPI code, encrypted by the suspend process. Additionally, we'd like it to have similar security properties as the suspend to disk methods currently in use (generally with LUKS).		Generally, we'd like to have the entire kernel (and thus not need to know which parts have say, key bits) possibly excepting the ACPI code, encrypted by the suspend process. Additionally, we'd like it to have similar security properties as the suspend to disk methods currently in use (generally with LUKS).

			== Implementation goals ==

			We intend to create a reasonable suspend to ram mode that can resist effective Cold Boot Attacks.
			We intend to implement this with the current Linux kernel.
			We intend to have nothing interesting in memory.
			We do not intend to have the system have any sort of integrity proof, this is protection against forensic analysis and other types of theft.

Ioerror: Initial edit

2009-05-19T04:55:42Z

Initial edit

New page

Currently in Gnu/Linux it is not possible to securely suspend a computer (such as a laptop) to RAM. When we say that suspend is not secure, we mean that it is possibly to read out meaningful data in various ways. This readout of memory may happen after the suspend state has been initiated or upon un-suspending. The canonical example of this type of attack is the [http://en.wikipedia.org/wiki/Cold_boot_attack Cold Boot Attack].

It is currently possible to suspend to disk in a secure manner. Generally this is accomplished by writing out the hibernate image into an encrypted partition or by prompting for a passphrase. Without the ability to unlock the disk or unencrypt the file, it is not possible to resume the machine.

We believe that it is possible to bring about similar protection with increased functionality with an encrypted suspend to RAM implementation.

Generally, we'd like to have the entire kernel (and thus not need to know which parts have say, key bits) possibly excepting the ACPI code, encrypted by the suspend process. Additionally, we'd like it to have similar security properties as the suspend to disk methods currently in use (generally with LUKS).