How many of you have documents with your Social Security number on your computer? How about health records? Or perhaps you store your passwords in a simple text file (please don't do this).
Anything you don't want in the hands of a criminal should be encrypted. Encrypting your files is not hard, and will make you far more secure.
Why Encrypt Your Files?
If your computer is lost or stolen, whoever is in possession of your computer can copy all your files. If your files are encrypted, then they can still copy them, but they won't be able to read them.
Doesn't My Computer's Password Protect Me?
Your computer password in no way prevents someone from copying unencrypted files from your computer . So long as an attacker has physical access, they can either remove the hard drive (though in recent laptops, this is often not worthwhile because SSDs are usually soldered onto the motherboard) or they can boot the computer from a live USB (usually using Linux). When they boot from a live USB, they can access the storage on the computer and copy all of the data off of it.
Which Files Should Be Encrypted?
- Tax returns
- Anything else with your Social Security Number
- Scans of your passport and driver's license if you have them
- Health records
The data for sale includes names, birth dates, policy numbers, diagnosis codes and billing information. Fraudsters use this data to create fake IDs to buy medical equipment or drugs that can be resold, or they combine a patient number with a false provider number and file made-up claims with insurers, according to experts who have investigated cyber attacks on healthcare organizations.
Medical identity theft is often not immediately identified by a patient or their provider, giving criminals years to milk such credentials. That makes medical data more valuable than credit cards, which tend to be quickly canceled by banks once fraud is detected.
- The fact that medical identity theft is often not immediately identified is key. Banks have gotten really good at identifying fraudulent transactions and confirming fraud with their customers, limiting the value of credit card numbers on the black market. But how often do people check if there's been a claim filed against their health insurance?
Of lesser importance:
- Financial statements and other records (though I'm sure some people, including myself, would put these in the previous category)
- Anything with your address on it
- Password databases (this is actually of high importance, but I don't know of any password database program that doesn't automatically encrypt your database for you)
Types of Encryption
With folder encryption, your files are stored in encrypted form within a regular folder on your computer. When the folder is decrypted, the decrypted files appear in a separate folder. So for example, you might have your encrypted files at C:\My Documents\Encrypted, and after decrypting your files, they'd be visible at C:\My Documents\Decrypted.
- Can easily back up encrypted files, as they appear as regular files to your computer (though containing apparent gibberish)
- You can leave the folder encrypted when you don't need to access your sensitive files, meaning even if someone were able to remotely gain access to your computer and look through your files, he or she would not be able to read your sensitive files
- This will not encrypt most of the metadata about your files. Without the decryption password, an attacker would be able to see things such as the directory structure, file permissions, the number of files, file sizes, and file modification/access times. Folder encryption programs may have an option to encrypt the names of the files and the directories
With container encryption (this is more commonly known as volume encryption, but I think container is more intuitive) you create an encrypted container file and store all your sensitive files in the container. To actually access your files you mount the container (it will appear as if you plugged a flash drive into your computer).
- Will never leak the number or size of your files or folders, or the directory structure, as in its encrypted state it's simply one big file
- You can leave the container unmounted when you don't need to access your sensitive files
- At least in the implementation I use (Veracrypt), you have to preallocate the container file. That is, you have to decide ahead of time that you want your container file to be, say, 5 GB in size. This file will always be 5 GB in size, regardless of whether you put 1 MB or 5 GB of sensitive files in it
- If you run out of space in your container file, you have to create a new container file of greater size and copy your sensitive files to it
- Big container files can be clunky to deal with at times, especially if you're trying to copy it over the Internet
- Most programs that implement container encryption do not modify the timestamp of the container file when you change your sensitive files inside the container. This can present problems for backup. I will go into more detail in a later post
Full Disk Encryption
With full disk encryption, your entire hard drive  is encrypted. When you turn on your computer, you must enter your encryption password before your operating system loads and you can use your computer.
- There's no need to figure out which files you should or should not encrypt. They're all encrypted
- There's no need to mess with mounting a container file
- If someone gains remote access to your machine, full disk encryption will not prevent them from reading your sensitive files. Once the computer is booted, all files are readable in unencrypted form
Plausible Deniability: Hidden Volumes
Some encryption programs offer hidden volumes. This does not work for folder encryption. When you create a hidden volume, you're actually creating a second encrypted volume inside the first one. This requires two passwords: one for the outer volume and one for the hidden volume. If you are forced to decrypt your data, you simply enter the password for the outer volume.
When properly implemented, it is not possible to prove that a hidden volume exists. Properly encrypted data looks like completely random data (if it weren't you could glean some information about the data), and an encrypted volume should always be first filled with random data (if it weren't, then you would be able to tell how much encrypted data there is).
Hopefully you will never need to use this option, but be aware it exists.
Your Computer Login Password is Still Important!
Your computer password isn't capable of protecting your data when your computer is off, but it does serve a critical role when your computer is on and your sensitive files are in an unencrypted state.
If your computer is full disk encrypted and your computer is on, or if you use container or folder encryption and you've mounted your encrypted data, your data is now accessible. If someone can log into your computer, they can copy your sensitive files. But if they can't log in or remotely access your computer through some attack over the Internet/LAN, then to copy your data they have to shut down your computer to either remove the hard drive or boot your computer with a live USB. When they shut down your computer, your encrypted data becomes unmounted, and is again unreadable without the encryption password.
Your computer's password can protect your data, but only in conjunction with encryption.
Attacks on Encryption
If someone is able to install a keylogger on your computer, they can record all your keystrokes and determine your password.
To prevent this, some encryption programs allow you to use a keyfile (sometimes exclusively, sometimes in conjunction with a standard password). In order to decrypt your data, you must have this file (and make sure to set it to read only so it's never accidentally modified).
This attack is specific to full disk encryption. This is going to get a little technical.
When you turn on your computer, it has to run some code to actually load the operating system (Windows, Linux, Mac, etc). If your computer is full disk encrypted, this code has to decrypt the hard drive before your operating system can load.
The evil maid attack gets its name from the hypothetical evil maid that goes into your hotel room, plugs a flash drive into your laptop, and manages to change the code that decrypts your hard drive. Specifically, he or she would reprogram it to record the encryption password and either save it to disk, whereupon he or she would come retrieve it at a future date, or somehow transmit it to a server.
This attack can be mitigated by the use of a TPM (Trusted Platform Module). It is a hardware chip that can detect if a system has been compromised and can boot the computer in a quarantine mode to help the user diagnose the problem. Unfortunately, from my research on the subject, they are difficult to set up correctly (though I haven't tried it myself).
In a brute force attack the attacker guesses a ton of different passwords. So long as you choose a password with enough characters, by the time the data is decrypted you will be long dead.
Targeted Bruce Force
This method involves the attacker using data they have about you to try to guess your password. For example, if they stole your laptop, they might scan your laptop, collect words and numbers found in your files into a dictionary, and use that dictionary as the basis of guessing your password.
So long as you don't pick your password based on things in your life, you will avoid this attack.
Open vs Closed Source Encryption Programs
This discussion of open vs closed source is not limited to encryption programs, but all programs in general.
When a program is open source, its source code is made available to the public. It can be inspected. Closed source code is exactly what you'd expect: the source code isn't made available to the public.
In either scenario, security vulnerabilities could be introduced into the code, whether maliciously or by accident. With open source code, the code can be audited by anybody as to whether such vulnerabilities exist.
Unfortunately, just because people could audit the code doesn't mean they do. In some cases, security vulnerabilities are only found when a team of security experts is hired to audit the code. Furthermore, this ability to have the code audited isn't exclusive to open source code: some companies that release closed source security programs hire security experts to audit their code (after having them sign Non Disclosure Agreements, of course).
Open source definitely allows more people to audit programs, but it is not a silver bullet. Ultimately, you have to decide for yourself who to trust, unless you want to write all the programs you use yourself .
If you want my opinion:
- Closed source security program that's never been audited: I'd have serious reservations about using such a program. You don't know how many security vulnerabilities exist
- Closed source security program that has been audited: I'd take into account the reputation of the company that made it, but I'd likely trust it
- Open source security program that's never been audited: This is a tough one. It really depends on factors such as how many contributors there are to the source code, how many open issues there are on its project tracker (typically Github), how quickly these issues are closed, and what alternative programs are available
- Open source security program that has been audited: I'd trust it unless someone provided some compelling reason not to
Recommended Encryption Programs
I actually don't use folder encryption so I don't have any to recommend.
Veracrypt. It's open source, free, been audited, supports hidden volumes and keyfiles, and is supported on Windows, Mac, Linux, and FreeBSD.
Full Disk Encryption
Veracrypt is a decent contender here. Unfortunately it does not support full disk encryption of Linux (though Linux has its own alternative). Also, it does not support TPM chips so it cannot protect you against evil maid attacks.
On Windows, Bitlocker is built in to the Ultimate and Enterprise versions of Windows Vista and 7, the Pro and Enterprise versions of Windows 8, 8.1, and 10, and the Education version of Windows 10. It supports TPM chips. Unfortunately, it does not appear to ever have undergone an audit (please leave a comment if it has), so you'll have to decide between the greater potential for security vulnerabilities in the code itself versus the increased security from a TPM chip.
On Linux, LUKS is the standard. I've never actually used it, but it is built into the Linux kernel, so it's probably trustworthy.
Recommended Encryption Method
I recommend at least container encryption of your sensitive files (I don't like folder encryption leaking the file metadata. As the NSA likes to say, if you have enough metadata, you don't need the data). Using full disk encryption as well as container encryption will be extra secure because your operating system keeps all sorts of logs of your activity, and also generates temporary files that might be sensitive. But honestly for most people, container encryption is enough.
It also doesn't prevent them from copying encrypted files either, but with proper encryption this is futile ↩︎
or just selected partitions ↩︎
Even then, you still have to trust that whoever wrote the compiler you're using didn't program it to insert malicious code into your programs. Sure, you could write your own compiler, but what if your silicon is design to take malicious action when it sees certain code? This rabbit hole goes on and on ↩︎