Our LUKS fde may not be enough anymore

General Privacy & Security
21

Now if only he had had Purism equipment.
Cam/Mic kill switch on Librem 14: off
Cam/Mic kill switch on Librem 5: off

As I understand it, there still needs to be some means of gathering sound from the vicinity of the device where the LUKS passphrase is being entered. If you can deny the attacker that means of gathering sound then it will help you.

Of course if you use your laptop in a public place, other means of gathering sound will be around and there is not much you can do about that - but then there are probably more reliable means of grabbing the passphrase in that case.

If you use your laptop in a private place but that private place has been compromised then the same two thoughts apply.

I think you should assume that if you use your mainstream phone in the vicinity of any laptop then the phone will be compromised by the authorities and could be used in this way.

Whether this has anything to do with the OP is, alas, speculation.

1 Like
22

Your remark here is IMO the core issue of this interesting debate on LUKS fde.
Because the truth is we keep hearing this tune more and more. We should ask ourselves why is it so and what should we do?
Also perhaps more concerning is the NIST announcement last January that they are starting a review process of their SP 800-132 Recommendation NIST Requests Comments on SP 800-132, Recommendation for Password-Based Key Derivation: Part 1: Storage Applications
in which they specify: NIST requests feedback on all aspects of SP 800-132. Additionally, NIST would appreciate feedback on the industry need for new password-based standards, including memory-hard password-based key derivation functions and password hashing schemes.
NIST’s problem here is that millions of computers that have to be compliant to their approved standards for legal reasons would like to move to Argon2 family, but can’t because they would loose compliance.
It is to be noted also that Canonical moved to argon2 as default on their install CD, as of Ubuntu 22.
QubesOS is still pbkdf2 on their install CD - and I wonder why?
Purism is also still pbkdf2 as default for LUKS container, but I presume that they are stuck because they have to continue providing compatibility for the Seabios/Grub boot path.

1 Like
23

That depends. If /boot is unencrypted then / can use whatever LUKS slot algorithm is supported by the kernel. if /boot is encrypted then it may be limited by the boot path (but / is still free to use a different slot algorithm). In other words, there is no such thing as FDE, only FPE.

Note that if you download an encrypted disk image and you fail to re-encrypt then the intruder has zero need to attack the slot encryption passphrase - because the disk encryption master key can be directly determined. In this scenario even a length 100, printable ASCII slot encryption passphrase (and whether used with PBKDF2 or Argon*) makes no difference, because it is simply bypassed.

1 Like
24

Yes. It is like this and will be. So do not store any information you think that some will be compromise you or your descendants in future for your leaved information in the past. Its a time where we do not know what kind of “God”, Religion, Algorithm and Neural Network, will be emerge in future, so its better to not have stored useless* data … you can be compromised by… for in future. By searching the last 100 years. Or have a secure phone and encryption and a way for yourself or your follows, to store something encrypted.

*Its hard to guess what this is. Because its the secret of evolution and the magic that only useful, right one was good enough to got reward by dailies A/B testing. No one knows. But Privacy is some kind of a joker. Because it will keep you third parties judgement by design.

25

Clearly written by someone who doesn’t have a good understanding of the subject matter. Passphrases as described above are typically generated from a character set size of 90-95 characters. A passphrase of 20 character length and generated from a character set size of 90 has an entropy of ~130bit.

The author’s assertion appears to be that a 128bit AES key is fine while a ~130bit entropy passphrase can be brute forced, that makes no sense.

Yes it does. Assuming the passphrase has a lower entropy than the size of the key, increasing the entropy of a passphrase is more effective than increasing the passphrase processing cost regardless if it’s by increasing iterations or memory costs. If the entropy of the passphrase is equal to, or greater than the cipher key size, there is no benefit in increasing iterations or memory costs.

The actual key conversion procedure given is simply…

sudo cryptsetup luksConvertKey /dev/whatever --pbkdf argon2id

