There you can read a border agent can ask you for the LUKS password, and it was LHR (London Heathrow), so at least England (or whole UK ?), and I know the US have the same policy. Maybe all Five-eyes countries ?
Unanswered questions so far:
- Anyway, did she bring her backup with her to London, or she restored the one left at home, on her arrival back home?
- Where is encrypting appVMS (subject of this topic) fits in there?
- Device, or password database?
And the new ones
- What about her passwords there? How she logged in anywhere?
- What the OP is trying to protect so that he/she needs to encrypt AppVM?
- From whom?
- What AppVM (offline, online, disp, vault.)?
I’d give to a custom my LUKS password, but they couldn’t use anything in there that could compromise my privacy.
And he’s accustomed to Qubes? No really, I haven’t been recently in the USA. How it could work? Would they ask me to open each qube to show them what is in there?
For the border crossing situation mentioned above I have a rather unusual possibility for you.
First get yourself an Opal 2.0 compliant SSD (any Samsung SSD should do) and activate the device to turn on encryption with a non-default key. Format the device and create a partition table as normal. Unlock the “shadow MBR” with your key and format the device again and create your partitions for your VMs to live on and install.
What does this do? When the device is still locked anybody looking at it will just see a normal partition table but an empty drive. Once the shadow MBR is unlocked the actual partitions will appear and will be usable just like a normal SED device. Once the SED is powered down its back to the default MBR and it being an empty drive to anyone who might inspect it. Putting the drive into any computer without unlocking it first its just a blank SSD drive. Everything on that drive is encrypted so even if they do a binary copy of the device thinking that they can recover data off of a blank/erased device all they will have is garbage. You just need to store a binary key somewhere so you can unlock the shadow MBR to use it.
1 Like
Now if if that isn’t polluting a topic, I don’t know what is, sorry Brad ^^
My answers to all the questions are hidden below (cause too long), and I’d like to go back on topic cause I’m also interested ^^
Couldn’t you install them the way you installed Kali ? Of course you’ll miss the security of templating.
Off-topic
To Enmus
Your 1st question show you didn’t even read the tweets and the comments ! >.<
Backup → remove → travel → get back → restore. As for how she did there, ask her ? Only she knows ^^
Also, read the many articles on the web about people asked to give away devices, social media passwords, etc. A simple search (q=border+customs+passwords) gives dozens of articles (example, with a few solutions).
In cases like that, there are many ways to store your passwords encrypted somewhere and recover them, being locally on a device (hidden containers) or remotely (a file that you can download). You can even (regular) mail yourself as explained in the article.
Protection from what ? Zee germans ! (You have to be a bit old to know this movie ref ^^). Seriously though, from anyone ! There are many use cases for many different people.
Seriously o_O ?! ^^ You know there are IT guys behind them, right ?
Anyways, encrypting appVMs (so their data) is the solution to a problem, plausible deniability. Which hidden containers can help with.
To slcoleman
Or now, hidden HARDWARE containers, didn’t know about that, thanks @slcoleman !
Isn’t that the ultimate way to conceal software ? Hardware is way harder to break.
Your linked doc looks as just an update of the spec. I wanted to read more but there are dozen links provided, do you have one to recommend ?
Can you write data to the normal/empty partition ? Like “innocent” normal stuff, without breaking the encrypted one ?
Offtopic
Thanks for your response. All you quoted, I wrote I’d do it (2FA (including mailing 2nd factor, why not, or the way I proposed), not bringing anything with me (like Joanna did) so my LUKS password would not be of a great help to them, I don’t have social media accounts, etc…) I’m sorry English is not my first language, so I wasn’t clear by the methods. I agree with all of them because I wouldn’t have them too (with me, or at all). But trying to “smuggle” encrypted whatever greatly increases the risk, as even written there - so don’t do it - that was my point, because YOU HAVE TO LIE, which makes “attack surface” bigger. Remember the concept - keep it minimal? Find another way to have it on your destination, and as for alternative way, we have to know what it is you are trying to have with you that you can’t go there without.
When you go online - say goodbye to your privacy, that’s why you have to use Qubes and dispVM (meaning not to bring online anything with you). Same is for real life. When you go out of your home, don’t bring your privacy with you (on a laptop or on a cell phone, among other things) otherwise say goodbye to it.
I hope I clarified my points, resting assured that the polluting of a polluted (at least by lying there’s nothing else on the device) - is actually purifying. 
I find it just dangerous and not responsible to tell people that by encrypting their whatever, they will be safe at the custom. To me, it just tells that you probably have never been in such a situation and you don’t know how it is to be held in a detention even for an unfortunate set of circumstances, but happily resolved. I know. Never lie to a cop.
Yes, this has been discussed endless number of times and each time you act like you have not been provided and endless list of highly credible reasons why this is an extremely important feature request.
Per app vim encryption must come to Qubes.
As always, when this is discussed, people slide between encrypted
qubes and hidden qubes.
They are completely different.
If you want encrypted qubes you can do this right now.
Create a new lvm pool on a new encrypted device, register that pool with
Qubes, and use it to create new qubes.
When you want to use such a qube, decrypt the container, and use the
qube as you will - when you are finished, close the encrypted
container.
(You could do this with multiple pools, of course, and script the
encryption/startup.)
This will guard against the opportunistic thief who takes your machine
when you are using it, (so the main luks device is decrypted), but those
qubes are not decrypted and not in use.
If you want a RAM based qube you can do this right now, by creating a
pool in RAM, and running qubes there. This adds a little to the security
of a stock disposable.
Neither of these are hidden.
It’s much more difficult to guard against forensic analysis which may
show that qubes have been used, although they do not apparently exist on
the system.
(People who discuss this often want plausible deniability.)
I don’t see many people being really clear about what they want, what the
security benefits will be, providing concrete solutions, or even
steps toward those solutions. I do see a lot of vague hopes.
When I comment in the Forum or in the mailing lists I speak for myself.
4 Likes
I’ve tried to ! (I’ve slightly edited my quote to be clearer)
This is not a totally hidden appVM, but without the correct password it shows an innocuous one.
I´m glad to see my post sparked useful conversation. I enjoyed it and I learnt about hidden app vms which was something else in the back of mind as well. Some of it is above my paygrade but unman´s idea of an LVM pool and the process after that I like. I have no idea how to do that but I do see that option when installing qubes and I have a laptop I can experiment on. Iĺl investigate this.
I don´t know if the hidden possibility by zithro is possible but I can try that one straight away.
I also wonder how hard border people would go after you. If your high profile sure, but in general would they even understand qubes and how it works? I don´t travel except across our borders here so its not a thing, but then again anything is possible.
Thanks for all of the contributions. Its all useful.
Is there a guide anywhere? I expect that it also can make the corresponding qubes faster. Would be great for disposables.
3 Likes
@unman Looks mostly good, but one should use ramfs instead of tmpfs as the latter can be swapped whereas the former cannot. Or disable swap globally…
Curious to see the results ! Especially the differences in logging mentioned in the linked issue about logging on the “Really_Disposable_Qubes” method by unman.
For sure, using different apps in the normal volume and the hidden volume will create different traces and arise suspicion.
You absolutely don’t want to use ramfs.
On the other hand I don’t use swap, and I doubt any one concerned about
forensics would do so at the moment.
1 Like
Summary
I responded to @Rokokur via private message specifically the day after his post in order to keep the topic clean. But, that was his first and last post as well as visit to the forum, as I suspected, so he didn’t read my pm. I’ll re-post that pm here so real him could read it, while I sincerely don’t care who of you are (he is).
Summary
The rest of you, please apologize.
I find the focus on “why do you want that?” misses the point. Seemingly a lot of people do.
I’ve often wished I could have an encrypted vault qube that will not start without a decryption password. Why? Because it would make me feel better, that’s why.
The vault is very rarely used and it would make me feel better knowing that the contents cannot be read by the currently running system every single time I boot, but only on those rare occasions where I supply the password by hand. Perhaps on those days I’ll physically disconnect my network cable too. Who knows.
Is it strictly necessary by qubes’ current security model? no. But it certainly doesn’t make things worse and, as I said, it would make me feel better.
Create a new lvm pool on a new encrypted device, register that pool with
Qubes, and use it to create new qubes.
When you want to use such a qube, decrypt the container, and use the
qube as you will - when you are finished, close the encrypted
container.
(You could do this with multiple pools, of course, and script the
encryption/startup.)
To me this does not read like “You can do it now” but more like “Actually it would be really simple to implement”.
Is there an idiot-proof guide for doing the above? My wish would be an option when creating a new qube to “require password to boot”… and the rest looks exactly the same. Possible?
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.
1 Like
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.
7 Likes