Lennart Poettering announce new solution to manage users home directory as portable images with encryption.
I think it could be very useful for Librem5 opposed to full-disk encryption.
5 Likes
I have long thought that decrypting storage and logging in should be coupled for single user machines. Typically, encryption is done at the block level. This is ideal for full disk encryption. The problem is if you encrypt at the block storage layer for multiple users, than each user gets a fixed amount of disk space to work with, and changing it after it has been provisioned is usually very inconvenient. For single user machines, you just have to worry about splitting the storage space between the operating system and the user and a performance penalty for moving files in and out of a separate temp file system. Linux file systems support per-directory encryption, which is not used often. People normally want to protect the rest of the operating system for good reason. If the operating systemâs files are altered by booting another operating system, then there is no protection if someone tries to use that operating system and starts using their encrypted storage.
This feature would be simpler to implement without systemd if a few changes were made to the login prompt. Use the login user name and password to mount the userâs home storage or unlock their home directory. Maybe PureOS and Devuan can be merged.
Home directory encryption breaks things like ssh, which stores SSH keys inside of the home directory, which has to be readable by the sshd service. Even if you unlock the home directory before you log in via ssh, the sshd process might not have access to the key necessary for decryption.
I prefer signing the operating system partitions, and encrypting user data partitions. For a single user device, decrypting the disk can be considered identification and authentication, so no login prompt is needed. A emergency dial user can be configured outside of the /home partition, so it is signed like the rest of the operating system, and does not require decryption.
If you live in a country where you can be âtorturedâ by the government to get you to reveal your login password, this might not be such a good idea. Having the two decoupled can make for better deniable encryption.
This need not be the case for general implementations. Instead you can use a single disk-wide encryption key but you store that encryption key multiple times, encrypted separately using each userâs personal password. Perhaps though it doesnât actually work like that, and I can see some challenges with that approach.
(I donât know that âmultiple usersâ is all that relevant for the Librem 5 - apart from the emergency dial scenario.)
I think the biggest challenge with storage encryption on Linux (generally) for the kind of issues that are being discussed here is that there is no enforced discipline across applications and the operating system as to what gets stored where. So it is hard to pin down what âprotectionâ approach is appropriate for what parts of the system. Flexibility is both a strength and a weakness.
If you need to hide the use of encryption, then you need plausible deniability. Typically, effective plausible deniability is too inconvenient to use for most users because configuration data has to be provided by the user each time that they unlock the encrypted data, or, there has to be an additional step that is hidden, and when omitted, still results in a computer that works as expected.
Full disk encryption does not ask for user names, even if there are multiple users / passphrases. In the multiple user scenario, you have a key for each passphrase (for each user) and the OS tries to unlock each one with the passphrase provided from the user. This key only unlocks the disk-wide key. Since they each unlock the same disk-wide key, there is no problem if 2 users have the same passphrase by accident. However, if these individual keys were used for identity, then having the same passphrase has a chance of logging into another userâs account. So that may be why asking for a user name may still be a good idea. But in theory, the user name could still be selected or entered after the disk is unlocked, and we would be no worse off than with conventional login designs. Key management for storage works differently than user account management, so that may be why no one has done this. However, the operating system can be changed to account for both management concerns while managing both at the same time.
Ideally, you would have 2 factor authentication with a secure lockout mechanism, but it is kind of silly to have it for a phone. People are in possession of their phone more often than a security token, so it makes little sense to require a security token. Maybe something small on a keychain would work, but people often take their phones to bed and leave their keys by the door. However, if it is only required during a reboot, then this is not so bad.
Maybe with a Librem 5, you can take the smartcard out before lending your cell phone to someone, they can use the phone, as long as they do not reboot it or require anything that requires additional authentication, and you can put the smartcard back when they return it.
In Linux, there is a disciple to what gets stored where, but it was not designed with this application in mind. Andriod seems to have created a cleaner split between what Google controls, and what the user controls. As far as Android is concerned, you may as well be renting the phone from Google. Linux distributions assume that you control everything, and they are just packaging and distributing things for your convenience. So separations are there to separate boot code, configuration, programs, user data, libraries, temporary data, and service data. Unfortunately, service data and temporary data can be for the operating system or for the user.
1 Like