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]\nVersion=1.0\nType=Application\n" >
./Desktop/MDV.desktop
printf "Terminal=false\nExec=mate-terminal -e \"sudo /srv/tc/MDV.sh\"\n"
>> ./Desktop/MDV.desktop
printf "Name=MDV\nIcon=mate\n" >> ./Desktop/MDV.desktop
printf "[Desktop Entry]\nVersion=1.0\nType=Application\n" >
./Desktop/documents.desktop
printf "Terminal=false\nExec=mate-terminal -e \"sudo /srv/tc/MDV.sh toggle
documentvault\"\n" >> ./Desktop/documents.desktop
printf "Name=documents\nIcon=/usr/share/pixmaps/gksu-icon.png\n" >>
./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\n" > /var/tmp/tc/documentvault.rc
printf "container=\"DOCvault\"\n" >> /var/tmp/tc/documentvault.rc
printf "containersize=\"500M\"\n" >> /var/tmp/tc/documentvault.rc
printf "key1=\"\$SVmountpoint/lake.jpg\"\n" >> /var/tmp/tc/documentvault.rc
printf "key2=\"\$SVmountpoint/mountain.jpg\"\n" >>
/var/tmp/tc/documentvault.rc
printf "backupdir=\"\$NASmountpoint/data\"\n" >> /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 "\n %s\n" "$1"
pause 1
}
function pause {
printf "%s\n" " 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
"\n"}'`
if [ -f "$backupdir/$container" ]; then
backupcopy=`stat -c %Y "$backupdir/$container" | awk '{printf $1 "\n"}'`
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 "\n%s\n" "opening system vault"
[ -n "$tcpopts" ] && GetKey
else
printf "\n%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 "\n%s\n" "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 "\n\n\n\n Select the PBKDF PRF algorithm you want to use ...\n"
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 "\n\t%s\n" "Invalid input"
sleep 2
continue
fi
break
done
# select cipher chain
while [ 1 ]; do
clear
printf "\n\n\n\n Select the cipher chain you want to use ...\n"
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 "\n\t%s\n" "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 "\n%s " "Select $container's"
tcplay -c -d $loopdevice $tcpopts -a $algorithm -b $cipher
[ $? == 0 ] || pause 1
# mount on /dev/mapper
printf "\n%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!