STIR/SHAKEN: A Cocktail of Cryptographic Clumsiness

Scams and fraudulent robocalls are rampant in the telephone system. Fraudsters often employ call spoofing to impersonate a known caller to the victim, making it difficult to detect and block the fraudster's calls. In an effort to combat call spoofing, the U.S. government mandated the use of a new suite of protocols called STIR/SHAKEN in 2019. STIR/SHAKEN is, at its core, a system that uses cryptography for abuse prevention. Providers include a cryptographically-signed assertion about the caller's identity and other metadata in call headers. This serves both to authentically convey this metadata between providers during call routing and to provide reportable, verifiable evidence of bad behavior by providers that originate fraudulent calls. The purpose of this paper is to investigate the security and privacy of STIR/SHAKEN and to assess its impact on the security and privacy of the telephone system. We find that STIR/SHAKEN is deeply harmful to user privacy and has severe security issues both in its design and implementation. We identify two main issues in the design of STIR/SHAKEN. First, signing call metadata renders it cryptographically non-repudiable. Second, STIR/SHAKEN has led to widespread new leakage of sensitive call metadata to off-path third parties. We also identify a number of issues in specific parts of STIR/SHAKEN, such as the PKI. We investigated STIR/SHAKEN implementations using several different techniques. We survey 29 providers about their STIR/SHAKEN experiences, did large-scale traffic measurements, including STIR/SHAKEN certificates, at a real telephone provider, and manually tested several STIR/SHAKEN implementations. Among our findings are that severely malformed certificates are common, and that some STIR/SHAKEN implementations completely break the federally-mandated *67 caller-privacy mechanism. Finally, we propose solutions to many of the issues we identified. We design a backwards-compatible key discovery mechanism that uses SIP error messages. We also design the first blind signing protocol for the asymmetric message franking (AMF) construction of Tyagi et al., and introduced new security definitions to capture novel security requirements we identify for the setting, such as verifier-hiding blindness. To our knowledge, in this effort we have initiated the formal study of blind signing for designated-verifier signatures.