I am not sure I agree with your conclusions. I don't find it tough to keep backups of the hidden OS. I can restore it in under a half hour. Further if "pressed" I can restore it for an adversary and demonstrate why I have the sector based backup available. The DATA on the second partition of my drive is extremely valuable and private. Because of the sensitive nature of the data (in the outer volume) I prefer to use TC encryption, which is automatically available via sector cloning. Its very simple and "one step" to backup any partition on my drive. I have ALL partitions backed up by sector so the second doesn't stand out as unique in that regard. This method also clearly means that I am not at all worried about physically hiding my removable drives. I don't need to hide something that is legal and I have good reason to need. Next, I differ in the conclusion that a hidden volume is not all that deniable (assuming no operator errors). About the only argument usually presented is that you have a 100 Gig volume with only 20 Gig in it. Well, that actually defines many of the unencrypted system disks in use. If I create a large unencrypted system disk and only use 20% of it, you would not consider that beyond the range of normal. However; if I do the same thing but now encrypt it because I want the contents to remain private, it somehow means that I am hiding data in the volume? I agree that even the use of TC will cause suspicion, but suspicion is completely different from full blown confirmation such as with Linux. I would rather face an adversary with suspicion, than one with confirmed encryption such as DM/Crypt LUKS. In the linux option I am simply saying NO WAY I will provide a password. If you stop and think about it, is that something YOU would be willing to do? Forgetting "rights" and considering the whole puzzle, its a tough call. Clearly, using multi hops and methods management to keep the "wolf" away is the best. I am just saying that at some point we all must consider the fluke that the "wolf" comes.
I use my decoy OS almost every single day. Continued usage "marks" it as needed. I just make sure any "marks" are all good stuff!!
I can imagine using the decoy OS every day for non-private true-name activity, and using the hidden OS for private more-or-less anonymous stuff. That way, the decoy is very plausible. However, switching from one to the other requires rebooting, right? So let's say that you use the decoy OS for a while, without any VPN or Tor. Then you reboot into the hidden OS, connect with VPN and/or Tor, and do private stuff. And then you switch back, and so on. If an adversary looks at your decoy OS and ISP logs, they'll see that there was no activity on your decoy OS during periods when the VPN was connected. You could address that by using a VPN for everything, and using a second VPN and/or Tor while you were using the hidden OS. But maybe the adversary would get the first VPN's logs too. I wonder if there's some way to set up decoy OS and hidden OS where both could be active at the same time. Maybe the hidden OS could run as a VM. One TrueCrypt passphrase would bring up just the decoy OS, while the other would bring up the decoy OS, with the hidden OS running as a VM.
So would a bootloader password and Bios password prevent Evil Maid? https://www.centos.org/docs/rhel-sg-en-3/s1-wstation-boot-sec.html
It depends on the Evil Maid's imagination and capabilities. Also, I'm not sure just exactly what sorts of attacks the term covers. With repeated physical access, anything is possible, including substantial hardware modifications. I'm also informed that Joanna Rutkowska of Qubes fame coined the term.
Except that I use a live linux flash (physical read only switch enabled) on an old desktop computer many days. There is NO harddrive in that machine. I use that for family members needing internet and also for myself. There are full days that I use live linux and never put a single mark on a computer of any kind. The computer with the decoy OS may not even get used on some days. All machine MAC stuff and router logs are "handled". The entire reason that I use this approach is because the older machine is too slow with windows and the old IDE drive just gave out. Running linux its perky and I don't need a drive. I can save stuff on a flash (enter TrueCrypt with volume options galore) This would be my retort and its true indeed! So my usage of my internet answers your point without me doing anything different at all. LOL!!
That is pretty cool It could never work for me, though. I manipulate far too much data, just about every day.
Reading between the lines on my post above yours. What I am saying is that would be my answer if questioned.
The HiddenOS feature in Truecrypt is wonderful on the paper, but there is a crucial tradeoff I personally can't stand: the decoy OS can ONLY be Windows, and for it to be plausible you need to use it every day - in fact you should use it for pretty much EVERYTHING but your "hidden" activity. I can tell you I'd NEVER use Windoze for my "normal" stuff, because while it might not be "top secret", it is still confidential/private business stuff that I do not want to handle in such a bad and insecure OS as it is Windoze. With pain in my heart I could accept running OS X as the "decoy"* OS, it might be backdoored but at least works well, but I'd never accept Windoze. I guess its just a matter of taste - I left Windows for goods+10 years ago and I don't want to ever go back to it. *I wouldn't even call "decoy" OS the "non-hidden OS", as I think it should be used for EVERYTHING except the "hidden" activity if you really want plausible deniability. Thus, I would call them "main OS" and "hidden OS".
You can run a hidden OS out of the second partition (which is essentially just a "container" with a decoy and "hidden" part) and have Linux as the "Decoy". This requires "not following the complete directions", but it works. Just don't re-install Windows - install Linux instead. You need to make sure you can boot from a USB, where you put the TC rescue disk.
PD, That plan works very well. There are several threads over at the TC forums about how to do that. Its easy to do. For me the largest issue is still that for the "high threat model" hidden OS stuff, you still need a windows host. I personally don't care about the windows regular OS, although I do use Linux much of the time even on that. I don't conduct sensitive business there but I do use it for banking and personal emails. Best of both worlds would be for someone trusted to write a hidden OS Linux software. I am not at the point where I could finish that project and run natively. I could create a Linux live distro with TrueCrypt and VirtualBox in the code/distro. That is easy enough. Inside a hidden volume, which would be on a fully TC encrypted partition, is an available linux VM running TOR. I know it would work but the non-native limitations to this method would have drawbacks. As always, you would seed the decoy volume with sensitive and plausible data to explain why the partition is encrypted. This way you could save everything you need on the hidden volume and still keep the "live" part squeaky clean. The regular OS would be just that, and create no reasonable suspicion of anything going on. You would occasionally access the outer volume from the regular OS and change some data to keep things looking realistic. I don't especially like this model but it is as close as I've come with my "code writing" abilities. LOL!!
As soon as I find the time, I'm going to try to prevent the Windows host in the hidden OS, from communicating -at- -all-, while allowing a Linux VM to access the Internet. No one here knows if it will work, so it will have to be tried. I have never used a VM, so it will be a learning curve. I read that Hyper-V can grant exclusive use to a network adapter only for the VM... but since we're trying to get away from MS communicating, I hope either VirtualBox or VMWare could do the same. It'll either be NIC tricks, or Firewall rules... just have to play around.
Follow-up to the last post: I blocked all connections in Windows 7 firewall, but the VirtualBox virtual machine in bridged mode still was able to access the internet.
Cool But what about Windows update etc? Does the firewall see everything? One could check that in the LAN router. Also, given that the bridged VM gets its own IP address from the LAN router, one could block everything from the host there. Edit: I should read links before posting In the thread that MrBrian links to, Incredible Hulctuary did just that (except blocking the host by MAC, rather than by IP address).
I blocked all connections on the Windows 7 host, so I assume Windows updates won't function on the host anymore. I wonder what percent of malware uses similar techniques to achieve stealth (it would need admin privileges to install a driver).
I don't know Windows well enough to bet one way or the other. But I vaguely remember something. Rootkits can do anything, right? They could even use covert channels
A few things come to mind. 1. I actually use the host OS to form an obfuscated bridge linking the first VPN to my ISP. I need/want that bridge in place because my linux VM's are running TOR, and I don't want my ISP to EVER see TOR being used. Anyone connecting to TOR without a bridge is ISP "tagged" pure and simple. 2. Supposing 7 as a host is locked down from communicating. You could open a linux VM and use that to secure your initial VPN tunnel. Further lets assume all the dropped connection, dns issues are resolved. Now for me its time to introduce TOR (TBB) but only via a bridge as described above. I am not convinced that running TOR out of the same OS as the one hosting the bridge is anywhere near as "isolated" as when they are separate. So is there a way to run separate linux VM's with the first acting as the VPN tunnel host/bridge, and the second as the TOR browser system? This would provide the isolation I am looking for. I can easily set this up running linux native for the tunnel and the VM for TOR. That would take the 7 hidden OS host out of the loop though. 3. I am really enjoying reading this thread as you guys discuss locking down 7 and trying to use it only as a simple host. I know this runs contrary to what is circulating, but I wonder if an older "basic" raw 7 install without the years of updates would actually be a safer option. If M$ has introduced any (enter tin foil hat) backdoor updates they would all be missing in this model. To tell you the truth I am much more concerned about "big brother" than some geek with a malware toy. As discussed many times in this forum, I defy anyone to present actual evidence of malware breaking out of a linux VM and getting to any host. I would like to hear your thoughts on point 3 and any other points as well.
Yes, I'd much rather have my ISP see VPNs than Tor. The Tor people, however, don't see it that way. Maybe it's just that, in their vision, everyone is proudly running Tor Isolation is always better. That's the point of using a pfSense VPN-client VM. You could do it with Debian, of course. But pfSense is already set up as a router, and it's also set up to run VPN links and route them securely. If you add Whonix, you get a setup where the VPN connection is isolated in the pfSense VM, the Tor client is isolated in the Whonix gateway VM, and the workspace is isolated in the Whonix workstation VM. Although I'd still be suspicious, what evil could a Truecrypt-hidden Windows 7 host do without network access? It could log everything, of course. But nothing would leak, unless Windows somehow gained Internet access through one of the VMs. And that seems unlikely, for a plain Windows 7 install that hadn't been "customized". Would it be necessary to keep Windows 7 activated, if it were just running VMs?
Mirimir, Let me condense your post into an overview that I would consider trying. For now, I would eliminate Whonix and can add it back in later. 1. I remove all connectivity from the hidden 7 host OS. It merely hosts TrueCrypt's hidden OS and that is it. 2. The 7 host OS will have VirtualBox installed. 3. I setup a pfSense VM in linux and it will be responsible for supporting the VPN bridge/tunnel. All dropped connection, dns issues, MAC changing, etc. will need to be fully resolved inside this VM. 4. I build a linux VM and run TOR (TBB) exclusively from that machine. I keep a perfectly clean VM original and use a clone. Periodically I delete the "dirty" one and keep starting with a clean machine. This model allows for a hidden OS, but it relies upon the use of 7. Conversely, I could just use Linux native and make my bridge there, and then employ a VM for TOR. It would be LUKS encrypted but wouldn't be hidden. Decisions!! Questions: Does my model above seem adequate? How would internet performance compare between the pfSense VM and the native 7 OS bridge? I am trying to decide if that model is worth building as compared to just running linux from start to finish. This will be another thread but I am also thinking of MOVING the hidden OS to an unconventional location on the disk. We can discuss the how to's in another thread. By having it elsewhere it would be better cloaked if your physical machine ever feel in the wrong hands!
The hidden Windows 7 needs to be blocked in the LAN router. That might be a giveaway. But using the same rules to block the decoy Windows 7 would provide deniability. You'd just inactivate them as needed. pfSense isn't a firewall that you install in Linux. It's a router/firewall OS that's based on FreeBSD. That's very secure You can do the same with Whonix clones, by the way. Yes. I use Linux and LUKS. But the idea of hidden Windows 7 that's locked down to merely hosting VMs is very cool. That looks like a workable plan. I don't think that pfSense VMs slow Internet connections. Whether or not it's worth doing depends on how much having a hidden OS matters to you.
After considering the overall approach I was thinking why not completely blow away the wireless card's driver (from the hidden 7 OS)? I would backup the driver (e.g. saved on the 7 desktop since its really a small file) using Macrium so it could be restored in seconds if I ever needed 7 to be able to connect. Nothing could be safer than having a 7 OS on a laptop with NO possibility to communicate because the wireless card is "dead in the water". I would still do the other fundamental steps to isolate 7 from the internet. Unless you are really going "tin foil hat", 7 on a laptop without wireless is not talking to anyone. Period! I have downloaded the latest pfSense and I am reading over at their forums. Also, I am looking through the pfSense instructions Mirimir posted at ivpn and linked in his signature here. If I proceeed with 7 as "dead in water" to the internet, I will then be relying upon pfSense for constructing my VPN bridge. I have a bunch to learn because of how I will use this VM. DNS appears easy to control using pfSense in the high privacy model as described by Mirimir. Strict DNS control should handle dropped connections as well. I also want to be able to change the MAC to match other machines in networks I use. Hopefully pfSense handles MAC easily. I haven't researched that far yet. Assuming this project is successful, then I would feel comfortable with 7 as my host. In fact a hidden 7 with this design seems safer to me than the linux model, which would NOT be physically hidden from an adversary. Tin foil hat thought: since my hidden 7 OS is WDE encrypted it would not matter if somewhere on the 7 drive there is a file stored/concealed by windows to betray me. That file would never be able to get to the internet. In the currently used 7 models we have no way of knowing if something sinister by windows is "riding along" with other data going into and out of our systems. Down deep we suspect something is out there. This project would address those suspicions. Any other links to assist me/us with using pfSense expressly as this project dictates would be appreciated.
@Palancar Yes, for a laptop with only WiFi access, trashing the WiFi driver in the hidden Windows OS would keep it offline. But what about keeping Windows activated? Doesn't Windows 7 disable stuff when not activated? Or is running VirtualBox just not one of those things that gets disabled?
Using the latest pfSense 2.1 instead of 2.03, there are a few changes. The VM now needs 512K RAM instead of 256K. Bloat? Also, pfSense 2.1 is fully IPv6 capable. So there are a couple of extra questions about IPv6 if/when you change interface IP addresses using the console. Most importantly, you can turn off IPv6 entirely. Using the webGUI, in "System: Advanced: Networking", uncheck "Allow IPv6" and save. Also, in editing "Firewall: Rules: LAN", delete the default IPv6 rule.
