Secure Compilation of Constant-Resource Programs

Barthe, Gilles; Blazy, Sandrine; Hutin, Rémi; Pichardie, David

doi:10.1109/csf51468.2021.00020

Cited by 6 publications

(3 citation statements)

References 24 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…However, they disallow secret branches, increasing the difficulty of implementing constant-time programs. Follow-up work includes constant-resource preserving compilation [9]. However, neither of them considered JIT compilation which is far more complex than the static compilation.…”

Section: Related Workmentioning

confidence: 99%

“…However, constant-time programs may be still vulnerable in practice if the runtime environment is not fully captured by constant-time models. For instance, static compilation from high-/intermediate-level programs to low-level counterparts can destruct constant-time security [8][9][10]; constant-time executable programs are vulnerable in modern processors due to, e.g., speculative or out-of-order execution [18,32,36]; JIT compilation makes constant-time bytecode vulnerable [14,16], called JIT-induced leaks hereafter. In this work, we focus on JIT-induced leaks.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Preventing Timing Side-Channels via Security-Aware Just-In-Time Compilation

Qin¹,

JulianAndres²,

Fu³

et al. 2022

Preprint

View full text Add to dashboard Cite

Recent work has shown that Just-In-Time (JIT) compilation can introduce timing side-channels to constant-time programs, which would otherwise be a principled and effective means to counter timing attacks. In this paper, we propose a novel approach to eliminate JIT-induced leaks from these programs. Specifically, we present an operational semantics and a formal definition of constant-time programs under JIT compilation, laying the foundation for reasoning about programs with JIT compilation. We then propose to eliminate JIT-induced leaks via a fine-grained JIT compilation for which we provide an automated approach to generate policies and a novel type system to show its soundness. We develop a tool DeJITLeak for Java based on our approach and implement the fine-grained JIT compilation in HotSpot. Experimental results show that DeJITLeak can effectively and efficiently eliminate JIT-induced leaks on three datasets used in side-channel detection.

show abstract

Section: Related Workmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Preventing Timing Side-Channels via Security-Aware Just-In-Time Compilation

Qin¹,

JulianAndres²,

Fu³

et al. 2022

Preprint

View full text Add to dashboard Cite

show abstract

“…Secure compilation of information-flow guarantees A long line of work [8,9,10,11,12,34,44,45] develops proof techniques and verified compilers to ensure that information flow properties like non-interference, the constant-time policy, or side-channel resistance are preserved by compilation. These techniques, however, are all concerned with whole-programs, unlike our work that starts with the premise that partial programs will interact with untrusted code.…”

Section: Related Workmentioning

confidence: 99%

SecurePtrs: Proving Secure Compilation with Data-Flow Back-Translation and Turn-Taking Simulation

El-Korashy¹,

Blanco²,

Thibault³

et al. 2021

Preprint

View full text Add to dashboard Cite

Proving secure compilation of partial programs typically requires back-translating a target attack against the compiled program to an attack against the source program. To prove this back-translation step, one can syntactically translate the target attacker to a source one-i.e., syntax-directed backtranslation-or show that the interaction traces of the target attacker can also be produced by source attackers-i.e., tracedirected back-translation.Syntax-directed back-translation is not suitable when the target attacker uses unstructured control flow that the source language cannot directly represent. Trace-directed back-translation works with such syntactic dissimilarity because only the external interactions of the target attacker have to be mimicked in the source, not its internal control flow. Revealing only external interactions is, however, inconvenient when sharing memory via unforgeable pointers, since information about stashed pointers to shared memory gets lost. This made prior proofs complex, since the generated attacker had to stash all reachable pointers.In this work, we introduce more informative data-flow traces, which allow us to combine the best of syntax-directed and trace-directed back-translation. Our data-flow back-translation is simple, handles both syntactic dissimilarity and memory sharing well, and we have proved it correct in Coq.We, moreover, develop a novel turn-taking simulation relation and use it to prove a recomposition lemma, which is key to reusing compiler correctness in such secure compilation proofs. We are the first to mechanize such a recomposition lemma in a proof assistant in the presence of memory sharing.We put these two key innovations to use in a secure compilation proof for a code generation compiler pass between a safe source language with pointers and components, and a target language with unstructured control flow.

show abstract