How does Qubes encrypt data?

When a compromised VM runs in Qubes OS, all data that belongs to that VM is exposed to the attacker.
That’s a problem. Though my main concern is having an attacker with physical access to the disk retrieve unencrypted data from it.

Luks runs in the VM and encrypts the data with the VM-specific key. The data then travels to storage domain via adresses /dev/xvda2 or /dev/xvda3. The encrypted data is finally written to vm1-cow.img or vm1-priv.img in the storage domain . If I got this right…

Can a VM write unencrypted data to disk when compromised? It’d be good then, to isolate the encryption process to a separate VM, have it do nothing more than encrypt and decrypt VM1’s data. The encryption key would never have to leave VM2 so if VM1 is compromised the attacker won’t know the encryption key. And VM1 can’t send unencrypted data to the storage domain…

I considerd to run a live OS from cdrom but there were drawbacks to it.

1 Like

Hi @Qenthusiast, welcome to the forum!

Why not just use the Qubes backup utility to perform the backup into the storage domain? It will encrypt it. It shouldn’t matter if the VM is compromised or not.

Also, here you’re talking about per-VM encryption this is NOT what happens by default in Qubes. It’s something you configured, right? Because if not, you may be confusing it with full disk encryption, which it has by default and should address your concern of physical access (as long as it the computer is fully shut down and you never boot it afterwards)

Also, I renamed the topic to make it more concise. Let me know in case it is not adequate.

1 Like

If your goal is security, then you are right. But what if you are studying your attackers?

1 Like

welcome to the forum!

Thank u

The architecture specification document was difficult to understand 4 me .I did not implement anything I’m a newb

This s what I understand after Ive read the arch-spec-0.3.pdf

Is the FDE encryption prcess isolated to trusted VM? Its a part of the trusted computing base TCB?

,can malware bypass FDE, then write unencrypted data to disk? I want to stop it

Ah, I see. Then welcome to Qubes!

So here’s the gist of it: in Qubes by default enables full disk encryption. This is why you need to type in two passwords to access your computer: the first one is for the full disk encryption and the second one is for your user.

So whenever you use Qubes, it automatically has that full disk encryption. This means that anything you do under Qubes is saved to the physical hard drive / SSD in an encrypted form.

So if someone stole your computer they wouldn’t be able to see anything inside your system (including any qube) as long as your computer was shut down. If it was suspended or with the screen locked, you’d only need to worry if you believe your attacker is extremely sophisticated.

So each qube doesn’t get encrypted individually (AFAIK). They just simply do their thing and dom0 (the adminVM) does that encryption process for them.

Of course this security is assuming your FDE password is strong and the attacker cannot see you type it over your shoulder.

1 Like

I get most of what u said .

If I got this right .an AppVM wants to write to disk…
AppVM sends data unencrypted to dom0 .dom0 encrypts data with a key that only dom0 knows about.
dom0 writes data to disk,finally

so,the key is isolated to dom0 where FDE runs. an attacker with physical access to disk nned to compromise dom0 first or know the password to retreve unencrypted data from disk

I miss the role of the storage domain still. it was mentioned in the arch specfication. .

thank u

1 Like

“Is the FDE encryption prcess isolated to trusted VM? Its a part of the trusted computing base TCB?”

dom0 does the FDE; it’s just standard FDE via luks for your entire system / all of your VMs at once. So yes, it’s part of the TCB.

“can malware bypass FDE, then write unencrypted data to disk? I want to stop it”

No, not from within a VM at least as dom0 handles the FDE.

If you really need per-VM encryption, there’ll be an option in Qubes 4.1 for very advanced users.

If you need some data encrypted inside a VM and want encryption handled by a different VM, then there’s qcrypt.

For most users however the aforementioned FDE should suffice.

1 Like

That’s pretty much it, as far as I understand it.

That document is outdated. No storage domain exists currently. Quoting from the docs:

(For those interested in the history of the project, Architecture Spec v0.3 [PDF] is the original 2009 document that started this all. Please note that this document is for historical interest only. For the latest information, please see the rest of the System Documentation.)

The following image is how the current architecture is (except for the GUI VM which will only be available on the next 4.1 version). Taken from the docs:

1 Like


the statement would benefit from confirmation .is there a source?

1 Like

now looking at links from deeplow

I’ve looked through the system section of the documents that were mentiond by deeplow

The picture thats shown in deeplows post was in the documentation and it suggests that Full Disk Encryption runs in the AdminVM .

Nothing was mentioned about Full Disk Encryption in TEXT in the System section of the documentation but there was an article discussing the handling of VM data at ‘Template Implementation | Qubes OS

Finally I looked at ‘Introducing the Next Generation Qubes Core Stack | Qubes OS’ .The last sentence here mentions an upcoming post about device and volume management in Qubes OS 4.0 but I can’t find it as I look through the news archives.

If someone could find a source that confirms that FDE runs in the AdminVM Idd be happy !

OFC it runs in dom0, otherwise it would literally not work :slight_smile: In a hypervisor, any full disk encryption need to be handled at the lowest level.


Why ?Sorry Im newb. Do you have a source ?

To me it seems the easiest way to implement FDE is to run a single prcess in the qube with disk access whuile In theory you have FDE if theres encryption in all VM except AdminVM ?

Only dom0 has the full disk access. Every qube only has access to its own space on the hard disk. Qubes OS does not implement per-qube encryption yet.

1 Like

The image is the source :slight_smile: But maybe it could be added somewhere in the documentation. It’s a community effort. If you or anyone else feel like they can contribute, feel free to improve it:

Entering sudo lsblk in the AdminVM proves that LUKS is mapping my disk (apart from the boot partition). This solves my issue.

1 Like