Unfortunately, nobody was teaching encryption in my Comp Sci degree.
So LUKS 1 is supposed to be 128 bit or 2^128 = ~10^38 (LUKS 2 = 2^256).
A five digit pin is a search space of 10^6 and an 8 digit is 10^9. So LUKS needs a 38 digit pin to properly be 128 bit?
And is ‘Data’ ordinarily readable on a sector by sector basis without the PIN?
Here is a short description on how LUKS works: https://askubuntu.com/a/805880
So yes, data is readable sector by sector without the PIN, but the data is “random garbage” without the master key. Normally it would be extremely difficult to brute-force guess the master key, but you can obtain the master key with the PIN (or any of the 8 passphrases if they are set). So the PIN is not directly used for encryption, but if you know that the PIN only contains digits and is maximum N long, then you can obtain the master key from 10^N guesses in the worst case, and by (10^N)/2 guesses on average.
So out of interest, I tried this on my own lockcode (which is more random and 6 digits long) using the following commands:
dd if=/dev/disk/by-id/dm-name-sailfish-home of=/home/defaultuser/hashcat.luks bs=512 count=4097
Then hashcat on my desktop:
hashcat -a 3 -m 14600 hashcat-xperia10.luks '?d?d?d?d?d?d'
(I.e. bruteforce luksheader with an input mask of 6 digits)
On my Linux desktop with a partially broken rocm install (so probably low performance), this took 6 minutes and 23 seconds:
hashcat-xperia10.luks:xxxxxx
Session..........: hashcat
Status...........: Cracked
Hash.Name........: LUKS
Hash.Target......: hashcat-xperia10.luks
Time.Started.....: Wed Sep 15 16:51:33 2021 (6 mins, 23 secs)
Time.Estimated...: Wed Sep 15 16:57:56 2021 (0 secs)
Guess.Mask.......: ?d?d?d?d?d?d [6]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........: 1044 H/s (1.96ms) @ Accel:128 Loops:32 Thr:64 Vec:1
Recovered........: 1/1 (100.00%) Digests
Progress.........: 400000/1000000 (40.00%)
Rejected.........: 0/400000 (0.00%)
Restore.Point....: 0/100000 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:3-4 Iteration:1399936-1399966
Candidates.#1....: xxxxxx -> xxxxxx
Hardware.Mon.#1..: Temp: 76c Fan: 0% Core:1630MHz Mem: 945MHz Bus:16
Started: Wed Sep 15 16:50:58 2021
Stopped: Wed Sep 15 16:57:57 2021
So yeah, it doesn’t take long.
Cool, now do it on a Sfos device 
Nah, thank you. That would probably take 2 days or so and is not how an attacker would do it.
Jolla! We want alphanumeric lock codes! 
actually no, what we want is this:
The implementation is ready to be merged thanks to @rinigus
From my limited understanding, it only works if the attacker knows the ssh password. So as an attack scenario it is very limited. It only works if the attacker can keep the device for long enough (years) for vulnerabilities to be discovered in openssh. Or can someone correct me?
If I recall correctly, when you use Recovery Mode, you can use the Shell option without any credentials and the sshd option uses username and password from the recovery image (and these are known) instead of the phone’s Developer Mode password.
No; ssh password has nothing to do with lock code. And the SSH password has no use if the phone is off.
The above clearly demonstrates that it takes mere minutes to brute-force a numerical lock code.
Pretty sure you have to give the lock code there too. Please try before claiming otherwise.
The security may be bad, but it is not a sham.
The recovery should most definitely ask for the lock code if one was set beforehand, but I have no memory of such prompt, probably because I didn’t have lock code set at the time.
That would only be a minor inconvenience to an attacker and does not offer any real security, since you can simply boot a different recovery image, that does not ask for any code…
How do the supposed important Jolla customers (government, corporate) are expected to deal with this possible attack? Do they have access to expensive tools from Sony or Jolla to lock the bootloader?
The only sensible defense is to use a good lockcode (10 characters+ with an alphabet of at least 36)
So i can be glad my daily used Sony XZ2 Compact with SFOS-Community-Port uses this:
Compared to the official encryption solution, this edition has way larger flexibility in LUKS passwords which has a major implication in the security. As it is, official encryption solution is vulnerable to brute force attack. Such attack can be rendered unfeasible using this community edition.
No; the encryption is still for real, even if the key is weak. The disk contents will be unreadable until mounted with correct crypto options and key.
@attah I believe the “minor inconvenience” does not refer to the encryption but to the locking code as protection of the Recovery mode. The attack needs recovery mode (to exfiltrate a copy of the first megabytes of /home), which asks for the locking code; but the locking code can be bypassed by booting another image.
That would make sense. Reply-to here is apparently hard to get right (i often get it wrong too, since for whatever reason you can’t see your on reply-to after you post).
Regarding the possibility to have separate encryption and lock code as proposed by @rinigus and @fingus , I did not find the instructions (on git) to be easy to follow by simple users like me. Since the code and merge request are 2 years old, it would be great if someone could check that it still works for a fresh install with current SFOS, and ideally capture the command session. (I know I have no right to ask anything from anyone.)
In general, if you mean community encryption solution, it was developed for ported devices. During those two years, nobody has ported it to the official device. I would consider that to be something which should be done by the users of the official device if they are interested. I don’t have any official device myself and don’t plan to start such port.