Automatically eliminating speculative leaks from cryptographic code with blade

Vassena, Marco; Disselkoen, Craig; Gleissenthall, Klaus v.; Cauligi, Sunjay; Kıcı, Rami Gökhan; Jhala, Ranjit; Tullsen, Dean M.; Stefan, Deian

doi:10.1145/3434330

Cited by 44 publications

(36 citation statements)

References 40 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Speculative leaks in software. Several tools target detection of speculative leaks in software [8,17,19,32,45,47]. They all rely on (sometimes implicit) assumptions about the speculation in hardware, see [9] for an overview.…”

Section: Related Workmentioning

confidence: 99%

Revizor: testing black-box CPUs against speculation contracts

Oleksenko

Fetzer

Köpf

et al. 2022

Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems

View full text Add to dashboard Cite

Speculative vulnerabilities such as Spectre and Meltdown expose speculative execution state that can be exploited to leak information across security domains via side-channels. Such vulnerabilities often stay undetected for a long time as we lack the tools for systematic testing of CPUs to find them.In this paper, we propose an approach to automatically detect microarchitectural information leakage in commercial black-box CPUs. We build on speculation contracts, which we employ to specify the permitted side effects of program execution on the CPU's microarchitectural state. We propose a Model-based Relational Testing (MRT) technique to empirically assess the CPU compliance with these specifications.We implement MRT in a testing framework called Revizor, and showcase its effectiveness on real Intel x86 CPUs. Revizor automatically detects violations of a rich set of contracts, or indicates their absence. A highlight of our findings is that Revizor managed to automatically surface Spectre, MDS, and LVI, as well as several previously unknown variants. CCS CONCEPTS• Security and privacy → Side-channel analysis and countermeasures.

show abstract

Section: Related Workmentioning

confidence: 99%

Revizor: testing black-box CPUs against speculation contracts

Oleksenko

Fetzer

Köpf

et al. 2022

Proceedings of the 27th ACM International Conference on Architectural Support for Programming Languages and Operating Systems

View full text Add to dashboard Cite

show abstract

“…Modeling Spectre-style attacks. Our adversarial semantics is in the vein of [3], [20], [4], giving full control over predictors and scheduling decisions to the attacker. Compared to the Cauligi et al [3] semantics, which models all known Spectre variants, we narrow our scope to capture only Spectre-PHT and Spectre-STL for program verification.…”

Section: Spectre-pht (Input Validation Bypassmentioning

confidence: 99%

“…Speculative security properties. We base our definition of SCT off that of Cauligi et al [3] and Vassena et al [20]. Their respective tools, Pitchfork and Blade, both verify SCT using different approximations: Pitchfork uses explicit secrecy labels and performs taint-tracking over speculative symbolic execution, while Blade employs a very conservative type system that treats all (unchecked) memory loads as secret.…”

Section: Spectre-pht (Input Validation Bypassmentioning

confidence: 99%

High-Assurance Cryptography in the Spectre Era

Barthe

Cauligi

Grégoire

et al. 2021

2021 IEEE Symposium on Security and Privacy (SP)

Self Cite

View full text Add to dashboard Cite

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

show abstract

“…Recent work [25] presents Blade, an automatic tool able to repair a program vulnerable to speculative execution attacks, by eliminating speculation-based leakage. Their approach is based on the insertion of a minimal amount of protect annotations in the source code, which may then be implemented as memory fence instructions at low level machine code.…”

Section: Hardware Instructions As Mitigationmentioning

confidence: 99%

Secure Compilation of Constant-Resource Programs

Barthe

Blazy

Hutin

et al. 2021

2021 IEEE 34th Computer Security Foundations Symposium (CSF)

View full text Add to dashboard Cite

Observational non-interference (ONI) is a generic information-flow policy for side-channel leakage. Informally, a program is ONI-secure if observing program leakage during execution does not reveal any information about secrets. Formally, ONI is parametrized by a leakage function , and different instances of ONI can be recovered through different instantiations of . One popular instance of ONI is the cryptographic constant-time (CCT) policy, which is widely used in cryptographic libraries to protect against timing and cache attacks. Informally, a program is CCT-secure if it does not branch on secrets and does not perform secret-dependent memory accesses. Another instance of ONI is the constant-resource (CR) policy, a relaxation of the CCT policy which is used in Amazon's s2n implementation of TLS and in several other security applications. Informally, a program is CR-secure if its cost (modelled by a tick operator over an arbitrary semi-group) does not depend on secrets.In this paper, we consider the problem of preserving ONI by compilation. Prior work on the preservation of the CCT policy develops proof techniques for showing that main compiler optimisations preserve the CCT policy. However, these proof techniques critically rely on the fact that the semi-group used for modelling leakage satisfies the property:

show abstract

Automatically eliminating speculative leaks from cryptographic code with blade

Cited by 44 publications

References 40 publications

Revizor: testing black-box CPUs against speculation contracts

Revizor: testing black-box CPUs against speculation contracts

High-Assurance Cryptography in the Spectre Era

Secure Compilation of Constant-Resource Programs

Contact Info

Product

Resources

About