Encryption in Fedora is intended as a security solution for the user
A few days ago the news broke that Owen Taylor, creator of GNOME Shell and the Pango library, and a member of the Fedora Workstation Development Working Group, presented a plan to encrypt system partitions and users' home directories by default in Fedora Workstation.
The benefits to switch to encryption by default include data protection in case of theft of a laptop, protection against device attacks left unattended, maintaining confidentiality and integrity without the need for unnecessary manipulations.
For quite some time, the Workstations Working Group has had open requests to improve the state of encryption in Fedora, and in particular to get to the point where you can have the installer encrypt systems by default. In order to move forward, I have been working on a requirements document and a draft plan.
In a very brief summary, the plan is: Use upcoming btrfs fscrypt support to encrypt system and home directories. The system will be encrypted by default with an encryption key stored in the TPM and linked to the signatures used to sign the bootloader/kernel/initrd, providing protection against tampering, while the home directories will be encrypted using the password user login.
According to the draft plan prepared, they plan to use Btrfs fscrypt for encryption. For system partitions, the encryption keys will be stored in the TPM module and they will be used together with digital signatures to verify the integrity of the bootloader, kernel and initrd (that is, at the system boot stage, the user will not need to enter a password to decrypt system partitions).
When encrypting home directories, keys are scheduled to be generated based on the user's login and password (the encrypted home directory will be connected when the user logs into the system).
The timing of implementation of the initiative depends on the transition from distribution kit to unified kernel image UKI (Unified Kernel Image), which combines the driver for loading the kernel from UEFI (UEFI Boot Stub), the Linux kernel image and the initrd system environment loaded into memory in a file.
Without UKI support, it is impossible to guarantee the invariance of the contents of the initrd environment, in which the keys to decrypt the FS are determined (for example, an attacker can change the initrd and simulate a password request, to avoid this, verified it is necessary to load the whole chain before mounting the FS).
In its current form, the Fedora installer has an option to encrypt partitions at the block level with dm-crypt using a separate passphrase that is not tied to a user account.
This request represents a big shift from having Secure Boot as something we put a lot of effort into, but doesn't really do much, to something we heavily rely on to provide an extra layer of security for the user.
I would be interested to hear, among other things: * Are there any requirements that the document does not capture? * Are there other threats we should try to address? …
This fix points out issues such as unsuitability for separate encryption on multi-user systems, lack of support for internationalization and tools for people with disabilities, the possibility of attacks via bootloader substitution (a bootloader installed by an attacker can pretend to be the original bootloader and request a decryption password), the need to support framebuffer in initrd to request a password.
Finally if you are interested in knowing more about it, you can check the details In the following link.