OpenSSL RSA Timing Vulnerability
Ryan Pierce / Townsend Analytics Ltd. / Archipelago LLC
18 Mar 2003 4:22PM ET
http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
This research paper illustrates a successful attack made by using a timing channel against OpenSSL's implementation of the RSA algorithm. It can potentially have serious consequences to FIX and other electronic commerce applications. The specific attack was made against OpenSLL as implemented by both Apache web server with mod.SSL and stunnel, the latter of which can be used to secure FIX sessions. FIX engines implementing OpenSSL may be vulnerable. In fact, any FIX implementation using SSL may be vulnerable if the crypto library does not address timing attacks.
The idea is that by repeatedly making connections to an SSL server, one is forcing the server to do RSA decryptions of ciphertexts of the attacker's choosing using the server's private key. By taking very accurate timestamps of how long the server takes to respond, and making many connection attempts with varying input, an attacker can then extract the server's private key based off the computation times.
Should the private key be extracted, the consequences are quite severe. I believe the attacker can then decrypt any data sent to or from that server, as well as impersonate that server.
Previously, it had been thought that for software crypto implementations on multiuser systems, other events happening on the server would create enough timing noise that timing attacks would be impractical. This is no longer the case.
The authors of this paper first attempted the attack using another process running on the same machine. They were able to recover 1024 bit keys by timing the results of 1.4 million decryptions, which they accomplished over the course of about 2 hourse. For our purposes, this case isn't of concern for us because we certainly don't allow our electronic adversaries to run processes on the same server as our FIX engines. However, what is more troubling is that the authors then attempted the same attack from a second machine over an Ethernet LAN, and were successful. Variations of network delay on the LAN didn't mask the timing channel. It is unknown whether timing variances imposed by running the attack over the Internet or a WAN would mask the vulnerability of the timing channel. Ironically, higher quality network connectivity with low, stable latency is easier to attack.
Defenses:
First, an attacker likely has to make >1 million decryption requests against your SSL FIX engine for the attacker to discover a 1024 bit key. This actually might slip under the radar; no SSL connection is ever successfully negotiated and no FIX Logon sent, so the failure might not necessarily be logged. Taking the view that one can open their FIX engine to the world simply because it is protected by SSL might result in disclosure of one's private key through a timing attack. But, unlike a public web server, FIX engines can be firewalled so that only authorized parties can connect.
Second, OpenSSL will optionally implement a common defense against timing attacks called "RSA blinding." This isn't implemented by default, to my knowledge, and it can slow performance slightly if enabled. I'd think that recompiling with this enabled could eliminate or severely reduce the timing channel. I'd hope that FIX engines using OpenSSL would be compiled using this.
Note also that while OpenSSL was the library analyzed, it isn't necessarily the only one vulnerable. The authors of the paper conclude that authors of crypto libraries should implement defenses against timing attacks.
