An average police department, however, has very limited funds. Unless the guy is much more interesting that we know, nobody would spend that much money on cracking his address book.
- He actually gave his password himself as part of a deal with the police which includes this as a cover up.
- The police got his password through another mean they don’t want to disclose and are using this as a cover up.
- They really want a list of his contacts and what they were discussing because they are scared than one of them could be tempted to do more than burn a few cars.
- France has a more computationally effective way to decrypt these drives which has yet to be released.
Bitlocker also saves encryption backup keys in the Microsoft cloud where they can probably subpoenad? Then they might have found the password saved on the windows PC somewhere.
If I wanted to get at an encrypted hard drive, I'd just tamper with the keyboard and record the password as it was being typed. Hardware keyloggers can be made very tiny with resources and determination.
The USB HID protocol isn't encrypted. You can literally just add a pass through that logs (or transmits) the data.
You'd have to check your USB connectors for a small extra dongle every time you boot up with just what is consumer-available[1]. There's also this type of stuff that can be wired into a keyboard[2], obviously harder to detect but a bit more involved to install as well.
With a national R&D budget you can without a doubt do much better than both of these.
You need to do random access to the memory buffer, and random access to virtual memory is slower than random access to actual ram, by enough to make it slow.
The algorithms are designed, at each step, to need a random memory location — the idea is you had some data, then use that data as the index into your memory.
This means the speed of the algorithm is measured in random memory accesses, and that speed is much slower for discs than RAM, even with SSDs.
Compared to Windows+Bitlocker, using full disk encryption on Ubuntu (the most user friendly distro) is bizarrely difficult. By default the boot partition is not encrypted (so evil maid attacks are easier) and the KDF iteration counts are way too low, as can be seen here.
When I setup FDE with LUKS on my Ubuntu laptop I had to go the manual route since I noticed that the default iteration counts don't make any sense, and it was so incredibly difficult to change them, pages upon pages of instructions.
Anyone has any insight why the state of FDE is so bad on Linux? Nobody uses it?
I'm using it on Linux (Ubuntu and Arch Linux) and it wasn't so difficult. The default kdf settings are also sensible in Ubuntu 22.04. the biggest problem afaik is that the kdf isn't changed when there is a new default. E.g. when you installed your system in 2018 and upgraded all the way you still have the defaults from 2018.
Even if you encrypt boot partition someone could modify grub to grab password for boot partition used there.
Then with that password they can evil maid again and change your boot partition. (unless you have same password on root/boot or password is embedded in boot partition in which case win for attacker)
You could detect evil maid if you add a script that does a hash over grub used to load with a salt from boot sector, show on screen for user to decide against memorised hash...
Prevent perhaps secure boot with custom keys?, but then that's one more layer. And you could probably use secure boot to avoid boot partition encryption entirely.
You can use an unencrypted /boot and have UEFI boot a unified kernel image with the kernel command line built in. And have secure boot verify the signature of that image.
A TPM could possibly be helpful: you can't be sure that the PC you're booting up is actually yours and not a clone or has somehow had secure boot disabled that's booting a tampered kernel image. So if the TPM usually unlocks your drive (and a PIN, for added security) and it suddenly asks for your password, then something could be going on.
Not exactly sure how the desktop Linux boot process is structured, but on windows with bitlocker the boot partition isn't encrypted either. UEFI has to be able to load a boot manager somehow, and unless you're going to splice in a DXE driver to your mobo's fw, which has the risk of bricking, to decrypt a partition, then you're always going to need a cleartext partition somewhere.
On windows the default way it's set up when you have a TPM though is that it locks the decryption keys against a hash of all of the code that has run during the boot process.
TL;DR: secure boot is hard, TPM security is a challenge.
FDE works fine with encrypted boot, it's just not the default for Ubuntu. I just ticked the "encrypt my install" box as far as I know, I only found out that my /boot wasn't encrypted after the fact.
For evil maid attacks, encrypting /boot or not shouldn't really matter unless there's a known exploit for your bootloader. IMO it doesn't matter much because before you can decrypt the main drive, you'll have to deal with either a rewriteable boot sector, a rewriteable EFI:/boot/grub, or a rewriteable /boot. Each step should verify the hashes of the next loader and of any of the loaded modules, so an attacker would need to inject themselves into your boot process before the verification chain can start. You need to keep secure boot on, though.
Setting this up right involves enrolling keys into your UEFI (every time the bootloader updates), securing your UEFI with a good password, and assuring nobody can reflash your motherboard firmware somehow. All of that isn't necessary if you trust that Microsoft's keys don't leak and if you use the pre-signed shims, but that approach tends to break kernel modules (i.e. when you use Nvidia's driver).
Microsoft can get around this problem because their root keys are preloaded into almost every secure boot capable device you can find. They can pre-sign a bootloader and distribute it to hundreds of millions of computers, whereas every Linux distro has to jump through hoops and use the Microsoft-signed loader as an inbetween stage or have the user set up their own keys and signature system.
Then there's the challenge of TPMs. Windows uses the TPM to verify nothing has changed or demand a recovery key, and can use TPM+PIN to unlock a Bitlocker partition. On Linux, there is a wide variety of tools, but as far as I can tell, you can only choose between "unlock the disk from the TPM" or "unlock the disk with your passphrase". I suppose it's possible to set up a multi stage boot process in which initramfs is loaded from a TPM-based key and the main system is decrypted using a password, but I'm not aware of any easy to use installers for that purpose. I find proper GUI support for TPM configuration sorely lacking compared to other operating systems.
The iteration count LUKS defaults to depends on your CPU's performance. By default, LUKS takes 1000ms (or 2000ms in modern versions) of hashing to determine the amount of iterations. I can definitely see why, because at some point I put my iterations up to 10 seconds and the preboot environment, lacking the necessary acceleration instructions, took forever to unlock the disk. Anyone trying out encryption on their new install would probably wipe and retry without encryption with those parameters, which is obviously worse.
Getting secure boot set up right is the biggest challenge in my experience. The tools are all there, but there's no real GUI for configuring any of this and with how many Linux enthusiasts will decree that secure boot is Microsoft conspiracy and TPMs are instruments of the devil, I'm not sure that'll change any time soon.
> Microsoft can get around this problem because their root keys are preloaded into almost every secure boot capable device you can find. They can pre-sign a bootloader and distribute it to hundreds of millions of computers, whereas every Linux distro has to jump through hoops and use the Microsoft-signed loader as an inbetween stage or have the user set up their own keys and signature system.
But then, they can also (technically) sign a bogus bootloader if asked nice-enough, like by a state agency.
> On Linux, there is a wide variety of tools, but as far as I can tell, you can only choose between "unlock the disk from the TPM" or "unlock the disk with your passphrase".
You can also have TPM + PIN since a few versions of systemd ago. I have set this up on my work laptop and seems to work well enough.
> But then, they can also (technically) sign a bogus bootloader if asked nice-enough, like by a state agency.
Definitely! However, the chance of them doing that is relatively small and the usability problem is a lot bigger than the risk of falling victim of an NSA red letter order.
> You can also have TPM + PIN since a few versions of systemd ago. I have set this up on my work laptop and seems to work well enough.
That's great! Do you happen to know a guide on how to set that up? The guides I can find use TPM to auto-unlock OR provide a PIN/password.
It really annoys me how everyone takes that statement that a 20 character password has been cracked at face value. If it was randomly generated, it is physically impossible to crack even if it was hashed with MD5. It's also unlikely that somebody memorized 20 random characters. It is much more likely that the passphrase was weak because it's the title of a Wikipedia article or contained in some public word list.
> As far as the investigation is concerned, in recent months new elements have been added to the file. The most significant is that the police managed to gain access to my computers, even though they were encrypted. The one at work, on which Windows is installed, is encrypted with BitLocker. _A previous report in the file says that they had already tried to access it while I was in police custody but had not succeeded._ But in September the Brigade d'appui en téléphonie, cyber-investigation et analyse criminelle (BATCIAC) sent a copy of the hard disk to the SDAT. In the PV, they only explain that they booted the computer with a bootable USB key and then used the software AccesData FTK imager 3.3.05 to copy the hard disk. But they don't talk about the decryption itself.
> My personal computer, which runs Ubuntu 18, is encrypted with Luks (the password is more than twenty characters: letters, numbers, punctuation marks...). I couldn't find any indication in the file about how they decrypted it, but there too they made a copy of the hard disk. There are even files that had been deleted and emails that had been downloaded with Thunderbird (and then deleted). They didn't find anything that could be related to the fires I'm charged with. But I think the very fact that they were able to access hard drives encrypted with supposedly unbreakable software should be made as widely known as possible.
This clearly hints at an evil maid attack, which we always knew were a real risk when it comes to full disk encryption.
Thanks! Reading the article, I was already wondering myself: Do we already know any of this for fact, or is this just more wild mass guessing?
The article doesn't seem to cite any new sources other than people speculating on twitter/mastodon. Following down the social media rabbit hole, I end up back at the article that sparked the debate 5 days ago. Some RFCs and product data sheets are cited to support the back-on-the-napkin calculations (also cited from social media), but do we have any credible source yet to confirm that's what really happened here?
> One of the consequences of the second law of thermodynamics is that a certain amount of energy is necessary to represent information. To record a single bit by changing the state of a system requires an amount of energy no less than kT, where T is the absolute temperature of the system and k is the Boltzman constant. (Stick with me; the physics lesson is almost over.)
>Given that k = 1.38×10-16 erg/°Kelvin, and that the ambient temperature of the universe is 3.2°Kelvin, an ideal computer running at 3.2°K would consume 4.4×10-16 ergs every time it set or cleared a bit. To run a computer any colder than the cosmic background radiation would require extra energy to run a heat pump.
>Now, the annual energy output of our sun is about 1.21×1041 ergs. This is enough to power about 2.7×1056 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2192. Of course, it wouldn’t have the energy left over to perform any useful calculations with this counter.
>But that’s just one star, and a measly one at that. A typical supernova releases something like 1051 ergs. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states.
>These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.
I’m not sure how we go from 20 character string to 256 bits? Guessing the 20 character string is a lot more likely than cycling through every state of a 256 bit key.
At some level it's extremely likely that this is all that ever needs to be done, even if the password needed to be cracked is 300 characters long and completely random.
The likely case is that this password is in a password vault, which is either 1) online managed by a company (in which it's easy to see that it's inevitable to be leaked or cracked, given the news we've seen from these companies) or 2) it's on a local device and still has a simple password to get access to all passwords. It's extremely unlikely that someone has a completely random password that is >40 characters long for the password manager.
Why would they do an evil maid attack on the Ubuntu laptop, but not at the same time on the Windows one?
And is there any information that they accessed the Ubuntu laptop before he was arrested (to do the evil maid attack)? I see no mention of that.
I think it's much more likely that it was a weak password, maybe even partially shared with other passwords. Maybe police obtained user passwords from other low value targets (online shops, ...), looked at them and noticed a pattern.
> There are even files that had been deleted and emails that had been downloaded with Thunderbird (and then deleted).
This doesn't mean much, unless user didn't know that when you delete a file it's content is not actually scrubbed from storage.
I agree with taking this with a grain of salt, but i'm not sure how "this clearly hints at an evil maid attack". At this point anything is pure speculation: evil maid or other pre-seizure compromise, some amount of password guessing, exploit in some of the software, secret extraction from hardware, ...
He says his BitLocker drive was on a work computer. If it was managed through Active Directory then those key may have been recoverable through his employer.
There used to be a bug where bitlocker would rely on the firmware's encryption functionality if it was there, and there were cases of firmware with a literal "if checkpasswd () then"... overwrite that check to true and you're in.
Soif it concerned a disk with that vulnerability, maybe they did it like that.
> It's also unlikely that somebody memorized 20 random characters.
I routinely memorized 15 character random passwords until I switched to bitwarden, 20 doesn't seem out of bounds. Now, with bitwarden, I have no idea what any of my passwords are.
I did this too, now i generate a random pwd long as hell and i do a pwd recovery when i have to log-in so i don’t have to store them anywhere.
My master pwd is my email pwd based on a mail server i operate.
Yes paranoid is my second name.
That’s the idea yeah - you have one long high entropy password that you use to unlock all your others. Then you only need to remember one thing.
In my case, this isn’t my literal password, but it’s very similar to: “These420HugeWhiteBadgers1984” Which is secure enough, easy to enter, and easy to remember.
This is what I don't understand about articles like this. Say we're using a cryptographic hash to generate the password from even a commonplace phrase. Typically you will have thousands of random bits in the hash and you can grab a uint64 (or even a uint128 if you want) from anywhere in that (theoretically uniformly distributed) set of bits. Is that not a random point in a 2^64 (2^128) space?
No, because in that entire space, only eg. 62^20 would be used, and that's a much smaller space. There are various techniques to focus on that subset of the space.
Interesting that this was generated on such an old version of Ubuntu. There were known implementation weaknesses in LUKS that would have surely cut the cracking time down to a manageable duration.
What I find weird is that not many talk about one of the parameter to PBKDF2, c, the number of iterations desired. Someone here mentioned it a few days ago: just make decryption fast enough to be acceptable for you but still a big multiplier compared to the default. What do people care, when unlocking their SSD, if it takes 3ms or 300ms to unlock the SSD at boot?
I mean: attacker shall have a bazillion RAM and a trizillion GPUs... Fine. I augment the number of iterations by 1024, there, it's brute-force attacking cost just rose by 1024.
(I'm not sure that person was attacked by bruteforce but I'm surprised it's always left out... And now I've got friends sending me that picture with "time needed to brute-force a password if it has x, y or z characters" and I don't know what to answer except that "it's more complicated than that picture which circulates everywhere)
The problem is PBKDF2 isn't as memory intensive, it's really easy to parallelize on a modern GPU thus making it a much worse PBKDF than Argon2id. Increasing iteration count is just a bandaid over this problem, you also need to have control over memory usage.
Sure argon2 is better, but high iteration count pbkdf2 is still a lot of work to crack, and afaik the work still scales linearly with iteration count.
Lets do bit of reality check here. I checked my 14 year old laptop luks setup and it has iteration count set to 462093 and it unlocks near instantly. Looking at hashcat benchmark results for PBKDF2-HMAC-SHA1[1] I'd estimate that for that iteration count it'd do about 47 kH/s. Running a full year with 100000 gpus of that perf means about 2^47 hashes bruteforced (=log2(47e3×100e3×86400×365)).
Considering that I'm using maybe 70ish bit secret there, I'm not exactly concerned. I still should upgrade to have better margin, but there is no reason to panic; I'd consider it still practically uncrackable with current level of tech.
I think it's worthwhile to be concerned about hashing ASICs used in crypto mining. They're stupidly cheap and outperform GPUs for hashing. They don't have much in the way of memory so they're not useful in memory-hard problems.
No, I agree with you on that matter, there is no reason to panic, I was just trying to explain why Argon2id should receive preference over PBKDF2. Something else I forgot and a sibling comment touched upon is that hashing algorithms that are not memory-intensive can often be run on ASICS and that's when things can get a bit uglier. Overall, this kind of thing really just depends on your threat model and the data you're trying to protect, let's not forget https://xkcd.com/538/ lol
The linked ElcomSoft article claims that LUKS does does that sort of thing by default:
>LUKS varies the number of hash iterations used to protect the master encryption key. When creating an encrypted disk with a given combination of encryption settings, LUKS benchmarks the user’s system. The data is used to select the number of hash iterations protecting the master encryption key.
Yes, `cryptsetup luksFormat` selects the LUKS1 key slot pbkdf iteration count parameter at runtime by benchmarking against a target `--iter-time` [1] [2], which is either 1s or 2s depending on version [3].
For a LUKS1 image created with Ubuntu 18.04 on a i5-8265U (Q3'18) CPU, that seems to result in an iteration count on the order of 1.8M. Assuming the RTX 4090 hashcat benchmarks [4] scale linearly on the iteration count, that's about 10kH/s for PBKDF2-HMAC-SHA1 or 5kH/s for PBKDF2-HMAC-SHA256.
In terms of brute-force vs password entropy, that would give you roughly 45 bits of entropy for 1k gpu-months, or ~250k gpu-years to net 56 bits of entropy. Those would be on the order of [a-z0-9]{8} (41 bits), [a-zA-Z0-9]{8} (47 bits) or [a-z]{12} (56 bits).
Worryingly close enough to make replacing the KDF a relevant concern, but still enough to make this story about brute-forcing a random 20-character password somewhat implausible, unless the password was far weaker than implied.
This isn't a PBKDF2 problem. It's a password problem with roots in practicality and psychology. His password has absolutely not been 20 random characters, but instead something easy to remember and type in, quite likely just 3 or 4 common words.
Pbkdf2 is designed to protect the users from their own bad choices more than anything else.
In fact if you think about it, pbkdf2 with a high number of iterations could become quite costly at scale. How much are you willing to pay to protect a given user from themselves?
If someone uses a proper password, one iteration is all you need.
Bitlocker can save backup keys in the cloud where they can probably be subpoenad by the police. If the victim used a password manager without encryption (e.g. browser) and used or saved the same password somewhere else, they might have gotten it this way.
I might be wrong, but something tells me that people who use LUKS to encrypt a hard drive would not use the password in question for an online service.
Remember all the mistakes DPR did and commenters were like "a criminal mastermind creating the Amazon of drugs couldn't have possibly asked on StackOverflow using his real identity how to build that".
Bitlocker saves the recovery key to the cloud, not the unlock PIN. Both can be used to recover access to the data, but the recovery key is not directly related to the password chosen.
Furthermore, the article talks about LUKS, which is decidedly not related to Bitlocker.
I doubt they would've spent the ridiculous amount of money you need to crack LUKS though. Most likely, the password was a phrase that could be brute forced through a dictionary attack, or it was reused somewhere else.
That's not to say we shouldn't move to Argon2i as GPU performance increases over time. Argon is proven to be stronger and there's very little reason not to upgrade if you can get your bootloader to unlock the modern LUKS standard (i.e. not GRUB).
I'm sorry if my comment was unclear. The person whose laptops were confiscated by the police stated that his bitlocker encrypted windows pc was also cracked by the police.
My point was: They could have gotten the bitlocker recovery key, then found his password somewhere on the windows pc and used that to "crack" the LUKS encrypted partition.
I think you are mistaken, the original article in french states that the BitLocker computer was not cracked by the local police, but was accessed later by some cyber-department of the police: https://nantes.indymedia.org/posts/87395/une-lettre-divan-en....
You are right that you can choose to backup recovery keys to the cloud, I just guessed that this would be one possible scenario.
In a way it'd actually be great if police was frequently cracking encrypted communications of old algorithms. It'd both increase the pressure on better standards as well as remove the need for shitty laws banning encryption outright.
An interesting bit from the linked ElcomSoft article:
>Brute force attacks became not just faster, but much smarter as well. The user’s existing passwords are an excellent starting point. These passwords can be pulled from the user’s Google Account, macOS, iOS or iCloud keychain, Microsoft Account, or simply extracted from the user’s computer. The user’s existing passwords give a hint at what character groups are likely used:
So if the victim used portions of that "longer than 20 characters" password in their other passwords, the amount of work required to crack the LUKS password would be much reduced.
This is why you let a computer choose. By doing that you end up forcing the attacker to brute force, which we all know is mathematically unfeasible given enough entropy.
"An activist imprisoned in France" makes this sound like some sort of locked up protestor, rather than someone that set fire to a load of vehicles and a warehouse.
It should really read "An arsonist imprisoned in France".
It's true, but if a murderer that donated to charity was imprisoned I would probably go with "a murderer imprisoned in France" rather than "a philanthropist imprisoned in France".
If you look into Koba's life before he came Stalin; even if you try to give what he did neutral descriptions, the words "mafia racket" still comes to mind.
The use of a memory hard KDF like Argon2 is hardly a panacea for something like disk encryption. If your passphrase is compute time hard already, the advantage of using something memory hard is unlikely to be more than a factor of a thousand or so. Adding even a single diceware generated word to a passphrase increases the difficulty by a factor of 7776. So passphrase length is by far the dominant factor.
There is a faction out there that claims that Argon2 is not as good as cache hard functions for the case where the user is only going to be willing to wait second or less. That's a reasonable assumption so it would probably be a good idea to evaluate more than just Argon2 for any particular application. Yes I know that Argon2 won a contest, but such contests are followed by a much longer evaluation period.
While I haven't worked on LUKS, if you put aside using several millions of dollars in raw compute, the options are in order of likelihood:
- recovering the key from a deleted file, ram, or other caches.
- obtained key or bytes thereof by prior surveillance. (so many ways)
- a forensics company could be sitting on a LUKS zero-day the way certain companies sit on Signal and iPhone vulns and use them on behalf of state actors.
- exploited a deprecated version themselves with an implementation error.
- prisoner had a short key because he used it so often
- brute force using generated wordlists from surveillance and data transcripts.
- trained a GPT model on all the books, music and online forum posts the prisoner had ever bought and used and produced a weighted wordlist. (I just made that one up.)
- Happen to have "millions of dollars in gpu time" because they already had racks of seized mining rigs from other investigations so the main cost was electricity.
Being an anarchist or secret police in France just seems like participation in their national traditions of riot sports, intrigue, and feats of mysterious intellectual prowess. There are so many unanswered questions in the story, I will wait for the Wes Anderson adaptation before thinking about it again.
Also, I would expect the government can crack passwords more cheaply than hiring normal commercial cloud compute.
Everything from negotiating good prices, to having their own or reserved cloud so the cost is having the ability to do it more than actually doing each crack, to asking an ally for help.
Would be kinda shocking if they pay the sticker price for this stuff.
You’re right. They probably pay a premium on the sticker price, after you include all of the necessary professional services and us gov only personnel with security clearances.
Bruteforce of such random password is just not plausible and talks about KDF "weakness" is just a distraction. I think most likely it was evil maid attack.
Here are projects which try to mitigate some of evil maid attack risks:
> Earlier this week a letter from an activist imprisoned in France was posted to the Internet.
And this letter's authenticity was verified how?
Even if authentic, it could be the result of coercion, to create a bluff and spook some other activists.
Or it could be that the cops fooled the activist into believing that they cracked his hard drive, so that he then wrote the letter.
Do not believe everything "posted to the Internet".
The letter says (DeepL translation) that "There are even files that had been deleted and emails that had been downloaded with Thunderbird (and then deleted)."
Files and e-mails come from somewhere. If I know that you downloaded certain files or e-mails from a mail server to your encrypted hard drive, I could claim that I decrypted them from your drive and spook you.
Might you be confusing skepticism with paranoia? They are almost opposite: the paranoiac is too willing to believe; a skeptic can be too unwilling.
Police perpetrating bluffs on people they have in custody is standard operating procedure.
I wouldn't weave the "scare people from using Linux encryption" narrative into it, though; I don't think that would be their motivation. (Though it could be a counterproductive unintended effect. The last thing authorities want it spooking people into finding better encryption.)
Anyway, I suspect that in situations in which cops really crack someone's hard drive at great expense, it mostly behooves them to take advantage of whatever they learn, while keeping secret how they got it.
If you have someone in custody who thinks their hard drive is safe, while you have secretly cracked it, that gives you an information advantage you can use at a strategic time.
Recognizing the ability of these entities to hire great cryptographers, what’s the possibility they found a shortcut or vulnerability in the algorithm (or set thereof) itself?
For whatever it's worth --- probably not much if you don't do any cryptography engineering --- the definition provided here is of a password KDF. There are other important kinds of KDF, and they don't necessarily have the goal of stretching an untenably low-entropy secret into a facsimile of an actual key. HKDF, for instance, is often the way you extract keys from a Diffie-Hellman exchange.
97 comments
[ 3.2 ms ] story [ 161 ms ] threadDoesn't sound like something you would spend on a small crime?
- He actually gave his password himself as part of a deal with the police which includes this as a cover up.
- The police got his password through another mean they don’t want to disclose and are using this as a cover up.
- They really want a list of his contacts and what they were discussing because they are scared than one of them could be tempted to do more than burn a few cars.
- France has a more computationally effective way to decrypt these drives which has yet to be released.
You'd have to check your USB connectors for a small extra dongle every time you boot up with just what is consumer-available[1]. There's also this type of stuff that can be wired into a keyboard[2], obviously harder to detect but a bit more involved to install as well.
With a national R&D budget you can without a doubt do much better than both of these.
[1] https://www.keelog.com/airdrive-keylogger/
[2] https://www.keydemon.com/en/keydemon/28-1576-hardware-keylog...
https://kolektiva.social/@cedar/110214532879538171
> This enemy site talks about using up to 10,000 computers with GPU acceleration to attack a LUKS password:
> https://blog.elcomsoft.com/2020/08/breaking-luks-encryption/
There, it says:
> Up to 10,000 computers and on-demand cloud instances can be used to attack a single password with Elcomsoft Distributed Password Recovery.
So this is the theoretical maximum of some service.
We should not be under the impression that the hard drive of the activist in question has been attacked with 10,000 GPUs.
https://news.ycombinator.com/item?id=35611425 "PSA: Upgrade your LUKS key derivation function" (>180 comments)
Why can't programs like Hashcat treat virtual memory (which is just disk space) as "on board memory", and then get 1000 attempts out of each TB?
I would think the calculations themselves are relatively minor, if you are using that amount of RAM.
This means the speed of the algorithm is measured in random memory accesses, and that speed is much slower for discs than RAM, even with SSDs.
When I setup FDE with LUKS on my Ubuntu laptop I had to go the manual route since I noticed that the default iteration counts don't make any sense, and it was so incredibly difficult to change them, pages upon pages of instructions.
Anyone has any insight why the state of FDE is so bad on Linux? Nobody uses it?
Then with that password they can evil maid again and change your boot partition. (unless you have same password on root/boot or password is embedded in boot partition in which case win for attacker)
You could detect evil maid if you add a script that does a hash over grub used to load with a salt from boot sector, show on screen for user to decide against memorised hash...
Prevent perhaps secure boot with custom keys?, but then that's one more layer. And you could probably use secure boot to avoid boot partition encryption entirely.
A TPM could possibly be helpful: you can't be sure that the PC you're booting up is actually yours and not a clone or has somehow had secure boot disabled that's booting a tampered kernel image. So if the TPM usually unlocks your drive (and a PIN, for added security) and it suddenly asks for your password, then something could be going on.
On windows the default way it's set up when you have a TPM though is that it locks the decryption keys against a hash of all of the code that has run during the boot process.
FDE works fine with encrypted boot, it's just not the default for Ubuntu. I just ticked the "encrypt my install" box as far as I know, I only found out that my /boot wasn't encrypted after the fact.
For evil maid attacks, encrypting /boot or not shouldn't really matter unless there's a known exploit for your bootloader. IMO it doesn't matter much because before you can decrypt the main drive, you'll have to deal with either a rewriteable boot sector, a rewriteable EFI:/boot/grub, or a rewriteable /boot. Each step should verify the hashes of the next loader and of any of the loaded modules, so an attacker would need to inject themselves into your boot process before the verification chain can start. You need to keep secure boot on, though.
Setting this up right involves enrolling keys into your UEFI (every time the bootloader updates), securing your UEFI with a good password, and assuring nobody can reflash your motherboard firmware somehow. All of that isn't necessary if you trust that Microsoft's keys don't leak and if you use the pre-signed shims, but that approach tends to break kernel modules (i.e. when you use Nvidia's driver).
Microsoft can get around this problem because their root keys are preloaded into almost every secure boot capable device you can find. They can pre-sign a bootloader and distribute it to hundreds of millions of computers, whereas every Linux distro has to jump through hoops and use the Microsoft-signed loader as an inbetween stage or have the user set up their own keys and signature system.
Then there's the challenge of TPMs. Windows uses the TPM to verify nothing has changed or demand a recovery key, and can use TPM+PIN to unlock a Bitlocker partition. On Linux, there is a wide variety of tools, but as far as I can tell, you can only choose between "unlock the disk from the TPM" or "unlock the disk with your passphrase". I suppose it's possible to set up a multi stage boot process in which initramfs is loaded from a TPM-based key and the main system is decrypted using a password, but I'm not aware of any easy to use installers for that purpose. I find proper GUI support for TPM configuration sorely lacking compared to other operating systems.
The iteration count LUKS defaults to depends on your CPU's performance. By default, LUKS takes 1000ms (or 2000ms in modern versions) of hashing to determine the amount of iterations. I can definitely see why, because at some point I put my iterations up to 10 seconds and the preboot environment, lacking the necessary acceleration instructions, took forever to unlock the disk. Anyone trying out encryption on their new install would probably wipe and retry without encryption with those parameters, which is obviously worse.
Getting secure boot set up right is the biggest challenge in my experience. The tools are all there, but there's no real GUI for configuring any of this and with how many Linux enthusiasts will decree that secure boot is Microsoft conspiracy and TPMs are instruments of the devil, I'm not sure that'll change any time soon.
But then, they can also (technically) sign a bogus bootloader if asked nice-enough, like by a state agency.
> On Linux, there is a wide variety of tools, but as far as I can tell, you can only choose between "unlock the disk from the TPM" or "unlock the disk with your passphrase".
You can also have TPM + PIN since a few versions of systemd ago. I have set this up on my work laptop and seems to work well enough.
Definitely! However, the chance of them doing that is relatively small and the usability problem is a lot bigger than the risk of falling victim of an NSA red letter order.
> You can also have TPM + PIN since a few versions of systemd ago. I have set this up on my work laptop and seems to work well enough.
That's great! Do you happen to know a guide on how to set that up? The guides I can find use TPM to auto-unlock OR provide a PIN/password.
Here's the Arch Wiki, but since this depends on systemd, it should be universal. The man page of systemd-cryptenroll is actually quite helpful.
https://wiki.archlinux.org/title/Trusted_Platform_Module#sys...
Also, by going with the original article (https://nantes.indymedia.org/posts/87395/une-lettre-divan-en...), which I translated using DeepL, this is what we know:
> As far as the investigation is concerned, in recent months new elements have been added to the file. The most significant is that the police managed to gain access to my computers, even though they were encrypted. The one at work, on which Windows is installed, is encrypted with BitLocker. _A previous report in the file says that they had already tried to access it while I was in police custody but had not succeeded._ But in September the Brigade d'appui en téléphonie, cyber-investigation et analyse criminelle (BATCIAC) sent a copy of the hard disk to the SDAT. In the PV, they only explain that they booted the computer with a bootable USB key and then used the software AccesData FTK imager 3.3.05 to copy the hard disk. But they don't talk about the decryption itself.
> My personal computer, which runs Ubuntu 18, is encrypted with Luks (the password is more than twenty characters: letters, numbers, punctuation marks...). I couldn't find any indication in the file about how they decrypted it, but there too they made a copy of the hard disk. There are even files that had been deleted and emails that had been downloaded with Thunderbird (and then deleted). They didn't find anything that could be related to the fires I'm charged with. But I think the very fact that they were able to access hard drives encrypted with supposedly unbreakable software should be made as widely known as possible.
This clearly hints at an evil maid attack, which we always knew were a real risk when it comes to full disk encryption.
The article doesn't seem to cite any new sources other than people speculating on twitter/mastodon. Following down the social media rabbit hole, I end up back at the article that sparked the debate 5 days ago. Some RFCs and product data sheets are cited to support the back-on-the-napkin calculations (also cited from social media), but do we have any credible source yet to confirm that's what really happened here?
All we know is the authorities gained access to his drive's key. We probably won't find out how they did it until his trial starts.
https://www.schneier.com/blog/archives/2009/09/the_doghouse_... (unfortunately the exponents are not displayed correctly here)
> One of the consequences of the second law of thermodynamics is that a certain amount of energy is necessary to represent information. To record a single bit by changing the state of a system requires an amount of energy no less than kT, where T is the absolute temperature of the system and k is the Boltzman constant. (Stick with me; the physics lesson is almost over.)
>Given that k = 1.38×10-16 erg/°Kelvin, and that the ambient temperature of the universe is 3.2°Kelvin, an ideal computer running at 3.2°K would consume 4.4×10-16 ergs every time it set or cleared a bit. To run a computer any colder than the cosmic background radiation would require extra energy to run a heat pump.
>Now, the annual energy output of our sun is about 1.21×1041 ergs. This is enough to power about 2.7×1056 single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2192. Of course, it wouldn’t have the energy left over to perform any useful calculations with this counter.
>But that’s just one star, and a measly one at that. A typical supernova releases something like 1051 ergs. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states.
>These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be infeasible until computers are built from something other than matter and occupy something other than space.
And is there any information that they accessed the Ubuntu laptop before he was arrested (to do the evil maid attack)? I see no mention of that.
I think it's much more likely that it was a weak password, maybe even partially shared with other passwords. Maybe police obtained user passwords from other low value targets (online shops, ...), looked at them and noticed a pattern.
> There are even files that had been deleted and emails that had been downloaded with Thunderbird (and then deleted).
This doesn't mean much, unless user didn't know that when you delete a file it's content is not actually scrubbed from storage.
https://learn.microsoft.com/en-us/windows/security/informati...
Soif it concerned a disk with that vulnerability, maybe they did it like that.
(See https://www.ieee-security.org/TC/SP2019/papers/310.pdf)
I routinely memorized 15 character random passwords until I switched to bitwarden, 20 doesn't seem out of bounds. Now, with bitwarden, I have no idea what any of my passwords are.
In my case, this isn’t my literal password, but it’s very similar to: “These420HugeWhiteBadgers1984” Which is secure enough, easy to enter, and easy to remember.
This is what I don't understand about articles like this. Say we're using a cryptographic hash to generate the password from even a commonplace phrase. Typically you will have thousands of random bits in the hash and you can grab a uint64 (or even a uint128 if you want) from anywhere in that (theoretically uniformly distributed) set of bits. Is that not a random point in a 2^64 (2^128) space?
Was it random, though?
I mean: attacker shall have a bazillion RAM and a trizillion GPUs... Fine. I augment the number of iterations by 1024, there, it's brute-force attacking cost just rose by 1024.
(I'm not sure that person was attacked by bruteforce but I'm surprised it's always left out... And now I've got friends sending me that picture with "time needed to brute-force a password if it has x, y or z characters" and I don't know what to answer except that "it's more complicated than that picture which circulates everywhere)
Lets do bit of reality check here. I checked my 14 year old laptop luks setup and it has iteration count set to 462093 and it unlocks near instantly. Looking at hashcat benchmark results for PBKDF2-HMAC-SHA1[1] I'd estimate that for that iteration count it'd do about 47 kH/s. Running a full year with 100000 gpus of that perf means about 2^47 hashes bruteforced (=log2(47e3×100e3×86400×365)).
Considering that I'm using maybe 70ish bit secret there, I'm not exactly concerned. I still should upgrade to have better margin, but there is no reason to panic; I'd consider it still practically uncrackable with current level of tech.
[1] https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb4...
>LUKS varies the number of hash iterations used to protect the master encryption key. When creating an encrypted disk with a given combination of encryption settings, LUKS benchmarks the user’s system. The data is used to select the number of hash iterations protecting the master encryption key.
For a LUKS1 image created with Ubuntu 18.04 on a i5-8265U (Q3'18) CPU, that seems to result in an iteration count on the order of 1.8M. Assuming the RTX 4090 hashcat benchmarks [4] scale linearly on the iteration count, that's about 10kH/s for PBKDF2-HMAC-SHA1 or 5kH/s for PBKDF2-HMAC-SHA256.
In terms of brute-force vs password entropy, that would give you roughly 45 bits of entropy for 1k gpu-months, or ~250k gpu-years to net 56 bits of entropy. Those would be on the order of [a-z0-9]{8} (41 bits), [a-zA-Z0-9]{8} (47 bits) or [a-z]{12} (56 bits).
Worryingly close enough to make replacing the KDF a relevant concern, but still enough to make this story about brute-forcing a random 20-character password somewhat implausible, unless the password was far weaker than implied.
[1] https://man7.org/linux/man-pages/man8/cryptsetup-luksformat.... [2] https://wiki.archlinux.org/title/dm-crypt/Device_encryption#... [3] https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v... [4] https://gist.github.com/Chick3nman/32e662a5bb63bc4f51b847bb4...
In fact if you think about it, pbkdf2 with a high number of iterations could become quite costly at scale. How much are you willing to pay to protect a given user from themselves?
If someone uses a proper password, one iteration is all you need.
Bitlocker can save backup keys in the cloud where they can probably be subpoenad by the police. If the victim used a password manager without encryption (e.g. browser) and used or saved the same password somewhere else, they might have gotten it this way.
Remember all the mistakes DPR did and commenters were like "a criminal mastermind creating the Amazon of drugs couldn't have possibly asked on StackOverflow using his real identity how to build that".
Furthermore, the article talks about LUKS, which is decidedly not related to Bitlocker.
I doubt they would've spent the ridiculous amount of money you need to crack LUKS though. Most likely, the password was a phrase that could be brute forced through a dictionary attack, or it was reused somewhere else.
That's not to say we shouldn't move to Argon2i as GPU performance increases over time. Argon is proven to be stronger and there's very little reason not to upgrade if you can get your bootloader to unlock the modern LUKS standard (i.e. not GRUB).
My point was: They could have gotten the bitlocker recovery key, then found his password somewhere on the windows pc and used that to "crack" the LUKS encrypted partition.
Besides, the user also had a Windows laptop encrypted with Bitlocker, and the police failed to crack that one (see top comment).
You are right that you can choose to backup recovery keys to the cloud, I just guessed that this would be one possible scenario.
>Brute force attacks became not just faster, but much smarter as well. The user’s existing passwords are an excellent starting point. These passwords can be pulled from the user’s Google Account, macOS, iOS or iCloud keychain, Microsoft Account, or simply extracted from the user’s computer. The user’s existing passwords give a hint at what character groups are likely used:
So if the victim used portions of that "longer than 20 characters" password in their other passwords, the amount of work required to crack the LUKS password would be much reduced.
It should really read "An arsonist imprisoned in France".
It definitely is.
I'm struggling to think of a good neutral term for this case.
this is not factual as arson is an accusation
There is a faction out there that claims that Argon2 is not as good as cache hard functions for the case where the user is only going to be willing to wait second or less. That's a reasonable assumption so it would probably be a good idea to evaluate more than just Argon2 for any particular application. Yes I know that Argon2 won a contest, but such contests are followed by a much longer evaluation period.
- recovering the key from a deleted file, ram, or other caches.
- obtained key or bytes thereof by prior surveillance. (so many ways)
- a forensics company could be sitting on a LUKS zero-day the way certain companies sit on Signal and iPhone vulns and use them on behalf of state actors.
- exploited a deprecated version themselves with an implementation error.
- prisoner had a short key because he used it so often
- brute force using generated wordlists from surveillance and data transcripts.
- trained a GPT model on all the books, music and online forum posts the prisoner had ever bought and used and produced a weighted wordlist. (I just made that one up.)
- Happen to have "millions of dollars in gpu time" because they already had racks of seized mining rigs from other investigations so the main cost was electricity.
Being an anarchist or secret police in France just seems like participation in their national traditions of riot sports, intrigue, and feats of mysterious intellectual prowess. There are so many unanswered questions in the story, I will wait for the Wes Anderson adaptation before thinking about it again.
Everything from negotiating good prices, to having their own or reserved cloud so the cost is having the ability to do it more than actually doing each crack, to asking an ally for help.
Would be kinda shocking if they pay the sticker price for this stuff.
C'mon guys.
Here are projects which try to mitigate some of evil maid attack risks:
https://github.com/noahbliss/mortar
https://safeboot.dev/
And this letter's authenticity was verified how?
Even if authentic, it could be the result of coercion, to create a bluff and spook some other activists.
Or it could be that the cops fooled the activist into believing that they cracked his hard drive, so that he then wrote the letter.
Do not believe everything "posted to the Internet".
The letter says (DeepL translation) that "There are even files that had been deleted and emails that had been downloaded with Thunderbird (and then deleted)."
Files and e-mails come from somewhere. If I know that you downloaded certain files or e-mails from a mail server to your encrypted hard drive, I could claim that I decrypted them from your drive and spook you.
Police perpetrating bluffs on people they have in custody is standard operating procedure.
I wouldn't weave the "scare people from using Linux encryption" narrative into it, though; I don't think that would be their motivation. (Though it could be a counterproductive unintended effect. The last thing authorities want it spooking people into finding better encryption.)
Anyway, I suspect that in situations in which cops really crack someone's hard drive at great expense, it mostly behooves them to take advantage of whatever they learn, while keeping secret how they got it.
If you have someone in custody who thinks their hard drive is safe, while you have secretly cracked it, that gives you an information advantage you can use at a strategic time.