This chapter covers embedded system and firmware security, a critical area for the Security+ SY0-701 exam under Objective 4.5 (Explain the fundamentals of embedded and specialized system security). Embedded systems, from IoT devices to industrial controllers, often lack traditional security controls, making firmware attacks a growing threat. You will learn how to secure the boot process, implement code signing, and use hardware roots of trust, as well as understand supply chain risks and best practices for patching. Mastering these concepts is essential for defending against low-level attacks that bypass OS-level defenses.
Jump to a section
Imagine you receive a sealed envelope containing a critical contract. Before you trust it, you check the wax seal: it must have the notary's unique stamp, unbroken, and the paper must show no signs of tampering. If the seal is intact and matches the notary's registered design, you can be confident the contract inside hasn't been altered since it was sealed. Now, consider an embedded device like a smart thermostat. Its firmware is the contract, and the secure boot process is the notary. The device has a hardware root of trust (the notary's official stamp) embedded at manufacture. At each boot, the bootloader (the envelope opener) checks a cryptographic signature on the firmware (the seal). If the signature is missing, invalid, or from an untrusted source, the bootloader refuses to load the firmware—just as you'd reject a broken seal. This prevents an attacker from replacing the firmware with malicious code (a forged contract). The mechanism is digital signature verification using a public key stored in read-only memory. The bootloader hashes the firmware, decrypts the signature with the public key, and compares the two hashes. If they match, trust is established. This is not a simple pass/fail; it's a chain: each stage verifies the next, from the immutable boot ROM to the OS kernel. An attacker who compromises one stage could bypass verification, which is why measured boot extends this by recording each stage's hash in TPM registers, allowing remote attestation.
What is Embedded System and Firmware Security?
Embedded systems are specialized computing devices designed for specific functions, often with limited resources (CPU, memory, power). Examples include IoT sensors, medical devices, automotive ECUs, and industrial PLCs. Firmware is the low-level software stored in non-volatile memory (ROM, flash) that controls the hardware. Security of firmware is paramount because it operates at the highest privilege level (Ring -2 on x86, EL3 on ARM), below the OS kernel. Compromised firmware can persist across reboots, evade antivirus, and provide attackers with stealthy, long-term access.
SY0-701 focuses on: secure boot, trusted firmware updates, hardware root of trust (TPM, HSM), code signing, supply chain integrity, and field-programmable gate array (FPGA) risks. The exam expects you to know how these mechanisms work and why they are needed.
How Firmware Attacks Work Mechanically
Attackers target firmware through several vectors: - Malicious updates: If firmware updates are unsigned, an attacker can replace legitimate firmware with malware (e.g., TrickBot's UEFI bootkit). - Physical attacks: JTAG/SWD debugging interfaces, SPI flash sniffing, or chip decapping to extract secrets. - Exploiting vulnerabilities: Buffer overflows in network-facing firmware (e.g., CVE-2021-44228 Log4Shell in IoT devices). - Supply chain compromise: Malicious components inserted before delivery (e.g., the 2018 Supermicro chip implant).
Once inside, firmware malware can:
Disable security features (Secure Boot, TPM).
Install persistent backdoors (e.g., LoJax UEFI rootkit).
Steal cryptographic keys from TPM.
Brick devices or alter critical functions (e.g., Stuxnet modifying PLC firmware).
Secure Boot and Measured Boot
Secure Boot is a UEFI feature that ensures only signed, trusted firmware executes. The process: 1. The CPU starts in a special mode (e.g., Boot ROM) that is immutable. 2. The Boot ROM loads the first-stage bootloader (e.g., UEFI firmware) and verifies its digital signature against a hash in the Key Database (KEK, db, dbx). 3. The bootloader verifies the next stage (e.g., OS bootloader), which verifies the OS kernel, and so on. 4. If any signature fails, boot stops and an error is displayed.
Measured Boot extends this by recording hashes of each boot component in TPM Platform Configuration Registers (PCRs). These PCRs are then used for remote attestation: a verifier checks that the boot chain matches a known-good configuration. Unlike Secure Boot, Measured Boot does not prevent execution of bad code; it only detects it after the fact.
Trusted Boot (Microsoft) verifies all Windows components before loading them, using the TPM.
Hardware Root of Trust (RoT)
The hardware root of trust is an immutable, tamper-resistant component that provides a foundation for all security. Common implementations: - Trusted Platform Module (TPM) 2.0: A dedicated chip (or fTPM) that stores keys, performs cryptographic operations, and measures boot components. TPM.PCRs can be used for attestation, and TPM.NV (non-volatile) storage holds secrets. - Hardware Security Module (HSM): A standalone device for key management, often used in servers and payment systems. Provides FIPS 140-2/3 validation. - ARM TrustZone: A hardware-enforced isolation mechanism in ARM processors that creates a secure world (Trusted Execution Environment, TEE) and a normal world. Secure boot and key management run in the secure world. - Intel SGX (Software Guard Extensions): Creates enclaves in memory that are encrypted and isolated even from the OS. Used for DRM and secure computation.
SY0-701 asks you to distinguish these: TPM is for platform attestation; HSM is for dedicated key storage; TrustZone is for process isolation.
Code Signing and Firmware Updates
All firmware updates should be digitally signed by the vendor. The signing process: 1. Vendor hashes the firmware image (SHA-256 or SHA-384). 2. Vendor encrypts the hash with their private key (RSA-2048 or ECDSA P-256) to create a signature. 3. The device's bootloader or update agent verifies the signature using the vendor's public key (stored in read-only memory or TPM). 4. If verification passes, the update is applied; otherwise, it is rejected.
Common mistakes: using weak hash algorithms (SHA-1), hardcoded keys, or allowing unsigned updates in a "test mode" that can be exploited.
Supply Chain Security
Firmware supply chain attacks are a top concern. Defenses include: - Bill of Materials (SBOM): A list of all software components and their versions, enabling vulnerability tracking. - Vendor assessment: Auditing vendors' security practices, including their firmware signing and update processes. - Hardware attestation: Verifying that components are genuine (e.g., using DICE - Device Identifier Composition Engine). - Secure procurement: Purchasing from trusted distributors, avoiding grey market components.
Real-World Tools and Commands
On Linux, you can check Secure Boot status:
mokutil --sb-stateCheck TPM PCR values:
tpm2_pcrreadOn Windows, use:
Get-TpmFor UEFI firmware analysis, tools like Chipsec and UEFITool are used by security researchers.
Key Standards and Acronyms
UEFI: Unified Extensible Firmware Interface, replaces legacy BIOS.
PCR: Platform Configuration Register (TPM).
KEK: Key Exchange Key (UEFI Secure Boot).
db/dbx: Signature database / Forbidden signature database (UEFI).
DICE: Device Identifier Composition Engine (Trusted Computing Group).
IETF SUIT: Software Update for Internet of Things (RFC 9019).
Summary of Threats and Countermeasures
| Threat | Countermeasure | |--------|----------------| | Malicious firmware updates | Code signing, secure update server, version rollback protection | | Physical tampering | Tamper-evident seals, JTAG fuse blowing, encrypted storage | | Bootkit/rootkit persistence | Secure Boot, Measured Boot, TPM attestation | | Supply chain compromise | SBOM, vendor audits, hardware RoT | | Side-channel attacks | Constant-time algorithms, masking, physical shielding |
Advanced Topic: FPGA Security
Field-Programmable Gate Arrays (FPGAs) are reconfigurable chips used in data centers and edge devices. Their bitstream (configuration file) can be intercepted or modified. Security measures include:
Bitstream encryption (AES-256) and authentication (HMAC).
Anti-tamper fuses to disable readback.
Unique device keys fused at manufacture.
SY0-701 may ask about FPGA risks in cloud environments (e.g., AWS F1 instances) where multi-tenancy could allow side-channel attacks.
Boot ROM Initialization
The CPU powers on and executes the first instruction from an immutable Boot ROM (masked at manufacture). This code initializes minimal hardware (clock, RAM controller) and locates the first bootloader (e.g., UEFI firmware on SPI flash). The Boot ROM is inherently trusted because it cannot be modified after fabrication. In a secure boot system, the Boot ROM contains a public key (or a hash of it) used to verify the next stage. If verification fails, the CPU halts or enters a recovery mode.
Bootloader Signature Verification
The first-stage bootloader (e.g., UEFI firmware) is loaded into RAM. The Boot ROM computes its hash (SHA-256) and checks it against the signature using the embedded public key. The signature must be valid and the bootloader must be from a trusted source (e.g., Microsoft's KEK). If verification fails, the boot process stops. On UEFI systems, the Signature Database (db) lists allowed signers, and the Forbidden Signature Database (dbx) lists revoked or compromised signatures. The bootloader may also measure itself into TPM PCR 0 before executing.
OS Kernel Verification
The bootloader (e.g., GRUB or Windows Boot Manager) verifies the OS kernel or boot kernel (e.g., vmlinuz or ntoskrnl.exe). On Linux with UEFI Secure Boot, shim (a signed small bootloader) loads GRUB, which then verifies the kernel's signature. On Windows, the bootloader verifies the kernel and critical drivers (e.g., boot drivers). Each component's hash is measured into TPM PCRs (e.g., PCR 4 for the bootloader, PCR 8 for the kernel). If any signature is missing or invalid, the boot fails. This prevents unauthorized code from executing at OS level.
Driver and Service Loading
After the kernel loads, it verifies and loads signed drivers and system services. On Windows, Kernel Mode Code Signing (KMCS) requires all kernel-mode drivers to have a valid signature from a trusted CA (e.g., Microsoft). On Linux, signed modules are enforced if CONFIG_MODULE_SIG is enabled. Measured boot extends PCRs for each loaded driver. If an unsigned driver is loaded (e.g., by malware), the TPM measurement will differ from the expected value, enabling remote attestation to detect tampering. In a secure boot environment, loading an unsigned driver should fail unless the system is in test mode.
Application Integrity Verification
At the application layer, integrity can be verified using code signing and runtime checks. Windows uses Windows Defender Application Control (WDAC) or AppLocker to enforce that only signed executables run. On IoT devices, firmware update agents verify signatures before applying updates. Runtime integrity monitoring tools (e.g., Tripwire, AIDE) can hash critical files and alert on changes. Secure enclaves (e.g., Intel SGX) protect application code in memory from being read or modified by the OS. For exam purposes, know that chain of trust extends from hardware to applications, and any break in the chain indicates compromise.
Scenario 1: UEFI Bootkit Detection in a SOC
An analyst at a large enterprise notices that several workstations show unusual network traffic to known command-and-control (C2) IPs after hours. The workstations have been patched and antivirus shows clean. The analyst runs a memory dump and finds hooks in the UEFI runtime services. Using Chipsec, they verify that Secure Boot is enabled but the boot chain includes a modified bootloader. The TPM PCR values (especially PCR 0 and 4) differ from the known-good baseline. The response: isolate the machines, reflash the UEFI firmware from a known-good image, revoke the compromised certificate in dbx, and initiate an incident response. Common mistake: assuming antivirus would detect the rootkit; antivirus runs in the OS and cannot see firmware-level infections.
Scenario 2: IoT Firmware Update Attack
A smart building management system uses IP cameras with a cloud update mechanism. An attacker compromises the update server and replaces the legitimate firmware with malware that opens a reverse shell. The cameras have no code signing verification. The attacker gains persistent access to the building network. The engineer notices that some cameras show wrong timestamps and are unresponsive to ping. Using Wireshark, they see encrypted traffic to unknown external IPs. The correct response: disconnect the cameras, manually reflash with verified firmware from the vendor's website, and implement code signing for future updates. Common mistake: the engineer tries to update the firmware again from the same server, which re-infects the cameras.
Scenario 3: Supply Chain Compromise in Medical Devices
A hospital receives new infusion pumps from a supplier. The pumps are installed and begin malfunctioning, displaying incorrect dosages. The biomedical engineer discovers that the firmware version is older than the one ordered and contains a known vulnerability (CVE-2023-1234). The hospital had not verified the firmware upon receipt. The correct response: quarantine all affected pumps, contact the supplier for a forensic investigation, and implement a secure procurement policy that requires SBOM and signed firmware. Common mistake: the hospital continues using the pumps, assuming the issue is isolated; this could lead to patient harm and regulatory fines.
What SY0-701 Tests: - Objective 4.5 covers: Secure boot, trusted firmware updates, hardware root of trust (TPM, HSM, TEE), code signing, supply chain integrity, and field-programmable gate array (FPGA) security. - You must understand the difference between Secure Boot (prevents unsigned code) and Measured Boot (detects changes). - Know that TPM is used for platform attestation and key storage, not for general-purpose computation. - Recognize that FPGA bitstreams can be encrypted and authenticated to prevent cloning or tampering.
Most Common Wrong Answers and Why: 1. Choosing "Measured Boot" when the question asks for a mechanism that prevents execution of unsigned code. Candidates confuse detection with prevention. Secure Boot blocks, Measured Boot only records. 2. Selecting "TPM" as the answer for a question about encrypting firmware updates. TPM does not encrypt firmware; it stores keys used for verification. Firmware encryption is separate. 3. Thinking that code signing alone ensures integrity of the entire update process. Code signing verifies origin, but rollback attacks (to an older vulnerable version) are still possible unless version rollback protection is implemented. 4. Assuming all embedded systems have the same security capabilities. Many IoT devices lack TPM or Secure Boot; the exam may test that you know this limitation.
Specific Terms and Acronyms: - PCR (Platform Configuration Register) - KEK, db, dbx (UEFI Secure Boot databases) - DICE (Device Identifier Composition Engine) - SBOM (Software Bill of Materials) - TEE (Trusted Execution Environment)
Trick Questions: - A question might say "Which technology stores cryptographic keys and performs attestation?" The answer is TPM, not HSM (HSM is for dedicated key management, not platform attestation). - Another might ask "What prevents a user from booting a modified OS?" Answer: Secure Boot, not Measured Boot.
Decision Rule: On scenario questions, first determine whether the need is to *prevent* tampering (Secure Boot, code signing) or *detect* tampering (Measured Boot, TPM attestation). Then look for keywords: "prevents" -> Secure Boot; "detects" or "reports" -> Measured Boot. For firmware updates, if the question mentions "update from untrusted source", the answer is code signing. If it mentions "rollback to previous vulnerable version", the answer is version rollback protection.
Secure Boot verifies digital signatures of boot components; Measured Boot records hashes in TPM PCRs.
TPM 2.0 is the standard for platform attestation and key storage; HSM is for dedicated key management.
Code signing for firmware updates must include version rollback protection to prevent downgrade attacks.
Supply chain security relies on SBOM, vendor audits, and hardware root of trust (e.g., DICE).
FPGA bitstreams should be encrypted and authenticated to prevent cloning and tampering.
UEFI Secure Boot uses KEK, db, and dbx databases to manage trusted signatures.
ARM TrustZone provides a Trusted Execution Environment (TEE) for secure code execution.
These come up on the exam all the time. Here's how to tell them apart.
Secure Boot
Prevents execution of unsigned or untrusted code.
Uses digital signatures verified by a hardware root of trust.
Fails closed: if verification fails, boot stops.
Commonly used in UEFI and ARM TrustZone systems.
Does not record hashes of boot components.
Measured Boot
Records hashes of each boot component in TPM PCRs.
Does not prevent execution; only detects tampering after the fact.
Allows boot to continue even if measurements differ.
Used for remote attestation to prove system integrity.
Requires a TPM to store PCR values.
TPM (Trusted Platform Module)
Integrated into the platform (chip or firmware).
Used for platform attestation, measured boot, and key storage.
Typically has limited storage and performance.
Standardized by TCG (Trusted Computing Group).
Often bound to a single system.
HSM (Hardware Security Module)
Standalone hardware device (PCIe card, network-attached).
Used for high-security key management, signing, and encryption.
High performance, supports many cryptographic operations per second.
Often FIPS 140-2/3 validated.
Can be shared across multiple systems.
Mistake
Secure Boot and Measured Boot are the same thing.
Correct
Secure Boot verifies signatures and blocks unsigned code from executing; Measured Boot records hashes of boot components in TPM PCRs for later verification but does not block execution. They are complementary.
Mistake
TPM is only used for BitLocker drive encryption.
Correct
TPM has many uses: platform attestation, secure key storage, measured boot, and sealing data to specific system states. BitLocker is just one application.
Mistake
All firmware updates are secure if they are signed.
Correct
Code signing prevents unauthorized updates, but without version rollback protection, an attacker can force a device to downgrade to an older, vulnerable firmware version. Also, if the signing key is compromised, all updates become untrustworthy.
Mistake
Embedded systems are too resource-constrained for security.
Correct
Many low-power devices now include hardware security features like TPM, secure enclaves, and cryptographic accelerators. Even constrained devices can implement lightweight cryptography (e.g., SHA-256, ECDSA).
Mistake
FPGA security is not a concern because FPGAs are reprogrammable.
Correct
FPGA bitstreams can be intercepted, cloned, or modified. Encryption and authentication are necessary to protect intellectual property and prevent malicious reconfiguration. Multi-tenant FPGA clouds (e.g., AWS F1) also face side-channel risks.
Secure Boot prevents execution of untrusted code by verifying digital signatures at each stage of the boot process. If a signature is invalid, the boot stops. Measured Boot, on the other hand, does not block execution; instead, it records hashes of each boot component in TPM Platform Configuration Registers (PCRs). These measurements can later be used for remote attestation to verify that the system booted into a known-good state. In the exam, remember: Secure Boot = prevention; Measured Boot = detection.
A TPM stores cryptographic keys and performs operations like hashing and signing. During boot, the TPM extends measurements into PCRs that are sealed to the system state. If firmware is tampered with, the PCR values will differ from expected, and the TPM will not release sealed keys (e.g., for BitLocker). Additionally, the TPM can be used to verify firmware update signatures. However, the TPM itself does not prevent the tampering; it only provides a way to detect it and protect secrets accordingly.
A hardware root of trust is an immutable, tamper-resistant component that serves as the foundation for all security mechanisms. It is typically implemented as a dedicated chip (e.g., TPM) or a secure area of the processor (e.g., ARM TrustZone). The root of trust provides a trusted source for cryptographic keys and measurements, enabling secure boot, attestation, and code signing. Because it is physically protected and cannot be modified by software, it ensures that the chain of trust starts from a known-good state.
Code signing ensures that the firmware comes from a legitimate source and has not been tampered with in transit. However, it does not prevent an attacker from forcing a device to accept an older, vulnerable firmware version (rollback attack). To mitigate this, version rollback protection must be implemented, where the device rejects any update with a version number lower than the current one. Additionally, if the signing key is compromised, all signed updates become untrustworthy, requiring key revocation and re-signing.
A Software Bill of Materials (SBOM) is a detailed list of all software components, libraries, and their versions used in a firmware image. It enables organizations to quickly identify vulnerable components (e.g., Log4Shell) and assess supply chain risk. By cross-referencing SBOMs with vulnerability databases (e.g., NVD), security teams can prioritize patching. For the exam, know that SBOM is a key practice for supply chain security and is recommended by NIST and CISA.
FPGA bitstreams can be encrypted (e.g., AES-256) and authenticated (e.g., HMAC) to prevent unauthorized readback or modification. The decryption key is stored in non-volatile memory within the FPGA, often fused at manufacture. Additionally, anti-tamper mechanisms (e.g., fuses that disable JTAG) prevent attackers from extracting the bitstream. In multi-tenant FPGA clouds, isolation and side-channel protections are critical to prevent co-tenant attacks.
DICE (Device Identifier Composition Engine) is a specification by the Trusted Computing Group that creates unique device identifiers based on a hardware root of trust. It uses a one-way function to derive a compound identity from a secret stored in immutable memory. DICE enables secure attestation and authentication of devices, even in low-cost IoT hardware. It helps verify that a device has not been replaced or cloned, which is crucial for supply chain integrity.
You've just covered Embedded System and Firmware Security — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?