Full Disk Encryption is planned to be introduced in the forthcoming release candidate of the Aeon Desktop to enhance data security for its users. The feature...

Full Disk Encryption is planned to be introduced in the forthcoming release candidate of the Aeon Desktop to enhance data security for its users.
The feature is expected to be included in the upcoming Release Candidate 3 (RC3).

Full Disk Encryption is designed to protect data in cases of device loss, theft or unauthorized booting into an alternative operating system.
Depending on the hardware configuration of a system, Aeon’s encryption will be set up in one of two modes: Default or Fallback.

Default Mode

The Default Mode is the preferred method of encryption provided the system has the required hardware. This mode utilizes the Trusted Platform Module(TPM) 2.0 chipset with PolicyAuthorizeNV support (TPM 2.0 version 1.38 or newer). In this mode, Aeon Desktop measures several aspects of the system’s integrity. These including:

  • UEFI Firmware
  • Secure Boot state (enabled or disabled)
  • Partition Table
  • Boot loader and drivers
  • Kernel and initrd (including kernel command line parameters)

These measurements are stored in the system’s TPM. During startup, the current state is compared with the stored measurements. If these match, the system boots normally. If discrepancies are found, users are prompted to enter a Recovery Key provided during installation. This safeguard ensures that unauthorized changes or tampering attempts are flagged.

Fallback Mode

The Fallback Mode is employed when the necessary hardware for Default Mode is not detected. This mode requires users to enter a passphrase each time the system starts. While it does not check system integrity as comprehensively as Default Mode, Secure Boot is strongly recommended to ensure some level of security, confirming that the bootloader and kernel have not been tampered with.

Contrary to initial concerns, Default Mode is not less secure than Fallback Mode despite not requiring a passphrase at startup. The strong integrity checks in Default Mode protect against attacks that could bypass normal authentication methods. For example, it can detect changes to the kernel command line that could otherwise allow unauthorized access. Furthermore, it safeguards against modifications to initrd thereby preventing potential passphrase capture in Fallback Mode.

Secure Boot, while optional in Default Mode due to the comprehensive integrity checks, is critical in Fallback Mode to maintain system security. Disabling Secure Boot in Fallback Mode increases vulnerability to tampering and attacks aimed at capturing the passphrase.

Aeon’s implementation of Full Disk Encryption provides robust security options tailored to the capabilities of users’ hardware. By offering both Default and Fallback modes, Aeon ensures that all users can benefit from enhanced data protection.

The inclusion of this feature in RC3 marks a significant step forward in safeguarding user data against potential threats.
Aeon users are encouraged to read and bookmark the Aeon Encryption Guide.

More Information about openSUSE:

Official

Fediverse

(Image made with DALL-E)

  • boredsquirrel@slrpnk.net
    13·
    4 months ago

    The word is measured boot I think. Full disk encryption is already possible with standard LUKS.

    Really really great to finally see Linux having these security features by default.

    They are still not remotely comparable to a Pixel with GrapheneOS but we are getting there

    • Phoenixz
      1·
      4 months ago

      I love me some LUKS. What features are .issing from it, in your view?

      • boredsquirrel@slrpnk.net
        4·
        4 months ago

        Hardware + tightly integrated software.

        Secure element that blocks brute forcing of passwords, pin codes or encrypted storage

        • Phoenixz
          3·
          4 months ago

          I wonder how you would block bruteforcing the encrypted storage. Once someone got their hands on your device for long enough to clone, you’re done and you get into the “how much is the data worth to you” territory.

          And it better be worth a lot because bruteforcing LUKS? Good luck. I wonder if even the NSA would be capable of that.

          There are issues with booting from unencrypted storage but that isn’t really a LUKS issue, though.

          TPM has shown to be quite vulnerable as well, with for example the usually hardware flaws where, IIRC, TPM would sent the security certificates in plan text over data lines somewhere.

          Either way, I don’t see my of these items as something great that LUKS doesn’t have.

          • boredsquirrel@slrpnk.net
            1·
            4 months ago

            Awesome when Google Pixel phones are fort knox and then send traffic to Google servers over TLS.

            Or IPC to whatever garbage these people install