How Certificates Work

A digital certificate is similar to a birth certificate. As you know, a birth certificate conveys information such as name, date of birth, gender, and other attributes which ultimately identifies a given individual. Yet somewhere on the certificate the hospital provided a seal of authenticity which, as it turns out, is difficult to imitate. As people inherently trust legitimate hospitals, your birth certificate (with proper seal of authenticity) essentially proves your identity to others.

Digital certificates are similar to birth certificates in that they too provide identifying characteristics, and are ultimately signed by a trusted third party. The real magic behind proving authenticity is achieved with a cryptographic function called a “digital signature." Before we get too deep into certificates and digital signatures, an ultra high-level overview contrasting the two categories of encryption is in order. Don't worry-- we'll keep it simple.

Symmetric Vs Asymmetric Cryptography

Symmetric encryption (also known as “private key” encryption) uses a single key to both encrypt and decrypt data. This single key is to be distributed to both parties wishing to communicate with each other, and must ultimately be kept private. Although relatively fast, private key encryption requires a unique key for every entity you wish to communicate with. (You never want to re-use the same key to communicate with more than one party.) This cumbersome “key management” issue prevents private key encryption from being used exclusively in e-commerce. Imagine needing a unique key for each customer you intent to do business with. For large e-commerce sites with many customers, millions of keys would be required, which is simply isn't feasible.

Asymmetric encryption (also known as “public key” encryption) is encryption which uses one key to encrypt data, and another key to decrypt data. These two keys are referred to as the “public” and “private” keys. While the private key must be kept secret, the other is made public and thus widely distributed. Those who wish to communicate with you would simply use your public key to encrypt the data. As only you own the corresponding private key, you are the only entity that can decrypt the message. Whether you're communicating with one or millions of customers, only two keys are ever needed. While this drastically simplifies key management, public key encryption is often CPU-intensive and therefore terribly slow.

Digital Signatures Now that that we've covered symmetric vs asymmetric cryptography, let's get back to digital signatures. A digital signature is a function which starts out by taking a message of variable length, such as the text from web page or an email, and computing a fixed-length “fingerprint” of that message. This is known as a hash code. The important thing to remember about hash codes is that they are one-way functions. So what does that mean? It means that you can take a message of variable length (say 5,000 bytes for example) and derive a unique and static-sized hash code from the message, but not the inverse. In other words, the unique fingerprint or “hash code” cannot be used to produce the original message. The other important aspect of a hash code is that it is intended to be unique per a given message. If two large files which contain the exact same text are individually hashed, the corresponding hash codes should be identical. However, if you were to change just a single character within one of the files, still leaving the thousands of other words unchanged, the hash functions would yield completely different results. For example, let's examine what happens when we take the hash of two files with identical content:

Notice that two different files with the same textual content yield the same cryptographic fingerprint. However, let's see what happens when we change only a single character in file “test2.txt:”

As you can see, changing only a single character (brown to Grown) radically alters the fingerprint. Often times, a hash code or “checksum” alone is used to convey authenticity. For example, software distributors who offer digital downloads of their products will publish checksums of the corresponding files on their web site to ensure to customers that the files haven't been tampered with, or perhaps become corrupted during the download. The problem with solely depending on a checksum for authenticity is that if an attacker successfully broke into your web server and altered your download, why wouldn't he simply alter the checksum as well? While checksums are useful, generating a unique signature of a file does not ensure security. While the checksum may be mathematically correct, we still can't prove who generated it.

A digital signature takes the concept of a checksum one step further. Like a checksum, a digital signature starts out by deriving a fixed-length fingerprint from a message. However, to prove that you and only you generated the hash code, we must electronically “sign” the hash code. This is done by encrypting the hash code with a secret encryption key. Technically speaking, this is the corresponding private key from an asymmetric public/private key pair.

At this point, we now have a working digital signature which can be distributed along with our data to ensure authenticity. To verify the authenticity of the original message, the receiver would first generate their own hash code of the data, using the same algorithm we originally used. The receiver would then use our widely distributed public key to decrypt our encrypted (or “signed”) hash code. Remember that in asymmetric cryptography, one key encrypts while the other decrypts. As such, the “public key” is able to decrypt the hash code which was encrypted by the highly secret “private key.”

Finally, if the decrypted hash code matches the hash code generated by the receiver, the message should be deemed authentic. If the hash code differ, then something went wrong along the way and the resulting message should not be considered legitimate.

Distributing Your Digital Signatures

Now that we know how to prove authenticity through digital signatures, we need to properly distribute our digital signature and public key in a standardized format. This is accomplished by encapsulating the digital signature and public key in what is known as an X.509 certificate. An X.509 certificate consists of your identifying attributes such as company name, a common name (www.acme.org for example), and finally your widely distributed public key. An actual X.509 certificate would appears as follows:

