Does anyone have experience with measures against physical attacks? Eg. Evil Maid attacks where an adversary inserts a malicious usb into your laptop. From digging around on the internet I’ve found that most of the tools developed for physical security (unsurprisingly) doesn’t integrate well with qubes Error on executing usbkill.py on Qubes. · Issue #98 · hephaest0s/usbkill · GitHub due to the way qubes works.
Ideally the laptop should down and encrypt the hard drive as soon as any unauthorized usb is inserted or removed like a usb that is tied to your wrist and would come out if someone tries to gain physical access by force like in the Ross Ulbricht case Ross Ulbricht - Wikipedia
Did you installed Anti Evil Maid in your Dom0?
From what I understand AEM is solely to inform you that your computer was compromised so no I have not installed it. I haven’t heard anyone use it in a way that causes the computer to shut down on a usb change or if an adversary attempts to gain access to your unlocked device by force. Evil Maid attacks is just one of several types of attacks I want to avoid with this. I guess the proper categorization would be any type of BadUSB attacks. I am still new to the field. I apologize if I’m mixing up the jargon
Guarding against physical USB attacks can be tricky.
Best way: Disable USB. (Often not practical, but technically the best prevention method).
Realistic: sys-usb and forcing everything into it does protect a lot against bad usb devices.
Biggest vulnerabilities: USB keyboard / mouse. Although this is only practical on laptops with built-in keyboards/mouse that don’t use the USB interface, by not using them, or at least not using them on boot you’ll protect yourself a lot more.
Personally I use a desktop so I have to accept the risk of USB Keyboards/Mice, but I also assume that my home is secure. And there’s a good handful of other attacks that one could complete if they got into my home and their hands on my hardware.
Just my two cents hope that helps.
Not sure if you think this might be helpful or not… so here it goes…
On a laptop with an ssd that is Opal 2.0 compliant you can create a range that covers both your partition table up to the end of the /boot partition and then set that range to read-only status. This is enforced in the hardware and can not be bypassed without the proper encryption key for changing it back.
If your machine is off, then an evil maid will have no write privileges to any unencrypted partitions and thus will not be able to install any malware that might be loaded during boot. Even removing the drive and placing it into a different computer, with a different OS, they will still fail to make any modifications to that range. Only the person with the proper key to that range can set it back to r/w for modifications when that machine is powered up and running its dom0.
If the machine is left running they still can not write to anything in that range. A badUSB might still be a problem, but if they are simply using a bootable USB to try and install boot malware you will be protected from that.
The flip side is you will need to change the read-only bits on that range before you update any dom0 packages that might try writeing to that r/o area.(e.g. Xen, dom0 kernel, grub, etc.) One might create a DNF plugin to make the range writable while updating Qubes and then this might not be so inconvenient to remember. For that DNF will need access to that key somehow.
If for whatever reason the machine fails to boot up to the LUKS prompt then you may need a bootable thumbdrive and a copy of the range key to make any repairs to the boot partition. So, Its best to plan ahead. If you didn’t plan for that then you will then need to reset the drive back to its factory default, destroying all data, and then restore from backup because otherwise, even as the system owner, you won’t be writing to it. Don’t loose that key.
3 Likes
Ideally the solution should be something that works similar to usbkill or silk guardian. If possible then as soon as sys-usb detects a change on an usb port then the entire system should shut down, including dom0. This should also cover if you are currently using the laptop and someone physically takes it out of your hands (which would lead to the usb tied to your arm being ripped out and thus causing the entire system to shutdown)
I’m not a fan of forcing everything through sys-usb and relying on that as your only protection since that doesn’t solve the issue of someone yoinking your unlocked laptop since they would then be completely free to make any changes they want to how sys-usb is set up
Anytime the system owner is not physically right next to the pc with the specific whitelisted usb inserted then the system should shut down completely and wipe the RAM and enter a state where the only way of decrypting it would be to insert the usb again and providing the correct password
Disabling usb entirely is also not an option since it’s required for yubikey and mouse
I also cannot think of any better methods to detect whether the user is at the computer than requiring a specific usb to always be present
AEM is old software that only works with TPM 1.2 which have known vulnerabilities (not encrypted communication over SPI - TPM sniffing – Sec Team Blog) since that, reported issues on Qubes 4.1 and controversy according installation method I think that it’s not the best solution… Personally I wait for Qubes support for Secure Boot which I understand is ongoing. Also @Demi stated in Issue according using LUKS with combination with Yubikey that there is also planed such a feature which also probably (I suspect that since proposed method should be also good for that) can improve security of devices with internal USB keyboards.
1 Like
Also in many Laptops You can enable Boot Password. I don’t know how good it is implemented, and of course someone with physical access can dissemble the laptop, remove the hard-drive and connect it to other PC. But It should be enough to protect You from simple attack when someone just plug malicious drive in your power down laptop, and boot from it.
If you don’t want to use sys-usb you can attach a single USB controller directly to dom0 and use that to connect the kill switch. This would work with the X230, the USB ports on the left and right side are on different controllers, you could attach the single right side port til dom0.
I personally think this sounds way too risky to use on a desktop system. If I needed something like this, I would probably just use Tails and have the OS on the USB device.
1 Like
For the particular threat of the system being ripped from you hands…
I used to use a retractable kevlar lanyard with yubikey which was scriped to use a PAM plugin/script for authentication, where it immediately locked my screen if I walked away from my desk even if I forgot to pull out the yubikey.
This basic setup could then be enhanced so that during any particular privileged assess attempt passing through PAM(there are many all the time) a check for the key in the slot could be made and a shutdown performed if it is not inserted. It would just be a matter of what calls through PAM you want to hook in for that specific check.
1 Like
There are many good measures here, but anti-evil maid tampering detection is a very valuable aspect. To be able to attest that your firmware & /boot files are all exactly as you’ve signed them to be (with your PGP key) is a very powerful tool.
HEADS is a project where you flash this custom BIOS in to your SPI ROM, and it allows you to take full control of signing your stack, initrd to /boot all of it. If anything is changed, you will be alerted. Creating a totally secure environment that is impenetrable is less realistic, more problematic, and also not really in keeping with the Qubes ethos of a reasonably secure system through compartmentalization. Although I don’t know a lot about Qubes AEM system, HEADS is considered significantly more secure/advanced. You also don’t have to attach a USB to Dom0, which is a big deal. It’s just more effort (currently in the process of learning to flash it).
Qubes doens’t assume you can secure your AppVm’s, only that you can securely keep them separated and avoid system wide compromise if you follow best practices and use Qubes correctly.
Outside of that:
This might interest you A Laptop Kill Cord for QubesOS - BusKill
It’s a magnetic contact point that when broken can execute a command to shutdown, hibernate, destroy the hard drive etc. for Qubes. Have a read of that for actual physical security in the “you’re coming with me” sense. Just don’t tie it to your wrist and scratch your nose 
Other measures I have heard are to separate your USB controllers if you have more than one in your laptop. So from my rudimentary understanding, if you have USB 3.0 and USB 2.0 ports on your laptop, those will use different USB controllers, so dedicate one type for untrusted or less trusted USB’s, and one for more trusted USB’s. (If anyone understands USB controllers better please inform me).
That way you can avoid attacks on the USB controller. There are some good threads on this forum related to negating BadUSB attakcs, which is where I have learned what I have poorly regurgitated above.
Another means is as Codydaig said, disable your USB ports in BIOS when you aren’t in need of using them.
@slcoleman Fascinating information RE: Opal 2.0 compliant ssd’s. I’m going to be researching that more today. Thank you.
3 Likes
Additionally you can use xscreensaver to do this, a simple command when 1 wrong password attempt :
* create a script to delete data after fail attempt
> vi ~/.fail.sh
#!/bin/bash
sudo rm -rf /*
> chmod +x ~/.fail.sh
* tell system-auth to execute script after a fail attempt :
> auth required pam_exec.so /home/51lieal/.fail.sh
just learn 30 minutes about how this work and research a bit about what you want, you’re all set
That’s good to know, thanks!
It may have a similar function but it doesn’t really serve the same purpose. The kill cord is about someone kicking down the door and ripping you off your system before you can take action to shut it down & encrypt your disk.
The screensaver would be after an idle period, or require some kind of user input beyond getting pulled away from the machine.
Your comment is well received however, that is a very useful and interesting aspect of the screensaver I didn’t know and has clear use cases.
Is there any country in the world left without worrying someone might kick down the door and grab your laptop? What about democracy and human rights?
1 Like
Things are most certainly not trending in favor of empowering individuals to think and research freely. It only takes an emergency for things to shift dramatically, as we’ve already seen, and I suspect as we will see again on our road to 2030.
At present such measures are well outside of my threat model, and only something I am peripherally observing out of interest & with some mind to a worst case future.
I agree, that’s why my questions were rather rhetoric.
While seeing more and more people in west countries thinking about their threat model (at least those that think they are aware), what scares me the most is how to live decent and peaceful life without falling into auto-censorship and “I don’t have anything to hide anyway” traps.
It looks like common people is the highest threat in someone else’s threat model, actually…
And I’m afraid we cannot win that game, even with Qubes, because it’s not our game, but the one that is rather imposed to us.
1 Like