CryptoDB
In Band Key Negotiation: Trusting the Attacker
Authors: | |
---|---|
Download: | |
Abstract: | 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. |
Video: | https://youtu.be/CiH6iqjWpt8?t=1028 |
BibTeX
@misc{rwc-2021-35549, title={In Band Key Negotiation: Trusting the Attacker}, note={Video at \url{https://youtu.be/CiH6iqjWpt8?t=1028}}, howpublished={Talk given at RWC 2021}, author={Sophie Schmieg and Thai Duong}, year=2021 }