We have moved to a new Sailfish OS Forum. Please start new discussions there.

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

Hello,

it seems that Sailfish 3 now encrypts by default the home partition using LUKS.

The problem is that the numeric code set by the user is actually the LUKS passphrase too.

I can imagine that cracking LUKS for numeric passphrases under 8 characters is matter of seconds. I don't even want to think what would be the length of a safe numeric-only passphrase.

Probably most users are not setting 30-number-long pins, specially given the pin is requested from time to time (without fingerprint unlock, all the time, just to unlock the screen).

Given that flashing is and must remain unlocked (at least in the XPerias), I can imagine it is trivial to flash a new bootloader and get access to the encrypted partitions.

Am I missing something here? Is it possible to lock flashing (i.e. fastboot flashing lock_critical)?

If things are like this, sailflish should ask for an actual password (or complex pattern) to decrypt and mount LUKS on boot, and then use an additionally user pin for all the other things (assuming there is no way to use any safe-enclave in the HW).

edit retag close delete

@goldenowl: can you provide a source for this? How do you know the PIN is also the passphrase for LUKS?
Are you using a Xperia 10? As of now only those models come with home encryption enabled.

And since encrypting an SDCard requires a passphrase (independent of the devices' PIN), it would be very unusual not to use one for the encryption of home, too.
There also is the possibility that SailfishSecrets may handle storing the LUKS passphrase and decrypting the partition once the device has been unlocked using the PIN is done with a dedicated passphrase nonetheless.

( 2020-01-05 03:36:44 +0300 )edit
4

I am using an Xperia 10.

I installed cryptsetup and checked the device that is luks-mapped to the home partition. It contains a single encryption key. I verified that the passphrase to access that key is my numeric pin as requested when booting the phone and it is.

Try it out: to verify it I just did cryptsetup luksAddKey /dev/disk/by-uuid/a61febbf-0920-4053-bd83-86b58ef26e46 (your /home disk uuid will be different) which asks for a current passphrase before asking for a new one. Providing anything other than my pin results in an error message saying there are no keys for the given passphrase.

( 2020-01-05 15:15:44 +0300 )edit
1

wow that's odd. can't verify since I don't have a 10. but using the PIN as password really doesn't seem very secure.

( 2020-01-06 01:02:23 +0300 )edit
5

Using the PIN directly as a LUKS passphrase is a shockingly stupid move from Jolla, even if a temporal solution.

( 2020-01-06 12:12:23 +0300 )edit

Sort by » oldest newest most voted

I tested cracking a 6-digit PIN (LUKS header was taken from Sailfish) with Hashcat and the following hardware:

OpenCL Platform #1: NVIDIA Corporation
======================================
* Device #1: GeForce GTX 1080 Ti, 2794/11177 MB allocatable, 28MCU
* Device #2: GeForce GTX 1080 Ti, 2794/11178 MB allocatable, 28MCU


It was done in under a minute:

Session..........: hashcat
Status...........: Cracked
Hash.Type........: LUKS
Time.Started.....: Thu Mar 26 12:44:26 2020 (22 secs)
Time.Estimated...: Thu Mar 26 12:44:48 2020 (0 secs)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:     5311 H/s (15.65ms) @ Accel:2 Loops:1024 Thr:512 Vec:1
Speed.#2.........:     5368 H/s (15.41ms) @ Accel:2 Loops:1024 Thr:512 Vec:1
Speed.#*.........:    10678 H/s
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Hardware.Mon.#1..: Temp: 45c Fan:  0% Util: 99% Core:1873MHz Mem:5005MHz Bus:8
Hardware.Mon.#2..: Temp: 41c Fan:  0% Util: 86% Core:1911MHz Mem:5005MHz Bus:8

Started: Thu Mar 26 12:43:59 2020
Stopped: Thu Mar 26 12:44:49 2020


So I would say this is a serious problem.

more

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?

( 2020-03-26 14:43:54 +0300 )edit
2

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!

( 2020-03-26 15:18:39 +0300 )edit

... 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

( 2020-03-26 19:56:06 +0300 )edit
3

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.

( 2020-03-26 20:50:21 +0300 )edit

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.

( 2020-05-06 22:10:32 +0300 )edit

The following info seems to have appeared on this topic, as linked from the 3.2.1 release notes:

The security code is discussed here. It is crucial to make the code long.

https://jolla.zendesk.com/hc/en-us/articles/360011115540

The minimum length of the code is 5 digits but we recommend a considerably longer code. The maximum is 42.

I'll take it as the acknowledgment that this is an issue...

more

3

Even the 42 digit maximum is equal with around 128-bit encryption, and the digits don't come from a secure pseudorandom generator, so it's not even that much. And anyway that's about the lower limit of acceptable.

But in reality one uses a 6-10 digits long pin, which is up to about 32-bit encryption. That's fine for a pin with limited number of trials, but not cool at all for drive encryption (unlimited trials).

( 2020-01-13 13:55:54 +0300 )edit

This really should have a "Tracked by Jolla" tag by now...

( 2020-01-13 15:05:04 +0300 )edit
1

Also, there are usability considerations - do you want to have a 10 digit long security code you will have to type in every time you want to unlock the device, just to keep your LUKS volume secure ?

I really think these should be split, like on a regular Linux distro install with luks - a strong alphanumeric passphrase you type on boot to unlock the volume + reasonably strong yet shorter to type user password you type to unlock the screen.

( 2020-01-13 15:08:16 +0300 )edit

I really wonder, how one manages to percieve an "acknowledgement of this (non-)issue" in Jolla's statements linked to above!?!

These help texts in Jolla's Zendesk simply describe the current implementation. To read more into that is just fantasising.

( 2020-01-13 18:33:39 +0300 )edit

• Everybody is free to choose their PIN length according to their (perceived) needs.
• The PIN is not used to encrypt data on mass storage.
It is merely used as a password to unlock a cryptographically strong key with which the data is encrypted.
• [OP] "I can imagine that cracking LUKS for numeric passphrases under 8 characters is matter of seconds."
I cannot "imagine" that and do not see how that might be done. IMO this is just FUD.
• [OP] "I don't even want to think what would be the length of a safe numeric-only passphrase."
5 digits, for me. But for tinfoil hats it will be at least 30. The perception of needed safety varies greatly, especially among those not fully understanding the technology (here primarily: applied cryptography) behind it.
• The OP contains a lot of speculative criticism, but nothing constructive.

I definitely do not want to enter three unlocking codes when booting my SFOS device: The Unlock PIN (>= 5 digits), the SIM PIN (>= 4 digits), plus a (unnecessary) cryptographically strong passphrase of at least 12 alphanumeric characters.
This would constitute an usability nightmare and reduce SFOS' appeal for everyone, except tinfoil hats.

more

12

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.

( 2020-01-13 17:44:49 +0300 )edit
1

+1 @goldenowl very well said

( 2020-01-13 19:51:48 +0300 )edit
2

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

( 2020-01-13 20:23:32 +0300 )edit
2

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.

( 2020-01-13 21:14:07 +0300 )edit

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.

• 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.