This chapter covers Trusted Platform Module (TPM) and Secure Boot, two critical hardware-based security technologies that protect the boot process and cryptographic keys from tampering. For the CompTIA A+ 220-1102 exam, these topics fall under Domain 2.0 (Security), Objective 2.2, which asks you to 'Given a scenario, implement and configure common security technologies.' Expect approximately 10-15% of the Security domain questions to involve TPM or Secure Boot. You must understand what TPM is, its versions, how to configure it in firmware, and how Secure Boot uses TPM to verify the integrity of the boot chain.
Jump to a section
Imagine a bank vault that contains the master keys to every safety deposit box in the building. The vault itself is a small, reinforced steel box welded to the floor, with a combination lock that only the bank manager knows. When an employee needs to access a deposit box, they don't get the master key directly; instead, they request the vault to open a specific box, and the vault's robotic arm retrieves the key and unlocks only that box. The vault logs every access attempt and refuses to open if it detects any physical tampering, like drilling or cutting. In this analogy, the vault is the TPM chip, the combination lock is the unique endorsement key burned into the chip during manufacturing, and the master keys are the storage root keys (SRKs) that protect other cryptographic keys. The robotic arm represents the TPM's secure execution environment that performs operations like signing and sealing without exposing the private keys to the operating system. Just as the vault cannot be opened by guessing the combination from a remote location, the TPM's private keys never leave the chip, making them immune to software-based theft. This hardware-enforced isolation is the foundation of features like BitLocker drive encryption and Secure Boot attestation.
What is TPM and Why Does It Exist?
A Trusted Platform Module (TPM) is a dedicated microcontroller, typically soldered onto the motherboard, that securely stores cryptographic keys, passwords, and certificates. It is designed to provide hardware-based security functions that are isolated from the main CPU and operating system. The TPM is specified by the Trusted Computing Group (TCG) and is available in two main versions for modern systems: TPM 1.2 and TPM 2.0. TPM 2.0 is the current standard and is required for Windows 11, while TPM 1.2 is still found on older hardware.
The primary purpose of TPM is to establish a hardware root of trust. This means that the system can rely on the TPM as a tamper-resistant foundation for security operations. Without a TPM, cryptographic keys are stored in software (e.g., on the hard drive), where they can be extracted by malware or an attacker with physical access. With a TPM, private keys never leave the chip, and operations like signing, encryption, and decryption happen inside the TPM. This makes it extremely difficult for an attacker to steal those keys, even if they compromise the OS.
TPM enables several critical security features: - BitLocker Drive Encryption: Uses the TPM to store the full-volume encryption key and verify the integrity of the boot components before releasing the key. - Platform Integrity Measurements: The TPM stores hashes (measurements) of firmware, boot loader, and OS components. These can be compared against known good values to detect tampering (measured boot). - Remote Attestation: A remote system can query the TPM for its measurements to verify that the system is in a known trusted state. - Sealing and Binding: Data can be encrypted with a key that is tied to specific TPM state measurements, so it can only be decrypted when the system is in that exact state.
How TPM Works Internally
The TPM contains several key components: - Endorsement Key (EK): A unique RSA or ECC key pair burned into the TPM during manufacturing. The private key never leaves the TPM. The public key is used to prove the TPM's identity. - Storage Root Key (SRK): Another key pair generated inside the TPM and protected by the EK. The SRK protects all other keys stored in the TPM's key hierarchy. - Platform Configuration Registers (PCRs): These are registers that store hash measurements of software and firmware. Typical systems have 24 PCRs (PCR 0-23), each used for specific components (e.g., PCR 0 for BIOS, PCR 2 for option ROMs, PCR 8 for boot loader). - Non-Volatile Memory (NVRAM): Used to store persistent data like the EK, SRK, and other keys. - Random Number Generator (RNG): Generates high-quality random numbers for key generation.
When the system boots, the firmware measures each component before executing it. A measurement is a cryptographic hash (SHA-1 for TPM 1.2, SHA-256 for TPM 2.0) of the component's code and configuration. This hash is stored in a PCR by extending it: PCR[n] = SHA256(PCR[n] || new_measurement). Because each measurement depends on all previous ones, the final PCR values are a unique fingerprint of the entire boot chain. If any component is modified (e.g., by malware), the hash chain will differ from the expected values.
TPM commands are sent via a hardware bus, typically LPC (Low Pin Count) for TPM 1.2 or SPI (Serial Peripheral Interface) for TPM 2.0. The operating system interacts with the TPM through a device driver and a TPM Base Services (TBS) stack. Applications use the TPM via the TCG Software Stack (TSS) or Microsoft's TPM API.
Key Components, Values, and Defaults
TPM Versions:
TPM 1.2: Uses SHA-1, limited to RSA keys, fixed PCR banks.
TPM 2.0: Uses SHA-256, supports RSA and ECC, flexible PCR banks, more algorithms.
PCR Count: 24 (0-23) on most systems. PCR 7 is used for Secure Boot policy.
EK Size: Typically 2048-bit RSA for TPM 1.2; 2048-bit RSA or ECC P-256 for TPM 2.0.
TPM Lockout: After multiple failed authorization attempts, the TPM enters a lockout state (default: 5 attempts, 10-minute lockout).
TPM Owner Password: TPM 1.2 requires an owner password to manage the TPM. TPM 2.0 uses user-defined authorization values.
Configuration and Verification Commands
In Windows, TPM management is done via: - tpm.msc: The TPM Management Console. Shows TPM manufacturer, version, status, and allows clearing the TPM. - Get-Tpm PowerShell cmdlet: Retrieves TPM information. - Clear-Tpm: Resets the TPM to factory defaults (requires reboot). - Enable-TpmAutoProvisioning: Automatically provisions the TPM for Windows.
In Linux, use:
- tpm2_getcap (for TPM 2.0) to list capabilities.
- tpm2_pcrread to read PCR values.
- tpm2_takeownership to take ownership.
For Secure Boot, configuration is in the UEFI firmware settings: - Secure Boot State: Enabled, Disabled, or Setup Mode. - Platform Key (PK): The root key that signs the Key Exchange Key (KEK). - Key Exchange Key (KEK): Signs the database updates. - Signature Database (db): Contains allowed signatures (hashes or certificates) for boot loaders. - Forbidden Signature Database (dbx): Contains revoked signatures.
How TPM Interacts with Secure Boot
Secure Boot is a UEFI feature that ensures only signed, trusted boot loaders are executed. The TPM supports Secure Boot by storing measurements of the boot chain in PCRs. When Secure Boot is enabled, the UEFI firmware verifies the digital signature of each boot component against the signatures in the db database. If verification passes, the component is executed and its hash is extended into the appropriate PCR. If verification fails, boot stops with an error.
The TPM can also be used for measured boot, where the firmware measures every component regardless of Secure Boot policy. These measurements are stored in PCRs and can be used for remote attestation. In Windows, BitLocker uses TPM PCR 7 (which includes Secure Boot policy) to seal the encryption key. If Secure Boot is disabled or the boot chain is altered, the PCR values change, and BitLocker will require a recovery key.
Secure Boot Details
Secure Boot uses three key databases stored in UEFI firmware: - PK (Platform Key): Establishes trust between the platform owner and firmware. Only one PK can be active. - KEK (Key Exchange Key): Authorizes updates to the signature databases (db and dbx). - db (Signature Database): Contains allowed signers or image hashes. - dbx (Revoked Signature Database): Contains forbidden signers or image hashes.
During boot, the firmware checks the signature of the boot loader (e.g., bootmgfw.efi) against db. If the signature is present and not revoked, the boot loader runs. The boot loader then checks the OS kernel similarly. This chain ensures that only trusted code runs from the moment the system powers on.
Secure Boot can be in one of three modes: - User Mode: The PK is set, and only signed updates are allowed. - Setup Mode: No PK is installed; any KEK can be added. Typically used for initial configuration. - Custom Mode: The user can manually manage keys.
Common Commands for Secure Boot
Check Secure Boot status: Confirm-SecureBootUEFI in PowerShell (Windows) or mokutil --sb-state in Linux.
List Secure Boot keys: Get-SecureBootPolicy or mokutil --list-enrolled.
Enable/Disable Secure Boot: Usually in UEFI firmware settings, not via OS commands.
Exam-Relevant Details
TPM 2.0 is required for Windows 11. If the system lacks TPM 2.0, Windows 11 cannot be installed.
Clearing the TPM (e.g., via Clear-Tpm or firmware option) will cause BitLocker to require a recovery key on next boot because the sealed key is lost.
Secure Boot does not prevent installation of alternative OSes like Linux if they are signed by a key in the db database (e.g., Microsoft's UEFI CA).
TPM can be disabled in firmware; this will break BitLocker and other TPM-dependent features.
The TPM chip can be discrete (soldered) or integrated into the CPU (fTPM). Both are functionally equivalent.
Windows 11 also requires Secure Boot capability (can be disabled but must be supported).
Trap Patterns on the Exam
Confusing TPM with HSM: HSM (Hardware Security Module) is a separate, often external device used for enterprise key management. TPM is a simpler, cheaper chip for client devices.
Thinking TPM is only for BitLocker: TPM enables many features, including measured boot, remote attestation, and application key storage.
Assuming Secure Boot replaces TPM: Secure Boot and TPM are complementary. Secure Boot verifies signatures; TPM stores measurements and keys.
Misunderstanding PCR values: PCRs are not stored on disk; they are volatile and reset on each boot.
Configuration Examples
Windows: To enable TPM, go to UEFI firmware settings, find Security or Trusted Computing section, and enable TPM. For TPM 2.0, it may be labeled 'TPM 2.0 Security Device' or 'Intel Platform Trust Technology' (Intel PTT) or 'AMD fTPM'. Save and exit. In Windows, run tpm.msc to verify status is 'The TPM is ready for use'.
Linux: Use tpm2_getcap -c properties-variable to check TPM version. To clear TPM, use tpm2_clear (requires owner authorization).
Secure Boot: In UEFI, enable Secure Boot (often under Boot tab). If the system is in Setup Mode, you may need to install the default keys (e.g., 'Restore Secure Boot to Factory Defaults').
Power On and UEFI Initialization
When the system powers on, the UEFI firmware initializes hardware components, including the TPM. The TPM is identified and its capabilities are read. The firmware begins measuring the boot process by hashing the firmware code itself (e.g., BIOS or UEFI firmware) and extending the hash into PCR 0. This measurement captures the exact firmware version and configuration. If the firmware has been tampered with, the hash will differ from the expected value. The TPM's PCRs start at 0 and are extended only; they cannot be reset except by a full system reset (power cycle). This step establishes the first link in the chain of trust.
Firmware Measures Option ROMs and Boot Loader
After initializing firmware, the UEFI firmware measures any option ROMs (e.g., network boot ROMs, GPU firmware) and extends the hash into PCR 2. Then, the firmware locates the boot loader (e.g., bootmgfw.efi for Windows) from the boot device. Before executing it, the firmware hashes the boot loader and extends the result into PCR 4. Additionally, the firmware verifies the digital signature of the boot loader against the Secure Boot signature database (db). If the signature is valid and not revoked, execution continues. If Secure Boot is enabled and verification fails, the boot stops with a security policy violation. The measurement into PCR 4 captures the identity of the boot loader.
Boot Loader Measures OS Kernel
The boot loader (e.g., Windows Boot Manager) takes over and measures the OS kernel and critical drivers before loading them. In Windows, the boot loader extends measurements into PCR 8. The boot loader also verifies the kernel's digital signature against the Secure Boot policy (or uses its own signature verification). The OS kernel is then loaded into memory and executed. The TPM now contains a chain of measurements from firmware through the kernel. Any tampering at any stage would cause the PCR values to differ from the expected values. For BitLocker, PCR 7 is used to measure Secure Boot policy; PCR 11 measures the BitLocker early boot components.
OS Requests TPM for Key Release
Once the OS kernel is running, Windows attempts to unlock the BitLocker-protected volume. The OS sends a command to the TPM to unseal the volume master key (VMK). The TPM checks the current PCR values against the values stored when the key was sealed (during BitLocker setup). If the current PCR values match the expected values (i.e., the boot chain is intact), the TPM decrypts the VMK and returns it to the OS. The OS then uses the VMK to decrypt the full-volume encryption key (FVEK) and access the drive. If the PCR values do not match (e.g., due to a bootkit or altered firmware), the TPM refuses to unseal, and the OS prompts for the BitLocker recovery key. This step demonstrates TPM's role in platform integrity verification.
Remote Attestation (Optional)
In enterprise environments, the system may perform remote attestation. A management server (e.g., using Microsoft System Center or a third-party solution) sends a challenge to the client. The client's TPM generates a quote: a signed set of current PCR values using the Attestation Identity Key (AIK). The server verifies the signature using the TPM's public endorsement key (EK) and compares the PCR values against a known good baseline. If they match, the server trusts that the client is running trusted software. This allows the server to grant network access or deploy sensitive data. Remote attestation relies on the TPM's ability to securely report measurements without exposing private keys.
Enterprise Deployment of TPM and Secure Boot
Scenario 1: BitLocker Drive Encryption on Corporate Laptops
A large enterprise issues thousands of Windows laptops to employees. To protect sensitive data in case of theft, the IT department enables BitLocker with TPM-only protection (no PIN or startup key). During provisioning, the TPM is cleared and then initialized using Initialize-Tpm in PowerShell. BitLocker is enabled via Group Policy, which automatically seals the encryption key to PCRs 7 and 11. The recovery keys are backed up to Active Directory. When a laptop boots normally, the TPM releases the key silently. However, if an attacker boots from a USB drive or modifies the UEFI settings, the PCR values change, and BitLocker demands the 48-digit recovery key. The enterprise uses a helpdesk process to retrieve recovery keys from AD. A common misconfiguration is forgetting to enable TPM in firmware, causing BitLocker to fail on first boot. Also, if the TPM is cleared (e.g., during motherboard replacement), all BitLocker volumes become inaccessible without recovery keys.
Scenario 2: Secure Boot to Prevent Bootkits A financial institution requires all point-of-sale (POS) systems to have Secure Boot enabled. The IT team configures the UEFI firmware to enable Secure Boot and ensure that only Microsoft-signed boot loaders are allowed. They also enroll a custom KEK to allow their own signed diagnostic tools. During an audit, they discover that some systems have Secure Boot disabled because a technician accidentally toggled it while troubleshooting. The team implements a BIOS configuration management tool to enforce Secure Boot settings remotely. They also test that Linux-based recovery tools are signed and added to the db database. A common issue is that some older hardware does not support Secure Boot, requiring a hardware refresh. Additionally, if the firmware battery dies, the Secure Boot keys may be lost, reverting to Setup Mode and requiring manual re-enrollment.
Scenario 3: Remote Attestation for Network Access A university uses a network access control (NAC) solution that requires clients to prove their integrity before connecting to the campus network. Each student laptop must have TPM 2.0 and run a health agent that performs remote attestation. The NAC server challenges the client, and the TPM signs the current PCR values. The server verifies the signature and checks that the PCR values match the expected baseline for a clean Windows installation. If the client is infected with a rootkit that modifies the boot chain, the PCR values will differ, and the client is quarantined to a remediation network. The IT team must manage the baseline updates when OS patches change the boot components. A failure point is when the TPM is not properly initialized for attestation (missing AIK), causing the client to fail attestation even though it is healthy. The team uses Group Policy to automatically provision the TPM and create the AIK.
Exam Focus: TPM and Secure Boot on 220-1102
This section is your highest-value study guide for exam questions. The CompTIA A+ 220-1102 exam tests TPM and Secure Boot under Objective 2.2: 'Given a scenario, implement and configure common security technologies.' You will see scenario-based questions where you must choose the correct technology or configuration step.
What 220-1102 Specifically Tests: - Identifying TPM versions: TPM 1.2 vs. 2.0. Know that TPM 2.0 is required for Windows 11. - TPM functions: Key storage, platform integrity, remote attestation, and sealing/unsealing. - Secure Boot: Purpose (prevents unauthorized boot loaders), location (UEFI firmware), and interaction with TPM. - Configuration steps: Enabling TPM in firmware, clearing TPM, enabling Secure Boot, and managing BitLocker recovery. - Troubleshooting: What happens when TPM is cleared, Secure Boot is disabled, or boot chain is altered.
Common Wrong Answers and Why Candidates Choose Them: 1. 'TPM is the same as a TPM module for BitLocker only.' Candidates often think TPM is only for BitLocker. Reality: TPM also supports measured boot and remote attestation. The exam will ask about other uses. 2. 'Secure Boot requires TPM to function.' This is false. Secure Boot can work without TPM; TPM adds measurement capabilities but is not required for signature verification. Candidates confuse the two. 3. 'Clearing the TPM removes BitLocker encryption.' Clearing the TPM does not remove encryption; it makes the sealed key unavailable, requiring recovery. The data remains encrypted. 4. 'TPM 1.2 supports SHA-256.' TPM 1.2 uses SHA-1; TPM 2.0 uses SHA-256. Candidates may assume newer algorithms are backward compatible.
Specific Numbers and Terms: - PCR count: 24 (PCR 0-23) - PCR 7: Secure Boot policy - PCR 11: BitLocker early boot components - TPM lockout: 5 failed attempts, 10-minute lockout - Windows 11 requirement: TPM 2.0 and Secure Boot capable (enabled not mandatory but recommended) - Secure Boot databases: PK, KEK, db, dbx
Edge Cases and Exceptions:
- If the system has a TPM but it is disabled in firmware, BitLocker cannot use TPM protection; it will fall back to a startup key or PIN.
- If Secure Boot is enabled but the boot loader is not signed by a trusted key, the system will not boot. This can happen when installing a custom OS.
- Clearing the TPM from the OS (e.g., Clear-Tpm) requires a reboot and will reset all keys. The TPM ownership is also cleared.
- On some systems, TPM 2.0 is implemented as firmware TPM (fTPM) inside the CPU. This is functionally identical to discrete TPM but may have different power-on behavior.
How to Eliminate Wrong Answers: - If a question asks about storing cryptographic keys in hardware, choose TPM. - If a question asks about verifying boot loader signatures, choose Secure Boot. - If a question asks about measuring boot components for integrity, choose TPM (with measured boot). - If a question mentions a remote server verifying system integrity, choose remote attestation (uses TPM). - Always consider the scenario: for drive encryption, TPM is the enabler; for boot security, Secure Boot is the gatekeeper.
TPM 2.0 is required for Windows 11 installation; TPM 1.2 is not sufficient.
TPM stores private keys in hardware; they never leave the chip.
Secure Boot uses UEFI signature databases (PK, KEK, db, dbx) to verify boot loaders.
TPM and Secure Boot are complementary: Secure Boot verifies signatures; TPM measures and reports integrity.
Clearing the TPM will cause BitLocker to require a recovery key on next boot.
PCR 7 stores the Secure Boot policy measurement; PCR 11 stores BitLocker early boot components.
TPM lockout occurs after 5 failed authorization attempts, lasting 10 minutes by default.
Measured boot records hashes in PCRs; Secure Boot enforces signature validation.
fTPM (firmware TPM) is a CPU-based implementation functionally identical to discrete TPM.
Remote attestation uses TPM to sign current PCR values, allowing a server to verify system integrity.
These come up on the exam all the time. Here's how to tell them apart.
TPM (Trusted Platform Module)
Soldered onto motherboard; relatively low cost (~$5-50).
Stores limited number of keys (typically 10-100).
Performs cryptographic operations (RSA, ECC, SHA) but slower than HSM.
Used in client devices: laptops, desktops, IoT.
Managed via firmware and OS tools (tpm.msc, PowerShell).
HSM (Hardware Security Module)
External device (USB, PCIe, network appliance); high cost ($500-$50,000+).
Stores thousands of keys with high-performance crypto.
Performs high-speed cryptographic operations (up to thousands of signatures per second).
Used in servers, data centers, and enterprise PKI.
Managed via dedicated software, often with FIPS 140-2 Level 3 physical security.
Secure Boot
Verifies digital signatures of boot components against db database.
Prevents execution of unsigned or revoked boot loaders.
Does not require TPM; uses UEFI firmware keys.
If verification fails, boot stops immediately.
Provides integrity verification of boot chain (binary trust).
Measured Boot
Records hashes (measurements) of boot components into TPM PCRs.
Does not prevent boot; allows boot even if measurements differ.
Requires TPM to store measurements.
Used for attestation and BitLocker sealing.
Provides integrity reporting (attestation trust).
Mistake
TPM is only used for BitLocker drive encryption.
Correct
TPM provides a hardware root of trust for many security features: measured boot, remote attestation, key storage for applications, and sealing data to specific system states. BitLocker is just one consumer of TPM services.
Mistake
Secure Boot requires a TPM to function.
Correct
Secure Boot is a UEFI firmware feature that verifies digital signatures of boot loaders using keys stored in firmware. It does not require a TPM. However, the TPM can store measurements of the boot chain for attestation, which complements Secure Boot.
Mistake
Clearing the TPM removes BitLocker encryption from the drive.
Correct
Clearing the TPM deletes the keys stored in the TPM, including the sealed BitLocker volume master key. The drive remains encrypted, but the TPM can no longer unlock it. You must use the recovery key to access the drive.
Mistake
TPM 1.2 and TPM 2.0 are interchangeable.
Correct
TPM 2.0 is not backward compatible with TPM 1.2. They use different command sets, algorithms (SHA-256 vs SHA-1), and key hierarchies. Windows 11 requires TPM 2.0. Many TPM 1.2 systems cannot be upgraded to TPM 2.0 without replacing the motherboard.
Mistake
Secure Boot prevents all malware from loading.
Correct
Secure Boot only verifies the boot loader and OS kernel signatures. Once the OS is running, malware can still be loaded after boot (e.g., via malicious drivers or applications) if not blocked by other security measures like Windows Defender or driver signing policies.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
TPM 1.2 uses SHA-1 hashing, only supports RSA keys, and has a fixed set of PCR banks. TPM 2.0 uses SHA-256, supports RSA and ECC, allows flexible PCR banks, and offers more cryptographic algorithms. TPM 2.0 is required for Windows 11. For the exam, know that TPM 2.0 is the current standard and that TPM 1.2 is legacy.
No, Secure Boot is a UEFI firmware feature that works independently of TPM. It verifies digital signatures of boot loaders using keys stored in firmware. However, TPM can enhance Secure Boot by measuring the boot chain and storing those measurements in PCRs, which is used by BitLocker and remote attestation. On the exam, remember that Secure Boot does not require TPM.
Clearing the TPM resets it to factory defaults, removing all keys, including the BitLocker volume master key. The drive remains encrypted, but you will need the BitLocker recovery key to unlock it. Also, any other applications that rely on TPM keys (e.g., certificate storage) will lose those keys. You can clear the TPM via the firmware menu or using the `Clear-Tpm` PowerShell cmdlet (requires a reboot).
TPM is enabled in the UEFI/BIOS firmware settings. Reboot and press the key to enter firmware setup (often F2, Del, or F10). Look for a 'Security' or 'Trusted Computing' section. Enable the TPM device (may be labeled 'Intel PTT', 'AMD fTPM', or 'TPM 2.0'). Save and exit. In Windows, run `tpm.msc` to confirm the TPM is ready. If it shows 'Compatible TPM cannot be found', the TPM may be disabled or not present.
Yes, many Linux distributions support Secure Boot. They use a signed boot loader (e.g., shim) that is signed by Microsoft's UEFI CA, which is included in the db database on most systems. The shim then loads a second-stage boot loader (e.g., GRUB) that is signed by the distribution's key. Alternatively, you can enroll your own keys in the firmware. For the exam, know that Secure Boot is not exclusive to Windows.
Measured boot records cryptographic hashes of each boot component into TPM PCRs during the boot process. It does not prevent boot; it only records the measurements. Secure Boot, on the other hand, actively verifies signatures and blocks unsigned boot loaders. Measured boot is used for attestation and BitLocker sealing, while Secure Boot enforces trust. Both can work together: Secure Boot ensures only signed code runs, and measured boot records what actually ran.
Platform Configuration Registers (PCRs) are volatile memory locations inside the TPM that store hash measurements of software and firmware. There are 24 PCRs (0-23) on typical systems. Each PCR is dedicated to specific components (e.g., PCR 0 for firmware, PCR 2 for option ROMs, PCR 4 for boot loader, PCR 7 for Secure Boot policy, PCR 8 for OS kernel, PCR 11 for BitLocker). PCR values are extended cumulatively, so they reflect the entire boot chain. They are used to verify system integrity and seal keys.
You've just covered TPM and Secure Boot — now see how well it sticks with free 220-1102 practice questions. Full explanations included, no account needed.
Done with this chapter?