skip to Main Content

AES CCM Encryption and Decryption


Cryptography is a fundamental component of any secure system enabling protection of sensitive information. However, the performance of a secure system is affected due to computationally intensive cryptographic transformations. The choice of development platforms for embedding cryptographic applications is made considering many factors like the processing power and speed besides, obviously the cost. AES CCM is a generic combined encryption and authentication block cipher mode. CCM is defined for use with block ciphers with a 128-bit block size, such as AES-128. The CCM mode specification supports authentication and encryption but does also support for messages that require only encryption.AES-CCM algorithm consists of two processes.CCM requires two block cipher encryption operations per each block of encrypted and authenticated message and one encryption per each block of associated authenticated data.

Encryption and Decryption Concept

The original information is known as plaintext, and the encrypted form as cipher text. The cipher text message contains all the information of the plaintext message, but is not in a format readable by a human or computer without the proper mechanism to decrypt it; it should resemble random gibberish to those not intended to read it. The encrypting procedure is varied depending on the key which changes the detailed operation of the algorithm. Without the key, the cipher cannot be used to encrypt or decrypt.

AES Algorithm

AES is a symmetric block cipher having variable key and fixed data length. The key lengths can be independently chosen as 128, 192 or 256 bits, which result in 10, 12 and 14 rounds of operation respectively. The data length is however fixed to 128 bits. The input as well as intermediate data can be considered as a matrix with four rows and four columns called state. Each element of the matrix is composed of eight bits, therefore enabling efficient implementation of AES on 8 bit platforms also. AES is mainly used to ensure secrecy in important communications, such as those of government covert operations, military leaders, and diplomats.


In WUSB AES algorithm is used for data encryption during transmission mode and decryption during reception mode.AES is the main block for MIC calculation in WUSB.Key for the AES algorithm is derived during authentication process. AES block cipher creates a robust stream cipher that can be used to provide integrity, encryption, or both. Wireless USB also supports public key encryption, but only for authentication. Devices may choose to start a first-time authentication with public key encryption. In this case, PK encryption is used to authenticate the device and to protect the distribution of the initial CCM key.

Different types of Authentication in WUSB

The purpose of the Authentication phase is to allow the device and host to prove to each other that they have the owner’s trust. There are several means of doing this, but the essence of most of the methods is that both parties prove to each other that they know a common secret without revealing the actual secret. New connections require some form of user-interaction as one of the parties to be connected will not yet have a Connection key.

Out-Of-Band Channel for Key Distribution

Devices can provide an out-of-band channel for distribution of a Connection key. Examples of such out-of¬ band channels might be wired USB connection, memory card, user-interface, etc. Devices that support this mode of key distribution never have to establish new connections. A connection context is transferred to the device via the OOB channel before the first wireless connection is ever made. Since the device was pre-loaded with a connection context, it can use connection requests to establish connections with the host.

Our device supports this method of authentication.

Symmetrical Association Key Authentication

Devices can have a fixed symmetrical association key. This is typically a hardwired key, set during manufacturing. This key must be unique to the device. The user is required to transfer this key from the device to the host in order to establish a new connection. This may be transferred by data entry or by OOB channel means.

PK Association Key Authentication

If devices wish, they can support Public Key encryption. In this case, the device must contain a unique key-pair. In this case, the user will not be required to transfer a key, but they will be required to participate in validating that host and device have received the correct public key from each other. This insures that the correct devices have been connected.


In general, hosts are responsible for key management operations. Hosts track the life of session keys and are responsible for creating and distributing replacement keys, or causing replacement keys to be derived. Devices do not request new keys. If a device becomes unsynchronized with respect to the current session key, the device must send a Reconnection request. Session keys are never transferred from device to host via the USB Framework. Distribution of a session key is a one-way function. Once in possession of a session key, the device never divulges that key.

PTK Management

The PTK is derived during the 4-way handshake and typically does not change during the life of the connection unless a Trust Timeout occurs on either the host or device. Under extreme circumstances, the key can be consumed if it is used to encrypt 248 packets. In this case, the host must perform an additional 4-way handshake with the device in order to derive a new PTK before the old PTK expires and the SFC associated with that key rolls over.

PTK is the “working” key for WUSB data encryption. These keys are derived during a 4 way handshake. The host maintains a separate PTK for every device connected. The host uses this key to encrypt all data packets sent to the corresponding device and to decrypt all packets received from the device. The device uses this key to decrypt all data packets received from the host and to encrypt all packets sent to the host.

GTK Management

The GTK is shared among all devices. Because it is shared, it must be changed whenever a device leaves the current group. A device should not discard an older GTK until the host begins to use the new GTK. Once the host uses the new GTK, it must not use the older GTK.

The GTK is a specialized temporary key that is shared by all members of the current USB cluster. It allows the host to send secured messages in a broadcast manner, such as an MMC. These messages are not encrypted, but they still require the addition of a MIC.Devices may not use the GTK for encryption.

Key derivation during 4 way handshake:

Initially after the dn_connect and getting connect_ack from Host, Host and device will start 4way handshake process for the authentication and for further proceedings. In Handshake 1 message host will send 46bytes of handshake data with a set handshake request. In first handshake message host will send TKID, CDID and HNONCE.Device will generate the 128bit random DNONCE.

Key Derivation

Key derivation during the 4-way handshake depends on PRF-256 to generate the actual session keys from the supplied data. The Key Derivation function then calls PRF-256 to compute 256- bits of key stream. This key stream is then split to form the initial management and data keys. The least significant 16 bytes of Key Stream becomes the KCK while the most significant 16 bytes become the PTK.


The input as well as intermediate data can be considered as a matrix with four rows and four columns called state. Each element of the matrix is composed of eight bits, therefore enabling efficient implementation of AES on 8 bit platforms also. The AES algorithm has four basic transformations.

1) Sub Byte Transformation – a nonlinear transformation applied to the elements of the matrix. This first step in each round is a simple substitution, when implemented as a Look up Table (LUT). It operates independently on each byte of state using S-box. The byte, s [i, j] become s'[i, j] through a defined substitution table.

2) ShiftRows Transformation – a cyclical shift operation with constant offsets, applied to the rows of the matrix. This second step in each round is permutation of rows by left circular shift; the first (leftmost, high order) i elements of row i are shifted around to the end (rightmost, low order).

3) MixColumns Transformation – the third step is a resource intensive transformation on the columns of state under which the four elements of each column are multiplied by a polynomial, essentially diffusing each element of the column over all four elements of that column.

4) AddRoundKey Transformation – performs modulo 2 (XOR) operation with the round key, which is obtained from the initial key by a key expansion procedure. The encryption flow starts with the addition of the initial key to the plaintext. Then the iteration continues for (Nr – 1) rounds (Nr being the total number of rounds). In last round the Mix Column step is bypassed.



CCM is a new mode of operation of a block cipher that combines the existing Counter (CTR) and CBC-MAC modes. It uses encryption algorithm to generate encrypted and authenticated data at the same time.

The AES-CCM process requires two AES cores. In order to achieve higher throughput, two separate AES cores, one for CBC-MAC and the other for Counter Mode are developed.

In AES CBC-MAC, the first AES core is working in cipher feedback mode. It XORs the new input to previously encrypted data. The core is used to calculate the MIC for the authenticity of data. The process starts with encrypting the first block and then successively XORs subsequent blocks and encrypts the result. The final MIC is one 128-bits block. Once the first block has been prepared, XORing the current block with previously encrypted block computes the MIC one block at a time. If the last block is not exactly 128-bit, it is padded with zeros. The final output is one 128-bit block, but the CCM requires only a 64-bit MIC, so the low order 64-bit of final output is discarded.


The Encryption process uses AES CBC-MAC core to generate the MIC and the AES Counter core for the encryption of data. The Key Scheduler provides the fresh Temporal Key (TK) for every new session.

In AES CCM encryption, the PTK (key) and A (CCM encryption key) key are feeded to AES encryption block. The output of the AES block is XORed with data payload. After completion of operation A (CCM encryption key) key is incremented by one each time and same process is repeated till last block of data.

In case of AES CCM decryption, it is almost identical to encryption. It first decrypts the data using AES Counter Mode core and calculates the MIC using AES CBC-MAC to compare both the results for data integrity.

Block Diagram of AES CCM

MIC (Message Integrity Code)

In case of OUT transactions, for all packets we are receiving 8bytes of MIC information. In this case we have to calculate MIC and have to match this calculated value with MIC present in packet. If it gets matched then there will not be any MIC error else there is MIC mismatch.

In case of IN transaction if that is secured transmission then we are calculating the MIC and appending at end of the payload.

MIC generation Requirements

  • CCM nonce
    Protocol requires the message and some additional keying material CCM nonce, Counter-mode blocks, and encryption blocks. The CCM nonce provides uniqueness to each message. The Counter-mode blocks are used to calculate the MIC. The encryption blocks provide the key stream that it used to encrypt the message and the MIC.
  • Counter-mode blocks
    Message is broken into 2 or more counter-mode blocks from B0 – Bn.
  • Encryption key block (A0)
    CCM uses the Ax blocks to generate the key stream that is used to encrypt the MIC and the portion of the message to be encrypted. Counter i is initialized to zero to form block A0 and incremented for generating successive blocks. Block A0 is always used to encrypt or decrypt the MIC. Additional Ax blocks are generated as needed for encryption or decryption of the payload. MIC is generated based on PRF-64 and CCM-MAC function.

Steps to be followed to calculate MIC

  • Form the counter mode blocks as specified the spec. till encryption offset bytes are consumed from the payload.
  • Feed the Key (PTK) ad block B0 to encryption block and result is ex-ored with B1 block. This ex-ored result is again input to encryption.
  • Perform the above counter mode operation till Bn block. After that consider left most 64 bits as MIC tag (T).
  • Perform the encryption operation with Key and A0 key to get key S to encrypt MIC.
  • Finally EX_OR the MIC tag T with left most 64 bits of key S which we are getting from above process. This ex-ored result will be encrypted MIC


The field of cryptography is perpetually changing; new algorithms, new techniques of implementation are constantly being derived. Keeping in view the AES-CCM, gives great insight into an efficient implementation of AES block cipher to satisfy the security requirement of high speed of emerging wireless standard Architecture. The core provides privacy, integrity, authenticity and replay protection of data. Future work includes further resource optimization to achieve lower power and higher throughput.


If you have any suggestion/feedback please email it to
Back To Top