who know?
i’ll find some broken laptop and test that (i prefer non-electrical solution since it has less weakness than one)
Do not be too paranoid bro 
For my threat model I am not a high value target at all, and I research Qubes OS as hobby. So I do not worry someone will do some highly customized attack on me.
Actually you already made a lot of assumptions like adversary knew you are using Qubes, and they are already equipped with Xen zeroday exploit to attack so other defenses are pointless. Actually maybe 50% time of an attack is spent on determining attack surface.
Just think like an intruder. For example you are a government employee, and you have seen me sharing some sensitive document on a forum. You would like to silence me, what will you do? You will try to contact the forum ask them to put a trojan on their website, and try to hack me and leak my location. You will have no idea that I am using Qubes at all. You will first try to crack my tor browser with some zero day or send phishing email to get a small trojan inside my OS. At this stage you only know I am using Linux, so you will send a very generic small trojan to my OS first. That small trojan will phone home to download the big trojan for further surveillance if it runs successfully. Then you will start to manually sending commands to the big trojan to find something interesting, and you review all the info the big trojan sent back. After all these things you finally determined I am using Qubes + whonix, then you opened the exploit arsenal hope to find some whonix/Xen exploit to screw me. All these things take time because Qubes OS is not like iPhone that have a quite certain attack surface and large user base so an exploit solution is already in place. At last you found the correct exploit and my dispvm is still online. You push those exploits to the trojan for execution and i am screwed. Restrictive security policy and sandbox will definitely slowdown even completely stop you at the initial stage, also all the security measures increase the difficult for you to collect intel. This chain of attack requires a lot of money and luck to really work, and I definitely think put more barriers will increase the difficulty and uncertainty. A well designed in-VM security architecture will definitely help those people who are really at risk.
2 Likes
@ppc very helpful links thanks!
Hadn’t considered how noticeable measures (ie glitter polish) might
attract attention. Will now add little wax to unused ports too.
Any other physical tamper evident methods? (outside or inside)
IIUC @zphaskqjrm you’ve created a custom chassis intrusion system for
your laptop. That’s impressive (to me, someone without hardware skills).
How/when does the chip wipe the keys?
Any details about your challenge response system (hardware and/or
software), that you’re comfortable sharing, would be most appreciated.
i’m still finding more
(i just found a broken laptop that chewing gum is in everywhere, however i don’t consider that effective way)
it wipe the key when the button is not pressed using some code in the soc (pi pico or arduino)
it wipe the key when the button is not pressed using some code in the
soc (pi pico or arduino)
how?
idk
Booting into a minimal distro first is also great as one can fo some magic configurations that need to be done once at boot time like:
HWCLOCK: ask ntp or gps receiver for time, do hwclock --systohc and set the rtc for the qubes session (some days of uptime dont produce noticeable drift on a good xtal based rtc)
CPU microcode-update
RANDOM: initialize seed for /dev/urandom by using noice from microphone input of soundcard.
other such stuff, I forgot