SurvivalBlog.com

Welcome to all the brave souls that didn’t scream and/or quickly scroll on when reading the title. I know a fair percentage of SurvivalBlog readers are concerned about OPSEC, but what about your electronic OPSEC? Is it as good as it should be? As good as it could be? I promise you won’t have to read the entire submission but you should take a look at the first few paragraphs to determine if its something you need to address. If you do, you can always try to find some trusted help in securing your systems. During the second half of last year I have spent a fair amount of time reading up on the subject and, as a result, have done a complete overhaul of my own computers. This is a description of some of the things I have learned and it might be useful for some of you.

So what are we up against? Actually many things depending on your time horizon. At the moment your biggest concern may be that your laptop contains information that you do not want to be made public when it gets stolen. This is the easiest to deal with because its unlikely that the thugs have much interest in your information; most likely they just want to make a quick buck at a pawnshop or on the black market. The situation gets more complicated when someone is after your bank/credit card information, etc. You will have to assume that these are more knowledgeable individuals that know what they are looking for and how to get it. The next layer up is industrial espionage, though I doubt many of you will have to worry about that. Real problems start when you are flagged by national security agencies (yes there are many NSAs) because you have to assume that they employ some of the most intelligent people and definitely have the most advanced equipment at their disposal to crack passwords, scan hard drives, scan working computers, backdoor access, etc. The biggest headaches are of course created by politicians and bureaucrats who these days seem to change laws any way they want whenever they feel like it. What is perfectly legal today may be outlawed next year. Even if you dutifully delete any ‘offending’ material from your hard drive at that point, I can guarantee you a low level scan of the drive has a good chance of recovering the documents afterwards. Which probably would still be used against you if someone was out to get you. Just another reason not to wait till the last moment to take action. How far will this go? Of course I don’t know but my gut feeling is that 10-15 years from now you could easily be labeled a terrorist because you have a copy of the KJV Bible on your hard drive. There are plenty of places where that is already the case today. Having a copy of the SurvivalBlog archives visible on your hard drive might land you in hot water, too.

The second challenge is the ever increasing ability of electronics to weave a web around us. I am sure you know by now to expect no privacy on your cell phone. Its encryption was cracked years ago and a call can probably be decrypted in real time. The same goes for just about anything you access on the internet. If you want to get visual confirmation of this, install the Lightbeam extension for Mozilla Firefox (it shows up as a tiny ‘cube’ at the lower right hand corner of the Firefox window’s add-on bar) and browse normally a few days. Then click on the cube and see how all the sites you visited are connected and by whom. You have probably read how the GPS data on your cell phone can be used to trace your whereabouts and perhaps even that at some airports travelers’ cell phones get taken out of their baggage to be ‘checked’. 20 minutes later they get them back; presumably minus the clone that was made from device’s internal data store. But it goes beyond that. How many of you have read about the shipment of Chinese electric water kettles that were held by Russian customs because they contained microprocessors and wi-fi chips capable of connecting to any wi-fi network within 650 ft. They could (and tried to) call home using the wi-fi connection. Now there is an interesting spy right inside your house.

But if the water kettle can do it, why not the fridge or your new alarm clock or … Do you have a laptop with a webcam? I’m sure the laptop has a microphone. Have you read that the tools to remotely control them are easily available on the Internet? If not, try this link. Do you have a shiny new XBox One? It can log you into your account when you walk into the room, so you are ready to resume playing your favorite on-line game the moment you hit the couch. Sounds nice, but think about it: it must have built-in facial recognition software and be connected to the internet to be able to do so. Do you really think no one has ever thought about inserting a remote control client in the system updates that are automatically pushed down to your hardware. Do you have a D-Link router? You can send it a special code string that allows you to bypass authentication when updating its settings. Very useful for when you forget your password. Apart from a numerical code, the string reads ‘editedbyjoelbackdoor’ backwards (I know: you can’t make this stuff up.)

Have you ever heard of WiSee? Its a technique that allows your wifi router to figure out where you are and what you are doing. I am quite sure there are many more innovations in the pipeline. Most (lets say 99%) of the people won’t think anything of it because they find it convenient. Eventually you might even be seen as a threat just because you refuse to put all these gadgets in your house: you must have something to hide. And as icing on the cake, see this and this.

What to do against all these threats? Well, becoming a Tibetan monk would be one option, though its a bit drastic. Actually if you’d rather stay home, the best thing to do is what I would call passive resistance because a bigger gun or more bullets isn’t going to get you anywhere with this. An understanding of your adversary’s tools and tactics, on the other hand, will give you a much better chance to escape unscathed. Let me try to explain the term passive resistance in more detail. During WWII in Europe’s occupied territories, most of the population was engaged in some form of passive resistance. A few engaged in active resistance but they were trained and knew what they were doing. Joe Sixpack did not have access to guns and dynamite but was mostly concerned with survival. That largely meant continuing to do whatever it was you were doing before the war with some modifications. For instance, some crops were supposed to be sold to the Germans, however official yields were rather low as part of the crop disappeared before ever making it to market. Sheep were all of a sudden very popular. If you were forced to do some work for the occupiers, slow and shoddy was the norm and preferably disappear overnight. People that housed refugees or downed pilots continued to go to work but never talked to anyone about what they hid. Things were done on a need to know basis: if you weren’t the family cook or provider you didn’t need to know how much food was kept in the basement. Fewer leaks that way. Another important point was to know the enemy: especially later in the war the bulk of the occupying force were conscripts: 16-18 year old kids that would have stayed home if given the choice. They were happy to leave you alone if you didn’t bother them so no need to antagonize them. My suggestion is that when it comes to cybersecurity you consider yourself Joe Sixpack and try to fly under the radar as much as you can.

Flying under the radar is as much a lifestyle change as it is about encrypting your USB stick. You can still use your iPhone, just assume someone is listening in and pick the subject of your conversations carefully. Same thing goes for email: don’t write anything that you wouldn’t say out loud in public. If you really have to have a confidential conversation do it in a place where microphones are few and far between. I read an account of someone from the west who wanted to visit a friend in Russia during the cold war. The Russian agreed to meet him somewhere on a street in town, they walked to the train station, took the train to the next town where they got off and walked out of town into a wide open plain where nothing but heather grew. Only there did his Russian companion think they were safe enough that they could talk without fear of repercussions.

