Encryption to take secure programming a step forward

[http://blog.trendmicro.com/wp-content/uploads/2012/03/Cartoon-2.jpg]

What is "Encryption"? Why is it associated with secure programming? What are the benefits of encryption? These are questions to be evaluated in this blog post along with some interesting facts about encryption. As we all know hashing is a one-way process in which the plain text/input cannot be retrieved from the hash value. What if we want to get the plain-text from the hash value? What could be the solution? The solution is Encryption.

Encryption

Encryption is a technique used to convert a plain text into an encoded format or cipher-text which could be reversed back to the original plain text. Unlike hashing, encryption is a two-way technique.

Fig 1: The flow of encryption

Fig 2: Encryption/Decryption related details for the Fig 1

Since encryption is a two-way process it allows the users to retrieve the encrypted value back to its original text. This is very useful in terms of bank transactions to store and retrieve credit/debit card details. Some of the significant uses of encryption are as follows:

1. Secure network communications (SSL/TLS handshake) 
2. Digital Signature

Secure programming with encryption 

Encryption requires a special attribute called "Key". Key is nothing but a string of bits used by an algorithm to encrypt the plain text to a cipher-text and vice versa. Classification of the cryptography keys falls under two main categories. They are as follows:

1. Symmetric key - One key
2. Asymmetric key - Two keys

Even though the structure and the flow of these two types are different, cryptographically both of them have the same strength. 

1. Symmetric Key Encryption

Let's take a look at the following scenario where A and B are communicating through a secure channel using the symmetric key.

Fig 3: Communication using Symmetric key

Fig 3 A sends a message encrypted with the key 1. B receives the cipher-text and decrypts it with key 2. Key 1 and key 2 are the same in this scenario where encryption and decryption are done using the same key. This is known as "Symmetric Key Encryption". Both sender and receiver will be using the symmetric key for encryption and decryption and therefore it will be easy to share the keys among peers. Also, the computational cost is low as it uses simple algorithms to generate the key for both encryption and decryption. 

Let's take another scenario to further analyze the symmetric encryption. There are three users in the following communication scenario where each of them will be communicating with one another.    

Fig 4: Symmetric key maintenance per user

Fig 4 illustrates the issue in following a symmetric key encryption. The issue identified here is the number of keys that a user(entity) should maintain depends on the number of peers the user is connected to. If the total number of entities connected in a network is L then the number of keys per entity should maintain will be L-1. In the practical scenario, each entity will be connected to hundreds or thousands of other entities. In such situations, it will be complex for the entity to maintain a huge number of keys.

Another important problem in symmetric key encryption is that for both encryption and decryption the same key is being used, so in case if a hacker gets to know the key then the communication will no longer be secure. Since most of the times, the symmetric key is being generated from some simple algorithms, cracking the key will not be an issue for a hacker. Asymmetric key encryption was introduced as the solution for the identified problems in Symmetric key encryption.

2. Asymmetric Key Encryption

Asymmetric key encryption is also known as "Public key encryption". This uses 2 separate keys for encryption and decryption known as public and private keys. 

Fig 5: Communication using Asymmetric keys

In asymmetric key encryption once a message has been encrypted by the receiver's public key (Public key of B) it can only be decrypted by receiver's private key (Private key of B). Therefore, no one else can read or modify the message as the private key of any entity will not be distributed to others. So any entity in the communication network only needs to maintain 2 keys, public and private key of its own. Another fact is that if a message is encrypted with the public key it should be decrypted with the private key (depending on the scenario the key holder might change) and vice versa. 

Comparison between Symmetric and Asymmetric key encryption

Following table illustrates the comparison between symmetric and asymmetric key encryption in general.

Fig 6: Comparison between symmetric and asymmetric key encryption

Real world usage of encryption

The 2 main real-world usages of encryption will be discussed in this section.

1. Secure network communications (SSL/TLS handshake)

SSL/TLS handshake is the very first step in any SSL/TLS connection. Let me tell a small story. Once upon a time, there lived a girl called Alice, not in Wonderland but in Switzerland who speaks English and French. Once she went to India she met a taxi driver called Chittu. As Alice wanted to visit an old palace in Delhi she wanted to ask Chittu to take her to that place. Here comes the real problem. Alice started the conversation by saying a Hi in French. In return, Chittu said "Namaste". Alice didn't know Hindi neither Chittu knows French. But both of them knew English. So they decided to talk in English from that point onward.      

Just like Alice and Chittu did, this is how two entities will get to know each other and share some metadata in order to proceed with the rest of the communication. This metadata mainly includes cipher suite and SSL version details. There are some other details as well but we are more interested in these 2 factors. A cipher suite is a collection of algorithms such as,

• Key exchange algorithm
• Authentication algorithm
• Block/stream ciphers
• Message authentication algorithm

Some of the SSL (Secure socket layer) stable versions are TLS V1.1 and TLS V1.2. Both client and server(the two entities) will agree upon these cipher suite and SSL versions and continue the communication. Before starting to analyze the SSL/TLS handshake there are some factors which need to be clarified at this point. Following are some of the key factors in a handshake.

1. Why handshake?

1. To ensure the client is communicating with the correct server.
2. For both parties (client and server) to agree on a "cipher suite" to exchange data.
3. Deciding on algorithm for necessary keys

Note: 2nd and 3rd points are somewhat similar

2. Three main steps in handshake

1. Hello (Client and Server)
2. Certificate exchange
• If one-way it will be server side certificate
• If two-ways it will be both server and client certificate
3. Key exchange (symmetric key)

Let's take a look at the one-way SSL/TLS handshake process in detail where only the server is being validated.

Fig 7: One-way SSL/TLS handshake

Steps:

1. The client is the one initiates the handshake in which the client sends some metadata such as the cipher suite and supporting SSL versions.
2. In return through ServerHello server send the possible cipher suite and the SSL version through which the server can continue the communication. Along with this information, the server sends the server side SSL certificate as well.
3. Once the client receives the certificate the client extracts the public key from the certificate.
4. Then the client generates a random seed, also known as "pre-master key".
5. Now only the client knows the pre-master key value which it needs to share with the server. So using the server's public key the client encrypts the pre-master key. According to the encryption theory if a encryption is done through the receiver's public key then the decryption should be done through the same receiver's private key. Since only the server knows its private key the server can now decrypt the pre-master key.
6. The client sends the pre-master key to the server.
7. The server decrypts the pre-master key using its private key. 
8. Both the client and server know the pre-master key now. So using the Diffie Hellman algorithm the symmetric key is generated by feeding the pre-master key as the input.

Step 1 to 7 fall under asymmetric type and from step 8 onward falls under symmetric type. The reason for such a flow is because, if the entire handshake is done through one symmetric key then any unauthorized entity could guess/find the key. So the communication will not be secure anymore. On the other hand, if the entire communication is to be done using the asymmetric key then again each and every request and response should be encrypted and decrypted which will be mathematically costly and time-consuming.  

As an efficient and secure mechanism, a hybrid way of communication is built using both symmetric and asymmetric types. Until both, the parties generate a common symmetric key an asymmetric key exchange method is followed and the symmetric key is generated by both server and client the rest of the communication is done in a symmetric way. This is how one-way SSL/TLS handshake is done. To perform a two-way handshake just as the server did, the client will also produce its certificate to the server where the server will confirm whether it is communicating with a valid client or not.

Some additional points:

In server.xml foro HTTPS connector is the clientAuth is set as,

• clientAuth="true" 
• It's a two-way handshake where the client needs to provide its certificate.
• clientAuth="false"
• It's a one-way handshake where the client doesn't need to provide client certificate.
• clientAuth="want"
• Even though it's a two-way handshake still the client can continue the communication without providing it's certificate to the server. It something like optional.

2. Message signing and verification

The next common real-world usage of encryption is message signing and verification. This is about verifying that the message is from the correct source or not. The process is very straightforward. Let's take a look at the following diagram.

Fig 8: Message signing and verification

Steps:

1. The sender will hash the message using a hashing algorithm.
2. The hashing algorithm returns a digest.
3. The digest will be sent encrypted using the sender's private key. 
4. This is known as the Digital signature and will be attached to the message.
5. The message along with the signature will be sent to the receiver.
6. The receiver hashes the message with the same hashing function that the sender has used.
7. The hashing function will return the digest.
8. The receiver will decrypt the signature with the sender's public key.
9. As the result, the decrypted value will be obtained by the receiver. 
10. If the digest value received from step 7 and the decrypted value obtained from step 9 are same then the message is from the receiver and the message is genuine. This maintains the data integrity. 

Summary

This blog has covered the basic concepts of encryption and decryption. It also analyzed the main 2 types of encryption; symmetric and asymmetric. The uses of public and private keys are discussed in this blog along with the main usages of encryption which covered SSL/TLS handshakes and message signing and verification. Hope this was a useful read :)