Titan: a custom TPM and more

I listened to a podcast and cut out the chit-chat, so you don’t have to:

Titan is a tiny security co-processing chip used for encryption, authentication of hardware, authentication of services.


Every piece of hardware in google’s infrastructure can be individually identified and cryptographically verified, and any service using it mutually authenticates to that hardware. This includes servers, networking cards, switches: everything. The Titan chip is one of the ways to accomplish that.

The chip certifies that hardware is in a trusted good state. If this verification fails, the hardware will not boot, and will be replaced.

Every time a new bios is pushed, Titan checks that the code is authentic Google code before allowing it to be installed.  It then checks each time that code is booted that it is authentic, before allowing boot to continue.

‘similar in theory to the u2f security keys, everything should have identity, hardware and software. Everything’s identity is checked all the time.’

Suggestions that it plays important role in hardware level data encryption, key management systems, etc.


Each chip is fused with a unique identifier. Done sequentially, so can verify it’s part of inventory sequence.

Three main functions: RNG, crypto engine, and monotonic counter. First two are self-explanatory. Monotonic counter to protect against replay attacks, and make logs tamper evident.

Sits between ROM and RAM, to provide signature valididation of the first 8KB of BIOS on installation and boot up.


Produced entirely within google. Design and process to ensure provenance. Have used other vendor’s security coprocessors in the past, but want to ensure they understand/know the whole truth.

Google folks unaware of any other cloud that uses TPMs, etc to verify every piece of hardware and software running on it.

Challenges in Authenticated Encryption

Authenticated encryption is the cryptographer’s front-line defense against attackers. It is the
protective shield applied to every network packet. It is the foundation of security for medical
devices, connected vehicles, the financial sector, the smart grid, and the Internet of Things.
But is this shield actually being used? Is it actually working? Is it doing what the users
actually need? Are industry practitioners listening to researchers? Are researchers listening
to industry practitioners?
This white paper identifies critical ongoing problems whose solutions will need concerted
community effort stretching years into the future. The challenges described in this white
paper are classified into four categories:
• Chapter 1: The security target is wrong.
• Chapter 2: The interface is wrong.
• Chapter 3: The performance target is wrong.
• Chapter 4: Mistakes and malice.
This white paper does not mean to suggest that authenticated ciphers are always aiming at
the wrong target. It is important to understand that, for many environments today, using
an existing standard such as AES-128-GCM [19] is simple, safe, and efficient. However, it is
equally important to understand that the existing standards fail to meet the needs of many
other environments. The AES cipher [10] and the AES-GCM authenticated cipher are used
as examples throughout this document to illustrate what can and does go wrong.

Source: https://chae.cr.yp.to/chae-20170301.pdf

AES-GCM-SIV: Specification and Analysis

Abstract. In this paper, we describe and analyze the security of the AES-GCM-SIV mode of operation, as defined in the CFRG specification [10]. This mode differs from the original GCM-SIV mode that was designed in [11] in two main aspects. First, the CTR encryption uses a 127-bit pseudo-random counter instead of a 95-bit pseudo-random value concatenated with a 32-bit counter. This construction leads to improved security bounds when encrypting short messages. In addition, a new key derivation function is used for deriving a fresh set of keys for each nonce. This addition allows for encrypting up to 250 messages with the same key, compared to the significant limitation of only 232 messages that were allowed with GCM-SIV (which inherited this same limit from AES-GCM). As a result, the new construction is well suited for real world applications that need a nonce-misuse resistant Authenticated Encryption scheme. We explain the limitations of GCM-SIV, which motivate the new construction, prove the security properties of AES-GCM-SIV, and show how these properties support real usages. Implementations are publicly available in [8]. We remark that AES-GCM-SIV is already integrated into Google’s BoringSSL library [1], and its deployment for ticket encryption in QUIC [16] is underway.

Source: https://eprint.iacr.org/2017/168.pdf

Neither Snow Nor Rain Nor MITM . . . An Empirical Analysis of Email Delivery Security

The SMTP protocol is responsible for carrying some of users most intimate communication, but like other Internet protocols, authentication and confidentiality were added only as an afterthought. In this work, we present the first report on global adoption rates of SMTP security extensions, including: STARTTLS, SPF, DKIM, and DMARC. We present data from two perspectives: SMTP server configurations for the Alexa Top Million domains, and over a year of SMTP connections to and from Gmail. We find that the top mail providers (e.g., Gmail, Yahoo, and Outlook) all proactively encrypt and authenticate messages. However, these best practices have yet to reach widespread adoption in a long tail of over 700,000 SMTP servers, of which only 35% successfully configure encryption, and 1.1% specify a DMARC authentication policy. This security patchwork — paired with SMTP policies that favor failing open to allow gradual deployment — exposes users to attackers who downgrade TLS connections in favor of cleartext and who falsify MX records to reroute messages. We present evidence of such attacks in the wild, highlighting seven countries where more than 20% of inbound Gmail messages arrive in cleartext due to network attackers.

Source: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/43962.pdf

CONIKS: Bringing Key Transparency to End Users

We present CONIKS, an end-user key verification service capable of integration in end-to-end encrypted communication systems. CONIKS builds on transparency log proposals for web server certificates but solves several new challenges specific to key verification for end users. CONIKS obviates the need for global third-party monitors and enables users to efficiently monitor their own key bindings for consistency, downloading less than 20 kB per day to do so even for a provider with billions of users. CONIKS users and providers can collectively audit providers for non-equivocation, and this requires downloading a constant 2.5 kB per provider per day. Additionally, CONIKS preserves the level of privacy offered by today’s major communication services, hiding the list of usernames present and even allowing providers to conceal the total number of users in the system.

Source: https://eprint.iacr.org/2014/1004.pdf

Post-quantum key exchange – a new hope∗

At IEEE Security & Privacy 2015, Bos, Costello, Naehrig, and Stebila proposed an instantiation of Peikert’s ring-learning-with-errors–based (Ring-LWE) key-exchange protocol (PQCrypto 2014), together with an implementation integrated into OpenSSL, with the affirmed goal of providing post-quantum security for TLS. In this work we revisit their instantiation and stand-alone implementation. Specifically, we propose new parameters and a better suited error distribution, analyze the scheme’s hardness against attacks by quantum computers in a conservative way, introduce a new and more efficient error-reconciliation mechanism, and propose a defense against backdoors and all-for-the-price-of-one attacks. By these measures and for the same lattice dimension, we more than double the security parameter, halve the communication overhead, and speed up computation by more than a factor of 8 in a portable C implementation and by more than a factor of 27 in an optimized implementation targeting current Intel CPUs. These speedups are achieved with comprehensive protection against timing attacks.

Source: https://eprint.iacr.org/2015/1092.pdf

Encryption at Rest in Google Cloud Platform

In this whitepaper, you will find more detail on Google’s key hierarchy and root of trust, as well as information on the granularity of encryption in specific GCP services for data at rest (this document does not cover encryption in transit). For all Google products, we strive to keep customer data highly protected, and to be as transparent as possible about how we secure it.
The content contained herein is correct as of August 2016, and represents the status quo as of the time it was written. Google Cloud Platform’s security policies and systems may change going forward, as we continually improve protection for our customers.

Source: https://cloud.google.com/security/encryption-at-rest/resources/encryption-whitepaper.pdf