Portal:Aeon/Encryption

Encryption

Overview

Aeon utilizes full disk encryption (FDE), which protects your data if your device is lost, stolen, or booted into an alternate operating system.

Depending on your hardware, Aeon's encryption will be set up in one of two modes: 1. Default Mode: Includes strong system integrity checks and automatically unlocks your encrypted disk partition.; 2. Fallback Mode: Requires a passphrase to unlock the encrypted disk partition, and has weaker or no system integrity checks.

Recommended Hardware

For Installation with default mode, Aeon must detect a Trusted Platform Module (TPM) 2.0 chipset with PolicyAuthorizeNV support. This means the chipset must support TPM 2.0 version 1.38 or newer.

If Aeon doesn't detect the recommended hardware, a notification will appear informing you that encryption is being set up in fallback mode.

Default Mode

In this mode, Aeon measures the following aspects of your system's integrity and stores those measurements in your device's TPM.

Secure Boot state (enabled or disabled)
Partition Table
Boot loader and drivers
Kernel and initrd (including kernel cmdline parameters)

These measurements will automatically update when the system updates.

On boot, the system compares it's current state to the measurements stored in the TPM.

If the measurements match, the encrypted disk partition unlocks automatically and the system boots.

If the measurements are mismatched, you will be asked for your recovery key, if this happens, it's possible your system was tampered with.

Recovery Key

Since updates are applied automatically, it's recommended to keep your recovery key at hand to avoid unexpected lockouts that prevent you from working.

NOTE: The keyboard layout used when entering the recovery key is typically the US layout. Characters may differ to the keys printed on your keyboard. This behavior can vary between devices and updates.

If you were prompted for the recovery key, only enter it if you can explain why the TPM measurements are mismatched.

Why the measurements might be mismatched:

The Secure Boot state was changed
Intentional changes were manually made to the boot loader, kernel or initrd

If you cannot explain why the TPM measurements are mismatched, you should examine the measured aspects of your system for signs of tampering before entering the recovery key.

Commonly changed aspects to check first:

Changes to the Secure Boot state
Changes to the kernel cmdline parameters

Remeasuring Boot Integrity

Manually remeasuring boot integrity should only be done if you can explain why your system requested the recovery key.

Usually its as simple as running:

user $ sudo sdbootutil update-predictions

Sometimes your recovery key is needed:

user $ sudo sdbootutil --ask-pin update-predictions

NOTE: When entering the recovery key, it will not be visible. Entering the wrong key will result in an error. If you enter the wrong key too many times, your TPM may lock you out for an unknown amount of time, as the timeout duration is determined by your hardware.

You can optionally use:

user $ sudo PIN=key sdbootutil update-predictions

This should only be used for debugging and testing purposes as bash history will leave your recovery key visible in plain text.

For full TPM re-enrollment visit Portal:Aeon/Encryption/Advanced#Complete_re-enrollment_of_TPM2.

Fallback Mode

In this mode, Aeon will not be able to measure your system's integrity before attempting to unlock the encrypted disk partition.

It's strongly recommended that Secure Boot is enabled as this will provide some confirmation that the boot loader and kernel have not been tampered with.

During installation you will asked to enter a passphrase, which will be required every boot to unlock the encrypted disk partition.

You will also be provided a recovery key in case the passphrase is forgotten.

If you forget the passphrase you set, a new one can be created Portal:Aeon/Encryption/Advanced#Adding_additional_credentials.

FAQ

"Default mode unlocks the disk without a passphrase, isn't that less secure than Fallback Mode?"

No, because default mode mode provides strong system integrity checks, it protects your system from attacks which would otherwise make it trivial to bypass your usual username and password authentication.

For example, most normal Linux systems can have their authentication bypassed by changing the kernel cmdline to boot with the parameter init=/bin/bash. In default mode, such a change would be detected and prevent the encrypted disk partition from being automatically unlocked.

Default mode's integrity checking also protects against alterations to the initrd, which could potentially be used by an attacker to capture the passphrase used by fallback mode.

"Why is Secure Boot strongly recommended for fallback mode, but not default mode?"

Secure Boot uses signed boot loaders, kernels, and kernel modules to establish a 'chain of trust' between a systems UEFI firmware and the boot process.

This can cause complications, with third-party kernel modules or even moving between different Linux distributions.

As default mode establishes a strong 'chain of trust' between a more comprehensive list of key boot components, the use of Secure Boot in default mode can be optional.

If Secure Boot is enabled in default mode, it will be measured and expected to stay enabled. Likewise, if it's disabled, it will be expected to stay disabled.

As fallback mode has no such measurements of boot components, Secure Boot should be enabled.

Disabling Secure Boot in fallback mode leaves your system vulnerable to tampering, including attacks which may capture your passphrase when entered.

Advanced Topics

For advanced topics, including details about the default key slot layout and how to add alternative credentials (Passphrases or FIDO2 keys) see Portal:Aeon/Encryption/Advanced.