This relies purely on the defaults, the default behaviour is to benchmark the system and set the parameters as such that the passphrase will be processed in ~2 seconds. For most people/systems this may be good enough but it may not be.

In the case of a Librem 5, relying purely on the defaults will result in a memory cost of ~333M which is significantly less than the 1G in the author’s example scenario.

If you want a memory cost of ~1G as per the example scenario and you are doing this directly on the phone then you can set --iter-time…

sudo cryptsetup luksConvertKey \
  --pbkdf argon2id \
  --iter-time 5000 \
  /dev/mmcblk0p2

If you are doing on another machine with the Librem 5 being the intended target…

sudo cryptsetup luksConvertKey \
  --pbkdf argon2id \
  --pbkdf-force-iterations 4 \
  --pbkdf-parallel 4  \
  --pbkdf-memory $((1024*1024)) \
  /dev/mmcblk0p2

The increase in memory cost comes with an increase in time to process the passphrase, using either of the above two examples will result in the Librem 5 taking ~5 seconds to process the passphrase rather than the ~2 second default.

The benchmark will always return at most 1G for the minimum memory cost, if increasing memory cost is the main goal for going through the conversion process and you have a reasonably well specc’d machine you could probably specifiy a higher memory cost directly.

3 Likes
26

That may not be true because a brute force attack against the underlying disk encryption is an attack against something different from a brute force attack against the key slot.

A successful attack against either will completely compromise all your data - but you don’t know in advance whether the attacker will attack the one, or the other, or both - and there may be technical differences in the difficulty in attacking each one.

If we assume that the attacker attacks both in parallel and that the unit cost in trying one “key” is the same … then the weakest link by entropy will fall first (on average) - so a user needs to understand which is the weakest link and strengthen the weakest link - which I guess is what you are saying.

Unfortunately it isn’t clear to me what strength of underlying disk encryption key this user was using. Was it AES 128 bit? Was it AES 256 bit? (noting that actual keys as used by AES-XTS are twice as long as the underlying AES key)

27

TL;DR When opening the container with the master key directly is magnitudes faster than processing the passphrase, why would you continue brute forcing the passphrase above the master key size?

Consider the following…

Create a small image file for the LUKS container…

root@svala:~# dd if=/dev/zero bs=512 count=$((1024*1024)) > luks.container
1048576+0 records in
1048576+0 records out
536870912 bytes (537 MB, 512 MiB) copied, 1.09705 s, 489 MB/s

Create a stupidly high entropy passphrase (a 96 character length passphrase randomly generated from a 92 character set (~626bit entropy)…

root@svala:~# LC_ALL=C tr -dc 'a-zA-Z0-9!@#$%&*()+=_,./<>?;:"|[]{}~`'"'-" < /dev/random | head -c 96 | tee passphrase; echo
wX"p";2P3Usg&$[hLC3bVz3FP,VFVWpriBFWH0uxj~aR-c%7}z:,Ch@D5]JhlEHo'W(O3(T/#bt`Nc{HH}RV:bGm._$!`6!<

Format the LUKS container…

root@svala:~# cryptsetup luksFormat -q --pbkdf argon2id --key-size 512 luks.container passphrase

Check the header for cipher key size (512bit) etc,…

root@svala:~# cryptsetup luksDump luks.container
LUKS header information
Version:       	2
Epoch:         	3
Metadata area: 	16384 [bytes]
Keyslots area: 	16744448 [bytes]
UUID:          	e678c1a4-510c-4615-97a9-946b7884d9d2
Label:         	(no label)
Subsystem:     	(no subsystem)
Flags:       	(no flags)

Data segments:
  0: crypt
	offset: 16777216 [bytes]
	length: (whole device)
	cipher: aes-xts-plain64
	sector: 512 [bytes]

