Executive Summary

“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.

Brief History

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.

Cryptography

Today, the four goals of any cryptographical system include1:

• Confidentiality (or privacy) – ensures that that data is kept unseen by others so that no one other than the intended recipient can read it.
• Integrity – ensures that data received by the intended recipient has not been altered or modified from the original. It includes processes to allow the recipient to confirm that there was no unauthorized modification (insertion, deletion, or corruption) of the original message while it was in transit. The term “checksum” is also used in cryptography systems.
• Authentication – includes techniques to verify the identity of the user or system that sends and receives the message. It is done to prove who you are and techniques include the use of digital certificates from third-party trusted authorities referred to as Certificate Authorities (CA).
• NonRepudiation – uses techniques to prove that the sender did send the message. It is “ensuring that a traceable legal record is kept and has not been changed by a malicious entity.” 2

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.

Encryption Keys

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.

Key Size

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.

Encryption Families

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 or Secret Key Cryptography (SKC)
• Asymmetric or Public Key Cryptography (PKC)
• Hashes

Symmetric/Secret Key

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/Public Key (PK)

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.

Asymmetric Example

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.

Hash Functions

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.

Hash Example –File Integrity

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.

Hash Example –Password Security

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.

Certificate Authorities (CA)

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.

SSL/TLS (Secured Sockets Layer or Transport Layer Security)

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.

SSL Example

Alice wants to securely conduct online business with Bob’s Beauty Supply.

• She is at Bob’s webpage, adds products to her cart and wants to check out.
• Her browser contacts the Bob’s secured web server that sends its certificate to Alice’s browser. Her browser checks the certificate’s signature against the information stored in the browser and if there is a match, Bob’s certificate is deemed valid. Bob’s secured web server is verified and considered to be trusted. If Alice’s browser hasn’t been updated, it may not see a match. It will then contact the issuing CA and check to see if the certificate is valid.
• If it is, Alice’s browser will initiate the security aspect of the process. Bob’s web server sends his public key to Alice.
• Alice wants to send a message or file. Her browser’s AES algorithm symmetrically encrypts her data with a one-time key.
• Her key is then encrypted using Bob’s public key.
• Both the encrypted message and key are then sent to Bob’s web server.
• Bob uses his private key to unencrypt Alice’s AES key, which is then used to decrypt Alice’s message or file.
• Bob may do a hash check to ensure that the message file has not been altered.
• This complex process occurs automatically in the background between the web server and browser.

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.

Failure Modes & Controls

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:

• Social Engineering – Employees giving up sensitive information, including passwords to hackers, and thereby allowing access to critical areas of the protected network. Make employees aware of phishing schemes and remind them to not disclose sensitive information without sufficient verification.
• Ineptitude – Users using weak passwords or storing personal passwords inadequately that allows an unauthorized party access to the user’s network systems, and thereby allowing them access to certain areas of the network and critical files. Users need to have strong passwords that are at least 8-10 characters long and include a mix of letter, symbols and numbers. Change these every 90 days and do not write them down or store them insecurely.
• Key and Password Storage – Ideally, the algorithm appliance has provisions for the secured storage of keys and passwords but if this is configured incorrectly, it provides an open door for a potential hacker and completely compromises the system. Appliances need to be properly configured and updated as necessary.
• Key Size – Use of algorithms with short key lengths (i.e. 56 bits) can compromise the secured message. These have been broken by brute force attacks. Short key algorithms may still be in use because of backward compatibility, hardware requirements or possible oversight. Longer key lengths (128 bits or higher for symmetric) should be the norm unless there is an overriding need for a short key lengths.
• Certificate Authority – The entire PKI system is built on trust that extends from the end user to the CA that vouches for user’s identity. A compromise of this system could lead to entities impersonating someone they are not.

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:

• In March 2011, a hacker attack compromised the access credentials of a Comodo (a CA) partner in Italy and used the partner’s privileges to generate nine fraudulent SSL certificates for major sites such as Google, Skype and Yahoo.6 Comodo indicated that attacks originated from an IP address in Iran.
• In July 2011, an internal audit at DigiNotar (CA) indicated that they were attacked and their cryptographic keys were compromised resulting in the issuance of fraudulent certificates for Google, Mozilla add-ons, Microsoft Updates and others7. The problem was so widespread that Diginotar customers had to replace all of their certificates since major browser vendors revoked all Diginotar certificate because the validity of the certificates could not be confirmed. Dignotar’s authority was revoked and the Dutch government took over the operations. Ultimately Diginotar had to file for bankruptcy.

Controls include:

• CAs need to be aligned with the new “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates.8” This is the “first international baseline standard for the operation of Certification Authorities (CA) issuing SSL/TLS digital certificates natively trusted in browser software.”9 It was announced in December 2011 and went into effect July 1, 2012.
• Browsers should be kept updated with current trusted and untrusted certificate lists.
•  Use of Extended Validation SSL Certificates that offer highest level of authentication and provider users with a green address bar when on adequately secured sites. It gives consumers an additional level of confidence on the security of the system.
•  Working with established and trustworthy CAs that have good security controls.
• Appropriate storage of keys in secure and encrypted hardware devices.

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

Contact Us

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.

References

1. “Department of Homeland Security: Control Systems Communications Encryption Primer.” Control Systems Security Program National Cyber Security Division (December 2009): Page 1. Online. Internet. Accessed May 2012, https://www.hsdl.org/?view&did=7972 
2. Ibid 1, page 2
3. Ibid 1, page 12
4. Kessler, Gary. “Overview of Cryptography” (November 2010): Online. Internet. Accessed May 2012, http://www.garykessler.net/library/crypto.html#pkcca  
5. Roberts, Paul. “Phony SSL Certificates issued for Google, Yahoo, Skype, Others.” Threat Post – The Kaspersky Lab Security News Service, (March 23, 2011): 1 pp. Online. Internet. Accessed May 2012, http://threatpost.com/en_us/blogs/phony-ssl-certificatesissued- google-yahoo-skype-others-032311  
6. Wood, Paul. “Internet Security Threat Report-2011 Trends.” Symantec, (April 2012): Page 23. Online. Internet. Accessed May 2012, http://www.symantec.com/threatreport/
7. Ibid 6
8. http://www.cabforum.org/
9. Ibid 6, page 24
10. Ibid 6, page 24