International Association
for Cryptologic Research

In this talk we will present challenges Google faces with key management, and how we built a system to instrument our cryptographic libraries to gain extensive observability into how our services use cryptographic key material in practice. This allows us to enforce best practices like key rotation, deleting old keys and respecting data limits, across global large scale distributed systems. Within Google, our tooling covers thousands of internal teams with diverse use cases, improving both security and reliability on a large scale. This talk also shows how we deployed post-quantum cryptography to Google's internal transport layer security protocol (ALTS), and made it the default option. We will talk about the challenges, both technical and organisational when making such a large-scale change to a global infrastructure as run by Google. We will share insights on the performance impact and discuss our design decisions and trade-offs.

In order to evaluate a privileged cryptographic primitive, say decrypt a ciphertext or check a signature, an endpoint needs to know the raw key material, the algorithm including all parameters, and the ciphertext/signature. For example, JWT contains an algorithm field that dictates how it should be verified. This seemingly innocuous design has led to countless broken implementations and vulnerabilities, including the infamous "alg: None". While the security community likes to pick on JWT, we show that JWT is not the only system that succumbs to what we call in-band protocol negotiation attacks. We display a showcase of old and new attacks in widely deployed standards and systems, including AWS S3 Crypto SDK (CVE-2020-8912), AWS Encryption SDK and AWS KMS (under embargo). We show that not only the algorithm field can cause problems, but even a mundane detail such as the ciphertext format can also lead to weaknesses. We found that the root cause of these vulnerabilities is a failure to answer this basic question: what is a key? Many systems, standards, or libraries consider a key consisting of only the raw secret material. A secret key material, however, is usually not enough to instantiate a protocol, forcing people to store other parameters in the ciphertext, i.e., doing in-band protocol negotiation. We present how Google uses Tink to ensure that even software that has not been reviewed by cryptography engineers will not be vulnerable to this class of attack.