By Steve Norman

Cryptography is one of those subjects that’s always had slightly glamorous undertones for me, directing my thoughts to secret codes, international spy rings, large-scale hacking by a super-criminal and hours spent in my youth happily writing in mirrors, re-arranging the alphabet or doing something with lemon juice that right now I can’t quite recall the specifics of!

At its most basic, cryptography is about hiding information, although in modern times such a definition probably does a huge disservice to the resources spent in mathematical and computer sciences to continuously advance encryption and decryption techniques, computer security, information theory and engineering that all gradually filter down from ensuring national security all the way to our everyday lives, whether logging on to our PCs, withdrawing cash or making a purchase with a credit card.

Advanced Encryption Standard (AES) is an encryption standard currently in use by the US government and has also been well accepted worldwide. It is a block cipher – an algorithm for performing encryption and decryption that uses related keys for each that might be identical or might need a relatively simple transformation to go from one to the other; these are known as symmetrical key algorithms. In the case of AES, these algorithms are made up of a block of individual bits that are then encrypted as a single unit (as opposed to stream ciphers that encrypt each bit individually).

In 2001, the National Institute of Standards and Technology (NIST), in the USA, approved the use of the 128-bit block algorithms implemented by what we know call the Advanced Encryption Standard for non-classified data, then in 2003 approved its use for classified data. The standard is also referred to as Rijndael, which is the name used in the selection process for NIST’s AES that combines the names of its developers Joan Daemen and Vincent Rijmen.

So how does it work in practice? In this case, a block cipher would take a 128-bit block of whatever the sender wishes to communicate (known as plaintext, although it does not necessarily have to be actual text) and turn it into a 128-bit block of cipher-text. This would be done in conjunction with a key, which in the case of AES is a 128-, 192- or 256-bit parameter that specifies the transformation of the plaintext into cipher-text. On the decryption side, the process is similar. The decryption algorithm takes the 128-bit block of cipher-text, combines it with the key, and reproduces the original plaintext.

Due to the fixed nature of these blocks (for example, 128- bits), there are various methods that enable block ciphers to provide the same service to messages of other lengths whilst maintaining the message integrity and confidentiality, though selection of such methods should be made carefully because only the more recent ones can do both simultaneously. Whilst specific details on this are outside the scope of this article, examples of these methods include ECB (Electronic Codebook) Mode, CBC (Cipher Block Chaining) Mode, CCM (Counter with CBB-MAC) Mode and OCB (Offset Codebook) Mode.

AES is the successor to another commonly used standard, the Data Encryption Standard (DES). DES is now believed to be too insecure for many applications, mainly due to its use of a 56-bit block. Despite the invention of Triple DES, which is basically implementing DES three times thus rendering it far more secure; there is still the theoretical possibility of attack which is what makes AES a more attractive proposition today, combined with its relative speed, compact memory requirement and ease of implementation.

So how secure is AES? Well, as mentioned before, it’s good enough for the US government, which you can take or leave as you will. The very few successful attacks on AES have been what are known as side channel attacks, which means they’ve gained information from the actual implementation of a cryptography system, for example information on timing, power consumption or noise emissions “leaking”, rather than from any cipher algorithms themselves within the scope of “security” as discussed here. One such well documented case involved combining timing information generated from a server that was designed to deliver timing information on the encryption cycles, and has been deemed impractical outside of research laboratories; others involve running programs on the same system running AES, which again could be deemed impractical in most cases. Other types of attack are generally based on speculation or theory and have not been proven as being practical.

Based on all of these factors, as well as its wide availability in the public domain, AES128 has been embraced in many applications besides top secret documents, where general security of data is of interest. These include password encryption for PC software applications; secure portable data storage; network interfacing; wireless medical equipment; sensor networks; factory automation control; credit card and other cardbased transactions in commercial as well as in industrial use, for example, in pre-payment meters; a popular related application may also be found in Automatic Meter Reading (AMR) for data collection via Power Line Communication.

This growing usage spurned ports of the Rijndael ANSI C code to many 32-bit microcontroller platforms, with a view to providing unrestricted AES128 middleware libraries free-of-charge to designers to enable easy implementation.

There will typically be three main components included in such libraries:

  • Source code of the encryption, decryption routines.
  • Associated header file for the above.
  • Test routines to verify the execution speed of the routines provided. Encryption key lengths of 128-bits, 192-bits and 256-bits are widely supported.

Implementing the library is very straightforward, generally following this simple process:

  • Call a function that initialises the key that will be used to encrypt and decrypt the messages; you just need to pass the size of the key (128-, 192- or 256-bits) to the library function provided.
  • Call a function to encrypt a 128-bit message; the result is a 128-bit encrypted message.
  • Call the decrypt function.

As mentioned previously, test functions are also a key component of an AES128 library. These could include simple tests, for example performing three encryptions / decryptions with three different key sizes (128-, 192- and 256-bits). Comparison would then be performed to verify that the result of each of these three encryptions / decryptions gives back the plaintext as well as measuring the encryption / decryption timings for each key size. As a secondary function, third party routines such as ValidAES, performs a deeper validation of the Rijndael implementation using externally validated test vectors. Details on this validation method can be found on the Internet at http://blogs.msdn.com/si_team/archive/2006/05/19/602055.aspx. It goes without saying that responsibility for the actual implementation lies with the user of the middleware.

In terms of resource required, middleware requires 4,494 bytes of code memory, 4,096 bytes of data memory and 10,376 bytes of constant memory, based on its usage in an NEC Electronics V850 32-bit microcontroller.

It should be noted that whilst developed with a 32-bit microcontroller in mind, given the general availability of ‘C’ source code in such a library, it would be practical to easily port the code to a 16-bit or even an 8-bit microcontroller, although the required response time should be considered as the CPU clock speed of the selected microcontroller decreases.

As a closing point of interest, apparently the Kama Sutra also encourages the use of ciphers for illicit communications between lovers. The applicability of AES128 for such uses is still to be validated!