Full Disk Encryption: Strongest Counter to Surveillance, Attack and Theft of Your Devices
One of your strongest counters to surveillance, attack, and theft of your devices is making sure the data on them is secure. Really, the only way to do that in this day and age is to make sure they are full disk encrypted. Full Disk Encryption refers to taking a hard drive inside of a device and encrypting it as a whole so that all the files it has are converted into an unreadable form (encrypted) and not accessible without the password to decrypt them. Some devices, like those running iOS, do this by default. Other’s like Macbooks and PCs running Linux, need to have these features enabled and setup. To start, I’ll dive right into FileVault2, which is the OSX built in Full Disk Encryption because it is what I use on my primary machine.
See: File Encryption Software on PrivacyTools.io
FileVault2
Native to all versions of Lion and up, FileVault2 is the advancement on the original FileVault that only encrypted the home folder. It uses 128bit AES in XTS mode to encrypt the disk and is highly suggested when setting up a new computer that has Yosemite or higher. Good strategy here on part of Apple to include a dedicated section about it in the Initial Computer Setup when you first setup OSX. When you set up FileVault2 for the first time, it requires you to have a password on the current administrator account and uses a random number generator (with about 320 bits of randomness available after first boot) to create a recovery key. I would recommend not storing this Recovery Key with Apple even though they give you the option to do so; using 3 security questions and answers for recovery authentication of this key. Instead, I would recommend writing it down on a piece of paper temporarily until you can keep it in an encrypted form (7zip password protected archive) in something like your Tresorit Drive. Once you have securely saved this key, burn/shred the paper you originally wrote it down on. Based on some findings in this paper: https://www.cl.cam.ac.uk/~osc22/docs/cl_fv2_presentation_2012.pdf, FileVault2 uses PBKDF2 x SHA256 and 41,000 iterations on the password. This works to prevent bruteforcing the password due to the delay in checking the hashed password with the one stored on the system. There also doesn’t appear to be a limit to the password length so one could in theory create one 100 characters long without any issues other than delay before unencrypting. It is unknown, but unlikely, if a backdoor has been implemented by Apple in FileVault2. If you have a Mac, I would highly recommend enabling full disk encryption to keep your files safe.
LUKS
Short for Linux Unified Key Setup, LUKS is the full disk encryption solution used by many Linux/GNU based operating systems. Typically, it uses AES 256-bit encryption in CBC mode with SHA256 for hashing but that can be edited if needed to run other modes like XTS and decreasing the key size of the AES algorithm to 128-bit. Like FileVault2 for OSX, LUKS has no character limit for the passwords/passphrases and I have tested this with a 212-character passphrase consisting of letters, numbers, spaces, and symbols. The iteration count for LUKS is specified by the CPU power of the machine. For slower computers, this may be lower than wanted so it can be specified with the cryptsetup command. The command would be: cryptsetup luksFormat -i 15000 <target device> and I would recommend experienced users setting the value at no less than 20,000. For serious individuals, you would be wise to take that count above 70,000 with a passphrase over 40 characters. LUKS is also fully open source that along with its consistent use within Linux distributions makes it a very trusted choice for FDE.
VeraCrypt
When TrueCrypt died back in 2014, there was a lot of talk about the security issues that the developers could have been talking about on their website. Was there really security issues? Were they served a National Security Letter mandating a backdoor in an update version be released? Nobody really knew anything above and beyond speculation and it had many people becoming weary. For Mounir Idrassi, that meant taking all of the security issues present in the TC 7.1a release and fixing them in a fork of the project called VeraCrypt. It is considered to be the official upgrade to TrueCrypt by many as it is open source, and had a code audit completed in October of 2016 (see: https://ostif.org/the-veracrypt-audit-results/). I am a firm believer in VeraCrypt as it boasts some serious enhancements to the general security of TrueCrypt while also adding in features of its own that really make the program that much more secure to use.
For starters, they got rid of RIPMD-160 due to it only being 160 bits on the hash and replaced it with SHA-512, which is of course the successor of SHA-256. They also upped the default iteration count in the initial releases to 500,000 iterations on the password, which is a serious, serious improvement over the 1000 that TrueCrypt offered. Recently, they have implemented a feature called a PIM value which stands for Personal Iterations Multiplier and not only gives us a third step of verification to decrypt alongside your passphrase and keyfiles, but also allows us to specify our iteration count in a unique but secure way. When specifying a PIM value for system encryption, you take your PIM value and multiply it by 2048. For container-based encryption you take 15000 and add it onto your PIM value times 1000. This means you could specify a PIM of 999 and have an iteration count over a million for an encrypted container. Some serious security for your files to be resting inside of.
VeraCrypt has also made some graphical improvements over TrueCrypt, is being consistently updated, and included little tweeks to improve usability, like adding a randomness meter to the “move your mouse screen” to display the random entropy you are acquiring. This, alongside the recent audit, is very promising for the tech industry. We now have a very solid encryption program to rely on for keeping our information and data secure.
As of October 2016, VeraCrypt has implemented some new algorithms for both encryption and hashing which is a positive move forward. Camelia and Kuznyechik were added as encryption algorithms, but stand-alone and are not able to be paired like the original three, and Streebog has been added as a hash algorithm. Moving forward, it would be nice to see an algorithm for encryption with Camelia and Serpent as a team. That way, we are able to get the added security of two encryption algorithms in cascading fashion, without having to rely on AES.
VeraCrypt Encryption Algorithms:
- Serpent
- AES
- TwoFish
- Camellia
- Kuznyechik
VeraCrypt Hash Algorithms:
- SHA-256
- SHA-512
- Whirlpool
- RIPMD-160
- Streebog
iOS Devices
Apple Mobile Devices running anything above version 8.0 are protected with Full-Device Encryption by default known as “Data Protection” in your Passcode settings. However, there is a big leap up from the 5C to the 5S and all devices from here on out that have TouchID. As a starting point, you should refresh yourself on the recent events that have unfolded between Aple and the FBI. I have posted links about this further down in the paper but it should be easy enough to search online. If you have one of the listed devices above 5S (6, 6S, 7, etc), you will have the best encryption Apple currently offers for their devices. Your iPhone will have a hardware chip inside called Secure Enclave that manages all encryption and the delays in between password attempts. All versions of iOS above 8 employ 256-bit AES full-device encryption in a unique way that protects all data past the lock screen. This data on the above listed devices is secured using an ephemeral key generated on boot that is entangled with your devices unique UUID to do the encryption. Your passcode protects this key. By default, a 4 digit numeric code is suggested when setting up a passcode/TouchID but users have the option to enable much longer, alphanumeric passcodes for greater security. This is something I would recommend doing.
As well, your device makes use of PBKDF2, as described above, with an iteration count high enough to generate an 80ms delay on passcode inputs (key stretching). This along with a few other security features effectively prevents bruteforce attacks on a device with a passcode longer than 11 characters. The other security features include a lockout after 5 failed passcode attempts and each attempt after that, Data Wipe feature than can be enabled to wipe your device after 10 failed attempts, and mandating your passcode to be inputted instead of using TouchID when you turn off your device or if you have not bypassed the lock screen in 48hrs.
Alongside the device level encryption that is deemed to be very secure (but not 100% yet), Apple pushed out properly encrypted iCloud backups in 9.3 that use the device’s passcode to encrypt the backup. Prior to this, Apple was able to give out iCloud backups when presented with a warrant and a user really couldn’t be deemed completely secure unless they disabled these backups on the device. But now, all of your information is backed up securely to iCloud and you still have the option to encrypt full backups to your computer. This being said, I would caution users to not backup applications that store sensitive information to iCloud. You have 2 modes of encryption protecting your device backups to iTunes if you are using full-disk encryption on your computer, but only one line of defense with iCloud.