17 research outputs found
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
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
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
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
Recommended from our members
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
Recommended from our members
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
Recommended from our members
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