"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 
3 Likes
Hey @nurmagoz, 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
3 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.
Please let me know what you’d like to see to make that happen
Inclusion into packages.debian.org.
Update: Packaging work to add BusKill to the Debian repos is complete. The new buskill package has been submitted to Debian. We hope it will be available in stable with the release of Debian 12 (bookworm).
Might be more suitable for the host operating system. That means Whonix-Host and/or Kicksecure.
Yeah, I started thinking about how to test this today. I guess it could run in a whonix workstation, but that probably doesn’t make much sense – especially in QubesOS. I guess I’ll look into Whonix-Host and/or Kicksecure. I assume both are Debian-based.
2 Likes
2 Likes
@Patrick Buskill is now in the stable Debian repos and can be installed in Debian via Apt
sudo apt-get install buskill
Can you please consider adding buskill to be installed by default in the next Whonix release?
What’s the benefit of having buskill installed by default in a VM?
Would be great for Whonix-Host, but I too do not see the benefits of installing the package in a VM. BusKill is available for most host operating systems so why not just install it there? Also probably shouldn’t give users a false sense of security; if the host is compromised, isn’t that basically game over?
Aside: I really like the design though. I wrote a little killswitch script for my host that monitors the live USB, but using a magnetic connection is clearly the way to go. I’d only suggest offering a wristband version because, in a worst case scenario, the first thing you’re expected to do is put your hands up.