Allow to decouple LUKS password from used Security code

REPRODUCIBILITY (% or how often): 100
BUILD ID = OS VERSION (Settings > About product): 4.1.0.23
HARDWARE (XA2, X10, X10 II, …): Xperia Tama

DESCRIPTION:

I am working on new version of /home encryption and managed to hit an issue with the assumed interaction between encryption and lockscreen code. Namely, after setting up encryption through dedicated wizard and opening up encrypted home volume, I am getting into Jolla’s setup wizard which assumes that my security code is set already. Which it is not (see steps to reproduce).

PRECONDITIONS:

Xperia Tama development build, not released. Includes https://github.com/sailfishos-open/sailfish-device-encryption-community setup and configured to support /dev/mapper/sailfish-home in encrypted or non-encrypted form.

STEPS TO REPRODUCE:

  1. Flash development image
  2. Boot and go through Encryption setup, choose to encrypt /home and set password test
  3. Reboot at the end of Encryption setup, as requested
  4. On new boot, enter password test when requested to decrypt /home
  5. Get greeted by “Hola…” and start setting up SFOS
  6. Enter SIM card PIN as requested
  7. Look with the amusement at “Confirm with security code” when requested.

At this stage, I have not set any security code.

EXPECTED RESULT:

As in usual install for non-encrypted /home, ask for new Security code.

ACTUAL RESULT:

See above.

ADDITIONAL INFORMATION:

If I use non-encrypted /home, setup works as expected and I am asked to enter new Security code. In this case, select non-encrypted /home in step 2, reboot as in step 3, and there will be no password to enter in step 4.

Relevant repositories:

PROPOSED SOLUTION

As shown in the post below, issue came from the use of LUKS keyslot as a location to store Security code. To avoid hitting the issue when LUKS keyslots are used differently, allow to disable this feature by hardware adaptation.

Edit history:

  • 21.09.05 changed bug title and proposed the solution
1 Like

And we are back in business! By lucky guess, it turns out that Jolla’s Security code check is using LUKS keyslot to keep it if you have LVM logical volume with the name sailfish/home. By renaming that logical volume to sailfish/home-open the link between PIN and LUKS was broken.

Can’t confirm it in the code as it is closed source.

Added:

Running strings /usr/lib64/qt5/plugins/devicelock/encsfa-fpd:

org.sailfishos.device.encryption
/dev/sailfish/home
Could not initialize crypt_device
Could not load LUKS parameters for crypt_device
3 Likes