Public key cryptography and security certificates

Public key cryptography offers ultimate security being based asymmetric keys and is the backbone for popular protocols like security sockets layer (SSL) to be able to communicate securely between web-servers and browsers. However a whole ecosystem is based on passing or exchanging security certificates.

This article explains public key cryptography and the role of security certificates and the way they are used by the secure protocols to provide ultimate security.

The encryption using a public key cryptography or private /public key pair ensures that the data can be encrypted by one key but can only be decrypted by the other key pair. The keys are similar in nature and can be used alternatively: what one key encrypts, the other key pair can decrypt. The key pair is based on prime numbers and their length in terms of bits ensures the difficulty of being able to decrypt the message without the key pairs.
 
One of the keys - the private key - is kept secret while other key - the public key - is distributed to anyone who wishes to communicate securely. Anybody with the public key can then encrypt message that can only be decrypted by the person holding the corresponding private key. Since public key is no a secret and can be know to anyone, anyone could impersonate the sender claiming to be the legitimate sender. 

To assure sender’s identity, sender can sign the message where message to be transmitted is encrypted with sender’s Private key (also called digital signature) and only the associate public key(with the receiver) will be able to decrypt it. However note that message is just signed but not secured since everybody has the public key. This digital signature can be transmitted along with encrypted message to be able to send the secure message along with sender authenticity.

More details on public keys and digital signature are in Securing your apps with Public Key Cryptography & Digital Signature .

While a combination of secret and public key cryptography solves the way two parties can communicate with each other and exchange information securely, they don’t completely address the trust issue between each other.  For example, how does a recipient determine if a public key really belongs to the sender? When does a public key expire? How can a key be revoked in case of a compromise? That's where the certificate comes in.    

Similar to a driving license that is issued by a state and establishes the identity indicating type of vehicle person is authorized to drive, issuing authority, date of issue, date of expiry etc, a certificate contains information about the owner of the certificate like e-mail address, owner's name, certificate usage, duration of validity, an expiration date, the name of the authority that issued the certificate, a serial number, any pertinent policies describing how the certificate was issued and/or how the certificate may be used, the digital signature of the certificate issuer, and perhaps other information. It contains also the public key and finally a hash to ensure that the certificate has not been tampered with.

Certificate Authorities (CAs) are the agencies that issues certificates and maintains repositories for public-keys. As one makes a choice to trust the person who signs this certificate, therefore one also trusts the certificate. This is a certificate trust tree.

Usually the browser already loads the root certificate of well known CAs like VeriSign. The CA maintains a list of all signed certificates as well as a list of revoked certificates. A certificate is insecure until it is signed, as only a signed certificate cannot be modified. Let’s look at how the overall protocols work between a secure server and a Client, typically user’s browser.

A user generates a key pair and forwards the public yet to CA. The CA checks sender authenticity and necessary steps to assure that the request is coming from the advertised sender. Different CA may just have different policies to establish trust. Once this is done, browser (on client side) and server can communicate securely via Secure Sockets Layer(SSL) technology , de-facto standard for secure commutation across the internet. SSL relies on SSL certificates that authenticates the identity of the website to the browser users and enables encrypted communication using asymmetric cryptography, as explained in previous section. Flow of certificate along with the steps involved in SSL connections is shown in figures 1 and 2.  

Click on image to enlarge.

Click on image to enlarge.
When a browser user wants to send confidential information to a web server, the browser will access the server’s digital certificate and obtain its public key to encrypt the data. Since the web server is the only one with access to its private key, only the server can decrypt the information. Below are some of steps involved in a SSL connection:

1. Client connects to an SSL-protected website (URL starting with https).
2. Website sends the copy of its SSL certificate to the browser along with the cryptographic proof that it possesses the associated private key.
3. Client browser verifies the signature to determine is certificate should be trusted. As long as the certificate is signed by one of the client’s Trusted Root Certification Authorities(like VeriSign or Entrust) and the certificate has not expired along with other checks, no trust dialogs are presented to the user and the secure connection starts seamlessly.
4. On a successful connection(i.e if certificate is valid), client browser will generate a one-time session key (symmetric key) and encrypt with server’s public key(extracted from the SSL certificate). Client browser will then send the encrypted session key to the server so that they will both have a copy.
5. The server will decrypt the message using its private key and extract the session key. This completes the SSL handshake thus allowing secure communication. Client browser and server can now communicate with each other sending data encrypted with session key.

When a web site does not have an SSL certificate signed by a CA whose root key is embedded in the browser, most Internet browsers will display a warning dialog box similar to that shown in figure 3, which may lead the users to question the trustworthiness of the site.

To conclude SSL provides a strong method of secure communication with the trust model based on Certification Authority (CA) to be able to trust the certificate. If the bad buys are able to somehow hack CA and issue fraudulent certificates from trusted CA, the whole model fails. There are thousands of CA’s (and may have different policies to issue certificates) and all must work perfectly to make this trust model work perfectly, something that would be far from ideal.

About the author:

Mohit Arora (mohit.arora@freescale.com) is a Senior Systems Engineer with Freescale Semiconductor.
---------------------------------------------------------------
If you found this article to be of interest, visit the Micocontroller Designline where you will find links to relevant technical articles, blogs, new products and news.

You can also get a weekly newsletter highlighting the latest developments in this sector - just Click Here to request this newsletter using the Manage Newsletters tab - if you aren't already a member you'll be asked to register.