Ozone: Efficient Execution with Zero Timing Leakage for Modern Microarchitectures

Time variation during program execution can leak sensitive information. Time variations due to program control flow and hardware resource contention have been used to steal encryption keys in cipher implementations such as AES and RSA. A number of approaches to mitigate timing-based side-channel attacks have been proposed including cache partitioning, control-flow obfuscation and injecting timing noise into the outputs of code. While these techniques make timing-based side-channel attacks more difficult, they do not eliminate the risks. Prior techniques are either too specific or too expensive, and all leave remnants of the original timing side channel for later attackers to attempt to exploit. In this work, we show that the state-of-the-art techniques in timing side-channel protection, which limit timing leakage but do not eliminate it, still have significant vulnerabilities to timing-based side-channel attacks. To provide a means for total protection from timing-based side-channel attacks, we develop Ozone, the first zero timing leakage execution resource for a modern microarchitecture. Code in Ozone execute under a special hardware thread that gains exclusive access to a single core's resources for a fixed (and limited) number of cycles during which it cannot be interrupted. Memory access under Ozone thread execution is limited to a fixed size uncached scratchpad memory, and all Ozone threads begin execution with a known fixed microarchitectural state. We evaluate Ozone using a number of security sensitive kernels that have previously been targets of timing side-channel attacks, and show that Ozone eliminates timing leakage with minimal performance overhead

A Survey of Techniques for Improving Security of GPUs

Graphics processing unit (GPU), although a powerful performance-booster, also has many security vulnerabilities. Due to these, the GPU can act as a safe-haven for stealthy malware and the weakest `link' in the security `chain'. In this paper, we present a survey of techniques for analyzing and improving GPU security. We classify the works on key attributes to highlight their similarities and differences. More than informing users and researchers about GPU security techniques, this survey aims to increase their awareness about GPU security vulnerabilities and potential countermeasures

Improved Cache Trace Attack on AES and CLEFIA by Considering Cache Miss and S-box Misalignment

This paper presents an improved Cache trace attack on AES and CLEFIA by considering Cache miss trace information and S-box misalignment. In 2006, O. Acıiçmez et al. present a trace driven Cache attack on AES first two rounds, and point out that if the Cache element number of the Cache block is 16, at most 48-bit of AES key can be obtained in the first round attack. Their attack is based on the ideal case when S-box elements are perfected aligned in the Cache block. However, this paper discovers that, the S-box elements are usually misaligned, and due to this feature and by considering Cache miss trace information, about 200 samples are enough to obtain full 128-bit AES key within seconds. In 2010, Chester Rebeiro et al. present the first trace driven Cache attack on C LEFIA by considering Cache hit information and obtain 128-bit key with 243 CLEFIA encryptions. In this paper, we present a new attack on CLEFIA by considering Cache miss information and S-box misalignment features, finally successfully obtain CLEFIA-128 key for about 220 samples within seconds

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

Formally verified countermeasures against cache based attacks in virtualization platforms

