Platform Firmware Resilience – (Part -1)

Reproduced from - https://2wisebit.wordpress.com/2025/02/02/platform-firmware-resilience-part-1/

Introduction

Modern computing systems consist of layered architectures. The software, including both operating systems and applications, is built on the underlying platform. This platform of hardware and firmware initializes the system, boots the system, and provides runtime services. Platform firmware, along with its configuration data, is absolutely central to trustworthiness and security in computing systems. Unfortunately, firmware is extremely privileged and very hard to fix. This makes it an attractive target for sophisticated attacks. A successful attack on the platform firmware can make a system inoperable or allow persistent malware to compromise low-level services, which then leads to data exfiltration, operational disruption, or other security breaches.

Why Platform Firmware Resiliency is Needed

• Critical Role of Firmware: Firmware boots up and initializes computing systems and delivers runtime services. It is the foundation of the system's security and functionality.
• High Privilege of Firmware: Firmware runs at the highest privilege levels, so it is the primary focus for the attacker. Compromised firmware can be used for persistent malware or a data breach with potential failure of the system.
• Patch Challenge: Firmware is difficult to patch or update; thus, vulnerabilities to known exploits remain unaddressed for quite a long period. Insecure updates leave one open to potential attacks more easily.
• Sophisticated Attack Landscapes: Advanced attackers aim at firmware in order to establish persistent access or to cause an interruption in services. Firmware attacks can often evade the more traditional security systems such as anti-viruses or firewalls.
• Persistence of Firmware Attacks: Malware can survive operating system reinstallation and hard drive replacement. This makes firmware attacks particularly dangerous and hard to detect.
• System Integrity at Risk: Compromised firmware can compromise the integrity of the whole system. That includes any operating system and applications. Malicious attackers can 'lever' access to low-level services to exfiltrate data or disrupt operations.
• Operational Disruption: Firmware corruption or attacks can make systems non-functional, causing downtime and loss. Such things are mainly concerning in relation to more critical infrastructure: healthcare, finance, or utilities, for example. Firmware-level attacks may allow for unauthorized access to sensitive data such as encryption keys and credentials. This may cause a data breach or non-compliance with the regulation.
• Lack of Visibility: Firmware is not often detectable using the traditional security tools. Long periods of undetected compromises occur without mechanisms for resilience.
• Regulatory and Compliance Requirements: There are numerous industries that require regulations, including strict guidelines about firmware practices such as GDPR, HIPAA, among others. Resilience provides compliance to such standards while preventing legal liability.
• Supply Chain Risks: Firmware vulnerabilities can be introduced at the manufacturing level or through third-party components. Resilience mechanisms mitigate risks from compromised supply chains.
• Protection of Critical Data: Firmware manages critical data like encryption keys and configuration settings. Resilience ensures that such data is safe and tamper-proof.
• Recovery from Attacks: Resilience enables systems to detect, respond to, and recover from firmware attacks. Without recovery mechanisms, systems may remain compromised indefinitely.
• Future-Proofing Systems: With increased sophistication in attack means, resilience enables and prepares systems to adapt to new emerging threats. Resilience provides an upstream approach towards firmware security.
• Building of Trust in Computing Systems: Resilience instils trust in the computing systems to achieve their desired capability on security and reliability. It ensures that systems operated as intended even under attacks and failures.
• Financial and Reputational Cost of Inaction: The costs associated with firmware attacks are way higher than that of inaction. Resilience reduces the risk of costly breaches, downtime, and recovery efforts.

Resiliency - Core Principles

1. Protect

Protection controls ensure that firmware code and platform-sensitive data that cannot be tampered with remain intact. Such include:

a. Secure Boot

• Execute Secure Boot where it checks the integrity and authenticity of firmware while booting.
• Firmware images should have crypto signatures when being executed.
• Only firmware upgrades from an authenticated source can be installed.

b. Firmware Update Integrity

• Firmware updates are cryptographically signed by the manufacturer or a trusted authority.
• Have secure protocols in place for publishing firmware updates, like HTTPS, in order to prevent man-in-the-middle attacks.
• Store firmware update packages in a safe and tamper-proof location.

c. Hardware-Based Protection

