ubuntustudio-bugs team mailing list archive

Thread
Date

[Bug 1975481] [NEW] On an encrypted Lubuntu installation, I have to type my passphrase twice

To: ubuntustudio-bugs@xxxxxxxxxxxxxxxxxxx
From: Aaron Rainbolt <1975481@xxxxxxxxxxxxxxxxxx>
Date: Mon, 23 May 2022 10:31:00 -0000
Reply-to: Bug 1975481 <1975481@xxxxxxxxxxxxxxxxxx>
Sender: noreply@xxxxxxxxxxxxx

Public bug reported:

Test hardware is an HP Z220 SFF Workstation, 32 GB RAM, 256 GB SSD + 1
TB SSD, UEFI, no secure boot. Test was done within Gnome Boxes, VM was
given SeaBIOS, 4 GB RAM, 20 GB disk space. Host OS is Ubuntu Studio
22.04, guest OS is Lubuntu Kinetic.

If you install Lubuntu with the "Encrypt system" feature offered by
Calamares, you will be asked early in the boot process for your security
key. The system will not boot without it. When the security key is
provided, the early boot screen (with the SeaBIOS text) disappears, and
the Plymouth screen appears (well, due to Bug #1973150, you have to use
a workaround to get it to appear, but whatever). You are then prompted
for the security key again, which should be unnecessary.

Steps to reproduce:

1: Boot the latest Lubuntu Kinetic image in Gnome Boxes.
2: Open the Lubuntu installer.
3: At the partitioning step, use "Erase disk", set your swapfile preference to "No swap", check "Encrypt system", and enter a security key (I used "qwe" as my key, if it matters).
4: Plug in your user data and begin the installation.
5: Ensure that "Restart Now" is checked, then click "Done" to reboot into the newly installed OS.
6: Click on the Lubuntu Kinetic VM you just made in Gnome Boxes.
7: Type your passphrase, and press Enter.

Expected result: The system should proceed to finish the boot process and get you to a desktop.
Actual result: You are required to enter the passphrase a second time to finish the boot process.

Notes:

With Arch Linux, this is a known problem, and it appears to have a well-
documented workaround here: https://wiki.archlinux.org/title/Dm-
crypt/Encrypting_an_entire_system#Avoiding_having_to_enter_the_passphrase_twice
I notice that, in the root directory of the encrypted system, there's a
"crypto_keyfile.bin" file, which suggests to me that Calamares tried to
implement a similar or identical workaround, but failed for some reason.

Also, considering the shortcomings of LUKS1 and the better security
offered by LUKS2, I'm wondering if Calamares should be encrypting /boot
at all? Why not just put /boot on a separate unencrypted partition, and
let Plymouth handle decryption? Granted, this would allow installation
of boot-level rootkits on a system without needing to break the
encryption, but really, even encrypting /boot doesn't fully prevent that
(I can think of at least two attacks that would circumvent an encrypted
/boot in the absence of Secure Boot, no matter how good the encryption
is), and if the data on the computer is sensitive enough to encrypt,
it's probably way more valuable than the computer itself. Why use less
effective data protection for the sake of a not-really-awesome bonus,
when we could sacrifice the "bonus" in favor of better data protection?
Anyway, just my two cents on the topic.

** Affects: calamares (Ubuntu)
Importance: Undecided
Status: New

** Tags: calamares encryption kinetic lubuntu luks

** Tags added: calamares encryption kinetic lubuntu luks

--
You received this bug notification because you are a member of Ubuntu
Studio Bugs, which is subscribed to calamares in Ubuntu.
https://bugs.launchpad.net/bugs/1975481

Title:
On an encrypted Lubuntu installation, I have to type my passphrase
twice

Status in calamares package in Ubuntu:
New

Bug description:
Test hardware is an HP Z220 SFF Workstation, 32 GB RAM, 256 GB SSD + 1
TB SSD, UEFI, no secure boot. Test was done within Gnome Boxes, VM was
given SeaBIOS, 4 GB RAM, 20 GB disk space. Host OS is Ubuntu Studio
22.04, guest OS is Lubuntu Kinetic.

If you install Lubuntu with the "Encrypt system" feature offered by
Calamares, you will be asked early in the boot process for your
security key. The system will not boot without it. When the security
key is provided, the early boot screen (with the SeaBIOS text)
disappears, and the Plymouth screen appears (well, due to Bug
#1973150, you have to use a workaround to get it to appear, but
whatever). You are then prompted for the security key again, which
should be unnecessary.

Steps to reproduce:

Expected result: The system should proceed to finish the boot process and get you to a desktop.
Actual result: You are required to enter the passphrase a second time to finish the boot process.

Notes:

With Arch Linux, this is a known problem, and it appears to have a
well-documented workaround here: https://wiki.archlinux.org/title/Dm-
crypt/Encrypting_an_entire_system#Avoiding_having_to_enter_the_passphrase_twice
I notice that, in the root directory of the encrypted system, there's
a "crypto_keyfile.bin" file, which suggests to me that Calamares tried
to implement a similar or identical workaround, but failed for some
reason.

Also, considering the shortcomings of LUKS1 and the better security
offered by LUKS2, I'm wondering if Calamares should be encrypting
/boot at all? Why not just put /boot on a separate unencrypted
partition, and let Plymouth handle decryption? Granted, this would
allow installation of boot-level rootkits on a system without needing
to break the encryption, but really, even encrypting /boot doesn't
fully prevent that (I can think of at least two attacks that would
circumvent an encrypted /boot in the absence of Secure Boot, no matter
how good the encryption is), and if the data on the computer is
sensitive enough to encrypt, it's probably way more valuable than the
computer itself. Why use less effective data protection for the sake
of a not-really-awesome bonus, when we could sacrifice the "bonus" in
favor of better data protection? Anyway, just my two cents on the
topic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/calamares/+bug/1975481/+subscriptions

Follow ups

[Bug 1975481] Re: On an encrypted Lubuntu installation, I have to type my passphrase twice
From: Aaron Rainbolt, 2022-06-23