A Simple Microcontroller Coprocessing Encryption Engine (Part 2)

Using the Encryption Engine in a Secure System

So before I get into the detail design of our Encryption Engine I want to explain how we will use it to create a secure system. As I previously stated, we are going to use the engine to secure serial data from a microcontroller. So in order to achieve this we are going to build the engine around an implementation of the XXTEA algorithm.

XXTEA is a symmetric-key block encryption algorithm. So this means that we encode and decode the data with the same key. And the fact that it is a block algorithm means that the plaintext and cyphertext are processed in ‘blocks’ of a predefined size. Within XXTEA we use a block size is 32 bits (4 bytes) with a minimum of 2 blocks and these are encrypted using a secure key which is 128-bits in length.

So you may immediately be thinking – wait a minute my serial data doesn’t come in nice eight byte chunks! However we don’t need to worry about this as we will not be encrypting the data to and from the microcontroller directly, as I will explain below.

Creating a Stream Cypher

We are going to convert the XXTEA block cypher into a stream cypher by using an encryption method called Counter or CTR mode.  So with this method we sequentially encode an incrementing counter value with our secret key and use the output as a ‘keystream’. We then exclusively OR our keystream with our plaintext to create the cyphertext. In order to achieve good security it is essential to use a counter of sufficient length to ensure that it does not wrap round and create a repeating keystream. In our application we will use a 64-bit counter to give us 18.4×10^18 bits of encoding before the keystream starts to repeat. Oh, and as an additional bonus that’s 18.4×10^18 per unique secret key!

As we are XOR the keystream with the plaintext we can encode data from our microcontroller of any bit length as we simply get the next keystream value every eight bytes of data. I have shown the encryption scheme in the diagram below.

Encryption Process
Encryption Process

 

 

The initial counter value is sometimes called the initialization vector and this value does not need to be kept secret. So we can openly transferred this value across the network when we are setting up our secure communication protocol without compromising our security in any way.

Decrypting the Stream

If we look at this arrangement in more detail then it should become apparent that as we are not encrypting our plaintext directly with the XXTEA algorithm but instead we are simply XORing it with our keystream. So this means we don’t need to run a decrypting algorithm to extract the plaintext from the cyphertext; which is great news for our implementation which only has limited resources.

In fact, to decrypt the stream we simply need to encrypt the appropriate counter value with our secret key and XOR the derived keystream with the cyphertext to extract the original plaintext. I have shown the decryption flow in the diagram below.

Decryption Prcoesses
Decryption Process

 

This covers the second point I made at the end of my previous posting. So we only need to implement the encryption portion of the algorithm to both encrypt and decrypt our communications.

Shared Information

For use to be able to communicate in a secure manner across the network we need to share two pieces of information.

  1. We need to know the common secret key value.
  2. We need to know the value of the 64-bit counter we are using as the initialization vector.

Once we have established these two pieces of information we can then create a secure communications network. So I’m not going to discuss the method by which you can create and distribute the secret key value. There are many possible answers to this question which you can find on the web.

One addition point I’d like to make is that my design will only store the secret key in dynamic memory. So if we remove the power from the CPLD we will lose the secret key. I have chosen to do this so that it is not possible to extract the key by interrogation of the configuration memory of the CPLD.

Finally, with the CPLD being a CMOS based device it is possible to suspend the clock to the device. Once suspended we can achieve very low power levels without losing configuration. So it can be used in very low power applications with very little additional drain on the battery power.

Creating a Message Authentication Code

The SPINS secure communications protocol proposed by Berkeley consists of two elements SNEP and µTESLA. So we are most interested in the first of these elements SNEP  (Secure Network Encryption Protocol). As our CPLD design will be doing all of the computation processes associated with SNEP.

The purpose of SNEP is to provide three important security primitives: data confidentiality, data authentication and data freshness. So we need to produce a Message Authentication Code (MAC) to provide data authenticity. Therefore we consider the MAC to be an encrypted checksum for the message. And in order to generate this we need to a different encryption mode called Cypher Block Chaining or CBC.

With the CBC mode we take the first eight bytes of our message and encrypt these with a secret key. The result of this is the MAC for the message so far, which I’ve called MAC[0]. This MAC is then XOR’ed with the next eight bytes of the message to create a value which we encrypt with a secret key to produce MAC[1]. We continue this process all the way through to the end of the message to produce the final MAC[n] value. So we can then send MAC[n] with the encoded message as an authentication code.

So when we decode the message we can then simply repeat this process and use the result to validate that the message received produces the same MAC[n].

To create a symmetrical process for each stage I have added a first stage of XORing the message with all 0’s. This ensures each stage is identical with the first stage encrypting the plaintext message.

Cypher Block Chain
Cypher Block Chaining

 

Encryption only

Again this processes only uses the encryption part of the XXTEA algorithm. This means that it is only a small extension to the functions we have already identified.

We will ensure confidentiality within our system with the encryption process. While achieving data freshness by having timely interactions within the system.

Conclusion

So I hope this gives you an insight into what we are going to achieve with this Encryption Engine. I’ve also explained how it might fit into our secure system. The next thing I want to look at is the design and simulation of the basic XXTEA encryption process. So this will be the subject of my next post.