This project is unmaintained and somewhat outdated now. We may continue to answer questions or respond to issues, but not in a timely manner.
This other project appears to be an improved implementation of the attack.
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)