Thanks @slcoleman and @enmus to point me as a rude guy ! Just kidding, no offense ^^
For the border crossing, enmus just quoted how it’s done by a security professional (one of the creator of Qubes), and many examples have been given : you don’t need to hide or deny what you don’t have at first.
I’m still interested about the OPAL drives cause they have plenty of applications, but I’m wondering if that would also work as a non-boot drive (ie secondary) ?
I’ve (quickly) read a bunch of pages from the 2nd PDF and it is not clear about that : it’s talking about boot sequences, but also that it can be manipulated with ATA commands, so dunno.
One interesting thing though, if I understood well, is that : in order to boot the shadow MBR, “PC firmware and configuration → MUST not have changed” (p 12-6).
Am I thinking right that using a drive like that would prevent BIOS/UEFI tampering (provided it’s clean prior to the disk setup) ?
@slcoleman And how does the outer partition table prevent the outer OS from overwriting the inner OS? I believe that’s a fundamental issue that is hard to solve.
Each OS does not necessarily even see the other partition because the MBR contains the partition table. With the shadow MBR you get a shadow partition table for free. If it’s not a formatted partition you won’t be writing to it will you? Well yes, “sudo dd of=/dev/sdb” would do it if you tried, but why would you do that?
The inspector would first have to add a partition then format that empty space thus wiping what you are trying to hide from him, which is likely a lot better than him discovering what is actually in it. You might still be able to unformat it depending on how much they write to it. But why would they do that? Just to watch for the expression on your face? And try to guess if you are guilty by how much you squirm as they hit the enter key? I doubt it. They may try to dump that missing partition to some media to examine it later, but it’s SED encrypted and possibly software encrypted on top of that. Believe me, they are not reading that data.
In any case I think it’s fine for the Qubes system to see the fake OS system for doing maintenance by mounting it on an AppVM, but the reverse is not to be trusted. And you especially would not want dom0 to be mounting anything that someone could have tampered with. So with that thought…
If you made that fake OS partition also read-only and loaded the OS directly into ram like a live DVD and then set up a COW file system over it you could even hide the fact that it is a read-only partition. The inspector could easilly install all their sooper-secrit specialized spyware successfully to disk which would just disappear upon the next reboot! You might even find a way to squirrel off a copy of the COW fs containing their spyware for forensic analysis later. Effectively Spying on the Spys. Genius!
In total I don’t believe that this issue should be solved by Qubes OS, but more likely by some standard Linux software such as dm-crypt. If such a tool becomes standard, there’s also no issue in plausibly having it.
Yes, but if they notice dm-crypt on your system they will make you unlock it, so no, it’s not really encrypted from their eyes. They will lock you in the back room until you provide the key to unlock it, and when that fails they get out the monkey wrench. That is kind of the whole point of my exercise here, making the OS itself an Invisible Thing™.
Opal SED drives are amazingly flexible for many different use cases. They don’t just do encryption. You may already be using one.
Thanks @slcoleman and @enmus to point me as a rude guy ! Just kidding, no offense ^^
For the border crossing, enmus just quoted how it’s done by a security professional (one of the creator of Qubes), and many examples have been given : you don’t need to hide or deny what you don’t have at first.
I’m still interested about the OPAL drives cause they have plenty of applications, but I’m wondering if that would also work as a non-boot drive (ie secondary) ?
Out of the box any Samsung SSD will work as an Opal compliant non-boot drive. You just add an OS if you want one, but you first need to learn how to manage keys and create ranges on the device. Basically you create a range, encrypt it, and then format your partition into that space. Growing partitions may not be possible, I have not played with that.
I’ve (quickly) read a bunch of pages from the 2nd PDF and it is not clear about that : it’s talking about boot sequences, but also that it can be manipulated with ATA commands, so dunno.
The tool to use is sedutil or msed. I don’t remember which tool came first/second. One of them will likely come with your os distribution and just needs to be installed.
One interesting thing though, if I understood well, is that : in order to boot the shadow MBR, “PC firmware and configuration → MUST not have changed” (p 12-6).
If you create a small partition at the beginning of the drive you may have to count cylinders so that you start the next partition on the MBR partition table in the right spot. What we did was create a partition on the regular MBR, unlock the shadow MBR and then repeat the same partitioning on the Shadow MBR. After that you format that space and install the first OS (if wanted), or data, and then with the shadow MBR still unlocked create and format the second partition. Once you cycle power that second partition will no longer be visible until you unlock the shadow again. Someone quickly examining the drive will see the data in the first partition but won’t even see the second partition. They will see it only if they get their hands on the machine with the MBR unlocked and still powered up in the machine.
Am I thinking right that using a drive like that would prevent BIOS/UEFI tampering (provided it’s clean prior to the disk setup) ?
If the drive range is set to cover the boot partition then set to read only then you won’t be able to write any boot files. You need to remove the ro attribute from that range to update it. You should be able to boot from it as read only unless something needs to write there for some reason. Some kind of early phase logging? I have not played with UEFI yet so I can’t say.
The best way to do this is to have a computer you use to cross borders just for that purpose. I know a lot of journalists and such that’ll put a fresh install of an OS to cross borders and just have enough on there to do what they need to. If they need a full copy of their computer I know some of them will backup to a “secure” cloud and restore once across the border. No solution is perfect, but I do believe that taking a computer with all your information (sensitive or not) traveling frequently isn’t the best idea. I practice this pretty regularly in day to day life. My laptop has enough on it for me to do what I need to most of the time away from home. Everything else stays at home.
Just my opinion. I see what you are wanting and technically that’s very difficult and there are other measures (arguably better measures) to take where you don’t have the data you don’t want seen in the first place. You can always log into social media once you cross borders.
Are you really reading the information provided ? ^^
You should also read this topic for more information.
Each problem has its own specific set of solutions. And the solution to one problem may be a problem for a different use case.
To me, you’re mixing things up.
@slcoleman, your post is a good ref, thanks for the thorough explanations ! A mod could even split your instructions to a separate OPAL topic ?
Will have to play with that, but just wanted to share my initial findings :
From Arch wiki " msed and OpalTool , the two known Open Source code bases available for self-encrypting drives support on Linux, have both been retired, and their development efforts officially merged to form sedutil ". So it is available from packages on Arch.
fedora and SuSE provide the sedutil package
Debian has no package, one should use the sedutil github link above (see Deb bug #825864).
But the kernel has been compiled with “CONFIG_BLK_SED_OPAL” since kernel 4.15.17-1 (ref: bug #891213), so AFAIK support is available for booting Debian from such drives.
“Yes, but if they notice dm-crypt on your system they will make you unlock it, so no, it’s not really encrypted from their eyes. They will lock you in the back room until you provide the key to unlock it, and when that fails they get out the monkey wrench. That is kind of the whole point of my exercise here, making the OS itself an Invisible Thing™. ;-)”
Yes, that’s true, but nevertheless irrelevant. You unlock it and obviously you have dm-crypt in there. If that same dm-crypt supports hidden volumes, you can hide the next one inside without any hardware support. They won’t ask for that as you obviously need dm-crypt to open the outer fake one.
Anyway OPAL seems to be an interesting addition to the toolbox and rather well spread so that it’s not too uncommon to have a disk that supports it and probably not raising suspicion for that very reason.
Hide in the masses - that’s what I wanted to state and that doesn’t work with uncommon technologies.
Well, if having some form of disk encryption (which is present in 90% of OSes nowadays) makes border controls instantly get out their monkey wrenches - even if you unlock -, an Opal disk won’t help you neither (“why do you have that disk which supports Opal?”). Obviously you shouldn’t have anything at all with you then.
You give the useful idiots in monkey suits at border crossings far too much credit. There is a reason they are gov workers… cause they are too stupid or too lazy to make it in the free market.
The very reason for plausible deniability… so you can give up that password.
The more I see gov agents shill against pd, the more I see that they are fearful of it, and the more motivated I am to have a pd layer on every device possible.
From what I have heard veracrypt allows for several hidden volumes and you can choose which one to open depending on the password provided though I have yet to play with it myself
Devs, how much would the community have to raise to pay for plausible deniability implementation in 4.2?
P.S. Please add ARRR and a ZEC Z-address to the donations page. XMR ring sigs might have been cracked… and we don’t want to end up like the CA truckers.
What would this look like to you? The key piece of plausible deniability is that you can reasonably deny that you knew about it. From what I’m understanding in this thread, you want to hide information when crossing borders, and if there were a way to do that that was baked into Qubes and you used it, that wouldn’t hold up anymore.
My preferred schema: PD at the qube level, hot-swapping at dom0 level…
When Qubes is installed it setups an encrypted space allocated for PD (whether user uses it or not).
When user sets up a Qube they can flag it to be included in the PD layer if PD is active.
From dom0, user can hot-swap into PD layer via a hotkey + creds (activate PD layer). Depending on the creds entered the PD layer vault space is decrypted to the outer or inner layer (Like Veracrypt). Qubes flagged to be included in the PD pool are now bound to the PD layer vault space.
It needs to be setup such that once qube is setup, bad actors could not know if the qube is included in the PD pool.
This would allow for qubes to run in parallel… some in PD… some in overt layer… leaving plenty of red herrings.
Ideally more than 2 passwords could be surrendered to bad actors (meaning PD space could have 3 or more passwords, taking to different layers).
.
The sandboxed architecture of Qubes seems it would adapt well to PD at the qubes level.
We already have working implementations with Veracrypt. Qubes 4.1 already has storage pools. Now it just needs a PD layer vault space setup by default when installed, so all Qubes installs look equal. And then some rails to decrypt and bind to the PD vault when hot swapped.
| 
|