"Why BusKill?
BusKill is a Dead Man Switch triggered when a magnetic breakaway is tripped, severing a USB connection. "
Has articles about qubes as well:
Sound an interesting project.
@maltfield nice stuff 
2 Likes
Hey @TNT_BOM_BOM, thanks 
Here’s the explainer video, which I think unpacks the idea of the cable better than words can convey
We’re just finishing the first production run thanks to a successful crowdfunding campaign on crowdsupply, and the cables should be shipping to backers in the next 1-2 months.
Of course, you can also make your own cable (it’s all open-source)
Right now the cross-platform GUI app just locks your screen, but on Linux you can make it shutdown or self-destruct (wipe your LUKS header) in just a few seconds (see the guides linked-to above). It takes 5.2 seconds from cable-separation to shutdown in Ubuntu
Let me know if you have any questions about BusKill
2 Likes
RAM wipe on shutdown to defeat a cold boot attack seems to be a related feature.
Does BusKill already implement RAM wipe on shutdown? Does the dracut module cold-boot-attack-defense (by security-misc) seem interesting / sanely implemented to you?
Related:
Is RAM Wipe possible inside Whonix? Cold Boot Attack Defense
1 Like
I guess that is:
Will be posting there.
1 Like
I will be interpreting this forum post as a development todo ticket to implement a:
- panic shutdown script
- panic button
- panic shutdown start menu entry
- panic shutdown on user action such as removal of some USB device (similar to BusKill) / USB kill cord
Sorry for the super-delayed response.
Does BusKill already implement RAM wipe on shutdown?
We just added a soft-shutdown to the app (currently CLI-only) in our latest release (v0.6.0). It does not include a RAM wipe.
Sorry, but I generally do not consider RAM wiping our highest-priority request atm. To quote from our article LUKS Header Shredder (BusKill Self-Destruct Trigger)
As far as I know, there is no evidence to suggest that a single political prisoner was caught or convicted by an opressive regime due to the results of a cold boot attack. At the time of writing, cold boot attacks exist in a purely academic realm.
Nevertheless, a welcome improvement to this BusKill self-destruct trigger would be to add a step to overwrite the RAM prior to shutdown. But such an implementation should be very carefully tested to ensure that it actually functions as intended across all linux distros–and that it doesn’t prevent the machine from being able to actually power-off. Otherwise, a poor implementation could actually make your self-destruct sequence less secure.
If your risk model is high enough to require defenses against cold boot attacks, you should thoroughly consider switching to TAILS–which has a well-tested implementation of RAM shredding.
Or you could just use an ultrabook with RAM soldered in-place. Or get yourself some superglue.
If you are aware of a case where cold boots were actually used IRL against a victim, please do let me know and I’ll prioritize it…
- panic shutdown on user action such as removal of some USB device (similar to BusKill) / USB kill cord
@Patrick Is there any reason you don’t just use the BusKill app? Are there any features that would be required for you to consider adding it to Whonix?
btw, one of our users recently submitted an RFP on Debian:
But it would be pretty cool to see the BusKill app come OOTB in Whonix. Please let me know what you’d like to see to make that happen
1 Like
Might be more suitable for the host operating system. That means Whonix-Host and/or Kicksecure.
Inclusion into packages.debian.org.
RAM wipe is very hard to properly implement. We’ve been working on this too but it stalled foor now. Initramfs has an initrd but what’s needed to wipe RAM on shutdown is an exitrd. Dracut has both an initrd and supports exitrd but it doesn’t properly unmount the luks root disk on shutdown. Therefore a dracut RAM wipe module that runs at very end of the boot process cannot fully wipe the RAM either. If you’re ready / wish to discuss this further lets move to the Whonix RAM wipe development forum thread, your github, dracut github or so at any time.
related:
If your risk model is high enough to require defenses against cold boot attacks, you should thoroughly consider switching to TAILS–which has a well-tested implementation of RAM shredding.
I am afraid this isn’t applicable or easily portable to other non-Tails Linux distributions. Tails doesn’t encrypt the root disk. They don’t need to. The contents of the root disk are the same for all users (except because in rare cases of customized self-made builds). Tails encrypts only the persistent storage. I didn’t check if that encryption is is properly unmounted at shutdown but might be easier. Unmounting an lvm, luks encrypted root disk is much harder.