A lot has been said and written about the NSA’s databases. I, too, wish they didn’t exist but I believe that we have to accept them as a fact of life. Regardless of what MSM is going to tell you, neither collection efforts nor databases will be abandoned or even scaled back. So it is important to understand what they can and cannot do with that information. And there is the rub. Computers are great for searching databases for a particular data item. Lets say the computer is told print all available information for your social security number, it will be spitting out page after page within seconds including things that you have long since forgotten and could probably pass a lie detector test denying them. If on the other hand you give a computer the task to ‘find me some terrorists’ it will fail gloriously. Yes, you will get a list of names but the chance that these people are real terrorists is practically zero. The problem is that computers have no intuition, no feeling if you wish. They simply take the criteria that you give them and look for matches. If you set the criteria too wide, you will be deluged with false positives. If you set the criteria too narrow, you will catch some hapless bystanders but not those people that have an expectation that you are looking for them and therefore have actively scattered their trails (think of someone walking through a brook to throw off any canines that come looking for him).

Occasionally one comes across references how all of this will radically change once quantum computers are in production in a few years. I believe that’s wishful thinking for several reasons: – The humans asking the questions haven’t changed. – A few qubits don’t make a fully functioning quantum computer capable of running advanced software. – A quantum computer is not your laptop at warp speed. It requires a totally different programming model that is being developed from scratch. This takes time to figure out, test and reliably implement. Time is in short supply. Otherwise you wouldn’t need to prep. Here is a reasonably accurate representation (as near as I can tell from reading other documents) of where we currently are.

I know there are lots of other types of analysis that can be done on a database (been there, done that) but at the end of the day the analysis is only as good as the person setting the criteria. This is the primary reason why MSM talk about so many studies that refute the studies they championed 6 months earlier. Any analyst worth their money can find what his/her paymaster wants to extract from a given database because only the headline result is reported, never the actual query that coughed up those results.

Now that you know this, how can you use this knowledge to your advantage? Let me give you a simplified example. You have never cared too much about prepping but something tipped you off: SHTF in 2 weeks. So you decide to visit every store in your area 3x each week to buy 2 jars of peanut butter. SHTF and the stores are empty the next day. The day after that a hungry crowd demands that police do something, so they run a database cross check on store receipts and quickly realize you must have a pantry full of peanut butter. And so you hear the dreaded knock on the door. Your neighbor who prepped for years bought an extra jar once a month (maybe two if there was a sale) for the last two years. They got way more peanut butter than you but nobody knocks on their door because their purchase pattern would be considered normal with not the slightest hint of hoarding activity. If you have a family of 2 and a baby and buy a large jar of peanut butter every week, that might be deemed suspicious also unless you sell peanut butter cookies. The same thing goes for all of sudden insisting on paying everything in cash at your regular grocery store. Paying cash at a store you visit once a year should be just fine. Like I said: scatter your trail; don’t create pattern breaks and don’t get too cute about it. Its all about optimizing effort/reward ratios: make sure you are not the low hanging fruit.

I will spare you the details about how databases work but you need to understand that, in the example above, the police were able to finger you so quickly because different databases can be easily and reliably connected by matching something called key fields. This could be your credit card number, customer number, store awards ID, etc. Running a tally on any one of these identifiers will quickly show how much of what you bought during a given time frame. Matching the store’s sales database against their customer database will deliver names and addresses. This is basically why the NSA only has to store the metadata of phone calls. Its all they need for their work because if you talked to a ‘person of interest’ you have also become a ‘person of interest’. The phone company maintains names and addresses on those phone numbers and can be made to cough them up one way or another. At which point you can be ‘interviewed’ or ‘bugged’ or ‘tapped’ for more information. Of course most people engaged in subversive activities are aware of this and use throw-away phones with cash pre-paid SIM cards bought in a store without video surveillance. You, on the other hand, had better hope that none of your contacts will ever be caught in a sting operation.

But you are still stuck with those documents that you want to protect for one reason or another. I will try to help you with those too, however things will become gradually more technical from here on. This cannot be helped but you may want to try to stay with it as best you can because having a false sense of security is worse than having no security. If you know that your system is insecure you may make a concerted effort to physically keep the documents from falling into the wrong hands. If you leave your documents on your laptop because they are ‘safely’ encrypted but do not realize that your encryption can be broken in two seconds, your position is a lot worse.

There are two ways that you can protect your documents: – lock down your systems so no one can get at them – lock down your documents so no one can get at them Recapping from what I mentioned earlier: there are simply too many threats to your system (from compromised clothing irons to malware) to seriously consider option 1. So we will focus on option 2: encrypting the documents. This has an added advantage that you can send them anywhere over the internet or even store them in the cloud and be reasonably certain no one but intended parties can access those documents. But you MUST encrypt them on the machine you create them on and not send them somewhere (even within your own house) to have them encrypted for you.

Now for some bad news: regardless what type of encryption scheme you want to use to protect your documents, YOU will always be the weakest link in your security chain. This is because you need a password. Whatever you choose it will orders of magnitude less secure than the computer generated key that encrypts your documents. People who study these things say that you will need a password of at least 40 random characters (think software activation keys) to match the strength of a widely used encryption key called AES-256. [If you happen to be one of the people who study these things: I know I am over-simplifying but this is intended for novices.]

The way most encryption schemes are working is that the document itself is encrypted by an established cipher for instance AES-256. The computer generated encryption key that is used for that purpose is, together with other relevant information, stored in a header that is added to the encrypted document. Document + header is usually referred to as a container; however a container can be much bigger and hold multiple documents or even an entire hard disk. In those cases all documents in the container are encrypted with the same key. Storing the encryption key with the encrypted document defeats the purpose of encryption unless you encrypt the encryption key with another cipher. This is were your password comes in: it is used to encrypt the document’s encryption key. So if you use a weak password the encryption key will be quickly recovered and the document can be as easily accessed as when you type in your password. In this scenario the use of AES-256 encryption simply gives you a false sense of security because no one in his right mind will try crack the encryption key: they will go after the way you have stored it.

