The anarchist, French cops and LUKS

Because everyone is speaking about Ivan's message (FR), let me talk about it, while still trying not to reveal sensitive stuff in the process.

To begin with, this does occur in a specific political context, involving law enforcement. However, keep in mind this post is not a political statement. I mostly speak from a technical point of view. And from a purely technical standpoint, I might do mistakes. Here, the police produced an interesting attack. But the same attack can occur when a foreign agency is working against a French administration. The terms "attacker", "target" and "victim" are generic and devoid of any notion of judgment. Also, my opinions on Ivan or even anarchism aren't relevant here. However, as any citizen, I cannot stay 100% neutral facing social and political issues.

The more I'm thinking about this incident, the more I'm thinking about that: every modern software (e.g. frameworks) has been made to support PBKDF2 as the most "modern and safe" KDF or password hash algorithm. But this was never made to be GPU/ASIC resilient. The Password Hashing Competition, or even hashcat benchmarks, showed us better algorithms, as Argon2. That's understandable: PBKDF2 is 15 years older than Argon2, and the offensive landscape changed a lot during these years. Thus, first, I'll take the opportunity of this incident to review the "password hashing" policies. Then I'll make some assumptions about the attack. Finally, I'll make a small conclusion, gathering all of what we've learned.

Of course, if you find an error or something to change, say it!

Context + "Think out of the box, please"

The incident occurred in a French law enforcement investigation. They cracked somebody's LUKS encryption.

