Cryptology ePrint Archive: Report 2022/426

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

Basavesh Ammanaghatta Shivakumar and Jack Barnes and Gilles Barthe and Sunjay Cauligi and Chitchanok Chuengsatiansup and Daniel Genkin and Sioli O'Connell and Peter Schwabe and Rui Qi Sim and Yuval Yarom

Abstract: 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.

Category / Keywords:

Date: received 3 Apr 2022

Contact author: basavesh shivakumar at mpi-sp org, gjbarthe at gmail com, sunjay cauligi at mpi-sp org, chitchanok chuengsatiansup at adelaide edu au, genkin at gatech edu, sioli oconnell at adelaide edu au, peter at cryptojedi org, rui sim at adelaide edu au, yval at cs adelaide edu au

Available format(s): PDF | BibTeX Citation

Version: 20220406:130424 (All versions of this report)

Short URL: ia.cr/2022/426


[ Cryptology ePrint archive ]