Q&A with Bill Lattin of Certicom

by Steve Ragan - Jul 24 2008, 17:52

With the coverage given to cryptography and data protection at the 2008 RSA conference, in the mainstream media, and in various research papers and case studies, there is lots of information to be found when researching the technology.

IT department managers and engineers are intimately familiar with the term "PKI", even the average user knows what RSA security is, and can recognize an SSL-secured Web site in their browser. However, how many are familiar with Elliptic Curve Cryptography or ECC?

Elliptic Curve Cryptography (ECC) was discovered in 1985 by Victor Miller (IBM) and Neil Koblitz (University of Washington) as an alternative mechanism for implementing public-key cryptography. At the time of its discovery, the ECC algorithm was described and placed in the public domain. What others found was that, while it offered greater potential security, it was slow.

Certicom focused on fixing this issue, and centered most of its company on these efforts. The Tech Herald was given access to Bill Lattin, the CTO of Certicom, who took the time to explain ECC and how it fits into layered security. He explained who is using it, and why it is a viable alternative to other cryptographic security solutions.

So how secure is ECC? Is it something worth researching? Well, the National Security Agency (NSA) certainly thinks so. In order to allow for a more widespread implementation of ECC, the NSA purchased from Certicom a license that covers twenty-six U.S. patents and applications in a restricted field of use. The license would be limited to implementations that were for national security uses and certified under FIPS 140-2, or where approved by NSA. Additionally, the NSA and NIST have identified that RSA-based encryption technologies are only sufficient for government communications until 2010, after which time agencies are required to switch to ECC. In this case, you can look at it as “what’s good for the government, might be worth exploring.”

So is Certicom the only ECC vendor? No, it is not. However, there are some vendors, such as Tumbleweed, that have licensed Certicom’s technology. You would be surprised as to who is using ECC vendor-wise. Sun Labs, Microsoft, and Red Hat are all under the ECC Interoperability Forum umbrella. The ECCIF ensures that ECC products from these vendors integrate seamlessly, providing end-to-end security. The odds are you have vendors and technology in place now that use ECC. Even RSA, Mozilla and Apache are a part of the EECIF.

This Q&A covers ECC, and acts as a starting point for research into the security.

This is not meant to push Certicom or any other vendor in any way. The answers are posted, as written, by Bill Lattin. No alterations were made to his responses.

The Tech Herald (TTH): Without getting too heavily into the mathematics, can you describe Elliptic Curve Cryptography?

Bill Lattin (BL): Elliptic Curve Cryptography (ECC) is a form of asymmetric or public key, cryptography. Public key cryptography is different from symmetric key cryptography in that it uses two separate keys – one to encrypt and one to decrypt; whereas, symmetric cryptography uses a single key to encrypt and decrypt – much like the key to the front door of your house. Unlike symmetric cryptography, in which the key may never be revealed to the public, with asymmetric cryptography one key may be made public (hence the name, public key cryptography) without compromising the secrecy of the associated private key. Today, public key cryptography is widely used to distribute symmetric keys and to create and verify digital signatures.

Advanced Encryption Standard (AES) and Data Encryption Standard (DES) are widely used symmetric cryptosystems. RSA is perhaps the best known form of public key cryptography because it is embedded in the Secure Socket Layer (SSL) protocol used in all web browsers. The security of RSA relies on the computational difficulty of factoring the RSA modulus into its composite secret primes. Factoring is becoming easier as computing power increases and as more efficient factoring algorithms are discovered. NIST has given guidance in SP800-57 and SP800-78 that RSA with a 1024 bit key size should not be used in selected applications by the end of this year and not at all by the end of the year 2010.

The security of ECC is based on a different problem than that underlying RSA. To break ECC, one must compute an elliptic curve discrete logarithm, and it turns out that this is a significantly more difficult problem than factoring. As a result, ECC key sizes can be significantly smaller than those of RSA. For example, the following table is derived from NIST and ANSI standards:

TTH: What are the strengths and weaknesses of ECC?

BL: From a cryptographic standpoint, an important strength of ECC is the fact that its very small key sizes can protect your data for many years. For example, NIST predicts that ECC-384 will be secure beyond the year 2030; whereas RSA-1024 will become obsolete by NIST standards in the year 2010.  ECC is also far more efficient at Suite B strengths than RSA. ECC scales easily from smart cards to mobile handsets to infrastructure routers and mainframes.

The weakness of ECC is not with the algorithm, but in that certain applications cannot use it because of backward compatibility requirements with legacy applications. This, of course, will be solved over time since there is no question that key sizes are increasing and RSA simply doesn’t scale at the key sizes NSA is mandating for even unclassified information

TTH: How does ECC fit into a layered security plan?

BL: A layered security plan is essential to providing security in depth. As a cryptographic element, ECC is an important ingredient to ensuring that your information is adequately protected both in storage and in transit, and that your certificate-based authentication systems are robust against attack. What many industry security professionals are only beginning to come to grips with is the fact that public key lengths are increasing beyond those in common use today.

Specifically, in 2005, the National Security Agency (NSA) announced its Suite B set of cryptographic methods for use in protecting both Sensitive But Unclassified (SBU) as well as Classified data. These Suite B algorithms are shown in Table 2.

This announcement was extremely important for a number of reasons. The US Government’s last public selection of an algorithm to protect SBU information was in 1977 when it published DES. With its Suite B announcement, NSA has indicated that AES is appropriate for protecting both classified and unclassified information. Also significant is that Suite B only specifies ECC for the public key operations; there is no RSA or DSA. This selection was likely made for scalability reasons since it is easier to build a secure system to support ECC key sizes or 256 and 384 bits than it is to support RSA key sizes of 3072 – 7,680 bits. Lastly, NSA created grouping of homogeneous strength cryptographic algorithms for protecting data with different levels of sensitivity in order to prevent the creating of a secure system using an inappropriate combination of algorithms.

