Binsec/Rel: Efficient Relational Symbolic Execution for Constant-Time at Binary-Level

Daniel, Lesly-Ann; Bardin, Sébastien; Rezk, Tamara

doi:10.1109/sp40000.2020.00074

Cited by 44 publications

(48 citation statements)

References 70 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Proof (Sketch). The proof is a simple extension of the proofs of correctness and completeness of RelSE for constant-time [16], to the speculative semantics. The extension requires to show that 1) violations reported on transient paths in the symbolic execution correspond to violations in concrete transient execution, and 2) if there is a violation in concrete transient execution, then there is a path in symbolic execution that reports this violation.…”

Section: Theoremsmentioning

confidence: 99%

“…Symbolic analyzers for Spectre-PHT [3], [4], [12] and Spectre-STL [5] model the speculative behavior explicitly, by forking the execution to explore transient paths, which quickly leads to state explosion-especially for Spectre-STL which has to fork for each possible store and load interleaving. The adaptation of symbolic execution to constant-time-like properties, known as relational symbolic execution (RelSE), has proven very successful in terms of scalability and precision for binary level [16]. In order to address C2, our key technical insight is to adapt RelSE to execute transient executions at the same time as regular executions (i.e.…”

Section: Introductionmentioning

confidence: 99%

“…A symbolic array is a function (Array I V) mapping each index i ∈ I to a value v ∈ V with operations: Relational Symbolic Execution (RelSE). RelSE [16], [36] is a promising approach to extend SE for analyzing security properties of two execution traces such as SCT 1 . It symbolically executes two versions of a program in the same symbolic execution instance and maximizes sharing between them.…”

Section: Introductionmentioning

confidence: 99%

“…In RelSE, variables are mapped to relational expressions which are either pairs of symbolic expressions (denoted ϕ l | ϕ r ) when they may depend on secret input; or simple symbolic expressions (denoted ϕ ) when the do not depend on secret input. For the security evaluation of memory accesses and conditional instructions, we use the function secLeak defined in [16] which ensures that a relational expression does not depend on secrets (i.e. that its left and right components are necessarily equal):…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Hunting the Haunter — Efficient Relational Symbolic Execution for Spectre with Haunted RelSE

Daniel¹,

Bardin²,

Rezk³

2021

Proceedings 2021 Network and Distributed System Security Symposium

Self Cite

View full text Add to dashboard Cite

Spectre are microarchitectural attacks which were made public in January 2018. They allow an attacker to recover secrets by exploiting speculations. Detection of Spectre is particularly important for cryptographic libraries and defenses at the software level have been proposed. Yet, defenses correctness and Spectre detection pose challenges due on one hand to the explosion of the exploration space induced by speculative paths, and on the other hand to the introduction of new Spectre vulnerabilities at different compilation stages. We propose an optimization, coined Haunted RelSE, that allows scalable detection of Spectre vulnerabilities at binary level. We prove the optimization semantically correct w.r.t. the more naive explicit speculative exploration approach used in state-of-the-art tools. We implement Haunted RelSE in a symbolic analysis tool, and extensively test it on a wellknown litmus testset for Spectre-PHT, and on a new litmus testset for Spectre-STL, which we propose. Our technique finds more violations and scales better than state-of-the-art techniques and tools, analyzing real-world cryptographic libraries and finding new violations. Thanks to our tool, we discover that indexmasking-a standard defense for Spectre-PHT-and well-known gcc options to compile position independent executables introduce Spectre-STL violations. We propose and verify a correction to index-masking to avoid the problem. addresses the Store to Load (STL) variant (a.k.a Spectre-v4 [13]), which exploits the memory dependence predictor. Unfortunately, Pitchfork does not scale for analyzing Spectre-STL, even on small programs (cf. Table IV). Other variants are currently out-of-scope of static analyzers (see Sections II and VII). Goal and challenges. In this paper, we propose a novel technique to detect Spectre-PHT and Spectre-STL vulnerabilities and we implement it in a new static analyzer for binary code. Two challenges arise in the design of such an analyzer: C1 First, the details of the microarchitecture cannot be fully included in the analysis because they are not public in general and not easy to obtain. Yet the challenge is to find an abstraction powerful enough to capture side channels attacks due to microarchitectural state. C2 Second, exploration of all possible speculative executions does not scale because it quickly leads to state explosion. The challenge is how to optimize this exploration in order to make the analysis applicable to real code. Proposal. We tackle challenge C1 by targeting a relational security property coined in the literature as speculative constanttime [5], a property reminiscent of constant-time [14], widely used in cryptographic implementations. Speculative constanttime takes speculative executions into account without explicitly modeling intrincate microarchitectural details. However, it is well known that constant-time programming is not necessarily preserved by compilers [15], [16], so our analysis operates at binary level-besides, it is compiler-agnostic and does not require source code. For thi...

show abstract

Section: Theoremsmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Hunting the Haunter — Efficient Relational Symbolic Execution for Spectre with Haunted RelSE

Daniel¹,

Bardin²,

Rezk³

2021

Proceedings 2021 Network and Distributed System Security Symposium

Self Cite

View full text Add to dashboard Cite

show abstract

“…due to cache behavior. While this verification traditionally amounted to manual scrutiny of the generated assembly code by cryptographic engineers, recent work has shown progress in automatic verification to alleviate this burden [38,7,3,6,20,22].…”

Section: Contributionsmentioning

confidence: 99%

Certified Compilation for Cryptography: Extended x86 Instructions and Constant-Time Verification

Almeida

Barbosa

Barthe

et al. 2020

Progress in Cryptology – INDOCRYPT 2020

View full text Add to dashboard Cite

We present a new tool for the generation and verification of high-assurance high-speed machine-level cryptography implementations: a certified C compiler supporting instruction extensions to the x86. We demonstrate the practical applicability of our tool by incorporating it into supercop: a toolkit for measuring the performance of cryptographic software, which includes over 2000 different implementations. We show i. that the coverage of x86 implementations in supercop increases significantly due to the added support of instruction extensions via intrinsics and ii. that the obtained verifiably correct implementations are much closer in performance to unverified ones. We extend our compiler with a specialized type system that acts at pre-assembly level; this is the first constant-time verifier that can deal with extended instruction sets. We confirm that, by using instruction extensions, the performance penalty for verifiably constant-time code can be greatly reduced.

show abstract

Not All Bugs Are Created Equal, But Robust Reachability Can Tell the Difference

Girol

Farinier

Bardin

2021

Computer Aided Verification

View full text Add to dashboard Cite

This paper introduces a new property called robust reachability which refines the standard notion of reachability in order to take replicability into account. A bug is robustly reachable if a controlled input can make it so the bug is reached whatever the value of uncontrolled input. Robust reachability is better suited than standard reachability in many realistic situations related to security (e.g., criticality assessment or bug prioritization) or software engineering (e.g., replicable test suites and flakiness). We propose a formal treatment of the concept, and we revisit existing symbolic bug finding methods through this new lens. Remarkably, robust reachability allows differentiating bounded model checking from symbolic execution while they have the same deductive power in the standard case. Finally, we propose the first symbolic verifier dedicated to robust reachability: we use it for criticality assessment of 4 existing vulnerabilities, and compare it with standard symbolic execution.

show abstract

Binsec/Rel: Efficient Relational Symbolic Execution for Constant-Time at Binary-Level

Cited by 44 publications

References 70 publications

Hunting the Haunter — Efficient Relational Symbolic Execution for Spectre with Haunted RelSE

Hunting the Haunter — Efficient Relational Symbolic Execution for Spectre with Haunted RelSE

Certified Compilation for Cryptography: Extended x86 Instructions and Constant-Time Verification

Not All Bugs Are Created Equal, But Robust Reachability Can Tell the Difference

Contact Info

Product

Resources

About