除了 Titan 的固件之外,我们还对在 AP 上运行的固件进行加密签名。Titan 会在平台启动流程中验证此签名。每当 AP 固件更新时,它还会验证此签名,以强制执行仅将真实 AP 固件映像写入 AP 的启动固件闪存芯片的操作。此验证流程可缓解尝试安装持久后门或使平台无法启动的攻击。如果 CPU 在其自身的微码身份验证机制中存在漏洞,签名验证还可为 Google 的平台提供纵深防御。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],[],[[["\u003cp\u003eThe Titan chip is a purpose-built microcontroller that serves as the hardware root of trust for Google Cloud data centers, protecting against physical attacks and privileged software threats.\u003c/p\u003e\n"],["\u003cp\u003eTitan chips establish a strong machine identity and ensure the integrity of platform firmware at boot and update times through built-in self-tests and cryptographic verification processes.\u003c/p\u003e\n"],["\u003cp\u003eEach Titan chip generates unique key material during manufacturing, allowing Google to verify the authenticity of Titan-enabled platforms integrated into their production network.\u003c/p\u003e\n"],["\u003cp\u003eWhen integrated into a platform, the Titan chip interposes between the application processor (AP) and the AP's boot firmware flash, ensuring that all firmware is verified before being run.\u003c/p\u003e\n"],["\u003cp\u003eThe Titan chip supports secure firmware upgrades by verifying the digital signature and security version number (SVN) of firmware, allowing recovery from vulnerabilities even in the root-of-trust firmware.\u003c/p\u003e\n"]]],[],null,["# Titan hardware chip\n\n*This content was last updated in January 2025, and represents the status quo as\nof the time it was written. Google's security policies and systems may change\ngoing forward, as we continually improve protection for our customers*.\n\nThe Titan chip is a purpose-built chip that establishes the hardware root of\ntrust for platforms in Google Cloud data centers. The Titan chip is a low-power\nmicrocontroller that is deployed on platforms such as servers, network\ninfrastructure, and other data center peripherals.\n\nThe Titan chip is an important component of the [Titanium hardware\nsecurity\narchitecture](/docs/security/titanium-hardware-security-architecture),\nwhich provides a foundational security layer that helps protect against physical\nattacks and threats to user data. The Titan chip lets Google securely identify\nand measure platform firmware and configuration. It is designed to protect\nagainst privileged software attacks and rootkits, from the machine boot process\nforward.\n\nThis document describes the chip architecture and security benefits of the Titan\nchip. The Titan chip supports a minimal trusted computing base (TCB) that lets\nthe chip provide the following benefits:\n\n- A hardware root of trust that creates a strong identity for a machine\n- Integrity verification of platform firmware, both at boot time and update time\n- [Remote credential\n sealing](/docs/security/boot-integrity#credential-sealing-process) flows that underpin Google's machine credential management system\n\nThe Titan chip family\n---------------------\n\nThe earliest Titan chips were designed in 2014. Later generations incorporated\nthe experience that was gained during iterative manufacturing, integration, and\ndeployment processes. For more information about how Google has contributed our\nknowledge about the Titan chip to the open-source hardware security community,\nsee [opentitan.org](https://opentitan.org).\n\nTitan chips include the following components:\n\n- Secure processor\n- AES and SHA cryptographic coprocessor\n- Hardware random number generator\n- Sophisticated key hierarchy\n- Embedded static RAM (SRAM), flash, and ROM\n\nTitan manufacturing identity\n----------------------------\n\nDuring the Titan chip manufacturing process, each Titan chip generates unique\nkey material. This key material is certified and used to produce endorsement records.\nThese endorsement records are stored in one or more registry databases, and are\ncryptographically protected using air-gapped and multi-party controls.\n\nWhen Titan-enabled platforms are integrated into the Google production network,\nthe backend systems can verify that these platforms are equipped with authentic\nTitan chips. Authentic Titan chips are provisioned with keys that were\nregistered and certified during the Titan manufacturing process. For more\ninformation about how services use the Titan identity system, see [Credential\nsealing\nprocess](/docs/security/boot-integrity#credential-sealing-process).\n\nLater-generation Titan chip identities are generated and certified in accordance\nwith industry standards such as [Device Identifier Composition Engine\n(DICE)](https://trustedcomputinggroup.org/what-is-a-device-identifier-composition-engine-dice/).\nThe original Titan chips were certified using a custom Google design, because\nthese chips were manufactured before relevant industry standards were\nintroduced. Google's experience in manufacturing and deploying secure hardware\nmotivates us to increase participation in standards processes, and newer\nstandards such as DICE, Trusted Platform Module (TPM), and Security Protocol and\nData Mode (SPDM) include changes that reflect our experience.\n\nTitan integration\n-----------------\n\nWhen the Titan chip is integrated into a platform, it provides security\nprotections to an application processor (AP). For example, Titan might be paired\nwith a CPU that runs workloads, a baseboard management controller (BMC), or an\naccelerator for workloads such as machine learning.\n\nTitan communicates with the AP using the serial peripheral interface (SPI) bus.\nTitan interposes between the AP and the AP's boot firmware flash chip, ensuring\nthat Titan can read and measure every byte of that firmware before the firmware\nis run at boot time.\n\nThe following steps occur when a Titan-enabled platform powers on:\n\n1. Titan keeps the CPU in reset mode while Titan's internal application processor runs immutable code (the *boot ROM*) from its embedded read-only memory.\n2. Titan runs a built-in self-test to verify that all memory (including the ROM) hasn't been tampered with.\n3. Titan's boot ROM verifies Titan's firmware using public key cryptography and mixes the identity of the verified firmware into Titan's key hierarchy.\n4. Titan's boot ROM loads Titan's verified firmware.\n5. Titan firmware verifies the contents of the AP's boot firmware flash using public key cryptography. Titan blocks the AP's access to its boot firmware flash until the verification process completes successfully.\n6. After verification, the Titan chip releases the AP from reset, allowing the AP to boot.\n7. The AP firmware performs additional configuration, which might include launching further boot images. The AP can capture measurements of these boot images and send the measurements to Titan for secure monitoring.\n\nThese steps achieve *first-instruction integrity* because Google can identify\nthe boot firmware and OS that was booted on the machine from the very first\ninstruction that runs during the startup cycle. For APs with CPUs that accept\nmicrocode updates, the boot process also lets Google know which microcode\npatches were fetched before the boot firmware's first instruction. For more\ninformation, see [Measured boot\nprocess](/docs/security/boot-integrity#measured-boot-process).\n\nThis flow is similar to the boot process that is performed by platforms that are\nequipped with a TPM. However, Titan chips include features that are not\ngenerally available on standard TPMs, such as Titan's internal firmware\nself-attestation or AP firmware upgrade security, as described in the following\nsections.\n\nStandard TPM integrations can be vulnerable to physical interposer attacks.\nNewer Titan integrations at Google mitigate these attacks by using\nintegrated roots of trust. For more information, see\n[TPM Transport Security: Defeating Active Interposers with DICE (YouTube)](https://www.youtube.com/watch?v=DKfbkOTYzOU).\n\nSecure Titan firmware upgrade\n-----------------------------\n\nThe Titan chip's firmware is signed by a key that is held in an offline HSM,\nwhich is protected by quorum-based controls. Titan's boot ROM verifies Titan\nfirmware's signature whenever the chip boots.\n\nTitan firmware is signed with a security version number (SVN), which conveys the\nsecurity state of the image. If a firmware image includes a vulnerability fix,\nthe image's SVN is incremented. Titan hardware lets the production network\nstrongly attest to the SVN of Titan's firmware, even if older firmware might\nhave had vulnerabilities. The upgrade process lets us recover from these\nvulnerabilities at scale, even if they affect Titan's own firmware. For more\ninformation, see [Recovering from vulnerabilities in root-of-trust\nfirmware](/docs/security/boot-integrity#recovering_from_vulnerabilities_in_root-of-trust_firmware).\n\nGoogle contributed to the latest version of the TPM Library specification, which\nnow includes features that let other TPMs provide similar self-attestation\nassurances. For more information, see the [TPM Firmware-Limited and SVN-Limited\nObjects section\n(PDF)](https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-1-Architecture.pdf#page=288)\nof version 1.83 of the TPM Architecture specification. These TPM features were\nimplemented and deployed on our latest Titan chips.\n\nSecure AP firmware upgrade\n--------------------------\n\nIn addition to Titan's firmware, we also cryptographically sign the firmware\nthat runs on the AP. Titan verifies this signature as part of the platform boot\nprocess. It also verifies this signature whenever the AP firmware is updated,\nenforcing that only authentic AP firmware images can be written to the AP's boot\nfirmware flash chip. This verification process mitigates attacks that attempt to\ninstall persistent backdoors or render the platform unbootable. Signature\nverification also provides defense in depth for Google's platforms in the event\nthat a CPU has a vulnerability in its own microcode authentication mechanism.\n\nWhat's next\n-----------\n\nLearn more about our [boot integrity\nprocess](/docs/security/boot-integrity)."]]