Encryption

Encryption techniques are based on the idea of substituting plaintext characters with encrypted characters. An encryption process applies an algorithm to each plaintext character combined with a character from a key. (A key is a series of characters, usually random, that remains static throughout the process of encryption.) The result of this process is an encrypted character. The process repeats itself once for each plaintext character, resulting in encrypted text.

A related algorithm can be applied to each encrypted text character combined with a character from the key, resulting in the original plaintext character. Repeating this application for each encrypted character results in the original plaintext. This process of encrypting and decrypting with the same key is called symmetric encryption.

Public and Private Keys

Of course, this begs the question of how to securely exchange the key between the sender and the recipient. Asymmetric encryption accomplishes this. Asymmetric encryption exposes a public key that anyone can use to encrypt data, while keeping a secret private key at both ends to decrypt data. These private keys don’t have to be the same key (and usually aren’t), but both can be used to decrypt data encrypted with a specific public key.

And how do we prevent someone from simply using the public key to decrypt plaintext encrypted with it, as we can with symmetric encryption? The answer is that some mathematical processes are very easy to do, and very difficult to reverse. In particular, it is easy to multiply two prime numbers, but hard to derive those two prime numbers from the product unless they are quite small. The difficulty of extracting the prime factors of large semiprime numbers (numbers that are the product of two prime numbers) is the basis for RSA, the most commonly used algorithm for implementing asymmetric encryption.

Since asymmetric key encryption and decryption requires more overhead than symmetric, it’s usually used only to exchange symmetric keys. These are then used to send encrypted data.

The Cipher Suite

There are other algorithms that handle different aspects of sending encrypted data. A set of algorithms that is used to send encrypted messages is called a cipher suite. A cipher suite typically consists of four algorithms: key exchange (the asymmetric algorithm), authentication, bulk exchange (the symmetric algorithm) and a Message Authentication Code, or MAC, algorithm.

Please note that the only relationship that a MAC algorithm has to a MAC address is that they share the same acronym. Otherwise, a Media Access Code address and a Message Authentication Code algorithm are entirely unrelated. (We explain MAC addresses in detail in Chapter 5: Transmitting Data Frames on the Link Layer.)

Authentication

Simply encrypting data isn’t enough to assure secure data transmission reliably. A malicious user could intercept a message during transit and substitute his own public key for the legitimate one. In such a case, the client and server will both believe that they are communicating with one another, while each is actually communicating with the malicious user. The malicious user can then alter the messages going back and forth with neither party the wiser. This is called a man-in-the-middle attack.

Authentication prevents such attacks by verifying that a party in a transmission is who it says it is. Authentication is accomplished using digital certificates and digital signatures. A web server that supports TLS has a digital certificate assigned by a certificate authority.

Digital Certificates

Digital certificates (DCs) are electronic documents that protect against impersonation, by certifying that a public key belongs to a specified entity. They contain their owner’s public key, as well as a statement that the public key belongs to that owner.

DCs prevent man-in-the-middle attacks by using a trusted third party to verify that public keys belong to who they say they belong to. The trusted third party is the Certficate Authority.

A DC is essentially a sequence of three required fields:

1. The tbsCertificate (or “to be signed certificate”) field contains the names of the subject (the entity holding the DC) and issuer, the subject’s public key, a validity period, and other associated information.
2. The signatureAlgorithm field contains the identifier for the cryptographic algorithm used by the CA to sign the certificate.
3. The signatureValue field contains the digital signature.

Digital Signatures

Digital signatures (DSs) are formed by digitally signing (i.e. encrypting) a bit-encoded version of a DC’s tbsCertificate field with a private key owned by the CA. This is usually a key reserved for this specific use, called the signature key. This has the effect of the CA certifying that the public key in the tbsCertificate field is actually owned by the subject to whom the CA has issued the certificate. The CA issues the DS to the subject as part of the process of issuing a digital certificate (DC).

Certificate Authorities

A certificate authority (CA) is a trusted issuer of digital certificates (DCs). There are two types of CAs: root CAs and intermediate CAs. Root CAs issue DCs to intermediate CAs, which in turn issue certificates to individual server entities. Root CAs also issue DCs to themselves. (The trustworthiness of root CAs’ comes from other than electronic means, such as having their private keys secured on cryptographic hardware in a tightly controlled area of the network.)

For example, www.whitehouse.gov‘s DC is issued by DigiCert SHA2 Secure Server CA, an intermediate CA. This CA’s DC is issued by DigiCert Global Root CA, a root CA. This CA’s DC is issued by itself.

This sequence of DCs is called a digital certificate chain.

The next article covers how TLS implements encryption and authentication to effect secure data transfer.