I am currently running VirtualBox on Windows and want to improve my setup.
I went though quite a lot of the recommendations in the wiki, but there’s a limit to the time I can allocate to setting up stuff, I would like your opinion as to the following:
Host: Debian Stretch
Encryption of a hidden volume with TrueCrypt7.1a (or Veracrypt?)
Whonix VMs inside VirtualBox, in the encrypted volume - yes, I read that KVM is recommended but as I am already familiar with VB I prefer to stay with that at this point (unless it seriously undermines my security, and I didn’t get this impression going through the wiki). The KVM installation guide immediately proceeds to fixing problems and dealing with bugs…
Connection, possibly through a remote public wifi with a directional antenna. Not sure about this one, plausible deniability will be a bit harder with such a setup…
I am interested to hear your opinions, I know where the wiki is or how to perform a web search
Any Debian, Fedora, Arch based distro is fine. Avoid Ubuntu but Ubuntu-based should be fine (ie Mint, Elementary, etc). Biggest determinant should be compatibility with your hardware and also your comfort level with distro.
Keep it simple - encrypt the whole disk. I believe TrueCrypt had a much larger following in the Windows world. LUKS is the standard on Linux. High scrutiny is good when it comes to crypto. Actively maintained and well-supported on every distro. Arch has the best docs on many topics: Data-at-rest encryption - ArchWiki
Good if you’re constantly on the move (and avoiding video surveillance). If plan is to do this from home / office, don’t bother. If you’ve been filtered down to 1-2 blocks, all is lost. At that point, surveillance switches from dragnet infosec to behavioral / financial profiling and white vans.
@pano. hidden folders for plausible deniability is more theoretical than practical. it assumes you are in a worst case scenario where your adversary is sufficiently restricted by rules that they will obey.
you: "there’s nothing on my computer."
attacker scenario a: "administer the shocks on this chump. zap you sure about that?"
attacker scenario b: “we don’t believe you. you’ll sit in confinement until you cooperate.”
will your plausible deniability succeed in such a scenario? most likely not.
others have referenced a scenario where “plausible deniability” is good for crossing borders with sensitive data. however, it’s still a risk for the reasons above. a simpler means is storing data that you may need at a another location in a properly encrypted and anonymized means at a temporary location on the internet. cross the border clean and download the problematic data later. “plausible deniability” no longer required because there is nothing to deny.
the hard reality, as a user that relies on anonymizing software, is that the game is pretty much over if you’ve been located. yes, encryption of the hard drive offers another barrier. but, if it is imperative that you cannot be exploited to give up the decryption mechanism, you should use a method that prevents you from knowing the decryption keys while being able to easily hide or lose the decryption mechanism. one method for this involves using luks for encrypting your hard drive and using a random 8k keyfile for the keyphrase. then, use cryptsetup to gpg encrypt the random 8k keyfile, which will include it in your boot image. you’ll know the passphrase to unlock the gpg encrypted keyfile. but, that passphrase is not what was used to encrypt your hd. thus, lose/destroy your boot key in worst case scenario, and you won’t be able to provide the decryption key under duress. however, this may have the downside of a lengthy incarceration or prolonged torture in worst case scenarios.
tldr; focus less on plausible deniability and more on avoiding practices that will place you in a position to be physically cornered by an attacker.
If it’s full disk encryption vs. partial in a hidden folder, I think it’s the latter is still better. If the whole disk is encrypted, this will first of all look suspicious by itself, second there isn’t even a “story” to tell here. If you refuse to give the key you’re assumed guilty. If you do, all the content is revealed. With partial encryption, at least you have revealed something, cooperated in some way, and, if your adversary isn’t sure if you’re the target he wants or not, that may be the end of it.
@pano it’s a risk. you give the attacker your drive. they then use any number of software suites to begin cataloging and analyzing the data. files containing randomized data will stick out, and they can then ask you about them.
for the scenario you describe, the “transit over borders” is often the assumption. you’re better off just not having the encrypted data at all. there’s no risk if it isn’t there.
That’s the best of course. But in other scenarios you must keep something. I don’t intend to give anyone my drive if I can help it.
I think even that, in a separate USB that can more easily be concealed, and revert to a clean VM snapshot every day. This, in addition to encrypting. I wonder about links. when one uses a browser, saving bookmarks makes the work much easier. Especially with onion links that cannot be easily searched for and found. Store that in an html file and avoid any bookmarks?
it all comes down to risk and threat model at that point. safest advice is not having the risky data on you. could just as easily create an image of the data you need, encrypt it, and host it with onionshare or another means before you travel. when you arrive at your destination, just download and use after you’ve cleared the risky check points.
also, another thing to keep in mind which i forgot to mention about hidden folders. if the os and software you use to access or create the data stored in hidden folders creates temporary files or artificats outside of the hidden folder, the hidden folder is essentially useless for maintaining privacy or plausible deniability.
This.
You never know what the OS saves outside your encrypted volume. In many cases log files, vm configuration files … reside under /var /home or /etc. I guess seeing some Whonix-VM config file would not be less suspicious than some encrypted drive. Then there is also swap… Sure, you can try to track down most of it and maybe move it to the hidden volume. But then you need to overwrite the non hidden part etc pp and you can never be sure you forgot to move something.
Depending on what is leaked to the non encrypted part of the drive you may be in a worse position than in the beginning.
With FDE you don’t have to worry about this at all.
There is good writeup on plausible deniability here: FrequentlyAskedQuestions · Wiki · cryptsetup / cryptsetup · GitLab under 5.2 and 5.18
In principle it is possible to completly encrypt a drive without a LUKS header so it won’t be obvious that it is encrypted (called plain mode see 2.5).
If you then want to go for FDE you still need to carry some other disk with kernel and initrd.
If you are not concerned about crossing borders but more about friends, family, fools then get a small + fast SD card or USB drive where you can install debian with FDE + whonix VMs. In this way you can easily switch to something less suspicious just by swapping drives.
FDE is less suspicious with each passing day. All iphones are encrypted. Bitlocker use on Windows is increasing. LUKS is common among Linux users. Seems to me that having encrypted volumes rather than FDE is more suspicious and requires more of a “story”.
I’ll also emphasize that security theorycrafting often ignores the costs of complexity. You may want to consider that the chance of you corrupting / deleting / losing the password to your hidden volume(s) is greater than the probability that plausible deniability works in your favor.
I’ll go out on a limb and say the proprietary OSes (at least in Windows case) have subverted FDE. Because they either designed it with a flaw or upload the keys to the “cloud”. If someone knowledgeable enough comes across a Linux FDE he will be more suspicious because they know that you know what you’re doing.
If encryption is forbidden where you are they can always torture you a little bit more to turnover the hidden volume passwords even if they don’t exist, because they have nothing to lose in doing so
But I wonder about the different scenarios discussed in this thread. It’s either that the device is viewed by harmless adversary or by all-powerful experts.
I think a common case may be that it’s seized by those who do have authority over you but do not have the expertise for complex analysis. Maybe they fit into the “fools” definition in the quoted paragraph.
In this case I would always rather have something innocent and easily accessible, as any normal person will have. If it’s a USB drive, I’d like to have a film there or something. Why did I hide it? because the film is pirated. I used a torrent to get it.
Another question - is there a “self-destruct” mechanism in any of the encryption solutions? Say - if a certain password is entered, data is wiped instead of being decrypted. Or even, if the drive wasn’t accessed for say a week - automatically wipe it next time someone tries to access it.
This would all depend on the situation. Saying you committed a crime (pirated) may not be the best idea since this may lead to further suspicion? Whats stopping them from sending the USB out for further analysis? You may have just given them a reason to do this.
Obviously your course of action would be decided on a case by case basis. I guess its all a matter of your threat model.
Kali linux has a nuke patch for cryptsetup which nukes all key slots when a certain password in entered
In many places its SOP to make multiple copies of the hard drive. This may not provide any benefit.
Because everybody does it, but it’s just an example, perhaps not the best one. Maybe place my bank details there. Or a password manager software (and supply the master password if forced).
Nothing, if that’s an advanced adversary. Otherwise, it’s expensive and time consuming.
Yes. Problem is we make assumptions. Assuming the worse is one thing, but sometimes solutions are disregarded (“don’t bother”) because they won’t work in the worst case, although they may work in a bad-but-not-worst-case.
Agreed, most advice given on the forum and elsewhere is always about worst case scenario. This advice may only apply to 5% of the actual cases (BTW I just made that number up). For the other times a little knowledge and common sense prevails
this is true. and quite frankly, unless an attacker is kicking your door down while you are near a machine that has the patch installed, this patch is pretty much security theater.
You could use this when asked for your password when crossing a border checkpoint.
This would likely get you in more legal trouble if officials found out so its not really plausible. Plus they may copy the HDD before entering the password for further analysis later on.
I remember reading from the Kali devs (can’t find it atm) that they don’t think that this is really a good/safe option in most Cases.
This, even if you had a attacker this stupid to let you “nuke” the disk, they would be even more eager and persistent to lock you up, plus its common like @0brand said to copy the Disk before anything happens.
