Re: Unlock LUKS with login/password

[Jeremy Stanley]

On 2023-03-11 12:57:56 -0500 (-0500), Timothy M Butterworth wrote:
[...]
> The reason you can not use Login/Password as the LUKS passphrase
> is because The Passphrase can not be different for different
> users. The passphrase is not simply a password but instead it is
> part of the key material used to decrypt and encrypt.

Not that I'm a fan of the proposed use case, but see the manpage for
cryptsetup-luksAddKey(8): "Adds a keyslot protected by a new
passphrase." So while there is only one passphrase for a key, a
device can be accessed by an arbitrary number of keys.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Unlock LUKS with login/password

[Timothy M Butterworth]

On Wed, Mar 8, 2023 at 11:33 AM Alexey Kuznetsov 
wrote:

>
>
> On Wed, Mar 8, 2023 at 7:11 PM Adrien CLERC  wrote:
>
>> Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :
>>
>> Hello!
>>
>> I have an idea about how modern linux should work with encrypted LUKS
>> partitions.
>>
>> Hi,
>>
>> I'm using LUKS for a long time on both my personal (desktop) and
>> professional (laptop) computers. Since they are single user (me), I use
>> autologin in the display manager, lightdm in my case. Because there is only
>> one slot configured in LUKS, I'm sure this is me, so lightdm can autologin
>> safely.
>>
>> However, you are proposing to solve the case for multiple user computers.
>> In that case, I would think about a much simpler design:
>>
>> - Remember which slot was used to unlock the LUKS root partition
>>
>> - Make a map with slot -> user to autologin
>>
>> - Autologin that user on boot
>>
>> No more passing password, no more password update headache. But only a
>> root user can update the map "slot -> user".
>>
>> Adrien
>>
> Right. But you still have to remember passpharse and your main account
> password. This is not about autologin. This is about unlocking your machine
> LUKS with only login/password without having an additional passphrase to
> remember.
>

The reason you can not use Login/Password as the LUKS passphrase is because
The Passphrase can not be different for different users. The passphrase is
not simply a password but instead it is part of the key material used to
decrypt and encrypt.

-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/
⠈⠳⣄⠀⠀

Re: Unlock LUKS with login/password

