Firmware Update Mechanisms
Firmware protection requires that only authentic and authorized firmware updates be applied to platform devices. Firmware update mechanisms must check for both authenticity (that the update comes from a trusted source) and authorization (that updates are allowed by the system owner). These mechanisms are divided into authenticated update mechanisms and authorized update mechanisms.
Authenticated Update Mechanism
Authentic update mechanism guarantees that an image of firmware update is legitimate to be applied. It occurs through the use of digital signatures. It is based on a Root of Trust for Update (RTU).
Main Elements of an Authentic Update Mechanism
- Root of Trust for Update (RTU): It involves incorporation of a signature validation algorithm. It holds a storage of keys where the public one, which confirms the correctness of the firmware's signature, is stored. The RTU is resistant to unauthorized modification.
- Signature Validation Process: The firmware image is digitally signed by an authorized entity (e.g., device/system manufacturer). The RTU checks the signature by verifying it using a public key found in its key store. If the key store does not have a direct public key, it may hold a hash of the public key. Such mechanisms hash the public key provided and compare this hash with the stored one before using the presented public key to validate the firmware signature.
- Key Compromise Handling: If the private key for some public key that was stored in the key store is compromised, then an attacker can sign malicious firmware and spread it out. Prerequisites for recovering keys include, but are not limited to: Key hierarchies: Using a hierarchical key structure to invalidate compromised keys. Key store updates: Updating or replacing keys as part of the firmware recovery process.
Authorized Update Mechanism
Whereas authentication ensures that an update is legitimate, authorization ensures that the update is permitted by the system owner. Several methods exist to authorize firmware updates.
- User-Initiated Updates: Users can manually update firmware using vendor-supplied tools. Updates can be done from external media, such as USB drives, or through software utilities running on the operating system. Updates can be applied immediately or scheduled for the next system reboot. To ensure stability: The updated firmware must be compatible with critical system data. If necessary, it should update or reset critical data to prevent compatibility issues.
- Managed Updates: System administrators can remotely update firmware using hardware/software-based management tools. This provides for central updating and deployment of updates across a number of systems.
- Rollback Mechanisms: If an update process includes both authentication and version control, rollback to a prior firmware version could be possible. Rollback can be physically controlled to prevent malicious installation of known vulnerable firmware by attackers.
- Manual Recovery: Firmware can become corrupted or cease to function, and users can manually recover by: Physically swapping the firmware to a known good version. Using a boot time recovery mechanism where reinstallation is possible.
- Automatic Recovery: Some systems can detect firmware corruption and automatically establish the backup firmware image. The backup is stored elsewhere, such as: A second flash memory chip. A protected storage partition.
Secure Local Update
Although authenticated update mechanisms are the recommended mechanism for firmware updates, secure local update mechanisms are also supported by some platforms. These are quite useful when authentic or automated update mechanisms are unavailable, like in cases of firmware corruption or rollbacks, which are not possible through regular update mechanisms.
Key Features of Secure Local Update Mechanisms
- Physical Presence Requirement: Update procedure on the machine will only happen if there's a clear unambiguous physical presence for the said update. For the protection of the system, especially against distant attacks, a mechanism must exhibit that a user with physical presence authorized the updating process. On the other hand, remote accesses or accesses where malware can get into the processes will not validate the physical presence.
Use Cases:
- Recovery by Firmware: One can recover an invalid firmware image through a safe local update procedure if other available update mechanisms are not working—for example, in authenticated update and automated recovery cases.
- Roll-back Updates: Using this mechanism enables a physically available administrator to move to an older firmware image within devices that roll back through standardized update channels unavailable for them.
- Remote Attacks: In order to avoid remote exploitation, these systems need to be designed in a way that verification of physical presence occurs during an update. Then no malicious body can remotely exploit an update.
- Vulnerability to Physical Attacks: If the device offers secure local updating, then vulnerability arises due to rogue administrators and others who will have physical access to the system.
Additional Protections: Some of the other physical, environmental, and technical security measures. While this document does not address these additional protections, they should be implemented to secure devices with local update mechanisms.
Firmware Authorization Mechanisms
Some administrative actions, such as modifying firmware settings or performing software recovery (e.g., restoring backups), may require platform-level authorization. This ensures that the entity requesting a change has the appropriate authorization to perform the action. Authorization mechanisms vary based on the environment and user type.
Authorization in Different Environments
- Large Organizations / Data Centers: Typically, a platform administrator manages the platform remotely using credentials specifically provisioned for administrative control.
- Smaller Enterprises or Consumer Devices: There may not be a remote platform administrator. In such cases, users may be required to assert authorization locally, often by confirming actions in person.
Unambiguous Physical Presence
- In certain systems, Unambiguous Physical Presence (UPP) is required to confirm authorization for critical actions. This ensures that only a physically present user can authorize significant changes, such as recovery actions or firmware modifications.
- UPP guarantees that malware cannot impersonate a physical user's authorization. It involves confirming that a local user has issued a command or authorized a change directly. This is crucial for preventing unauthorized manipulation by malicious software.
Ensuring Physical Presence Verification
Verifying Unambiguous Physical Presence is complex and requires dedicated hardware or mechanisms. Some methods for confirming UPP include:
- Physical Buttons or Jumpers: These can directly indicate the presence of a user and enable actions only when a physical interaction occurs.
- Trusted Paths: A trusted path between mechanisms that verify physical presence and the platform is essential to prevent tampering by malware. This can involve using I/O devices (e.g., keyboard, touchpad) or internal buses to create secure communication pathways between the user and platform. Integrity of the platform must be verified (e.g., early in the boot process) to ensure that the platform is in a trusted state before processing the user's action.
- Service Processors (e.g., EC, BMC): Some platforms may provide trusted paths through dedicated service processors, ensuring secure verification and authorization of the action from physically present users.
Vulnerabilities and Considerations
- Vulnerabilities with Physical Access: Devices that rely on Unambiguous Physical Presence are susceptible to attacks if an attacker gains physical access to the system. This could include physical manipulation of the device or spoofing the presence verification process.
- Physical Security: Strong physical security measures are required to protect platforms that use UPP, especially in environments where physical access cannot be fully controlled (e.g., consumer environments).
- Non-bypassability: To satisfy non-bypassability guidelines, the platform must ensure that trusted paths are protected from malware or unauthorized influence during any authorization processes.
Network-Assisted vs. Local Recovery
Recovery from corruption can typically occur in two ways: local recovery or network-assisted recovery. Each method offers different benefits and is suited for various scenarios.
- Expedient:?It provides the fastest recovery solution, especially in environments where network connectivity is unavailable or unreliable.
- High Customer Satisfaction:?Local recovery is preferred in many cases due to its self-sufficiency, as it does not require external resources or connections.
- Limitations:?The device's storage capacity can sometimes prevent local recovery, particularly if the necessary recovery data exceeds available space.
Network-Assisted Recovery
- When Local Recovery is Not Feasible:?In cases where local recovery isn't possible due to storage constraints or other issues, network-assisted recovery provides an alternative.
- Secure Implementation:?This approach must be implemented securely, using methods like encryption, digital signatures, and secure transport to ensure the integrity of the recovery process and protect sensitive data.
- Recommended Approach:?It is advisable for devices to support both local and network-assisted recovery, as this dual capability enhances the overall resiliency of the system.
Automated vs. Manual Recovery
Recovery can be categorized into three types based on the level of user involvement during the process:
- Fully Automated Recovery: No User Interaction:?The system automatically detects corruption and initiates the recovery process without requiring any input from the user. Fast Recovery at Scale:?This method is especially beneficial in large-scale deployments or widespread attacks, as it allows for rapid recovery with minimal downtime. Drawbacks:?It may not be supported by all systems or desired by all users. Some systems may require administrative credentials or authorization to continue recovery, which may not be feasible for automated recovery processes.
- Partially Automated Recovery: Automatic Initiation:?The recovery process begins automatically but requires user interaction at certain points, such as confirming an action or providing additional input. Balance:?This method strikes a balance between automation and user control, ensuring that recovery can proceed quickly while still involving the user when needed.
- Manual Recovery: User Initiation:?The recovery process requires the user (often a platform administrator) to manually initiate recovery. Use Cases: Preferred by some users who want to be informed of a system failure before the recovery process proceeds. Useful in cases where forensic analysis is needed, allowing the administrator to gather critical information before taking further steps.
Policy Considerations
- Administrator-defined Policies:?These policies govern how recovery occurs, including any privilege requirements or constraints on firmware versions that can be used during recovery.
- Potential Issues with Policies: If the firmware version in the policy is the same version that was attacked, simply restoring it could lead to a cycle of attack and recovery. Policies may be a target for attack, so recovery mechanisms should account for the possibility that these policies may not be available during the recovery process. Multi-step recovery may involve certain policies that are only fulfilled at the end of the process, which could create challenges if recovery is interrupted or only partially completed.
Forensic Considerations
- Preserving Evidence:?Recovery mechanisms should, where possible, preserve evidence during the recovery process. Overwriting firmware images during recovery may destroy valuable information that could assist in understanding the nature of the attack.
- Recording Attacked Images:?It is important to ensure that attacked firmware images or other critical data are either retained or recorded to support post-incident analysis.
Event Logging
The logging of events surrounding firmware and recovery processes is very important in helping with forensic analysis as well as providing an audit trail. These logs may be used to help monitor changes, confirm the integrity of updates, and ensure recovery activities are valid. Some of the key features of event logging are:
Key Goals of Event Logging
- Capture Attack Information: Logging of firmware and recovery events allows the platform administrator to capture information that could help reveal an attack or a compromise.
- Identify Vulnerabilities: Logs can provide clues as to whether the threat platform contained unknown security vulnerabilities or if the attack was part of a larger, more widespread threat. They will assist in identifying trends or patterns that are common attacks, making the future detection of threats in real-time or preventing future attacks easier.
- Track Events: Logs serve as an audit trail, recording at what point in time specific events occurred, such as firmware updates or recovery actions.
- Track Authorization: Logs include vital information regarding who authorized a change or recovery event and the date and time when the activity occurred. This provides accountability and can be applied to verify whether only authorized people performed the changes.
- Maintain Integrity: Keeping a log of every action can trace if events such as updates or recovery processes were conducted correctly by manufacturers and administrators.
Considerations for Event Logging
Determine Necessary Logging:
- Manufacturer's Responsibility: The platform and device manufacturers will decide the appropriate level of event logging based on their target customer base and the specific security needs of the platform.
- Environmental Considerations: The environment in which the platform will operate (e.g., enterprise, consumer, or data center environments) will influence the scope and depth of logging. Different environments may have different regulatory requirements or security concerns.
- Protect Log Data: The logged events must be stored in a way that ensures their integrity. This includes techniques such as digital signatures or hashing to prevent tampering or modification of the logs.
- Secure Recovery and Transmission: Logs should be recoverable and transmitted securely, ensuring that the data is available when needed without exposing it to unauthorized parties during storage or transit.
- Controlled Access to Logs: Unauthorized access to event logs can be harmful because malicious actors could analyze the logs to exploit weaknesses in the system. Therefore, access to event logs must be tightly controlled.
- Limit Log Access: Only authorized personnel should be able to view or manage event logs, and mechanisms should be in place to restrict access based on roles or levels of trust.
Security of Event Log Data:
- Prevent Data Exfiltration: Logs often contain valuable information about the system's state, updates, and recovery actions. If compromised, they could broaden the attack surface or reveal sensitive system details.
- Encryption and Authentication: Events should be logged using encryption techniques to protect sensitive data.
Authentication mechanisms should ensure that only legitimate devices or users can append entries to the logs.
Previously
Read More