• Leverage TPM or HSM features to have the integrity of firmware and cryptographic keys be protected.
• Implement memory protection mechanisms, such as Intel Boot Guard, AMD Secure Boot, to inhibit modifications of firmware without permission.

d. Access Control

• Only grant access to firmware configuration interfaces, like UEFI settings, to authorized users.
• Implement RBAC (Role-Based Access Control) for limiting the privilege of updating firmware and for configuration changes.

2. Detection

Detection mechanisms can detect whether the platform firmware code or the critical data is compromised. These are:

a. Integrity Measurement

• Use cryptographic hashes or digital signatures to measure the integrity of firmware components.
• Store the integrity measurements in secure locations like TPM Platform Configuration Registers for later verification.

b. Runtime Monitoring

• Incorporate runtime monitoring tools that can identify anomalies in the firmware behaviour.
• Utilize hardware-based mechanisms like Intel TXT and AMD SME to verify the integrity of firmware during runtime.

c. Logging and Auditing

• Log firmware updates, configuration changes, and integrity checks.
• Protect the records to prevent leakage to attackers.

d. Firmware Attestation

• Use remote-attestation-based protocols to offer assurance related to the integrity of firmware and enable external entities to verify it.
• Ensure a secure communication channel for attestation in order to avoid spoofing and interference.

3. Recovery

Recovery mechanisms restore the integrity of platform firmware code and sensitive data in case of compromise. The methods include:

a. Backup and Restore

• Maintain robust backups of firmware images and sensitive configuration data.
• Guarantees secure recovery from tamper-resistant storage with an option for recovery.

b. Fallback Mechanisms

• Store two firmware banks, e.g., A/B partitions to have a fallback to a known good version of firmware at any given time.
• Make use of hardware-based recovery mechanisms such as Intel Boot Guard or AMD Secure Boot to recover into a trusted state.

c. Authorized Recovery

• Limit recovery of firmware only to authorized entities or systems.
• Apply cryptographic authentication in order to enable only valid recovery processes.

d. Manufacturer-Assisted Recovery

• Apply manufacturer-assisted recovery when local recovery is not permitted by the organization.
• Ensure that recovery activities cannot compromise security and do not weaken systems recovered.

Detailed Discussion on the principles

Protection

The?Protection?section focuses on safeguarding the firmware and critical data of platform devices against malicious attacks and unintended modifications. This includes firmware in management controllers, service processors, storage devices, network controllers, and graphics processing units (GPUs). Protection also extends to critical data, as its compromise can undermine platform integrity. Below are the key guidelines and components for ensuring robust protection:

Protection and Update of Mutable Code

This section outlines guidelines for protecting mutable firmware code, emphasizing principles such as authenticated firmware updates, integrity protection, and non-bypassability of security mechanisms.

Authenticated Update Mechanism

• Use of Authenticated Updates: Firmware updates must be performed using an authenticated update mechanism to ensure the integrity and authenticity of the update. For local updates, physical presence is required to prevent unauthorized modifications.
• Cryptographic Signatures: Firmware update images must be cryptographically signed using an approved digital signature algorithm (e.g., FIPS 186-4) with a minimum-security strength of 112 bits.
• Verification Process: The update process must first verify the authenticity of the key certificate used to sign the firmware update image. After verifying the key certificate, the process must validate the digital signature of the update image to ensure it has not been tampered with. Only updates with verified and authenticated signatures should be applied to the system.
• Integrity Assurance: This two-step verification process (key certificate and digital signature) ensures that only legitimate and unaltered firmware updates from trusted sources are installed.

Integrity Protection

• Flash regions containing device firmware must be protected against unauthorized modifications, except through authenticated or secure local update mechanisms.
• Integrity protections must be enabled continuously or triggered prior to any execution outside the update process to prevent tampering.

Non-Bypassability

• No mechanisms (e.g., development or diagnostic interfaces) should allow attackers to bypass the authenticated update mechanism.
• The device must prevent unauthorized rollback to earlier firmware versions with known security vulnerabilities.

Immutable Code Protection

