Setting Up Per-qube Encryption

Hi,

I know that disk is encrypted with LUKS passphrase but I’m looking for a possibility to additionally encrypt single qube. Is it possible to do it? (I consider creating standalone VM or using VeraCrypt if needed).

Any advises appreciated.

Thank you

1 Like

This is in the pipeline.
In the meantime, there is a simple alternative,which does allow you to
add additional encryption.
Create a new storage pool on a supplementary encrypted drive. Create a
new qube using that storage pool. Now you have a workable space where
other qubes will be stored on an additionally encrypted space. Storage
pools are covered here -
if you need help with them, just ask.

I should say that I think this idea, (additionally encrypted qubes),
has no real security benefit.
The reason is this: if the current situation is an issue, it must be
because an attacker can access a qube storage when it is not running.
That means that they have access to dom0 (whether directly by seizing
the machine, or by an escalation from a qube). In either case, they have
the capacity to drop a program which will either capture the password
for the encrypted qube, or wait for the qube to be active and pull off
the now unencrypted data.
So while the idea appears to have obvious benefits, it seems to me to be
security theatre.
Can you say what threat you think it would guard against? I feel I am
missing something.

Related thread:

Also, I’ve edited the title for clarity.

While you’re working on your laptop, an attacker runs by and snatches it. Full access to dom0, but no access to encrypted data at rest.

Longstanding issue:

1 Like

But that assumes that you are not protecting the data within your
qubes. I guess I assumed that people who are worried about this are
already encrypting data and/or using safe storage mechanisms within
the qubes.

If the “run by” attacker was an opportunistic thief then they are
unlikely to be bothered by disk or qube encryption - they are more
interested in the hardware than the contents.
If it was targeted they will image the disk, and (as I said) drop a
monitor program to capture the password, and arrange for the laptop to
be returned to you. (More likely than that, is that they will already be
monitoring you, and will have captured the password as you typed it in,
so the apparent run by theft just gives them a chance to mirror the
disk.)

Thats why I said it’s in the pipeline. Demi said she was working on a
solution.

Thanks for your answers!

I think adw well explained possible threat.

So I understood from this conversation that swap is shared between between all the qubes (which makes sense to me). Is it somehow overwritten by random data at the moment of laptop shut-down? Can it be enforced on request during QubesOS run to clean it (overwrite unused parts of swap by random data)?

Let’s say that e.g. I’m working on sensitive Libre Office document in a separate qube. I understand that Libre Office temporary files will be saved in swap so anyone who accesses my laptop when it is not encrypted will have access to unencrypted swap with parts of my sensitive file.

Will this encryption feature that Demi is working on also include plausible deniability? Just asking.

But that assumes that you are not protecting the data within your qubes. I guess I assumed that people who are worried about this are already encrypting data and/or using safe storage mechanisms within the qubes.

Can you elaborate a little more on this, please?

If it was targeted they will image the disk, and (as I said) drop a monitor program to capture the password, and arrange for the laptop to be returned to you.

If the laptop is returned to me, it can no longer be trusted.

Thanks for your answers!

I think adw well explained possible threat.

I don’t think this is quite right - each qube can use own swap, which may
be encrypted.
The system as a whole can also run swap: you can turn this off
obviously, and if you are concerned about this possibility should do so.
You can also use encrypted swap space.
I would turn it off.

Doubt it - that’s an entirely different problem.

Qubes enhances security through compartmentalisation.
That’s it.
If you have valuable data (whether monetary or personal value) you take
steps to protect it, and Qubes allows you to use specific tools to do
so within the qubes. If you are not already using those tools then you
probably don’t value the data that much after all.
Probably the best protection is not to take it loaded on to your
laptop at all.
You may feel you need some data on the road - fine - store it
encrypted online, or invest in a hardware encrypted USB device, and
access it only when needed.

If it was targeted they will image the disk, and (as I said) drop a monitor program to capture the password, and arrange for the laptop to be returned to you.

I never like such blanket statements - probably not to be trusted,
depending on what defences you have put in place.

For many use cases, I agree. For example, the default password manager we include in the standard Fedora template is KeePassXC, which supports encrypting its database. Currently, users concerned about the kinds of threats discussed in this thread should certainly take advantage of this feature.

As for what users want beyond this (and why), perhaps what they really want is the equivalent of per-qube FDE. That’s how I understand #1293. It’s a well-known problem for OSes in general that mere file-level or container-level encryption does nothing about all the confidential data strewn around the rest of the OS (metadata, swap files, paging files, etc.). This is one reason FDE has gained prominence as a best practice. Within each qube, it’s not clear how a user can implement this best practice without thereby inventing a solution to #1293.

Users should be aware of this possibility and should be prepared to distrust returned hardware for precisely this reason.

In that case, you might be toast, but of course that doesn’t mean per-qube encryption is not worthwhile. The fact that a security measure protects against only some threats but not others (i.e., the fact that it is not a panacea) is not a reason to reject it. If it were, then we’d probably have no security at all. We mustn’t allow the perfect to be the enemy of the good. (I’m not saying that you were saying otherwise; just pointing this out for anyone for whom it might not be obvious.)

That wasn’t for you. That was for everyone else reading this thread who wasn’t already aware of this issue (probably most of them) because no one had mentioned it yet.

Related issues: