Protecting Cache States Against Both Speculative Execution Attacks and Side-channel Attacks

Hardware caches are essential performance optimization features in modern processors to reduce the effective memory access time. Unfortunately, they are also the prime targets for attacks on computer processors because they are high-bandwidth and reliable side or covert channels for leaking secrets. Conventional cache timing attacks typically leak secret encryption keys, while recent speculative execution attacks typically leak arbitrary illegally-obtained secrets through cache timing channels. While many hardware defenses have been proposed for each class of attacks, we show that those for conventional (non-speculative) cache timing channels do not work for all speculative execution attacks, and vice versa. We maintain that a cache is not secure unless it can defend against both of these major attack classes. We propose a new methodology and framework for covering such relatively large attack surfaces to produce a Speculative and Timing Attack Resilient (STAR) cache subsystem. We use this to design two comprehensive secure cache architectures, STAR-FARR and STAR-NEWS, that have very low performance overheads of 5.6% and 6.8%, respectively. To the best of our knowledge, these are the first secure cache designs that cover both non-speculative cache side channels and cache-based speculative execution attacks. Our methodology can be used to compose and check other secure cache designs. It can also be extended to other attack classes and hardware systems. Additionally, we also highlight the intrinsic security and performance benefits of a randomized cache like a real Fully Associative cache with Random Replacement (FARR) and a lower-latency, speculation-aware version (NEWS)

Random and Safe Cache Architecture to Defeat Cache Timing Attacks

Caches have been exploited to leak secret information due to the different times they take to handle memory accesses. Cache timing attacks include non-speculative cache side and covert channel attacks and cache-based speculative execution attacks. We first present a systematic view of the attack and defense space and show that no existing defense has addressed both speculative and non-speculative cache timing attack families, which we do in this paper. We propose Random and Safe (RaS) cache architectures to decorrelate the cache state changes from memory requests. RaS fills the cache with ``safe'' cache lines that are likely to be used in the future, rather than with demand-fetched, security-sensitive lines. RaS captures a group of safe addresses during runtime and fetches addresses randomly displaced from these addresses. Our proposed RaS architecture is flexible to allow security-performance trade-offs. We show different designs of RaS architectures that can defeat cache side-channel attacks and cache-based speculative execution attacks. The RaS variant against cache-based speculative execution attacks has 4.2% average performance overhead and other RaS variants against both attack families have 7.9% to 45.2% average overhead. For some benchmarks, RaS defenses improve the performance while providing security

New Cache Attacks and Defenses

The sharing of last-level cache (LLC) among different physical cores makes cache vulnerable to side channel attacks. An attacker can get private information about co-running applications (victims) by monitoring their accesses. Cache side channel attacks can be mitigated by partitioning cache between the victim and attacker. However, previous partition works make the incorrect assumption that only the victim's cache misses are visible to attackers. In this work, we provide the key insight that both cache hits and cache misses from the victim are vulnerable. For a cache hit, although it does not affect the existence state, it can still change the replacement state and coherence state, which can also leak information to attackers. Based on this, we propose Invisible-Victim cache (IVcache), a new cache design that can mitigate both traditional LLC attacks and the new variants. IVcache classifies all processes as protected and unprotected. For accesses from protected processes, IVcache handles state changes in a slightly different way to make those accesses absolutely invisible to any other processes. We evaluate the defense effectiveness and performance of IVcache in the gem5 simulator. We show that IVcache can defend against real-world attacks, and that it introduces negligible performance effect to both protected and unprotected processes

LightBox: Full-stack Protected Stateful Middlebox at Lightning Speed

Running off-site software middleboxes at third-party service providers has been a popular practice. However, routing large volumes of raw traffic, which may carry sensitive information, to a remote site for processing raises severe security concerns. Prior solutions often abstract away important factors pertinent to real-world deployment. In particular, they overlook the significance of metadata protection and stateful processing. Unprotected traffic metadata like low-level headers, size and count, can be exploited to learn supposedly encrypted application contents. Meanwhile, tracking the states of 100,000s of flows concurrently is often indispensable in production-level middleboxes deployed at real networks. We present LightBox, the first system that can drive off-site middleboxes at near-native speed with stateful processing and the most comprehensive protection to date. Built upon commodity trusted hardware, Intel SGX, LightBox is the product of our systematic investigation of how to overcome the inherent limitations of secure enclaves using domain knowledge and customization. First, we introduce an elegant virtual network interface that allows convenient access to fully protected packets at line rate without leaving the enclave, as if from the trusted source network. Second, we provide complete flow state management for efficient stateful processing, by tailoring a set of data structures and algorithms optimized for the highly constrained enclave space. Extensive evaluations demonstrate that LightBox, with all security benefits, can achieve 10Gbps packet I/O, and that with case studies on three stateful middleboxes, it can operate at near-native speed.Comment: Accepted at ACM CCS 201