Cache based attacks are a class of side-channel attacks that are particularly effective in virtualized or cloud-based environments, where they have been used to recover secret keys from cryptographic implementations. One common approach to thwart cache-based attacks is to use constant-time implementations, which do not branch on secrets and do not perform memory accesses that depend on secrets. However, there is no rigorous proof that constant-time implementations are protected against concurrent cache attacks in virtualization platforms; moreover, many prominent implementations are not constant-time. An alternative approach is to rely on system-level mechanisms. One recent such mechanism is stealth memory, which provisions a small amount of private cache for programs to carry potentially leaking computations securely. We weaken the definition of constant-time, introducing a new program classification called S-constant-time, that captures the behavior of programs that correctly use stealth memory. This new definition encompasses some widely used cryptographic implementations. However, there was no rigorous analysis of stealth memory and S-constant-time, and no tool support for checking if applications are S-constant-time. In this thesis, we propose a new information-flow analysis that checks if an x86 application executes in constant-time or S-constant-time. Moreover, we prove that (S-)constant-time programs do not leak confidential information through the cache to other operating systems executing concurrently on virtualization platforms. The soundness proofs are based on new theorems of independent interest, including isolation theorems for virtualization platforms, and proofs that (S-)constant-time implementations are non-interfering with respect to a strict information flow policy which disallows that control flow and memory accesses depend on secrets. We formalize our results using the Coq proof assistant and we demonstrate the effectiveness of our analyses on cryptographic implementations, including PolarSSL AES, DES and RC4, SHA256 and Salsa20.Los ataques basados en el cache son una clase de ataques de canal lateral (side-channel) particularmente efectivos en entornos virtualizados o basados en la nube, donde han sido usados para recuperar claves secretas de implementaciones criptográficas. Un enfoque común para frustrar los ataques basados en cache es usar implementaciones de tiempo constante (constant-time), las cuales no tienen bifurcaciones basadas en secretos, y no realizan accesos a memoria que dependan de secretos. Sin embargo, no existe una prueba rigurosa de que las implementaciones de tiempo constante están protegidas de ataques concurrentes de cache en plataformas de virtualización. Además, muchas implementaciones populares no son de tiempo constante. Un enfoque alternativo es utilizar mecanismos a nivel del sistema. Uno de los más recientes de estos es stealth memory, que provee una pequeña cantidad de cache privado a los programas para que puedan llevar a cabo de manera segura computaciones que potencialmente filtran información. En este trabajo se debilita la definición de tiempo constante, introduciendo una nueva clasificación de programas llamada S-constant-time, que captura el comportamiento de programas que hacen un uso correcto de stealth memory. Esta nueva definición abarca implementaciones criptográficas ampliamente utilizadas. Sin embargo, hasta el momento no había un análisis riguroso de stealth memory y S-constant-time, y ningún soporte de herramientas que permitan verificar si una aplicación es S-constant-time. En esta tesis, proponemos un nuevo análisis de flujo de información que verifica si una aplicación x86 ejecuta en constant-time o S-constant-time. Además, probamos que los programas (S-)constant-time no filtran información confidencial a través del cache a otros sistemas operativos ejecutando concurrentemente en plataformas de virtualización. La pruebas de corrección están basadas en propiedades que incluyen teoremas, de interés en sí mismos, de aislamiento para plataformas de virtualización y pruebas de que las implementaciones (S-)constant-time son no interferentes con respecto a una política estricta de flujo de información que no permite que el control de flujo y los accesos a memoria dependan de secretos. Formalizamos nuestros resultados utilizando el asistente de pruebas Coq, y mostramos la efectividad de nuestros análisis en implementaciones criptográficas que incluyen PolarSSL AES, DES y RC4, SHA256 y Salsa20

Prime+Retouch: When Cache is Locked and Leaked

Caches on the modern commodity CPUs have become one of the major sources of side-channel leakages and been abused as a new attack vector. To thwart the cache-based side-channel attacks, two types of countermeasures have been proposed: detection-based ones that limit the amount of microarchitectural traces an attacker can leave, and cache prefetching-and-locking techniques that claim to prevent such leakage by disallowing evictions on sensitive data. In this paper, we present the Prime+Retouch attack that completely bypasses these defense schemes by accurately inferring the cache activities with the metadata of the cache replacement policy. Prime+Retouch has three noticeable properties: 1) it incurs no eviction on the victim's data, allowing us to bypass the two known mitigation schemes, 2) it requires minimal synchronization of only one memory access to the attacker's pre-primed cache lines, and 3) it leaks data via non-shared memory, yet because underlying eviction metadata is shared. We demonstrate Prime+Retouch in two architectures: predominant Intel x86 and emerging Apple M1. We elucidate how Prime+Retouch can break the T-table implementation of AES with robust cache side-channel mitigations such as Cloak, under both normal and SGX-protected environments. We also manifest feasibility of the Prime+Retouch attack on the M1 platform imposing more restrictions where the precise measurement tools such as core clock cycle timer and performance counters are inaccessible to the attacker. Furthermore, we first demystify undisclosed cache architecture and its eviction policy of L1 data cache on Apple M1 architecture. We also devise a user-space noise-free cache monitoring tool by repurposing Intel TSX