Keyslots:
  0: luks2
	Key:        512 bits
	Priority:   normal
	Cipher:     aes-xts-plain64
	Cipher key: 512 bits
	PBKDF:      argon2id
	Time cost:  5
	Memory:     1048576
	Threads:    4
	Salt:       2c bc f0 4c ce 98 67 ca cb b0 b5 ba f6 e4 f5 72 
	            8c 97 2c 0e 69 8e 05 4c 2e 47 c4 b3 14 6c 54 bf 
	AF stripes: 4000
	AF hash:    sha256
	Area offset:32768 [bytes]
	Area length:258048 [bytes]
	Digest ID:  0
Tokens:
Digests:
  0: pbkdf2
	Hash:       sha256
	Iterations: 144830
	Salt:       8c 68 ed 1b 5c 32 a7 7b 59 dd f5 49 7f 3f 84 85 
	            f9 4d 61 33 b6 f6 cb 76 db 37 fe d5 80 01 14 77 
	Digest:     fe 76 ec bb 1c c1 cc 50 e9 44 17 e1 69 f3 6b 4e 
	            d6 7f db 67 bb d7 a0 7e c4 6d 99 78 ed fb 69 ac

Extract the LUKS container master key…

root@svala:~# cryptsetup luksDump -q --key-file passphrase --dump-master-key --master-key-file masterkey.bin luks.container
LUKS header information for luks.container
Cipher name:   	aes
Cipher mode:   	xts-plain64
Payload offset:	32768
UUID:          	e678c1a4-510c-4615-97a9-946b7884d9d2
MK bits:       	512
Key stored to file masterkey.bin.

Check master key as readable hex (128 characters from a character set size of 16 (a-f + 0-9) confirms 512bit)…

root@svala:~# xxd -p -c 64 < masterkey.bin
794ed357c17233232034a5e989d130eed5c558f4edfe871d1900ec4990b02e1c98a42576f4153d85b44e981a4e0e09db0af38914e3bcf01c1a4ef2952a18a387

Time passphrase processing by open LUKS container with passphrase…

root@svala:~# time cryptsetup open --key-file passphrase luks.container luks_opened

real	0m1.857s
user	0m5.466s
sys	0m0.272s
root@svala:~# cryptsetup close luks_opened

Time opening of LUKS container using master key directly…

root@svala:~# time cryptsetup open --master-key-file masterkey.bin luks.container luks_opened

real	0m0.213s
user	0m0.108s
sys	0m0.016s
root@svala:~# cryptsetup close luks_opened

Regardless of whether you use “real” or “user” metrics, opening the container with the master key directly is magnitudes faster than processing the passphrase, why would you continue brute forcing the passphrase above 512bit incurring a time penalty that doesn’t exist if you went directly with the master key?

2 Likes
28

Now if only we had real facts about our activist’s actual encryption setup.

One concern that I have - and it is touched on by the article linked in the OP - is that encryption that was set up many years ago may lock in weaker security choices.

Even so, it’s only worth a handful of bits based on those numbers. In the overall scheme of things, it will only change the comparison a small amount.

Let’s say that 512 bit AES-XTS key is the default. Let’s generously subtract off 10 bits for a direct attack against the master key being “1000 times” faster than attacking the slot passphrase. So call that 502 bits. That is still much much stronger than any realistic passphrase. (Would need length 77 printable ASCII passphrase.)

Actually I’m unclear on whether 512 bit AES-XTS should really be considered to have 256 bit AES strength (and, again, let’s knock off 10 bits). That is still demanding of a printable ASCII passphrase of length 38 which may exceed what people are really using or could readily remember.

Then worry that our activist might have been using 256 bit AES-XTS (which would change the comparison numbers again).

29

I don’t buy this at all, cryptsetup reencrypt provides options for changing most parameters during reencryption. There is one noteworthy potential caveat for LUKS1 if trying to increase the key size in that there may not be enough space in the header to accomodate the operation but it’s not an absolute and there are various workarounds. Admittedly the workarounds are not simple “one liners” but they are also not rocket science either.

