Security is a process, not a program:
First, encryption doesn't make your data secure by itself, there are a variety of other activities and steps you have to take with most encryption products. A case in point is Windows EFS, while it's encryption is easy and looks secure on paper, in practice Microsoft outlines several additional "
" that need to be done before the data is not recoverable from an attacker. There is an additional caveat that File Level
EFS encryption creates a plain-text copy
of any open EFS file temporarily, and "deletes" that file after it's closed. That file can be "
" and an attacker would then have the entire file in plain-text and no further need to crack or hack EFS. Folder Level EFS encryption still "suffers" from this plain-text flaw technically, but since that plain-text temp file is made inside an encrypted folder, it's not recoverable using an "undelete" utility.
Other encryption products have similar handling or additional steps you need to take to secure the data being encrypted. Most products tell you of these additional steps if you read the entire set of directions, others do not make it so clear even if you do.
The goal of encryption is to keep data hidden from the unintended or unauthorized. Encryption does not, on it's own, make your data "safer", in fact it should make your data unrecoverable unless you know the secret(s) to unlock it. That means that you should have backups of all your important data. Data that isn't important probably shouldn't be encrypted, but it's possible that unimportant data also gets caught in the encryption scheme. And, keep in mind that by encrypting your data, you are creating a risk that data you're trying to protect may not even be recoverable by you (the authorized), should something go wrong with the process.
Protecting/Encrypting that backup data is beyond the scope of this article, but there is plenty of information on the subject out there already. This article is simply stressing that encryption is supposed to make your data unreadable, and you should back it up before doing so :)
Handling, protecting and backing up the "secrets" or keys is equally important, make a plan to do all three!
Data at rest vs Data in motion:
Data at rest would be a CD/DVD sitting in its' sleeve, on the table, or a PC that is turned off. Data at rest is also data that isn't being accessed, a file or folder on a computer that is running can be data at rest. Data in motion is data that is being accessed, or data that is being sent. You want to protect data at rest because it will soon be data in motion, and you want to protect data in motion from anyone who is not supposed or intended to see that data. Encryption can solve both issues, but it's not the only tool available to do so. There are also levels of access to contend with, risks you have to take no matter what solution you choose. While some encryption solutions do not decrypt the data on disk, they keep the key/password in memory, technically there are ways of getting that key/password out of memory. It's a trade off, you have to weigh the likelihood of that happening and what risk that may pose should it happen. There are even ways of getting those keys/passwords after the computer is turned off (see
) or is hibernating (see
). No encryption or method is perfect, it's only as strong as its weakest link, never lose sight of that fact.
Full Disk Encryption: What it is and isn't...
Full Disk Encryption
(FDE) like BitLocker, TrueCrypt, PGP or FreeOTFE encrypts the OS and all the files on the OS partition(s). A new bootloader is placed in an unencrypted portion of the HDD which prompts the user or expects some credential (USB/DVD/SmartCard/Passwor
d) to supply the key to unlocking the rest of the OS and the boot process.
Some products are able to use the TPM chip present on many modern day motherboards to offer some additional protect from attacks like a Coldboot attack, or a Bios root kit. Others see TPM as a paper-tiger, if the attacker has the access, they can do a variety of other tasks (physical key-logger, remove ram etc...) that make TPM redundant and give people a
false sense of security.
Some FDE is done at the hardware level, like Seagate's
Momentus drives, Hitachi's
BDE and Toshiba's
SED HDD's. These types of drives do all the encryption and decryption on the HDD's own electronics, then send the data to the rest of the computer's hardware as a normal unencrypted data.
FDE only protects the data at rest, on the HDD, when the OS is not booted up, it doesn't protect the ram or other physical components of the computer. If I steal your Laptop and remove the HDD, it's fully encrypted and I can only hope to guess your password. There are mistakes you can make that will betray the encryption you're trusting to protect you, mistakes like: perhaps your pagefile or hibernation file is not on the same partition as your (encrypted) OS, if that is so I may have your decryption keys in plain-text. Perhaps your laptop is only hibernating, and it has a PCMCIA slot I can place a FireWire adapter in, then maybe I can use
PassWare to read RAM and get your decryption keys. There is also a chance that if you're using Windows XP or 2003 and that TrueCrypt might not have fully encrypted the hibernation files (see
Disclaimer at the bottom), and I could recover the key there...
Once the OS is up and running, none of the data "looks" encrypted to an attacker. FDE does not protect the running OS in any way. If a backdoor or attacker gets into the PC, while it's running, that backdoor or attacker sees everything on the OS like you do. If you lose power or turn you computer off, the data is pretty safe from an attacker. Once the secret is given and the OS is booted, it's possible to retrieve that secret from memory, or do what the attacker wants to do on the computer.
FDE protects from physical (HDD) theft, that is it is primary and that is nearly the only benefit. You may want to consider turning off hibernation/sleep modes, it's up to you to weigh that risk.
Other Encryption Methods: Zip/Rar/7zip
You can use the old tried and true Zip file with a password to open method. This method is still a very good one for protecting data in motion AND data at rest. There are again caveats to this, mostly the data is only as safe as the password being used. Some containers use "slower" password hashes than others that will add to the time it would take an attacker to guess the password. Winrar's password guessing is the slowest I've encountered, WinZip the fastest and 7Zip being in the middle of the three.
Windows is able (since XP) to natively create
WinZip compatible archives, and to allow you to password protect them. That encryption however is a weaker form than what currently ships in WinZip and other compression products that support WinZip+encryption. AES-256 is the current standard for WinZip, but an
older and flawed version of WinZip encryption was licensed to the Microsoft OS, and this is the case for the newer Microsoft OSs as well.
Open Office/Word/Excel/Power-Point Document Encryption: Microsoft Office 2013 and 2010 support the strongest, rather the slowest, password protection options. With
SHA1 run 100,000 times (default can be configured higher or lower) and two AES-128 checks after that. In layman terms that means the password is still the weakest link, but with that many operations to do, checking the password takes longer for an attacker, and is barely noticeable to the authorized persons.
Microsoft Office 2007 uses SHA-1 50,000 times and one AES-128 check. The default has changed in
2007 Sp-2 and beyond to use the 100,000 SHA-1 and two AES-128 checks now, but is fully able to open prior versions of Office documents. Older Office suites however are not able to read newer documents unless a
compatibility pack is applied to them, and even so, they are not able to create new or convert their older password protections into the newer versions.
Office XP - 2003 by default uses the same default protection as office 97 - 2000, a 40-bit RC4 algorithm that can be quickly found using a Rainbow Table or other brute-force methods. XP and 2003 Office suites however had far more encryption options available than the previous suites. However the default is what is most commonly found, and even with these options
mistakes were made.
uses PBKDF2 with 1024 iterations which also makes guessing passwords against the latest versions of OpenOffice very slow from an attacker view point. The password is still the weakest link, the longer the better, the more "random" or unguessable the better.
Other Types Of Encryption: Various applications support encryption at various levels, databases can have the entire DB encrypted, a few tables perhaps, or even just certain rows/cells. Most databases I have encountered rely on 3rd party software to do any and all encryption, and those 3rd parties typically have processes that need to be followed to remain secure.
Hardware security modules or managers can be found for all sorts of
applications and needs. There are even very unique HSM's like the
Yubikey-Standard that can be used in conjunction with lots of other security products you may never have thought of.
PGP, GPG aka Public Key Cryptography:
Public Key Cryptography is a hard concept to grasp at first. But you use it everyday on the internet, httpS, ssh, sftp and many VPN solutions use Public Key Cryptography (ssl/tls) to secure the transmission of data (data in motion, mind you).
The basics are, you create a key-pair and someone you know creates a key-pair. You can password protect the private key, or you don't have to, it is recommended that you do have a password protecting the private key. So you have your Public and Private keys and I have mine. We can tell/show/give anyone our
public keys we want. We must however protect our private keys from others. I can take your
public key, encrypt,
sign or seal my file using your
public key, and when I send it to you, only you can decrypt it with your private key (and password) The password has nothing to do with how the keys were made by the way, the password is only there to protect the private key from being used by others if they are stolen or copied. You can change the password that protects your private key if you want, it won't make any difference, the private key remains the same.
EFS uses Public Key Cryptography, as do many other applications. Public Key Cryptography helps eliminate password sharing, but it doesn't scale well past two parties. PGP has a method, much like S/MIME, that allows multiple recipients to receive one version of an encrypted email, but it's not the standard way in which Public Key Cryptography works.
Encryption Suites: TrueCrypt, FreeOTFE, PGP, AxCrypt, BitLocker etc...
There are dozens of them out there, and each has their caveats. Make sure you know of them before you choose. Some suites support what are called "keyfiles", it's a second password if you will, that you don't type so it's not going to get key-logged by a key-logger. You browse to this key-file and it's read by the OS to retrieve the first 512k of data to use as the second password. Some suites support the creation of hidden or plausibly deniable OSs. There are
many caveats to using them, make sure you know them. BitLocker also has other modes and features that make up its suite, the
BL To-Go features for example. Remember these suites may have their flaws, if an attacker can get on a running OS, they may be able to
issue commands that undermine the product.
Choosing the products you need: Understand you have to take multiple steps to protect your data. Don't password protect a zip file, and send the password in the same email as the zip file. Call the person you're sending it to to relay it, use some other method/channel to transfer the secret. Learn how to use PGP/GPG (aka public key cryptography) and don't worry about a second channel or a password from the sender/receiver, all you need to know is your own password.
Do not JUST encrypt your laptops if they contain sensitive data, make sure you have controls around how that data is accessed... If I swipe the laptop out of a nurse's hands and run off, I don't have to contend with the offline protection of the FDE. I will likely have quite a few patient health records and information at my fingertips if there is no control around those records.
By all means, keep as much data under lock and key as you can. Don't allow users to have offline data if they don't need it. Patient records are a prime example. Or find a solution that addresses certain scenarios like the "nurse snatching" one. Perhaps the nurses' ID badge doubles as a second factor of authentication, and when it's not present, the laptop locks or shuts down (dead-man switch).
Do not expect encryption to solve all your access problems. Sharing passwords is the worst thing you can do, there is no accountability and it's very easy to forget them. Do not forget Schneier's law:
Encryption can be very strong, but implemented very poorly, even if it
gets certified by those who are supposed to be authorities in these matters!
Do not get caught up with hype and marketing, rankings or "leadership". Use the right tools for the right job, for you!
Instead of "deadman" switch, think of a proximity card, those are widely available and operate on the same principal. However they are cumbersome and external, most Laptops support smartcards, if you look at most you can find the slot. the size of a credit card. And you can force windows to lock when you remove it :) There maybe other experts who'd like to contribute this may be a security question for EE!
I hope you don't mind me asking this here (or asking you at all) but I have a question about PGP Keys.
I noticed that the length of some Open Keys are longer than others. Does that mean those are any "safer"? Could I assume that, "the longer a key, the better"?
My open PGP key is 15 lines long, and looks rather short in comparison to many others. Does that mean, I am more vulnerable or exposed than those with larger public keys?
If that should be true, is there any way to modify my certificate and make it more secure?
I really appreciate your help !
1024, which is often the default, is probably too small. Current experts recommend 2048 or higher, but not too high :) Doubling a key's length doesn't double it's "strength", it only doubles the space you have to search for the key. Your chances are better using a larger key, but if it's too large then you are going to have a bottleneck in the encryption/decryption process. This is what a 4096-bit key looks like: https://www.schneier.com/contact.html