Enhancements to UEFI

The SecEP ensures that the CPU only executes a trusted BIOS, and the BIOS relies on the SecEP to protect security-critical data — this is the foundation that Samsung Galaxy Book4 Secured by Knox builds upon to provide best-in-class laptop PC security. In this chapter, we describe how this foundation is used improve on the standard UEFI boot process.

Secure Boot Configuration Recovery

The security of the UEFI boot process depends on the integrity of both the firmware and its configuration data. Secure Boot configuration data is particularly security-sensitive, since it forms the basis to make decisions such as:

• Whether Secure Boot is enabled
• Which keys to use for Secure Boot
• Which OS images have been revoked

Therefore, protection of Secure Boot configuration data is critical to establish the root of trust. In addition, these Secure Boot settings need to be recovered from a “known-good” backup if corruption is detected.

The section on Hardware-backed trust details how UEFI code is protected and auto-recovered from a backup if corruption is detected. However, the same techniques for code can’t be applied for configuration data, since configuration data can be modified after the BIOS signatures are generated. Thus, it isn’t possible to generate a signature for configuration data during compilation, and validate it using the same UEFI code validation flow.

Samsung’s Secure Boot Configuration Recovery addresses this shortcoming.

As part of the UEFI standard, security-critical boot configuration data is written to flash as UEFI Variables. UEFI Variables are stored as key-value pairs, where each key consists of a Globally-Unique Identifier, or GUID, and a variable name. Boot configuration data is typically modified by an administrator through the BIOS menu. These “known-good” values are backed up in SecEP flash storage.

An attacker can attempt to subvert Secure Boot by modifying or corrupting on-disk variables with inexpensive flash writing tools. For example, they can disable Secure Boot entirely, or change the public keys used to verify signatures. The Secure Boot Configuration Recovery feature detects such out-of-band writes and also recovers these variables to the previously backed up values.

Detecting and recovering from unauthorized offline writes to Secure Boot configuration

First, integrity information for the Secure Boot UEFI variables is stored on the SecEP’s flash storage, protecting and isolating it from software and hardware-based tampering. This information is cryptographically-protected using the Master Storage key kept within the SecEP. This key authenticates the variable’s content, name, and GUID.

During boot, the SecEP provides integrity information to the BIOS. The BIOS uses this information to validate the Secure Boot UEFI variables. If an integrity corruption is detected, the BIOS automatically discards any corrupted values, and reverts all protected variables back to their “known-good” values. Once the SecEP completes the recovery, the user is notified through a BIOS notification before the boot process is continued.

Tamper Alert

The Tamper Alert feature alerts admins of certain security-critical events that indicate tampering with security-critical data or code in any layer of the software stack. Specifically, this feature deals with tampering that the system can’t automatically recover from. Such events typically need admin action to restore the system to a good state. Tamper Alerts are presented to the admin in a protected pre-boot environment. This feature can also require admins to acknowledge alerts by entering their BIOS password before allowing the system to boot up.

Tamper tracking is handled through the SecEP’s Tamper Flag, an indicator used to determine if there were any new policy violations on the device. The Tamper Flag is stored on the SecEP’s flash storage, isolating and protecting it from any compromises on the OS.

Authorized software, including the BIOS and System Management Mode, can request the SecEP to turn on the Tamper Flag when they detect tampering, such as during the following scenarios:

• When unauthorized writes to protected, read-only System Management Mode regions are detected. This typically indicates an exploit attempt within System Management Mode.

• When security-critical OS components, such as the event logging service, are detected to have been uninstalled. This typically indicates malware.

• When invalid policies for system management interrupt call protection are detected. This typically indicates attempts to tamper with the system’s security configuration.

• When the Windows Platform Binary Table is disabled. This typically indicates malware.

Tamper Alert can be configured to require either admin or user confirmation whenever a violation occurs, before the BIOS starts the OS. During system start up, the BIOS Bootloader reads the Tamper Flag state from the SecEP. If this flag indicates that corruption is detected:

• If admin confirmation is required, then the admin BIOS password must be entered to proceed with boot, or

• If user confirmation is required, then the user can acknowledge the alert by choosing to continue with the boot process.

In both cases, the device will continue to display a message indicating that a corruption was detected during system boot, until the Tamper Flag is cleared.

By providing a consistent method for different components to report a corruption, Tamper Alert ensures that IT admins and device users are made aware of compromises when they happen, thus providing enterprises an opportunity to trigger a response more quickly and effectively.