- How does this attack works on the high level?
Resource sharing on multicore CPUs has benefits like low cost and efficiency. This, however, is the attack point that we saw over the years. With the cache attack, the victim's data extracted with cache manipulations.
The countermeasure against the various cache attacks is disabling simultaneous multi-threading (SMT) and the obvious is the cleansing of the cache during the context switching. The cross-core cache attack is prevented by partitioning the Last Level Cache (LLC) (e.g. Intel CAT) and disabling shared memory for different security domains.
The presented attack works even the countermeasures are applied. This attack leverages contention on the ring interconnect, which is the component that enables the communication between the different CPU units.
The hardest part of this attack is getting information about the ring since it was not well documented.
L1 and L2 caches are called private caches since they are private to the core so that cross explanation is not possible. Since the Nehalem-EX the L3 cache (LLC) is divided into slices into equal size and only one slice per core.
In Intel architecture the L1, L2, and LLC are inclusive, meaning that if there is data on L1 and L2 then it is also in L3.
The ring-bus in the above picture tells most of its structure. It used in intra-process communications when a cache miss occurs in L1,L2 then the data must travel on the ring-bus to arrive LLC.
Now skipping the low-level details, the attacker's process can create a contention by transmitting 1 and idle with 0. By measuring the latency they can extract keys from insecure naive square-and-multiply RSA implementation. Like in the power attack, the second peak indicates the bit 1. This is similarly done for EdDSA.
The second face of this new channel is the keystrokes. The attack leaks the timing of the keystrokes and this can be used to reconstruct the typed words or worse the passwords. Like in this article;
- What are the mitigations against his attack?
For cryptographic code use secure implementations particularly constant-time programming principles. A side-channel secure implementation will not be vulnerable to the current state of being in the Cache-Ring attack. However, achieving that may not be an easy job since Intel CPUs perform hardware store elimination between the private caches and ring interconnect ( see Hardware Store Elimination)
For keystrokes, hardware can be designed based on spatial partitioning and statically-scheduled arbitration policies. Also, a software-based solution can be designed for sending the password in regular intervals.
- What are the consequences of this attack?
It opened a new side-channel on the multicore CPUs. I've expected that clever minds will improve this attack in many ways. Note that, still, if your code is not vulnerable to cache attacks and they are timing-attack free, I don't see an exploit there, yet.
- Are secure implementations affected by this attack?
Currently, no. Keystrokes, however, can be a big issue.
