Digital Certificates (part 1 of 2)

This post will explore digital certificates.  Consider this as a result of a need to learn more detail about how certificates work.

Start here:

  1. VeriSign: Introduction to Digital Certificates
  2. VeriSign: Introduction to Public Key Cryptography


Cryptography solves many key computer issues (like identification).  Traditional security based on physical devices is useless in the digital world.   In order to protect information and identity, complex algorithms are needed to hide the content and user.

Early generation encryption solved the problem but had a big problem with how far it could transfer its secret keys.  It became too difficult and expensive to safeguard the symmetric keys.  Beyond this, the key trust required new keys for each new trust relationship.  It also implied prior knowledge of the other person.

Since both parties know the secret key, there is no way to know which of the two parties might have modified content or acted as the other.  The shared key does not indicate identification.  Therefore it can not be used to authenticate.

Public key encryption was first created in the mid 1970’s.  For the first time it was possible to transfer secret data without exposing the secret key.   There are two keys (one public and one private) that do the opposite of each other.  If you use the public key to encrypt, only the private key can decrypt.  Likewise, if data is encrypted using the private key, it can only be decrypted by the public key.

The public key is made widely available for all to use.  The private key is only available to the owner.  SSL uses the public keys of servers to encrypt traffic to the web.  The SSL protocol requests the public key from the server directly as part of its negotiation.

If a user wants to send a private message to another person, they use the public key of that person to encrypt the message.  The recipient uses their private key to decrypt the message.

The power of this is that the public key can be used by anyone and the content sent to the private key owner cannot be decrypted by anyone else (assuming that the encryption is strong enough).

Since only one person owns the private key, it is therefore true that if you decrypt data from the users public key, you can be guaranteed that it came from that person.  This introduces the concept of digital signatures.

Sometimes it is only necessary to prove that someone sent data.  The actual data does not necessarily need to be encrypted but the producer and the consumer want to guarantee that nothing has changed and that the content came from the producer.  This is used extensively in code signing.

The quick summary is that a hash algorithm is run against a section of data and the resulting digest (like SHA1) is encrypted using the private key of the producer.  The consumer receives the data and decrypts the digest and compares this against the digest calculated from the received data.  If they do not match, something has been altered that should not have been.

The problem however is that just because a public key is published it does not necessarily mean that the owner is the person you want to trust.  Someone could send you a public key that actually belongs to someone else.  There is a need to guarantee trust.

Digital certificates are the answer.  Similar in nature to a passport or driver license, they uniquely identify you based on a trusted organisation.    The user’s public key is signed by a certificate authority (think VeriSign) that can vouch for you being a valid user/company.  They only sign public keys they trust through a process of proving identity.  Years ago I needed a certificate for Citrix and had to prove to VeriSign that we were who we said we were.  It can be an extensive process based on the level of verification.

Digital certificates contain a number of data items to help verify identity and trust.  This includes the concept of expiration.  Proof of identity only lasts for a specific time (usually a year).

Certificates can be allocated based on a trust hierarchy.  Trust is relative to the parent which can be mapped to many layers before it gets back to a certificate authority root.  Web browsers have a list of certificate authorities they trust and that is the basis of determining trust with HTTPS sites.  Only trusted CAs are allowed.

More in the next post…

Live near Brisbane, Australia. Software developer currently focused on iOS and Android. Avid Google Local Guide

Tagged with: , ,
Posted in Certificates, Security, SSL
Follow Red Circle Blog on
%d bloggers like this: