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 the Knox security platform 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.

BIOS 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
• Whether the device has certain debugging features enabled that may be abused by a physical attacker to modify in-memory BIOS code or data,
• Whether the device is classified as being in factory, which enables certain special operations during manufacture-time that can be abused by physical attackers.

Therefore, the protection of such UEFI configuration data, and the ability for code to be recovered from a “known-good” backup if corruption is ever detected, is critical in order to establish the root of trust.

The section on Hardware-rooted 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.

Samsung’s BIOS Configuration Recovery feature addresses this shortcoming.

As part of the UEFI standard, security-critical boot configuration data is written to flash as UEFI/BIOS Variables. UEFI Variables are stored as key-value pairs on the SPI flash storage, where each key consists of a Globally-Unique Identifier, or GUID, and a variable name. UEFI 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 variables on the SPI flash storage with inexpensive flash writing tools. For example, they can disable Secure Boot entirely, or change the public keys used to verify signatures. The BIOS Variables Protection and 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 tampering by untrusted software. 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.

Protecting the BIOS Password

The BIOS password is the basis for BIOS authentication, and is therefore particularly security-critical and important to recover if corrupted by hardware failure or malicious activity. The BIOS password hash is itself a UEFI variable. To offer additional isolation, robustness of storage, and recovery guarantees, the BIOS password hash is backed up in the SecEP’s internal EEPROM storage. The SecEP’s internal storage is very small, and is therefore used to store only the most security-critical data. If corruption of the BIOS password hash is detected, recovery happens from the SecEP’s internal storage (instead of the SecEP Flash Storage).

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 Alerts are typically indicative of actions by malware or physical attackers that impact security guarantees on the Samsung Galaxy Book with the Knox security platform. For example, Tamper Alerts are raised when there are attempts to boot unauthorized firmware, if there are writes to protected SMM memory, or if corruption of security-critical BIOS configuration data is detected.

These types of attacks can lead to malicious actions such as attempts to persist on disk, manipulated security-critical configurations, privileged escalation, disabled security event logging, bypassed access control, and tampered storage.

Samsung Galaxy Books with the Knox security platform provide tamper alerts for the most common cybersecurity attacks. Each alert is mapped to the MITRE ATT&CK knowledge base, a global and industry-recognized cybersecurity resource providing detailed explanations of the tactics and techniques used in malicious activities, including:

• T1542 (Pre-OS Boot)
• T1565 (Data Manipulation)
• T1068 (Exploitation for Privilege Escalation)
• T1562 (Impair Defenses)
• T1489 (Service Stop)
• T1110 (Brute Force)
• T1490 (Inhibit System Recovery)

For a list of supported Tamper Alerts, see Event Integration with Windows Event Viewer.

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 SMM (System Management Mode), can request the SecEP to turn on the Tamper Flag when they detect tampering.

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.