Hard Disk Encryption Options

Discussion in 'privacy technology' started by driekus, Jan 27, 2015.

  1. driekus

    driekus Registered Member

    Joined:
    Nov 30, 2014
    Posts:
    489
    As per our discussion on https://www.wilderssecurity.com/threads/to-write-or-not-to-write.372724/ we are looking to map out the options for encryption. Each of the options would be assessed according to several criteria:

    1.) Ease of setup and use
    2.) Ability to protect against data thieves (not nation state level)
    3.) Ability to protect against law enforcement and low level government
    4.) Ability to protect against nation state high level government organizations

    For solutions I propose that we stick to a few per operating system.

    Linux
    LUKS-dmcrypt (FDE)
    Ubuntu OTS encryption (FDE)

    Windows 8
    Bitlocker (FDE)

    Windows XP/Windows 7
    Truecrypt (Container)

    Android
    In-built android encryption (FDE)
    Encdroid (Container)
    EDS (Container)

    iOS
    In-built iOS encryption (FDE)

    Mac OS
    Mackeeper

    Cross Platform (Mac, Linux, Windows)
    Intel SSD encryption (FDE)
    TrueCrypt (Container)


    I realize some solutions like Truecrypt will fit into multiple categories.

    I have deliberately missed out a lot of options because I want to hear what you use. Preference is for trust no one encryption that could withstand nation state level actors. However for some OS like android and iOS I dont believe this is possible.

    Also if there are other criteria you believe missing please let me know.

    We are looking to create tutorials on as many of these alternatives as possible so if there is an area you are passionate about let me know. Personally Iam most comfortable with Linux dm-crypt/LUKS. I have worked with others but there are probably users here with extensive knowledge that would be beneficial for the tutorial.
     
    Last edited: Jan 28, 2015
  2. Yuki2718

    Yuki2718 Registered Member

    Joined:
    Aug 15, 2014
    Posts:
    1,257
    Built-in encryption on Android, at least before 5.0 LolliPop, can cause lots of troubles.
    1. You have to enter pass-phrase everytime you (re)boot your phone and in Android it is also used as an usual PIN lock-code. For security perspective, of course you have to use strong pass-phrase but cuz it is too much inconvenient many people use weak one so can be easily brute-forced.
    2. Any failure on encryption will cause you to loose all your data. I myself experienced this, tho not serious matter for me.
    3. Some device can't update its OS if encrypted.
    4. There's some performance delay, even in 5.0 LP.

    I recommend EDS or Encdroid for encryption on Android. EDS is compatible with LUKS, TC, VC, and Cybersafe and provide nearly same UX as on-the-fly encryption. Of course on-the-fly encryption is impossible in Android unless you rooted, so it uses temporary files so there's some security concern, but I think it is the best encryption program in Play Store. Encdroid is one of EncFS implementation on Android, also handy and worth considering. There're some known vuln in current version of EncFS, but as of always the case of vuln in crypt, they are quite conditional and non of them are practically dangerous in usual usage scenario.
     
  3. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    6,032
    There's also FDE with ZFS in FreeBSD 10.

    Anyone used it?
     
  4. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,151
    Location:
    UK
    Couple of thoughts on what might be included - I assume this is all about at-rest encryption.

    Distinguish between FDE and container encryption - in practice, they're quite different.
    The importance of strong passwords and the amount of entropy you likely need.

    Personally, I've got experience with LUKS/dmcrypt, Bitlocker (which is definitely W7 too, and is the only way of having password-less boot FDE in that context if you use a TPM), Truecrypt (cross-platform container mode), and EFS (for when there's no TPM). I've also used pendrive Linux with encrypted Home directories (which I think is Luks again).

    I don't know if you were also thinking of file/zip encryption too.
     
  5. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    Regarding full disk encryption, if your operating system and data are on the same disk, using that OS also makes your encrypted data readable. When in use, and encrypted OS can be compromised just as easily as an unencrypted OS. If a user wants to encrypt both the OS and the data, they should consider putting them on separate drives that use different passwords/phrases.
     
  6. driekus

    driekus Registered Member

    Joined:
    Nov 30, 2014
    Posts:
    489
    At the moment focused on FDE and container.

    Personally not familiar with EFS, can you elaborate?
     
  7. driekus

    driekus Registered Member

    Joined:
    Nov 30, 2014
    Posts:
    489
    Agreed, I will include that as a good practice.
    I will also look at passphrase usage, given how poorly most people select passwords.
     
  8. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    A lot of people would disapprove of my password selection and storage method, but it's worked quite well for me. Using PGP and any random keys, I created half a dozen source files, each about 1000 lines long. The passwords are copied and pasted from one of the source files. I have a little encoding system that tells me which file I used, the line and character the copy starts on and the line and character on which it ends. The encoded locations are contained in another text file. Each entry also contains meaningless characters. Some of the characters are shifted. I'd like to see someone translate that gibberish text document into passwords. They'd need to have all of the source files and would have to determine what order I wrote down the locations, which characters are shifted, and which are just padding.
     
  9. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,151
    Location:
    UK
    EFS is Windows encrypted file system using symmetric key encryption based on keys stored under the user account. Works on W2000 onwards on business editions of Windows. Default AES-256 encryption.

    The application of it is that it provides seamless encryption of files on a per-user basis, so that other users and disk inspection "cannot" see the data, and where there isn't a TPM chip to make FDE easy. For some classes of use, and particularly on a laptop, it simply isn't realistic to be popping in a strong password every time you have to reboot, because they are up and down so often.

    If you are logged in, you get to see the files transparently, otherwise not. So, for example, you can encrypt the mailbox and MyDocuments folder (and some LAD files), so that if a laptop is stolen, it isn't viewable. But it has vulnerabilities and it is file-by-file (or inherited from folders) so it doesn't protect swap etc. I find it useful, for some things on some machines. I suppose the equivalent on Linux is encryption of Home directories as you get with Ubuntu setup these days (I think swap is also encrypted in those circumstances, not sure). Key management is no biggie because I don't bother, it's essentially tied to the machine and account - the data is backed up using different schemes (where EFS doesn't survive anyway).

    While I remember, one of the issues with FDE is that many of the schemes assume the machine is single-user for password entry; of course, there are commercial offerings where this is not true, and they may also support various smartcard TFA solutions too.

    There appear to be a couple of camps regarding password selection, the one I prefer being Diceware based, because I'm fast at typing real words, and I find it quite easy to remember the word combinations. But it's very important to adopt strict randomness, any attempts to use "clever" phrases tend to be obvious to the cracking software. Other people seem to like the 12-16 letter/character combinations OK with some form of mnemonic, but I dislike them.

    I have looked at using a Yubikey with a long static password for FDE (plus a PIN), but don't think this all that good because the second factor is likely to be nicked along with the machine!
     
    Last edited: Jan 29, 2015
  10. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    6,032
    But aren't Windows passwords easy to crack and/or work around?

    How is EFS protected from that?

    Linux passwords are also easy to reset if you have console access. And so I suspect that encrypting /home/user/ is similarly vulnerable. But I've always used dm-crypt/LUKS, so I've never looked into that.
     
  11. krustytheclown2

    krustytheclown2 Registered Member

    Joined:
    Nov 18, 2014
    Posts:
    210
    Windows passwords are trivial 99% of the time with Ophcrack and the like

    Encrypting your home folder is going to protect your privacy in the case of the seizure/theft of your computer almost as well as FDE (in that it will shield your personal data not what programs you have installed and such), but it may not protect well against surreptitious modification of your system by somebody with physical access. It is important to note that even LUKS protected system can be attacked through the unencrypted boot partition and of course hardware with physical access, so in practice there isn't a huge difference between the security of the two options.
     
  12. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    6,032
    So does cracking Windows password get around EFS?

    Does cracking Linux password get around encrypted home?

    I agree that LUKS is vulnerable with physical access. But it takes prior access, to install a keylogger or mess with /boot, or access to get the key from RAM before it fades. And I'm not aware of any exploits via /boot that don't depend on capturing the passphrase during entry. So as long as there's no physical access while I'm using the system, LUKS isn't vulnerable. Right?
     
  13. Yuki2718

    Yuki2718 Registered Member

    Joined:
    Aug 15, 2014
    Posts:
    1,257
    No, as long as you use strong password cracking it by Ophcrack (or other) is impossible. Ophcrack is just a bruteforce program when rainbow table of LMHush and NTLMHush is not available i.e. password is strong. I know many people actually use weak password tho. As a practice more prefered method to compromise Windows' account in domain is pass-the-hush, but I think it can't be used to decrypt EFS.
    Unless you're attacked by sophisticated exploit (especially kernel exploit) and it silently install, say, BIOS/UEFI rootkit. It's quite unlikely but government agencies would be able to.
    So as we once talked, not to be flagged among mass is first and important defence.
     
  14. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    6,032
    Right. But I don't do anything on host machines except running VMs and maintenance. So they'd be attacking a VM. Still, my only hope then would be breakout failure.
    Right. For Mirimir, it's too late :rolleyes:
     
  15. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,151
    Location:
    UK
    Well, yes. I do use strong account passwords and TFA with HMAC/SHA1 Yubikey support, and that gives me better confidence in the EFS part. But I do not rely on it for anything other than "routine" theft threats and fulfilling my Data protection responsibilities - far better than the government do! There's been a data breach involving the Justice department sending disks around about sensitive cases, and losing them. Presumably unencrypted. Gah.

    Incidentally, I'd like to raise an issue that's big for me regarding the scope and level of protection of at-rest encryption. Basically, with things like LUKS/dmcrypt, Bitlocker, Truecrypt, EFS, once you unlocked the data for the user, it's completely open to anything running in user-space malware. I assess my threat as mainly from remote sources (the theft issue is the main local one and easily solved, and I'd expect the state to wave a wrench at me) - but the problem with the remote threat is that none of the encryption mechanisms do much about providing in-depth protection of data. Once you've opened a Truecrypt container or partition, it's open to all processes (and if you're not careful, it's open to all users of the box too!) So this leaves it all open to exfiltration and ransomware. While I do VM data partitioning stuff manually like Qubes does, it's painful and imperfect. RBACs are an approach to that, but currently quite fragile to implement. What I want is quite simple really: any process or child/spawned process that gets access to the internet does not get access to my real file systems. Any process or child/spawned process that gets access to my real file systems does not get access to the internet. Of course, you then need some kind of customs-control for handing stuff over the divide, but that could be managed. For now, I'll work with VMs.
     
  16. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    6,032
    I like that summary :thumb: That's my goal too.
    :)
     
  17. Yuki2718

    Yuki2718 Registered Member

    Joined:
    Aug 15, 2014
    Posts:
    1,257
    Tho there's no ITW case, there've been many reports of VM vuln which allow attacker to infect host or compromise hypervisor. So I'm not sure how much VM makes sense against dedicated, well-resourced attacker. It will at least add some complexity, but from what I've seen such complexity usually don't stop skilled attacker.
    lol. I hope Yuki2718 is still safe!:argh:
    Good point!:thumb: such access control and privilege isolation makes your data much safer.
     
  18. deBoetie

    deBoetie Registered Member

    Joined:
    Aug 7, 2013
    Posts:
    1,151
    Location:
    UK
    My feeling about the use of VM/hypervisors is that it will (does) deter standard malware, even sophisticated stuff, where they will go for the low-hanging fruit and are known to actively avoid security researchers with VMs. Of course it will not stop targeted attacks specifically against the hypervisor, I'd assume they would be high-value limited-use attacks.
     
  19. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    6,032
    Right, dedicated hosts with network and sneakernet isolation are sometimes prudent ;)
     
  20. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    If one wants to use virtual machines in this manner, the host system should be as hardened as possible and stripped of all unnecessary components. One possible setup would be to use the computers hard drive as strictly encrypted storage, no operating system. The stripped operating system, encryption, and virtualization software could be put on a read-only media, CD or DVD. This way the host can't be altered and the virtual systems are untouchable without it.
     
  21. mirimir

    mirimir Registered Member

    Joined:
    Oct 1, 2011
    Posts:
    6,032
    I like that idea :thumb:

    Creating such a Linux LiveDVD would be easy using bootcd. The FDE HDD would hold just the "VirtualBox VMs" folder.

    Another thing to play with :eek:
     
  22. noone_particular

    noone_particular Registered Member

    Joined:
    Aug 8, 2008
    Posts:
    3,798
    I experimented quite a bit with Win 98 and encrypted partitions, loading alternate registries and running applications from those partitions. At one time, I was running P2P software from an encrypted partition, with no evidence of its existence anywhere in Windows. Although the NT versions of Windows restrict (and log) you more, there's quite a few possibilities that will work with most any OS. A boot loader on a CD opens up all kinds of possibilities.
     
  23. KeyPer4Life

    KeyPer4Life Registered Member

    Joined:
    Dec 18, 2013
    Posts:
    974
    Vulnerabilities and other issues associated with Windows Encrypted File System. (EFS)
    wikipedia
     
  24. driekus

    driekus Registered Member

    Joined:
    Nov 30, 2014
    Posts:
    489
    I am going to try to focus on the basics here. I wont focus too heavily on the detail (but will mention some of the EFS vulnerability concerns). I think it will be better if this is highly accessible. Most readers here are very well versed on security but the goal is to try and provide accessible articles and tutorials, potentially even get it put on a site like the EFF.

    I am going to start writing tonight and will post sections as I get to them. I am keen to do the Linux and Intel SSD stuff and if no one else is interested can do other parts (except for Apple). Looking for general tutorial on pro's and con's, installation, pitfalls and security concerns. Also guessing by interest that if stuff gets put in people will be happy to go through and edit for clarity.
     
  25. Yuki2718

    Yuki2718 Registered Member

    Joined:
    Aug 15, 2014
    Posts:
    1,257
    Wait, what vulnerability concerns? EFS don't have vuln on XP+ as seen in KerPer4Life's link. Also listed "issues" should be actually obvious and natural, all of them except admin priv (this is obvious too) are also true to most of other file/folder encryption solution.

    Of course normal user won't know those basics so explaining them is not bad, but please be careful when you do this as I'm too much tired of hearing again and again "using RIPEMD for TC is dangeous" or "AES is broken till x rounds" etc, sometimes even from seemingly techy people, cuz they don't know how those crypt are used. (I've been answering these things in another forum too.)

    The word vulnerability gives people strong impression as if this itself is dangerous even when that's not the case. vulnerable hash is only dangerous when it is used for authentication or identity check, and any known attack against AES is only on quite limited situation and still not complete. Even DES is practically not yet broken as an algorithm, as all known attack requires fairly unlikely condition, so only practical problem is its key size (64 bit).

    So if you write about this, call for attention to attack condition and reality of attack to reduce this endless confusion.
     
Loading...