Tuesday Dec 01, 2009

Update: Next-Generation Security for the Apache Web Server

[Read the original article at http://blogs.sun.com/vipul. Other sites that carry this content may have trouble displaying it in its intended format.]

One of my previous blog posts talked about Elliptic Curve Cryptography, why it is being endorsed by the National Security Agency and how a small team of researchers at Sun Labs has had a big hand in promoting its wide-spread industry adoption.

A few days ago, I received notification that the development team behind Apache has finally integrated the patch that makes this next-generation security technology available to the users and administrators of the world's most popular web server. It has been a long, slow journey -- we demonstrated the first version of ECC-enabled Apache at a Sun Labs Open House in 2004 (and you thought high tech moves fast!) -- but I'm excited to see this final chip fall in place. It is a significant milestone in overhauling the cryptographic underpinnings of the World Wide Web.

The timing couldn't be better. NIST guidelines (see pages 63, 66) recommend that key sizes used with RSA (the currently popular incumbent technology) be doubled from 1024- to 2048-bits after 2010 to guarantee adequate protection of sensitive information -- think online banking and e-commerce. The big advantage of ECC is it can provide equivalent security using much smaller keys. More specifically, corresponding ECC key sizes only need to increase from 160- to 224-bits. Since the computational cost of public-key operations grows roughly as the cube of the key-size, the performance advantage of ECC over RSA increases as security needs increase over time:

RSAECCSpeed-up with
keysizeops/s keysizeops/s
Through 20101024738.91601783.62.41
(i.e. 1783.6/738.9)
Through 20302048113.4224711.4 6.27
(i.e. 711.4/113.4)

Table 1: Comparison of server-side cryptographic operations needed to establish a secure connection. These numbers were obtained with OpenSSL 1.0.0-beta2 on a MacBook Pro laptop with a 2.5GHz Intel Core 2 Duo processor and 4GB of SDRAM using the command "openssl speed rsa1024 rsa2048 ecdhp160 ecdhp224".

Table 1 compares the speed of doing an RSA decryption against the speed of an ECDH computation. These are the main cryptographic operations a web server needs to perform for establishing an HTTPS connection. As shown, ECC operations are faster by a factor of more than six for key sizes needed beyond 2010. I wouldn't expect an ECC-based HTTPS server to perform six times better than an RSA-based server because there are other operations in processing an HTTPS request that are common to both. One needs HTTPS-level testing with a tool like httpperf to determine the actual speedup. We did such a study back in 2004 and found that an ECC-based HTTPS server can handle between two to four times as many connections as an RSA-based server (for key sizes needed beyond 2010). I'd love to repeat that experiment with the latest software running on contemporary hardware when I can find some time. Stay tuned.

"More times than we can count, we've made history, without history even knowing we were there."
- Keith Alexander, Director NSA/Chief CSS, speaking at the NSA's 55th Anniversary.
  (For many years, the U.S. government did not acknowledge the existence of the
  NSA earning it the nickname "No Such Agency")

Tuesday Jun 16, 2009

Next-Generation Security for the Apache Web Server

Elliptic Curve Cryptography (ECC) is a next-generation public-key cryptographic technology that is more resource efficient than RSA (learn why) and was recently endorsed by the NSA for protecting sensitive US Government Information (see The Case for ECC and Suite B).

Sun Labs has played a major role in promoting wide-spread industry adoption of this technology by:

  1. Leading the standardization of ECC within SSL/TLS, the dominant security protocol used on the Internet (see RFC 4492 and its earlier versions).
  2. Contributing ECC technology to OpenSSL (version 0.9.8 and later) and NSS/Mozilla (version 3.8 and later) -- two cryptographic libraries that power the world's most popular open source web server (Apache) and browser (Firefox), respectively.
  3. Initiating and leading a cross-vendor ECC Interoperability Forum (with participants from Apache, Certicom, Microsoft, Mozilla, OpenSSL, Red Hat, RSA, Sun and Verisign) to ensure seamless interoperability between ECC-enabled offerings from different companies.

ECC has been part of Firefox since October 2006 when version 2.0 was released but isn't yet included in the default build of the Apache web server (see Bug 40132). I recently updated the patch and corresponding instructions to create an ECC-enabled version of Apache 2.2.11 with OpenSSL 1.0.0-beta2. If you happen to try out the patch, I'd love to get your feedback.

In case you are wondering "why should I care?", think of this as another step in reducing the computational cost of security so service providers like Amazon, Facebook, Google and Yahoo can turn on HTTPS by default for all user interactions (not just the login phase), thereby boosting privacy on the Internet.


Vipul Gupta


« July 2016