Avoiding all sidelines, keeping this simple, for my understanding and for the record and please correct me if I am wrong… Summary:
"cryptsetup close" of root device during shutdownis already implemented.
"cryptsetup close" of root device during shutdownis already implemented.iff your initrd/distro of choice do so. For the root disk it doesn’t matter what systemd does, it matters what the initrd/distro do. hence ping the maintainers of those.
Debian feature request:
Wipe LUKS Disk Encryption Key for Root Disk from RAM during Shutdown to defeat Cold Boot Attacks from Initial Ramdisk (initramfs-tools or dracut)
Control: severity -1 wishlist
Control: reassign -1 cryptsetup-initramfs
Control: block -1 by 778849Hi,
AFAICT dracut has dracut-shutdown(8) which you can extend at will, or
convince the maintainer to ship the required logic for everyone.
However Debian’s default initramfs, namely initramfs-tools(7) currently
has no interface to hook into at shutdown, and init doesn’t even hand
execution over to the initramfs during the shutdown phase (#778849).
When such an interface is available we can ship shutdown scripts into
cryptsetup-initramfs.cheers
--
Guilhem.
related:
Support restoring initrd on shutdown and pivoting into it (#778849)
Maybe a good reason for replacing initramfs-tools with dracut.
Debian dracut feature request:
Wipe LUKS Disk Encryption Key for Root Disk from RAM during Shutdown to defeat Cold Boot Attacks from Dracut Initramfs
dracut upstream feature request:
dracut upstream pull request:
Review welcome.
- https://github.com/Kicksecure/security-misc/tree/master/usr/lib/dracut/modules.d/40cold-boot-attack-defense
- https://github.com/Kicksecure/security-misc/blob/master/usr/lib/dracut/modules.d/40cold-boot-attack-defense/module-setup.sh
- https://github.com/Kicksecure/security-misc/blob/master/usr/lib/dracut/modules.d/40cold-boot-attack-defense/wipe-ram-needshutdown.sh
- https://github.com/Kicksecure/security-misc/blob/master/usr/lib/dracut/modules.d/40cold-boot-attack-defense/wipe-ram.sh
Could you please test the sdmem(1) — secure-delete — Debian bullseye — Debian Manpages command. Check the timing. How long the command requires to complete. Because the same time will be required on every reboot / shutdown.
Note: There’s a chance it might freeze a VM or host operating system. It didn’t happen to me yet but better to have this in mind.
Installation:
sudo apt update
sudo apt install secure-delete time
Disabling swap is required. Otherwise smem would fill up all RAM and the system highly likely to permanently freeze.
sudo swapoff --all
To verify that swap is off:
sudo swapon --show ; echo $?
Expected output:
0
Built-in help:
sudo sdmem -h
Default mode:
time sudo sdmem
Verbose mode:
time sudo sdmem -v
Probably better because it shows some progress.
For just a single pass of RAM wipe with zeros:
- without verbose mode:
-
time sudo sdmem -l -l
-
- with verbose mode:
-
time sudo sdmem -l -l -v
-
The time command is optional. Can be dropped. But useful here to measure how long it takes.
Default mode does, quote:
27 passes with special values defined by Peter Gutmann.
Not sure that is really necessary because if I remember right, Peter Gutmann was about hard drives, not RAM. Is there any research how many passes RAM wipe requires?
Should RAM wipe be skipped inside VMs for faster reboot / shutdown times? I am not sure about the dynamics of RAM wipe in VMs. In worst case, the VM might start use swap file on the host operating system. Therefore I tend to say RAM wipe should be skipped if a VM is detected.
secure-delete* package name in debian (sdmem: secure-delete memory)
Wipe mode is secure (38 special passes)
Using /dev/urandom for random input.
real 1m40.819s
user 0m0.072s
sys 0m0.163s
Wipe mode is insecure (one pass with 0x00)
real 0m0.503s
user 0m0.008s
sys 0m0.089s
Happen to me, i opened xfce-terminal and start moving it right and left until the screen freezed permanently (play for less than 3 minutes with anything like browse some stuff and open close terminal…).
Huge progress has been made.
Implemented by dracut module cold-boot-attack-defense (by security-misc).
Will in near future be available for Kicksecure hosts. Should be easy to port to other Linux distributions.
See design documentation, review welcome:
More documentation, call for testers coming in near future.
Future design (additional kexec based RAM wipe) has been elaborated:
https://www.kicksecure.com/wiki/Dev/RAM_Wipe#Future_Design
I’ll try to assign this task to implement also the future design to a contractor. Hopefully there will be a good news soon.
is in process.