I thought about Qubes installation as second OS on single computer and read that people here say that in this case it would be safer to install boot partition on external USB flash drive so that adversary at least can’t use other OS to infect Qubes boot partition or use bios/uefi to infect Qubes.
So it creates several questions for me:
Can adversary just create new one boot partition and this way infect or boot Qubes (in case of physical access) ? I mean why he can’t just install new boot partition from Qubes installer on other USB drive and use it instead of mine? Is every boot partition unique for all users so no one can replicate it? Probably it is, otherwise it makes no sense (in case of physical access).
I read that (as I understood) making of external boot partition setup is even simpler than make dual-boot setup for Qubes. The only thing is needed is to choose manual partitioning during installation and choose USB flash drive as boot partition disk and specify other internal disk partition for OS installation. I understood correctly? Or it is “copium” and I better need to follow this manual of dear @Apparatus? Of course it’s much more safer and reliable but also it is much more F*****G COMPLICATED and has 100500+ ways where you can **** up. At least it looks so.
However will it really work for dual-boot setup? In theory it will no touch other OS’s boot partition and since it wasn’t overwritten you just power on computer and it automatically boots other OS and in order to boot Qubes you need to enter boot menu and boot from external flash drive. At least I see this this way.
I think the problem with dual boot, from a security standpoint is a bit different.
If I understand the write ups (other webpages) , Bootkit can install itself without the user doing anything incorrect. Without the user knowing it happened.
You probably mean that this Bootkit maybe can infect Qubes external bootloader when it’s plugged in during Qubes booting, but can it really infect it accidentally? Each malware should be made specially for special goals which implies working with certain operating systems. If attacker isn’t aware of Qubes present on the machine as second OS his malware is unlikely to be able to infect an OS for which it is not intended. To let an attacker know about Qubes user at least should use the same network with Qubes and Windows, use sys-firewall as update proxy, use clearnet in some qubes. And even then, this is only if the attacker is from the ISP’s side. In case of the external Qubes boot Qubes will be booted only from that external drive and without it it will be only some part of encrypted data on the hard drive. Can random malware infect external Qubes bootloader when it’s not intended for this? I doubt. Can random malware somehow interact with Qubes from bios without using the bootloader? Not sure. I don’t know.
Of course I’m not cyber spec. I’m just describing my assumptions and understanding of the subject.
For exmple: it can implement a simple keylogger, then your disck encryption password and your login credentials are stolen. - such malware not need to be OS specific, right? But hardware/BIOS/UEFI specific instead.
You think I didn’t think about their physical access to the external bootloader when I asked this? My question has sense only if assume that I could somehow get rid of / or destroy that external bootloader before they could take it. So that’s why I ask if they can replicate it. Because if they can then the only reason left why to use this setup is to achieve a deniable encryption, as said in Apparatus manual. And at the same time it could protect you from that keylogger if luks headers are transferred to this drive too so adversary still can’t decrypt disk even if knows the password, until he gets physical access to that drive.
I think ‘calculating’ the detached headers is possible - but I don’t know how feasible scenario. But if you simply use the full disk as a single encrypted partition, and using the default luks settings, then I would think it is kind of straight forward to ‘replicate’ such detached boot disk.
Of course, getting the encryption key itself is a different question, and I still believe that this is the only real obstackle here.
Probably not though. Most TPMs are poorly designed, and easily exploitable.
If not with manufacturer credentials hardcoded in the chips, by simply attaching to the bus and sniffing the keys.
Here is an example of BitLocker key recovery (in 45 seconds). The priciple would be the same for any operating system. https://yewtu.be/watch?v=wTl4vEednkQ
TPMs are not (and have never really ever been) secure hardware. I cannot say enough, that TPMs should not be relied upon.
and that’s one of the reasons Qubes does not even support it.
and also confirms, that the only ‘obstacke’ is your luks encryption key → so, keep it safe