In order to make your weak password stronger (i.e. harder to crack) most security algorithms add salt to it. In cryptography ‘salt’ refers to a random string that is concatenated to your password before it is encrypted through hashing. A hash function is a mathematical one-way street: you can store the hashed value in plain sight because no one has found a way to reverse the hashing function yet (at least that we know of). The next time you enter your password, the computer goes through the same hashing process; if the result is the same as the stored value you are granted access. Cryptographers not only use salt, sometimes they also use pepper. This refers to the use of a third input into the hashing function. This can be a static random number that is stored in a place that is not associated with the protected container. Programs like TrueCrypt have the ability to derive this third value from one or more files called key files, which opens up a whole new set of possibilities.

In my own setup key files play a very important part because: – they thwart any and all key loggers since no keys are pressed to access them. – I set the system up so it knows where the key files should be so I don’t have to worry about webcams looking at me selecting the files. – the key files do not need to be on the system: you can put them on a USB stick or wherever suits your needs. For instance I store one of the key files that protect my document vaults on my NAS (Network Attached Storage.) If my laptop gets stolen and taken beyond the range of my wireless router, its container locks up because the required key file is physically unavailable to the hashing process. The information in that container is now protected by 1536 bit encryption. That is the equivalent of a 192 character password and I wish the thief good luck trying to open the container. – In a similar arrangement you can put key files on a flash drive or (micro)SD card and carry them with you so only you can access the vaults, even if your password is easy to guess. A microSD card has the advantage that it can be easily disposed of in an emergency.

When you do use key files, make sure they are write protected. Even changing a single bit (i.e. changing a ‘d’ to an ‘e’ in a text file) will render your container permanently closed. The same goes if you use pictures as key files. Some viewers have a habit of updating exif data without asking. This will also permanently lock your data.

Because most of my containers are protected by two unique keyfiles, there is a lot of information to keep track of that I do not want to memorize. All this information is stored on the computer itself but in order to keep these things under wraps, they are stored in their own small container that I think of as a systemvault.

And how does it all work once its set up? Quite nicely actually. I have an icon on my desktop that I double click. Then the computer asks for the container’s password and, if I make no mistakes, opens the container to make all documents inside freely accessible. If I double click. the same icon again it closes the container. Doesn’t get much simpler than that.

There are other, more nefarious, threats to your encrypted document. Why would someone try to crack your encryption if they can simply read your password with a key logger or watch your fingers with a remote controlled webcam? There are many programs (called trojans) and viruses doing the rounds on the internet with only one purpose: to get your information. Passwords are worth money on the black market. The password to your encrypted vault may not be worth as much as that of your bank account but who knows what’s lurking out there. So you have antivirus software installed to keep those intruders at bay. [Remember who is the weakest link …] Now tell me honestly: how many backdoors are there in your computer’s operating system? They are not detectable by your antivirus software but grant complete access to your computer by anyone who knows how to exploit them. Someone could make a copy of your document as you are creating/reading it and send it to command central without you being aware that anything is going on. At least until they choose to notify you, possibly via the local SWAT team.

Now what do the paranoid do? Well, they stick to using open source software where the source code can be freely inspected by anyone interested [The really paranoid download the source code and then go on a customizing spree; no, I’m not kidding]. They refuse to load any software for which the source code has not been published. The latter usually being referred to as a binary blob. Most computers, tablets and cell phones run on binary blobs. All versions of Windows, OSX, iOS and Android are at least partially closed source. Some people insist that Microsoft has included backdoors since Windows95. The fact that Microsoft’s monopoly was never broken up (unlike AT&T) is considered more proof of nefarious activities. I am not saying that there are backdoors because that is hard to prove without access to the source code. I will say that the silence of US companies while complying with DOJ/NSA (at least until Mr. Snowden’s revelations caused their foreign clients to bolt) suggests that it is not a stretch to assume the worst about their products. And so I prefer to avoid them. And so should you if you are really into OPSEC. My personal opinion is that anyone who says he’s got a secure system while running one of those blobs is misguided at best. I am not even sure I would want to receive an encrypted document from him unless its in a way that’s not traceable. However that’s no different from getting a call from someone that sits in front of his XBox One. If you really want to improve your cybersecurity, you’ll have to run a Linux distro without any blobs. Please don’t read this as me saying that those distros cannot be compromised. Its software so, yes, of course it can be ‘adapted’. Its just that its a lot harder to do so unnoticed for any length of time and since Linux is used on fewer PCs/laptops such activities don’t deliver a lot of bang for the buck. Again its a matter of making sure you are not the low hanging fruit.

Next up I want to expand a bit on my systems’ overhaul. Three things were involved: -1- I switched the file system for my external drives to Btrfs. This isn’t security related but it provides checksums on files and folder structures and self-healing capabilities based on built-in redundancies. This should help preserve data in case a drive starts getting worn-out or external backups deteriorate faster than expected. I don’t think its all that useful for system drives yet because you need to run a separate command to release the space taken up by deleted files. -2- The installation of a number of virtual machines (VMs) for specific tasks like on-line banking, email and secure browsing. Since most of the VMs only take up 2GB-4GB in disk space its not a big deal to create a few extra. Mine actually reside on a USB stick with room to spare. The idea was to avoid cross contamination by programs or web sites trying to access cookies they did not put there. For instance the banking VM is only used to talk to my bank’s servers and to store bank account related passwords. -3- Creating a number of encrypted containers. Most of the VMs have their own container which stores passwords, documents, browser settings, cookies, etc. This container needs to be opened before the VM is all that useful. Other containers store documents permanently or are used to send documents over a local network in encrypted form.

After going through these steps and relocating a number of files, my systems are now very much plain vanilla if you start them up. They appear to be used for some general purpose web browsing, playing a few games and contain some music. One of them stores scans of old photographs. Nothing out of the ordinary. You won’t even find a copy of the text that you are reading at the moment.

Let’s take a bit more in-depth look at my setup: Step -1-: If you don’t know what I am talking about; just forget it. Step -2-: After reading up on my options (there are several VM vendors) I settled on Virtualbox. Its consistently ranks at or near the top in tests and is very user friendly. You install Virtualbox like any other application. I use version 4.2.18 from this site because that was the latest in the 4.2 series at the time. Don’t forget to download the correct extension pack from the same web page. The software is free. Why? Basically you are one of their beta testers, which is why you want latest stable build, not bleeding edge. The company makes its money by selling fully tested versions to enterprise customers. Once you run the program, it presents you with a wizard to take you through the steps of creating a VM; the wizard will warn you if you select the wrong settings.