In France, in a context of terrorism, law enforcement are able to use intelligence means, within a certain reach (until the equivalent of NATO CONFIDENTIAL, one of the lowest levels of classification). Given the nature of the teams which took part in the investigation, I can guess some of these means could have been implied. Thus, keep in mind that intelligence services (with NATO COSMIC TOP SECRET-equivalent means) and attackers with a bunch of money (these include countries which attack civilians and don't respect human rights) are able to do worst than what's described here.

First, let's make a recap of what we know by reading Ivan's publication:

  • a PC using Windows and being encrypted with BitLocker has been dumped by the SDAT (Anti-Terrorism Sub-Directorate) using AccessData FTK Imager 3.3.05. In the record, nothing is said about the encryption. This has been done after a failure of the BATCIAC (Support Brigade in Telephones, Cyber-investigation and Criminal Analysis);
  • a PC using Ubuntu 18 and being encrypted using LUKS has been accessed. Given the Ivan's said, the password was a composition of "more than 20 chars, letters, numbers, special chars". Nothing is written in the record about how they proceed to this;
  • The record, showing potentially incriminating data (making it mandatory to disclose said data), is dated on "the last month", which, I guess, means "last mount" since Ivan's last letters (he seems to write a lot of those). Thus, I assess that it has been written in one of the three first months of 2023.

To get a better understanding of the context of this investigation, using web search, we have to know that (source (DE)):

  • Ivan Alocco was arrested on the 11th of June 2022 around 03:03 (Paris timezone). Thus, the record of for adding files, and which lead to the notice from Ivan, would have been written, at least 6 months after that;
  • The investigations would start in February 2022 by the SDAT. "For months, the cops set up surveillance loops and listening devices, installed a camera in the entrance of my home, intercepted my mail […] and monitored my bank account", wrote Ivan.

Because I don't know the details of this investigation, I'll focus on the encryption of HDDs. But, keep in mind that it's just ONE of many means available to the attackers. Indeed, it's possible for them to access the HDD content via a plethora of attacks (arrest while the disk was unlocked, an evil made attack (https://github.com/nyxxxie/de-LUKS 👀), etc.). This last one is, I believe, the most probable. However , I have no idea about how the French police were "authorized" to do so (e.g. if it's a desktop computer, it would mean that they trespassed into the Ivan's home without him. This may be unauthorized, but I don't know precisely how the Ivan's computer was secured nor do I know about laws surrounding these cases enough).

To me, without more context data, any kind of attack which could lead to the decryption, including circumvent, is indeed possible. It's not necessarily a problem with the encryption at rest. It could, but not necessarily.

Recommendations on password hashing & KDF, the state of the art

This is a small review of the different standards I know by being French and by working in the European Union. This is a very-french centric point of view. Feel free to let me know about the standards in other countries.

NIST (+/- 2017)

According to, you should store your password by "hashing" them using PBKDF2 or BALLOON (without giving minimal parameters to use with the BALLOON KDF).

As a parameter of these KDF, they are recommending to use the following HASH functions:

  • Approved hash functions (or a HMAC of them): SHA-1 (?!?), SHA-224, SHA-256, SHA-384, SHA512, SHA-512/224 and SHA-512/256;
  • SHA-3;
  • CMAC;
  • KMAC;
  • cSHAKE;
  • ParallelHash.

The NIST recommendation for the PBKDF2 parameters are:

  • At least a 32b-length salt;
  • At least 10,000 iterations, with 10,000,000 ones in a powerful system where the user-perceived performance is not critical.

Thus, the pitfall of this recommendation is the vague cost parameter of PBKDF2 and the lack of recommendation of BALLOON. Moreover, one of these KDF (PBKDF2) is not GPU/ASIC resilient.

FIPS 140-3 (2019)

It supersedes FIPS PUB 140-2, recommends only the PBDKF2, and suggests the same parameters as the rest of the NIST. Except for the following points:

  • It recommends at least 1000 iterations, with 10,000,000 ones in a powerful system where the user-perceived performance is not critical;
  • It recommends at least a 128b-length salt.

The pitfall of this spec is the same as with general-purpose NIST recommendations (or worst, because of iterations values).

ANSSI (2021; France)

Speaking about French law enforcement, what are the recommendations of the French cybersecurity agency?

The ANSSI advocates for:

  • For Hash algorithms, the usage of SHA-256, SHA-384, SHA-512, SHA-512/256, SHA3 (with an output of 256, 384 or 512 bits);
  • For Key Derivation Functions, the usage of HKDF, NIST SP800-56C, ANSI-X9.63-KDF or PBKDF2;
  • For Password hash, the usage of PBKDF2 only, with, at least, a 128b-length salt and with an iterations value "as big as possible, while it's not affecting the legitimate usage".

The pitfall in this spec is that there is no minimal value for the iterations of PBKDF2.

French RGS (2014; France)

The RGS is a French set of guidelines to protect administrations and sensitive organizations. The last RGS about this topic has been published… in 2014!

For hash functions, it's recommended to use "a function on which partial attack is not known" and "where the best attack has a complexity of O(2^(h/2)) where h is the length of the fingerprint". The minimal length of the fingerprint which is allowed is 256b. Example: SHA-256.

No KDF is mentioned.

ECRYPT-CSA (2018; EU)

The ECRYPT-CSA is a European coordination group focussing on cryptography and digital watermarking.

As of 2018, the following recommendations are expected to cover a 10 to 50-years lifetime:

  • The hash functions: SHA-2 (256, 384, 512, 512/256), SHA-3 (256, 384, 512, SHAKE128, SHAKE256), Whirlpool, BLAKE & BLAKE2 (256, 384, 512);
  • For the KDF: NIST-800-108-KDF (all modes), X9.63-KDF, NIST-800-56-KDF-A/B, NIST-800-56-KDF-C, HKDF, IKE-v2-KDF, TLS-v1.2-KDF.

The group was unsure about the evolution of the protection provided by PBKDF2, bcrypt and scrypt.

They were also unsure about Argon2 and other "known" KDF. Read the section 6.1, it's very interesting.

BSI (2023; Germany)

The BSI is a part of the German Federal Ministry of the Interior. Amongst other stuff, they audit software and hardware for the German ministries, and issue recommendations on security.

For hash algorithm, they recommend: SHA-256, SHA-512/256, SHA-384, SHA-512, SHA3-256, SHA3-384, SHA3-512;

For the KDF, it uses the NIST recommendation.

NSA CNSA 2.0 (2022; US)

  • Hash: SHA-384 or SHA-512;
  • KDF is absent from this standard.

Sources:

Assumptions about the attack

At this point, it's important to underline that the attack could have been done via any technical mean. For the purpose of this paper, I'll focus on the encryption at rest part specifically.

Due to how the French police is organised, and based on my small knowledge of them, the section in charge of breaking encryption at rest could be the SDAT or the IRCGN (forensic science research department of the French National Gendarmerie, this includes digital forensic). My small knowledge about them is a bit outdated now. Thus, the following is just a series of tips and clues about how things would have worked years ago.

As far as I know, if the IRCGN had been involved, they would only break the encryption. The rest of the investigation(the proper research files' contents) would then be done by the initial investigators. But, for sure, there's many very smart and talented engineers in the IRCGN, with access to a lot of both financial and technical means. As a personal note, I have a lot of respect for these engineers and their technical skills.

Since I don't know about the old processes in place if the SDAT had been involved, I don't have any clues about it.

Based on elements given in the beginning of this article, both the "key recovery" process and the investigation would have been done during 6 months. So far I know, this seems a small duration. (Imagine the amount of time needed to fully investigate 1 TB!; that said, I don't know the size of the Ivan's HDD) It still cannot exclude other means than attacks on the encryption at rest.

For BitLocker, here is the way I would do, if I was to assume the attacker's role:

  1. I would ask Microsoft or the company for the recovery keys sent to the MS account or the Active Directory, if available. More info in the documentation about backing these keys up and finding them.
  2. If BitLocker was configured in a TPM only mode, there are many ways to intercept the master key (e.g. "Understanding BitLocker TPM Protection" by Elcomsoft, "Forensic method for decrypting TPM-protected BitLocker volumes using Intel DCI" by Bichara de Assumpção, Abdalla dos Reis, Marcondes, Monteiro da Silva Eleutério & Vieira).
  3. If BitLocker was configured with a PIN, and the computer was running during the arrest, I guess I would search to extract the RAM and find the master key.
  4. If BitLocker was configured with a PIN and the computer was powered off, I guess I would try to make a list of probable PINs. This would be based on the target's personal information, similar affairs, and on leaked passwords which could be linked to the target (taken from previous investigations and/or from data leaks).

For LUKS, here is my analysis. First, it was an Ubuntu 18 under the LUKS. As of 2023-04-26, I've installed an Ubuntu 18.04.06 (2021) without updating it and by encrypting the disk during the installation. The default LUKS configuration is the following:

  • LUKS version: 1;
  • KDF: PBKDF2, using SHA256 and a 32b salt. As explained in the documentation of LUKS1, the number of iterations is benchmarked during the key creation to take 1 second, with a minimum of 1000 iterations;
  • Encryption scheme: AES in XTS mode with sequential IV (aes-xts-plain64).

This was the expected result according to an article.

If, as expected by DataParty or @[email protected], the attackers could have used "up to 10,000 modern GPUs", the cost of the operation would amount to tens of millions per mount by using GCP ones (Estimated price for 1 month: at least 2,140,057.86€ ). Actually, even if the PBKDF2 has not been made to resist to the GPUs, the hash-rate of a PBKDF2-SHA256 password in an NVIDIA Tesla A100 seems to not be that good, the cost parameter being efficient (around 3.5 MH/s per card for 999 iterations, the minimum of LUKS1 being 1000).

I don't know about the hash cracking science enough, thus, I'll not make any assessment about the tool or the crack strategy they used. I wouldn't be surprised to learn that they used an internal crack station, or one from a company like Celebrite, MSAB. I think about a crack station in the style of the Synactiv's Kraqozorus (Every french pentester is jealous of it! 😄).

But all of that work would be nothing without profiling. If we have a limited number of guessing (because we're fighting against a secure element, or because of a low hash-rate), we need to avoid wasting them. As far as I see, though I didn't think about it for a very long time, profiling can be used in many ways:

  1. Knowing the usual constructions of passwords (the "rules" of hashcat or JTR);
  2. Knowing information relative to the target. Keywords or bits of words which would be used to the password construction.

These actions should cover the target itself (in this case, the person arrested) but also people with the same demographic data, opinions, or arrested in similar cases. Then, you should shuffle all of that with factors, and you should get good enough results. Please, note that I have no clues about the efficiency of this kind of profiling.

Conclusion

Here, I tried to draw a quick landscape of the possible attacks on HDD encryption. It is, by no means, non-exhaustive. I've done it primarily to learn more about it (e.g. I didn't see anywhere a compilation of KDF recommendations from standards).

Coming back to the case which leads to this post, I am pretty sure that the exploited vector wasn't the encryption. Else, it would mean that the profiling was excellent and the password quite insecure.

Anyway, we will probably never know how French law enforcement did it. Indeed, I can say with confidence that if a judge asks for a disclosure of the method used to get to the results, the police are in a position that allows them to lie about the real investigation. As a real cop already told me off the record: "The day that a judge ask us how we managed to get the password, we may say that we found the password in a piece of paper or any kind of bullshit: we don't want to reveal our real capabilities.". Do not forget that many cases of forgery committed by french cops have been documented in last years.

On another side, I'm curious about how the French army is managing this risk for itself. If they use the same software as civilian, I'm very curious about how they are doing to tamper this kind of attack. However, if they are using special stuff, I guess that would be acid for the IRCGN and the SDAT to face them 😄

I tried to not reveal anything sensitive. But, if I've done so, be sure that it was not voluntarily. In that case, let's say that it's in response to the many violations of the Human Rights by French law enforcement, as well as in counterpart for the 18 murders you've been doing each year for the past 50 years. And that's not even accounting for mutilations…

Highlight

Some time ago, I decided to highlight "lesser known" artists on my README files and blog posts. This is a gift for curious people who find these texts, a digital time capsule of sorts!

Due to serendipity of calendar and the rediscovery of a forgotten tab in my browser, I (finally!) listened to the music of Joanna Foliveli.

Even if it's not really what I'm used to listening to, I have to say that it's a great project. I knew about her drawings already (and I love them!), but, it was the first time I was listening to her music! Check her out on Bandcamp!

Disclaimer: I never let the artists know that I’m featuring them in my "highlight" section beforehand. This was true of any artist featured here before, and it still is. Therefore, I’d like to make clear that they may not share my opinions or political views.