Re: Brumley Boneh timing attack on OpenSSL
- Original Message - From: Nomen Nescio [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 24, 2003 1:20 PM Subject: Re: Brumley Boneh timing attack on OpenSSL Regarding using blinding to defend against timing attacks, and supposing that a crypto library is going to have support for blinding: - Should it do blinding for RSA signatures as well as RSA decryption? If you are a client, and you manually control the signature generation (like you use PGP to sign email messages), I wouldn't implement blinding. But if you are a server (or a client that automatically responds to requests) that signs message for some reason, and you receive many requests, I would. RSA decryption, yes for servers. - How about for ElGamal decryption? - Non-ephemeral (static) DH key exchange? Again, if you are automatically answer to requests, yes I would. In the Freedom network, servers had non-ephemeral keys and did a DH key exchange with clients (client side used ephemeral keys and was anonymous), we implemented blinding on the server side to counter timing attacks because we had a hunch that they could work over network connections. - Ephemeral DH key exchange? No, I wouldn't. I would be very surprised if you could do timing attacks on one execution of a modulo exponentiation, unless there is some way to trick a server in using the same secret on different inputs, even though it's suppose to do ephemeral DH. - How about for DSS signatures? Yes if you automatically answer to requests. Paul Kocher's initial paper on the subject explicitly mentions DH, RSA and DSS. If there is a possibility that you can be used as an oracle, and you have a static key, you should be careful. --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Brumley Boneh timing attack on OpenSSL
Anton Stiglic wrote: - Should it do blinding for RSA signatures as well as RSA decryption? If you are a client, and you manually control the signature generation (like you use PGP to sign email messages), I wouldn't implement blinding. But if you are a server (or a client that automatically responds to requests) that signs message for some reason, and you receive many requests, I would. The way I understand the attack, you have to throw a million specially-chosen guesses at the server, which it will blindly attempt to decrypt and use. Basically, you're getting the server to decrypt chosen ciphertext for you. I don't see how the attack can apply to signatures, where the server itself is formatting the data to be signed. Unless the server is just directly signing (RSA-encrypting) arbitrary client-supplied data, but that's a no-no anyway. This is slightly more than theoretical, as OCSP servers do nothing but emit signed responses. An OCSP client can only indirectly influence some of the data that a server signs, and so it seems very difficult to pull off the attack. M. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Brumley Boneh timing attack on OpenSSL
Bill Stewart [EMAIL PROTECTED] writes: Schmoo Group response on cryptonomicon.net http://www.cryptonomicon.net/modules.php?name=Newsfile=articlesid=263mode=order=0thold=0 Apparently OpenSSL has code to prevent the timing attack, but it's often not compiled in (I'm not sure how much that's for performance reasons as opposed to general ignorance?) I had blinding code included in my crypto code for about 3 years, when not a single person used it in all that time I removed it again (actually I think it's probably still there, but disconnected). I'm leaning strongly towards general ignorance here... Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Brumley Boneh timing attack on OpenSSL (fwd)
Some clarification by Peter Gutmann [EMAIL PROTECTED] on why cryptlib doesn't do timing attack resistance default: Peter Gutmann [EMAIL PROTECTED]: cryptlib was never intended to be a high-performance SSL server (the docs are fairly clear on this), and I don't think anyone is using it to replace Apache or IIS. OTOH it is used in a number of specialised environments such as closed environments, embedded systems and mainframes. For example two real-world uses of the cryptlib SSL server are in embedded environment A and mainframe environment B. In A, the processing is handled by a low-power embedded processor. It takes 10-15s to perform an SSL handshake, and that's after the code has been optimised to death to squeeze every possible bit of performance out of it. Performing the necessary 1.5M queries at 15s each would take approximately 8 1/2 months at 100% CPU load (meaning that the device is unable to perform any other operations in that entire time). This is unlikely to go unnoticed, given that it's polled from other devices for status updates. In B, CPU resources are so scarce that the implementation uses null cipher suites because it can't afford the overhead of even RC4 for encryption (admittedly this required a custom code hack, cryptlib doesn't normally support null encryption suites). After about 100 or so attempts at a full SSL handshake, klaxons would sound and blue-suited troops would deploy onto the raised flooring to determine where all the CPU time is going. In neither of these environments (and various similar ones) would a side- channel attack requiring 1M or so queries (e.g. this one, or the Bleichenbacher attack, or the Klima-Pokorny-Rosa attack, which cryptlib shouldn't be vulnerable to since I'm paranoid about error reporting) be terribly feasible. OTOH blinding does produce a noticeable slowdown for a process that's already regarded by its users as unacceptably slow and/or CPU-intensive (I have some users who've hacked the key-exchange process to use fixed shared keys because they just can't spare the CPU time to do a real handshake, e.g. by injecting the shared key into the SSL session cache so you just do a pseudo-resume for each new connection). For this reason, cryptlib makes the use of sidechannel- attack-protection an optional item, which must be selected by the user (via use of the blinding code, now admittedly I should probably make this a bit easier to do in future releases than having to hack the source :-). This is not to downplay the seriousness of the attack, merely to say that in some cases the slowdown/CPU consumption vs.attack risk doesn't make it worthwhile to defend against. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Brumley Boneh timing attack on OpenSSL (fwd)
At 09:51 AM 03/22/2003 +0100, Eugen Leitl wrote: Some clarification by Peter Gutmann [EMAIL PROTECTED] on why cryptlib doesn't do timing attack resistance default: Peter Gutmann [EMAIL PROTECTED]: cryptlib was never intended to be a high-performance SSL server (the docs are fairly clear on this), and I don't think anyone is using it to replace Apache or IIS. OTOH it is used in a number of specialised environments such as closed ... For this reason, cryptlib makes the use of sidechannel- attack-protection an optional item, which must be selected by the user (via use of the blinding code, now admittedly I should probably make this a bit easier to do in future releases than having to hack the source :-). This is not to downplay the seriousness of the attack, merely to say that in some cases the slowdown/CPU consumption vs.attack risk doesn't make it worthwhile to defend against. If it's not meant to be a high-performance server, then slowing it down another 20% by doing RSA timing things is probably fine for most uses, and either using compiler flags or (better) friendlier options of some sort to turn off the timing resistance is probably the better choice. I'm not sure how flexible things need to be - real applications of the openssl code include non-server things like certificate generation, and probably some reasonable fraction of the RSA or DH calculations don't need to be timing-protected, but many of them are also things that aren't CPU-consumption-critical either. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Brumley Boneh timing attack on OpenSSL
Regarding using blinding to defend against timing attacks, and supposing that a crypto library is going to have support for blinding: - Should it do blinding for RSA signatures as well as RSA decryption? - How about for ElGamal decryption? - Non-ephemeral (static) DH key exchange? - Ephemeral DH key exchange? - How about for DSS signatures? In other words, what do we need as far as blinding support either in developing a crypto library or in evaluating a crypto library for use? Suppose we are running a non-SSL protocol but it is across a real-time Internet or LAN connection where timing attacks are possible. And suppose our goal is not to see a paper and exploit published within the next three years telling how to break the protocol's security with a few hours of connect time. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Brumley Boneh timing attack on OpenSSL
Nomen Nescio wrote: Regarding using blinding to defend against timing attacks, and supposing that a crypto library is going to have support for blinding: - Should it do blinding for RSA signatures as well as RSA decryption? - How about for DSS signatures? My guess is that it's not necessary, as the attacker doesn't have as much control over the input to the modular exponentiation process in the case of RSA signatures. (For RSA decryption, the attacker can specify the ciphertext freely. However, for signatures, the input to the modular exponentiation is a hash of the attacker's chosen input, which gives the attacker a lot less freedom to play Bleichenbacher-like games.) But then, the recent Klima-Pokorny-Rosa paper shows how even just a tiny crack can lead to subtle, totally unexpected attacks. Who would have thought that SSL's version rollback check (two bytes in the input to the modular exponentiation) could enable such a devastating attack? Not me. The Boneh-Brumley and KPR papers have made me much more paranoid about side-channel attacks. As a result, I might turn blinding on even for signatures by default, out of caution, even though I can't see how such an attack could possibly work. - How about for ElGamal decryption? - Non-ephemeral (static) DH key exchange? Yes, I think I'd use side channel defenses (like blinding) here. I don't know of any attacks off the top of my head, but it sure seems plausible to me that there might be some. - Ephemeral DH key exchange? I wouldn't tend to be very worried about ephemeral exchanges, since all the attacks we've seen so far require many interactions with the server with the same key. I could be wrong, but this seems pretty safe to me. In other words, what do we need as far as blinding support either in developing a crypto library or in evaluating a crypto library for use? Suppose we are running a non-SSL protocol but it is across a real-time Internet or LAN connection where timing attacks are possible. And suppose our goal is not to see a paper and exploit published within the next three years telling how to break the protocol's security with a few hours of connect time. Good question. Personally, I'd enable side channel defenses (like blinding) by default in the crypto library in every place that the library does some lengthy computation with a long-lived secret. But I'll be interested to hear what others think. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Brumley Boneh timing attack on OpenSSL
From Slashdot: http://slashdot.org/article.pl?sid=03/03/14/0012214mode=threadtid=172 David Brumley and Dan Boneh write: Timing attacks are usually used to attack weak computing devices such as smartcards. We show that timing attacks apply to general software systems. Specifically, we devise a timing attack against OpenSSL. Our experiments show that we can extract private keys from a OpenSSL-based server such as Apache with mod_SSL and stunnel running on a machine in the local network. Our results demonstrate that timing attacks against widely deployed network servers are practical. Subsequently, software should implement defenses against timing attacks. Our paper can be found at Stanford's Applied Crypto Group. http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html Schmoo Group response on cryptonomicon.net http://www.cryptonomicon.net/modules.php?name=Newsfile=articlesid=263mode=order=0thold=0 Apparently OpenSSL has code to prevent the timing attack, but it's often not compiled in (I'm not sure how much that's for performance reasons as opposed to general ignorance?) They also comment (as did somebody on Slashdot) that this is distinct from the timing attack described in the paper by Canvel, Hiltgen, Vaudenay, and Vuagnoux last month. That one's an implementation problem and hard to exploit. http://lasecwww.epfl.ch/memo_ssl.shtml http://slashdot.org/article.pl?sid=03/02/20/1956229 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
