Constant-Time Foundations for the New Spectre Era Sunjay Cauligiy Craig Disselkoeny Klaus v. Gleissenthally Dean Tullseny Deian Stefany Tamara Rezk? Gilles Barthe♠| yUC San Diego, USA ?INRIA Sophia Antipolis, France ♠MPI for Security and Privacy, Germany |IMDEA Software Institute, Spain Abstract 1 Introduction The constant-time discipline is a software-based countermea- Protecting secrets in software is hard. Security and cryptog- sure used for protecting high assurance cryptographic imple- raphy engineers must write programs that protect secrets, mentations against timing side-channel attacks. Constant- both at the source level and when they execute on real hard- time is effective (it protects against many known attacks), ware. Unfortunately, hardware too easily divulges informa- rigorous (it can be formalized using program semantics), and tion about a program’s execution via timing side-channels— amenable to automated verification. Yet, the advent of micro- e.g., an attacker can learn secrets by simply observing (via architectural attacks makes constant-time as it exists today timing) the effects of a program on the hardware cache[16]. far less useful. The most robust way to deal with timing side-channels This paper lays foundations for constant-time program- is via constant-time programming—the paradigm used to im- ming in the presence of speculative and out-of-order exe- plement almost all modern cryptography [2, 11, 12, 26, 27]. cution. We present an operational semantics and a formal Constant-time programs can neither branch on secrets nor definition of constant-time programs in this extended setting. access memory based on secret data.1 These restrictions Our semantics eschews formalization of microarchitectural ensure that programs do not leak secrets via timing side- features (that are instead assumed under adversary control), channels on hardware without microarchitectural features. and yields a notion of constant-time that retains the ele- Unfortunately, these guarantees are moot for most modern gance and tractability of the usual notion. We demonstrate hardware: Spectre [20], Meltdown [22], ZombieLoad [29], the relevance of our semantics in two ways: First, by con- RIDL [32], and Fallout [5] are all dramatic examples of attacks trasting existing Spectre-like attacks with our definition of that exploit microarchitectural features. These attacks reveal constant-time. Second, by implementing a static analysis that code that is deemed constant-time in the usual sense tool, Pitchfork, which detects violations of our extended may, in fact, leak information on processors with microar- constant-time property in real world cryptographic libraries. chitectural features. The decade-old constant-time recipes are no longer enough.2 CCS Concepts: • Security and privacy ! Formal secu- In this work, we lay the foundations for constant-time in rity models; Side-channel analysis and countermeasures. the presence of microarchitectural features that have been Keywords: Spectre; speculative execution; semantics; static exploited in recent attacks: out-of-order and speculative ex- analysis ecution. We focus on constant-time for two key reasons. First, impact: constant-time programming is largely used in ACM Reference Format: real-world crypto libraries—and high-assurance code—where Sunjay Cauligi, Craig Disselkoen, Klaus v. Gleissenthall, Dean developers already go to great lengths to eliminate leaks via Tullsen, Deian Stefan, Tamara Rezk, and Gilles Barthe. 2020. Constant- side-channels. Second, foundations: constant-time program- Time Foundations for the New Spectre Era. In Proceedings of the 41st ming is already rooted in foundations, with well-defined ACM SIGPLAN International Conference on Programming Language semantics [4, 8]. These semantics consider very powerful Design and Implementation (PLDI ’20), June 15–20, 2020, London, attackers—e.g., attackers in [4] have control over the cache UK. ACM, New York, NY, USA, 20 pages. https://doi.org/10.1145/ and the scheduler. An advantage of considering powerful 3385412.3385970 attackers is that the semantics can overlook many hardware details—e.g., since the cache is adversarially controlled, there Permission to make digital or hard copies of part or all of this work for is no point in modeling it precisely—making constant-time personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies amenable to automated verification and enforcement. bear this notice and the full citation on the first page. Copyrights for third- Contributions. We first define a semantics for an abstract, party components of this work must be honored. For all other uses, contact three-stage (fetch, execute, and retire) machine. Our machine the owner/author(s). PLDI ’20, June 15–20, 2020, London, UK 1More generally, constant-time programs cannot use secret data as input to © 2020 Copyright held by the owner/author(s). any variable-time operation—e.g., floating-point multiplication. ACM ISBN 978-1-4503-7613-6/20/06. 2OpenSSL found this situation so hopeless that they recently updated their https://doi.org/10.1145/3385412.3385970 security model to explicitly exclude “physical system side channels” [25]. PLDI ’20, June 15–20, 2020, London, UK S. Cauligi, C. Disselkoen, K. v. Gleissenthall, D. Tullsen, D. Stefan, T. Rezk, and G. Barthe supports out-of-order and speculative execution by model- before evaluating the branch condition. In that case, the pro- ing reorder buffers and transient instructions, respectively. cessor guesses which branch will be taken. For example, the We assume that attackers have complete control over mi- processor may erroneously guess that the branch condition croarchitectural features (e.g., the branch target predictor) at line 1 evaluates to true, even though ra contains value 9. It when executing a victim program and model the attacker’s will therefore continue down the “true” branch speculatively. control over predictors using directives. This keeps our se- In hardware, such guesses are made by a branch prediction mantics simple yet powerful: our semantics abstracts over unit, which may have been mistrained by an adversary. all predictors when proving security—of course, assuming These guesses, as well as additional choices such as exe- that predictors themselves do not leak secrets. We further cution order, are directly supplied by the adversary in our show how our semantics can be extended to capture new semantics. We model this through a series of directives, as predictors—e.g., a hypothetical memory aliasing predictor. shown on the bottom left of Figure1. The directive fetch: true We then define speculative constant-time, an extension of instructs our model to speculatively follow the true branch constant-time for machines with out-of-order and specula- and to place the fetched instruction at index 1 in the reorder tive execution. This definition allows us to discover microar- buffer. Similarly, the two following fetch directives place the chitectural side channels in a principled way—all four classes loads at indices 2 and 3 in the buffer. The instructions in the of Spectre attacks as classified by Canella et al.[6], for ex- reorder buffer, called transient instructions, do not necessarily ample, manifest as violations of our constant-time property. match the original instructions, but can contain additional We further use our semantics as the basis for a prototype information (see Table1). For instance, the transient version analysis tool, Pitchfork, built on top of the angr symbolic of the branch instruction records which branch has been execution engine [30]. Like other symbolic analysis tools, speculatively taken. Pitchfork suffers from path explosion, which limits the depth In our example, the attacker next instructs the model to of speculation we can analyze. Nevertheless, we are able to execute the first load, using the directive execute 2. Because use Pitchfork to detect multiple Spectre bugs in real code. the bounds check has not yet been executed, the load reads We use Pitchfork to detect leaks in the well-known Kocher from the secret element Key»1¼, placing the value in rb . The test cases [19] for Spectre v1, as well as our more exten- attacker then issues directive execute 3 to execute the fol- sive test suite which includes Spectre v1.1 variants. More lowing load; this load’s address is calculated as 44 + Key»1¼. significantly, we use Pitchfork to analyze—and find leaks Accessing this address affects externally visible cache state, in—real cryptographic code from the libsodium, OpenSSL, allowing the attacker to recover Key»1¼ through a cache side- and curve25519-donna libraries. channel attack [16]. This is encoded by the leakage observa- Open source. Pitchfork and our test suites are open source tion shown in red on the bottom right. Though this secret and available at https://pitchfork.programming.systems. leakage cannot happen under sequential execution, our se- mantics clearly highlights the possible leak when we account 2 Motivating Examples for microarchitectural features. In this section, we show why classical constant-time pro- Modeling hypothetical attacks. Next, we give an example gramming is insufficient when attackers can exploit microar- of a hypothetical class of Spectre attack captured by our chitectural features. We do this via two example attacks and extended semantics. The attack is based on a microarchi- show how these attacks are captured by our semantics. tectural feature which would allow processors to speculate Classical constant time is not enough. Our first example whether a store and load pair might operate on the same consists of 3 lines of code, shown in Figure1 (top right). The address, and forward values between them [18, 28]. program, a variant of the classical Spectre v1 attack [20], We demonstrate this attack in Figure2. The reorder buffer, branches on the value of register ra (line 1). If ra’s value after all instructions have been fetched, is shown in the top is smaller than 4, the program jumps to program location right.