Install VeraCrypt in dom0 to Encrypt Some AppVMs

User Support
1

I have using LUKS. Some times I am in the Qubes doing things like update and want to leave my system running

I am concerned about computer being taken and kept on and active and then files acessed.

I want to install Veracrypt in dom0 and encrypt “PrayingWithFriend” qube

Will there be a problem in moving a Veracrypt deb for Debian 9 into dom0 and installing to do this?

I want to encrypt directory with the PrayingWithFriend data and then decrypt data in dom0. One problem is Veracrypt wants to mount data as drive letters and I’m not sure if there is a way around this. I just want the directories encrypted and then decrypted. Cryptomator would be better but I don’t think this will run in dom0. I also do not knows if I can run anything in dom0 that has graphics interface and can’t be run in terminal.

Is there better approach? i want to encrypt whole qube and not just files on it because sometimes there could be other informaton left in qube. If I encrypt a photo where I am kissing my female friend but there is other stuff I didn’t encrypt this is trouble. best to encrypt entire qube. I don’t want to have to wonder about if I left other stuff around in qube.

I do not want to create a standalone VM with its own LUKS. This would make it hard to move stuff in and out of the VM.

it would be good to have terminal commands to make easy if someone able to do

2

First of all, read this before installing anything in dom0: How to install software in dom0 | Qubes OS.

Second, dom0 currently runs Fedora, so deb may not work there.

Perhaps this might be helpful:

3

this is possibly a good point

4

This is different that what other poster wrote.

They wanted AppVMs that could be denied.

I want AppVMs that can be encrypted. I don’t care if they see them. I want to be able to update Qubes and leave and not have to worry about someone gaining access easily to an AppVM.

I have read the game theory about passwords and Veracrypt and torture. I would rather face threat of tortures and have the AppVm encrypted than have everything out in the open when not locked by LUKS.

1 Like
5

I am interested in this too and I thought simple screenlock would do the thing? I’m probably misreading your goal?

Taken physically, or online?

6

I think he is referring to physical.

My take on this:

If you adversary is able to physically access your computer without you noticing, he can pwn you. Doesn’t matter how much crypto you roll:

  • Place camera or microphone to capture password
  • hardware implant HID’s or whatever else
  • firmware implant
  • many stuff more

It is irrelevant if your computers screen is locked, or your crypto containers are closed.

Assuming an adversary that would be capable and motivated to extract your whole machine hot (hotswapping to mobile power supply and keep it running) imo indicates an adversary capable of all mentioned attacks.

I would really urge you to think about this again. At least i would really avoid being tortured under any circumstances.

You can use an extra luks container for your ultra secure AppVM lvs if you think this provides better security to your specific use case. Cryptsetup/LUKS is installed per default and nothing indicates that you need the features veracrypt offers you additionally, like hidden volumes, so the risk of endless torture decreases dramatically as your adversary cannot reasonably claim a hidden volume being existent.

If you really are ok with torture: Just don’t give them the password. If you change your mind in the process of torture, you have a way out by simply disclosing it, leaving you with more options to choose from in the event.

In summary:

  1. Your qubes are encrypted by default with full disk encryption, so an adversary cannot read the qubes on your system if it is locked.
  2. While there are reason for additional encryption with software diverse suites in certain scenarios, this cannot protect against attacks with covert physical access to your hardware.
  3. Hidden volumes are a neat idea, but if torture is a possibility, you really do not want them, if you do not plan on getting tortured indefinitely. As you mentioned, this is game theoretically a far from optimal move.
  4. If your adversary is able to access your hardware running with all crypto containers unlocked, he might be able to access it even if you have screen lock enabled and can certainly access it if not.
7

That’s why asked. I just don’t understand how praying with friend, not to care if someone sees it until it’s encrypted, possibility someone to take away laptop and to torture and willing to be tortured fit together?

What’s on that laptop actually? Don’t leave it unattended and especially on if this could happen?! It’s just not an option. Again, maybe I’m missing something.

1 Like
8

@enmus and @Suspicious_Actions

