You hit the nail on the head!
If it doesn’t improve your actual security but only makes you feel more secure, it actually harms you and is to be avoided.
That’s why it is ALWAYS a valid question to ask: why do you want to do this? how does this make you more secure? … really?
And why “It makes me feel better” is NEVER a valid answer.
By this I am reacting to your last post without passing any judgement on the topic of this thread and whether it would actually make you more secure or not.
You are incorrect. It does NOT harm me. And there is nothing “only” about my own peace of mind. Encrypting something twice might not be better, mathematically speaking, than encrypting it once; but it sure ain’t worse!
It harms you in making you feel more secure than you are. Again, I am not talking about the concrete topic of this thread, but simply react to the “it’s making me feel better” statement.
Each solution needs to be thoroughly vetted as to what it actually does and what the effects on your security are.
In this particular case you can encrypt things 7 times… if you have a key logger, or someone is looking over your shoulder, or you are using obvious passwords etc. All you are doing is wasting energy and heating the planet while lying to yourself.
Read what you wrote above. It’s a prime example of lying to yourself. If you don’t trust “the system” you should never input the decryption password. If you have a key logger the thief will extract your encrypted data plus the pass phrase next time you are online. It makes no sense.
I am not saying there are no scenario where it makes sense to encrypt a qube’s storage. There very likely are (@unman’s interest in the topic suggests as much). However your reasons are very much not.
Per-vm encryption is necessary because limits of full disk encryption. When an attacker that may be able to acquire your device in a post-boot authenticated state this feature provides reasonable protection.
In this scenario, an attacker acts opportunistically to steal your computer in an unencrypted state. With per-vm encryption, the only data that would be compromised would be the data from those active/running unencrypted VMs.
This type of attack is common and well documented. We don’t have ‘good guy’ case studies because they don’t make the news but we don’t distinguish between the motives of an attacker just the nature of the attack itself to draw lessons from. Two very high profile examples of this attack being used is against the creator of the original silk road and the creator of the alphabay market websites. In both cases, the targets deliberately distracted - one by a faking a fight between two couples and the other by driving a car into the targets living room.
It is very difficult to defend against this type of attack and naive to think you will have the opportunity to act quickly enough to defend yourself. Per-vm encryption minimizes damage in these cases to only those VMs which are active at the time of attack - and this can mean all the difference.
Like most people, my computer is on 99% of the time. I only benefit from the security full disk encryption provides 1% of the time. The argument for this is simple, when a vm is not running it’s data should be in a secure state and not rely on antiquated security paradigm from 1980s. Threat landscape is different now and the type of security it demands has evolved. This may not be your threat model but it is a very valid one and the merits of per-vm encryption is very clear.
For an operating system based on the idea of compartmentalisation, it seems strange to completely dismiss the idea of only decrypting the app-vm you’re actually using in the current session.
Even before playing through various attack scenarios, it would seem better than only being able to decrypt everything at once at boot time.
I dislike simplistic analyses of the type “if X is compromised you can forget everything anyway because then a sophisticated adversary would be able in theory to do Y”. That reasoning is academic and the real world is messier. Not every attack is maximally efficient, nor is every intrusion necessarily permanent - they may be opportunistic and transient!
I’d much rather have encrypted data stolen than unencrypted data.
And even if, IF my dom0 is compromised by a sophisticated state level adversary today, my encrypted VM would still be safe until I use it next - possibly weeks or months later. In the interim perhaps the bug could be disclosed and the intrusion discovered/neutralised. So don’t tell me it makes me less safe and is a stupid idea.
I also feel the need to state that I dislike the lecturing and dismissive tone of this discussion.
At least I found that I am not alone in wishing for encrypted AppVMs.
However I also understand that it won’t be built and so I will continue to work around this limitation by hand.
i agree 100% with everything you have said i do not want to distract from the topic at hand but i also want to share my experience why i would like to see vm encryption. i am very well versed in the secondary screening experience. when i am not traveling i am traveling. here is what i have learned. it is not a good look to cross borders with a wiped device. its suspicious and you will be denied entry unless you are a citizen/resident. i like the idea of vm encryption it allows me to just delete the vm which has been compartmentalized for at risk activities and still retain all my normal day to day. worse case they image the device the vm enryption provide some measure of assurance the deleted vm data is not easily forensically recoverable. needless to say i have continuously wiping and reinstalling my qubesOS multiple times a month for this reason its a huge pain
I haven’t done that. In fact I explicitly did the opposite.
That should tell you something or at least make you re-examine your position. Why else be here?
Having qube level encryption has significant advantage over single layer full disk encryption methods mostly but not only in the case when the drive has been unlocked (as it often is) but also when it is locked. Especially if they adopt two different implementations you can greatly mitigate risk or reduce the likelihood of unauthorized access that may arise from a flaw being exploited in the implementation of a single layer of encryption… the chances are very low such vulnerabilities are available on both levels of encryption. You will find this is often a requirement for devices in US government and military use in classified deployments.
I don’t know if @Brad had the time to test my idea of hidden appVMs, and by the way it’s not really the same thing as simply encrypting appVMs, but I came with a crude suggestion to use an equivalent of encrypted AppVMs, manually though.
You can pop up any disposable VM and attach a disk via xl block-attach DOMID '/path/to/file.img,,xvdX' (changing capital X accordingly, also note this can’t be an hdX/sdX type, as only the PV interface is supported in domUs).
The “file.img” is containing TrueCrypt-like volumes (or even LVM/ZFS encrypted pools). You then mount it from inside your disposable, and can use encrypted data as you wish.
Of course this needs manual tweaking if using apps needing the data inside the encrypted file (symlinks, etc). Or just install the apps in the encrypted container.
I said in the related github issue, that I would expect users with
sensitive data to be storing it encrypted within a qube, and
decrypting it as and when needed.
What advantage would you expect an encrypted qube to provide over this?
I’m not a native english speaker so I may have misunderstood, but didn’t you mean the opposite : why this would be better than an encrypted qube ?
Depends if you’re talking about totally hidden appVMs or encrypted appVMs.
For hidden ones I already explained.
For encrypted ones, I agree, I only see one advantage : easy portability of data. Moving a file is easier/faster than exporting a volume. You shutdown the VM the file is immediately available. Also it would allow to share the file with different VMs, maybe more easily (not as the same time though).
But don’t hit me if I say crap, I’m still learning ^^
I meant what I said - in what way would an encrypted qube be better
than encrypted data within a standard qube?
It’s for those who say they want or need encrypted qubes to
explain what advantage they will bring.
(I am not saying that there are no advantages, but that people who press
for encrypted qubes should be clear about what it is that they want and
why.)
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
Convenience. An encrypted qube means all customizations, installed software, autostart scripts and much more, easily backed up and inaccessible to an attacker unless decrypted. Not just data.
And, this is kind of a loop, or paradox. Prior to get to convenience, the one should be able to know a lot about Qubes (otherwise serious security damage, or a sense of a false security could happen), but then if the one would know a lot about Qubes, the one wouldn’t ask how to achieve it - he would know how.
Quick personal example, I’m a recently converted Quber, so I have a lot to learn.
In vanilla Xen, to boot a domU from a normal or a hidden volume, I just mount the corresponding volume containing the disk (ie the location of “disk.img”).
Now what would be the way to do it properly in Qubes ? Compared to my method, is it only about LVM handling and not especially Qubes ?
I read your instructions from a previous post which cleared things up.
I’ve also read the doc secondary HDD, which has some useful steps, but they need to be adapted.
But nowhere I found a doc like “Create your domUs and run them from custom locations” (Qubes air is that you ? ^^).
Does a guide like that exist ?
I need to test and maybe sleep on that, but I have preliminary questions :
I’m not clear on what you want that isn’t included in
secondary-storage
As you know, the docs are a a collaborative effort, so feel free to
clarify/add matter if you think it is missing.
I need to test and maybe sleep on that, but I have preliminary questions :
- can’t I mess things up by creating a new volume in the main “vm-pool”, and registering that with Qubes ?
No - they appear in Qubes manager.
I cant speak for the GUI tools but the command line tools fail
gracefully if the backing volumes are not available.
I’d be very interested in you elaborating on how you would personally go about encrypting data within a standard qube. I was looking at gocryptfs for this use case, but would love your opinion.
I like gocryptfs somewhat, but don’t use it.
I rarely use “cloud” storage, so the claimed advantages mean nothing to
me, and the disclosure of information about file sizes and structure is
unfortunate.
If I worked heavily in the cloud I would look at CrysFS, but not rely on
it at the moment.
I use veracrypt (from habit), and GPG - that combination fits my needs.
As always, you should be clear about your requirements, use case, and
set out your risk profile. Few people do this.
For most users there are some simple questions that help:
How sensitive is the information?
Will you store data in the cloud?
Will you need the encrypted data available in Windows or Mac?
After determining risk profile by considering adversary and likelihood
of targeting, and competency, you can take steps to propose a workable
solution. If the user cant use the tools they will bypass them.
Thank you! Totally agree about starting from threat modelling.
It seems like the two projects differ primarily in that file size is obfuscated in CryFS, I’ll start using it when it gets to 1.0. Here’s the comparison if anyone else is interested:
https://nuetzlich.net/gocryptfs/comparison/