High-Assurance Cryptography in the Spectre Era

Abstract

High-assurance cryptography leverages methods from program verification and cryptography engineering to deliver efficient cryptographic software with machine-checked proofs of memory safety, functional correctness, provable security, and absence of timing leaks. Traditionally, these guarantees are established under a sequential execution semantics. However, this semantics is not aligned with the behavior of modern processors that make use of speculative execution to improve performance. This mismatch, combined with the high-profile Spectre-style attacks that exploit speculative execution, naturally casts doubts on the robustness of high-assurance cryptography guarantees. In this paper, we dispel these doubts by showing that the benefits of high-assurance cryptography extend to speculative execution, costing only a modest performance overhead. We build atop the Jasmin verification framework an end-to-end approach for proving properties of cryptographic software under speculative execution, and validate our approach experimentally with efficient, functionally correct assembly implementations of ChaCha20 and Poly1305, which are secure against both traditional timing and speculative execution attacks.[5], [6], [7], [10] either consider weaker threat models or are not proven sound). Following an established approach, our method is decomposed into two steps: (i) check that the program does not perform illegal memory accesses under

Relational Models of Microarchitectures for Formal Security Analyses

“…LCMs support branching on secrets and are not limited to reasoning about vulnerabilities involving transient execution nor are they limited to capturing just a single Spectre variant. Pitchfork [17] detects SPECTRE V1/V4; however, its implementation is unsound [10], and its SPECTRE V4 detection scheme scales poorly.…”

SoK: Practical Foundations for Software Spectre Defenses

“…Like the constant-time programming model in the non-speculative world, the • ct leakage model is strong and hardware-agnostic, making it a solid foundation for security guarantees. The • ct leakage model is a popular choice among existing formalizations: As we highlight in Figure 2, over half of the formal semantics for Spectre use the • ct leakage model (or an equivalent) [8,16,21,27,28,55,67]. Guarnieri et al [29] leave the leakage model abstract, allowing the semantics to be used with several different leakage models, including • ct .…”

“…This makes it ideal for domains that already have clear policies about what data is sensitive, such as cryptography (e.g., secret keys) or software isolation (e.g., memory outside the sandbox). Indeed, tools that target cryptographic applications ( [8,16,21,67]) all verify that programs satisfy the direct speculative constant-time (SCT) property.…”

“…(Mis)predictions from the conditional branch predictor are constrained-there are only two possible choices for every decision-so the analysis remains fairly tractable. Jasmin [8], Binsec/Haunted [21], and Pitchfork [16] all additionally model storeto-load (STL) predictions, where a processor forwards data to a memory load from a prior store to the same address. If there are multiple pending stores to that address, the processor may choose the wrong store to forward the data-this is the root of a Spectre-STL attack.…”

“…5 The definition of wSNI in [29] does not require that the initial states be low-equivalent. Speculation windows are also valuable for mitigation tools: although tools like Blade [67] and Jasmin [8] are able to prove security without reasoning about speculation windows, modeling a speculation window would reduce the number of fences (or other mitigations) these tools need to insert, improving the performance of the compiled code.…”