If you don’t succeed the first time: a VM is just a specially formatted file on your computer; you can always delete it and start over to try again. Once you have created your virtual machine, you need to install an OS in it from an iso image just like you would on a normal hard drive. When the installation is complete you can click Virtualbox’ start button and the VM boots up just like a real computer. As with all powerful software there are a few extra things you should learn like how to share folders between VM and host, use a clipboard to copy documents in and out of the VM and optimizing the VM’s drivers and settings. You can get by without these but won’t be quite as productive. The minimum hardware configuration to run VMs without too many crashes/performance penalties seems to be: dual core CPU and 1 GB ram (though 2 GB works better). Step -3-: There are several programs that create encrypted containers in a variety of ways. After looking at them I decided to go with the Linux equivalent of TrueCrypt because it seemed to be the best fit for what I wanted to achieve. I know Truecrypt is open source but Linux distros generally stay away from it for licensing reasons. According to a person that was involved in vetting TrueCrypt’s license, it is worded in a way that allows the developers to sue you if you use it for its intended purpose. When the developers were alerted to this their response was along the lines of ‘So what?’. Another programmer took TrueCrypt’s documentation and from scratch wrote a program that creates TrueCrypt compatible containers. This wasn’t too difficult because the Linux version of TrueCrypt uses functionality available in newer Linux kernels for actual encryption/decryption work. The new program is called tcplay and is carried by most Linux distros. Just make sure you get version 1.1 or higher if you want to use it. The nice thing about that setup is that the Linux kernel provides enterprise strength encryption which is continually updated and improved. You get to hitch a ride for free.

Another benefit of the way Linux deals with encryption is that any information that is read or written is directly transferred between RAM and the container: any piece of information that exists outside of the computer’s memory is always encrypted. There is no program involved that could make an illicit copy before encrypting your information. In my setup I have made sure that the vaults are linked to memory locations (not locations on the hard drive) when they are opened. This is to ensure that no unencrypted data gets inadvertently written to disk.

As a final measure I implemented layered security where cracking one password only gets you some information but not all of it. Here is an example of getting to bank account passwords: – start computer and insert USB stick holding the VMs – start VM manager; requires computer’s admin password and systemvault password (the system vault contains a key file and routing data of the banking VM’s vault; the second key file is stored inside the VM allowing me to store backup copies of the vault in plain sight since they can only be opened inside the VM) – start banking VM; requires VM admin password and VM vault password (password file is stored inside VM vault) – decrypt password file; requires password and key file selection

All passwords are salted and hashed and most of them are peppered as well. So any attacker would need to use my computer and USB stick and then crack a series of passwords while blindly guessing one keyfile. I am counting on the fact that they will give up before they get that far, even though most of the passwords used are easy to type/remember (= inherently weak). In daily life it depends what I am working on but most of the time I only have to enter two passwords to be able to access my bank’s web site through a VM which to me is a reasonable trade-off for the added security. Is such an elaborate setup overkill? Perhaps, time will tell! But hopefully I have given you some ideas to work with.

Last but not least there is one thing you need to keep in mind when working with encrypted documents. If you have a habit of hibernating your computer, its memory contents will be written directly to a special area on your hard drive called swap space. This means that any open documents are recoverable from the swap space until its overwritten with other data. So you must close your documents before hibernating or encrypt your swap space to close that loophole.

—————————————

Next up, for the intrepid and those who wish to add to their skills (remember skills and knowledge are just about the only things that cannot be taken away from you), a step by step guide of what is required to get to the point of double clicking an icon to open/close a container. We will start completely from scratch by installing a Linux distro. I admit this is a bit of an experiment since some of the commands will wrap around to the next line on SurvivalBlog’s web page. However after some testing I am fairly confident they will be in the correct format when pasted into a text editor.

As I have mentioned in a previous submission, the best Linux distro to use when you are used to Windows (XP/Vista/7) is Linux Mint 13. This is their current long term supported (till 04/2017) Ubuntu derivative which means out-of-the-box support for most hardware. Version 14, 15 and 16 are also available but are really development snapshots with a short life cycle. You will also want to stay away from LMDE if you never tried Linux before. Mint focuses on keeping a productive desktop environment which means it looks very familiar if you are used to XP/Vista/7. The other Linux desktops come with a (sometimes much) higher learning curve. If you have never installed an operating system you probably should get someone to assist you in the following steps: -1- Download the iso image from the Linux Mint web site. In the following instructions I am assuming you are using the MATE desktop so you may want to download that version. If you don’t know if your computer can handle 64-bit code, just use the 32-bit version. -2A- Burn the downloaded image onto a DVD and start your computer from there, however this makes the system rather slow. -2B- Download the Windows version from a software package called Unetbootin. This allows you to transfer the downloaded iso image to a flash drive and boot your computer from that. This is much faster especially if you use (real) USB 3.0 drives. -3- Start the computer from your DVD or flash drive. -4A- Permanently install Linux on your hard drive – a 10GB partition is more than big enough. Backup ALL your data if you have never done this before because you will need to defragment Windows and then shrink your Windows partition. Linux installs its own bootloader that allows you to choose if you want to run Windows or Linux every time you (re)start your computer. -4B- Permanently install on an external drive. This can be a (8MB+) USB stick also. Make sure you install the bootloader on the external drive in this scenario, so your hard drive is untouched. This may be the better alternative because you can tell the installer to use the entire drive, saving you the partitioning process. If you are new to this the easiest way to tell which drive is your hard drive/external drive/etc. is to check their reported size. Note that Linux can read/write all Windows disk formats so you can use your primary hard drive to store containers if you wish. -5- During a permanent install Linux will make you enter a password. Write It Down! It is much more important than with most Windows installs and if you forget it you will be able to do nothing but re-install Linux. -6- Reboot the computer from the image you just installed.

To make your life a bit easier and more productive try the following steps (they are not critical though):
– Right click on the panel at the bottom of your screen
– Select ‘Add to Panel’
– Scroll down the window and select ‘Workspace Switcher’
– Click ‘Add’; click ‘Close’
You should see 4 gray rectangles on the panel. These represent 4 desktops, each just a mouse click away. You can run applications on each desktop and switch between them which is much nicer than having them all stacked on one desktop.

