“Two can keep a secret if one of them is dead?” - Unknown
The need for secrets and privacy is ever-present in today’s digital environment. Anything that you do online, from shopping to banking, requires the use of passwords, authentication user IDs and secured modes for storing and transmitting information. To facilitate these protections, a wide variety of encryption and cryptographic systems are in use—working in the background while we go about our daily routine.
This paper is a primer on encryption systems and provides a high level overview of encryption systems, types of systems used in day-to-day processes, terms that you are likely to see and the potential pitfalls of such systems.
Some say that encryption systems developed shortly after human beings learned to write. The goal at that time, as we all know, was to have a system that allows one person to communicate with another without a third intercepting and reading the message. Early encryption systems were rudimentary and involved simple letter transpositions, something like the Captain Plasma decoder ring found in a cereal box. Cryptography saw significant evolution during WWII by the Germans, British, Japanese and Americans, both in terms of developing new ways of encrypting messages, as well as in breaking such systems.
Today, the four goals of any cryptographical system include1:
There are a wide variety of encryption algorithms and their use varies depending on the user type, application, data or level of security needed. These algorithms are essentially elaborate mathematical functions that convert a standard message/data/file (called plaintext) into unreadable data (ciphertext). The other goal of these systems is to prevent someone from reverse engineering the ciphertext message simply by looking for patterns in it. A well-designed algorithm eliminates all such patterns so that the ciphertext looks like a random list of characters.
After the algorithm, key size is critical in the effectiveness of any encryption system. Keys are described in terms of bits since bits form the foundation of all computer communications. Keys are machine-generated through pseudorandom number generators within the algorithm. The key is a string or list of characters that serves to initiate or set up the algorithm. If a key with minor variation is used (i.e. “123” vs. “122”) and applied to a plaintext message, such as “HELLO,” it should generate ciphertext that should be markedly different for each of the keys. This eliminates the potential of someone reverse-engineering the ciphertext to determine the actual key, which could then be used to decrypt all messages. Keys need to be sufficiently unique so that they cannot be inferred or guessed.
To ensure the uniqueness of a key, we need very large set of keys to choose from and this is determined by the key length. A 2-bit key (22) has four possible key choices. A 3-bit key (23) has eight choices. As you can see, key size is based on powers of 2 and the number of choices doubles at every iteration. When you have a small key size, you can easily develop a list of all of the key choices and apply them all to the algorithm until you find the correct key. This is referred to as Brute Force attack. Using specialized computer hardware, researchers have been able to brute force break an algorithm with a 56-bit key. They were able to find all 256 or 7.2x1016 (72,000,000,000,000,000) combinations.
A 128-bit key (2128) for symmetric encryption would have 3.402x1038 choices. This is an enormously large set of combinations and it is nearly impossible to conduct a brute force attack on this. Key sizes can be larger depending on the algorithm.
The three common algorithm families that are encountered in typical digital transactions are noted below and form the basis of Public Key Infrastructure (PKI):
Symmetric encryption simply uses the same key to encrypt and decrypt the message. This works well when attempting to secure content that does not requiring sharing the key with anyone else. If an encrypted message is sent, then the key must be sent with it so the receiver can decrypt the message. This can be very easily intercepted, thereby negating the entire encryption process. Because of this, symmetric key is generally used to encrypt and secure data that is at rest (in storage) rather than data in transport.
There are a wide variety of algorithms and each works differently, has different computing power requirements, varies in key size, and has different applications. Software applications used for encrypting stored data may use a variety of these algorithms. Examples include DES (56 bit key size), Triple DES (168), DESX (120), CAST (128/256), RC variants, Blowfish (32 to 448), Camellia, Kasumi, SkipJack, Aria (128/192/256), AES (128/192/256), etc. NIST designated AES (Advanced Encryption Standard) to be the official successor to the 56 bit DES in December 2001 and currently is the standard for symmetric encryption. AES has received NSA approval as well.
Asymmetric Encryption uses one key (public key) to encrypt the plaintext message and another key (private key) to decrypt the cipher text message. Ciphertext cannot be decrypted using the public key. The public and private keys are mathematically related to one another, but cannot be reverse-engineered. If you know the public key, it is mathematically impossible to derive the private key.
Various algorithms in this space include RSA, Diffie-Hellman, Digital Signature Algorithm, ECC, ElGamal, LUC, Cramer-Shoup, etc. Key sizes on these will vary from 256 bits to 3072 depending on the algorithm and the level of security desired.
Algorithms in the asymmetric family are computationally more intensive and operate slower than comparable algorithms in the symmetric family.
As in symmetric, asymmetric keys have to be of adequate length to eliminate brute force attacks. Asymmetric algorithms operate differently and require key sizes that are much larger than those found in symmetric For example, to have the same level of key strength as the symmetric AES 128 algorithm, the asymmetric RSA and ECC algorithms require 3,072 and 256-bit keys, respectively.
Alice and Bob both want to send files to Carol. Carol provides both of them with her public key. The public key is published and openly available. Alice and Bob encrypt the file and send the ciphertext to Carol. Only Carol can decrypt the files using her private key. If Dave intercepts the encrypted file, he can’t decrypt it without Carol’s private key.
A Hash is a one-way, cryptographic, mathematical function that is very important in authenticating a message (data) and in non-repudiating a user’s digital signature.
A hash provides a digital finger print or checksum of a file’s content. The content of the file are put through the hash’s mathematical function to create a string of characters of a defined length called a “digest.” Altering one character in the file results in a significant change in the output hash. These are one-way functions, meaning that once a digest has been formed, it cannot be reverse-engineered to recreate the actual message.
There are a variety of hash functions such as MD4, MD5, RIPEMD, HAVAL, WhirlPool, TIGER, SHA-1 (Secure Hash Algorithm), SHA-2. SHA-1 and 2 were designed by NSA and are the predominant hash function in use today. SHA-3 is under development and should be released by 2013.
So let’s see how this would work in real life. Alice wants to send a file to Bob. She puts the file through SHA-2, and sends the hash digest and file to Bob. She tells Bob that she used SHA-2. Bob runs the file through SHA-2 and then checks the hash digest to the digest Alice sent. If it matches exactly, he is going to be reasonably sure that the file was not altered while being sent and this guarantees the integrity of the file. Additionally, he can use the integrity of the hash output/file to authentic and non-repudiate Alice as the sender of the file. In real life, the hash generation and checking is done in near real-time by the computer hardware/software. There is no user involvement in this process.
Hash functions are also used to securely store password files on servers and computer systems. As a security measure, passwords should never be stored in cleartext format on the server. User passwords are hashed to form a unique digest for each user. Storing the passwords in a hashed format also makes it useless to a hacker that steals the file. Since the hash function is one-way, it is not possible for the hacker to determine the passwords from the digest.
When Bob enters his user ID and password to log on, the entered password goes through a hash function and the digest is compared to the stored digest. If it is the same, then Bob is authenticated and allowed access into the network. However, if Bob forgets his password, there is no way for the system to recover it and he will have to create a new one.
These are commonly trusted, third-party organizations located worldwide that issue digital certificates to others, and have the responsibility of authenticating the identity of these parties who are being issued a digital certificate. “The purpose of the CA is to verify that all certificates being used in the network are both genuine and legitimate.”3 Some of the larger CAs include Verisign, GTE Global, Thawte, etc.
A real-world analogy would be the California DMV identifying someone and then providing them with a driver’s license that would be used by other entities (e.g., bank, department store) to positively identify that person.
Parties that need a certificate would contact the root or intermediate CA to provide a digital certificate once they have confirmed the identity of the party. The digital certificate contains a public key, name of party, expiration date, name of authority issuing the certificate, serial number, how it should be used and digital signature of the issued party.4
A digital certificate is essential in creating the secured, web connection known as SSL.
For this discussion, we will consider SSL and TLS as one and the same although there are technical differences. TLS is a successor to SSL, but for this discussion, we will refer to it as SSL.
Whenever we are conducting business online and require a secure connection, we will see either “https” instead of “http” in our browser address bar, and/or see a small locked padlock icon in our browser window. There is a new variant of SSL called EVSSL (Extended Validation) that generates a green address bar when in a secured environment.
SSL utilizes all of the concepts discussed above to create a secure transmission channel to ensure the integrity, confidentiality and authenticity of the data in motion over HTTP.
Alice wants to securely conduct online business with Bob’s Beauty Supply.
The example above was a secured web-based transaction. Similar encryption measures are found with encrypted email services, which are used to ensure that no one is eavesdropping on the content of the email as the packets are sent off to the recipient. The type of algorithms and encryption family being used will vary depending on the application and security level desired.
Various failure modes noted below can very readily undermine the robustness of the various encryption systems discussed so far. Controls to mitigate these deficiencies are also noted:
Hackers can set up sites that an end user would see as a trusted site, but that turn out to be a site distributing malware. Repressive governments can set up legitimate looking websites (i.e. a Google page) with a fake certificate, but have malware that would track end user’s actions, queries and correspondence from that site. Hackers could create bogus certificates to set up sites for phishing or MITM (man-in-the-middle) attacks, specifically against those who have not updated their certificate revocation lists5. There were numerous hacks at CA in 2011 and two of the prominent ones included:
Controls include:
Always On SSL - This means that SSL is on at all times when a user is in a specific company’s website, rather than simply during a login or other secured processes. This is designed to mitigate against potential MITM attacks and provide end-to-end security.10
To learn more about how OneBeacon Technology Insurance can help you manage technology risks, please contact Dan Bauman, Vice President of Risk Control for OneBeacon Technology Insurance at dbauman@onebeacontech.com or 262.966.2739.