AES Encryption a Primer

The Advanced Encryption Standard (AES) is an encryption algorithm that is based on a symmetrical block cipher. This means the AES cipher can equally be used to encrypt and decrypt. The AES standard was defined by the US National Institute of Standards and Technology (NIST) through the selection of the Rijndael Family of ciphers.

AES comprises three block ciphers: AES-128, AES-192 and AES-256. Each cipher encrypts and decrypts data in blocks of 128 bits using cryptographic keys of 128-, 192- and 256-bits, respectively. Symmetric (also known as secret-key) ciphers use the same key for encrypting and decrypting, so the sender and the receiver must both know, and use, the same secret key.

The encryption or decryption process requires the algorithm to conduct the block cipher processing a number of times to assure the encryption of the data. This is referred to as a round and it consists of several processing steps that include substitution, transposition and mixing of the input plain text and transform it into the final output of ciphertext.

 
Diagram_Cypher.png
 

AES 256 is widely referred to as being ‘Military Grade’ encryption, largely due to its origin as a NSA approved algorithm for protection of data up to Top Secret. To understand this claim, it is important to understand the factors that can weaken the implementation of AES, causing security vulnerabilities.

AES can be implemented in differing ways, for instance there are numerous open source implementations such as Open SSL, Javascript, and Python that implement the AES algorithm. These implementations are not necessarily robust or correct, even if the AES algorithm is mathematically challenging to compromise. With cyber vulnerability, the risk of compromise is likely to come from errors in the software implementation of the AES algorithm or its use within an application, rather than the mathematical basis of the AES algorithm itself. The Heartbleed bug is an example of this in practice. In Heartbleed the crypto services for TLS/SSL had a vulnerability where it exposed the private key material used to encrypt the data. This was not a vulnerability of the encryption, but of the implementation.

Understanding whether AES128 or 256 is suitable for a certain level of classification is not direct and straightforward,  Without replicating sensitive data, we can outline these factors are  largely related to;

  • The number of rounds the cipher runs for,
  • The secure origin of key material from a known random number source (ensuring unique private keys)
  • Strength of protection over the encryption key processing (including storage, generation and keeping the secret a secret)
  • Protection of the physical cryptographic function (the computer or component implementing the cryptographic function)
  • Origin of the AES algorithm implementation (geographic and source of the software/hardware implementation).

Both the UK and US Governments operate schemes to ensure that cryptographic implementations are verified when used to protect classified data. The widest known scheme is the Federal Information Processing Standards (FIPS) 140, which is a standard for the build and verification of cryptographic modules. FIPS 1401 has 4 levels of security against which a module can be qualified, allowing use against a variety of US DoD and Government classification levels. It is common for encryption solutions that claim FIPS140-2 compliance is qualified against FIPS 140-2 Level 1 (the lowest level), which affords only simple assurance of implementation.

Equally, simply taking FIPS 140-2 compliance as a simple correlation of applicability to protect classified information is not a valid approach, even more so when comparing US accreditation standards against UK protective marking levels. Such claims need to be examined closely, for instance some devices/software can claim protection for information up to US Top Secret, but in reality the solution is a generic FIPS 140-2 Level 1 solution. These claims do not necessarily translate as suitable for the protection of UK protectively marked data, depending on the deployment scenario and various threat vectors.

To ease the ability to choose appropriate solutions, the UK National Cyber Security Centre runs separate compliance schemes aimed at compliance against UK requirements;

  • Commercial Product Assurance (CPA); Provides assurance that a product meets the requirements for protecting information up to and including OFFICIAL-SENSTIVE
  • CESG Assisted Products Service (CAPS); Provides assurance that a product meets the requirements for protecting information up to and including Top-Secret.

These schemes check the encryption product for the presence of vulnerabilities, but also the surrounding provision of active support, configuration control and other factors that can affect the quality of the cryptographic protection.

It must be remembered that simply having a product that is assured against a scheme such as FIPS, CPA or CAPS is not an automatic approval for UK MOD accreditation. Instead the accreditation case for a system takes the encryption product into account, but looks at the wider threats that could be applied to a system (or not) along with the physical, cyber and other effects against the system. The implementation of the encryption must be looked at in this context.

Conclusion

Simply talking about the strength of AES with 256 bit key material (AES-256) is generally meaningless without taking into context the protection measures, quality and other areas pan Defence Lines of Development (DLOD) that are required to provide protection of data confidentiality and integrity. Application of an unverified AES solution in a product cannot provide assurance against vulnerability and compromise of confidentiality.



Interested in this subject?

Get in touch, we are happy to provide assistance and training

InsightsLuke Davies