• Protection of Immutable Code Immutable code is stored in non-upgradable memory, such as Read-Only Memory (ROM). Though immutable code is highly resistant to tampering, upgrading the field code is not feasible. There are certain considerations.
• Write Protection: When non-upgradable memory is utilized, the write protection mechanism must be immutable and may not be modified for unauthorized changes. The integrity of the code is ensured throughout the device lifecycle.
• One-Time Programmable (OTP) Memory: When OTP memory is used, the code is programmed at the time of manufacturing and cannot be modified later. OTP memory adds a layer of protection against post-deployment modification by eliminating the possibility of modification.
• Trade-Offs: Immutable and OTP memory offer excellent tamper resistance, but they forgo the ability to update fields. This design is suitable for critical firmware components that do not need frequent updates.
• Organizations can use immutable or OTP memory to protect crucial firmware code at its highest possible level and impose update restrictions in the process.

Runtime Critical Platform Firmware Protection

Running in RAM:

o??? If firmware is copied into RAM for running, its modification by software needs to be prevented. This could be done with hardware-enforced memory protection mechanisms.

o??? Alternatively, the firmware must finish its execution without any interference during running time, and no executing software is permitted till then.

RAM-based Temporary Data Store:

o??? If such critical firmware relies on the RAM for temporary data storage, then such a memory section should not be accessible by applications without control.

o??? Thus, trusted memory sections or hardware-based isolation techniques, such as Intel SGX, ARM TrustZone, shall have to be used.

Running in Cache:

• When firmware or critical data is cached, it must be protected from unauthorized access or modification by software.
• Cache isolation mechanisms, such as partitioning or hardware-enforced access controls, should be implemented to prevent untrusted software from accessing or altering cached firmware or data.
• Cache integrity checks can be used to detect and prevent tampering during runtime.

Avoid Interference:

o??? Software must not be allowed to alter, deny execution of, or otherwise interfere with the operation of critical firmware.

o??? Privilege levels, MPUs, or secure enclaves can enforce this.

Trusted Memory:

o??? The role of trusted memory is very important in runtime protection because it has allowed a secure environment for firmware execution and data storing.

o??? This mechanism will ensure critical firmware and all data associated with it are not compromised by tampering or access by untrusted software.

o??? Mechanisms like trusted memory which might be through hardware-based encryption of memory or even access control help to harden the firmware against runtime attacks.

Protection of Critical Data

This section deals with protection of critical data accessed by the devices. When such data are allowed to change without authorization, functionality and security may be put at risk. This must, therefore, not be allowed. To this effect, critical data must also be protected and provision made for making alterations to it.

The basic guiding principles are:

o??? Controlled Modifiability:

Critical data must be changeable only through the device itself, or through well-defined interfaces provided by the device firmware, for example, APIs and standards-based interfaces.

o??? Dependent Symbiont Devices:

Devices that are dependent on a host may have to rely on the host device to enforce this requirement.

o??? Validation of Updates:

Updates to critical data shall be validated, with either the device or host device, to ensure that the data is validly formed. This includes:

Range or Bounds Checking:?It ensures that data falls within defined limits.

Format Validation:?This validates the form and format of data.

Update Authorization:

Important data updates should be authorized through a Platform Administrator, or using an authorized mechanism of firmware updates.

Authentication may also be carried out through techniques like digital signature for authenticating integrity and authenticity of important data before its utilization.

o??? Factory default settings need to be secured at the same level as firmware code.

Such defaults should be updatable with the same security mechanisms as for firmware updates.

Examples of Sensitive Data:

o??? Fuse Settings:

OTP fuses store sensitive data such as cryptographic keys, device configuration, or security policies. Once programmed, fuses are not changeable, thus the storage is tamper-proof.

o??? ROM Tables:

These tables will store immutable information, like bootloader settings or hardcoded parameters for a particular piece of hardware. Once written, these tables will be not be changed since they cannot be altered.

o??? User Keys:

Such data will include, for example, cryptographic keys used in encryption, decryption, or authentication and shall be securely stored and managed. Typically, such keys are stored on secure hardware modules, such as in TPMs or HSMs.

Secure Storage and Access:

o??? Critical data must be stored in trusted memory regions or hardware-isolated areas, where unauthorized access is not possible.

o??? Access to critical data should be limited to authorized firmware components or processes.

