The following discussion is meant to facilitate the understanding of side-channel attacks that affect today’s modern multicore processors. Side-channel attacks leverage the side effects of the execution of code. In this discussion, I will cover channels available through shared hardware devices such as processors, hard disk controllers or shared physical memory. Specifically, our focus will be on side channels in the last-level shared cache of Intel CPUs.
Types of Side-Channel Attacks
There are several types of side-channel attacks. One type that has received popular coverage is based on a technique called differential power analysis. This technique is a statistical method through which a black-box analysis of an unknown cryptographic hardware device can be used to discover secrets and intermediate cryptographic values via their power consumption. However, there are several other side-channel attacks that rely upon some knowledge of the system under test.
This is not as limiting as it might seem. For example, microprocessor specifications are available through the Hardware Reference documentation available from most manufacturers. I will discuss these side-channel attacks, which exploit knowledge of the underlying architecture in order to leak secrets from a virtual machine (VM) located on a CPU to another VM located on that same CPU. Note that this does not mean the same core, but rather the same processor package.
This scenario often arises in cloud computing when physical resources are shared among customers, called tenants. The storage technique is common on clouds because it allows the provider to use its physical resources in the most efficient manner possible.
Infrastructure-as-a-Service Clouds and Others
Infrastructure-as-a-service (IaaS) clouds offer scalability of servers or other resources based upon the demand from the tenant. To respond to these demands, the cloud provider will launch VMs on its compute nodes, or physical computers. These VMs can either be on the same compute node or they could be geographically separated onto different compute nodes. In order to protect one tenant’s resources from another on the same compute node, cloud providers rely upon the virtual machine monitor (VMM), or hypervisor. The VMM is responsible for protecting each tenant from exposure, whether accidentally or intentionally, to other tenants on the same compute node. It is this logical isolation that would be defeated via side-channel attacks.
There are other types of clouds, as well. Platform-as-a-service (PaaS) clouds are generally Web servers or other hosted servers that allow users to share common binaries and environments. Everyone has access to the same software, and the isolation is generally performed through Linux containers rather than full VMs. They also share the same kernel, as well as all the write-protected shared memory pages, so that pages do not have to be duplicated from one container to the next. For example, they share the same libc for Unix. The PaaS attack uses a strike against the shared last-level CPU cache but exploits this deduplication.
Attacks Against Services
The attacks against IaaS clouds, which use VMs for isolation, are by necessity more complex because one must find shared resources across VMs. In these attacks, the shared resource will be the CPU’s last-level cache, which is shared across VMs as well as CPU cores. Note that while PaaS attacks also use this feature, attacks against IaaS must be more sophisticated.
The first attack against the IaaS clouds is the same attack used against PaaS clouds. But, as I will describe, it is much more complex in the IaaS case; in fact, it’s often impossible. PaaS attacks, on the other hand, makes this attack trivially simple when Linux containers are used.
The attacks below assume that there is at least one (but usually several) attacker VMs controlled by the adversary, and at least one (but usually more) target VMs belonging to the cloud tenant under attack. In order for the attacks to succeed, the adversary must have at least one VM located on the same compute node and physical CPU (not the same core, but the same processor package) as the target. Note that this has been demonstrated to be possible in 40 percent of the experimental trials conducted. In these trials, the experimenters used a covert channel to identify whether they were a co-resident on the same machine, but this could be done by means of OS fingerprinting, network probes and even the side channel itself by stimulating a behavior in a target and searching for telltale signs of the activity, such as timing variations in code execution.
Because of this, some commercial cloud providers are offering guarantees that one tenant will be allocated a set of resources to themselves, not shared by another tenant.
Once co-residency has been achieved between an attacker VM and a target VM, there are several side channels that may be employed by the attacker to obtain information from the target. The most successful have been based on the CPU’s cache. Multiple cores can complicate this attack since each core has its own cache. However, in Intel CPUs the cores share what is called the last-level cache (LLC). The LLC is much larger than the caches on the cores themselves. This complicates attacks, as does its slower speed.
Stay Tuned…
I will discuss three attacks aimed at multicore CPUs, which are finely grained enough to discover cryptographic secrets. Given this resolution, other secrets are certainly possible to obtain, but cryptographic secrets such as private keys are often the best protected and most sensitive secrets in the target VM. Once again, any secret on your cloud instance can be obtained if the conditions are right. These side-channel attacks can exploit any execution timings to obtain any secret that your cloud VM processes.
Find out how your secrets on the cloud could be leaked to an attacker in Parts II and III of this series. Part II reviews attacks against El Gamal and RSA encryption in more depth, while Part III covers the attack that can recover an AES key in two minutes.
Security Researcher, IBM X-Force