Certificate:
Data:
Version: 1 (0x0)
Serial Number: 1 (0x1)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=California, L=El Granada, O=Atomic Fission Certificates,
OU=Certificate Authority Division, 
CN=certificates.atomicfission.com/emailAddress=
 This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
 
Validity
Not Before: Jul 13 17:36:34 2007 GMT
Not After : Jul 12 17:36:34 2008 GMT
Subject: C=US, ST=New York, L=Ithaca, O=Acme Burritos 123, OU=IT Division,
CN=www.acmeburritos123.com/emailAddress=
 This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
 
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public Key: (1024 bit)
Modulus (1024 bit):
00:c5:6f:5d:56:fe:6e:83:b1:4d:4c:84:65:a2:f1:
fb:93:0c:28:ba:b2:dc:d2:4d:46:89:83:f9:0d:c3:
57:a9:ad:30:a5:ce:76:52:76:82:76:73:34:b3:eb:
33:77:cd:82:22:be:56:4e:01:6c:c4:91:5f:46:b3:
97:fa:b1:e8:5a:a9:a4:29:a4:03:32:9a:a4:cc:8f:
25:eb:42:b0:48:ba:96:57:ad:f1:c8:0e:5a:11:64:
f8:ba:d7:35:1d:fa:50:8b:fb:f7:98:52:88:63:b6:
3c:61:3f:9a:0a:72:04:4f:09:85:31:c3:14:7e:93:
90:b0:e8:b7:54:2d:47:d9:87
Exponent: 65537 (0x10001)
Signature Algorithm: sha1WithRSAEncryption
be:01:54:79:46:2b:5c:3f:9e:1c:e4:97:d6:1c:68:69:93:a2:
b9:92:69:93:a9:33:21:c4:d4:7d:f5:71:f2:57:66:be:4a:90:
3c:c5:40:ef:ba:02:96:e3:f6:50:f0:7b:28:b2:33:6a:0c:66:
ac:53:3c:6f:25:10:03:79:e2:81:1a:3e:37:d2:d2:b9:84:f6:
c0:76:8b:fc:70:b3:0d:d2:b0:79:5b:6c:a2:89:4c:84:9f:92:
ed:bd:4e:24:7a:2f:8b:12:8d:9f:86:62:bb:22:b0:7a:41:bc:
f8:a3:92:db:0e:cd:1c:43:00:b4:91:a1:64:5f:4f:4d:b8:de:
b1:00

Once your identifying attributes and public key are neatly packaged into a properly formated X.509 certificate, the entire certificate gets its own unique fingerprint via a checksum routine. This checksum is then “signed” by a trusted certificate authority (CA) such as Verisign or Thawte. The certificate authority uses their private key to sign (or essentially encrypt) your certificate's fingerprint. Your customers will use the CA's widely distributed public key to decrypt the signed fingerprint in order to determine your authenticity. If the fingerprint decrypts properly, you can safely assume that the signature was signed by a trusted certificate authority. For our certificate above, the certificate authority used the SHA1 checksum algorithm to create a fingerprint of the X.509 certificate. The checksum was then encrypted using RSA encryption:

Signature Algorithm: sha1WithRSAEncryption
be:01:54:79:46:2b:5c:3f:9e:1c:e4:97:d6:1c:68:69:93:a2:
b9:92:69:93:a9:33:21:c4:d4:7d:f5:71:f2:57:66:be:4a:90:
3c:c5:40:ef:ba:02:96:e3:f6:50:f0:7b:28:b2:33:6a:0c:66:
ac:53:3c:6f:25:10:03:79:e2:81:1a:3e:37:d2:d2:b9:84:f6:
c0:76:8b:fc:70:b3:0d:d2:b0:79:5b:6c:a2:89:4c:84:9f:92:
ed:bd:4e:24:7a:2f:8b:12:8d:9f:86:62:bb:22:b0:7a:41:bc:
f8:a3:92:db:0e:cd:1c:43:00:b4:91:a1:64:5f:4f:4d:b8:de:
b1:00

Key Strength 

Simply put, encryption “bit lengths” represent the number of possibilities for a given key. For example, if your encryption key is “Hi-$ecyourIT182” and your encryption algorithm was a 64 bit cipher, then it would take up to 2⁶⁴ attempts, or about 18 quintillion (18,446,744,073,709,551,616) tries to systematically guess every potential password combination before correctly guessing the phrase “Hi-$ecyourIT182 .”

