19

I use Fedora Linux and was recently looking into doing Full Disk Encryption on data drives such as /home on some of my / my family's PCs. I understand that LUKS security will be partially dependent on having strong passwords and not doing very obviously stupid things (saw some articles where people were auto-unlocking an encrypted /home partition during boot by passing a keyfile located on an unencrypted / filesystem - which anyone with a livedisc could also use those to open the LUKS container).

The main reason why I am concerned was that while googling various things about LUKS / its settings, I came across this Elcomsoft article which talks about breaking LUKS encryption. If that wasn't bad enough, I also saw they had a similar article about breaking Veracrypt... so I am at a loss as to what I should use for FDE.

I admit that most of the infosec stuff is over my head. But I'm still not clear if I can make those solutions secure merely by tweaking settings/algorithms/etc or if the flaw was with something in the projects themselves (I thought it sounded like the latter). On the one hand, the article itself says that

LUKS can be viewed as an exemplary implementation of disk encryption

But the scary part is in the "Breaking LUKS Encryption" sections and how they make it sound like it is very easy to do with their software.

Trying to google was likewise unhelpful as all of the information I could find on "how secure is LUKS?" etc either talked generically about the underlying crypto algorithms or was dated before the Elcomsoft articles. But my reasoning is that in this day and age, it is probably a bit naive to assume that all thieves that might "smash-and-grab" a PC or hard drive from someone's home are going to be technical neophytes. The cheaper of the 2 products mentioned in the LUKS article appeared to be $300 USD. Not chump change but also not unaffordable by any stretch if someone really wanted to get in.

My initial guess based on these is that FDE with LUKS/Veracrypt would still be "better than nothing", but if I was unlucky and tech-savvy thieves nabbed my PC then data like Tax Records etc might not be protected. Likewise, anything I had almost certainly would not be protected from government entities or law enforce if they have access to the Elcomsoft products or similar software. Assuming I don't piss off anyone in power, the most I probably have to worry about from the "gov'mint" is saving memes or maybe keeping an offline copy of a few youtube videos... but it is troubling to think that it is so easy for FDE to be defeated.

Am I reading this wrong / is it just sales "spin" from Elcomsoft trying to market their product? If it is as easy to defeat as they make it sound, then can anything be done on the end user end to better protected against? If so, what / how?

When I see things like

Up to 10,000 computers and on-demand cloud instances can be used to attack a single password with Elcomsoft Distributed Password Recovery.

The first thing that goes through my head is to wonder if I can configure LUKS to only allow at most X attempts per minute, with X as some small number like 3. But AFAIK this option does not exist and is nothing more than a dream...

zpangwin
  • 321
  • 2
  • 9
  • 3
    Note that "if I can configure LUKS to only allow at most x attempts per minute" would not be helpful in this case as any serious attacker with local access can bypass any official interface and just use their own software on the raw encrypted data. – Jon Bentley Jun 09 '21 at 11:49
  • @Jon Bentley, good point. I guess even if the crypto-container supported some internal "last access time" or some such, a custom software could just ignore that rule – zpangwin Jun 09 '21 at 17:38
  • @zpangwin, indeed, that's the thing with full-disk encryption: there's no way to throttle or stop the attacker after they've stolen or copied your disk. Something like passwords can be invalidated if the password hashes leak, but the encrypted data on the disk can't. So, you need to make the key derivation function slow enough in advance. – ilkkachu Jun 09 '21 at 18:32
  • 7
    `But the scary part is in the "Breaking LUKS Encryption" sections and how they make it sound like it is very easy to do with their software.` - A software vendor has a financial incentive to make it sound like their software can do something "with ease". –  Jun 10 '21 at 09:50
  • That's one reason why Microsoft insists on having BitLocker use TPM+PIN instead of a password: the PIN is shorter but the retry rate is hardware-limited and out of reach. – user1686 Jun 10 '21 at 16:28

3 Answers3

56

No, Elcomsoft cannot break LUKS or Veracrypt. What they do is to guess the password. Any password-based encryption mechanism can be broken by guessing the password: this is not a flaw in the encryption software.

