UEFI Secure Boot

From Thomas-Krenn-Wiki
Jump to navigation Jump to search

Secure Boot is a part of the UEFI specification that should guarantee the authenticity of important software parts. Critical parts of the firmware, such as the OS loader, should only be executed if they have been authorized to do so in advance by a trusted institution. Therefore, rootkits are excluded that take root even before the operating system (OS) boots.

Cryptographic mechanisms (Signatures) avoid that untrusted software components are executed.

The key in the UEFI firmware verify the authenticity of, for example, bootloaders. A bootloader is only executed if it presents a valid "signature". [1] If a signature can not be verified or is not valid, the system can not start. For example, if the bootloader's signature does not match the one expected by the UEFI firmware, the system will not boot.

Current information

Advantages of Secure Boot

Using Secure Boot offers the following benefits:

  • Malware protection: Secure Boot is particularly effective at detecting rootkits that infiltrate critical parts of the operating system before the actual boot process begins.
  • The signature system allows specific software to be excluded, ensuring that only the desired software is used.


Disadvantages of Secure Boot

  • Above all, the fact that the Platform Key (PK; see below) is not under the end customer's control turns out to be a disadvantage.
  • For Secure Boot, all software components must be signed accordingly. This also applies to the associated hardware drivers for the firmware. For the subsequent installation of hardware systems, it must be made sure that the key from the hardware manufacturer of the new component is stored on the system.[1]

Choice of the operating system:

  • Alternative operating systems or Dual Boot configurations are made more difficult by Secure Boot. The fact that Linux installations can now only be performed after manually disabling Secure Boot in the UEFI firmware creates yet another obstacle to using Linux.
  • With Dual Boot, you would even have to constantly switch between Secure Boot and Non-Secure Boot in order to boot signed and unsigned operating systems.

Recommendations from Canonical

In a whitepaper from Canonical (blog.canonical.com), the following recommendations about Secure Boot are stated:

  • Factory default: At this time, it is not yet clear whether Linux can be used out of the box. With Secure Boot disabled by default, it would be easier to use Linux. However, this setting is controversial from a security standpoint, as it allows unsigned OS loaders to run.
  • For the use of Custom firmwares, there must be a possibility to reconfigure the keys in setup mode. A GUI or a user interface would be necessary. Given the limited user base, it is questionable whether firmware manufacturers will offer this feature.
  • The UEFI system should be shipped in Setup mode (see below), which allows the first signature keys to be added to the signature databases during OS installation. This prevents keys from being present on the system at the time of delivery—against the user's wishes—that would exclude other systems.

Secure Boot and Windows 8/Server2012

The Windows 8 Certification Requirements[2] - for the certification of hardware - prescribe the following things for the Secure Boot (page 188ff, excerpts from this):

  • Mandatory. Secure Boot must ship enabled - Secure Boot is activated per default.
    • Note II: Windows Server systems may ship with Secure Boot disabled, but all other provisions of this sub-requirement must be met - A deactivated Secure Boot is allowed for Windows Server.
  • Mandatory. When Secure Boot is Enabled, Compatibility Support Modules (CSM) must NOT be loaded - It is not possible anymore to boot in Legacy Mode (CSM) with activated Secure Boot.
  • Mandatory. Support for the UEFI "forbidden" signature database - A database to revoke/black list signatures must be supported.
  • Mandatory. Secure firmware update process - A secure firmware update process so that only signed firmware is installed. Furthermore, the Secure Boot Public Key is also protected.

Secure Boot and Linux

The above mentioned requirements for Windows 8 as well as Windows Server 2012 certified hardware have a larger influence on the use of common distributions with Secure Boot.

For information on the current approach to installation under Secure Boot, see the wiki article Installing Operating Systems on UEFI Systems.

When the Secure Boot issue first arose, distribution vendors responded as follows:

Technical function

Available key

Secure Boot relies heavily on the use of asymmetric cryptography. The root of trust is granted to the owner of a so-called Platform Key (PK). Another pair of keys - Key Exchange Keys (KEKs) - is also located in the firmware.

According to the specifications, the purpose of PK and KEK is the following:[3]

  • The PKs develop a base of trust between the platform owner and the platform firmware.
  • The KEKs develop a base of trust between the operating system and the platform firmware.

The key is located in the so-called "Signature Databases", that are databases in which they are stored. The following "trust databases" are used:[4]

  • Platform Key Database
    • Objects for modifying the KEKs.
  • Key Exchange Key Database
    • Objects for modification of KEKs.
  • Key Exchange Key Database
    • Includes those trust objects that are permitted to modify the allowed and forbidden signature databases.
  • Allowed/Authorized signature database
    • Includes those trust objects that are used for the signature verification of the firmware (for example signed firmware driver).
  • Forbidden database
    • Contains signatures that have been revoked and who are therefore no longer trusted.

Firmware mode

Without a PK, the UEFI system is in Setup Mode, in which the PK and KEK databases can be modified and populated without authentication. After the PK is loaded, the UEFI platform is in user mode, and remains there until the PK is removed (PK clear). In principle, both the PK and the KEK can be changed as desired in setup mode. In user mode, they can only be changed if they are signed with the firmware's current PK. According to the specifications, the following schema results: PK and KEK can only be changed if:[3]

  • In the setup mode, when PKpub is signed with its associated PKpriv.
  • In user mode, when the PKpub is signed with the current PKpriv of the firmware.

KEKs can always be read but only be written, when:

  • in setup mode (without authentication)
  • in user mode, when the KEK is signed with the current PKpriv of the firmware.

The owner of the PK is typically the "platform owner". The KEKs are under control of the OEM or OS-seller.

Microsoft demands for Windows 8 that Secure Boot is activated per default. A technet-article describes how the database keys interact with each other:[5]

The Key Enrollment Key database (KEK) is a separate database of signing keys that can be used to update the signature database and revoked signatures database. Microsoft requires a specified key to be included in the KEK database so that in the future Microsoft can add new operating systems to the signature database or add known bad images to the revoked signatures database.

The OEM stores the signature database, revoked signatures database, and KEK signature databases on the firmware nonvolatile RAM (NV-RAM) at manufacturing time. These signature databases must be included to boot Windows by using Secure Boot.

After these databases have been added, and after final firmware validation and testing, the OEM locks the firmware from editing, except for updates that are signed with the correct key or updates by a physically present user who is using firmware menus, and then generates a platform key (PK). The PK can be used to sign updates to the KEK or to turn off Secure Boot.

In summary, this leads to the following key points:

  • Microsoft possesses in KEK a key that allows to add new signed OS and to revoke software parts.
  • The signature databases are stored in the firmware's NVRAM at the time of manufacture.
  • Using a Platform Key (PK) provided by the manufacturer, you can update the KEKs or disable Secure Boot.

References

  1. ↑ 1.0 1.1 UEFI Secure Boot Impact on Linux (ozlabs.org)
  2. ↑ Windows 8 Hardware Certification Requirements (msdn.microsoft.com)
  3. ↑ 3.0 3.1 UEFI Specification page 1451 (uefi.org/specs)
  4. ↑ Deploying Secure Boot: Key Creation and Management (uefi.org)
  5. ↑ Secure Boot Overview (technet.microsoft.com)


Translator: Alina Ranzinger

Alina has been working at Thomas-Krenn.AG since 2024. After her training as multilingual business assistant, she got her job as assistant of the Product Management and is responsible for the translation of texts and for the organisation of the department.


Related articles

Creating Windows UEFI Boot-Stick in Windows
Show article
Installing Windows in UEFI-mode
Show article
Installing Operating Systems on UEFI Systems
Show article