This is a good example of how security is not a one size fits all affair. What is unthinkable for your might be legitimate for someone else.

You seem to have political adversaries in mind, a government perhaps. In which case your position is reasonable to say: never leave your machine running, they can bug your room, install a cam, torture you etc.

However, let’s take @qubesn00b’s case at face value: From her various posts I have the impression of a girl who might like other girls but still lives with her religious parents in a country like Iran. In that case she wouldn’t worry that much about someone bugging her room or surveilling her long-term, but rather about a surprise visit of maybe the father or some overzealous neighbor / sister / brother / religious police etc. Even in those places it would be quite unlikely for them to torture her just because she has encrypted data and refuses the password for it, especially if all they have is a hunch or suspicion but no other proof. Their goals might make no sense to you. They might be fine with the situation as long as it stays hidden an no one can say they should have known.

I don’t know. Never was in Iran, but I am somewhat familiar with fundamentalist religious people.

My point is: we have to trust that the OP understands their surroundings. If she says encrypted data works for her, it doesn’t have to be hidden beyond the funny “PrayingWithFriend” name… fine.

3 Likes
9

You are actually absolutely right. @Sven.

Hey @qubesn00b give it a go and apologize if bringing additional worries! I hope you recognized we tried to help with different perspective.

2 Likes
10

How would this be done? Is it possible to do this on same drive already encrypted as LUKS within LUKS?

11

sure.
You can create a file that contains just random

sudo dd if=/dev/urandom of=<your-container> bs=4k count=<size-in-blocks> status=progress

This will write a file containing random with the size of 4kiB x <count> and show the speed so you don’t have to wonder if it is working or not. The size depends on your needs.

sudo cryptsetup luksFormat <your-container>

will ask you for confirmation to create an encrypted container and for a password (twice). There are many options you can add to this command, but the defaults are sane.

Then you can open this container with

sudo cryptsetup luksOpen <your-container> <some-name>

is the so called mapper name and is uncritical. It will create a virtual block device you can mount under /dev/mapper/<some-name> that you can handle like any other block device.

It does not have a file system yet, so we have to create one once:

sudo mkfs.ext4 /dev/mapper/<some-name>

The container is open and has a filesystem in it, but is not mounted yet, so just mount it to ~/my-open-container

sudo mount /dev/mapper/<some-name> ~/my-open-container

You can close it by unmounting and luksClose

sudo umount ~/my-open-container
sudo cryptsetup luksClose <some-name>

The next time you open you don’t have to create a file system so

sudo cryptsetup luksOpen <your-container> <some-name>
sudo mount /dev/mapper/<some-name> <your-mountpoint>

is what you need to do.

Of course you can use little scripts or aliases to enhance usability when opening and closing.

You can store crypto containers in crypto containers in crypto containers + … if you wan to

For more information on cryptsetup consult the manpage.

This is how you create luks crypto containers. I am not too familiar with lvs, maybe there are other options with that.

You have to store your lvs in there and link it to the appropriate place i think.

12

Do you have any resources you can point me to, in order to better understand physical tampering threats? I am not as much concerned about BIOS firmware due to HEADS, but I am interested in hardware keyloggers etc. but haven’t found a lot of good info on those threats. Sorry if its a little off-topic, maybe i should’ve pm’ed.

13

You want the fancy shit? Take a look at the ANT catalogue.

PLugging in a hardware keylogger might be obvious on inspection, but the OMG cables are pretty fucking stealth.

If there is nothing on the free market to fit your needs, nothing stops you from cramming in a little ESP32 or a ESP8266 wherever it needs to be to capture whatever it needs to capture. It has Wifi and bluetooth for data extraction and costs literally nothing. The other day i saw such implants for RFID access control MITM. Pretty neat and open source.

You cannot touch the keyboard? No worries! Plant a microphone somewhere and use this to convert sound into keystrokes.

Those are just a few ideas, there are endless possibilities.

In general: Your adversary touching your hardware is a GameOver™ situation if you do not use tamper detection and especially really use it.

2 Likes