SecureSuspendToRam: Difference between revisions

From Noisebridge
Jump to navigation Jump to search
No edit summary
Line 1: Line 1:
{{Template:OutOfDate}}
== Introduction ==
== Introduction ==



Revision as of 23:33, 7 February 2011

Oldcomputer.png
This article seems to be really old or very much out of date, and may contain wrong info.


Wiki-tip: You can check its history to see when it was last edited.

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 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.

Implementation details

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