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.
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)
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.
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.
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?
- 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.
C'mon guys.
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.
https://news.ycombinator.com/item?id=35611425 "PSA: Upgrade your LUKS key derivation function" (>180 comments)
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.
It should really read "An arsonist imprisoned in France".
I'm struggling to think of a good neutral term for this case.
It definitely is.
this is not factual as arson is an accusation
Here are projects which try to mitigate some of evil maid attack risks:
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.
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.
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.
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".
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)
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...
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.
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.
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.
>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.
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.
Doesn'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.
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.
