A. Contribution

  1. Problem addressed by the paper

Automatic defense mechanism against cache side-channel attack.

  1. Solution proposed in the paper. Why is it better than previous work?

The solution proposed is by creating large number of code fragment replicas and then randomly switching between replicas at runtime. It unites two previously unrelated strands of research: side channel and artificial software diversity. It does not require source code modification or specialized hardware so it can be automatically applied to existing software. Previous diversity techniques transform each program trace identically. The diversity based technique in this paper instead transforms programs to make each program trace unique. This approach offers probabilistic protection against both online and off-line side-channel attacks.

  1. The major results.

The experiment shows moderate overhead of 1.5-2x in practice. In the best scenario, the EVICT+TIME attack can derive only 4.96 key nibbles, or about 20 key bits out of 128 bits. In the PRIME+PROBE attack, the experiments show an average of 3.32 correctly recovered key nibbles or 13.28 key bits out of 128 bits.

B. Basic idea and approach. How does the solution work?

It works by creating a large number of unique program execution paths by automatically generating diversified replicas for parts of an input program. Replicas derived from the same original program fragment have different implementations, but perform semantically equivalent computations. At runtime, it then randomly and frequently switches between these replicas. It will then randomly alter static and dynamic memory load to alter cache behavior and thus disrupts or adds noise to the side channel. Then the authors perform experiments with EVICT+TIME and PRIME+PROBE attacks to evaluate its efficiency and effectiveness.

Thwarting_Cache_Side-Channel_Attacks_Through_Dynamic_Software_Diversity_pdf

C. Strengths

  1. It significantly reduces side channel leakage.

D. Weaknesses

  1. Its overhead of 1.5x-2x is a bit slow.
  2. It does not discuss if an attacker with knowledge of this paper will be able to circumvent this defense.
  3. It relies on the randomness selection of the replicas. With knowledge of this paper and ability to break the randomness (figuring out the randomizing algorithm), an attacker may succeed in his/her side channel attack.
  4. It does not discuss if an attacker could further probe the remaining keys using other advanced techniques. They only mentions that it is not feasible to further probe the remaining keys using brute force attack. What if it is possible to probe the remaining keys using other advanced techniques?
  5. If binary access is allowed, there is additional protection on the OS level that needs to be done to make the attacker not able to accurately determine which replica of each program unit was executed in an observed program trace. Otherwise, an attacker who observes a complete trace of control-flow transfers could filter out the effects of the replicas’ diversifying transformations, regardless of what those effects are.
  6. It only selects nine functions relevant to AES encryption algorithm. It does not explain the total functions available. Therefore, we can not know if it is a large or small portion of it. (Nine out of how many?)

E. Future work, Open issues, possible improvements

  1. There is an implementation limitation that currently does not support diversification of inline assembly. It could be further developed to support rewriting of inline assembly.