[Sailfish 3] Numeric pin as LUKs passphrases make device encryption useless

Thanks for the test! How would the benefit look like, if the input alphabet would consist of alpha-numeric input and the PIN therefore consist of letters and digits. If Jolla switch to a keyboard input compared to number pad input the input alphabet would drastically change the magnitude of the base of calculation 10^ vs 48^ ... so the first step to a solution would be as simple as a keyboard?

It would improve the situation quite a bit. Because the key space (amount of combinations the attacker has to try) would grow significantly. Now for the 6-digit PIN the key space is 10^6 = 1000000, which isn't much for a proper GPU cracking hardware. Having a full keyboard with lowercase & uppercase alphabets (english), digits and special characters the key space (for 6 char pass) would be something like (if I calculated correctly) (26+26+10+50)^6 = 1973822685184. Of course it would be good to enforce some decent minimum length for it or otherwise instruct users to have decent length passwords here.

I don't have the numbers right away how much effort would it require to crack that (or what should be considered minimum length for LUKS pass), but it would definitely improve the situation a lot!

... yeah it would be a improvement. BTW, I am not familiar with hashcat but does the pass function of LUKS e.g. PBKDF2 brings some cost, even for GPU brute force attacks? Is this not the idea behind derivation functions? SFOS's default is LUKS1 and for that format:

  $ LANG=C cryptsetup --help |grep "Default PBKDF"
  Default PBKDF for LUKS1: pbkdf2, iteration time: 2000 (ms)
  Default PBKDF for LUKS2: argon2i

It does and the cracker needs to run the password candidates through that function to test them. So it's not a vulnerability in either PBKDF2 or LUKS, but just brute-force testing through different passphrases. To raise the bar it would be good to configure LUKS to use sha512 (instead of sha256) and have more iterations. That way the cracking would require more effort with the small price of taking a bit more time to unlock the encrypted partition.

Just an idea to raise the cost (not tested): The unlock happens while booting. So adding (CLI) a second very long passphrase (numeric) for unlocking the device is not that difficult. If so, then deleting the former one would be enough to raise the bar. The login after the device booted would happen with the normal pin ... thought.

I am not sure you have any idea of what you are talking about. According to https://hashcat.net/forum/thread-7051.html, cracking a 10-digit password is 11 days. A 9 digit password would be 1 day. An 8 digit password would be 2 hours. That was in 2017...

It is merely used as a password to unlock a cryptographically strong key with which the data is encrypted.

I really think you don't understand... if you lose your phone, anyone can attack your short password to obtain access to the luks key. There is no protection for anyone to access luks headers of any partition because flashing a custom bootloader is perfectly possible.

And YES, you do want to write a safe passphrase on boot. This is what Android did not so long ago, particularly when running custom ROMs. Once you are in the system, you can control how many retries the user is allowed to do for unlocking with shorter, numeric pins etc, but before there is no choice unless you have a secure enclave to store that information. Again, it is not tinfoil, it is you not having basic knowledge of what you are talking about.

+1 @goldenowl very well said

It's good enough for every-I-don't-have-nothing-to-hide-ones. ;)

Also note that an attacker would likely extract the LUKS headers first off the device, where he can run the pin quessing much mor quickly, on multiple machines and possibly even using public cloud resources on a very masive scale (thousands of CPUs).

Thats why encryption passphrase needs to be strong, unless you use a HSM you trust & that dependably prevent's key extraction and fast guessing.

Agreed, I should have omitted the "merely" in my answer.
Besides that, thank you all for (implicitly) corroborating my other points so nicely. 😉

WRT the technical aspects, I do concur with the assessments that ...

• it is technically possible to program and build a specially crafted "recovery image", which detects running on an Android phone reflashed to SailfishOS and scrutinizes its LVM volumes to automatically extract the LUKS header(s). Alternatively this may be done manually with a regular SailfishOS' recovery image.
  For this to work, physical control over the device and a USB cable is needed to start such a "recovery image" per fastboot boot in order to obtain the LUKS header(s) for analyses.
• after creation of that tool, its use on a specific device and exfiltration of the LUKS headers, it would be possible to perform a brute force attack, using the specific knowledge that SailfishOS's device encryption uses numerical passphrases ("PINs").
• if all these preconditions are given, an attacker with a well equipped PC should be able to find a matching 5 digit PIN within seconds, a 6 digit PIN within minutes, a 7 digit PIN within half an hour and every additional digit used increases the needed time by the factor 10.

But exactly these assessments render the statement "if you lose your phone, anyone can attack your short password to obtain access to the luks key" untrue:

• Almost all finders of the phone will not be able to detect that it runs SailfishOS, not be capable of utilising fastboot boot to boot a SailfishOS recovery image, not be able to perform extraction manually or to automatise it, plus not be able to "reverse-hash" the extracted data to ultimately obtain the PIN.
• A couple of PPM (parts per million) of all potential finders might be able to perform these steps, but the most of them will refrain from doing so due to moral and/or legal reasons (see next point).
• In most (western) jurisdictions taking such an effort to exfiltrate somebody else's data fulfils the criminal offence of computer espionage. Hence using that data bears some danger for a finder, who is most likely living in the same nation / jurisdiction as the owner of the lost device.

Thus a complete security assessment of the "lost device scenario" renders this risk negligible, even without any device encryption (but e.g., in contrast to unencrypted SD cards).
Well, actively disregarding or simply not being able to see the non-technical aspects is typical for "tin foil hattism". Just as regarding everyone (or maybe just oneself) as an aim of professional, targeted (i.e., individual, specific and costly) attacks (e.g. by a secret service). If you do believe that "they are after you", a regular Smartphone with SailfishOS is definitely the wrong choice, anyway. It is much more likely though, that none of us is interesting enough to justify the many € 10.000,- that costs.

Still you can use a 42 digit PIN, which provides sufficient entropy (> 120 bits) for encrypting information, which is classified as Top Secret.
Which is futile, as the rest of the environment (SFOS and its apps) have not, cannot, should not and hence will not provide sufficiently strong security mechanisms and assessments: First and foremost this would need a fixed configuration (no settings, no (un)installing apps etc.) as the biggest security flaw is usually the user altering the system.

But what really got me started was demanding from Jolla that enforcing such a nonsense should be imposed on every user!
That is ultimately the most common result of "tin foil hattism": to strongly believe that oneself and everyone must be forced to use Top Secret cryptographic strength, no matter what the requirements are and regardless if this really increases the overall security.
It reality such a setup just drives most people away, because it is unbearable or even unusable for them while they gain nothing.

P.S.: Please meditate about your "ad hominem": "Again, it is not tinfoil, it is you not having basic knowledge of what you are talking about."
Hint: For most readers such arrogant and ignorant statements just point at their author.