Technical Security Controls

There is a lot to talk about with regard to technical security controls, aka the “sexy stuff” like firewalls and IDS.  So rather than bore you with technobabble (in Scrappy Information Security, I start boring you with packets, headers, ports & MACs as a way of introducing how the Internet works), I will instead focus on an explanation of encryption.

Why encryption?  Because it is no exaggeration to say that secure online anything that involves money or personal information could not happen without encryption.  Further, secure remote access—used by corporate road warriors—would not be possible without encryption.  And increasingly, encryption is being used to keep private data private when “at rest,” that is, when sitting in a file on a database somewhere.  So there is a good chance that your project may rely on it.

Technology aside, encryption is really nothing more than the use of a secret code to hide information from the people to whom you wish to keep it secret.  In this case, though, it is an example of hiding something “in plain sight.”  The bad guys can see it.  They can hold it in their hands.  They just can’t read it.  One of the first documented proponents of encryption was Julius Caesar.  According to legend, he employed what has come to be known as the “Caesar shift.”  When he needed to send a secret message to one of his field generals, he would shift the letters in the message three places to the right.  So “fight now” became “cfdeq klt.”  Though simplistic by today’s standards, the Caesar shift worked, ostensibly because there were no web-based articles on “Breaking Caesar’s Code,” and also because many people of the time were illiterate.

Although the creation of a good cryptosystem quickly becomes very complicated, the above historical anecdote references the two components needed: the algorithm and the variable.  The algorithm is a formula—a series of steps—that must be followed to turn the plain text into cipher text, and vice versa.  The variable is the secret key to the formula.

In the Caesar example, the algorithm is to simply put two alphabet strings on top of each other:

a b c d e f  g h i  j k  l  m  n o p q r s  t  u  v w x  y z
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Without a mono-spaced font, it’s hard to get them to line up.  But you get the idea.

The key is to shift the lower alphabet three places to the right:

a  b c d e f  g  h i  j  k  l m n o p q r  s t  u v w x y  z
X Y Z A B C D E F G H I J K L M N O P Q R S T U V W

This method of encryption is called symmetric encryption, since the same key encrypts and (when applied in reverse) decrypts.  Symmetric encryption is used today, though, not surprisingly, the algorithm is much more complex and the key is longer.

Symmetric encryption is used because it is quicker.  Unfortunately, symmetric encryption suffers from three primary drawbacks:

1. Key exchange can be problematic.  In short, you and I have agreed to use the alphabet-shift method to encrypt our communications.  Before I send you a message, I decide that the letters should be shifted eight places to the right.  How exactly do I get this information to you?
2. Key management becomes difficult as the system grows.  Let us say I have a lot of friends I want to exchange information with.  Not only do I want to keep the information safe from the outside world, I also don’t want the other members of my circle to eavesdrop on my communications with any one of them.  So when I communicate with Bob, we agree to shift the alphabet one place to the left.  With Mary, it is two.  (We have to assume that no one in the group is smart enough to try various shifts on any intercepted messages not bound for them.)  Remembering “Bob / one,” “Mary / two” is easy enough.  But managing the various keys grows more complex as my circle of correspondence grows.
3. It cannot be used for other important facets of secure communications, such as authentication (I am who I say I am) and non-repudiation (I cannot tell a lie; it was me who sent that email).

Recognizing these limitations, two really smart guys—Whitfield Diffie and Martin Hellman, to give credit where it is due—developed a new system called asymmetric encryption.  Asymmetric encryption uses very high-level math, involving prime numbers on the order of 100 to 200 digits, raised to powers and run through other mathematical blenders.  What comes out of these calculations are two related numbers.  One of the numbers easily can be derived if you know the other.  But trying to reverse the calculation is for all intents and purposes mathematically impossible.

A commonly offered analogy is the dropping of a glass.  Dropping a glass very easily creates thousands of small pieces.  Recreating the glass from those scattered pieces, while theoretically possible, is extremely difficult and ultimately probably is not worth the effort.  I would offer the following as another real-world example.  With a recipe in your hand, you ostensibly could whip up a batch of Coca Cola in your kitchen.  But try starting with the bottle of Coke, and determining all of the ingredients.  Pepsi certainly has not been able to do it yet.

So what is the significance of these two numbers?  They are used to create a pair of keys: One public and one private.  I place my public key literally “out there,” for anyone and everyone to use to send me a message.  Actually, anyone who wishes to exchange confidential information puts their public key out there in a centrally-located place, called a certificate authority, or CA.  When someone uses my key to encrypt a message to me, it is dropping the glass.  When I receive the message, I use my private key—a glass-restoring magic spell, if you will—to decrypt it.  If someone intercepts the message and does not have my private key, he must reassemble the glass with tweezers and glue.

As you probably can extrapolate, this system is called public key cryptography.  In contrast, the use of a symmetric key sometimes is called private key cryptography.

So if asymmetric cryptography is so good, why would anyone use symmetric cryptography?

As touched on earlier, longer keys lead to messages which are “better” encrypted, that is, harder to break.  With asymmetric encryption, because there exists a mathematical relation between the two numbers, they must be very large in order to result in a sufficiently strong key.  Longer keys require more time to encrypt and decrypt.  If you are sending an encrypted email to someone, a few extra seconds probably will not concern you.  But if you are using encryption to secure an ongoing communication—such as an online banking session or an online purchase—the latency period can become troublesome.  As such, a common trick is to use public key cryptography to agree on a symmetric key, and then use that symmetric key for all further conversation in that session.

As a way of conclusion, I would say that cryptography is perhaps the most challenging concepts in information security.  But it is everywhere, and in the future will only be more everywhere.  As such, an understanding of the basic principles is important.