A Turning Point for Verified Spectre Sandboxing

Spectre attacks enable an attacker to access restricted data in an application's memory. Both the academic community and industry veterans have developed several mitigations to block Spectre attacks, but to date, very few have been formally vetted; most are "best effort" strategies. Formal guarantees are particularly crucial for protecting isolated environments like sandboxing against Spectre attacks. In such environments, a subtle flaw in the mitigation would allow untrusted code to break out of the sandbox and access trusted memory regions. In our work, we develop principled foundations to build isolated environments resistant against Spectre attacks. We propose a formal framework for reasoning about sandbox execution and Spectre attacks. We formalize properties that sound mitigation strategies must fulfill and we show how various existing mitigations satisfy (or fail to satisfy!) these properties

Robust Constant-Time Cryptography

The constant-time property is considered the security standard for cryptographic code. Code following the constant-time discipline is free from secret-dependent branches and memory accesses, and thus avoids leaking secrets through cache and timing side-channels. The constant-time property makes a number of implicit assumptions that are fundamentally at odds with the reality of cryptographic code. Constant-time is not robust. The first issue with constant-time is that it is a whole-program property: It relies on the entirety of the code base being constant-time. But, cryptographic developers do not generally write whole programs; rather, they provide libraries and specific algorithms for other application developers to use. As such, developers of security libraries must maintain their security guarantees even when their code is operating within (potentially untrusted) application contexts. Constant-time requires memory safety. The whole-program nature of constant-time also leads to a second issue: constant-time requires memory safety of all the running code. Any memory safety bugs, whether in the library or the application, will wend their way back to side-channel leaks of secrets if not direct disclosure. And although cryptographic libraries should (and are) written to be memory-safe, it is unfortunately unrealistic to expect the same from every application that uses each library. We formalize robust constant-time and build a RobustIsoCrypt compiler that transforms the library code and protects the secrets even when they are linked with untrusted code. Our evaluation with SUPERCOP benchmarking framework shows that the performance overhead is less than five percent on average

CT-Wasm: Type-Driven Secure Cryptography for the Web Ecosystem

A significant amount of both client and server-side cryptography is implemented in JavaScript. Despite widespread concerns about its security, no other language has been able to match the convenience that comes from its ubiquitous support on the "web ecosystem" - the wide variety of technologies that collectively underpins the modern World Wide Web. With the introduction of the new WebAssembly bytecode language (Wasm) into the web ecosystem, we have a unique opportunity to advance a principled alternative to existing JavaScript cryptography use cases which does not compromise this convenience. We present Constant-Time WebAssembly (CT-Wasm), a type-driven, strict extension to WebAssembly which facilitates the verifiably secure implementation of cryptographic algorithms. CT-Wasm's type system ensures that code written in CT-Wasm is both information flow secure and resistant to timing side channel attacks; like base Wasm, these guarantees are verifiable in linear time. Building on an existing Wasm mechanization, we mechanize the full CT-Wasm specification, prove soundness of the extended type system, implement a verified type checker, and give several proofs of the language's security properties. We provide two implementations of CT-Wasm: an OCaml reference interpreter and a native implementation for Node.js and Chromium that extends Google's V8 engine. We also implement a CT-Wasm to Wasm rewrite tool that allows developers to reap the benefits of CT-Wasm's type system today, while developing cryptographic algorithms for base Wasm environments. We evaluate the language, our implementations, and supporting tools by porting several cryptographic primitives - Salsa20, SHA-256, and TEA - and the full TweetNaCl library. We find that CT-Wasm is fast, expressive, and generates code that we experimentally measure to be constant-time

High-Assurance Cryptography in the Spectre Era

International audienceHigh-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

Spectre Declassified: Reading from the Right Place at the Wrong Time

Practical information-flow programming languages commonly allow controlled leakage via a “declassify” construct—programmers can use this construct to declare intentional leakage. For instance, cryptographic signatures and ciphertexts, which are computed from private keys, are viewed as secret by information-flow analyses. Cryptographic libraries can use declassify to make this data public, as it is no longer sensitive. In this paper, we study the impact of speculative execution in practical information-flow programming languages. First, we show that speculative execution leads to unintended leakage that violates the programmer’s intent. Concretely, we present a PoC that recovers the AES key of an implementation of AES written in FaCT, a domain-specific language for constant-time programming. Our PoC is an instance of a Spectre-PHT attack; interestingly, it remains effective even if the program is compiled with Speculative Load Hardening (SLH), a compiler-based countermeasure against Spectre-PHT. Second, we propose compiler-based countermeasures for protecting programs against leakage, and show that these countermeasures achieve relative non-interference: Informally, speculative leakage of the transformed programs must correspond to sequential leakage of the original programs. One of our countermeasures is a new transformation of independent interest called selective speculative load hardening (selSLH). SelSLH optimizes SLH as implemented by the LLVM compiler, reducing the number of inserted mitigations. Third, we implement one of our countermeasures in the FaCT compiler and evaluate performance overhead for core cryptographic routines from several open-source projects. The results indicate a moderate overhead. Although we do not implement selSLH, we carry a preliminary evaluation which suggests a significant gain over SLH for cryptographic implementations

Foundations for Speculative Side Channels

