wiki/src/contribute/design/memory_erasure.mdwn

   1 [[!meta title="Memory erasure"]]
   2
   3 In order to protect against memory recovery such as cold boot attack,
   4 the system RAM is overwritten when Tails is being shutdown or when the
   5 boot medium is physically removed.
   6
   7 #### The big picture
   8
   9 The previous implementation of the Tails memory erasure feature
  10 suffered from flaws that were demonstrated by [[external
  11 audit|security/audits/Blackhat_De-Anonymizing_Live_CDs]]. In short, it
  12 only erased free memory and let data in the aufs read-write branch in
  13 recoverable state.
  14
  15 In order to erase the biggest possible part of the system memory, the
  16 hereby described new implementation, shipped in Tails 0.7, runs in a
  17 fresh environment provided by a newly started Linux kernel. This way,
  18 a given part of the memory either is *used* by the memory erasure
  19 process itself or it is considered as free and thus *erased* by this
  20 process; in any case, it is at least overwritten once.
  21
  22 #### initramfs tweaks
  23
  24 The Linux kernel and initramfs used to erase the memory are the same
  25 as the ones normally used by a Tails system... that actually includes
  26 some bits of code dedicated to this mission.
  27
  28 An initramfs-tools hook includes the necessary files in the initramfs
  29 at build time. A runtime init-premount script either does nothing, or
  30 erases memory before shutting down or rebooting the system; its
  31 behaviour depends on the `sdmem` kernel command line parameter value.
  32 Additionally, the `sdmemopts` kernel command line parameter allows
  33 fine tuning the options passed to the `sdmem` program.
  34
  35 - [[!tails_gitweb config/chroot_local-includes/usr/share/initramfs-tools/hooks/sdmem]]
  36 - [[!tails_gitweb config/chroot_local-includes/usr/share/initramfs-tools/scripts/init-premount/sdmem]]
  37
  38 These `sdmem` and `sdmemopts` are appended to the fresh kernel command
  39 line parameters, when memory erasure is triggered, by the
  40 `tails-kexec` initscript that is itself parameterized by the usual,
  41 slightly customized, kexec-tools configuration file.
  42
  43 - [[!tails_gitweb config/chroot_local-includes/etc/default/kexec]]
  44 - [[!tails_gitweb config/chroot_local-includes/etc/init.d/tails-kexec]]
  45
  46 #### Actual memory erasure process
  47
  48 The software that performs the actual memory erasure is sdmem, which
  49 is part of the [secure-delete](http://www.thc.org/) package. sdmem is
  50 called using the `-v` (verbose mode) option to give feedback to the
  51 user, as well as the `-llf` options: memory is only overwritten once
  52 with zeros; this is the fastest available mode, and is enough to
  53 protect against every memory forensics attack we know of.
  54
  55 - [[!tails_gitweb config/chroot_local-includes/etc/default/kexec]]
  56
  57 #### Triggers
  58
  59 Different kinds of events trigger the memory erasure process. All lead
  60 to run the `tails-kexec` initscript.
  61
  62 **First, the memory erasure process is triggered at the end of a normal
  63 shutdown/reboot sequence.** This is implemented by slightly modifying
  64 the System V initscripts shipped by the `kexec-tools` Debian package:
  65 the `kexec-load` initscript, that normally only runs at reboot time,
  66 is enabled to run at shutdown time as well. A custom `tails-kexec`
  67 initscript replaces the `kexec` one in order to support the case when
  68 the boot medium is not available anymore at the time this script runs;
  69 it also provides an improved user interface more suitable for Tails
  70 target users needs. Finally, the standard Debian `halt` and `reboot`
  71 initscripts are taken over by having the `tails-kexec` initscript run
  72 before they have a chance to be run (implemented with `Required-Stop`
  73 in the LSB headers).
  74
  75 - [[!tails_gitweb config/chroot_local-patches/run_kexec-load_on_halt.diff]]
  76 - [[!tails_gitweb config/chroot_local-includes/etc/init.d/tails-kexec]]
  77 - [[!tails_gitweb config/chroot_local-hooks/52-update-rc.d]]
  78
  79 **Second, the memory erasure process is triggered when the boot medium
  80 is physically removed during runtime (USB boot medium is unplugged or
  81 boot CD is ejected).** This is implemented by a custom `udev-watchdog`
  82 program monitors the boot medium; it's run by a wrapper, started at
  83 boot time, that brutally invokes the memory erasure process, bypassing
  84 other system shutdown scripts, when this medium happens to be
  85 physically removed.
  86
  87 - [[!tails_gitweb config/chroot_local-includes/usr/local/sbin/udev-watchdog-wrapper]]
  88 - [[!tails_gitweb config/chroot_local-includes/usr/src/udev-watchdog.c]]
  89 - [[!tails_gitweb config/chroot_local-hooks/52-udev-watchdog]]
  90 - [[!tails_gitweb config/chroot_local-includes/etc/init.d/tails-sdmem-on-media-removal]]
  91 - [[!tails_gitweb config/chroot_local-hooks/52-update-rc.d]]
  92
  93 #### Making sure needed files are available
  94
  95 The memlockd daemon, appropriately configured, ensures every file
  96 needed by the memory erasure process is locked into memory from boot
  97 to memory erasure time.
  98
  99 - [[!debpts memlockd]]
 100 - [[!tails_gitweb config/chroot_local-includes/etc/memlockd.cfg]]
 101
 102 #### User interface
 103
 104 Since this process can take a while the user can leave the computer
 105 and let it finish on its own after removing the boot medium, or simply
 106 turn it off if he or she is not worried about this attack: if Tails
 107 was booted from a CD it is ejected before the memory wiping is
 108 started, and if it was booted from a USB drive it can be removed as
 109 soon as the memory wiping has been started.
 110
 111 A short but visible message, displayed for a few seconds, explains the
 112 user what is going to happen.
 113
 114 - [[!tails_gitweb config/chroot_local-includes/etc/init.d/tails-kexec]]