Hi, I'll try to be brief for clarity's sake, but if you need any additional info please ask away. I need help in designing an encryption scenario which gives me plausible deniability What I have: - Two drives, SSD and HDD What I need: Two encrypted windows systems ("Safe to reveal" and "Hidden") on two different drives, completely invisible to one another. I need to be able to run 1. or 2. depending on password given at boot. If hidden volumes come into play, a list of what to do after what would be appreciated, I've worked with TrueCrypt, just not hidden volumes. Additional problems that I see: 1. Since my SSD is small I can't fit both OS's on 1 drive, therefore when running "Safe" OS (from HDD). This takes away a bit out of plausible deniability - the SSD is there physically and not visible by the OS. One possible way around that (maybe I'm reaching) would be "Hidden" on SSD inside a hidden volume, which to the "Safe" would be visible as a 100gb free partition (I can put some fake data there). "Safe" - Win7 "Hidden" Win8.1 As stated above, a list of things to do in order would be appreciated. PS. As a bonus, if we can add a livecd of tails of something of that sort loaded from RAM as third boot option that would be great! Thank you!
Can be done for sure. Not a "starter's" configuration though. I don't know what computer skills you are bringing with you, but I notice its your first post. Welcome to Wilder's. If you want to work with TC you have to know that the bootloader for Win 7 is different than the one for 8.1. What that simply means is that you will use a bootable usb to mount the hidden OS and the loader for the other OS could be on the machine. You cannot use one loader for two different OS's with the standard TC software. You would have two loaders in this case and the workability becomes fine. The downside is that you would be responsible for "hiding" the bootable usb from any adversary. Discovery of the bootable usb would "dent" your plausible deniability. You don't have to worry about the liveCD/tails because loading in RAM from an optical drive will supersede the other systems and can be done at any time. All would run in RAM in that instance and would not bother the other two systems during use (excluding operator errors on your part). Lets just acknowledge that TAILS can be started at any time and it runs in RAM. Done lets move on. There are many ways to accomplish what you want to do. Lets concentrate on having a hidden OS available that doesn't show to an adversary. I don't care which version of windows you use the process is the same. For now I am going to put the decoy/can be shown OS on the SSD and forget about it. I will assume you can do that using either TC, Bitlocker, VeraCrypt, etc.... As per your case needs you want the two drives to be independent of each other in a sense. For safety after you have created this decoy remove the SSD preventing it from being further tampered with. However; make sure to create a TC rescue disk IF you encrypt the SSD. This helps you to gain access to the decoy OS if something goes wrong with the headers. Now lets put the HDD in the machine and build what we need. For now I am going to assume you know how to forensically prepare/wipe the disk platter before starting. If you have any doubt STOP right now and make sure this is done and not skipped. Once wiped clean, now we build our partitions assigning geography/partition sizes as needed. Your minimum is two partitions with the second being at least 5-10% larger than the first. At this point I don't know if you are dealing with a 200 Gig drive or a 2 TB drive. Overview: you are going to use partition one and create a temporary decoy OS of the system being used in the hidden OS. Once its created you will make a backup of it. You MUST possess the skills to do a reliable backup and restore of a complete operating system. If you don't know how, STOP and gain that skillset. After the decoy is created with TC installed into it go ahead and create the hidden OS. Read the TC manual to discover how its done. Not tough. I've done hundreds of them using scores of public and private binaries. Now you have a hidden OS up and working BUT again your backup skills are being called upon. I suggest you make a sector image of the hidden partition (complete partition not the hidden OS). This will be needed if you ever need to do a restore, and its easy to do those restores with the proper skillset. Hang in there we are almost done with instructions. All backups are done and the hidden is working fine. Next we are going to create a bootable usb flash drive with which to mount the hidden OS. There are several guides here and I have scores of them around the net. This too is an easy process. This step is a requirement because when we return the SSD and its bootloader to the machine itself, THAT bootloader will not mount the hidden OS (its different). Lets assume you have created a working usb bootflash and backed it up for safe keeping. Now fully wipe partition ONE on the HDD. After that you can format a normal partition there and use it for normal file storage or whatever ----- BUT ---- do not change the partition size. I don't intend to disassemble TC code here so just follow that instruction. Picture this in your mind's eye. A computer with a second HDD for file storage and the owner wants those files encrypted. His operating system on the SSD (decoy actually) needs to be able to access those files for plausible deniability, which it will be able to do. It can't mount the hidden OS but it can mount the outer volume, which hides the fact a hidden OS exists. This is your exact scenario. You mount the hidden OS using a bootable flash and IF the flash is well hidden there is no proof a hidden OS is in existence. I don't imply this is a complete step by step but it will get you up and running. If you are NEW to all of this you have some learning to do. Sorry, but I don't have time to do a manual tutor on every step. Also, I don't discuss code here, except in "box diagram" terms.
Thank you for the warm welcome, quick and so thorough reply! Very good point about secure erasing data, I'd probably miss that and I have to read more on that, especially that SSD is involved and just rewriting the data x times will not be enough. As for backups, I've been playing around with clonezilla so I should be fine. I see now that 1. I've made some mistakes with my assumptions 2. I wasn't clear enough which system will be hidden and which decoy Some more info: SSD : 128GB : Hidden OS : Win 8.1 HDD : 700gb : Decoy OS : Win7 One more thing is, to quote you: "Picture this in your mind's eye. A computer with a second HDD for file storage and the owner wants those files encrypted. His operating system on the SSD (decoy actually) needs to be able to access those files for plausible deniability, which it will be able to do. It can't mount the hidden OS but it can mount the outer volume, which hides the fact a hidden OS exists. This is your exact scenario. You mount the hidden OS using a bootable flash and IF the flash is well hidden there is no proof a hidden OS is in existence." This scenario would indeed be perfect. Our problem is that I want to use the SSD not as a decoy but as the hidden OS, which will be the one used on a more regular basis. Therefore to an outside viewer it appears as though the computer has an SSD which is not really used - and it looks kind of cheeky, therefore we're also looking for a way to hide or justify that fact. Updates/changes: 1. I'd like Hidden OS on SSD to have access to another hidden partition on HDD (for regular data). Decoy should not have this access. 2. I'd like Hidden OS to be able to use most of my SSD space. 3. Since there will be 1 OS per 1 drive, can I not use bootable USB to mount Hidden OS? (For example by choosing boot device at startup, with default to Decoy OS). If it's a possibility (and not hurting plausible deniability) I'd rather not have another usb device to boot. 4. Unencrypted part of the SSD can either be or not be visible to Decoy OS (if not visible then full disk encryption could be the way to go, but that could be suspicious for someone if additional unused SSD is noticed. If visible, then perhaps it could be mounted as a folder of the HDD instead of drive letter, that would make fake data less noticable). Is that even valid reasoning? Any ideas on how to make the scenario more viable would be appreciated. 5. Further developing 4. , it might be good to have ~85gb for hidden volume for Hidden OS, and ~15 gb for an unhidden unencrypted (or encrypted) Ubuntu install, which could be useful in other ways. Would that be in conflict with your 40/60% recommendation on initial installation? Plus Fat32/NTFS might be an issue here, right? I know that I'm tossing variables and changing the design drastically, but your advice made me realize the flaws in reasoning. Summary: Maybe I want too much, I know this is a possibility. Please correct me if I'm wrong. If my above idea would be executed without further changes, we'd have: SSD : Two partitions: 1. (Un)Encrypted Ubuntu (or empty NTFS) 15GB (which if I understand correctly would appear as a 100gb partition includding the hidden one). (this needs further thought) 2. Encrypted Hidden Win8.1 HDD: Two partitions: 1. Encrypted Decoy win7 2. Encrypted Hidden partition for Data which only Hidden win8.1 can see) PS. Yes, I'm pursuing the project and this will be executed for sure at some point and I will share the results. I'll try to reply as promptly as I can and I appreciate the help a lot! Having read your post I know that I need more help on the design than I thought, and I'd like to have it all well planned before it goes live. I'm really glad that I've registered and posted here!
Today I can give some general thoughts. Standing back and listening to your "conversational ability" regarding encryption, while realizing that you have never even used a hidden OS in normal configuration, leaves you exposed to additional setbacks along the way. As a student you appear to want to skip a few grades, but have not learned the subject matter in those grades yet. This doesn't mean it can't be accomplished but surely you can see that your commitment to "picking yourself off the pavement" will need to be higher than the average project participant. When I originally visualized the SSD for the decoy its partly because of what you posted above. It makes little sense to tell an adversary that your OS is being run on a slower hard drive when the SSD is 5 times as fast. I know of no single user that has such a configuration and its for that reason. Next, as a beginner using public binaries, you have to remember that in order to create a hidden OS on a drive you MUST first have created a decoy (using significant space) from which to clone the OS. You had stated that the space on the SSD was too limited for that purpose, although your wording was different. I would like to "bend" your thinking some. If you are concerned about speed of the sata you could consider options: 1. use a bare bones windows OS as the hidden OS and it would simply host for virtual machines running within the hidden OS partition. Those machines would be running Linux and that alone would triple or better your speeds. My linux systems run many times faster on the same machine that Windows is running on. In fact the machine I am keying this post on has multiple bare metal OS's, one of which is Win 10. When I boot Windows its actually painful to use because its so slow by comparison. This is not a baby machine. i7 with 16 Gig of ram so its a long way from basic hardware. I am getting great speeds and I am running bare metal Linux, chained to many multiple VM's for compartmentalizing my connection identity. That is outside this thread but shows Linux is light on a machine and so powerful. This is just an idea to consider.
Thank you for your reply! Yes, I realize that the project and requirements exceed my knowledge on the subject, but as you say - I think it can be done. Plus there's a lot to learn in the process. As for the SSD/HDD dilemma - yes, I can see that this makes little sense to tell an adversary that - I guess I just needed a confirmation. So it seems my options are as follows: 1. No plausible deniability SSD Full disk encryption - WIN 8.1 HDD Full disk encryption - Not that it matters for deniability, but win 7 (or maybe linux) plus hidden data partition regardless (if possible) 2. Plausibe deniability (might require a bigger SSD in the future, which is also a possiblity, but not atm) SSD Two partitions : 50gb (win7 or linux decoy) and 70gb (including a 50gb win 8.1 hidden) HDD One partition, but with hidden volume (if possible, if not it would have to be a volume in a file unless we have a better option to not arise suspicion) Hidden volume only visible to Hidden OS (I will definitely need more space than 50gb for hidden OS to use) One more question/confirmation: What I thought I could do but I can't is manually create a hidden partition and restore a backup of a partition there (which would enable me to use more than half of the ssd for the hidden OS). This can be done only by TC, which handles this in the code in a way that requires to have the process done as you described (with 2 partitions on 1 physical drive, which cannot be modified in any way during/after the process). And lastly, I'll definitely give your mindbend a thought. I've been toying with VM's too, but havent based the whole idea of running the pc on VM's "only". What exactly do you mean by bare bones - just the fact that you don't use the OS for anything apart from VM's, or rather something like Windows Server Core? (which is an interesting thought too). I too have an i7 (older generation), and 32gb ram, so there's plenty of room to have fun (for example I have an ubuntu VM running off a ramdisk entirely). Regardless this whole VM idea could go into play to both options above by creating another hidden OS on HDD or if Hidden Data partition is possible even the whole SSD could go for a hidden VM Storage. What software are you using for VM's?
I've read some more about the topic and there are more problems that I see: 1. When accessing hidden OS all non-hidden partitions are mounted in read-only mode. This is a huge problem for me because I have the second HDD which I want to be able to use and don't want it all in hidden partitions. 2. It's a problem to install Hidden on SSD. I'd want it to be NTFS, so hidden would have to be 2.1 times larger. It would mean that my Win8.1 system partition would have to be 40gig, which is problematic. I could create another hidden partition on SSD and even mount it in a folder of Hidden OS system drive, but that would be fiddly in usage after a while. So the real question here is : Is there a better encryption software, which would enable me to play around with partition sizes (for instance install win8.1, then backup whole partition and restore it to a hidden volume and then make it bootable).
Some of the questions you ask encroach on my personal privacy and I can't/won't reveal my specific configuration ---- you should understand that. I am ok with you asking but just know I don't reveal specifics many times. A large part of my postings are reflections of over a decade of site mgmt with TC, even though I have made a disclaimer here before that I mostly use Linux now, excluding archival off premises large storage media. Further disclaimer; I actually have moved from TC to VeraCrypt but know that TrueCrypt is a fine product for archives still to this day. Lets answer some of your post. #2 above: Just want to make sure that you understand the hidden OS can be NTFS while the outer shell can still be Fat32. This would greatly reduce the space wasting you mentioned and cut the overage to 5-7 % max. Regarding #1 above: I understand that reservation. There are many ways to get data out of the hidden OS sort of bypassing that code restriction. e.g. - CDR/DVR will write files out fine. VM - basic virtual machine where the machine is configured to grab the usb controller from the host and you can write all files from a shared folder on the hidden OS to your external drives by going through the vm "workaround" and it works without a hitch! If you were going online with the VM there would be some small security risks with virtual additions, but in this case the VM is ONLY being used for data transfer via usb to an external HDD.. Its a safe method therefore. Finally, if you want to become "expert like" you can grab the source code and re-compile your own binary removing that write block restriction if you wanted to. While many get angry over the restriction it protects from operator errors causing security problems. Disclaimer: for the last few years I was running a hidden OS I had private binaries with that restriction completely removed, so I don't want to be a hypocrite here. Remember I don't do code here. Lastly, you had asked about partition geometry. There is alot of stuff you can do with moving partitions and placement of large data chunks anywhere you want on a disk platter. The issue is for a user to become advanced enough to learn how to "call out" and address that data via specific disk location. You would be leaving canonical calls and using exact byte location, which requires code modification since "out of the box" TC wouldn't have a clue. Its also possible to use advanced Grub4Dos methods to manually address a disk platter and leave TC code alone. In this case any calls to the disk would happen before TC ever "woke up" and its done in RAM pre-boot.
