SecureSuspendToRam: Difference between revisions
(Initial edit) |
No edit summary |
||
| 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. | |||
Revision as of 21:59, 18 May 2009
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 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).
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.