[Marco d'Itri]

On Mar 10, Stephan Verbücheln  wrote:

> On Fri, 2023-03-10 at 15:12 +0100, Marco d'Itri wrote:
> > In the future the initramfs will (usually) be static as well.
> Can you provide more information on that?
Due to multiple reasons, mostly related to secure boot and boot 
attestation, there is significant interest by distributions in providing 
static and signed initrds.
BTW, I have been informed that "initramfs" is an obsolete term and that 
we are back to "initrd" like in the '90s.

Some people in Debian are interested in working on 
https://github.com/systemd/mkosi-initrd, which will provide a static 
initrd built from system binaries and extensible using the 
systemd-sysext and future systemd-sysconf mechanisms for things like 
SAN boot or sshd in the initrd.
Do not look too hard at it at this point: the upstream developers are 
going to make soon a new release with significant changes.

I expect that people interested in working on initramfs-tools can 
probably extend it with little work to generate static images suitable 
for the most common deployments.
People with uncommon ones will have to do without the modern boot 
attestation features or else sign their own images (which will be very 
easy once I, or somebody else, will have packaged sbctl).
Obviously there are no new requirements for the systems without secure 
boot.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Unlock LUKS with login/password

[Stephan Verbücheln]

On Fri, 2023-03-10 at 15:12 +0100, Marco d'Itri wrote:
> In the future the initramfs will (usually) be static as well.

Can you provide more information on that?

Thanks and regards
Stephan



signature.asc
Description: This is a digitally signed message part

Re: Unlock LUKS with login/password

[Stephan Verbücheln]

On Fri, 2023-03-10 at 14:28 +, Jeremy Stanley wrote:
> Okay, so you're wanting to rely on encrypted /boot as an incomplete
> alternative to checking file signatures, because the current
> attestation solutions are also imperfect. Keep in mind that
> checksumming isn't providing protection from coherent modification
> of the decrypted filesystem and checksums, it's just protecting
> against someone blindly modifying the encrypted blocks.
No, this is not about blind modification. There are relevant attacks in
this area.

https://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/

>  If they have
> physical access to your system sufficient to modify firmware or add
> hardware without you noticing, then encrypted /boot is pretty
> pointless against such an actor.
The only thing an attacker can modify in software is the GRUB binary in
/boot/efi. The GRUB binary can be more easily verified by Secure Boot
and it is where I enter my LUKS passphrase.


> Well, it's not as if encrypted /boot is protecting you from the
> attacks described in that article either. Someone with that level of
> access to your system can quite easily record/copy your decryption
> keys, or simply wait until you've unlocked your sensitive data.
Hardware modifications are not a fair comparison. Hardware
modifications can always replace anything with anything that looks
alike.

> Sure, if you're concerned that sensitive information is being put in
> /boot sufficient to warrant the additional work of protecting it
What additional work? The installer did it automatically without me
even noticing for years.
Having a separate /boot partition is actually more work. You need to
decide on the required size, choose an appropriate filesystem etc.

> from disclosure when someone steals the device or gets their hands
> on the drive after disposal, then by all means go ahead. It's just
> not usually worth that amount of additional complexity.
Any installed program that is not in the essential setup should be
considered sensitive information.

> It comes down to basic cost/benefit analysis, and deciding what
> threats you reasonably want to invest in defending against. I'm
> certainly not saying there's *never* a reason to encrypt /boot, but
> people who feel they need to do so aren't involved in improving
> tools and automation sufficiently to make it convenient to set up
> either.
There is nothing inconvenient about it.

Regards


signature.asc
Description: This is a digitally signed message part

Re: Unlock LUKS with login/password

[Jeremy Stanley]

On 2023-03-10 13:48:21 + (+), Stephan Verbücheln wrote:
> Encryption per se does not protect against modification, I am aware of
> that. That is even more true for disk encryption where the encrypted
> data block has to fit into the physical disk block, so there is no room
> for a MAC or signature. However, in combination with a filesystem like
> btrfs which checksums everything, it is providing some protection, even
> though it was not designed for that purpose.

Okay, so you're wanting to rely on encrypted /boot as an incomplete
alternative to checking file signatures, because the current
attestation solutions are also imperfect. Keep in mind that
checksumming isn't providing protection from coherent modification
of the decrypted filesystem and checksums, it's just protecting
against someone blindly modifying the encrypted blocks. If they have
physical access to your system sufficient to modify firmware or add
hardware without you noticing, then encrypted /boot is pretty
pointless against such an actor.

> Apart from the fact that UEFI Secure Boot is an overly complex monster
> which is basically broken[1] by design, my understanding of it is also
> that it does not protect configs, initramfs etc. in /boot. It only
> protects the kernel image and loaded modules.
> 
> [1]
> https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/

Well, it's not as if encrypted /boot is protecting you from the
attacks described in that article either. Someone with that level of
access to your system can quite easily record/copy your decryption
keys, or simply wait until you've unlocked your sensitive data.

> In addition, files in /boot like the initrd are generated individually
> and may contain files not limited to what someone puts into /boot
> intentionally. In contrast to /boot/efi, /boot does not only contain
> static files delivered by the distribution.

Sure, if you're concerned that sensitive information is being put in
/boot sufficient to warrant the additional work of protecting it
from disclosure when someone steals the device or gets their hands
on the drive after disposal, then by all means go ahead. It's just
not usually worth that amount of additional complexity.

It comes down to basic cost/benefit analysis, and deciding what
threats you reasonably want to invest in defending against. I'm
certainly not saying there's *never* a reason to encrypt /boot, but
people who feel they need to do so aren't involved in improving
tools and automation sufficiently to make it convenient to set up
either.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Unlock LUKS with login/password

[Marco d'Itri]

On Mar 10, Stephan Verbücheln  wrote:

> Apart from the fact that UEFI Secure Boot is an overly complex monster
> which is basically broken[1] by design, my understanding of it is also
> that it does not protect configs, initramfs etc. in /boot. It only
> protects the kernel image and loaded modules.
It can, with an appropriate configuration.

> In addition, files in /boot like the initrd are generated individually
> and may contain files not limited to what someone puts into /boot
> intentionally. In contrast to /boot/efi, /boot does not only contain
> static files delivered by the distribution.
In the future the initramfs will (usually) be static as well.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Unlock LUKS with login/password

[Stephan Verbücheln]

Encryption per se does not protect against modification, I am aware of
that. That is even more true for disk encryption where the encrypted
data block has to fit into the physical disk block, so there is no room
for a MAC or signature. However, in combination with a filesystem like
btrfs which checksums everything, it is providing some protection, even
though it was not designed for that purpose.

Apart from the fact that UEFI Secure Boot is an overly complex monster
which is basically broken[1] by design, my understanding of it is also
that it does not protect configs, initramfs etc. in /boot. It only
protects the kernel image and loaded modules.

[1]
https://www.welivesecurity.com/2023/03/01/blacklotus-uefi-bootkit-myth-confirmed/

In addition, files in /boot like the initrd are generated individually
and may contain files not limited to what someone puts into /boot
intentionally. In contrast to /boot/efi, /boot does not only contain
static files delivered by the distribution.

Regards
Stephan

Re: Unlock LUKS with login/password

[Russ Allbery]

Jeremy Stanley  writes:

> Disk encryption is great (when properly implemented) to protect
> sensitive information on your machine from prying eyes if it gets
> stolen, but unless you're putting sensitive data in /boot why go to the
> added trouble of encrypting it?

I think this is the key point: you should not be putting sensitive data in
/boot, and this is generally always avoidable (and architecturally better
to put it elsewhere).

I have put sensitive data in /boot in the past because reasons, so it's
not strictly true there is *never* a benefit, but I agree that this wasn't
a great architecture and there were better ways to do it.

-- 
Russ Allbery (r...@debian.org)  

Re: Unlock LUKS with login/password

[Jeremy Stanley]

On 2023-03-09 06:21:10 + (+), Stephan Verbücheln wrote:
> Can you explain or refer to literature why encrypted /boot is
> pointless?
[...]

Doesn't really need literature, just some rational thought.

People often confuse encryption with attestation. Try to explain
what security benefits you gain from keeping the contents of /boot
secret.

Sure, you don't want someone with physical access to the machine
changing the files in /boot in order to backdoor the system startup
process, but you don't need to encrypt the contents to gain that
property. Attestation (a.k.a. "secure boot") relies on cryptographic
signatures to avoid using files which have been altered, regardless
of whether /boot has been encrypted:

https://wiki.debian.org/SecureBoot

But take it a step further, if someone has extended physical access
to your machine, it's pretty easy to (depending on the device) add
a hardware keylogger, packet sniffer, other circuits which can even
supply the attacker with reverse-tunneled remote access once you've
unlocked and booted the machine.

Disk encryption is great (when properly implemented) to protect
sensitive information on your machine from prying eyes if it gets
stolen, but unless you're putting sensitive data in /boot why go to
the added trouble of encrypting it?
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Unlock LUKS with login/password

[Stephan Verbücheln]

Can you explain or refer to literature why encrypted /boot is
pointless?

Regards

PS: Let's for now ignore non-security benefits, e.g. that encrypted
/boot means that you do not have to decide on the size of your /boot
partition.


signature.asc
Description: This is a digitally signed message part

Re: Unlock LUKS with login/password

[Stephan Verbücheln]

That is also the main reason why I do not use automatic login. I need
to enter the password anyway.

Unfortunately, the same is true for smartcard login. An OpenPGP
smartcard would be perfect for both login (including SSH public key
auth) and unlocking the keyring, even better than a password, but that
has not been implemented.

Regards

Re: Unlock LUKS with login/password

[Marco d'Itri]

On Mar 08, Alexey Kuznetsov  wrote:

> 1) grub can ask for a login/password, then MD5 the text and unlock the LUKS
Forget about this part: encrypted /boot/ is pointless from a security 
point of view and this complexity does not belong in the boot loader.

Once you accept this then you will end up with a design very similar to 
https://www.freedesktop.org/wiki/Specifications/login-unlock/ .

So you would need to implement having Plymouth or whatever else storing 
the credentials in the kernel keyring and then probably a PAM module 
that will make them available to the rest of the stack (notably 
pam_gnome_keyring).

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Unlock LUKS with login/password

[Arnaud Ferraris]

Le 08/03/2023 à 17:11, Adrien CLERC a écrit :

Hello,


Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :

Hello!

I have an idea about how modern linux should work with encrypted LUKS 
partitions.


Hi,

I'm using LUKS for a long time on both my personal (desktop) and 
professional (laptop) computers. Since they are single user (me), I 
use autologin in the display manager, lightdm in my case. Because 
there is only one slot configured in LUKS, I'm sure this is me, so 
lightdm can autologin safely.


However, you are proposing to solve the case for multiple user 
computers. In that case, I would think about a much simpler design:


- Remember which slot was used to unlock the LUKS root partition

- Make a map with slot -> user to autologin

- Autologin that user on boot

No more passing password, no more password update headache. But only a 
root user can update the map "slot -> user".




The issue with this approach is that you still need to enter a password 
for session keyrings (such as gnome-keyring).
Ideally, the LUKS password would be forwarded to PAM (and automatically 
reused for logging in *and* unlocking the session keyring)


The issue is that the system (often plymouth on desktop/laptop setups) 
would then need to:

* unlock the filesystem
* initialize PAM straight away
* check the user password
* raise an error if either of the above fails, potentially locking the 
filesystem again if the password/encryption key is valid but does not 
match the selected user


Overall a nice idea, but not so simple to implement properly ;)

Cheers,
Arnaud


Adrien

Re: Unlock LUKS with login/password

[Agathe Porte]

Hi Alexey,

2023-03-08 16:45 CET, Alexey Kuznetsov:
> Right now on a system encrypted with LUKS, the first prompt you'll see is a
> grub passphrase to unlock the device, after OS boot you see a second prompt
> for login/password. This looks redundant.
>
> How about bypassing the second prompt and allowing grub to handle all
> security prompts including the login/password and unlocking the LUKS at the
> same time?

I disable the login password by connecting my user automatically on my
LUKS setup. It is a few clicks away in most DEs I would guess.

Did you consider this instead of implementing what you propose?

Bests,

Agathe.

Re: Unlock LUKS with login/password

[Alexey Kuznetsov]

On Wed, Mar 8, 2023 at 7:11 PM Adrien CLERC  wrote:

> Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :
>
> Hello!
>
> I have an idea about how modern linux should work with encrypted LUKS
> partitions.
>
> Hi,
>
> I'm using LUKS for a long time on both my personal (desktop) and
> professional (laptop) computers. Since they are single user (me), I use
> autologin in the display manager, lightdm in my case. Because there is only
> one slot configured in LUKS, I'm sure this is me, so lightdm can autologin
> safely.
>
> However, you are proposing to solve the case for multiple user computers.
> In that case, I would think about a much simpler design:
>
> - Remember which slot was used to unlock the LUKS root partition
>
> - Make a map with slot -> user to autologin
>
> - Autologin that user on boot
>
> No more passing password, no more password update headache. But only a
> root user can update the map "slot -> user".
>
> Adrien
>
Right. But you still have to remember passpharse and your main account
password. This is not about autologin. This is about unlocking your machine
LUKS with only login/password without having an additional passphrase to
remember.

Re: Unlock LUKS with login/password

[Alexey Kuznetsov]

On Wed, Mar 8, 2023 at 7:08 PM Agathe Porte  wrote:

> Hi Alexey,
>
> 2023-03-08 16:45 CET, Alexey Kuznetsov:
> > Right now on a system encrypted with LUKS, the first prompt you'll see
> is a
> > grub passphrase to unlock the device, after OS boot you see a second
> prompt
> > for login/password. This looks redundant.
> >
> > How about bypassing the second prompt and allowing grub to handle all
> > security prompts including the login/password and unlocking the LUKS at
> the
> > same time?
>
> I disable the login password by connecting my user automatically on my
> LUKS setup. It is a few clicks away in most DEs I would guess.
>
> Did you consider this instead of implementing what you propose?
>
> Bests,
>
> Agathe.
>

Yes I did. I did the same on my machine. I only type passpharse and initrd
have luks-key script, and gdm has autologin. But another notebook with LUKS
setup has multiple users, so autologin will not work. This is not about
autologin. This is about unlocking your machine LUKS with only
login/password without having an additional passphrase to remember.

Re: Unlock LUKS with login/password

[Adrien CLERC]

Le 08/03/2023 à 16:28, Alexey Kuznetsov a écrit :

Hello!

I have an idea about how modern linux should work with encrypted LUKS 
partitions.


Hi,

I'm using LUKS for a long time on both my personal (desktop) and 
professional (laptop) computers. Since they are single user (me), I use 
autologin in the display manager, lightdm in my case. Because there is 
only one slot configured in LUKS, I'm sure this is me, so lightdm can 
autologin safely.


However, you are proposing to solve the case for multiple user 
computers. In that case, I would think about a much simpler design:


- Remember which slot was used to unlock the LUKS root partition

- Make a map with slot -> user to autologin

- Autologin that user on boot

No more passing password, no more password update headache. But only a 
root user can update the map "slot -> user".


Adrien

Unlock LUKS with login/password

[Alexey Kuznetsov]

Hello!

I have an idea about how modern linux should work with encrypted LUKS
partitions.

Right now on a system encrypted with LUKS, the first prompt you'll see is a
grub passphrase to unlock the device, after OS boot you see a second prompt
for login/password. This looks redundant.

How about bypassing the second prompt and allowing grub to handle all
security prompts including the login/password and unlocking the LUKS at the
same time? It can be done with few steps:

1) grub can ask for a login/password, then MD5 the text and unlock the LUKS
device using this MD5 passphrase: md5(login+password) or using a simple
plain(login+password) string.

2) grub passing this information (login/password) to the kernel.

3) Kernel boots and passing (or password manager service, which can be part
of systemd) reads that data from kernel (/proc/cmdline) and rewrites it
(hide for security reasons).

4) password manager (systemd service) makes login manager (gdm) auto login
with provided data and unlocking session (gnome) keyring.

5) if the user updates the password (passwd, chpasswd), then the password
manager updates LUKS corresponding slot with md5(login+password) or
plain(login+password) passphrase.

Since LUKS1 supports 8 keys, we can support only 8 logins which can open a
drive and automatically login to the system. Also password manager has to
associate every user (UID) with LUKS device UUID and slot number for simple
key updates.Another option: we can use one SLOT0 or masterkey with a
different technique for encrypting keys and storing all users in the
encrypted list on ESP partition, this option has no user count limits.

I'm using full disk encryption (including /boot), except the ESP
(/boot/efi) partition for grub.img and other EFI binaries).

Theoretically it can work with legacy grub (stage2 compiled using modules
and grub.cfg (right?) which can be used to specify how we should unlock the
device using passphrase or login/password) and the EFI option can read all
configs from grub.cfg.

This is major changes to the linux password management. Can it be improved
and proposed as standard?

-- AK