Suite B is critically important for the commercial world because NSA has redefined industry best practice for cryptographically protecting data. Remember, NSA is stating that AES-128 and ECC with a 256-bit key size (comparable in strength to RSA-3072) must be used to protect unclassified information. Most commercial firms today don’t use adequately strong cryptography to protect their sensitive information.

For instance, most companies using Virtual Private Networks (VPNs) today are using AES-128 but only RSA-1024 – a tremendous mismatch! RSA-1024 only offers 80 bits of security compared with the 128 bits provided by AES. How about those “industry-strongest” SSL certificates some vendors offer? If they are signed using the SHA-1 hash and RSA-2048, did you know you are not getting a level of security that matches AES-128? SHA-1 provides a comparable strength of only 80 bits, and RSA-2048 only provides a comparable strength of 112 bits!

Based on NIST and ANSI guidance, Table 3 provides a more complete picture of the comparative strengths of various cryptographic algorithms:

As part of their layered security strategy, commercial organizations should use the above table and review their deployed cryptosystems to ensure algorithms of sufficient strength are used. For instance, protocols such as SSL/Transport Layer Security (TLS), SSH and IKE/IPsec support a variety of cryptographic algorithms with strengths ranging from 40-bits to 256-bits. If these protocols are being used to transport company-sensitive data, their use of algorithms with strengths below 128 bits should be prevented.

The key point is that it is no longer adequate to simply “encrypt” your data. You must now actively select the appropriate cryptographic algorithms with the baseline established by Suite B. Companies should expect their Sarbanes Oxley and Health Insurance Portability and Accountability Act (HIPAA) auditors to request this level of detail as to how they are protecting such covered data.

TTH: ECC is used by the NSA and a few other government agencies, what about SMB and regular IT shops? Who is using it and how is it used?

BL: When Suite B was announced, it caused many commercial operating system (OS) vendors to examine the performance of their web servers using the larger RSA-3072 key size versus using ECC-256. At the 2006 RSA Conference, Microsoft, Red Hat and Sun presented benchmark data showing that TLS server performance was faster using ECC – especially as RSA key sizes increased to 3072 and beyond. For example, Sun Microsystems found they could use 3.5 fewer servers to support the same number of transactions per second when using ECC-224 vs RSA-2048.

Research In Motion (RIM) is using ECC exclusively in the BlackBerry. When they were designing the product, they made the decision to incorporate cryptographic algorithms that were beyond reproach for handling all different data types. As a result, they selected ECC-521 and AES-256.  This strategy worked well for them as it opened the US government market to them, and acted as a barrier to entry for similar devices from other manufacturers who only used RSA-1024 and AES-128.

A European bank recently determined that it needed to migrate its infrastructure from RSA-1024 to at least RSA-4096. When they discussed this with their outsourced IT provider, that provider was going to significantly raise their annual fees due to the increased MIPS required to process RSA-4096. As a result, the bank moved to ECC-256.

Today, ECC is supported by the major OS vendors, and it is being used for both TLS and IPsec VPNs. It is also embedded in a wide number of applications from such companies as Oracle, Sybase, Sterling Commerce, Fidelity, and Nokia.

TTH: Data protection is a huge topic in IT, how can ECC help businesses adapt?

BL: Certainly data protection, using cryptographic algorithms of appropriate strength, is of critical importance. Using ECC will enable businesses to protect their most sensitive information with very strong cryptography that will have little impact on system performance – in terms of CPU power, bandwidth consumption, and power consumption.

Businesses handling sensitive data covered by legislation such as Sarbanes Oxley and HIPPA must ensure that their systems employ controls sufficient to meet evolving internal and external threats. NSA’s Suite B mandate has established a new bar for the strength of cryptographic algorithms used to protect such information.

TTH: How hard is ECC to implement in a large-scale network?

BL: Due to its light impact on computing networks, ECC scales very well to large networks comprised of devices with a wide variety of capabilities, such as CPU power, bandwidth, and storage capacity. ECC certificate authorities are coming on line this year to supply SSL X.509 certificates. ZigBee has adopted ECC for use in its “smart energy” network applications, which can involve thousands of nodes. It’s only in some networks where backward compatibility is required with legacy applications that do not support ECC where ECC deployment may be limited.

TTH: Based on the news coverage and expert opinion, data encryption and security seems so basic, yet it isn’t used nearly as much as it should be. Why is this do you think?

BL: I’ve been involved with the design and manufacture of commercial encryption systems since 1981. Key management and performance are the hardest problems in the application of cryptography. Key management covers the generation, storage, distribution, use, lifetime, and destruction of cryptographic keys. The most successful secure applications are those where cryptography is integrated directly into the application and where the key management functionality is automated. Lotus Notes is an example of an application that seamlessly integrates cryptography. The seamless integration of encryption via HTTPS with web browsers has made Internet commerce possible. Applications designers need to find ways to integrate cryptography while automating its functionality.

In addition to applications developers implementing security better today, users could be more proactive in forcing their vendors to provide products with appropriate levels of embedded security. If you have a business where sensitive information must be encrypted, you should require your vendors to adopt today’s state-of –the art security. Many vendors have not followed the latest trends in cryptography until their customers require it of them.

Certainly encryption performance is critical to successful secure deployments because servers must operate as fast as possible and users don’t like to wait for access to be granted. At today’s required key sizes, ECC is extremely efficient for key management functions in applications ranging from ePassports to high volume secure e-commerce servers.

Around the Web