After the product is shipped, we enter the product maintenance phase. We might subsequently receive a security issue report from either an external or internal customer. Once the issue is identified, we need to fix the issue and prepare a firmware update that can be deployed to all existing products in the field. The time to fix the security issue is important because between the time when the issue is discovered and the time when the issue is fixed, the product is under the risk of being attacked.
Mitigation Strategy and Tactics
Firmware Vulnerability Mitigation Tactics
Tactics | Architecture and Design | Implementation | Maintenance |
|---|---|---|---|
Eliminate the vulnerability. | Reduce attack surface, such as unnecessary SMI handlers. Adopt secure design principles, such as least privilege. Use the correct cryptographic algorithm. | Enable compiler defensive technologies, such as sanitizer, static analysis, and dynamic analysis. Use a type-safe language, such as Rust. Use vulnerability scan tools. | Enhance vulnerability scan tools. |
Break the exploit. | Adopt firmware resiliency – protection, detection, and recovery – such as secure boot. Adopt firmware integrity measurement and attestation, such as measured boot. | Enable compiler defensive technologies, such as stack cookies, address space layout randomization (ASLR), data execution protection (DEP), code integrity guard (CIG), arbitrary code guard (ACG), control flow guard (CFG), and so on. Enable kernel protection technology, such as Supervisor Mode Execute Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), kernel page table isolation (KPTI), and so on. | |
Contain the damage. | Adopt container and virtualization (vertical). Adopt isolation and compartmentalization (horizontal). | Enable supervisor mode. Enable hypervisor. Enable trusted execution environment (TEE). | |
Reduce the attack windows. | Adopt firmware resiliency – updates. Define firmware update process. | Enable firmware component-level update. | Enable firmware supply chain detection. Enable effective firmware vulnerability detection. UEFI scanner. |
shows the example in the UEFI/EDK II system firmware
Tactics | Method | UEFI/EDK II Example |
|---|---|---|
Eliminate the vulnerability. | Reduce attack surface | SMI Handler Profile |
Static analysis/dynamic analysis | Clang static analysis, memory sanitizer, KLEE | |
Security test/fuzzing | Host-based firmware analyzer, Peach, AFL | |
Vulnerability scan | CHIPSEC | |
Break the exploit. | Stack guard | MSVC:/GS, GCC:-fstack-protector |
Address space layout randomization | DXE/SMM ASLR | |
Data executable prevention | SMM Memory Protection | |
Arbitrary code guard | UEFI Core Memory Protection | |
Control flow guard | DXE/SMM Control Flow Enforcement Technology (CET) | |
Code Integrity Guard | UEFI secure boot | |
Contain the damage, | Sandbox | EBC |
Deprivilege | Ring3-based OPROM, SMI Handler | |
Isolation | Ring3-based OPROM, SMI Handler | |
Reduce the attack windows. | Resiliency | Signed update, secure boot, signed recovery, flash lock |
Measurement and attestation | Measured Boot (SRTM), Secure Launch (DRTM) | |
Antivirus | UEFI scanner |
Supply Chain for the Firmware Components
In general, supply chain management is a way to manage the lifecycle of products and services. Firmware is one of the most important components in the platform-level supply chain. We need a robust way to trace each firmware image for a given platform and ensure that they are up to date and have not been tampered.
Firmware Component Certificate and Manifest
Firmware Component Certificates
Platform Certificate | Certificate Format | Data Format |
|---|---|---|
TCG Platform Certificate Profile – TCG Infrastructure working group TCG Endorsement Key (EK) Credential Profile – TCG Infrastructure working group TCG DICE Certificate Profile – TCG Device Identifier Composite Engine (DICE) working group | X.509, The Directory: Public Key and Attribute Certificate Frameworks – ITU X.509 An Internet Attribute Certificate Profile for Authorization – RFC 5755 | Privacy-Enhanced Mail (PEM) – RFC 1421, 7468 BASE64 encoding – RFC 4648 Abstract Syntax Notation One (ASN.1) Distinguished Encoding Rules (DER) – ITU X.690 |
The component certificate should include the reference manifest information. As such, the verifier can get the component information for attestation. For example, the TCG platform certificate includes a PlatformConfigurationURI attribute. From this Uniform Resource Identifier (URI), the verifier can get a reference integrity manifest or measurement (RIM). The format of the reference integrity manifest (RIM) is compliant with the Software Identification (SWID) tag defined in the ISO/IEC 19770-2 specification or Concise Identification (CoSWID) tag defined in the IETF Security Automation and Continuous Monitoring (SACM) working group. The SWID tag is formatted using the Extensible Markup Language (XML), while the CoSWID is formatted using the Concise Binary Object Representation (CBOR). CBOR is a data format whose design goals include the possibility of extremely small code size, relatively small message size, and extensibility without the need for version negotiation. The underlying data model is JSON. The CBOR encoding is much smaller than ASN.1 encoding. As such, it is more suitable for the embedded or Internet of Things (IoT) environment. Besides the CoSWID definition, the IETF Remote Attestation Procedures (RATS) working group added RIM extensions for the CoSWID to meet the needs of the TCG RIM specification.
Firmware Component Manifest
Firmware Component Manifest | Firmware Identification Tag | Data Format |
|---|---|---|
TCG reference integrity manifest (RIM) – TCG Infrastructure working group Guidelines for the Creation of Interoperable SWID Tags – NIST IR 8060 | Software Identification (SWID) Tags – ISO/IEC 19770-2:2015 | Extensible Markup Language (XML) – W3C XML Signature Syntax and Processing – W3C XML Schema Definition (XSD) – W3C |
RIM extension for CoSWID – IETF Remote Attestation Procedures (RATS) working group CBOR-based format for SUIT manifest – IETF Software Update for Internet of Things (SUIT) working group | Concise Software Identification Tags (CoSWID) – IETF Security Automation and Continuous Monitoring (SACM) working group | Concise Binary Object Representation (CBOR) – RFC 7049 CBOR Object Signing and Encryption (COSE) – RFC 8152 Concise Data Definition Language (CDDL) – RFC 8610 |
Firmware Attestation Data
At runtime, the Platform Root-of-Trust and chain-of-trust record the evidence for firmware components in the platform and report them to the verifier. Next, the verifier can compare the component data with the reference manifest to see if the system is trusted. Taking the TCG Platform Firmware Profile as an example, the platform static root-of-trust for measurement extends the system firmware hash into the Platform Configuration Registers (PCR) of the Trusted Platform Module (TPM) and records the hash values into the TCG event log. At runtime, the verifier uses the TPM quote process to verify the TPM PCR values signed by the TPM attestation key. Then the verifier can process the hash data in the TCG event log and try to reproduce the hash values in the PCR value. At this point, the verifier can compare the firmware hash value in the TCG event log and the firmware hash value in the platform reference integrity manifest.
Besides the system firmware measurement, the device firmware measurement can be retrieved via the DMTF Secure Protocol and Data Model (SPDM) protocol between the host and the device. The measurement data is signed by the device using its private certificate. The verifier can use the device public certificate to verify the measurement and then compare it with the device firmware hash value in the reference integrity manifest.
If the device implements the TCG Device Identifier Composition Engine (DICE), then the layered DICE certificates can be used. The device identity certificates, such as the Initial Device Identifier (IDevID) Certificates and Local Device ID (LDevID) Certificates, embed a cryptographic identity in the device so that a verifier may be assured that the device is of reputable origin. The device attestation certificates assert that the device’s manufacturer has embedded a cryptographic key in a device. It allows a verifier to determine which manufacturer created the device.
The IETF Remote Attestation Procedures (RATS) working group defined the entity attestation token (EAT). The EAT provides a signed (attested) set of claims that describe the state and characteristics of an entity, typically a device like a phone or an IoT device. The EAT token is formatted as a CBOR web token (CWT) or a JSON web token (JWT) signed with the device attestation key.
The IETF Trusted Execution Environment Provisioning (TEEP) working group defined the architecture and the protocol for the Trusted Application Manager (TAM) and TEEP agent. The TAM can manage the Trusted Application (TA) in a device, such as query information, install TA, and delete TA.
Table 23-5 lists the standards involved in the firmware attestation data.
Firmware Attestation Data
Attestation | Attestation Data | Data Format |
|---|---|---|
TCG Platform Firmware Profile (PFP) – TCG PC Client working group | TPM Platform Configuration Register (PCR) + TCG event log – TCG PFP | Firmware measurement + TPM quote – TCG TPM |
DMTF Secure Protocol and Data Model (SPDM) – DMTF Platform Management Components Interconnection (PMCI) working group | Device Firmware Measurement Block – DMTF SPDM | Signed device firmware measurement – DMTF SPDM |
DICE Layering Architecture – TCG Device Identifier Composite Engine (DICE) working group | DICE certificate – TCG Device DICE working group | (N +1) Layer signed certificate for firmware measurement – DICE certificate |
Entity attestation token (EAT) – IETF Remote Attestation Procedures (RATS) working group | CBOR web token (CWT) – RFC 8392 JSON web token (JWT) – RFC 8529 | Entity state and characteristics + signing – IETF RATS EAT |
Figure 23-1 shows a general firmware attestation flow. A system includes a root-of-trust and other mutable components. At manufacturing time, the system can be provisioned with the identity information and an attestation key. At the same time, a system certificate and a reference manifest are generated to describe the system information. At runtime, the system reports the attestation data, which includes the system identity information and the component hashes and is signed by the attestation key. The verifier collects the attestation data, verifies the signature with the public attestation certification, and finally compares against the component hash. Please be aware that this is a conceptual flow. A real implementation may have slight differences or more complications.
General Firmware Attestation Flow
Vulnerable Firmware Detection
- 1)
Assess how many products have a similar vulnerability. This can be detected via the supply chain management for the firmware component.
- 2)
Assess if other versions of the firmware have the same vulnerability. This can be done by a signature-based scan tool which can collect a signature of a piece of vulnerable code to see if other versions of the firmware have the same piece of code. A detailed code review may be needed to see when this vulnerability was first introduced in the system.
- 3)
Assess if a similar vulnerability exists in another place besides the reported one. This can be done by a vulnerability-based scan tool which can leverage the vulnerability to attack the system. We may use this tool to test different interfaces and different versions of the firmware. Also, a detailed code review for the similar interface is helpful to catch the similar vulnerability.
Antivirus for Firmware
Besides the firmware vulnerability detection in the firmware release, we can use an antivirus component to detect firmware runtime binary status. This can be considered as a complement for the firmware resiliency – detection. For example, Microsoft announced the UEFI scanner, which is a new component of the built-in antivirus solution on Windows 10. It can scan the insides of the firmware and perform the security assessment. The UEFI scanner can detect a known vulnerable component in the firmware or a misconfigured chipset register in the system. The limitation is that the scanner must read the whole firmware. This can be achieved when the firmware is on a Serial Peripheral Interface (SPI) flash. However, if the firmware is on a Non-Volatile Memory Express (NVMe) flash, the scanner cannot read the firmware content. The alternative is to let the scanner check the firmware component measurement to know what the corresponding component is.
Firmware Update
Once we have identified all vulnerable firmware, we need to prepare the firmware update package. In order to reduce the attack windows, the firmware update frequency is a key indicator. If it is too long, then we may give the attacker too much time to attack the known vulnerable system. If it is too short, then we may bring too much burden to the validation team wherein they need to validate the new firmware release again and again.
- 1)
We can update the full firmware image, such as the whole SPI flash update including the system BIOS and the management engine (ME), together with the non-host firmware such as the embedded controller (EC) or baseboard management controller (BMC). The benefit is that the system will be in a clean, well-known state.
- 2)
We can enable a component-level firmware update. For example, we can update with system BIOS or the management engine (ME) separately. The “Intel 64 and IA-32 Architecture Software Developer Manuals” also defines a way to update the CPU Microcode independent of the system BIOS. Ideally, the component-level firmware update can accelerate the firmware update process and reduce the validation effort. In practice, we need to do necessary validation for the various possible combinations. There might be a case that two different component versions cannot work with each other, for example.
- 3)
We can enable the firmware configuration update. For example, the UEFI specification defines a way to update the UEFI secure boot key in the UEFI authenticated variable region.
Besides the working image, the system recovery image and the system default configuration data should be updated as well. This is to address the case of the vulnerability also existing in the recovery image or the system default configuration data. For example, if we need to update the forbidden database for the UEFI secure boot key, then the manufacturer’s default forbidden database should also be updated. Otherwise, we may expose a rollback attack against the configuration.
Last but not of least importance, in order to track how many firmware updates are deployed, we need to prepare a new reference manifest for the firmware update package. Then the verifier can collect the firmware information and check with the latest platform certificate and reference manifest. If possible, the automated firmware update should be designed to push the latest firmware image to the system if the verifier detects the existence of some vulnerable firmware.
Summary
In this chapter, we introduced the activities for firmware maintenance after the release. We revisited the vulnerability mitigation strategy and tactics, namely, reduce the attack window in the maintenance phase. We went through the supply chain–related industry standards, including the firmware component certificate, such as TCG platform certificate, TPM EK endorsement certificate, and DICE certificate; firmware reference manifest such as TCG RIM using SWID or CoSWID; IETF RIM extension for CoSWID and IETF SUIT manifest; firmware attestation data such as the TCG Platform Firmware Profile; DMTF SPDM device measurement; DICE layered certificate profile; and the IETF EAT token. Finally, we discussed the vulnerable firmware detection techniques and firmware update methods.
References
Book
[B-1] James Ransome and Anmol Misra, Core Software Security: Security at the Source, CRC Press, 2014
Conference, Journal, and Paper
[P-1] Matt Miller, “Trends, Challenges, and Strategic Shifts in the Software Vulnerability Mitigation Landscape,” in BlueHat IL 2019, available at https://github.com/microsoft/MSRC-Security-Research/blob/master/presentations/2019_02_BlueHatIL/2019_01%20-%20BlueHatIL%20-%20Trends%2C%20challenge%2C%20and%20shifts%20in%20software%20vulnerability%20mitigation.pdf
Specification and Guideline
[S-1] ISO/IEC 19770-2, “Information Technology – Software Asset Management – Part 2: Software Identification Tag,” 2015
[S-2] NIST SP800-193, “Platform Firmware Resiliency Guidelines,” 2018, available at https://csrc.nist.gov/publications/sp800
[S-3] NIST SP800-155, “BIOS Integrity Measurement Guidelines,” 2011, available at https://csrc.nist.gov/publications/sp800
[S-4] NISTIR 8060, “Guidelines for the Creation of Interoperable Software Identification (SWID) Tags,” 2016, https://csrc.nist.gov/publications/nistir
[S-5] TagVault org, “SWID Tag Signing Guidelines,” 2017, https://tagvault.org/swid-tags/guidelines/
[S-6] TCG, “TCG PC Client Platform Firmware Integrity Measurement,” 2019, https://trustedcomputinggroup.org/wp-content/uploads/TCG_PC_Client-FIM_v1r24_3feb20.pdf
[S-7] TCG, “TCG PC Client Reference Integrity Manifest Specification,” 2020, https://trustedcomputinggroup.org/wp-content/uploads/TCG_PC_Client_RIM_r0p15_15june2020.pdf
[S-8] TCG, “TCG Reference Integrity Manifest (RIM) Information Model,” 2020, https://trustedcomputinggroup.org/wp-content/uploads/TCG_RIM_Model_v1-r13_2feb20.pdf
[S-9] TCG, “TCG Trusted Attestation Protocol (TAP) Information Model,” 2019, https://trustedcomputinggroup.org/resource/tcg-tap-information-model/
[S-10] TCG, “TCG Platform Certificate Profile,” 2020, https://trustedcomputinggroup.org/resource/tcg-platform-certificate-profile/
[S-11] TCG, “TCG EK Credential Profile,” 2014, https://trustedcomputinggroup.org/resource/tcg-ek-credential-profile-for-tpm-family-2-0/
[S-12] TCG, “Implicit Identity Based Device Attestation,” 2018, available at https://trustedcomputinggroup.org/resource/implicit-identity-based-device-attestation/
[S-13] TCG, “Symmetric Identity Based Device Attestation,” 2020, available at https://trustedcomputinggroup.org/resource/symmetric-identity-based-device-attestation/
[S-14] TCG, “DICE Layering Architecture,” 2020, available at https://trustedcomputinggroup.org/wp-content/uploads/DICE-Layering-Architecture-r19_3june2020.pdf
[S-15] TCG, “DICE Certificate Profiles,” 2020, https://trustedcomputinggroup.org/wp-content/uploads/DICE-Certificate-Profiles-r01_3june2020-1.pdf
[S-16] DMTF, “Security Protocol and Data Model Specification,” 2020, available at www.dmtf.org/standards/pmci
[S-17] IETF, “RFC 5755 – An Internet Attribute Certificate Profile for Authorization,” 2010, https://tools.ietf.org/html/rfc5755
[S-18] IETF, “RFC 7049 – Concise Binary Object Representation (CBOR),” 2013, https://tools.ietf.org/html/rfc7049
[S-19] IETF, “RFC 7519 – JSON Web Token (JWT),” 2015, https://tools.ietf.org/html/rfc7519
[S-20] IETF, “RFC 8152 – CBOR Object Signing and Encryption (COSE),” 2017, https://tools.ietf.org/html/rfc8152
[S-21] IETF, “RFC 8322 – Resource-Oriented Lightweight Information Exchange (ROLIE),” 2018, https://tools.ietf.org/html/rfc8322
[S-22] IETF, “RFC 8392 – CBOR Web Token (CWT),” 2018, https://tools.ietf.org/html/rfc8392
[S-23] IETF, “RFC 8412 – Software Inventory Message and Attributes (SWIMA) for PA-TNC,” 2018, https://tools.ietf.org/html/rfc8412
[S-24] IETF, “RFC 8610 – Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures,” 2019, https://tools.ietf.org/html/rfc8610
[S-25] IETF, “SUIT: A Firmware Update Architecture for Internet of Things,” 2019, https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/
[S-26] IETF, “SUIT: An Information Model for Firmware Updates in IoT Devices,” 2020, https://datatracker.ietf.org/doc/draft-ietf-suit-information-model/
[S-27] IETF, “SUIT: A Concise Binary Object Representation (CBOR)-based Serialization Format for the Software Updates for Internet of Things (SUIT) Manifest,” 2020, https://datatracker.ietf.org/doc/draft-ietf-suit-manifest/
[S-28] IETF, “SACM: Security Automation and Continuous Monitoring (SACM) Architecture,” 2019, https://datatracker.ietf.org/doc/draft-ietf-sacm-arch/
[S-29] IETF, “SACM: Concise Software Identification Tags,” 2019, https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/
[S-30] IETF, “SACM: Definition of the ROLIE Software Descriptor Extension,” 2020, https://datatracker.ietf.org/doc/draft-ietf-sacm-rolie-softwaredescriptor/
[S-31] IETF, “RATS: Remote Attestation Procedures Architecture,” 2020, https://datatracker.ietf.org/doc/draft-ietf-rats-architecture/
[S-32] IETF, “RATS: The Entity Attestation Token (EAT),” 2020, https://datatracker.ietf.org/doc/draft-ietf-rats-eat/
[S-33] IETF, “RATS: Reference Integrity Measurement Extension for Concise Software Identities,” 2020, https://datatracker.ietf.org/doc/draft-birkholz-rats-coswid-rim/
[S-34] IETF, “RATS: Reference Interaction Models for Remote Attestation Procedures,” 2020, https://datatracker.ietf.org/doc/draft-birkholz-rats-reference-interaction-model/
[S-35] IETF, “RATS: Arm's Platform Security Architecture (PSA) Attestation Token,” 2020, https://datatracker.ietf.org/doc/draft-tschofenig-rats-psa-token/
[S-36] IETF, “TEEP: Trusted Execution Environment Provisioning (TEEP) Architecture,” 2020, https://datatracker.ietf.org/doc/draft-ietf-teep-architecture/
[S-37] IETF, “TEEP: Trusted Execution Environment Provisioning (TEEP) Protocol,” 2020, https://datatracker.ietf.org/doc/draft-ietf-teep-protocol/
[S-38] W3C, “XML Signature Syntax and Processing,” 2013, www.w3.org/TR/xmldsig-core1/
[S-39] Microsoft, “PE format Authenticode,” 2019, https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#appendix-a-calculating-authenticode-pe-image-hash
Web
[W-1] NIST, Software Identification (SWID) Tagging, https://csrc.nist.gov/projects/Software-Identification-SWID, https://github.com/usnistgov/swid-tools
[W-2] CBOR, http://cbor.io/
[W-3] “Rough Guide to IETF 102: Internet of Things,” www.internetsociety.org/blog/2018/07/rough-guide-to-ietf-102-internet-of-things/
[W-4] Intel Compute Lifecycle Assurance, www.intel.com/content/www/us/en/security/compute-lifecycle-assurance.html
[W-5] Intel Transparent Supply Chain, www.intel.com/content/www/us/en/products/docs/servers/transparent-supply-chain.html, https://servermarketinglibrary.intel.com/intel-transparent-supply-chain
[W-6] Intel Key Generation Facility, https://intel-epid-sdk.github.io/ecosystem/
[W-7] Microsoft, “UEFI scanner brings Microsoft Defender ATP protection to a new level,” www.microsoft.com/security/blog/2020/06/17/uefi-scanner-brings-microsoft-defender-atp-protection-to-a-new-level/
[W-8] Microsoft, “Modern Service Management for Azure v1.1,” https://azure.microsoft.com/en-us/resources/msm-for-azure/