You may often hear computer professionals assert that 128 bit encryption is “strong” encryption, while anything less that 128-bit encryption should be considered “weak” encryption. Generally speaking, this is not an accurate statement due to the fact that that not all encryption ciphers are created equally. Recall that there are two categories of encryption: “symmetric” and “asymmetric.” A 128-bit (or greater) encryption key length is quite strong for a symmetric encryption algorithm such as 3DES, RC4, or AES. However, a 128-bit key size for an asymmetric algorithm such as RSA or DSS would be dangerously short. Unlike their symmetric counterparts, asymmetric algorithms require key sizes of at least 512 bits. In fact, most security professionals will not implement asymmetric algorithms with a key size less than 768 bits.

Symmetric encryption is fast, yet it requires a unique encryption key for each individual you plan on communicating with. For web sites which have numerous customers, attempting to securely create and issue a unique key for each customer would be incredibly time consuming. On the other hand, asymmetric cryptographic solves the key exchange issue by issuing everyone only a single public key which is to be used for encryption. The encrypted messages are then decrypting using a single secret key which only your server has access to. The downside to asymmetric cryptography is that it is very CPU intensive and thus far slower than symmetric encryption.

In an attempt to have the best of both worlds, the SSL protocol takes a hybrid approach to encryption. Specifically, asymmetric encryption is used only initially in order to exchange certificates and agree on a (temporary) shared key. Once the SSL session is established, asymmetric encryption ceases and symmetric encryption commences using the recently created shared key. In most web server environments, you and your certificate authority must agree on the asymmetric (or “public”) key size. This is because your certificate authority is the entity that actually converts your certificate signing request (CSR) into an actual, usable certificate. Although the CA will determine a public key length, customers often have a say in the matter, and tend to standardize on 1024-bit RSA. The symmetric (or “private”) ciphers are completely within your control as they're configured within your web server's properties. By default, web servers will support a vast array of public/private encryption combinations. These combinations, known as “cipher suites,” are presented to web clients in hopes that the server and client can agree on one combination in particular. In SSL v3 and TLS v1, the client is allowed to suggest cipher suites, but the server has the final say as to which cipher suite is actually used. Therefore, security-conscious sites should remove any weak or “export grade” cipher suites from the server altogether. This is the only way to ensure that only strong encryption will be used in SSL sessions.

A primer on certificates wouldn't be complete without at least a parenthetical note regarding United States encryption export law. Prior to January of 2000, the United States Bureau of Export Administration restricted the export of “strong” cryptography to countries outside the United States. Although the restrictions were incrementally reduced over time, the historical consensus was that nothing over 40-bit symmetric/512-bit asymmetric could be exported. As of today, strong encryption may be exported to many foreign nations, as long as they are not an embargoed country. Although many years have passed since the US “liberalization” of encryption export law, the concept of “export-compatibility” is still a feature-set found in many encryption applications. Essentially what this means is that a cryptographic application that supports “export grade” ciphers will fundamentally support weak ciphers. With protocols such as SSLv2 the client, rather than the server, may negotiate which cipher suite to be used. Consequently, hackers may exploit situations such as this to “downgrade” encrypted sessions in order to make cracking the session far easier. Given the fact that computing power has increased significantly over the last decade, weak or “export-grade” ciphers may now be cracked fairly quickly and must therefore never be used under any circumstance.

Certificate Authorities and Public Key Infrastructure

A certificate authority is analogous to the traditional Better Business Bureau. A CA serves as a trusted third-party that can testify to the validity of business when you alone cannot. Certificate authorities are hierarchical, meaning they can either sign client X.509 certificates directly, or they can sign a lower-tiered certificate authority's certificate, which effectively grants the lower-tiered CA the ability to sign client certificates directly. This hierarchical system of trusted certificate authorities forms what is know as the public key infrastructure, or PKI.

At this point, you may be wondering how your computer will inherently trust a certificate signed by an authority such as Verisign, while completely rejecting lesser-known CAs such as “Acme Certificates” or similar. The method by which your computer either trusts or rejects a CA is application-specific. Microsoft Windows for example, provides a centralized root certificate repository which is intended to be queried by all Microsoft-based applications. Although infrequent, new root CAs are pushed to Windows systems via standard Windows Updates. Cross-platform applications on the other hand, such as Mozilla Firefox and Sun Microsystems' Java Runtime Environment, cannot depend on such platform-specific certificate repositories and must therefore depend on their own built-in cache of trusted root certificate authorities. Application-specific management of trusted root CAs is fairly transparent to the average end-user. Just note, however, that this situation can prove arduous for organizations who wish to build their own internal trusted root certificate authorities. This is because the newly created root CA certificate must now be added to several different repositories on each computer!