mjg59 | PSA: upgrade your LUKS key derivation function:
Many Linux users rely on LUKS for their disk encryption but perhaps they need to pay a bit more attention to it. If the disk was encrypted more than a few years ago (LUKS Version 1) it appears that it might not be secure enough to withstand a concerted attack. It is time to check whether you are using Version 2, and if not the fix takes a few minutes. [JR]
Here's an article from a French anarchist describing how his (encrypted) laptop was seized after he was arrested, and material from the encrypted partition has since been entered as evidence against him. His encryption password was supposedly greater than 20 characters and included a mixture of cases, numbers, and punctuation, so in the absence of any sort of opsec failures this implies that even relatively complex passwords can now be brute forced, and we should be transitioning to even more secure passphrases.
Or does it? Let's go into what LUKS is doing in the first place. The actual data is typically encrypted with AES, an extremely popular and well-tested encryption algorithm. AES has no known major weaknesses and is not considered to be practically brute-forceable - at least, assuming you have a random key. Unfortunately it's not really practical to ask a user to type in 128 bits of binary every time they want to unlock their drive, so another approach has to be taken.
This is handled using something called a "key derivation function", or KDF. A KDF is a function that takes some input (in this case the user's password) and generates a key. As an extremely simple example, think of MD5 - it takes an input and generates a 128-bit output, so we could simply MD5 the user's password and use the output as an AES key. While this could technically be considered a KDF, it would be an extremely bad one! MD5s can be calculated extremely quickly, so someone attempting to brute-force a disk encryption key could simply generate the MD5 of every plausible password (probably on a lot of machines in parallel, likely using GPUs) and test each of them to see whether it decrypts the drive.
(things are actually slightly more complicated than this - your password is used to generate a key that is then used to encrypt and decrypt the actual encryption key. This is necessary in order to allow you to change your password without having to re-encrypt the entire drive - instead you simply re-encrypt the encryption key with the new password-derived key. This also allows you to have multiple passwords or unlock mechanisms per drive)
Good KDFs reduce this risk by being what's technically referred to as "expensive". Rather than performing one simple calculation to turn a password into a key, they perform a lot of calculations. The number of calculations performed is generally configurable, in order to let you trade off between the amount of security (the number of calculations you'll force an attacker to perform when attempting to generate a key from a potential password) and performance (the amount of time you're willing to wait for your laptop to generate the key after you type in your password so it can actually boot). But, obviously, this tradeoff changes over time - defaults that made sense 10 years ago are not necessarily good defaults now. If you set up your encrypted partition some time ago, the number of calculations required may no longer be considered up to scratch.
And, well, some of these assumptions are kind of bad in the first place! Just making things computationally expensive doesn't help a lot if your adversary has the ability to test a large number of passwords in parallel. GPUs are extremely good at performing the sort of calculations that KDFs generally use, so an attacker can "just" get a whole pile of GPUs and throw them at the problem. KDFs that are computationally expensive don't do a great deal to protect against this. However, there's another axis of expense that can be considered - memory. If the KDF algorithm requires a significant amount of RAM, the degree to which it can be performed in parallel on a GPU is massively reduced. A Geforce 4090 may have 16,384 execution units, but if each password attempt requires 1GB of RAM and the card only has 24GB on board, the attacker is restricted to running 24 attempts in parallel.
So, in these days of attackers with access to a pile of GPUs, a purely computationally expensive KDF is just not a good choice. And, unfortunately, the subject of this story was almost certainly using one of those. Ubuntu 18.04 used the LUKS1 header format, and the only KDF supported in this format is PBKDF2. This is not a memory expensive KDF, and so is vulnerable to GPU-based attacks. But even so, systems using the LUKS2 header format used to default to argon2i, again not a memory expensive KDF. New versions default to argon2id, which is. You want to be using argon2id.
What makes this worse is that distributions generally don't update this in any way. If you installed your system and it gave you pbkdf2 as your KDF, you're probably still using pbkdf2 even if you've upgraded to a system that would use argon2id on a fresh install. Thankfully, this can all be fixed-up in place. But note that if anything goes wrong here you could lose access to all your encrypted data, so before doing anything make sure it's all backed up (and figure out how to keep said backup secure so you don't just have your data seized that way).
The full instructions are in the linked source.
(Score: 1, Troll) by Mojibake Tengu on Wednesday April 19, @08:13AM (2 children)
Disk encryption should be cast upon whole drive even before the filesystem is engaged.
Like what geli does even before the BSD loader starts form ZFS.
That's only way to be sure nothing got poisoned, especially bootloader.
Linux opsec is a joke. On par with Windows.
Even MacOS does this correct right.
The edge of 太玄 cannot be defined, for it is beyond every aspect of design
(Score: 5, Insightful) by pTamok on Wednesday April 19, @09:35AM
If the whole drive is encrypted, how does the cpu get the non-encrypted instructions to run the bootloader? Both Windows and Linux need somewhere that is non-encrypted, and that somewhere is usually the separate EFI System Partition (ESP) on the same disk as the operating system and data.
I'm not familiar with the BSD set-up, but if the whole disk is encrypted, it means the bootloader must reside elsewhere.
(Score: 3, Interesting) by pvanhoof on Wednesday April 19, @04:43PM
If you hardware was tampered with (Evil MAID attack), it's always going to be game over. They can for example install keylogger hardware between your keyboard and CPU.
That's game over no matter how many times you scream and yell BSD. Unless of course you each and every time you boot check all of your hardware with a microscope or something. Which, even while you scream and yell BSD very very loudly, you aren't doing.
Because of that the bootloader and initrd not being encrypted, does not really matter. You perhaps made it a little bit more easy for the evil maid.
I suggest putting your bootloader and initrd on for example a USB stick. And boot your encrypted LUKS from that. Then don't forget to take the USB stick with you when you leave the computer behind. Else it's also game over.
(Score: 2, Insightful) by Anonymous Coward on Wednesday April 19, @09:49AM (3 children)
A 21 character password with upper+lower case, numbers and popular punctuation has about 65^21 combinations.
Sure attackers can use many GPUs. Say you have 1 million devices that do 600 million SHA256 per second.
Say pbkdf2 with "only" 10,000 rounds of sha256.
65^21 x 10000 / (1 million x 600 million) seconds = 6.22206506 × 10^19 years. Sure in theory you'd probably might find it less than 50% of the way through but in practice you're going to use a different method.
Thus I doubt the problem was with pbkdf2 and I suspect the article is a distraction from the actual methods used/vulnerability exploited.
(Score: 1, Insightful) by Anonymous Coward on Wednesday April 19, @01:12PM (1 child)
I had estimated the password complexity at around 2^80. Too much for casual password cracking, unless he just used chained dictionary words. Assuming a GPU core can do 2^30 checks/s, there are 2^16 cores on a GPU and the attacker has a cluster of 2^10 GPus, they are still 2^24 = 16M seconds away from a break, in the order of half a year. They would also use up around 5 GWh = 5M kWh of energy, at a cost of half a million euros (assuming 300W GPUs, 10ct/kWh). And 2^30 checks/s is overly optimistic, because the GPU will, even with the old algorithm, use MUCH more than a handful of cycles on pbkdf2.
- Even if the French had an almighty password cracker, would they put it to use or even reveal its existence for some sorry anarchist dude?
- mjg has been lobbying for an M$ signed boot chain before. He didn't run the numbers
Your suspicion might be correct.
(Score: 2) by crm114 on Wednesday April 19, @02:46PM
And this:
https://xkcd.com/538/ [xkcd.com]
(Score: 2) by driverless on Thursday April 20, @07:10AM
Yup. Shamir's Law says "encryption is bypassed, not attacked". If you're relying on brute force for your attack, you're doing it wrong. I've seen ridiculously over-the-top FDE with a huge long password, (snort) deniable encryption, a hardware key device, and nested encrypted volumes, accessed by LE as part of an investigation not by attacking the encryption but just by good old-fashioned detective work. If this guy used a "password was supposedly greater than 20 characters and included a mixture of cases, numbers, and punctuation" then you can guarantee they didn't get in by brute-forcing it.
(Score: 3, Insightful) by pTamok on Wednesday April 19, @09:58AM (2 children)
Having read the article, and the linked anarchist's article in the original French, there are some areas of ambiguity and lack of clarity.
The implication is that the French authorities have been able to decrypt a copy of the disks of the accused person's computers: both the (work) Windows computer, encrypted with Bitlocker; and the personal Linux computer running Ubuntu 18 encrypted with LUKS (presumably versions 1), with the PBKDF2 key derivation function. the authorities are unlikely to say how they did it.
Without more technical details of the encryption set-up, it is difficult to comment with any certainty - but that won't stop a lot of people commenting anyway, including me.
The accused person claims to have used a long password (of at least 20 characters) with a mixture of letters, numbers, and punctuation marks. Something like Long!-Password!-1234! is more 'guessable' than cd7e:48f5;547e,a393.5409, so without actually knowing the password, it's difficult to say how strong it actually was. Password guessers are pretty sophisticated these days.
In addition, someone watching or videoing the person entering the password is a pretty obvious way of finding it out. If you are a member of a group of people, and enter the password in company, or in areas where there could well be video cameras, then the strength of the password is pretty irrelevant if you are shoulder-surfed.
If the accused person has been a 'person of interest' to the authorities for some time, then it is also possible that a keyboard logger has been used.
Extraordinary claims require extraordinary proof - while I will not rule out the possibility that the French State have the means to crack 20+ random character passwords, I would suggest there are other, less labour-intensive methods that could have been used. From a technical point of view, if the French can do this, I'd love to know the technical details.
(Score: 0) by Anonymous Coward on Wednesday April 19, @03:14PM (1 child)
Hardware.
I was under the impression the hardware is backdoored on all modern silicon, e.g. Intel management engine [wikipedia.org].
(Score: 1) by pTamok on Thursday April 20, @09:40AM
That might be true, but the claim here is that the French administration decrypted a copy of the data on the disk drive.
Now, it might be that compromised hardware gave them the password/phrase to use on the copy of the data, but that is not what it being claimed.
This is why security-sensitive people are suspicious of the Intel Management Engine, AMD's Platform Security Processor, ARM's TrustZone/Confidential Computing Architecture, Apple's Secure Enclave, and Pluton. Essentially, they are 'black boxes' over which, you as the end-user, have no control.
There is very little work being done on building Open Hardware, which would be general purpose computers under end-user control.
(Score: 1, Offtopic) by Gaaark on Wednesday April 19, @02:38PM
My passwords are generally 27-30ish characters long, using a modified 'xkcd' word system: i use words with made up words/not real words/modified words and padding.
I seem to have a good mind for passwords and number combinations (shit: going in to work each day, i have to use at minimum 6 different number/character combinations (alarm systems, doors, log-ins, etc), so for long passwords, generally the first couple words spark my mind to the rest of it. (although ones i generally don't use much, i let a password program handle).
But i guess every system has a flaw that may not be your own if the 'software' is flawed.
--- Please remind me if I haven't been civil to you: I'm channeling MDC. ---Gaaark 2.0 ---
(Score: 1) by toph on Wednesday April 19, @03:23PM
(Score: 3, Informative) by ShovelOperator1 on Wednesday April 19, @07:50PM
It is really hard to get to the real description of operations against encrypted machines, however, there are some interesting examples found over the web. Unfortunately - usually the deeper parts. For example, Russian intelligence sent an agent to infiltrate the laptop of one of Levant officials. The agent was caught and told on a video that the thing needed was to "insert the flash drive to the laptop while in an airport".
It can be quite possible that there are some flashing capabilities in the USB controller which, when activated by the properly formatted USB drive or USB device, install additional software in it which can sniff the bus, extract keyboard-related packets and then process them to the infected OS to be sent by network.
However it could be much easier:
- Classic EMA. Generally, the hardware must be kept on someone all time to prevent it. Putting the password, message that it is bad and then putting it again with the same result should be a big no-no for such hardware because it could be substituted too - it is done with credit card terminals all time.
- Extracting by power consumption changes - 1950s ciphering machine "Fialka" had a special adapter for using in foreign countries. This adapter guaranteed a constant power draw, to minimize possibility to analyze current consumption and decipher the text.
- Jumping the air gap with RF. Not much possible, but still possible. Intel is really difficult in cooperation when it comes to their firmware. Additionally, they confirmed that they hide malware in it - when they threatened the ?System76? or ?Purism? to prevent turning their ME off, it is a clear sign that they hide something in the ME ("only-bad-guys-have-something-to-hide" corporate speak).
- Smartphone connected to the PC. Not much more to explain, many apps have permissions to hack user's PCs right in their EULAs.