Ultimately however, there is no “lock in” as you can just create a new container with all the options/choices you desire and then clone the contents from the old container to the new. It’s not any more involved than cloning a physical drive. You can set the UUID of the new container to match the old so everything gets picked without any need for remapping. I do this on a regular basis, and is my preferred method for converting from LUKS1 to LUKS2.

Both of the articles are rather scant on detail and substance, everything is assumption and speculation which renders the whole thing pointless in my mind.

30

What I meant is that that is the effect if the user takes no additional action. If the user has the perspective that he set up encryption so it’s all good, and then later on security improvements are available, those improvements might not be automatic. Some security choices have to be recorded in the LUKS metadata, for use each time the encrypted volume is unlocked, and those choices are not reviewed automatically.

(As far as I can see, when you enter the plaintext passphrase, it would be possible for the software to re-encrypt the slot with improved security choices, if available, while keeping the same passphrase, and to do so automatically, but there would no doubt be philosophical and practical objections.)

I would like to see even a definitive statement that the activist was using LUKS2 rather than LUKS1.

31

Personally I really wouldn’t want an OS to automatically push such changes to something as fundamental as encryption.

I doubt you’ll see a definitive on anything. The original article makes mention of Ubuntu 18 in a way that I percieved it to be a clean/new install on Ubunut 18. So I would guess that what ever the default LUKS version was for Ubuntu 18 is probably what was being used, I know nothing of Ubuntu however.

32

That might be an op-sec failure right there. @TiX0

Assuming it means 18.04 LTS, that is 4 years out of date and 2 LTS releases out of date. Quite apart from any changes to LUKS security defaults, this does not speak of someone who is keeping his software current. OK, technically, at the time of his arrest, 18.04 was still inside its general support period - but it is still much tardier than I like to be.

Actually, it is. I just formatted a new LUKS volume specifying no parameters, hence taking all the defaults, and here’s what I got:

  • LUKS2
  • master key 512 bit AES-XTS
  • slot: argon2id, time cost 5, memory 1048576, threads 4

which all seems reasonable. That’s with Ubuntu 22.04 LTS.

1 Like
33

And for those that care about these things (which would be more than the average proportion of people, in this forum), I did a Live Boot of Ubuntu 18.04 LTS and did a default luksFormat … here’s what I got:

  • LUKS1
  • master key 256 bit AES-XTS
  • slot: (by definition) PBKDF2, iterations 3266590

That’s on the same computer as yesterday’s test - so, to the extent that some of these parameters may be “benchmarked” for the particular hardware, it is an apples-to-apples comparison.

Of course we know nothing at all about the hardware that is “Ivan’s personal computer” and we can’t be sure that LUKS was set up on Ubuntu 18.04, only that that is the version that he was running at the time of his letter.

1 Like
34

I agree. And in fact I made the same kind of failure when upgrading from PureOS 9 to 10 because I was too lazy to do a clean-install and instead did a dist-upgrade, which kept the original (weaker?) LUKS1 header in place. But then again, a clean install would only have improved the LUKS to version 2, but kept the pbkdf2 KDF since it is the default.
I was not aware that there could be such issues with commonly considered strong fde as the LUKS design. It was Garrett’s article that alerted me and had me check which versions of LUKS and associated KDFs were on all my devices. In doubt, and unable to assess the real risks, I decided to change everything to argon2id. Am I safer now than before? I have no idea…
But in a sense, reading this article was a good thing: it brought me awareness of a potential disastrous situation I didn’t know about - and this was the purpose for my starting this topic. But after 33 posts in this thread, I must say that I still don’t know if pbkdf2 could now or could not be brute-forced. Nobody seems to have a definite answer: maybe we should just ask cryptography expert Bruce Schneier and have an educated opinion on this issue (which may in fact not really be one, as the general opinion is.)

2 Likes
35