Now that you are up and running you need to install a few scripts and a program. The reason is that tcplay is a low level program that only takes care of the very basics through the command line. Opening, closing and modifying of a container from the user perspective is really a three step process and tcplay takes care of only one of those steps. Doing those steps out of order or skipping one has nasty consequences for your data or can even lock up your computer (trust me, I tried …:). Perhaps someday someone will write a nice GUI for a program that combines those steps but in the meantime we go with quick and dirty.

Though installing the scripts can be done using ‘ordinary’ (= point and click GUI) programs, I will use the command line interface. This way you can simply copy and paste the commands instead of having to learn to use new software. If you are not used to typing commands you should definitely use the copy/paste method since the commands are rather picky. For instance ‘echo #.. >>/etc/fstab’ is harmless but ‘echo #.. >/etc/fstab’ will make your system unbootable and you will have to install the Linux distro from scratch.

To use the command line interface you need to open a terminal: click on ‘Menu’ in the lower left hand corner of the screen and then click on ‘Terminal’. This should open up a new window with a blinking text cursor. This window has an ‘Edit’ menu that you can click on to use the ‘Paste’ function. Click on the terminal window to activate it. Depending on how you highlight text in your browser, the computer may or may not execute pasted commands right away. If it doesn’t, press the ‘ENTER’ key after pasting the command.

# We begin with the command: sudo su # and enter your password as required.

# Next commands (can be copy/pasted as a single block) are:
mkdir -pm755 /srv/tc
printf “tmpfs /tmp tmpfs defaults 0 0” >> /etc/fstab
printf “tmpfs /var/tmp tmpfs defaults 0 0” >> /etc/fstab

# To get tcplay you need an internet connection as you need to download a small file.
# For 64 bit OS:
wget
http://mirrors.kernel.org/ubuntu/pool/universe/t/tcplay/tcplay_1.1-1_amd64.deb
# – or –
# For 32 bit OS:
wget
http://mirrors.kernel.org/ubuntu/pool/universe/t/tcplay/tcplay_1.1-1_i386.deb

# To install the downloaded program:
gdebi tcplay*
# answer the prompt by pressing the ‘y’ key

# Now we need to create the scripts that execute the various tasks.
# Note that each of the files MUST start with the phrase #!/bin/bash as its very first line.
# Open a text editor:
pluma /srv/tc/MDV.sh 2>/dev/null
# Copy and paste the first script (below) into the text editor; then click the ‘save’ button and close the editor.
# We also need to make this script executable:
chmod 755 /srv/tc/MDV.sh

# Open the text editor again:
pluma /srv/tc/MUV 2>/dev/null
# Copy and paste the second script (below) into the text editor; save and close.

# Open the text editor a 3rd time:
pluma /srv/tc/CV 2>/dev/null
# Copy and paste the third script (below) into the text editor; save and close.

# switch to user mode (very important):
exit

# then (you can copy/paste the following commands in one block):
ln -s /var/tmp ./Desktop/vaults
printf “[Desktop Entry] Version=1.0 Type=Application ” >
./Desktop/MDV.desktop
printf “Terminal=false Exec=mate-terminal -e \”sudo /srv/tc/MDV.sh\” “
>> ./Desktop/MDV.desktop
printf “Name=MDV Icon=mate ” >> ./Desktop/MDV.desktop
printf “[Desktop Entry] Version=1.0 Type=Application ” >
./Desktop/documents.desktop
printf “Terminal=false Exec=mate-terminal -e \”sudo /srv/tc/MDV.sh toggle
documentvault\” ” >> ./Desktop/documents.desktop
printf “Name=documents Icon=/usr/share/pixmaps/gksu-icon.png ” >>
./Desktop/documents.desktop

Minimize the terminal window.
Double click on the MDV.desktop icon on your desktop. In the popup window click on ‘Mark as trusted launcher’.

Next we will create a system vault. If you run into trouble and the process aborts; you need to type the following command in your terminal window and start over again:
sudo rm /srv/tc/.SystemVault

Double click on the MDV icon on your desktop again and enter your password; then select ‘create’ in the popup window and click OK button. In the next popup window type ‘systemvault’ (without quotes; then click OK button).

Your computer will now create your systemvault after asking what hash function and what cipher(s) to use [see notes below]. It will also require a password for the vault. Write that password down too. The whole process can take anywhere from 1 to 15 minutes due to random seeding. You will just have to be patient and let it run.

Once your systemvault has been created, you need to open it as follows:
Double click on the MDV icon on your desktop and enter your password; then select ‘open’ in the popup window, click OK, type ‘systemvault’ (without quotes), click OK.
Now click on the ‘vaults’ icon on your desktop. The file browser window that opens up should show an entry ‘tc’. Double click on that and you should see an entry called ‘Lost + Found’ (if you don’t see it try <CTRL><H> to show hidden files). If you do you are looking into an empty vault.

# Now restore your minimized terminal window and copy/paste the following block of commands into it:
user=”`whoami`”
printf “containerlocation=/home/$user ” > /var/tmp/tc/documentvault.rc
printf “container=\”DOCvault\” ” >> /var/tmp/tc/documentvault.rc
printf “containersize=\”500M\” ” >> /var/tmp/tc/documentvault.rc
printf “key1=\”\$SVmountpoint/lake.jpg\” ” >> /var/tmp/tc/documentvault.rc
printf “key2=\”\$SVmountpoint/mountain.jpg\” ” >>
/var/tmp/tc/documentvault.rc
printf “backupdir=\”\$NASmountpoint/data\” ” >> /var/tmp/tc/documentvault.rc