Encryption software can and should mitigate the risk of guessing by making it costly. Both LUKS and Veracrypt do it securely (at least with default settings, it might be possible to weaken the settings if you misconfigure them). They can't completely elimintate the risk of password guessing or snooping because by design, if the adversary figures out what the password is, they will be authorized.

You can protect yourself by using a password that has a high enough entropy. (See Confused about (password) entropy, Calculating password entropy?, Password entropy in layman's terms, How can I create a secure password?, …) Note that length helps entropy, but is not enough: a long password can be weak (for example, the first line of a well-known song would make a bad password). Special characters contribute very little to entropy and are counterproductive. A high-entropy password must be randomly generated: humans are very bad at generating entropy. Diceware is popular, though actually using dice rather than using a computer for the random generation isn't actually more secure (except in extremely rare, usually made-up circumstances).

If you can't remember a strong enough password, you can store it (or a password-equivalent key file) on removable storage. Of course, there's then the risk of losing the device containing the key file. Or you can use a TPM and bind the encryption key to that TPM, which carries the risk of not being able to access the data if your motherboard breaks.

Gilles 'SO- stop being evil'
  • 51,415
  • 13
  • 121
  • 180
  • Thanks, I think something I read in the "Extracting Encryption Metadata" section had given me a false impression that there was something "wrong" / "bad" in the way LUKS did things that bruteforce was only one of the options they were using. After reading your and vidarlo's responses, I can see that I misinterpreted that the first time through. So aside from password strength, would you recommend changing any of the default LUKS settings (e.g. `--hash sha512` etc)? – zpangwin Jun 08 '21 at 18:56
  • 2
    @zpangwin Default settings for LUKS are fine. The weakest link for FDE is weak passwords and evil maid attacks, not the hash/cipher. – Navin Jun 09 '21 at 04:48
  • 1
    That second article about Veracrypt seems to also mention scraping encryption keys off from the memory of a running system. But that's also a generic attack requires having admin access to a running system with the drive unlocked, and if they get to do that, they get to do a lot of other stuff too. Starting with just copying all the interesting data from filesystem the same way the legitimate user would. – ilkkachu Jun 09 '21 at 18:36
  • One could additionally increase the number of hash iterations (PKDF2 rounds) while setting up disk encryption (`cryptsetup -i ...`). That means it will take more seconds to unlock during boot but it will slow down all brute force attacks, too. – Ned64 Jun 10 '21 at 11:11
  • @Ned64 Yes that would slow it down, but in polynomial time. I had just a brief look at Elcomsoft article and I didn't see whether they copied the metadata to one machine or a cluster, but I guess that their brute force attack relies on parallel computation. – FluidCode Jun 10 '21 at 22:05
  • “for example, the first line of a well-known song would make a bad password” Would it really? Does anyone try attacks with whole sentences or phrases? The amount of possible word combinations is huuuge, even when using proper English grammar. – Michael Jun 11 '21 at 06:22
  • 1
    @Michael It's a well-known scheme for generating passphrases, so of course people who are trying to guess passphrases do it. The number of combinations of arbitrary words quickly gets huge with length, but the number of actual English sentences is much smaller, and the number of songs is waaaaay smaller. For example Spotify boasts 70 million ≈ 2^26 tracks (probably far fewer songs due to instrumental pieces and duplicates), it's not all that large. In comparison an [xkcd 936](https://xkcd.com/936/) passphrase (4 random words) is around 2^44 bits. – Gilles 'SO- stop being evil' Jun 11 '21 at 09:37
21

While LUKS offers strong protection against brute force attacks by using thousands of iterations of a hash function during key derivation, we have significant advances in password recovery attacks compared to what we had in the past. Brute-forcing a password today becomes significantly faster due to the use of GPU acceleration, distributed and cloud computing. Up to 10,000 computers and on-demand cloud instances can be used to attack a single password with Elcomsoft Distributed Password Recovery.

Taken from Elcomsoft's webpage.

They don't have any cryptographic breaks, only brute force attacks. So security still relies on having a good pass phrase - Elcomsoft brings nothing revolutionary to the table, only a sleek UI for performing the brute force attack.

vidarlo
  • 14,890
  • 2
  • 43
  • 56
  • Thanks, I had seen that about the bruteforce but when I read it I assumed it was one option of many rather than the *only* option. re-reading it after seeing your response, I can see that I was mistaken. – zpangwin Jun 08 '21 at 18:50
  • 4
    If you are OK with not having a nice UI, and don't want to pay $300, HashCat supports LUKS password cracking and is free. Performance will depend on the hardware you've got available (high end graphics cards are best - although frustratingly cryptocurrency miners are making them hard to find at the moment), but it may help give you an idea of what state-of-the-art attack capabilities look like. – James_pic Jun 09 '21 at 10:36
  • @James_pic Unfortunately, even if if cryptominers weren't a thing, I probably couldn't justify the cost of a high end GPU right now. But I do appreciate the mention. Have been meaning to at least learn enough cracking (and network tools) to properly audit my own stuff, so will try to check that out when I get some time. – zpangwin Jun 09 '21 at 17:42
  • Mid-range and low-end GPUs will also work, albeit slower, as will servers with GPUs rented from your cloud provider of choice. – James_pic Jun 09 '21 at 18:16
2

Other answers have thoroughly addressed the nature of Elcomsoft's capabilities and explained that there is no known cryptographic vulnerability in LUKS itself. To answer the core question "Is LUKS encryption effective for hard drives on home computers?," you must consider the value of the information you are trying to protect, and the risk that you are trying to address with full-disk encryption. Who are the threat actors who would target your home computer hard drives? What are their intent and capability, and what is the likelihood that you will be targeted? Do you have any other vulnerabilities that increase the likelihood of attack (for example, are you a political opponent of a totalitarian government?)

On one end of the threat spectrum, consider a typical residential burglar. A burglar may be the most likely threat, but also one with low technical capabilities. Their intent is probably to steal your PCs for resale on the black market, and they may not even think to check the hard drives for valuable information. A burglar will probably be defeated by nearly any form of disk encryption that requires a reasonably hard-to-guess password (they may be defeated by a command prompt). They are unlikely to take the time to brute-force your LUKS passphrase.

On the other end of the spectrum, perhaps you are a spy for foreign government (or working on a subversive humanitarian project in a totalitarian regime). Your threat actor may be a state security service (eg FBI or MI5) with sophisticated technical capabilities and extensive resources. If that's the case, there may be nothing you can do with LUKS encryption that will really protect your data. They may know of a zero-day exploit that they can use to install a keylogger to capture your passphrase, and they certainly know how to brute-force a LUKS passphrase. Alternatively, they may use their resources to completely bypass disk encryption. For example, the FBI used special tactics to arrest Ross Ulbricht (aka "Dread Pirate Roberts), the creator of Silk Road. Four undercover agents surrounded him while he used his laptop in a public library. Two agents distracted him, while two more agents grabbed his open laptop before he could lock it and started to extract evidence.

Consider a wholistic picture of the risk you are trying to mitigate before you go too far down any one rabbit hole. Disk encryption is certainly necessary, but only as part of a comprehensive security system (physical security, malware protection, phishing education, firewall, regular software updates, etc.)

Craig Finch
  • 121
  • 3
  • I agree with much of what you say but I do disagree with "A burglar may be the most likely threat, but also one with low technical capabilities. [..] A burglar will probably be defeated by nearly any form of disk encryption [..] They are unlikely to take the time to brute-force your LUKS passphrase."; it's not that it couldn't go down exactly as you say. But this part makes assumptions and seems bit lazy/naive. It doesn't consider rising tech skills of general public (including the burglar) or him simply knowing someone with both the tech skills and lack of ethics that is willing to try – zpangwin Jun 11 '21 at 17:32
  • @zpangwin You and I differ on our assessment of the risk posed by burglars, and that's fine. My overall point is that controls like disk encryption need to be thought of in the context of risk. Risk analysis is a key part of infosec in business settings, but seldom thought about in the home. – Craig Finch Jun 14 '21 at 15:51