Developers of high-security systems (e.g., cryptographic libraries, web browsers) mustnot allow sensitive information (e.g., encryption keys, browser cookies) to make its way to an attacker. However, clever attackers can make use of unintentional side-channels—such as timing information or other hardware resource metrics—to infer or leak the values of these secrets. Even worse, attackers can exploit hardware features such as speculative execution to create new vectors for side-channel leakage even where none existed before.Side-channels are not typically captured in formal program semantics—information froma side-channel is leaked to an attacker purely as a side-effect of execution, rather than any explicit data flow. Furthermore, speculative execution fundamentally destroys security properties like memory or type safety, as they implicitly assume a standard sequential execution model. Without formal models to rely on, developers find themselves manually applying ad-hoc mitigations as a best-effort solution to prevent timing side-channels and speculative attacks. Unfortunately, these ad-hoc mitigations often lead to obfuscated code—and yet give no guarantee of a sound or complete defense.This dissertation seeks to remedy this. We explore several formal frameworks that makeside-channel effects explicit, both with and without the threat of speculative execution. Along the way, we introduce FaCT, a language and compiler for writing code free from side-channels; Pitchfork, a semantics and tool for detecting speculative side-channels in binaries; and ZFI, a framework for validating sandbox protections against speculative attacks. In addition to the systems presented in this dissertation, the research community writ large has developed several program analysis and defense tools backed by formal models, whether these models are explicit or implicit. We round out this dissertation by surveying these systems, examining various design choices and identifying areas of open research.Ultimately, this dissertation demonstrates the power of practical, formal foundationswhen dealing with speculative side-channel security. By relying on sound, formal frameworks, high-security developers can write programs that verifiably do not leak sensitive information

Foundations for Speculative Side Channels

Developers of high-security systems (e.g., cryptographic libraries, web browsers) mustnot allow sensitive information (e.g., encryption keys, browser cookies) to make its way to an attacker. However, clever attackers can make use of unintentional side-channels—such as timing information or other hardware resource metrics—to infer or leak the values of these secrets. Even worse, attackers can exploit hardware features such as speculative execution to create new vectors for side-channel leakage even where none existed before.Side-channels are not typically captured in formal program semantics—information froma side-channel is leaked to an attacker purely as a side-effect of execution, rather than any explicit data flow. Furthermore, speculative execution fundamentally destroys security properties like memory or type safety, as they implicitly assume a standard sequential execution model. Without formal models to rely on, developers find themselves manually applying ad-hoc mitigations as a best-effort solution to prevent timing side-channels and speculative attacks. Unfortunately, these ad-hoc mitigations often lead to obfuscated code—and yet give no guarantee of a sound or complete defense.This dissertation seeks to remedy this. We explore several formal frameworks that makeside-channel effects explicit, both with and without the threat of speculative execution. Along the way, we introduce FaCT, a language and compiler for writing code free from side-channels; Pitchfork, a semantics and tool for detecting speculative side-channels in binaries; and ZFI, a framework for validating sandbox protections against speculative attacks. In addition to the systems presented in this dissertation, the research community writ large has developed several program analysis and defense tools backed by formal models, whether these models are explicit or implicit. We round out this dissertation by surveying these systems, examining various design choices and identifying areas of open research.Ultimately, this dissertation demonstrates the power of practical, formal foundationswhen dealing with speculative side-channel security. By relying on sound, formal frameworks, high-security developers can write programs that verifiably do not leak sensitive information

CT-Wasm: Type-Driven Secure Cryptography for the Web Ecosystem

A significant amount of both client and server-side cryptography is implemented in JavaScript. Despite widespread concerns about its security, no other language has been able to match the convenience that comes from its ubiquitous support on the "web ecosystem" - the wide variety of technologies that collectively underpins the modern World Wide Web. With the introduction of the new WebAssembly bytecode language (Wasm) into the web ecosystem, we have a unique opportunity to advance a principled alternative to existing JavaScript cryptography use cases which does not compromise this convenience. We present Constant-Time WebAssembly (CT-Wasm), a type-driven, strict extension to WebAssembly which facilitates the verifiably secure implementation of cryptographic algorithms. CT-Wasm's type system ensures that code written in CT-Wasm is both information flow secure and resistant to timing side channel attacks; like base Wasm, these guarantees are verifiable in linear time. Building on an existing Wasm mechanization, we mechanize the full CT-Wasm specification, prove soundness of the extended type system, implement a verified type checker, and give several proofs of the language's security properties. We provide two implementations of CT-Wasm: an OCaml reference interpreter and a native implementation for Node.js and Chromium that extends Google's V8 engine. We also implement a CT-Wasm to Wasm rewrite tool that allows developers to reap the benefits of CT-Wasm's type system today, while developing cryptographic algorithms for base Wasm environments. We evaluate the language, our implementations, and supporting tools by porting several cryptographic primitives - Salsa20, SHA-256, and TEA - and the full TweetNaCl library. We find that CT-Wasm is fast, expressive, and generates code that we experimentally measure to be constant-time

Constant-Time Foundations for the New Spectre Era

PLDI '20International audienceThe constant-time discipline is a software-based countermeasure used for protecting high assurance cryptographic implementations against timing side-channel attacks. Constant-time is effective (it protects against many known attacks), rigorous (it can be formalized using program semantics), and amenable to automated verification. Yet, the advent of micro-architectural attacks makes constant-time as it exists today far less useful. This paper lays foundations for constant-time programming in the presence of speculative and out-of-order execution. We present an operational semantics and a formal definition of constant-time programs in this extended setting. Our semantics eschews formalization of microarchitectural features (that are instead assumed under adversary control), and yields a notion of constant-time that retains the elegance and tractability of the usual notion. We demonstrate the relevance of our semantics in two ways: First, by contrasting existing Spectre-like attacks with our definition of constant-time. Second, by implementing a static analysis tool, Pitchfork, which detects violations of our extended constant-time property in real world cryptographic libraries