Let’s imagine a situation: one guy named Ali lives in a country with a repressive regime. Because of some reason he is arrested and his computer is seized. And here let’s imagine two different situations:
On his computer he has Debian on full encrypted LUKS2 disk, with installed KVM and Whonix in it.
On his computer he has Qubes installed on encrypted LUKS2 disk.
Let’s assume that in both situations it’s better for him do not let them to decrypt the disk than to let. Assume that he succeeded in it (could swallow paper with password before they broke into his house, or other way distroyed it, etc.).
And let’s try to guess: in which of two situations his *** will be burnt stronger: when they meet LUKS encrypted disk with Debian or when they meet flashing lights, screaming everywhere “YES! IT’S ME, QUBES! QUBES!!! YES, HE’S USING ME, USED ME, HE HAD ME LIKE A ***** AND I LIKED IT!!!”
Yes, of course you can say that if he’s arrested in a repressive country he’s anyway in trouble, but I can say that when they know that some guy on the virtual side of reality, who they really don’t like, used Qubes for his anonimous online activity in messangers, and here they meet another suspicious guy from the real side of reality who has Qubes too, it’sssss… Of course you can say that there’s nothing good for him anyway, but if in the first case he would be and in the second case he would be sentenced to death, I think it would have mattered to him.
My proposition is to add in installer option to install Qubes version that has entries and disk decryption screen replaced by the fake ones (let’s assume by the Debian ones). I may not have been very technical, but I’m sure you understand my point. The goal is do not let adversaries to know that it’s Qubes inside while disk is encrypted.
I continue to encourage Qubes developers to strengthen anonymity protection in their system. You may not be able to hide Qubes usage from applications (in other words “from the other side of the Internet”), but you still can do something in this matter from the user and ISP side and it matters even much more than hiding it from applications. And that’s something that’s largely up to you, not just Whonix developers. It’s not their fault that Qubes leaks its usage to ISP thus putting users at high risk in some countries.
Security is good but in many cases it is impossibile without sufficient anonymity.
It’s user’s problem to do everything that depends on him to protect himself in such situation but he can’t if developers failed it on their side. So they must do their best too in doing everything that depends on them in this matter.
This topic is recurrent, and I think it is a case of choosing adqueate tools for a given threat model. It turns out there is an entire team working on a tool for the situations that require no trace to be left on a computer and that system is not Qubes OS, it’s TAILS.
Unrelated moderator note: made small edits to remove unnecessarily offensive language.
You all who think that, just confuse the soft with the warm. It’s not about leaving no trace, it’s about keeping the adversary from getting to those traces. And so it’s about user protection and security. What do you mean actually under this word “security”? Protecting users from evil, bad hackers? It’s not enough to protect them. All this situation reminds me situation when a guy looking for someone who sells him a car and finds only one guy who can sell him only the wheels, another guy who wants to sell him the body of the vehicle, and the third guy who can sell him an engine. And when he gets angry, all three of them say to him, “Well, in the end, if you’re so smart, you can build a car that you like!”
Qubes would be a perfect OS for protection security and anonimity if its developers just were perfectionists. Instead of this they just handed over the anonimity part to the Whonix team, and said, “And that will do!” But things don’t work this way. Whonix developers can only fix anonimity holes related to their own Whonix, but not anonimity holes related to Qubes OS. You can’t just come up with an imaginary word “SECURITY” and pretend that users are being protected in this way. Security without anonimity is not inadequate security for many people in this world. Instead, you’re trying to look like you created your OS to protect housewives who are afraid of hackers.
No one’s asking you to redo the entire system from scratch. No one’s asking you rewrite all the code from scratch. You just asked to patch a few holes related to anonimity in your OS:
Create mechanism giving (and warning user) to re-route all update checks and update downloads (and not only update downloads) through Tor (in other words to hide Qubes usage from user’s ISP if user wants it). It has sense more to do before user’s first connection to the Net than only after. That’s why it is important to implement this in installer (or in that post-installation configuration part where user asked to install templates and so on).
Give user ability to hide Qubes presence on his computer from forensic investigation, if user decides that it is better for him.
At this time this is all. And I don’t think that it is too much. All this can’t be done by Whonix developers, but only by Qubes developers.
Maybe something like rubberhose encryption would fit here as an addition? This way he might even be able to tell a (misleading) passphrase for a non-qubes archive.
I wrote my request hoping that it would be easier for them just to replace the entries and disk decryption screen by the fake ones (in other words to try remove signs, showing the presence of Qubes) than to implement in Qubes another new project or something like this. It would be already good if they just agreed to do at least something like this. Not even to mention something bigger.
Bethinking the current situation that’s probably very true…
I am not an expert at all at estimating the effort needed from QubesOs dev team, but lets hope it will get implemented some day… I would definitely like it.
What is the difference when the Qubes disk encryption screen is faked and showed something else? There is still the Luks header and all the encrypted data.
The guy named Ali would become trouble because he uses disk encryption and not because he has Qubes installed. Is there even a country which has a death sentence because of disk encryption? I could’nt find any…
Do you know what Ali should do? He should study the Law to realize how legalese really works. He would be surprised…
The difference is really big because all messangers that Ali will use will know that Ali uses Qubes. Then if dictatorship dogs collect some data about online activity of his accounts they can create profile. If somewhere in their country Ali will be accidently arrested and they will find Qubes on his laptop, then how do you think, will they match his identity to that profile? And how big amount of Qubes users could live in their country? Especially those who used Tor in the same time. When he will be sentenced to death he will be sentenced not for using Qubes but for that activity he kept on his accounts. And the fact that he used Qubes could have been one of the decisive ones in sentencing him. Of course he wouldn’t be doing so well anyway if they found there some LUKS encrypted disk with some other OS, but then there would be at least a little chance that he would receive a lighter sentence, as his guilt would not be so clearly proven or he would pass through another trial at all. Or even would be released (unlikely but).
So you’re the one who needs to learn some logic.
That are way too many ifs and assumptions for me, especially that all the data you’re worrying about, could be collected by some agency and pointed at you because you’re the only Qubes user in a radius of XYZ miles and you, your Laptop and your Geolocations could be matched even you used some thing of tunneling.
For the logic sake you use messengers which are untrusted and worry about fingerprinting. If the stuff in your messengers is so hot maybe you should separate them from your Laptop (create another layer) or if this really makes you feel better, change the LUKS-Screen-Image to something else, which will help you not a thing if you’re worried about an super-agency you described before.
Don’t you worry about Ali. He got past the security checkpoint with no problems, and willingly gave up the password to his WINDOWS computer for a quick inspection.
His Qubes installation, along with the plans to destroy the death star, flew first class in a Micro SD card masterfully hidden inside a wristwatch in his luggage.
Security is only as good as that one weak spot: xkcd: Security
What he really want is something like https://shufflecake.net/ but before Ali gets too excited about it, there are still some caveats:
How about Full Disk Encryption (FDE)? Can you boot Linux from a Shufflecake-encrypted partition?
In theory yes, and we are working on that. It requires a bit of work, because you need to load Shufflecake at bootloader time, but yes, it’s possible. Consider it WIP.
What happens if my machine crashes while I’m writing data on a Shufflecake volume?
There is a good chance of volume corruption and data loss. As it is now, Shufflecake does not offer crash consistency, but we have very clear plans on how to implement it in the future, they are also mentioned in the documentation and are WIP.
So but what I really don’t get. If plausible deniability is so important for Ali, why not install Windows first and keep Qubes “hidden” in the second part of the disk with the boot-files kept on USB? Wouldn’t that be the “easiest” way for him?
If you know the reason why the feature I asked for is pointless, then you should start with that and tell the reason and not to beat around the bush. The only justifiable reason can be that it is impossible to hide Qubes on the computer. Everything else is just excuses.
I want you all to understand: I am not Ali. I created this scenario just to show another attack vector that Qubes users may be exposed to and from which Qubes does not yet protect them. All requests I make here are created to improve the security in Qubes OS and so this way it can protect people around the world better. So my goals are clear - I try for people. And for whom do you all try? Whose interests do you advocate when you say a user could have done something or could have done it instead of saying that there really are the reasons and the ways to improve Qubes more? You might as well to say that users don’t need any anonymous and secure OSes at all, but instead, they need to develop their own security tools that suit personally them, because their security is only their own business! With this approach to the case you can just not develop any protected OS and say, “Let people all over the world deal with their own problems!”. The whole point of these systems is for any “Ali” to get sufficient security out of the box without the need of becoming cool geek / hacker and building something on his own.
And before you go any further, ask yourself again whose interests you’re really advocating here.
As far as I see it, its impossible to hide it so that it can’t be found by someone skilled. So what do we achieve with such a feature if there is still a risk remaining?
Installing Windows, keep some disk space unallocated and install a “hidden” OS inside OR change the Luks-Passphrase Image OR wipe the LuksHeader from Disk and restore it in resuce mode again to boot, is not like re-building the kernel from scratch and an acceptable task for someone who really needs that feature, while the rest of us is Ok for the moment with how it is.
Did you ask the Devs or even yourself what this feature will cost or what even could be achieved with it and how it comes, that things like Shufflecake barely exists and are not OS Standard yet? And anyway and to calm your mind: feel free to start a fundraising and you can call me in. But I guess the main problem to hide something which has to be kept on disk because it must be used again, can’t be solved properly. But maybe you have a solution, so lets see.
I’ll go even further with a motion to investigate the following proposals:
Experiment with creating an optional step in the Qubes OS anaconda installer that allows the user to customize their GRUB installation.
Custom entries, custom backgrounds, custom fonts, etc.
Experiment with trying to get shufflecake successfully into a Qubes OS initramfs, to see if it boots
And then see what it can do
Knowing full well that it will likely be nowhere near production-ready, but more as a proof of concept
I’ve got loads of testing machines. I will endeavor to investigate and report back. Might be a while, though.
Thankfully, everyone else has already beaten me to it with all the “this is not REAL security, and anyone who knows what they’re doing will see right through this. It’s only good at deterring anyone who doesn’t know what they’re doing” responses, so I don’t need to say it
Sidenote. The most refreshingly creative way I’ve seen LUKS headers transferred was via NFC. Took 30-45 seconds, but it worked
I just built Shufflecake. It’s still very much in testing (and segfaulted on two of my machines after ten minutes, corrupting all the hidden volumes ), but it looks promising.
…still won’t protect you if it’s known that Qubes OS is present on your drive, but it cold prove useful in some circumstances if this is not the case
@Qubie, did you have something like THIS in mind for GRUB?
OR devs can just develop feature implemented into installer (or in GUI inside OS) that could place boot files on some external drive and remove them with entry from bios. How is that? Sounds good? Yes, users could do many things themselves. They even could improve Qubes instead of its developers, so why are these developers even needed?
I meant some Linux distro but Windows is good too. Maybe it really doesn’t matter what OS will be faked. Unless the nature of the encryption makes it possible to understand that the disk is LUKS encrypted.
And what would the presence of Qubes OS reveal if entries were faked or deleted and in the computer was simply an encrypted LUKS disk or disk partition?
and in the second case he would be sentenced to death, I think it would have mattered to him.
), but it looks promising.
