Daniel Ge, David Mally, Nick Meyer

This is an implementation of the Flush+Reload cache timing side channel attack as described in a paper by Yarom and Falkner. Our paper goes into how we implemented the attack.

In short, Flush+Reload technique exploits content-based page sharing (or memory deduplication) to monitor cache lines. To detect whether a program executes a particular instruction in a given time slot, the technique involves flushing that portion of instruction memory from cache (using the clflush x86 instruction), waiting, and timing how long it takes to access that instruction. This technique has been demonstrated against the modular exponentiation procedure in GnuPG pre-1.4.14, which allows an attacker to extract the private RSA exponent from cache timing data.

As a proof of concept, we attacked GPG 1.4.12. To set this up, there are a few build scripts in the built_gpg/ directory. On OS X, run:

$ brew install gnupg.rb

On Linux (and also on OS X if you don't want to use Homebrew):

$ ./install_locally.sh

Of course, you should never run arbitrary executable code from the Internet. You should verify that the scripts do what they are expected to do (they're pretty short).

Run make first.

To make things easier, we have provided a convenience script run.sh. Edit the relevant variables in the file before running it.

To obtain addresses to target, the simplest way to begin is to open the executable in GDB or LLDB and set breakpoints. You can take a look at some of our sample annotated address txt files in the docs/addr/ directory to give you a good starting point for which GPG source lines to target. Some files contain 3 addresses and some files contain 6, which could, understandably, be confusing. These are artifacts of the various trials we ran. Ultimately, our successful attack on EC2 used only three probes, but feel free to experiment.

Also, note that the annotated EC2 file does not have line numbers. We ended up digging into the disassembly to find those addresses, which, in that case, were ones corresponding to addresses close to the retq instruction for those functions. More details are in our linked implementation paper.

As a result of our unexpected Google search ranking for "flush+reload", we have seen a slight uptick of interest in our code (just a couple of emails, really). While we can't answer every question, we do have suggestions for papers worth reading for anyone who is looking to apply/extend the principles of the FLUSH+RELOAD attack:

• Wait a minute! A fast, Cross-VM attack on AES
• Seriously, get off my cloud! Cross-VM RSA Key Recovery in a Public Cloud
• Cross Processor Cache Attacks
• Cache Template Attacks: Automating Attacks on Inclusive Last-Level Caches (Suggested by a passing university student who asked us questions about our code)
• Make Sure DSA Signing Exponentiations Really are Constant-Time (A recent OpenSSL DSA key recovery attack co-authored by Yarom)