This is where it gets confusing. Based on my testing, PBKDF2 is not the default (see above). However if you are talking about a given operating system installer, the defaults that it applies could be different from the defaults that cryptsetup applies. Furthermore, if you are talking about a root file system then, whatever the default is, it has to work with the kernel in the boot file system (which, again, could influence the operating system installer).

Furthermore, in the case of Ubuntu (which uses GRUB), you have the choice of booting previous kernels and, for a time, after a major version upgrade you might still want to be able to boot the previous major version, which means that security can’t be upgraded beyond what is supported by the previous major version.

Maybe you should raise an issue against PureOS if you believe that the operating system installer is not capable of using Argon*.

(Things are different on the Librem 5, where you have a LUKS disk image and you can change the slot encryption after download and before flashing … if the result boots at all. That is, there is no installer.)

Indeed. And I’m pretty sure that the French authorities aren’t going to tell you, not any time soon, maybe never.

Sounds fair.

1 Like
36

Everything can be brute-forced. Even if we combine all machines together to make the world biggest brute-force and we still need mathematically 50 billion years to get through all possible passwords with a specific max length … grandmas PC from year 1990 can break it within few minutes if you’re lucky/unlucky (depending on which side you’re ^^).

It’s all about probability calculation. Every chance above 0% as tiny as it could be, it’s a chance that brute force gets successfully. But in the real world it’s like winning 10 times the mega jackpot in lotto in row with only one ticket each time. So it’s more theoretical than a real issue.

Back to our topic:
Argon2id is good, because you can have same probability that your password get brute-forced with shorter length of your password. But you also can choose a longer password with just LUKS and you are not less save. The real question is: did the activist something wrong, was police just unrealistic lucky or has LUKS a bug they could abuse? The first case is most likely in my mind. But without more information, we just know nothing.

1 Like
37

Except one-time pads, although they have other practical issues of their own.

1 Like
38

The default depends on the individual distros, the defaults for the cryptsetup version you are using are listed at the end of cryptsetup --help

For an additional data point, at this time, running cryptsetup luksFormat on PureOS Byzantium on a Librem 5, taking all defaults results in…

  • LUKS2
  • master key 512 bits AES-XTS
  • slot: argon2i, time cost 4, memory 377114, threads 4

For many people, their phone typically holds the most personal/sensitive data of all the devices they own. Are these defaults considered good by todays standards?

In what context? Reasonable defaults for a desktop OS? Reasonable for the average desktop user? Reasonable across the board?

39

It depends on the threat model, but decrypting LUKS containers is usually not a time-effective attack against a typical smartphone user. Currently the most preferred method for adversaries focusing on smartphones is social engineering attacks, such as phishing; the weakest link is still the user.

40

I think the “problem” here is that it is adapting the default parameters to the hardware that it is running on.

So with relatively modest hardware specs such as you may find on a phone, the algorithm is producing default values that are weaker than you would get if you ran the same default cryptsetup command on the same distro and version on a much more powerful (which is not difficult) desktop / laptop computer.

So your choices on a phone are:

a) accept a much longer unlock time each time you boot the phone, v.
b) accept that the size of the GPU farm that the nasty actor needs in order to brute force your slot is much smaller

in either case comparing phone v. desktop/laptop with same distro and version (and all other things being equal).

And when I say “time”, I am also implicitly talking about the constraints imposed by memory. On my desktop I could comfortably tell Argon to use 8GB of RAM in order to make it just that much more challenging for the nasty actor to brute force my slot but clearly that is not an option on a phone that only has 3GB of RAM.

So to pick up your point: yes, that’s right - a person’s most sensitive data may well be held on the device that is least able to protect it.

But that’s “protect it from slot passphrase brute-forcing” which is only one small part of the total security / privacy risk.

Sorry, I meant reasonable for my desktop hardware (and taking into account current encryption technology that is supported by LUKS).

The original material clearly stated that our activist is using Ubuntu - so I was happy to test exactly that.

Out of curiosity, does that mean that PureOS Byzantium on a Librem 5 does not support argon2id ?