The authentication of the public keys used in a security protocol is one of the essential steps to ensuring the authenticity of the participants.
You may ask, “Why do you need to authenticate the public keys in a security protocol?” Without authentication, it may be possible for someone to insert themselves in a protocol and appear as a valid participant. This is the traditional man-in-the-middle attack. For example, assume Alice and Bob are using Diffie-Hellman (DH). If Eve inserts herself into the communications path and impersonates both Alice and Bob in the DH protocol, Alice and Bob will discover this only if they authenticate the public keys they receive from each other. This is because each will have received Eve’s public key during the exchange rather than each other’s authentic keys.
Public-key authentication schemes range from manual to fully automatic methods. Manual methods work well when a limited number of parties are involved; automated methods are generally more secure and cost effective for large distributed networks. Manual authentication usually involves an out-of-band verification process, such as telephonic verification, the use of pre-shared secrets, or public key signing “events” such as those held at IETF meetings.
As the number of users increases, it is no longer always practical to use a manual method – users may not know each other or secure communications must be established “on-the-fly”. A VPN device or a secure telephone may need to establish a secure session with a previously unknown (but authorized) party. For these applications where a manual setup process is too costly or time intensive, an automated method must be used. Automated methods will rely upon certificates; and as we’ve seen in this issue of Code and Cipher, there are many forms of certificates ranging from implicit to proprietary and X.509 explicit formats.
When certificates are used, a Certificate Authority (CA) is required. However, it need not be complex or standalone. Again, depending on system criteria, the CA could be built into one device and issue certificates to the other communicating devices. For instance, a CA in a manufacturing environment may create and load a manufacturer’s certificate into each device before it is shipped. At the customer site, another device with a built-in CA will communicate with all other deployed devices, validate their manufacturer’s certificates, and then issue new customer-specific certificates to them. These certificates can be proprietary, if it’s a closed network, or X.509 for an open network. Both proprietary explicit and implicit certificates can be very lightweight. A public CA really only needs to be used when secure communications must be established between parties who have little to no other a priori knowledge of each other.
Obviously, this column is not a complete discussion of authentication methods or certificates. There are many alternatives available for performing the critical task of public key authentication. Security requirements, level of expertise and resources available all influence the final product. The use of a simple embedded CA issuing either implicit or explicit certificates can provide high security and great efficiency. Which authentication solution you select will depend on your specific application and its projected usage requirements.
This issue of Code & Cipher reviews the first annual Certicom ECC Conference and summarizes some of the key discussions at the event.
This issue of Code and Cipher examines different types of certificates, their uses and benefits.