Recovery of Critical Data:

o??? Critical data should be recoverable from secure backups or factory defaults in case it is corrupted.

o??? The recovery mechanisms should ensure that only authenticated and validated data is restored.

Detection

The?Detection?section outlines mechanisms to identify unauthorized changes to device firmware and critical data before they can negatively impact the device's functionality. These detection mechanisms are particularly essential for devices lacking strong firmware protections, and they also help ensure the effectiveness of existing protection mechanisms. Below are the key guidelines for detection:

Detection of Corrupted Code

Detection mechanisms are critical for verifying the integrity of firmware and ensuring that unauthorized or corrupted firmware does not compromise the device.

• Corrupted Firmware Detection: Mechanisms must be in place to verify the integrity of firmware during the boot process using the Root of Trust for Detection (RTD). These mechanisms should detect unauthorized or corrupted firmware that could damage the device or inject malware.
• RTD Resilience: A successful attack on firmware should not compromise the RTD or the mechanisms required to detect corruption in the firmware.
• Validation Techniques:

The firmware should be authenticated and genuine before execution and not unauthorized or corrupted to gain access to the system. The most important rules are as follows:

o??? Digital Signature Verification:

Verify using an accepted digital signature algorithm like RSA, ECDSA, or cryptographic hash such as SHA-256 before executing outside the RTD to ensure firmware integrity.

o??? Verification Procedure:

Certificate Validation:?To begin with, the updating process should verify whether the used signing certificate to sign the firmware is authentic. This should include a verification of the certificate chain and ensure it comes from a trusted authority.

Verification of Firmware Signature:?The update process after ensuring the certificate authentication should validate whether the digital signature of the firmware image matches that of the same signed hash. It would, therefore, tell whether the firmware has been altered or not.

o??? Symbiont Devices:

Symbiont devices (Devices that rely on a host). In this kind of device, the host can be expected to check firmware integrity.

A stand-alone boot-capable symbiont device is expected to validate its own integrity prior to any firmware execution.

o??? Hardware-based Devices:

The hardware-based devices such as FPGAs or CPLDs sometimes may not support cryptographic methods.

In such situations, mechanisms based on hardware should be implemented to identify load failures or corruption based on checksums, parity checks, or error-detection codes.

o??? Role of Certificates:

In the authentication process, certificates hold a very high role. Certificates ensure that the update is valid and reliable. Certificates provide a link between the firmware image and the source in a trusted link.

The certificates are to be so stored and kept that they must not be easily exploited for illicit operations without valid authorization. At the time of validation, either expired or the revoked certificates shall be rejected.

• Corruption Recovery: If corruption is detected, the RTD or CTD (Critical Trust for Detection) should trigger a recovery process to restore the device's firmware to an authentic version.
• Corruption Notifications and Logging: The detection mechanism should send notifications and log events when corruption is detected.
• Policy-Based Detection: The detection system may use policies set by the Platform Administrator to define actions triggered by detected corruption.

Detection of Corrupted Critical Data

This section emphasizes the detection of corrupted critical data in platform devices, ensuring that data integrity is maintained to prevent operational failure or security vulnerabilities.

• Integrity Checks on Critical Data: The RTD or CTD must perform integrity checks on critical data before it is used. This could involve: Validating the data against known valid values. Verifying the hash of the data storage to ensure consistency.
• Use of Watchdog Timers: As an alternative or supplement to integrity checks, the RTD or CTD may use watchdog timers to detect potential corruption of critical data. Watchdog timers are hardware or software mechanisms that track the system's operation and can trigger a recovery action when an anomaly is detected.

Read More

• https://github.com/intel/pfr-wilson-city
• https://www.latticesemi.com/PFR
• https://tianocore-docs.github.io/Understanding_UEFI_Secure_Boot_Chain/draft/looking_forward__platform_firmware_resiliency/
• https://youtu.be/4Z0J4PjCXbc
• https://trustedcomputinggroup.org/resource/tcg-architecture-overview-version-1-4/
• https://csrc.nist.gov/pubs/sp/800/147/final
• https://csrc.nist.gov/pubs/sp/800/147/b/final
• https://developer.arm.com/documentation/den0128/latest