Refresh the file browser window (click circular arrow). It should now show a file in your vault. This file is a called a resource file and you need to create one for each container you want to create and/or use. Double click the file to open it. If the system asks you to select a program, choose pluma. The first 3 lines are mandatory; the second 3 are optional and can be deleted (or commented out by putting a # in front of the line) if you don’t want to use key files and automatic container backups. With the sample resource file the computer will try to create/use a 500 MB container called DOCvault in your home directory. If you want to use key files you must define them (and make sure they exist) before trying to create the container or the process will fail.

Click on the MDV icon on your desktop. Select ‘close’ and again type: systemvault and select OK.
Refresh the file browser window and the ‘tc’ folder should now be empty or have disappeared altogether.

# During the installation process the tc folder was located on your disk and not yet in memory. So we will clean up with:
sudo rm -fR /var/tmp/*
# And by restarting the computer we move the /var/tmp folder into memory:
sudo reboot
# Which concludes your installation process.

If you want to create the container defined in the sample resource file, you go through the same steps as when you created the system vault. But you first need to copy two key files into your systemvault and make sure that the key1= and key2= entries in the documentvault.rc file contain the names of these files.
-Doubleclick on the MDV icon on your desktop, enter your password and then select ‘create’ in the popup window and click OK button.
-In the next popup window type ‘documentvault’ (without quotes; then click OK button).
If the computer can’t find the key files you specified, it will abort the process with an error message.
Once the creation process is complete, you can access the contents of this container by double clicking the ‘documents’ icon on the desktop. This container will show up as a folder beside the ‘tc’ folder that holds the system vault.

Technical Notes and Code to Copy/Paste:

By default the systemvault only uses a password. If you want to use a keyfile also change the line ‘tcpopts=””‘ in MDV.sh to ‘tcpopts=”-k $key1″‘ before creating the system vault. A key file can be added later by running MDV’s modify option. Once the modify operation has completed, you need to define tcpopts as shown above before you can open the systemvault again. To make this change in MDV.sh you must run your text editor with elevated privileges like so: sudo pluma /srv/tc/MDV.sh

To change key files for other containers you need to add lines defining key3 and key4 as the new key files to the container’s resource file. Then run MDV’s modify option. Then copy key3 and key4 definitions to the key1 and key2 definitions.
If you don’t want to use any key files, you need to change the line
‘tcpopts=”-k $key1 -k $key2″‘ in MDV.sh to ‘tcpopts=””‘.

To create additional icons on your desktop: right click the desktop and select ‘Create launcher’. You can check the properties of the existing MDV and ‘documents’ icons for an example of what to enter in the various fields. To find a fitting icon for your launcher, click on the button to the left of the text entry fields and browse the ‘pixmaps’ folder.
When you create a new icon make sure the container name mentioned in the ‘command’ field matches the name of an existing resource (.rc) file in the system vault.

$SVmountpoint and $NASmountpoint (as used in the sample resource file) are defined at the start of the MDV.sh script. Their values can be changed as required. $SVmountpoint will always point into the opened system vault wherever you want to store the vault. $NASmountpoint allows you to define the location of an external or network drive.

When creating a container you will be given some options on how to encrypt your key. You can choose from three hash functions and 8 cipher combinations. For hash functions (first menu) I only use options 1 and 2 based on their heritage. As far a the ciphers goes: the longer the cipher chain the stronger the encryption as each cipher adds 512 bits to the key length.

If you decide to use VMs also, do NOT try to create containers inside the VM. It will cause you nothing but grief. Create the container directly on your hardware and then copy it into the VM; after that it will work just fine.

The MDV script supports the following options:
– open : opens a container.
– close : closes a container.
– toggle : toggles between open and closed states.
– unload : closes all open containers (useful when hibernating/shutting
down your computer).
– opencopy : opens a (backup) copy of a container besides the current
copy. This allows you to compare contents or documents without having to
create an unencrypted copy somewhere.
– create : creates a new container.
– modify : allows you to change the container’s password and/or key files.
– backup : create a backup copy of the container.
– restore : restore a container’s primary header in case it has become
corrupted.
– info : display information about the container.

The scripts should work on any Linux distro but a few commands are hard coded for use with the MATE desktop. For instance ‘mate-terminal’ and ‘matedialog’ will have to be replaced by the appropriate commands for that distro/desktop. A final note regarding the scripts: they run fine on a daily basis on my systems but I do not believe all possible code paths have been fully tested so the road less traveled may be rocky.

License: The code is released under a FreeBSD license which means you can use, improve or cripple it in any way you want. You can even sell copies to your buddies. However the license also includes the magic formula: the code comes without any warranty. Its not even guaranteed to be fit for its intended purpose.

********** Save the following lines as MDV.sh ************
#!/bin/bash

tcsdir=”/srv/tc”
TCmountdir=”/var/tmp”
SVmountpoint=”$TCmountdir/tc”
NASmountpoint=”/mnt/NAS”

function SysVault {
container=SystemVault
containersize=12M
containerlocation=”$tcsdir”
backupfolder=”$TCmountdir/tcb”
mountname=”`basename “$SVmountpoint”`”
}

function OtherVaults {
filecount=0
[ -d “$SVmountpoint” ] && filecount=`ls “$SVmountpoint” | wc -l`
if [ $filecount -eq 0 ]; then
“$tcsdir”/MDV.sh open systemvault
[ $? == 0 ] || exit 1
echo
fi

resources=”$SVmountpoint/$vaultname.rc”
[ -r “$resources” ] || notify “Cannot retrieve $resources”
. “$resources”
mountname=”`echo $container | sed -e’s/^\.//g’`”
}

function OpenVault {
filecount=`ls “$TCmountdir” | grep “$mountname” | wc -l`
if [ $filecount -gt 0 ]; then
mountname=”$mountname$filecount”
vaultpath=”`matedialog –file-selection 2>/dev/null`”
container=”$container$filecount”
containerlocation=”/tmp”
ln -fs “$vaultpath” “$containerlocation/$container”
fi

mountpoint=”$TCmountdir/$mountname”
echo ” opening container on $mountpoint”
. “$tcsdir”/MUV mount
pause 0
}

function ToggleVault {
mounted=`cat /etc/mtab | grep “$container” | wc -l`
if [ $mounted -eq 0 ]; then
. “$tcsdir”/MUV mount
else
. “$tcsdir”/MUV unmount
fi
}

function UnloadVaults {
unset lastvault
while true; do
mounted=”`cat /etc/mtab | grep “/dev/mapper”| cut -d” ” -f1 | tail -1`”
[ -z “$mounted” ] && exit 0
vault=”`echo $mounted | cut -d/ -f4`”
[ “$vault” == “$lastvault” ] && exit 1

device=”`tcplay -j $vault | grep “Device:” | cut -d: -f2 | tr -d
[:space:]`”
mountpoint=”`cat /etc/mtab | grep “$mounted” | cut -d” ” -f2`”
umount “$mounted”
rmdir “$mountpoint”
tcplay -u “$vault”
losetup -d “$device”
lastvault=”$vault”
done
}

function GetKey {
echo “Select system vault key file”
key1=”`matedialog –file-selection 2>/dev/null`”
[ -z “$key1” ] && exit 1
}

function CheckKeyfileAccess {
file1=`echo “$key1” | grep “$NASmountpoint” | wc -l`
file2=`echo “$key2” | grep “$NASmountpoint” | wc -l`
NeedNAS=`echo $file1 + $file2 | bc -l`
if [ $NeedNAS -gt 0 ]; then
mounted=`cat /etc/mtab | grep “$NASmountpoint” | wc -l`
if [ $mounted -eq 0 ]; then
echo “mounting NAS …”
mount “$NASmountpoint”
[ $? == 0 ] || pause 1
fi
fi

if [ -n “$key1” ] && [ ! -r “$key1” ]; then
notify “unable to access keyfile $key1”
fi

if [ -n “$key2” ] && [ ! -r “$key2” ]; then
notify “unable to access keyfile $key2”
fi
}

function notify {
printf ” %s ” “$1”
pause 1
}

function pause {
printf “%s ” ” Press any key to exit”
read -n 1
exit $1
}

# ———————————————————-
# must be run as root
[ $EUID == 0 ] || notify “You need administrator rights. Try: sudo
/path/to/MDV.sh”

action=”$1″
vaultname=”$2″

if [ -z $action ]; then
action=”`matedialog –list –hide-header –text=”Select an action”
–column=action open close backup opencopy unload create info modify restore`”
[ -z “$action” ] && exit 1
fi

[ “$action” == “unload” ] && UnloadVaults

if [ -z $vaultname ]; then
vaultname=”`matedialog –entry –text=”Enter vault name”`”
[ -z “$vaultname” ] && exit 1
fi

SV=”`echo $vaultname | grep -i systemvault`”
if [ -n “$SV” ]; then
SysVault
tcpopts=””
tcpnewopts=”–new-keyfile=$key3″
else
OtherVaults
tcpopts=”-k $key1 -k $key2″
tcpnewopts=”–new-keyfile=$key3 –new-keyfile=$key4″
fi

mountpoint=”$TCmountdir/$mountname”
case “$action” in
“create”) . “$tcsdir”/CV;;
“open”) . “$tcsdir”/MUV mount;;
“close”) . “$tcsdir”/MUV unmount;;
“opencopy”) OpenVault;;
“unload”) UnloadVaults;;
“toggle”) ToggleVault;;
“info”) . “$tcsdir”/MUV info;;
“restore”) . “$tcsdir”/MUV restore;;
“modify”) . “$tcsdir”/MUV modify;;
“backup”) . “$tcsdir”/MUV backup;;
*) notify “unknown action: $action”;;
esac

************** Save the following lines as MUV **************
#!/bin/bash

action=”$1″
loopdevice=”`losetup -a | grep $container | cut -d: -f1 | tail -1`”
[ -f “$containerlocation/$container” ] || notify “container
$containerlocation/$container not available”
cd $containerlocation

# ———————————————————————
# back up container
if [ “$action” = “backup” ]; then
[ -z “$backupdir” ] && notify “backup folder not set up”
[ -w “$backupdir” ] || notify “$backupdir not accessible”

# compare file’s modification times
backupcopy=0
currentcopy=`stat -c %Y “$containerlocation/$container” | awk ‘{printf $1
” “}’`
if [ -f “$backupdir/$container” ]; then
backupcopy=`stat -c %Y “$backupdir/$container” | awk ‘{printf $1 ” “}’`
fi
if [ $backupcopy -eq $currentcopy ]; then
echo ” Container already backed up”
pause 0
fi
if [ $backupcopy -gt $currentcopy ]; then
echo ” Backup is newer – Do you really want to overwrite it? (y/n)”
answer=”`read -n 1 | tr [:upper:] [:lower:]`”
[ “$answer” == “y”] || exit 0
fi

# unmount container to make sure all caches have been flushed
mounted=`cat /etc/mtab | grep “$mountpoint” | wc -l`
if [ $mounted -gt 0 ]; then
echo closing container …
. $tcsdir/MUV unmount
fi

# copy container
echo “backing up container to $backupdir …”
cp -f “$containerlocation/$container” “$backupdir/$container”
[ $? == 0 ] || pause 1
chmod 644 “$backupdir/$container”
exit $?
fi

# ———————————————————————
if [ “$action” == “unmount” ]; then
# already unmounted
[ -z “$loopdevice” ] && return

# systemvault must be the last one to unmount
if [ “$vaultname” == “systemvault” ]; then
mounted=`cat /etc/mtab | grep “/dev/mapper” | wc -l`
sysmounts=`cat /etc/mtab | grep -i “$container” | wc -l`
[ $sysmounts -lt $mounted ] && notify “System vault in use: cannot close it”
fi

# remove user access
mounted=”`cat /etc/mtab | grep “$container” | cut -d” ” -f2 | tail -1`”
if [ -n “$mounted” ]; then
container=”`cat /etc/mtab | grep “$mounted” | cut -d” ” -f1 | cut -d/ -f4`”
umount “$mounted”
[ $? == 0 ] || pause 1
rmdir “$mounted”
fi

# remove encryption mapping
loopdevice=”`tcplay -j $container 2>/dev/null | grep “Device:” | cut -d:
-f2 | tr -d [:space:]`”
if [ -n “$loopdevice” ]; then
tcplay -u $container
[ $? == 0 ] || pause 1
fi

# release the loop device
losetup -d $loopdevice
return
fi

# ——- required for all following functionality ——–
# associate container with loop device
if [ -z “$loopdevice” ]; then
loopdevice=$(losetup -f)
losetup $loopdevice $container
[ $? == 0 ] || pause 1
fi

# ———————————————————————
if [ “$action” == “mount” ]; then
# already mounted?
mounted=`cat /etc/mtab | grep “$mountpoint” | grep $container | wc -l`
[ $mounted -eq 0 ] || notify “container $container already open”

# check key file availability
CheckKeyfileAccess

# create temp directories
if [ ! -d $mountpoint ]; then
mkdir $mountpoint
[ $? == 0 ] || pause 1
fi
if [ -n $backupfolder ] && [ ! -d $backupfolder ]; then
mkdir -m 777 $backupfolder
[ $? == 0 ] || pause 1
fi

# container already mapped?
mapped=”`tcplay -j $container 2>/dev/null | grep $loopdevice`”
if [ -z “$mapped” ]; then

# no: map it now
# release loop device if not successful
if [ “$vaultname” == “systemvault” ]; then
printf ” %s ” “opening system vault”
[ -n “$tcpopts” ] && GetKey
else
printf ” %s” “$container “
fi
tcplay $tcpopts -m $container -d $loopdevice
if [ $? != 0 ]; then
losetup -d $loopdevice
pause 1
fi
fi

# mount container
mount -o nosuid /dev/mapper/$container “$mountpoint”
[ $? == 0 ] || pause 1

# enable access by all users
chmod 777 $mountpoint
exit 0
fi

# ———————————————————————
# retrieve container info
if [ “$action” = “info” ]; then
[ -n “$tcpopts” ] && [ -z “$key1” ] && GetKey
CheckKeyfileAccess
tcplay $tcpopts -id $loopdevice
if [ $? != 0 ]; then
printf ” %s ” “Will try to access backup info:”
tcplay –use-backup $tcpopts -id $loopdevice
[ $? == 0 ] || pause 1
fi
pause 0
fi

# ———————————————————————
# restore header from backup
if [ “$action” = “restore” ]; then
[ -n “$tcpopts” ] && [ -z “$key1” ] && GetKey
CheckKeyfileAccess
tcplay –modify –restore-from-backup-hdr $tcpopts -d $loopdevice
[ $? == 0 ] || pause 1
pause 0
fi

# ———————————————————————
# modify password and/or keyfiles
if [ “$action” = “modify” ]; then
[ -n “$tcpopts” ] && [ -z “$key1” ] && GetKey
CheckKeyfileAccess

if [ -n “$tcpnewopts” ]; then
if [ -z “$key3” ]; then
holdkey=”$key1″ && GetKey
key3=”$key1″ && key1=”$holdkey”
fi
fi
if [ -n “$key3” ] && [ ! -r “$key3” ]; then
notify ” unable to access new keyfile $key3″
fi

if [ -n “$key4” ] && [ ! -r “$key4” ]; then
notify ” unable to access new keyfile $key4″
fi

tcplay –modify -d $loopdevice $tcpopts $tcpnewopts
pause 0
fi

************** Save the following lines as CV **************
#!/bin/bash

# vault already created
[ -f “$containerlocation/$container” ] && notify “container already exists”

# double check for old mounts just in case
mounted=`cat /etc/mtab | grep “$mountpoint” | grep $container | wc -l`
[ $mounted -eq 0 ] || notify “an older version of this container is already open”

CheckKeyfileAccess

# select PBKDF PRF algorithm while [ 1 ]; do

clear
printf ” Select the PBKDF PRF algorithm you want to use … “
PS3=”your choice: “
select i in “whirlpool” “RIPEMD160” “SHA512”

do case $i in
“whirlpool”) algorithm=”whirlpool”;;
“RIPEMD160″) algorithm=”RIPEMD160”;;
“SHA512″) algorithm=”SHA512”;;
*) unset algorithm;;
esac
break
done

if [ -z “$algorithm” ]; then
printf ” \t%s ” “Invalid input”
sleep 2
continue
fi

break
done

# select cipher chain
while [ 1 ]; do

clear
printf ” Select the cipher chain you want to use … “
PS3=”your choice: “
select i in AES-256-XTS TWOFISH-256-XTS SERPENT-256-XTS
TWOFISH-256-XTS,AES-256-XTS AES-256-XTS,SERPENT-256-XTS
SERPENT-256-XTS,TWOFISH-256-XTS
AES-256-XTS,TWOFISH-256-XTS,SERPENT-256-XTS
SERPENT-256-XTS,TWOFISH-256-XTS,AES-256-XTS

do case $i in
“AES-256-XTS”) cipher=”AES-256-XTS”;;
“TWOFISH-256-XTS”) cipher=”TWOFISH-256-XTS”;;
“SERPENT-256-XTS”) cipher=”SERPENT-256-XTS”;;
“TWOFISH-256-XTS,AES-256-XTS”) cipher=”TWOFISH-256-XTS,AES-256-XTS”;;
“AES-256-XTS,SERPENT-256-XTS”) cipher=”AES-256-XTS,SERPENT-256-XTS”;;
“SERPENT-256-XTS,TWOFISH-256-XTS”) cipher=”SERPENT-256-XTS,TWOFISH-256-XTS”;;
“AES-256-XTS,TWOFISH-256-XTS,SERPENT-256-XTS”) cipher=”AES-256-XTS,TWOFISH-256-XTS,SERPENT-256-XTS”;;
“SERPENT-256-XTS,TWOFISH-256-XTS,AES-256-XTS”) cipher=”SERPENT-256-XTS,TWOFISH-256-XTS,AES-256-XTS”;;
*) unset cipher;;
esac
break
done

if [ -z “$cipher” ]; then
printf ” \t%s ” “Invalid input”
sleep 2
continue
fi

echo
break
done

# create container
cd $containerlocation
dd if=/dev/zero of=$container bs=1 count=0 seek=$containersize
[ $? == 0 ] || pause 1

# setup loop device
loopdevice=”`losetup -a | grep $container | cut -d: -f1 | tail -1`”
if [ -z “$loopdevice” ]; then
loopdevice=$(losetup -f)
losetup $loopdevice $container
[ $? == 0 ] || pause 1
fi

# initialize container
[ -n “$tcpopts” ] && [ -z “$key1” ] && GetKey

printf ” %s ” “Select $container’s”
tcplay -c -d $loopdevice $tcpopts -a $algorithm -b $cipher
[ $? == 0 ] || pause 1

# mount on /dev/mapper
printf ” %s ” “Enter $container’s”
tcplay $tcpopts -m $container -d $loopdevice
[ $? == 0 ] || pause 1

# create a filesystem in it (ext2 for flash based devices)
mkfs.ext2 /dev/mapper/$container
[ $? == 0 ] || pause 1
pause 0

And that’s it, folks!