The usual method of distributing public keys in networks of any scale is a certificate authority (CA)—a central server with a well-known public key which generates certificates for securely determining the proper public key of other elements in the network. However, existing CAs typically use RSA keys for signing and they do not necessarily have the capability to sign material using an ECC key pair—though there are some CAs that provide support for ECC. In the near future, however, CAs will need ECC certificates to implement a number of ECC-based protocols that are being submitted to the IETF (Internet Engineering Task Force) and IEEE ( Institute of Electrical and Electronics Engineers).
Since CAs are such critical components in an organization’s security infrastructure—tightly integrated into existing security practices and protocols—and since the distribution of the CA’s public key is a significant part of making that CA useful, merely rolling out a new CA with an ECC key pair provides significant logistical hurdles.
There is a way to manage these hurdles. Traditional CAs with non-ECC public keys can still be used to distribute ECC public keys. The technology that permits this is the hybrid certificate.
A hybrid certificate is a certificate which binds an ECC public key to a communicating party, but which is itself signed using non-ECC signature algorithms, and the CA’s private key. Schematically, it looks like Figure 3.
Hybrid certificates can be verified by any end entity which already has secure knowledge of the CA’s existing public key—say, a browser using certificates to verify the identities of web servers—without the need to distribute a new public key for the CA. Using this technology, you can associate ECC public keys with any communicating party *without* having to replace your CA.
From a performance perspective, hybrid certificates do not present any disadvantages as compared to an ECC-only solution. Even though the user of a hybrid certificate has to implement and use both ECC and RSA, the only RSA operation used is signature verification, which is much faster than RSA signature generation, relatively speaking.
If the CA can be upgraded to handle ECC signatures itself, hybrid certificates can also be used to roll out the new, ECC public key for an existing CA—a technique offering a route by which the existing, non-ECC CA key may be ‘grandfathered’ out of use. The CA can issue certificates signed by both technologies in an interim period, and clients capable of verifying the CA’s ECC signature can use the ECC signature exclusively. Eventually, if clients incapable of doing ECC verification are no longer in use, the non-ECC key can be allowed to expire, and the CA need only issue ECC-signed certificates thereafter. The benefit here is that the ECC technology can be integrated into the network gradually, as needed.
The Benefits of Hybrid Certificates
Hybrid certificates may be found to offer such potential benefits in any number of applications—a way to employ ECC and reap its benefits without entirely replacing the CA. A likely initial use is in deployments using TLS-based protocols.
Specifically, portable and constrained devices such as web-enabled phones using ECC for the handshake with a secured web server could see significant performance benefits, but they could just as well prove useful in any network using protocol families offering both ECC and non-ECC based methods of authentication and verification.