How Google’s Custom Security Chip Secures Servers at Boot

Data centers these days are busy replacing expensive hardware solutions with “software-defined” everything, but the trend is the opposite when it comes to security. While software still prevails in keeping servers secure, hardware is often being added to the mix as another layer of protection, especially during the boot process, when a computer is vulnerable to dangers such as maliciously modified firmware.

This trend started when UEFI — and Secure Boot — replaced BIOS on computers, and was carried a step further when Google began including an additional custom designed hardware security chip on all servers and peripherals in its data centers. In June, Hewlett Packard Enterprise followed suit and announced it was joining the secured-by-hardware crowd by including its own custom chip on its Gen10 servers. Lenovo also includes a degree of security-on-a-chip technology on its line of servers, through XClarity Controller.

There are several advantages to having security protections contained in chipsets that are separate from a server’s CPUs. Being isolated from the server’s main components, they are more difficult for an outside hacker who manages to get through a system’s defenses to find and penetrate. In addition, they can utilize read-only memory that can be difficult or impossible to modify.

See also: Here’s How Google Secures Its Cloud

At its Cloud Next event in March, Google unveiled a custom security chip called Titan, which was likely the “official unveiling” of the security hardware we discussed on Data Center Knowledge in January. On Thursday, some Google Cloud Platform engineers posted a blog detailing how Titan works to make its data centers more secure.

Titan consists of a secure application processor, a cryptographic co-processor, a hardware random number generator, a sophisticated key hierarchy, embedded static RAM (SRAM), embedded flash and a read-only memory block. According to Google, its main purpose is “to ensure that a machine boots from a known good state using verifiable code and establishes the hardware root of trust for cryptographic operations in our data centers.”

This type of protection has grown increasingly important, not only to stop traditional black hats motivated by profit, but to repel governments — both foreign and domestic — that have been successfully devising methods to exploit firmware vulnerabilities, sometimes in ways that can survive re-installation of an operating system.

See also: Google Shares New Details About its TPU Machine Learning Chips

Interestingly, the GCP engineers said that before verifying the validity of code on the host server, Titan runs something of a self-diagnostic to make sure it hasn’t been compromised:

“Titan’s application processor immediately executes code from its embedded read-only memory when its host machine is powered up. The fabrication process lays down immutable code, known as the boot ROM, that is trusted implicitly and validated at every chip reset. Titan runs a Memory Built-In Self-Test every time the chip boots to ensure that all memory (including ROM) has not been tampered with. The next step is to load Titan’s firmware. Even though this firmware is embedded in the on-chip flash, the Titan boot ROM does not trust it blindly. Instead, the boot ROM verifies Titan’s firmware using public key cryptography, and mixes the identity of this verified code into Titan’s key hierarchy. Then, the boot ROM loads the verified firmware.”

At this point, Titan verifies the contents of the host’s boot firmware using public key cryptography:

“Holding the machine in reset while Titan cryptographically verifies the boot firmware provides us the first-instruction integrity property: we know what boot firmware and OS booted on our machine from the very first instruction. In fact, we even know which microcode patches may have been fetched before the boot firmware’s first instruction. Finally, the Google-verified boot firmware configures the machine and loads the boot loader, which subsequently verifies and loads the operating system.”

Google also explains how Titan gives each machine its own cryptographic identity:

“The Titan chip manufacturing process generates unique keying material for each chip, and securely stores this material … into a registry database. The contents of this database are cryptographically protected using keys maintained in an offline quorum-based Titan Certification Authority (CA). Individual Titan chips can generate Certificate Signing Requests (CSRs) directed at the Titan CA, which … can verify the authenticity of the CSRs using the information in the registry database before issuing identity certificates.”

According to Google, this process not only verifies the identity of the chips generating the CSRs, but verifies the firmware running on the chips as well.

“This property enables remediation and allows us to fix bugs in Titan firmware, and issue certificates that can only be wielded by patched Titan chips.”

As security issues continue to grow, it would probably be good to bet that hardware solutions such as this will soon become the norm.