… and the necessary bit of seasoning that you might not have noticed on your most critical logic, with OutSystems

This article is meant to explore some peculiarities of the CBC Mode, an Encryption Scheme widely used together in cybersecurity to encrypt messages, along with a way of guaranteeing confidentiality and integrity in a secure way. Finally, let’s see how do we tackle this complex subject in OutSystems.

We all want to maximize data confidentiality and integrity when exchanging messages on the internet with someone without an unwanted party in the middle tinkering with data sent back and forth. Messages in this context might be anything we want to convey, ranging from your photo album, emails, or even a Git version control push commit of your code. One of the choices any I.T. worker should worry about is on the Encryption Scheme used to encrypt the data to be sent.

On the image below, it is represented three rounds/blocks of a C.B.C. encryption scheme. Imagine your whole message broken down to chunks of a fixed size. Each chunk will contribute along with the encryption key to originate a Ciphertext chunk. At the end of the encryption process, those ciphertext chunks will be concatenated and form the message ciphertext. Another aspect to notice is that one of the inputs of any of those encryption blocks, apart from the first block we will refer to in a bit, is the encryption of the previous chunk, therefore, making the resulting Ciphertext much more scrambled. This makes encryption even more unpredictable, though the encryption of each chunk always has to stall for the previous chunk to be encrypted, therefore making it impossible to parallelize the whole encryption scheme.

Three rounds of a Cipher Block Chaining (C.B.C.) Encryption Scheme

On these schemes, the IV, A.K.A. Initialization Vector, is a number that is better not to be already taken before. This IV must ideally be the closest to random, or the risk of Statistical Correlations between IV and Plaintext or the Chosen Plain Text attack might wipe out security (link). By using an IV in a proper encryption scheme, like in C.B.C., one can produce distinct ciphertexts from the same message on the assumption that a different IV is used in each message encryption. This is a useful property of this kind of encryption schemes, for that, a Network attacker, someone that can eavesdrop on packets transmitted from their victims’ machine to the router in, say, an internet cafe, will not even have a clue that the encrypted message might have already been sent before. This lack of information on the bad guy’s side strengthens confidentiality on the legitimate users exchanging correctly encrypted messages.

Nevertheless, another key aspect worth mentioning is that, while Confidentiality is one of the key elements to form a secure communication channel between two parties, it alone does not provide integrity. If an attacker can tamper with the message being sent without any of the two parties being aware, Confidentiality by itself will not work. The attacker will be running a “Disinformation” attack, for one party cannot be sure that the message received is the one the sender intended to send. As such, a good point to remember is that we can not assure Confidentiality without Integrity. Now, is adding integrity as easy as appending a Signature to the message? Not quite…

To provide integrity of the message being sent, we need a way to let the receiver know that the message while being propagated through the channel, for example, within the vicinities of the Internet Cafe, was not changed during the transmission. If it was, the recipient would know and would reject the message. Such a message could have the following kind of format:

Template format of an encrypted message

As the picture illustrates, the M.A.C. derived from the message would need to guarantee the integrity of encrypted content. Two ways of combining Confidentiality that comes with encryption and integrity from digital signatures: MAC-then-Encrypt and Encrypt-then-MAC.

It turns out that the worst way to encrypt a message is to do MAC-then-Encrypt. Multiple attacks can be directed to this form of encryption; some of the known are BEAST, Lucky13, POODLE; in a very succinct way, it has to do with the recipient must first decrypt the message to calculate the M.A.C. to verify the integrity of the message.

MAC-Then-Encrypt

As so, the correct way to do encryption is Encrypt-then-MAC, for the recipient can calculate the M.A.C. right away on the Ciphertext without the need to decrypt the message. This is the same scheme used on the recent T.L.S. version 1.3 to secure HTTP requests.

Encrypt-then-MAC

Lastly, it is worth mention that in OutSystems, all the previous points were taken care of. Namely, the CryptoAPI Extension from OutSystems already has built-in code. Namely, the function encrypt, called from the AES_Encrypt exposed Server Action.

1public static String encrypt(byte[] keyBytes, String plaintext)
2        {
3            using (Aes crypto = getCipher())
4            {
5                crypto.Key = keyBytes;
6                crypto.IV = getRandomBytes(crypto.BlockSize / 8);
7
8                byte[] plainBytes = Encoding.UTF8.GetBytes(plaintext);
9                MemoryStream ms = new MemoryStream();
10                ms.Write(crypto.IV, 0, crypto.IV.Length);
11                using (CryptoStream cs = new CryptoStream(ms, crypto.CreateEncryptor(crypto.Key, crypto.IV), CryptoStreamMode.Write))
12                    cs.Write(plainBytes, 0, plainBytes.Length);
13                ms.Close();
14                var cipherBytes = ms.ToArray();
15
16                HMACSHA256 mac = new HMACSHA256();
17                mac.Key = keyBytes;
18
19                var macBytes = mac.ComputeHash(cipherBytes);
20
21                MemoryStream resStream = new MemoryStream();
22                resStream.Write(cipherBytes, 0, cipherBytes.Length);
23                resStream.Write(macBytes, 0, macBytes.Length);
24                return Convert.ToBase64String(resStream.ToArray());
25
26            }
27        }

On line 6, a random IV is calculated and used on an encryption algorithm called A.E.S., A.K.A. Advanced Encryption Standard, instance at line 11 to create a CryptoStream instance, encrypting the message on line 12; since the Mode parameter is not defined by the A.E.S. instance upon creation, the default results in C.B.C. Note that the own IV is written into the message stream at line 10 to be used by its decrypt function complement. Moreover, at line 19, a M.A.C. Algorithm, namely SHA 256, is calculated upon the Ciphertext previously originated, making use of the Encrypt-then-MAC approach.