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

3 Likes

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:

3 Likes

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.

1 Like

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.

1 Like

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:

Blockquote 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.

Nothing triggers me more than this theoretical argument that assumes because an attacker has managed to seize a device in post boot authenticated state they magically possess all the capabilities, resources, authority with all preparations necessary in hand to quickly drop a trojan in hopes of catching additional passwords. This logic behind this type of thinking has no basis in real world. Identifying real, valid and repeatedly documented threats and vectors against full disk encryption and it’s significant limitations with silly hypothetical scenario does not help me and the countless other users share similar threat models.

Per-vm encryption is absolutely not security theater.

Full disk encryption only provides very limited protection to circumstance that a device is obtained in a pre-boot authenticated state only. In modern day era computers are pretty much on 24/7. Full disk encryption was created to solve the problem of protecting data in transit only. Threat landscape has changed significantly.

Simply put, if a VM is not active its data should be at rest in a secured state.

Furthermore, if a VM is erased its data should not be recoverable from a target host in a post boot authenticated state.

Finally, the data created during a disposable VM serssion should be truly ephemeral and irrecoverable another benefit of per-vm encryption done right.

On a sidenote as per NSA own specifications, encryption should be doubled wherever possible. Spread over two implementations provides most robust data protection that if a weakness or exploit is found in one the other is still effective.

4 Likes

3 months is a pretty slow burn. You must be raging by now.

Nothing here is a theoretical argument. It’s a statement of the current
state of attack for certain vulnerable individuals.
As you so rightly say:
People who think like this are just in the real world thinking about actual threat vectors.

I don’t think I used the phrase “security theater”, although I could have
done.
I completely agree that data at rest should be secure. I said as
much.
I am not convinced that encrypting a qube is the best way to achieve
this, but I am open to being convinced. (As I said.)

In your comment, you use the word “data” to refer to different things, I
think. Do you mean only the data in the qube, or do you also mean to
cover metadata, and trace evidence in the qube, dom0 or sys-gui?

The 4.1 callback pool will allow you to implement whatever encryption/steganography/… technique you like for storage pools yourself. There’s an example for luks encryption with file pools in the code.

Essentially it’s the pool approach that @unman mentioned.

Since you can choose to put each VM in its own storage pool, you essentially get per-VM encryption if you deem it necessary.

I guess what you want is some UX checkbox to encrypt your VM which is unlikely to come any time soon.

1 Like

Hey that was obviously typo and I removed that sentence in my early draft how did you see it?

By data, I am referring to the data in the Qube.

I will pay a $5,000 bounty - I am even open to making that payment upfront in advance of the work being completed - to anyone that can implement that in GUI so its actually useful.

2 Likes

This is quite a strong conclusion. “Value” of my data is not a boolean (“much valuable” or “not that much valueable”). It depends on how much effort I need to reliably protect it and how much I suffer if I loose the data, multiplied by the probability of loosing it. For most non-technical (or otherwise busy) people, the effort is too large, given the low probability of a targeted attack. The goal of Qubes OS – as I understand it – is to make security not just reasonable, but also available to people. Otherwise you can say that everything has been already available long ago: Xen, PGP etc. Qubes is not even needed.

After 10 minutes your post get’s send to all email users. Any edit after that is lost on us.

1 Like

I’d say that this is possible, but i don’t think this would be easy for non-technical people.

I don’t understand your comment.
Qubes contributes to security through compartmentalisation. It is not a
one-shot security solution. Nor should it aim to be.
It does enable users to use other tools in the qubes, and in some cases,
like the vault, it highlights those tools.

As to my comment, I thought I hedged it: “probably”. “not much”.
A strong conclusion would be: “If you are not already using those tools
you don’t value the data.” - see the difference?

1 Like

Kinda late but the answer you are looking for is U2F with some other encryption. Zulu crypt and mount might work or not. All these used to work… the problem is that once you give a solution the crew has to distroy it at some update. That is why I don’t use this forum very often. Good luck if you are still looking for answers. USBguard???

Just my 2 cents. I ran into an issue trying to use Qubes OS for work under the BYOD program. One of the mandates is full-disk encryption. While I do understand that in reality it is FDE, the agent has no way of knowing making not possible to use. It’s unfortunate but understandable.