23. AES hardware accelerator (AES)

23.1 Introduction

The AES hardware accelerator (AES) encrypts or decrypts data, using an algorithm and implementation fully compliant with the advanced encryption standard (AES) defined in Federal information processing standards (FIPS) publication 197.

The peripheral supports CTR, GCM, GMAC, CCM, ECB, and CBC chaining modes for key sizes of 128 or 256 bits.

AES is an AMBA AHB slave peripheral accessible through 32-bit single accesses only. Other access types generate an AHB error, and other than 32-bit writes may corrupt the register content.

The peripheral supports DMA single transfers for incoming and outgoing data (two DMA channels required).

23.2 AES main features

23.3 AES implementation

The devices have one AES peripheral.

23.4 AES functional description

23.4.1 AES block diagram

Figure 101 shows the block diagram of AES.

Figure 101. AES block diagram

Figure 101. AES block diagram. The diagram shows the internal architecture of the AES peripheral. On the left, a 32-bit AHB bus connects to an AHB interface. The AHB interface is connected to a set of 'Banked registers' (AES_KEYRx, AES_IVRx, AES_SR, AES_CR, AES_DINR, AES_DOUTR, AES_SUSPRx) via 32-bit access lines (key, IV, counter, status, control). The registers are connected to the 'AES Core (AEA)' via signals KEY, IVI, DIN, DOUT, and Save / Restore. A 'swap' block is shown between the registers and the core. Below the registers is 'Control Logic', which is connected to the AHB interface and the core. To the left of the control logic are 'DMA interface' (connected to aes_in_dma and aes_out_dma) and 'IRQ interface' (connected to aes_it). The 'aes_hclk' signal is shown as an input to the AHB interface. The diagram is labeled MSv42154V1.
Figure 101. AES block diagram. The diagram shows the internal architecture of the AES peripheral. On the left, a 32-bit AHB bus connects to an AHB interface. The AHB interface is connected to a set of 'Banked registers' (AES_KEYRx, AES_IVRx, AES_SR, AES_CR, AES_DINR, AES_DOUTR, AES_SUSPRx) via 32-bit access lines (key, IV, counter, status, control). The registers are connected to the 'AES Core (AEA)' via signals KEY, IVI, DIN, DOUT, and Save / Restore. A 'swap' block is shown between the registers and the core. Below the registers is 'Control Logic', which is connected to the AHB interface and the core. To the left of the control logic are 'DMA interface' (connected to aes_in_dma and aes_out_dma) and 'IRQ interface' (connected to aes_it). The 'aes_hclk' signal is shown as an input to the AHB interface. The diagram is labeled MSv42154V1.

23.4.2 AES internal signals

Table 134 describes the user relevant internal signals interfacing the AES peripheral.

Table 134. AES internal input/output signals

Signal nameSignal typeDescription
aes_hclkInputAHB bus clock
aes_itOutputAES interrupt request
aes_in_dmaInput/OutputInput DMA single request/acknowledge
aes_out_dmaInput/OutputOutput DMA single request/acknowledge

23.4.3 AES cryptographic core

Overview

The AES cryptographic core consists of the following components:

The AES core works on 128-bit data blocks (four words) with 128-bit or 256-bit key length. Depending on the chaining mode, the AES requires zero or one 128-bit initialization vector IV.

The AES features the following modes of operation:

Note: Mode 2 is only used when performing ECB and CBC decryption.

The operating mode is selected by programming the MODE[1:0] bitfield of the AES_CR register. It may be done only when the AES peripheral is disabled.

Typical data processing

Typical usage of the AES is described in Section 23.4.4: AES procedure to perform a cipher operation on page 642 .

Note: The outputs of the intermediate AEA stages are never revealed outside the cryptographic boundary, with the exclusion of the IVI bitfield.

Chaining modes

The following chaining modes are supported by AES, selected through the CHMOD[2:0] bitfield of the AES_CR register:

Note: The chaining mode may be changed only when AES is disabled (bit EN of the AES_CR register cleared).

Principle of each AES chaining mode is provided in the following subsections.

Detailed information is in dedicated sections, starting from Section 23.4.8: AES basic chaining modes (ECB, CBC) .

Electronic codebook (ECB) mode

Figure 102. ECB encryption and decryption principle

Diagram illustrating ECB encryption and decryption with three blocks. Encryption shows Plaintext blocks 1-3 entering Encrypt blocks with a key to produce Ciphertext blocks 1-3. Decryption shows Ciphertext blocks 1-3 entering Decrypt blocks with a key to produce Plaintext blocks 1-3. A legend defines input, output, and key scheduling symbols.

The diagram illustrates the ECB encryption and decryption process across three parallel blocks. In the Encryption section, three 'Plaintext block' boxes (1, 2, and 3) are at the top. Each has a downward arrow to an 'Encrypt' box. Each 'Encrypt' box also receives a 'key' input from the left. The output of each 'Encrypt' box is a 'Ciphertext block' (1, 2, and 3) at the bottom. In the Decryption section, three 'Ciphertext block' boxes (1, 2, and 3) are at the bottom. Each has an upward arrow to a 'Decrypt' box. Each 'Decrypt' box also receives a 'key' input from the left. The output of each 'Decrypt' box is a 'Plaintext block' (1, 2, and 3) at the top. A 'Legend' on the left shows a light gray box for 'input', a dark gray box for 'output', and a circular arrow icon for 'key scheduling'.

Diagram illustrating ECB encryption and decryption with three blocks. Encryption shows Plaintext blocks 1-3 entering Encrypt blocks with a key to produce Ciphertext blocks 1-3. Decryption shows Ciphertext blocks 1-3 entering Decrypt blocks with a key to produce Plaintext blocks 1-3. A legend defines input, output, and key scheduling symbols.

ECB is the simplest mode of operation. There are no chaining operations, and no special initialization stage. The message is divided into blocks and each block is encrypted or decrypted separately.

Note: For decryption, a special key scheduling is required before processing the first block.

Cipher block chaining (CBC) mode Figure 103. CBC encryption and decryption principle Diagram illustrating the CBC encryption and decryption process. The diagram is divided into two sections: Encryption and Decryption. In the Encryption section, three plaintext blocks (Plaintext block 1, 2, and 3) are shown. Each block is XORed with an initialization vector (for the first block) or the previous ciphertext block (for subsequent blocks) before being processed by an 'Encrypt' block. The output of each 'Encrypt' block is a ciphertext block. In the Decryption section, the same three ciphertext blocks are shown. Each block is processed by a 'Decrypt' block, and the output is XORed with the previous ciphertext block (or the initialization vector for the first block) to produce the plaintext block. A legend indicates that white boxes represent input, grey boxes represent output, and a circular arrow represents key scheduling.

Encryption

Plaintext block 1, Plaintext block 2, Plaintext block 3

initialization vector

key

Encrypt

Ciphertext block 1, Ciphertext block 2, Ciphertext block 3

Decryption

Plaintext block 1, Plaintext block 2, Plaintext block 3

initialization vector

key

Decrypt

Ciphertext block 1, Ciphertext block 2, Ciphertext block 3

Legend

MSv42141V1

Diagram illustrating the CBC encryption and decryption process. The diagram is divided into two sections: Encryption and Decryption. In the Encryption section, three plaintext blocks (Plaintext block 1, 2, and 3) are shown. Each block is XORed with an initialization vector (for the first block) or the previous ciphertext block (for subsequent blocks) before being processed by an 'Encrypt' block. The output of each 'Encrypt' block is a ciphertext block. In the Decryption section, the same three ciphertext blocks are shown. Each block is processed by a 'Decrypt' block, and the output is XORed with the previous ciphertext block (or the initialization vector for the first block) to produce the plaintext block. A legend indicates that white boxes represent input, grey boxes represent output, and a circular arrow represents key scheduling.

In CBC mode the output of each block chains with the input of the following block. To make each message unique, an initialization vector is used during the first block processing.

Note: For decryption, a special key scheduling is required before processing the first block.

Counter (CTR) mode

Figure 104. CTR encryption and decryption principle

Diagram illustrating the CTR encryption and decryption principle. The diagram is divided into two horizontal sections: 'Encryption' and 'Decryption'. In the 'Encryption' section, a sequence of three 'Counter' blocks is shown. Each counter block has an input 'value' (starting from an initial value, then 'value + 1', then 'value + 2') and an output 'key'. Each 'key' is input to an 'Encrypt' block. The output of each 'Encrypt' block is XORed (indicated by a circle with a cross) with a corresponding 'Plaintext block' (Plaintext block 1, 2, and 3) to produce a 'Ciphertext block' (Ciphertext block 1, 2, and 3). In the 'Decryption' section, the same sequence of three 'Counter' blocks and 'key' outputs is shown. Each 'key' is input to a 'Decrypt' block. The output of each 'Decrypt' block is XORed with a corresponding 'Ciphertext block' (Ciphertext block 1, 2, and 3) to produce a 'Plaintext block' (Plaintext block 1, 2, and 3). A 'Legend' on the left indicates that white boxes represent 'input', grey boxes represent 'output', and the circle with a cross represents 'XOR'. The diagram is labeled 'MSv42142V1' in the bottom right corner.

Encryption

Counter → (+1) → Counter → (+1) → Counter

value      value + 1      value + 2

key → Encrypt      key → Encrypt      key → Encrypt

Plaintext block 1 → ⊕ → Plaintext block 2 → ⊕ → Plaintext block 3

Ciphertext block 1      Ciphertext block 2      Ciphertext block 3

Decryption

Counter → (+1) → Counter → (+1) → Counter

value      value + 1      value + 2

key → Decrypt      key → Decrypt      key → Decrypt

Plaintext block 1 ← ⊕ ← Plaintext block 2 ← ⊕ ← Plaintext block 3

Ciphertext block 1      Ciphertext block 2      Ciphertext block 3

Legend

input

output

⊕ XOR

MSv42142V1

Diagram illustrating the CTR encryption and decryption principle. The diagram is divided into two horizontal sections: 'Encryption' and 'Decryption'. In the 'Encryption' section, a sequence of three 'Counter' blocks is shown. Each counter block has an input 'value' (starting from an initial value, then 'value + 1', then 'value + 2') and an output 'key'. Each 'key' is input to an 'Encrypt' block. The output of each 'Encrypt' block is XORed (indicated by a circle with a cross) with a corresponding 'Plaintext block' (Plaintext block 1, 2, and 3) to produce a 'Ciphertext block' (Ciphertext block 1, 2, and 3). In the 'Decryption' section, the same sequence of three 'Counter' blocks and 'key' outputs is shown. Each 'key' is input to a 'Decrypt' block. The output of each 'Decrypt' block is XORed with a corresponding 'Ciphertext block' (Ciphertext block 1, 2, and 3) to produce a 'Plaintext block' (Plaintext block 1, 2, and 3). A 'Legend' on the left indicates that white boxes represent 'input', grey boxes represent 'output', and the circle with a cross represents 'XOR'. The diagram is labeled 'MSv42142V1' in the bottom right corner.

The CTR mode uses the AES core to generate a key stream. The keys are then XOR-ed with the plaintext to obtain the ciphertext as specified in NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation .

Note: Unlike with ECB and CBC modes, no key scheduling is required for the CTR decryption, since in this chaining scheme the AES core is always used in encryption mode for producing the key stream, or counter blocks.

Galois/counter mode (GCM)

Figure 105. GCM encryption and authentication principle

Diagram of GCM encryption and authentication principle showing the flow from Initialization vector and key through Init, Counter, Encrypt, XOR, and GF2mul blocks to produce ciphertext and a TAG.

The diagram illustrates the GCM encryption and authentication process. It starts with an Initialization vector and a key input to an Init (Encrypt) block, which outputs an H value. Simultaneously, the Initialization vector is passed to a Counter block. The key is also input to a series of Encrypt blocks. The Counter blocks are chained: the first outputs value , the second outputs value + 1 , and the third outputs value + 2 . Each Encrypt block takes the key and a counter value to produce an output. This output is XORed ( \( \oplus \) ) with a Plaintext block (1, 2, or 3) to produce a Ciphertext block . Each Ciphertext block is then input to a GF2mul block. The H value from the Init block is also input to the first GF2mul block. The outputs of the GF2mul blocks are chained: the output of one is XORed ( \( \oplus \) ) with the next Ciphertext block before being input to the next GF2mul block. The final output of the last GF2mul block is input to a Final block, which produces the TAG . A legend indicates that light gray boxes are input , dark gray boxes are output , and \( \oplus \) represents XOR . The identifier MSv42143V1 is shown in the bottom right.

Diagram of GCM encryption and authentication principle showing the flow from Initialization vector and key through Init, Counter, Encrypt, XOR, and GF2mul blocks to produce ciphertext and a TAG.

In Galois/counter mode (GCM), the plaintext message is encrypted while a message authentication code (MAC) is computed in parallel, thus generating the corresponding ciphertext and its MAC (also known as authentication tag). It is defined in NIST Special Publication 800-38D, Recommendation for Block Cipher Modes of Operation - Galois/Counter Mode (GCM) and GMAC .

GCM mode is based on AES in counter mode for confidentiality. It uses a multiplier over a fixed finite field for computing the message authentication code. It requires an initial value and a particular 128-bit block at the end of the message.

Galois message authentication code (GMAC) principle

Figure 106. GMAC authentication principle

Diagram of GMAC authentication principle showing the flow from Initialization vector and key through Init, H, GF2mul, XOR, and Final blocks to produce a TAG.

The diagram illustrates the GMAC authentication process. It starts with an Initialization vector and a key input to an Init (Encrypt) block, which outputs an H value. The Initialization vector is also input to the first GF2mul block along with the H value. The key is input to a series of GF2mul blocks. The GF2mul blocks are chained: the output of one is XORed ( \( \oplus \) ) with a Plaintext block (1, 2, or 3) before being input to the next GF2mul block. The final output of the last GF2mul block is input to a Final block, which produces the TAG . A legend indicates that light gray boxes are input , dark gray boxes are output , and \( \oplus \) represents XOR . The identifier MSv42144V1 is shown in the bottom right.

Diagram of GMAC authentication principle showing the flow from Initialization vector and key through Init, H, GF2mul, XOR, and Final blocks to produce a TAG.

Galois message authentication code (GMAC) allows authenticating a message and generating the corresponding message authentication code (MAC). It is defined in NIST Special Publication 800-38D, Recommendation for Block Cipher Modes of Operation - Galois/Counter Mode (GCM) and GMAC .

GMAC is similar to GCM, except that it is applied on a message composed only by plaintext authenticated data (that is, only header, no payload).

Counter with CBC-MAC (CCM) principle

Figure 107. CCM encryption and authentication principle

Diagram illustrating the CCM encryption and authentication principle. The process starts with B0, which is input to an 'Init (Encrypt)' block along with a 'key'. This produces an 'Initialization vector'. Simultaneously, B0 is passed through a counter sequence: B0 -> Count 1 -> (+1) -> Count 2 -> (+1) -> Count 3. Each counter value is input to an 'Encrypt' block with a 'key'. The output of the 'Init (Encrypt)' block is XORed with 'Plaintext block 1' to produce 'Ciphertext block 1'. 'Ciphertext block 1' is then input to an 'Encrypt' block with a 'key', and its output is XORed with 'Plaintext block 2' to produce 'Ciphertext block 2'. 'Ciphertext block 2' is input to another 'Encrypt' block with a 'key', and its output is XORed with 'Plaintext block 3' to produce 'Ciphertext block 3'. Finally, the output of the last 'Encrypt' block is passed to a 'Final' block, which produces the 'TAG'.
Diagram illustrating the CCM encryption and authentication principle. The process starts with B0, which is input to an 'Init (Encrypt)' block along with a 'key'. This produces an 'Initialization vector'. Simultaneously, B0 is passed through a counter sequence: B0 -> Count 1 -> (+1) -> Count 2 -> (+1) -> Count 3. Each counter value is input to an 'Encrypt' block with a 'key'. The output of the 'Init (Encrypt)' block is XORed with 'Plaintext block 1' to produce 'Ciphertext block 1'. 'Ciphertext block 1' is then input to an 'Encrypt' block with a 'key', and its output is XORed with 'Plaintext block 2' to produce 'Ciphertext block 2'. 'Ciphertext block 2' is input to another 'Encrypt' block with a 'key', and its output is XORed with 'Plaintext block 3' to produce 'Ciphertext block 3'. Finally, the output of the last 'Encrypt' block is passed to a 'Final' block, which produces the 'TAG'.

In Counter with cipher block chaining-message authentication code (CCM) mode, the plaintext message is encrypted while a message authentication code (MAC) is computed in parallel, thus generating the corresponding ciphertext and the corresponding MAC (also known as tag). It is described by NIST in Special Publication 800-38C, Recommendation for Block Cipher Modes of Operation - The CCM Mode for Authentication and Confidentiality .

CCM mode is based on AES in counter mode for confidentiality and it uses CBC for computing the message authentication code. It requires an initial value.

Like GCM, the CCM chaining mode can be applied on a message composed only by plaintext authenticated data (that is, only header, no payload). Note that this way of using CCM is not called CMAC (it is not similar to GCM/GMAC), and its use is not recommended by NIST.

23.4.4 AES procedure to perform a cipher operation

Introduction

A typical cipher operation is explained below. Detailed information is provided in sections starting from Section 23.4.8: AES basic chaining modes (ECB, CBC) .

Initialization of AES

To initialize AES, first disable it by clearing the EN bit of the AES_CR register. Then perform the following steps in any order:

Data append

This section describes different ways of appending data for processing, where the size of data to process is not a multiple of 128 bits.

For ECB or CBC mode, refer to Section 23.4.6: AES ciphertext stealing and data padding . The last block management in these cases is more complex than in the sequence described in this section.

Data append through polling

This method uses flag polling to control the data append through the following sequence:

  1. 1. Enable the AES peripheral by setting the EN bit of the AES_CR register.
  2. 2. Repeat the following sub-sequence until the payload is entirely processed:
    1. a) Write four input data words into the AES_DINR register.
    2. b) Wait until the status flag CCF is set in the AES_SR, then read the four data words from the AES_DOUTR register.
    3. c) Clear the CCF flag, by setting the CCFC bit of the AES_CR register.
    4. d) If the data block just processed is the second-last block of the message and the significant data in the last block to process is inferior to 128 bits, pad the remainder of the last block with zeros and, in case of GCM payload encryption or CCM payload decryption, specify the number of non-valid bytes, using the NPBLB bitfield of the AES_CR register, for AES to compute a correct tag;.
  3. 3. As it is the last block, discard the data that is not part of the data, then disable the AES peripheral by clearing the EN bit of the AES_CR register.

Note: Up to three wait cycles are automatically inserted between two consecutive writes to the AES_DINR register, to allow sending the key to the AES processor.

NPBLB bits are not used in header phase of GCM, GMAC and CCM chaining modes.

Data append using interrupt

The method uses interrupt from the AES peripheral to control the data append, through the following sequence:

  1. 1. Enable interrupts from AES by setting the CCFIE bit of the AES_CR register.
  2. 2. Enable the AES peripheral by setting the EN bit of the AES_CR register.
  3. 3. Write first four input data words into the AES_DINR register.
  4. 4. Handle the data in the AES interrupt service routine, upon interrupt:
    1. a) Read four output data words from the AES_DOUTR register.
    2. b) Clear the CCF flag and thus the pending interrupt, by setting the CCFC bit of the AES_CR register.
    3. c) If the data block just processed is the second-last block of an message and the significant data in the last block to process is inferior to 128 bits, pad the remainder of the last block with zeros and, in case of GCM payload encryption or CCM payload decryption, specify the number of non-valid bytes, using the NPBLB bitfield of the AES_CR register, for AES to compute a correct tag;. Then proceed with point 4e).
    4. d) If the data block just processed is the last block of the message, discard the data that is not part of the data, then disable the AES peripheral by clearing the EN bit of the AES_CR register and quit the interrupt service routine.
    5. e) Write next four input data words into the AES_DINR register and quit the interrupt service routine.

Note: AES is tolerant of delays between consecutive read or write operations, which allows, for example, an interrupt from another peripheral to be served between two AES computations. NPBLB bits are not used in header phase of GCM, GMAC and CCM chaining modes.

Data append using DMA

With this method, all the transfers and processing are managed by DMA and AES. To use the method, proceed as follows:

  1. 1. Prepare the last four-word data block (if the data to process does not fill it completely), by padding the remainder of the block with zeros.
  2. 2. Configure the DMA controller so as to transfer the data to process from the memory to the AES peripheral input and the processed data from the AES peripheral output to the memory, as described in Section 23.4.16: AES DMA interface . Configure the DMA controller so as to generate an interrupt on transfer completion. In case of GCM payload encryption or CCM payload decryption, DMA transfer must not include the last four-word block if padded with zeros. The sequence described in Data append through polling must be used instead for this last block, because NPBLB bits must be setup before processing the block, for AES to compute a correct tag.
  3. 3. Enable the AES peripheral by setting the EN bit of the AES_CR register
  4. 4. Enable DMA requests by setting the MAINEN and DMAOUTEN bits of the AES_CR register.
  5. 5. Upon DMA interrupt indicating the transfer completion, get the AES-processed data from the memory.

Note: The CCF flag has no use with this method, because the reading of the AES_DOUTR register is managed by DMA automatically, without any software action, at the end of the computation phase. NPBLB bits are not used in header phase of GCM, GMAC, and CCM chaining modes.

23.4.5 AES decryption round key preparation

Internal key schedule is used to generate AES round keys. In AES encryption, the round 0 key is the one stored in the key registers. AES decryption must start using the last round key. As the encryption key is stored in memory, a special key scheduling must be performed to obtain the decryption key. This key scheduling is only required for AES decryption in ECB and CBC modes.

Recommended method is to select the Mode 2 by setting to 01 the MODE[1:0] bitfield of the AES_CR (key process only), then proceed with the decryption by setting MODE[1:0] to 10 (Mode 3, decryption only). Mode 2 usage is described below:

  1. 1. Disable the AES peripheral by clearing the EN bit of the AES_CR register.
  2. 2. Select Mode 2 by setting to 01 the MODE[1:0] bitfield of the AES_CR. The CHMOD[2:0] bitfield is not significant in this case because this key derivation mode is independent of the chaining algorithm selected.
  3. 3. Set key length to 128 or 256 bits, via KEYSIZE bit of AES_CR register.
  4. 4. Write the AES_KEYRx registers (128 or 256 bits) with encryption key. Writes to the AES_IVRx registers have no effect.
  5. 5. Enable the AES peripheral, by setting the EN bit of the AES_CR register.
  6. 6. Wait until the CCF flag is set in the AES_SR register.
  7. 7. Clear the CCF flag. Derived key is available in AES core, ready to use for decryption.

Note: The AES is disabled by hardware when the derivation key is available.

To restart a derivation key computation, repeat steps 4, 5, 6, and 7.

Note: The operation of the key preparation lasts 59 or 82 clock cycles, depending on the key size (128- or 256-bit).

23.4.6 AES ciphertext stealing and data padding

When using AES in ECB or CBC modes to manage messages the size of which is not a multiple of the block size (128 bits), ciphertext stealing techniques are used, such as those described in NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation: Three Variants of Ciphertext Stealing for CBC Mode . Since the AES peripheral does not support such techniques, the application must complete the last block of input data using data from the second last block.

Note: Ciphertext stealing techniques are not documented in this reference manual.

Similarly, when AES is used in other modes than ECB or CBC, an incomplete input data block (that is, block with input data shorter than 128 bits) must be padded with zeros prior to encryption (that is, extra bits must be appended to the trailing end of the data string). After decryption, the extra bits must be discarded. As AES does not implement automatic data padding operation to the last block , the application must follow the recommendation given in Section 23.4.4: AES procedure to perform a cipher operation on page 642 to manage messages the size of which is not a multiple of 128 bits.

Note: Padding data are swapped in a similar way as normal data, according to the DATATYPE[1:0] field of the AES_CR register (see Section 23.4.13: AES data registers and data swapping for details).

23.4.7 AES task suspend and resume

A message can be suspended if another message with a higher priority must be processed. When this highest priority message is sent, the suspended message can resume in both encryption or decryption mode.

Suspend/resume operations do not break the chaining operation and the message processing can resume as soon as AES is enabled again to receive the next data block.

Figure 108 gives an example of suspend/resume operation: Message 1 is suspended in order to send a shorter and higher-priority Message 2.

Figure 108. Example of suspend mode management

Diagram illustrating the suspend and resume of Message 1 to process Message 2. Message 1 consists of blocks 1-6. Message 2 consists of blocks 1-2. The diagram shows Message 1 being suspended after block 3, Message 2 being processed, and then Message 1 resuming with block 4.

The diagram illustrates the flow of data blocks for two messages. Message 1 is shown as a vertical sequence of six 128-bit blocks. A callout bubble indicates that a 'New higher-priority message 2 to be processed' interrupts Message 1. An arrow points from the end of Message 1's third block to an 'AES suspend sequence' box. From this box, an arrow points to the start of Message 2's first block. Message 2 consists of two 128-bit blocks. After Message 2's second block, an arrow points to an 'AES resume sequence' box. From this box, an arrow points back to the fourth block of Message 1. Message 1 then continues with its remaining blocks (4, 5, 6, and ellipsis). A small code 'MSv42148V1' is visible in the bottom right corner of the diagram area.

Diagram illustrating the suspend and resume of Message 1 to process Message 2. Message 1 consists of blocks 1-6. Message 2 consists of blocks 1-2. The diagram shows Message 1 being suspended after block 3, Message 2 being processed, and then Message 1 resuming with block 4.

A detailed description of suspend/resume operations is in the sections dedicated to each AES mode.

23.4.8 AES basic chaining modes (ECB, CBC)

Overview

This section gives a brief explanation of the four basic operation modes provided by the AES core: ECB encryption, ECB decryption, CBC encryption and CBC decryption. For detailed information, refer to the FIPS publication 197 from November 26, 2001.

Figure 109 illustrates the electronic codebook (ECB) encryption.

Diagram of ECB encryption showing two blocks, Block 1 and Block 2. Each block consists of an input register (AES_DINR), a swap management block, an encryption core, another swap management block, and an output register (AES_DOUTR). The process for Block 1: AES_DINR (plaintext P1) is swapped to produce I1, which is encrypted with AES_KEYRx (KEY) to produce O1, which is then swapped to produce AES_DOUTR (ciphertext C1). The same process is repeated for Block 2 with P2, I2, O2, and C2. A legend indicates that white boxes are inputs and grey boxes are outputs. The diagram is labeled MSv19105V2.

Figure 109. ECB encryption

MSv19105V2

Diagram of ECB encryption showing two blocks, Block 1 and Block 2. Each block consists of an input register (AES_DINR), a swap management block, an encryption core, another swap management block, and an output register (AES_DOUTR). The process for Block 1: AES_DINR (plaintext P1) is swapped to produce I1, which is encrypted with AES_KEYRx (KEY) to produce O1, which is then swapped to produce AES_DOUTR (ciphertext C1). The same process is repeated for Block 2 with P2, I2, O2, and C2. A legend indicates that white boxes are inputs and grey boxes are outputs. The diagram is labeled MSv19105V2.

In ECB encrypt mode, the 128-bit plaintext input data block P x in the AES_DINR register first goes through bit/byte/half-word swapping. The swap result I x is processed with the AES core set in encrypt mode, using a 128- or 256-bit key. The encryption result O x goes through bit/byte/half-word swapping, then is stored in the AES_DOUTR register as 128-bit ciphertext output data block C x . The ECB encryption continues in this way until the last complete plaintext block is encrypted.

Figure 110 illustrates the electronic codebook (ECB) decryption.

Diagram of ECB decryption showing two blocks, Block 1 and Block 2. Each block consists of an input register (AES_DINR), a swap management block, a decryption core, another swap management block, and an output register (AES_DOUTR). The process for Block 1: AES_DINR (ciphertext C1) is swapped to produce I1, which is decrypted with AES_KEYRx (KEY) to produce O1, which is then swapped to produce AES_DOUTR (plaintext P1). The same process is repeated for Block 2 with C2, I2, O2, and P2. A legend indicates that white boxes are inputs and grey boxes are outputs. The diagram is labeled MSv19106V2.

Figure 110. ECB decryption

MSv19106V2

Diagram of ECB decryption showing two blocks, Block 1 and Block 2. Each block consists of an input register (AES_DINR), a swap management block, a decryption core, another swap management block, and an output register (AES_DOUTR). The process for Block 1: AES_DINR (ciphertext C1) is swapped to produce I1, which is decrypted with AES_KEYRx (KEY) to produce O1, which is then swapped to produce AES_DOUTR (plaintext P1). The same process is repeated for Block 2 with C2, I2, O2, and P2. A legend indicates that white boxes are inputs and grey boxes are outputs. The diagram is labeled MSv19106V2.

To perform an AES decryption in the ECB mode, the secret key has to be prepared by collecting the last-round encryption key (which requires to first execute the complete key schedule for encryption), and using it as the first-round key for the decryption of the ciphertext. This preparation is supported by the AES core.

In ECB decrypt mode, the 128-bit ciphertext input data block C 1 in the AES_DINR register first goes through bit/byte/half-word swapping. The keying sequence is reversed compared to that of the ECB encryption. The swap result I 1 is processed with the AES core set in decrypt mode, using the formerly prepared decryption key. The decryption result goes through bit/byte/half-word swapping, then is stored in the AES_DOUTR register as 128-bit plaintext output data block P 1 . The ECB decryption continues in this way until the last complete ciphertext block is decrypted.

Figure 111 illustrates the cipher block chaining (CBC) encryption.

Diagram of CBC encryption showing two blocks, Block 1 and Block 2. Block 1 takes plaintext P1, swaps it to P1', XORs it with IVI, encrypts it with KEY to produce O1, swaps O1 to produce ciphertext C1. Block 2 takes plaintext P2, swaps it to P2', XORs it with O1 to produce I2, encrypts it with KEY to produce O2, swaps O2 to produce ciphertext C2. A legend indicates input, output, and XOR symbols.

Figure 111. CBC encryption

The diagram illustrates the CBC encryption process for two blocks. Block 1 : AES_DINR (plaintext P1) is processed through a Swap management block to produce P1'. P1' is XOR-ed with the IVI (from AES_IVRx) to produce I1. I1 is then processed by the Block cipher encryption block using the KEY (from AES_KEYRx) to produce O1. O1 is processed through another Swap management block to produce AES_DOUTr (ciphertext C1). Block 2 : AES_DINR (plaintext P2) is processed through a Swap management block to produce P2'. P2' is XOR-ed with O1 to produce I2. I2 is then processed by the Block cipher encryption block using the KEY to produce O2. O2 is processed through another Swap management block to produce AES_DOUTr (ciphertext C2). A legend indicates that light gray boxes represent input, dark gray boxes represent output, and the circle with a cross symbol represents XOR. The diagram is labeled MSv19107V2.

Diagram of CBC encryption showing two blocks, Block 1 and Block 2. Block 1 takes plaintext P1, swaps it to P1', XORs it with IVI, encrypts it with KEY to produce O1, swaps O1 to produce ciphertext C1. Block 2 takes plaintext P2, swaps it to P2', XORs it with O1 to produce I2, encrypts it with KEY to produce O2, swaps O2 to produce ciphertext C2. A legend indicates input, output, and XOR symbols.

In CBC encrypt mode, the first plaintext input block, after bit/byte/half-word swapping (P1'), is XOR-ed with a 128-bit IVI bitfield (initialization vector and counter), producing the I1 input data for encrypt with the AES core, using a 128- or 256-bit key. The resulting 128-bit output block O1, after swapping operation, is used as ciphertext C1. The O1 data is then XOR-ed with the second-block plaintext data P2' to produce the I2 input data for the AES core to produce the second block of ciphertext data. The chaining of data blocks continues in this way until the last plaintext block in the message is encrypted.

If the message size is not a multiple of 128 bits, the final partial data block is encrypted in the way explained in Section 23.4.6: AES ciphertext stealing and data padding .

Figure 112 illustrates the cipher block chaining (CBC) decryption.

Diagram of CBC decryption showing two blocks, Block 1 and Block 2. Block 1 takes ciphertext C1, swaps it to I1, decrypts it with KEY to produce O1, XORs O1 with IVI to produce P1', swaps P1' to produce plaintext P1. Block 2 takes ciphertext C2, swaps it to I2, decrypts it with KEY to produce O2, XORs O2 with O1 to produce P2', swaps P2' to produce plaintext P2. A legend indicates input, output, and XOR symbols.

Figure 112. CBC decryption

The diagram illustrates the CBC decryption process for two blocks. Block 1 : AES_DINR (ciphertext C1) is processed through a Swap management block to produce I1. I1 is then processed by the Decrypt block using the KEY (from AES_KEYRx) to produce O1. O1 is XOR-ed with the IVI (from AES_IVRx) to produce P1'. P1' is processed through another Swap management block to produce AES_DOUTr (plaintext P1). Block 2 : AES_DINR (ciphertext C2) is processed through a Swap management block to produce I2. I2 is then processed by the Decrypt block using the KEY to produce O2. O2 is XOR-ed with O1 to produce P2'. P2' is processed through another Swap management block to produce AES_DOUTr (plaintext P2). A legend indicates that light gray boxes represent input, dark gray boxes represent output, and the circle with a cross symbol represents XOR. The diagram is labeled MSv19104V2.

Diagram of CBC decryption showing two blocks, Block 1 and Block 2. Block 1 takes ciphertext C1, swaps it to I1, decrypts it with KEY to produce O1, XORs O1 with IVI to produce P1', swaps P1' to produce plaintext P1. Block 2 takes ciphertext C2, swaps it to I2, decrypts it with KEY to produce O2, XORs O2 with O1 to produce P2', swaps P2' to produce plaintext P2. A legend indicates input, output, and XOR symbols.

In CBC decrypt mode, like in ECB decrypt mode, the secret key must be prepared to perform an AES decryption.

After the key preparation process, the decryption goes as follows: the first 128-bit ciphertext block (after the swap operation) is used directly as the AES core input block I1 for decrypt operation, using the 128-bit or 256-bit key. Its output O1 is XOR-ed with the 128-bit IVI field (that must be identical to that used during encryption) to produce the first plaintext block P1.

The second ciphertext block is processed in the same way as the first block, except that the I1 data from the first block is used in place of the initialization vector.

The decryption continues in this way until the last complete ciphertext block is decrypted.

If the message size is not a multiple of 128 bits, the final partial data block is decrypted in the way explained in Section 23.4.6: AES ciphertext stealing and data padding .

For more information on data swapping, refer to Section 23.4.13: AES data registers and data swapping .

ECB/CBC encryption sequence

The sequence of events to perform an ECB/CBC encryption (more detail in Section 23.4.4 ):

  1. 1. Disable the AES peripheral by clearing the EN bit of the AES_CR register.
  2. 2. Select the Mode 1 by setting to 00 the MODE[1:0] bitfield of the AES_CR register and select ECB or CBC chaining mode by setting the CHMOD[2:0] bitfield of the AES_CR register to 000 or 001, respectively. Data type can also be defined, using DATATYPE[1:0] bitfield.
  3. 3. Select 128- or 256-bit key length through the KEYSIZE bit of the AES_CR register.
  4. 4. Write the AES_KEYRx registers (128 or 256 bits) with encryption key. Fill the AES_IVRx registers with the initialization vector data if CBC mode has been selected.
  5. 5. Enable the AES peripheral by setting the EN bit of the AES_CR register.
  6. 6. Write the AES_DINR register four times to input the plaintext (MSB first), as shown in Figure 113 .
  7. 7. Wait until the CCF flag is set in the AES_SR register.
  8. 8. Read the AES_DOUTR register four times to get the ciphertext (MSB first) as shown in Figure 113 . Then clear the CCF flag by setting the CCFC bit of the AES_CR register.
  9. 9. Repeat steps 6-7-8 to process all the blocks with the same encryption key.

Figure 113. ECB/CBC encryption (Mode 1)

Diagram of ECB/CBC encryption sequence showing input, computation, and output phases.

The diagram illustrates the ECB/CBC encryption sequence (Mode 1) across three phases:

Legend:
PT = plaintext = 4 words (PT3, ... , PT0)
CT = ciphertext = 4 words (CT3, ... , CT0)

MS18936V3

Diagram of ECB/CBC encryption sequence showing input, computation, and output phases.

ECB/CBC decryption sequence

The sequence of events to perform an AES ECB/CBC decryption is as follows (More detail in Section 23.4.4 ).

  1. 1. Follow the steps described in Section 23.4.5: AES decryption round key preparation , in order to prepare the decryption key in AES core.
  2. 2. Select the Mode 3 by setting to 10 the MODE[1:0] bitfield of the AES_CR register and select ECB or CBC chaining mode by setting the CHMOD[2:0] bitfield of the AES_CR
  1. register to 000 or 001, respectively. Data type can also be defined, using DATATYPE[1:0] bitfield. KEYSIZE bitfield must be kept as-is.
    1. 3. Write the AES_IVRx registers with the initialization vector (required in CBC mode only).
    2. 4. Enable AES by setting the EN bit of the AES_CR register.
    3. 5. Write the AES_DINR register four times to input the cipher text (MSB first), as shown in Figure 114.
    4. 6. Wait until the CCF flag is set in the AES_SR register.
    5. 7. Read the AES_DOUTR register four times to get the plain text (MSB first), as shown in Figure 114. Then clear the CCF flag by setting the CCFC bit of the AES_CR register.
    6. 8. Repeat steps 5-6-7 to process all the blocks encrypted with the same key.

Figure 114. ECB/CBC decryption (Mode 3)

Timing diagram for ECB/CBC decryption (Mode 3) showing input, computation, and output phases.

The diagram illustrates the sequence of operations for ECB/CBC decryption (Mode 3). It is divided into three main phases:

Legend:
PT = plaintext = 4 words (PT3, ... , PT0)
CT = ciphertext = 4 words (CT3, ... , CT0)

MS18938V3

Timing diagram for ECB/CBC decryption (Mode 3) showing input, computation, and output phases.

Suspend/resume operations in ECB/CBC modes

To suspend the processing of a message, proceed as follows:

  1. 1. If DMA is used, stop the AES DMA transfers to the IN FIFO by clearing the DMAINEN bit of the AES_CR register.
  2. 2. If DMA is not used, read four times the AES_DOUTR register to save the last processed block. If DMA is used, wait until the CCF flag is set in the AES_SR register then stop the DMA transfers from the OUT FIFO by clearing the DMAOUTEN bit of the AES_CR register.
  3. 3. If DMA is not used, poll the CCF flag of the AES_SR register until it becomes 1 (computation completed).
  4. 4. Clear the CCF flag by setting the CCFC bit of the AES_CR register.
  5. 5. Save initialization vector registers (only required in CBC mode as AES_IVRx registers are altered during the data processing).
  6. 6. Disable the AES peripheral by clearing the bit EN of the AES_CR register.
  7. 7. Save the AES_CR register and clear the key registers if they are not needed, to process the higher priority message.
  8. 8. If DMA is used, save the DMA controller status (pointers for IN and OUT data transfers, number of remaining bytes, and so on).

To resume the processing of a message, proceed as follows:

  1. 1. If DMA is used, configure the DMA controller so as to complete the rest of the FIFO IN and FIFO OUT transfers.
  2. 2. Disable the AES peripheral by clearing the EN bit of the AES_CR register.
  3. 3. Restore AES_CR register (with correct KEYSIZE) then restore AES_KEYRx registers.
  4. 4. Prepare the decryption key as described in Section 23.4.5: AES decryption round key preparation (only required for ECB or CBC decryption).
  5. 5. Restore AES_IVRx registers using the saved configuration (only required in CBC mode).
  6. 6. Enable the AES peripheral by setting the EN bit of the AES_CR register.
  7. 7. If DMA is used, enable AES DMA transfers by setting the DMAINEN and DMAOUTEN bits of the AES_CR register.

23.4.9 AES counter (CTR) mode

Overview

The counter mode (CTR) uses AES as a key-stream generator. The generated keys are then XOR-ed with the plaintext to obtain the ciphertext.

CTR chaining is defined in NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation . A typical message construction in CTR mode is given in Figure 115 .

Figure 115. Message construction in CTR mode

Diagram illustrating message construction in CTR mode. It shows the structure of the Initial Counter Block (ICB) and the resulting Ciphertext (C) and Plaintext (P).

The diagram illustrates the message construction in CTR mode. At the top, a horizontal bar represents the message structure with 16-byte boundaries. It starts with the Initial Counter Block (ICB), followed by the Ciphertext (C), and ends with a block of zero padding (labeled '0'). Below the ICB, a callout shows its internal structure with 4-byte boundaries, divided into the Initialization vector (IV) and the Counter. A vertical arrow labeled 'decrypt' points from the Ciphertext (C) block down to the Plaintext (P) block, indicating the decryption process.

Diagram illustrating message construction in CTR mode. It shows the structure of the Initial Counter Block (ICB) and the resulting Ciphertext (C) and Plaintext (P).

The structure of this message is:

CTR encryption and decryption

Figure 116 and Figure 117 describe the CTR encryption and decryption process, respectively, as implemented in the AES peripheral. The CTR mode is selected by writing 010 to the CHMOD[2:0] bitfield of AES_CR register.

Figure 116. CTR encryption

Diagram of CTR encryption process showing Block 1 and Block 2. Each block uses an AES_IVRx (Nonce + 32-bit counter) as input I to an Encrypt block along with AES_KEYRx (KEY). The Encrypt block produces output O. The input P (AES_DINR) is processed through Swap management (controlled by DATATYPE[1:0]) to become P'. P' is XOR-ed with O to produce C'. C' is then processed through another Swap management block to become the ciphertext C (AES_DOUTR). The counter is incremented (+1) for the next block. Legend: input (white box), output (grey box), XOR (circle with cross).
Diagram of CTR encryption process showing Block 1 and Block 2. Each block uses an AES_IVRx (Nonce + 32-bit counter) as input I to an Encrypt block along with AES_KEYRx (KEY). The Encrypt block produces output O. The input P (AES_DINR) is processed through Swap management (controlled by DATATYPE[1:0]) to become P'. P' is XOR-ed with O to produce C'. C' is then processed through another Swap management block to become the ciphertext C (AES_DOUTR). The counter is incremented (+1) for the next block. Legend: input (white box), output (grey box), XOR (circle with cross).

Figure 117. CTR decryption

Diagram of CTR decryption process showing Block 1 and Block 2. Each block uses an AES_IVRx (Nonce + 32-bit counter) as input I to an Encrypt block along with AES_KEYRx (KEY). The Encrypt block produces output O. The input C (AES_DINR, ciphertext) is processed through Swap management (controlled by DATATYPE[1:0]) to become C'. C' is XOR-ed with O to produce P'. P' is then processed through another Swap management block to become the plaintext P (AES_DOUTR). The counter is incremented (+1) for the next block. Legend: input (white box), output (grey box), XOR (circle with cross).
Diagram of CTR decryption process showing Block 1 and Block 2. Each block uses an AES_IVRx (Nonce + 32-bit counter) as input I to an Encrypt block along with AES_KEYRx (KEY). The Encrypt block produces output O. The input C (AES_DINR, ciphertext) is processed through Swap management (controlled by DATATYPE[1:0]) to become C'. C' is XOR-ed with O to produce P'. P' is then processed through another Swap management block to become the plaintext P (AES_DOUTR). The counter is incremented (+1) for the next block. Legend: input (white box), output (grey box), XOR (circle with cross).

In CTR mode, the cryptographic core output (also called keystream) Ox is XOR-ed with relevant input block (Px' for encryption, Cx' for decryption), to produce the correct output block (Cx' for encryption, Px' for decryption). Initialization vectors in AES must be initialized as shown in Table 135.

Table 135. CTR mode initialization vector definition

AES_IVR3[31:0]AES_IVR2[31:0]AES_IVR1[31:0]AES_IVR0[31:0]
IVI[127:96]IVI[95:64]IVI[63:32]IVI[31:0]
32-bit counter = 0x0001

Unlike in CBC mode that uses the AES_IVRx registers only once when processing the first data block, in CTR mode AES_IVRx registers are used for processing each data block, and the AES peripheral increments the counter bits of the initialization vector (leaving the nonce bits unchanged).

CTR decryption does not differ from CTR encryption, since the core always encrypts the current counter block to produce the key stream that is then XOR-ed with the plaintext (CTR encryption) or ciphertext (CTR decryption) input. In CTR mode, the MODE[1:0] bitfield setting 01 (key derivation) is forbidden and all the other settings default to encryption mode.

The sequence of events to perform an encryption or a decryption in CTR chaining mode:

  1. 1. Disable the AES peripheral by clearing the EN bit of the AES_CR register.
  2. 2. Select CTR chaining mode by setting to 010 the CHMOD[2:0] bitfield of the AES_CR register. Set MODE[1:0] bitfield to any value other than 01.
  3. 3. Initialize the AES_KEYRx registers, and load the AES_IVRx registers as described in Table 135 .
  4. 4. Set the EN bit of the AES_CR register, to start encrypting the current counter (EN is automatically reset when the calculation finishes).
  5. 5. If it is the last block, pad the data with zeros to have a complete block, if needed.
  6. 6. Append data in AES, and read the result. The three possible scenarios are described in Section 23.4.4: AES procedure to perform a cipher operation .
  7. 7. Repeat the previous step till the second-last block is processed. For the last block, apply the two previous steps and discard the bits that are not part of the payload (if the size of the significant data in the last input block is less than 16 bytes).

Suspend/resume operations in CTR mode

Like for the CBC mode, it is possible to interrupt a message to send a higher priority message, and resume the message that was interrupted. Detailed CBC suspend/resume sequence is described in Section 23.4.8: AES basic chaining modes (ECB, CBC) .

Note: Like for CBC mode, the AES_IVRx registers must be reloaded during the resume operation.

23.4.10 AES Galois/counter mode (GCM)

Overview

The AES Galois/counter mode (GCM) allows encrypting and authenticating a plaintext message into the corresponding ciphertext and tag (also known as message authentication code). To ensure confidentiality, GCM algorithm is based on AES counter mode. It uses a multiplier over a fixed finite field to generate the tag.

GCM chaining is defined in NIST Special Publication 800-38D, Recommendation for Block Cipher Modes of Operation - Galois/Counter Mode (GCM) and GMAC . A typical message construction in GCM mode is given in Figure 118 .

Figure 118. Message construction in GCM

Diagram illustrating message construction in GCM. It shows the flow from Initialization vector (IV) and Counter to the Initial Counter Block (ICB), then through Additional Authenticated Data (AAD), Plaintext (P), and Last block to the Authenticated & encrypted ciphertext (C), and finally to the Authentication tag (T).

The diagram illustrates the message construction process in GCM. It shows the following components and flow:

Zero padding / zeroed bits are indicated by grey boxes in the diagram.

Diagram illustrating message construction in GCM. It shows the flow from Initialization vector (IV) and Counter to the Initial Counter Block (ICB), then through Additional Authenticated Data (AAD), Plaintext (P), and Last block to the Authenticated & encrypted ciphertext (C), and finally to the Authentication tag (T).

The message has the following structure:

The GCM standard specifies that ciphertext C has the same bit length as the plaintext P.

When a part of the message (AAD or P) has a length that is a non-multiple of 16-bytes a special padding scheme is required.

Table 136. GCM last block definition

EndiannessBit[0] ----- Bit[31]Bit[32]----- Bit[63]Bit[64] ----- Bit[95]Bit[96] ----- Bit[127]
Input data0x0AAD length[31:0]0x0Payload length[31:0]

GCM processing

Figure 119 describes the GCM implementation in the AES peripheral. The GCM is selected by writing 011 to the CHMOD[2:0] bitfield of the AES_CR register.

Figure 119. GCM authenticated encryption

Figure 119. GCM authenticated encryption diagram showing Init, Header, Payload, and Final stages.

The diagram illustrates the GCM authenticated encryption process, divided into four main stages:

Legend:

Figure 119. GCM authenticated encryption diagram showing Init, Header, Payload, and Final stages.

The mechanism for the confidentiality of the plaintext in GCM mode is similar to that in the Counter mode, with a particular increment function (denoted 32-bit increment) that generates the sequence of input counter blocks.

AES_IVRx registers keeping the counter block of data are used for processing each data block. The AES peripheral automatically increments the Counter[31:0] bitfield. The first counter block ( CB1 ) is derived from the initial counter block ICB by the application software (see Table 137).

Table 137. Initialization of AES_IVRx registers in GCM mode

AES_IVR3[31:0]AES_IVR2[31:0]AES_IVR1[31:0]AES_IVR0[31:0]
ICB[127:96]ICB[95:64]ICB[63:32]ICB[31:0]
32-bit counter = 0x0002

Note: In this mode, the setting 01 of the MODE[1:0] bitfield (key derivation) is forbidden.

The authentication mechanism in GCM mode is based on a hash function called GF2mul that performs multiplication by a fixed parameter, called hash subkey (H), within a binary Galois field.

A GCM message is processed through the following phases, further described in next subsections:

GCM init phase

During this first step, the GCM hash subkey (H) is calculated and saved internally, to be used for processing all the blocks. The recommended sequence is:

  1. 1. Disable the AES peripheral by clearing the EN bit of the AES_CR register.
  2. 2. Select GCM chaining mode, by setting to 011 the CHMOD[2:0] bitfield of the AES_CR register, and optionally, set the DATATYPE[1:0] bitfield.
  3. 3. Indicate the Init phase, by setting to 00 the GCMPH[1:0] bitfield of the AES_CR register.
  4. 4. Set the MODE[1:0] bitfield of the AES_CR register to 00 or 10. Although the bitfield is only used in payload phase, it is recommended to set it in the Init phase and keep it unchanged in all subsequent phases.
  5. 5. Initialize the AES_KEYRx registers with a key, and initialize AES_IVRx registers with the information as defined in Table 137 .
  6. 6. Start the calculation of the hash key, by setting to 1 the EN bit of the AES_CR register (EN is automatically reset when the calculation finishes).
  7. 7. Wait until the end of computation, indicated by the CCF flag of the AES_SR transiting to 1. Alternatively, use the corresponding interrupt.
  8. 8. Clear the CCF flag of the AES_SR register, by setting the CCFC bit of the AES_CR register.

GCM header phase

This phase coming after the GCM Init phase must be completed before the payload phase. The sequence to execute, identical for encryption and decryption, is:

  1. 1. Indicate the header phase, by setting to 01 the GCMPH[1:0] bitfield of the AES_CR register. Do not modify the MODE[1:0] bitfield as set in the Init phase.
  2. 2. Enable the AES peripheral by setting the EN bit of the AES_CR register.
  3. 3. If it is the last block and the AAD size in the block is inferior to 128 bits, pad the remainder of the block with zeros. Then append the data block into AES in one of ways described in Section 23.4.4: AES procedure to perform a cipher operation . No data is read during this phase.
  4. 4. Repeat the step 3 until the last additional authenticated data block is processed.

Note: The header phase can be skipped if there is no AAD, that is, Len(A) = 0.

GCM payload phase

This phase, identical for encryption and decryption, is executed after the GCM header phase. During this phase, the encrypted/decrypted payload is stored in the AES_DOUTR register. The sequence to execute is:

  1. 1. Indicate the payload phase, by setting to 10 the GCMPH[1:0] bitfield of the AES_CR register. Do not modify the MODE[1:0] bitfield as set in the Init phase.
  2. 2. If the header phase was skipped, enable the AES peripheral by setting the EN bit of the AES_CR register.
  3. 3. If it is the last block and the plaintext (encryption) or ciphertext (decryption) size in the block is inferior to 128 bits, pad the remainder of the block with zeros.
  4. 4. Append the data block into AES in one of ways described in Section 23.4.4: AES procedure to perform a cipher operation on page 642 , and read the result.
  5. 5. Repeat the previous step till the second-last plaintext block is encrypted or till the last block of ciphertext is decrypted. For the last block of plaintext (encryption only), execute the two previous steps. For the last block, discard the bits that are not part of the payload when the last block size is less than 16 bytes.

Note: The payload phase can be skipped if there is no payload data, that is, Len(C) = 0 (see GMAC mode).

GCM final phase

In this last phase, the AES peripheral generates the GCM authentication tag and stores it in the AES_DOUTR register. The sequence to execute is:

  1. 1. Indicate the final phase, by setting to 11 the GCMPH[1:0] bitfield of the AES_CR register.
  2. 2. Compose the data of the block, by concatenating the AAD bit length and the payload bit length, as shown in Table 136 . Write the block into the AES_DINR register.
  3. 3. Wait until the end of computation, indicated by the CCF flag of the AES_SR transiting to 1.
  4. 4. Get the GCM authentication tag, by reading the AES_DOUTR register four times.
  5. 5. Clear the CCF flag of the AES_SR register, by setting the CCFC bit of the AES_CR register.
  6. 6. Disable the AES peripheral, by clearing the bit EN of the AES_CR register. If it is an authenticated decryption, compare the generated tag with the expected tag passed with the message.

Note: In the final phase, data is written to AES_DINR normally (no swapping), while swapping is applied to tag data read from AES_DOUTR.

When transiting from the header or the payload phase to the final phase, the AES peripheral must not be disabled, otherwise the result is wrong.

Suspend/resume operations in GCM mode

To suspend the processing of a message , proceed as follows:

  1. 1. If DMA is used, stop the AES DMA transfers to the IN FIFO by clearing the DMAINEN bit of the AES_CR register. If DMA is not used, make sure that the current computation is completed, which is indicated by the CCF flag of the AES_SR register set to 1.
  2. 2. In the payload phase, if DMA is not used, read four times the AES_DOUTR register to save the last-processed block. If DMA is used, wait until the CCF flag is set in the AES_SR register then stop the DMA transfers from the OUT FIFO by clearing the DMAOUTEN bit of the AES_CR register.
  3. 3. Clear the CCF flag of the AES_SR register, by setting the CCFC bit of the AES_CR register.
  4. 4. Save the AES_SUSPxR registers in the memory, where x is from 0 to 7.
  5. 5. In the payload phase, save the AES_IVRx registers as, during the data processing, they changed from their initial values. In the header phase, this step is not required.
  6. 6. Disable the AES peripheral, by clearing the EN bit of the AES_CR register.
  7. 7. Save the current AES configuration in the memory, excluding the initialization vector registers AES_IVRx. Key registers do not need to be saved as the original key value is known by the application.
  8. 8. If DMA is used, save the DMA controller status (pointers for IN data transfers, number of remaining bytes, and so on). In the payload phase, pointers for OUT data transfers must also be saved.

To resume the processing of a message , proceed as follows:

  1. 1. If DMA is used, configure the DMA controller in order to complete the rest of the FIFO IN transfers. In the payload phase, the rest of the FIFO OUT transfers must also be configured in the DMA controller.
  2. 2. Disable the AES peripheral by clearing the EN bit of the AES_CR register.
  3. 3. Write the suspend register values, previously saved in the memory, back into their corresponding AES_SUSPxR registers, where x is from 0 to 7.
  4. 4. In the payload phase, write the initialization vector register values, previously saved in the memory, back into their corresponding AES_IVRx registers. In the header phase, write initial setting values back into the AES_IVRx registers.
  5. 5. Restore the initial setting values in the AES_CR and AES_KEYRx registers.
  6. 6. Enable the AES peripheral by setting the EN bit of the AES_CR register.

If DMA is used, enable AES DMA requests by setting the DMAINEN bit (and DMAOUTEN bit if in payload phase) of the AES_CR register.

23.4.11 AES Galois message authentication code (GMAC)

Overview

The Galois message authentication code (GMAC) allows the authentication of a plaintext, generating the corresponding tag information (also known as message authentication code). It is based on GCM algorithm, as defined in NIST Special Publication 800-38D, Recommendation for Block Cipher Modes of Operation - Galois/Counter Mode (GCM) and GMAC .

A typical message construction for GMAC is given in Figure 120 .

Figure 120. Message construction in GMAC mode

Figure 120: Message construction in GMAC mode. The diagram shows a message structure with 16-byte boundaries. It starts with an ICB (Initialization Vector (IV) and Counter) which has 4-byte boundaries. This is followed by 'Authenticated data' of length 'Len(A)'. The 'Authenticated data' is followed by a 'Last block' which is zero-padded. Above the 'Last block', there are two fields: '[Len(A)]64' and '[0]64'. An arrow labeled 'auth.' points from the 'Authenticated data' to an 'Authentication tag (T)'. A legend indicates that grey boxes represent 'Zero padding'. The reference 'MSv42158V2' is in the bottom right corner.
Figure 120: Message construction in GMAC mode. The diagram shows a message structure with 16-byte boundaries. It starts with an ICB (Initialization Vector (IV) and Counter) which has 4-byte boundaries. This is followed by 'Authenticated data' of length 'Len(A)'. The 'Authenticated data' is followed by a 'Last block' which is zero-padded. Above the 'Last block', there are two fields: '[Len(A)]64' and '[0]64'. An arrow labeled 'auth.' points from the 'Authenticated data' to an 'Authentication tag (T)'. A legend indicates that grey boxes represent 'Zero padding'. The reference 'MSv42158V2' is in the bottom right corner.

AES GMAC processing

Figure 121 describes the GMAC mode implementation in the AES peripheral. This mode is selected by writing 011 to the CHMOD[2:0] bitfield of the AES_CR register.

Figure 121. GMAC authentication mode

Figure 121: GMAC authentication mode. The diagram is divided into four phases: (1) Init, (2) Header, (3) Payload (omitted), and (4) Final. Phase (1) shows the initialization where AES_KEYRx (KEY) and [0]128 are input to an Encrypt block, producing H. Phase (2) shows the header processing where AES_DINR (message block 1) and AES_DINR (message block n) are processed through Swap management and GF2mul blocks, with H being XORed into the stream. DATATYPE [1:0] is also shown. Phase (4) shows the final processing where AES_KEYRx (KEY) and AES_IVRx (IV + 32-bit counter = 0x0) are input to an Encrypt block, producing S. The output of the Encrypt block is XORed with the output of a GF2mul block (which takes len(A)64 || [0]64 and H as input) to produce the AES_DOUTR (authentication tag T). A legend indicates that light grey boxes are 'input', dark grey boxes are 'output', and a circle with a cross is 'XOR'. The reference 'MSv42150V2' is in the bottom right corner.
Figure 121: GMAC authentication mode. The diagram is divided into four phases: (1) Init, (2) Header, (3) Payload (omitted), and (4) Final. Phase (1) shows the initialization where AES_KEYRx (KEY) and [0]128 are input to an Encrypt block, producing H. Phase (2) shows the header processing where AES_DINR (message block 1) and AES_DINR (message block n) are processed through Swap management and GF2mul blocks, with H being XORed into the stream. DATATYPE [1:0] is also shown. Phase (4) shows the final processing where AES_KEYRx (KEY) and AES_IVRx (IV + 32-bit counter = 0x0) are input to an Encrypt block, producing S. The output of the Encrypt block is XORed with the output of a GF2mul block (which takes len(A)64 || [0]64 and H as input) to produce the AES_DOUTR (authentication tag T). A legend indicates that light grey boxes are 'input', dark grey boxes are 'output', and a circle with a cross is 'XOR'. The reference 'MSv42150V2' is in the bottom right corner.

The GMAC algorithm corresponds to the GCM algorithm applied on a message only containing a header. As a consequence, all steps and settings are the same as with the GCM, except that the payload phase is omitted.

Suspend/resume operations in GMAC

In GMAC mode, the sequence described for the GCM applies except that only the header phase can be interrupted.

23.4.12 AES counter with CBC-MAC (CCM)

Overview

The AES counter with cipher block chaining-message authentication code (CCM) algorithm allows encryption and authentication of plaintext, generating the corresponding ciphertext and tag (also known as message authentication code). To ensure confidentiality, the CCM algorithm is based on AES in counter mode. It uses cipher block chaining technique to generate the message authentication code. This is commonly called CBC-MAC.

Note: NIST does not approve this CBC-MAC as an authentication mode outside the context of the CCM specification.

CCM chaining is specified in NIST Special Publication 800-38C, Recommendation for Block Cipher Modes of Operation - The CCM Mode for Authentication and Confidentiality . A typical message construction for CCM is given in Figure 122 .

Figure 122. Message construction in CCM mode

Diagram of CCM message construction showing the layout of B0, Associated Data (A), Plaintext (P), and Encrypted Tag (T).

The diagram illustrates the message construction in CCM mode. The top row shows the message components aligned to 16-byte boundaries: B0, Associated data (A) with length Len(A), Plaintext (P) with length Len(P), and Enc(T) with length Len(T). B0 is further detailed as containing flags, Nonce (N) with length Len(N), and Q, aligned to 4-byte boundaries. The process shows 'Associated data (A)' and 'Plaintext (P)' being fed into an 'authenticate' block to produce 'MAC (T)'. Simultaneously, 'Plaintext (P)' is fed into an 'encrypt' block to produce 'Authenticated & encrypted ciphertext (C)'. A 'Decrypt and compare' block connects the ciphertext (C) and Enc(T) back to the MAC (T). Zero padding is indicated at the end of the Associated Data and Plaintext sections to reach 16-byte boundaries.

Diagram of CCM message construction showing the layout of B0, Associated Data (A), Plaintext (P), and Encrypted Tag (T).

The structure of the message is:

known length \( \text{Len}(A) \) that can be a non-multiple of 16 bytes (see Figure 122 ). The standard also states that, on MSB bits of the first message block ( \( B_1 \) ), the associated data length expressed in bytes ( \( a \) ) must be encoded as follows:

    • – If \( 0 < a < 2^{16} - 2^8 \) , then it is encoded as \( [a]_{16} \) , that is, on two bytes.
    • – If \( 2^{16} - 2^8 < a < 2^{32} \) , then it is encoded as \( 0xff \parallel 0xfe \parallel [a]_{32} \) , that is, on six bytes.
    • – If \( 2^{32} < a < 2^{64} \) , then it is encoded as \( 0xff \parallel 0xff \parallel [a]_{64} \) , that is, on ten bytes.
    • 16-byte blocks (B) associated to the plaintext message \( P \) , which is both authenticated and encrypted as ciphertext \( C \) , with a known length \( \text{Len}(P) \) . This length can be a non-multiple of 16 bytes (see Figure 122 ).
    • Encrypted MAC (T) of length \( \text{Len}(T) \) appended to the ciphertext \( C \) of overall length \( \text{Len}(C) \) .

When a part of the message ( \( A \) or \( P \) ) has a length that is a non-multiple of 16-bytes, a special padding scheme is required.

Note: CCM chaining mode can also be used with associated data only (that is, no payload).

As an example, the C.1 section in NIST Special Publication 800-38C gives the following values (hexadecimal numbers):

N: 10111213 141516 ( \( \text{Len}(N) = 56 \) bits or 7 bytes)
A: 00010203 04050607 ( \( \text{Len}(A) = 64 \) bits or 8 bytes)
P: 20212223 ( \( \text{Len}(P) = 32 \) bits or 4 bytes)
T: 6084341B ( \( \text{Len}(T) = 32 \) bits or \( t = 4 \) )
\( B_0 \) : 4F101112 13141516 00000000 00000004
\( B_1 \) : 00080001 02030405 06070000 00000000
\( B_2 \) : 20212223 00000000 00000000 00000000
\( CTR0 \) : 0710111213 141516 00000000 00000000
\( CTR1 \) : 0710111213 141516 00000000 00000001

Generation of formatted input data blocks \( B_x \) (especially \( B_0 \) and \( B_1 \) ) must be managed by the application.

CCM processing

Figure 123 describes the CCM implementation within the AES peripheral (encryption example). This mode is selected by writing 100 into the CHMOD[2:0] bitfield of the AES_CR register.

Figure 123. CCM mode authenticated encryption

A detailed block diagram of CCM mode authenticated encryption. It is divided into four main sections: (1) Init, (2) Header, (3) Payload, and (4) Final. Section (1) shows the initialization where a mask and the first counter block (CTR0) are used to generate the first counter block (CTR1) via a counter increment (+1). Section (2) shows the header processing where associated data blocks (B1 to Bu) are processed through swap management and XORed with the counter blocks before being encrypted. Section (3) shows the payload processing where plaintext blocks (P1 to Pm) are processed similarly. Section (4) shows the final step where the MAC (T) is generated by encrypting the counter blocks and XORing the result with the associated data. A legend indicates that light gray boxes represent inputs, dark gray boxes represent outputs, and a circle with an X represents an XOR operation. The diagram also shows various AES registers like AES_IVRx, AES_KEYRx, AES_DINR, and AES_DOUTR, as well as internal components like 'Encrypt', 'Swap management', and 'Counter increment (+1)'.
A detailed block diagram of CCM mode authenticated encryption. It is divided into four main sections: (1) Init, (2) Header, (3) Payload, and (4) Final. Section (1) shows the initialization where a mask and the first counter block (CTR0) are used to generate the first counter block (CTR1) via a counter increment (+1). Section (2) shows the header processing where associated data blocks (B1 to Bu) are processed through swap management and XORed with the counter blocks before being encrypted. Section (3) shows the payload processing where plaintext blocks (P1 to Pm) are processed similarly. Section (4) shows the final step where the MAC (T) is generated by encrypting the counter blocks and XORing the result with the associated data. A legend indicates that light gray boxes represent inputs, dark gray boxes represent outputs, and a circle with an X represents an XOR operation. The diagram also shows various AES registers like AES_IVRx, AES_KEYRx, AES_DINR, and AES_DOUTR, as well as internal components like 'Encrypt', 'Swap management', and 'Counter increment (+1)'.

The data input to the generation-encryption process are a valid nonce, a valid payload string, and a valid associated data string, all properly formatted. The CBC chaining mechanism is applied to the formatted plaintext data to generate a MAC, with a known length. Counter mode encryption that requires a sufficiently long sequence of counter blocks as input, is applied to the payload string and separately to the MAC. The resulting ciphertext C is the output of the generation-encryption process on plaintext P.

AES_IVRx registers are used for processing each data block, AES automatically incrementing the CTR counter with a bit length defined by the first block B0. Table 138 shows how the application must load the B0 data.

Note: The AES peripheral in CCM mode supports counters up to 64 bits, as specified by NIST.

Table 138. Initialization of AES_IVRx registers in CCM mode

AES_IVR3[31:0]AES_IVR2[31:0]AES_IVR1[31:0]AES_IVR0[31:0]
B0[127:96]B0[95:64]B0[63:32]B0[31:0]

Note: In this mode, the setting 01 of the MODE[1:0] bitfield (key derivation) is forbidden.

A CCM message is processed through the following phases, further described in next subsections:

CCM Init phase

In this phase, the first block B0 of the CCM message is written into the AES_IVRx register. The AES_DOUTR register does not contain any output data. The recommended sequence is:

  1. 1. Disable the AES peripheral by clearing the EN bit of the AES_CR register.
  2. 2. Select CCM chaining mode, by setting to 100 the CHMOD[2:0] bitfield of the AES_CR register, and optionally, set the DATATYPE[1:0] bitfield.
  3. 3. Indicate the Init phase, by setting to 00 the GCMPH[1:0] bitfield of the AES_CR register.
  4. 4. Set the MODE[1:0] bitfield of the AES_CR register to 00 or 10. Although the bitfield is only used in payload phase, it is recommended to set it in the Init phase and keep it unchanged in all subsequent phases.
  5. 5. Initialize the AES_KEYRx registers with a key, and initialize AES_IVRx registers with B0 data as described in Table 138 .
  6. 6. Start the calculation of the counter, by setting to 1 the EN bit of the AES_CR register (EN is automatically reset when the calculation finishes).
  7. 7. Wait until the end of computation, indicated by the CCF flag of the AES_SR transiting to 1. Alternatively, use the corresponding interrupt.
  8. 8. Clear the CCF flag in the AES_SR register, by setting to 1 the CCFC bit of the AES_CR register.

CCM header phase

This phase coming after the GCM Init phase must be completed before the payload phase. During this phase, the AES_DOUTR register does not contain any output data.

The sequence to execute, identical for encryption and decryption, is:

  1. 1. Indicate the header phase, by setting to 01 the GCMPH[1:0] bitfield of the AES_CR register. Do not modify the MODE[1:0] bitfield as set in the Init phase.
  2. 2. Enable the AES peripheral by setting the EN bit of the AES_CR register.
  3. 3. If it is the last block and the AAD size in the block is inferior to 128 bits, pad the remainder of the block with zeros. Then append the data block into AES in one of ways described in Section 23.4.4: AES procedure to perform a cipher operation . No data is read during this phase.
  4. 4. Repeat the step 3 until the last additional authenticated data block is processed.

Note: The header phase can be skipped if there is no associated data, that is, \( Len(A) = 0 \) .

The first block of the associated data (B1) must be formatted by software, with the associated data length.

CCM payload phase (encryption or decryption)

This phase, identical for encryption and decryption, is executed after the CCM header phase. During this phase, the encrypted/decrypted payload is stored in the AES_DOUTR register. The sequence to execute is:

  1. 1. Indicate the payload phase, by setting to 10 the GCMPH[1:0] bitfield of the AES_CR register. Do not modify the MODE[1:0] bitfield as set in the Init phase.
  2. 2. If the header phase was skipped, enable the AES peripheral by setting the EN bit of the AES_CR register.
  3. 3. If it is the last data block to encrypt and the plaintext size in the block is inferior to 128 bits, pad the remainder of the block with zeros.
  4. 4. Append the data block into AES in one of ways described in Section 23.4.4: AES procedure to perform a cipher operation on page 642 , and read the result.
  5. 5. Repeat the previous step till the second-last plaintext block is encrypted or till the last block of ciphertext is decrypted. For the last block of plaintext (encryption only), apply the two previous steps. For the last block, discard the data that is not part of the payload when the last block size is less than 16 bytes.

Note: The payload phase can be skipped if there is no payload data, that is, \( Len(P) = 0 \) or \( Len(C) = Len(T) \) .

Remove \( LSB_{Len(T)}(C) \) encrypted tag information when decrypting ciphertext C.

CCM final phase

In this last phase, the AES peripheral generates the GCM authentication tag and stores it in the AES_DOUTR register. The sequence to execute is:

  1. 1. Indicate the final phase, by setting to 11 the GCMPH[1:0] bitfield of the AES_CR register.
  2. 2. Wait until the end-of-computation flag CCF of the AES_SR register is set.
  3. 3. Read four times the AES_DOUTR register: the output corresponds to the CCM authentication tag.
  4. 4. Clear the CCF flag of the AES_SR register by setting the CCFC bit of the AES_CR register.
  5. 5. Disable the AES peripheral, by clearing the EN bit of the AES_CR register.
  6. 6. For authenticated decryption, compare the generated encrypted tag with the encrypted tag padded in the ciphertext.

Note: In this final phase, swapping is applied to tag data read from AES_DOUTR register.

When transiting from the header phase to the final phase, the AES peripheral must not be disabled, otherwise the result is wrong.

Application must mask the authentication tag output with tag length to obtain a valid tag.

Suspend/resume operations in CCM mode

To suspend the processing of a message in header or payload phase, proceed as follows:

  1. 1. If DMA is used, stop the AES DMA transfers to the IN FIFO by clearing the DMAINEN bit of the AES_CR register. If DMA is not used, make sure that the current computation is completed, which is indicated by the CCF flag of the AES_SR register set to 1.
  2. 2. In the payload phase, if DMA is not used, read four times the AES_DOUTR register to save the last-processed block. If DMA is used, wait until the CCF flag is set in the

AES_SR register then stop the DMA transfers from the OUT FIFO by clearing the DMAOUTEN bit of the AES_CR register.

  1. 3. Clear the CCF flag of the AES_SR register, by setting to 1 the CCFC bit of the AES_CR register.
  2. 4. Save the AES_SUSPxR registers (where x is from 0 to 7) in the memory.
  3. 5. Save the AES_IVRx registers as, during the data processing, they changed from their initial values.
  4. 6. Disable the AES peripheral, by clearing the EN bit of the AES_CR register.
  5. 7. Save the current AES configuration in the memory, excluding the initialization vector registers AES_IVRx. Key registers do not need to be saved as the original key value is known by the application.
  6. 8. If DMA is used, save the DMA controller status (pointers for IN data transfers, number of remaining bytes, and so on). In the payload phase, pointers for OUT data transfers must also be saved.

To resume the processing of a message , proceed as follows:

  1. 1. If DMA is used, configure the DMA controller in order to complete the rest of the FIFO IN transfers. In the payload phase, the rest of the FIFO OUT transfers must also be configured in the DMA controller.
  2. 2. Disable the AES peripheral by clearing the EN bit of the AES_CR register.
  3. 3. Write the suspend register values, previously saved in the memory, back into their corresponding AES_SUSPxR registers (where x is from 0 to 7).
  4. 4. Write the initialization vector register values, previously saved in the memory, back into their corresponding AES_IVRx registers.
  5. 5. Restore the initial setting values in the AES_CR and AES_KEYRx registers.
  6. 6. Enable the AES peripheral by setting the EN bit of the AES_CR register.
  7. 7. If DMA is used, enable AES DMA requests by setting to 1 the DMAINEN bit (and DMAOUTEN bit if in payload phase) of the AES_CR register.

23.4.13 AES data registers and data swapping

Data input and output

A 128-bit data block is entered into the AES peripheral with four successive 32-bit word writes into the AES_DINR register (bitfield DIN[31:0]), the most significant word (bits [127:96]) first, the least significant word (bits [31:0]) last.

A 128-bit data block is retrieved from the AES peripheral with four successive 32-bit word reads from the AES_DOUTR register (bitfield DOUT[31:0]), the most significant word (bits [127:96]) first, the least significant word (bits [31:0]) last.

The 32-bit data word for AES_DINR register or from AES_DOUTR register is organized in big endian order, that is:

For using DMA for input data block write into AES, the four words of the input block must be stored in the memory consecutively and in big-endian order, that is, the most significant word on the lowest address. See Section 23.4.16: AES DMA interface .

Data swapping

The AES peripheral can be configured to perform a bit-, a byte-, a half-word-, or no swapping on the input data word in the AES_DINR register, before loading it to the AES processing core, and on the data output from the AES processing core, before sending it to the AES_DOUTR register. The choice depends on the type of data. For example, a byte swapping is used for an ASCII text stream.

The data swap type is selected through the DATATYPE[1:0] bitfield of the AES_CR register. The selection applies both to the input and the output of the AES core.

For different data swap types, Figure 124 shows the construction of AES processing core input buffer data P127 to P0, from the input data entered through the AES_DINR register, or the construction of the output data available through the AES_DOUTR register, from the AES processing core output buffer data P127 to P0.

Figure 124. 128-bit block construction with respect to data swap

Figure 124: 128-bit block construction with respect to data swap. The diagram illustrates four data swap scenarios: 00 (no swapping), 01 (16-bit half-word swapping), 10 (8-bit byte swapping), and 11 (bit swapping). Each scenario shows the mapping of input data blocks (Word 0-3) to the AES core buffer (P127-P0) with arrows indicating the data swap order. A legend at the bottom explains the symbols for memory blocks, buffer data, zero padding, and the swap order indicators.

Figure 124. 128-bit block construction with respect to data swap

The diagram illustrates the construction of a 128-bit block for the AES processing core input buffer (P127 to P0) based on the DATATYPE[1:0] bitfield settings. The input data is shown as four words (Word 3, Word 2, Word 1, Word 0) in memory, with increasing memory addresses from left to right. The output is the data as it appears in the AES core buffer, with arrows indicating the mapping and data swap order (1 to 4).

Legend:

MSV42153V2

Figure 124: 128-bit block construction with respect to data swap. The diagram illustrates four data swap scenarios: 00 (no swapping), 01 (16-bit half-word swapping), 10 (8-bit byte swapping), and 11 (bit swapping). Each scenario shows the mapping of input data blocks (Word 0-3) to the AES core buffer (P127-P0) with arrows indicating the data swap order. A legend at the bottom explains the symbols for memory blocks, buffer data, zero padding, and the swap order indicators.

Note: The data in AES key registers (AES_KEYRx) and initialization registers (AES_IVRx) are not sensitive to the swap mode selection.

Data padding

Figure 124 also gives an example of memory data block padding with zeros such that the zeroed bits after the data swap form a contiguous zone at the MSB end of the AES core input buffer. The example shows the padding of an input data block containing:

23.4.14 AES key registers

The AES_KEYRx write-only registers store the encryption or decryption key bitfield KEY[127:0] or KEY[255:0]. The data to write to each register is organized in the memory in little-endian order, that is, with most significant byte on the highest address (reads are not allowed for security reason).

The key is spread over eight registers as shown in Table 139.

Table 139. Key endianness in AES_KEYRx registers (128- or 256-bit key length)

AES_KEYR7
[31:0]
AES_KEYR6
[31:0]
AES_KEYR5
[31:0]
AES_KEYR4
[31:0]
AES_KEYR3
[31:0]
AES_KEYR2
[31:0]
AES_KEYR1
[31:0]
AES_KEYR0
[31:0]
----KEY[127:96]KEY[95:64]KEY[63:32]KEY[31:0]
KEY[255:224]KEY[223:192]KEY[191:160]KEY[159:128]KEY[127:96]KEY[95:64]KEY[63:32]KEY[31:0]

The key for encryption or decryption may be written into these registers when the AES peripheral is disabled, by clearing the EN bit of the AES_CR register.

The key registers are not affected by the data swapping controlled by DATATYPE[1:0] bitfield of the AES_CR register.

23.4.15 AES initialization vector registers

The four AES_IVRx registers keep the initialization vector input bitfield IVI[127:0]. The data to write to or to read from each register is organized in the memory in little-endian order, that is, with most significant byte on the highest address. The registers are also ordered from lowest address (AES_IVR0) to highest address (AES_IVR3).

The signification of data in the bitfield depends on the chaining mode selected. When used, the bitfield is updated upon each computation cycle of the AES core.

Write operations to the AES_IVRx registers when the AES peripheral is enabled have no effect to the register contents. For modifying the contents of the AES_IVRx registers, the EN bit of the AES_CR register must first be cleared.

Reading the AES_IVRx registers returns the latest counter value (useful for managing suspend mode).

The AES_IVRx registers are not affected by the data swapping feature controlled by the DATATYPE[1:0] bitfield of the AES_CR register.

23.4.16 AES DMA interface

The AES peripheral provides an interface to connect to the DMA (direct memory access) controller. The DMA operation is controlled through the AES_CR register.

Data input using DMA

Setting the DMAINEN bit of the AES_CR register enables DMA writing into AES. The AES peripheral then initiates a DMA request during the input phase each time it requires to write a 128-bit block (quadruple word) to the AES_DINR register, as shown in Figure 125.

Note: According to the algorithm and the mode selected, special padding / ciphertext stealing might be required. For example, in case of AES GCM encryption or AES CCM decryption, a DMA transfer must not include the last block. For details, refer to Section 23.4.4: AES procedure to perform a cipher operation.

Figure 125. DMA transfer of a 128-bit data block during input phase

Diagram showing DMA transfer of a 128-bit data block during input phase. It illustrates the flow of data from memory (Words 0-3) through DMA single writes to the AES_DINR register and into the AES core input buffer. The diagram shows bit positions (D127 to D0) and the order of writes (1 to 4).

The diagram illustrates the DMA transfer of a 128-bit data block during the input phase. At the top, a horizontal arrow indicates 'Chronological order' and 'Increasing address' from left to right. Below this, a section titled 'Memory accessed through DMA' shows four words: Word3 (D127 to D96), Word2 (D95 to D64), Word1 (D63 to D32), and Word0 (D31 to D0). Each word is associated with a 'DMA single write' operation, labeled 1, 2, 3, and 4 respectively. DMA requests are indicated as 'DMA req N', 'DMA req N+1', 'DMA req N+2', and 'DMA req N+3'. Arrows show the data flow from these writes into the 'AES_DINR' register. Below the register, the 'AES core input buffer' is shown, with a note '(No swapping)'. The buffer is divided into segments with bit positions: 1127 to 196, 195 to 164, 163 to 132, and 131 to 10. Arrows 1 through 4 show the order of write to the AES_DINR, which corresponds to the order of data filling the buffer. The diagram is labeled 'System' on the right and 'AES peripheral' on the right. A reference code 'MSV42160V1' is in the bottom right corner.

Diagram showing DMA transfer of a 128-bit data block during input phase. It illustrates the flow of data from memory (Words 0-3) through DMA single writes to the AES_DINR register and into the AES core input buffer. The diagram shows bit positions (D127 to D0) and the order of writes (1 to 4).

Data output using DMA

Setting the DMAOUTEN bit of the AES_CR register enables DMA reading from AES. The AES peripheral then initiates a DMA request during the Output phase each time it requires to read a 128-bit block (quadruple word) to the AES_DINR register, as shown in Figure 126.

Note: According to the message size, extra bytes might need to be discarded by application in the last block.

Figure 126. DMA transfer of a 128-bit data block during output phase

Diagram illustrating the DMA transfer of a 128-bit data block during the output phase. The diagram shows the flow of data from the AES core output buffer through the AES_DOUTR register to memory accessed via DMA. The memory is divided into four words (Word0 to Word3), each 32 bits wide. DMA single read requests are generated by the AES for each word. The order of read from the AES_DOUTR register is indicated by numbers 1 to 4, corresponding to the words Word0, Word1, Word2, and Word3 respectively. The diagram also shows the MSB and LSB positions for each word and the overall chronological order of increasing address.

The diagram illustrates the DMA transfer of a 128-bit data block during the output phase. At the top, a horizontal arrow indicates 'Chronological order' and 'Increasing address'. Below this, a section titled 'Memory accessed through DMA' shows four words: Word3 (D127 to D96), Word2 (D95 to D64), Word1 (D63 to D32), and Word0 (D31 to D0). Each word has a corresponding DOUT range: DOUT[127:96], DOUT[95:64], DOUT[63:32], and DOUT[31:0]. Below the memory words, four 'DMA single read' blocks are shown, labeled 1, 2, 3, and 4. These are connected to 'DMA req N', 'DMA req N+1', 'DMA req N+2', and 'DMA req N+3' respectively. A horizontal line labeled 'AES_DOUTR' connects these DMA requests to the 'AES core output buffer' below. The buffer is divided into four 32-bit segments: O127 to O96, O95 to O64, O63 to O32, and O31 to O0. Arrows labeled 1, 2, 3, and 4 point from the buffer segments to the DMA single read blocks. A note '(No swapping)' is present. At the bottom, a dashed line indicates the 'Order of read from AES_DOUTR' with numbers 1 to 4. The diagram is labeled 'MSV42161V1' in the bottom right corner.

Diagram illustrating the DMA transfer of a 128-bit data block during the output phase. The diagram shows the flow of data from the AES core output buffer through the AES_DOUTR register to memory accessed via DMA. The memory is divided into four words (Word0 to Word3), each 32 bits wide. DMA single read requests are generated by the AES for each word. The order of read from the AES_DOUTR register is indicated by numbers 1 to 4, corresponding to the words Word0, Word1, Word2, and Word3 respectively. The diagram also shows the MSB and LSB positions for each word and the overall chronological order of increasing address.

DMA operation in different operating modes

DMA operations are usable when Mode 1 (encryption) or Mode 3 (decryption) are selected via the MODE[1:0] bitfield of the register AES_CR. As in Mode 2 (key derivation) the AES_KEYRx registers must be written by software, enabling the DMA transfer through the DMAINEN and DMAOUTEN bits of the AES_CR register have no effect in that mode.

DMA single requests are generated by AES until it is disabled. So, after the data output phase at the end of processing of a 128-bit data block, AES switches automatically to a new data input phase for the next data block, if any.

When the data transferring between AES and memory is managed by DMA, the CCF flag has no use because the reading of the AES_DOUTR register is managed by DMA automatically at the end of the computation phase. The CCF flag must only be cleared when transiting back to data transferring managed by software. See Section 23.4.4: AES procedure to perform a cipher operation , subsection Data append , for details.

23.4.17 AES error management

AES configuration can be changed at any moment by clearing the EN bit of the AES_CR register.

Read error flag (RDERR)

Unexpected read attempt of the AES_DOUTR register sets the RDERR flag of the AES_SR register, and returns zero.

RDERR is triggered during the computation phase or during the input phase.

Note: AES is not disabled upon a RDERR error detection and continues processing.

An interrupt is generated if the ERRIE bit of the AES_CR register is set. For more details, refer to Section 23.5: AES interrupts .

The RDERR flag is cleared by setting the ERRIE bit of the AES_CR register.

Write error flag (WDERR)

Unexpected write attempt of the AES_DINR register sets the WRERR flag of the AES_SR register, and has no effect on the AES_DINR register. The WRERR is triggered during the computation phase or during the output phase.

Note: AES is not disabled after a WRERR error detection and continues processing.

An interrupt is generated if the ERRIE bit of the AES_CR register is set. For more details, refer to Section 23.5: AES interrupts .

The WRERR flag is cleared by setting the ERRC bit of the AES_CR register.

23.5 AES interrupts

Individual maskable interrupt sources generated by the AES peripheral signal the following events:

These sources are combined into a common interrupt signal from the AES peripheral that connects to the Arm ® Cortex ® interrupt controller. Each can individually be enabled/disabled, by setting/clearing the corresponding enable bit of the AES_CR register, and cleared by setting the corresponding bit of the AES_SR register.

The status of each can be read from the AES_SR register.

Table 140 gives a summary of the interrupt sources, their event flags and enable bits.

Table 140. AES interrupt requests

Interrupt acronymAES interrupt eventEvent flagEnable bitInterrupt clear method
AEScomputation completed flagCCFCCFIEset CCFC (1)
read error flagRDERRERRIEset ERRC (1)
write error flagWRERR

1. Bit of the AES_CR register.

23.6 AES processing latency

The tables below summarize the latency to process a 128-bit block for each mode of operation.

Table 141. Processing latency for ECB, CBC and CTR

Key sizeMode of operationAlgorithmClock cycles
128-bitMode 1: EncryptionECB, CBC, CTR51
Mode 2: Key derivation-59
Mode 3: DecryptionECB, CBC, CTR51
256-bitMode 1: EncryptionECB, CBC, CTR75
Mode 2: Key derivation-82
Mode 3: DecryptionECB, CBC, CTR75

Table 142. Processing latency for GCM and CCM (in clock cycles)

Key sizeMode of operationAlgorithmInit PhaseHeader phase (1)Payload phase (1)Tag phase (1)
128-bitMode 1: Encryption/
Mode 3: Decryption
GCM64355159
CCM635511458
256-bitMode 1: Encryption/
Mode 3: Decryption
GCM88357575
CCM877916282

1. Data insertion can include wait states forced by AES on the AHB bus (maximum 3 cycles, typical 1 cycle).

23.7 AES registers

23.7.1 AES control register (AES_CR)

Address offset: 0x00

Reset value: 0x0000 0000

31302928272625242322212019181716
Res.Res.Res.Res.Res.Res.Res.Res.NPBLB[3:0]Res.KEYSIZERes.CHMOD[2]
rwrwrwrwrwrw

1514131211109876543210
Res.GCMPH[1:0]DMAOUTENDMAINENERRIECCFIEERRCCCFCCHMOD[1:0]MODE[1:0]DATATYPE[1:0]EN
rwrwrwrwrwrwrwrwrwrwrwrwrwrwrw

Bits 31:24 Reserved, must be kept at reset value.

Bits 23:20 NPBLB[3:0] : Number of padding bytes in last block

The bitfield sets the number of padding bytes in last block of payload:

0000: All bytes are valid (no padding)

0001: Padding for one least-significant byte of last block

...

1111: Padding for 15 least-significant bytes of last block

Bit 19 Reserved, must be kept at reset value.

Bit 18 KEYSIZE : Key size selection

This bitfield defines the length of the key used in the AES cryptographic core, in bits:

0: 128

1: 256

Attempts to write the bit are ignored when the EN bit of the AES_CR register is set before the write access and it is not cleared by that write access.

Bit 17 Reserved, must be kept at reset value.

Bit 15 Reserved, must be kept at reset value.

Bits 14:13 GCM/PH[1:0]: GCM or CCM phase selection

This bitfield selects the phase of GCM, GMAC or CCM algorithm:

00: Init phase

01: Header phase

10: Payload phase

11: Final phase

The bitfield has no effect if other than GCM, GMAC or CCM algorithms are selected (through the ALGOMODE bitfield).

Bit 12 DMAOUTEN: DMA output enable

This bit enables/disables data transferring with DMA, in the output phase:

0: Disable

1: Enable

When the bit is set, DMA requests are automatically generated by AES during the output data phase. This feature is only effective when Mode 1 or Mode 3 is selected through the MODE[1:0] bitfield. It is not effective for Mode 2 (key derivation).

Bit 11 DMAINEN: DMA input enable

This bit enables/disables data transferring with DMA, in the input phase:

0: Disable

1: Enable

When the bit is set, DMA requests are automatically generated by AES during the input data phase. This feature is only effective when Mode 1 or Mode 3 is selected through the MODE[1:0] bitfield. It is not effective for Mode 2 (key derivation).

Bit 10 ERRIE: Error interrupt enable

This bit enables or disables (masks) the AES interrupt generation when RDERR and/or WRERR is set:

0: Disable (mask)

1: Enable

Bit 9 CCFIE: CCF interrupt enable

This bit enables or disables (masks) the AES interrupt generation when CCF (computation complete flag) is set:

0: Disable (mask)

1: Enable

Bit 8 ERRRC: Error flag clear

Upon written to 1, this bit clears the RDERR and WRERR error flags in the AES_SR register:

0: No effect

1: Clear RDERR and WRERR flags

Reading the flag always returns zero.

Bit 7 CCFC: Computation complete flag clear

Upon written to 1, this bit clears the computation complete flag (CCF) in the AES_SR register:

0: No effect

1: Clear CCF

Reading the flag always returns zero.

Bits 16, 6:5 CHMOD[2:0] : Chaining mode selection

This bitfield selects the AES chaining mode:

000: Electronic codebook (ECB)

001: Cipher-block chaining (CBC)

010: Counter mode (CTR)

011: Galois counter mode (GCM) and Galois message authentication code (GMAC)

100: Counter with CBC-MAC (CCM)

others: Reserved

Attempts to write the bitfield are ignored when the EN bit of the AES_CR register is set before the write access and it is not cleared by that write access.

Bits 4:3 MODE[1:0] : AES operating mode

This bitfield selects the AES operating mode:

00: Mode 1: encryption

01: Mode 2: key derivation (or key preparation for ECB/CBC decryption)

10: Mode 3: decryption

11: Reserved

Attempts to write the bitfield are ignored when the EN bit of the AES_CR register is set before the write access and it is not cleared by that write access.

Bits 2:1 DATATYPE[1:0] : Data type selection

This bitfield defines the format of data written in the AES_DINR register or read from the AES_DOUTR register, through selecting the mode of data swapping:

00: None

01: Half-word (16-bit)

10: Byte (8-bit)

11: Bit

For more details, refer to Section 23.4.13: AES data registers and data swapping .

Attempts to write the bitfield are ignored when the EN bit of the AES_CR register is set before the write access and it is not cleared by that write access.

Bit 0 EN : AES enable

This bit enables/disables the AES peripheral:

0: Disable

1: Enable

At any moment, clearing then setting the bit re-initializes the AES peripheral.

This bit is automatically cleared by hardware upon the completion of the key preparation (Mode 2) and upon the completion of GCM/GMAC/CCM initial phase.

23.7.2 AES status register (AES_SR)

Address offset: 0x04

Reset value: 0x0000 0000

31302928272625242322212019181716
Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.
1514131211109876543210
Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.BUSYWRERRRDERRCCF
rrrr

Bits 31:4 Reserved, must be kept at reset value.

Bit 3 BUSY: Busy

This flag indicates whether AES is idle or busy during GCM payload encryption phase:

0: Idle

1: Busy

When the flag indicates “idle”, the current GCM encryption processing may be suspended to process a higher-priority message. In other chaining modes, or in GCM phases other than payload encryption, the flag must be ignored for the suspend process.

Bit 2 WRERR: Write error

This flag indicates the detection of an unexpected write operation to the AES_DINR register (during computation or data output phase):

0: Not detected

1: Detected

The flag is set by hardware. It is cleared by software upon setting the ERRRC bit of the AES_CR register.

Upon the flag setting, an interrupt is generated if enabled through the ERRRIE bit of the AES_CR register.

The flag setting has no impact on the AES operation. Unexpected write is ignored.

Bit 1 RDERR: Read error flag

This flag indicates the detection of an unexpected read operation from the AES_DOUTR register (during computation or data input phase):

0: Not detected

1: Detected

The flag is set by hardware. It is cleared by software upon setting the ERRRC bit of the AES_CR register.

Upon the flag setting, an interrupt is generated if enabled through the ERRRIE bit of the AES_CR register.

The flag setting has no impact on the AES operation. Unexpected read returns zero.

Bit 0 CCF: Computation completed flag

This flag indicates whether the computation is completed:

0: Not completed

1: Completed

The flag is set by hardware upon the completion of the computation. It is cleared by software, upon setting the CCFC bit of the AES_CR register.

Upon the flag setting, an interrupt is generated if enabled through the CCFIE bit of the AES_CR register.

The flag is significant only when the DMAOUTEN bit is 0. It may stay high when DMA_EN is 1.

23.7.3 AES data input register (AES_DINR)

Address offset: 0x08

Reset value: 0x0000 0000

Only 32-bit access type is supported.

31302928272625242322212019181716
DIN[31:16]
rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw
1514131211109876543210
DIN[15:0]
rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw

Bits 31:0 DIN[31:0] : Input data word

A four-fold sequential write to this bitfield during the input phase results in writing a complete 128-bit block of input data to the AES peripheral. From the first to the fourth write, the corresponding data weights are [127:96], [95:64], [63:32], and [31:0]. Upon each write, the data from the 32-bit input buffer are handled by the data swap block according to the DATATYPE[1:0] bitfield, then written into the AES core 128-bit input buffer.

The data signification of the input data block depends on the AES operating mode:

The data swap operation is described in Section 23.4.13: AES data registers and data swapping on page 665 .

23.7.4 AES data output register (AES_DOUTR)

Address offset: 0x0C

Reset value: 0x0000 0000

Only 32-bit read access type is supported.

31302928272625242322212019181716
DOUT[31:16]
rrrrrrrrrrrrrrrr
1514131211109876543210
DOUT[15:0]
rrrrrrrrrrrrrrrr

Bits 31:0 DOUT[31:0] : Output data word

This read-only bitfield fetches a 32-bit output buffer. A four-fold sequential read of this bitfield, upon the computation completion (CCF set), virtually reads a complete 128-bit block of output data from the AES peripheral. Before reaching the output buffer, the data produced by the AES core are handled by the data swap block according to the DATATYPE[1:0] bitfield.

Data weights from the first to the fourth read operation are: [127:96], [95:64], [63:32], and [31:0].

The data signification of the output data block depends on the AES operating mode:

The data swap operation is described in Section 23.4.13: AES data registers and data swapping on page 665 .

23.7.5 AES key register 0 (AES_KEYR0)

Address offset: 0x10

Reset value: 0x0000 0000

31302928272625242322212019181716
KEY[31:16]
wwwwwwwwwwwwwwww
1514131211109876543210
KEY[15:0]
wwwwwwwwwwwwwwww

Bits 31:0 KEY[31:0] : Cryptographic key, bits [31:0]

This write-only bitfield contains the bits [31:0] of the AES encryption or decryption key, depending on the operating mode:

The AES_KEYRx registers may be written only when KEYSIZE value is correct and when the AES peripheral is disabled (EN bit of the AES_CR register cleared). Note that, if, the key is directly loaded to AES_KEYRx registers (hence writes to key register is ignored and KEIF is set).

Refer to Section 23.4.14: AES key registers on page 667 for more details.

23.7.6 AES key register 1 (AES_KEYR1)

Address offset: 0x14

Reset value: 0x0000 0000

31302928272625242322212019181716
KEY[63:48]
wwwwwwwwwwwwwwww
1514131211109876543210
KEY[47:32]
wwwwwwwwwwwwwwww

Bits 31:0 KEY[63:32] : Cryptographic key, bits [63:32]

Refer to the AES_KEYR0 register for description of the KEY[255:0] bitfield.

23.7.7 AES key register 2 (AES_KEYR2)

Address offset: 0x18

Reset value: 0x0000 0000

31302928272625242322212019181716
KEY[95:80]
wwwwwwwwwwwwwwww
1514131211109876543210
KEY[79:64]
wwwwwwwwwwwwwwww

Bits 31:0 KEY[95:64] : Cryptographic key, bits [95:64]

Refer to the AES_KEYR0 register for description of the KEY[255:0] bitfield.

23.7.8 AES key register 3 (AES_KEYR3)

Address offset: 0x1C

Reset value: 0x0000 0000

31302928272625242322212019181716
KEY[127:112]
wwwwwwwwwwwwwwww
1514131211109876543210
KEY[111:96]
wwwwwwwwwwwwwwww

Bits 31:0 KEY[127:96] : Cryptographic key, bits [127:96]

Refer to the AES_KEYR0 register for description of the KEY[255:0] bitfield.

23.7.9 AES initialization vector register 0 (AES_IVR0)

Address offset: 0x20

Reset value: 0x0000 0000

31302928272625242322212019181716
IVI[31:16]
rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw
1514131211109876543210
IVI[15:0]
rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw

Bits 31:0 IVI[31:0] : Initialization vector input, bits [31:0]

Refer to Section 23.4.15: AES initialization vector registers on page 667 for description of the IVI[127:0] bitfield.

The initialization vector is only used in chaining modes other than ECB.

The AES_IVRx registers may be written only when the AES peripheral is disabled

23.7.10 AES initialization vector register 1 (AES_IVR1)

Address offset: 0x24

Reset value: 0x0000 0000

31302928272625242322212019181716
IVI[63:48]
rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw
1514131211109876543210
IVI[47:32]
rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw

Bits 31:0 IVI[63:32] : Initialization vector input, bits [63:32]

Refer to the AES_IVR0 register for description of the IVI[128:0] bitfield.

23.7.11 AES initialization vector register 2 (AES_IVR2)

Address offset: 0x28

Reset value: 0x0000 0000

31302928272625242322212019181716
IVI[95:80]
rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw
1514131211109876543210
IVI[79:64]
rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw

Bits 31:0 IVI[95:64] : Initialization vector input, bits [95:64]

Refer to the AES_IVR0 register for description of the IVI[128:0] bitfield.

23.7.12 AES initialization vector register 3 (AES_IVR3)

Address offset: 0x2C

Reset value: 0x0000 0000

31302928272625242322212019181716
IVI[127:112]
rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw
1514131211109876543210
IVI[111:96]
rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw

Bits 31:0 IVI[127:96] : Initialization vector input, bits [127:96]

Refer to the AES_IVR0 register for description of the IVI[128:0] bitfield.

23.7.13 AES key register 4 (AES_KEYR4)

Address offset: 0x30

Reset value: 0x0000 0000

31302928272625242322212019181716
KEY[159:144]
wwwwwwwwwwwwwwww
1514131211109876543210
KEY[143:128]
wwwwwwwwwwwwwwww

Bits 31:0 KEY[159:128] : Cryptographic key, bits [159:128]

Refer to the AES_KEYR0 register for description of the KEY[255:0] bitfield.

23.7.14 AES key register 5 (AES_KEYR5)

Address offset: 0x34

Reset value: 0x0000 0000

31302928272625242322212019181716
KEY[191:176]
wwwwwwwwwwwwwwww
1514131211109876543210
KEY[175:160]
wwwwwwwwwwwwwwww

Bits 31:0 KEY[191:160] : Cryptographic key, bits [191:160]

Refer to the AES_KEYR0 register for description of the KEY[255:0] bitfield.

23.7.15 AES key register 6 (AES_KEYR6)

Address offset: 0x38

Reset value: 0x0000 0000

31302928272625242322212019181716
KEY[223:208]
wwwwwwwwwwwwwwww
1514131211109876543210
KEY[207:192]
wwwwwwwwwwwwwwww

Bits 31:0 KEY[223:192] : Cryptographic key, bits [223:192]

Refer to the AES_KEYR0 register for description of the KEY[255:0] bitfield.

23.7.16 AES key register 7 (AES_KEYR7)

Address offset: 0x3C

Reset value: 0x0000 0000

31302928272625242322212019181716
KEY[255:240]
wwwwwwwwwwwwwwww
1514131211109876543210
KEY[239:224]
wwwwwwwwwwwwwwww

Bits 31:0 KEY[255:224] : Cryptographic key, bits [255:224]

Refer to the AES_KEYR0 register for description of the KEY[255:0] bitfield.

Note: The key registers from 4 to 7 are used only when the key length of 256 bits is selected. They have no effect when the key length of 128 bits is selected (only key registers 0 to 3 are used in that case).

23.7.17 AES suspend registers (AES_SUSPxR)

Address offset: 0x040 + 0x4 * x, (x = 0 to 7)

Reset value: 0x0000 0000

These registers contain the complete internal register states of the AES processor when the AES processing of the current task is suspended to process a higher-priority task.

Upon suspend, the software reads and saves the AES_SUSPxR register contents (where x is from 0 to 7) into memory, before using the AES processor for the higher-priority task.

Upon completion, the software restores the saved contents back into the corresponding suspend registers, before resuming the original task.

Note: These registers are used only when GCM, GMAC, or CCM chaining mode is selected.

These registers can be read only when AES is enabled. Reading these registers while AES is disabled returns 0x0000 0000.

31302928272625242322212019181716
SUSP[31:16]
rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw
1514131211109876543210
SUSP[15:0]
rwrwrwrwrwrwrwrwrwrwrwrwrwrwrwrw

Bits 31:0 SUSP[31:0] : AES suspend

Upon suspend operation, this bitfield of the corresponding AES_SUSPxR register takes the value of one of internal AES registers.

23.7.18 AES register map

Table 143. AES register map and reset values

OffsetRegister313029282726252423222120191817161514131211109876543210
0x000AES_CRRes.Res.Res.Res.Res.Res.Res.Res.NPBLB[3:0]Res.KEYSIZERes.CHMOD[2]Res.GCMPH[1:0]DMAOUTENDMAINENERRIECCFIEERRCCCFCCHMOD[1:0]MODE[1:0]DATATYPE[1:0]EN
Reset value000000000000000000000
0x004AES_SRRes.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.BUSYWRERRRDERRCCF
Reset value0000
0x008AES_DINRDIN[31:0]
Reset value00000000000000000000000000000000
0x00CAES_DOUTRDOUT[31:0]
Reset value00000000000000000000000000000000
0x010AES_KEYR0KEY[31:0]
Reset value00000000000000000000000000000000
0x014AES_KEYR1KEY[63:32]
Reset value00000000000000000000000000000000
0x018AES_KEYR2KEY[95:64]
Reset value00000000000000000000000000000000
0x01CAES_KEYR3KEY[127:96]
Reset value00000000000000000000000000000000
0x020AES_IVR0IVI[31:0]
Reset value00000000000000000000000000000000
0x024AES_IVR1IVI[63:32]
Reset value00000000000000000000000000000000
0x028AES_IVR2IVI[95:64]
Reset value00000000000000000000000000000000
0x02CAES_IVR3IVI[127:96]
Reset value00000000000000000000000000000000
0x030AES_KEYR4KEY[159:128]
Reset value00000000000000000000000000000000
0x034AES_KEYR5KEY[191:160]
Reset value00000000000000000000000000000000
0x038AES_KEYR6KEY[223:192]
Reset value00000000000000000000000000000000
0x03CAES_KEYR7KEY[255:224]
Reset value00000000000000000000000000000000
0x040AES_SUSP0RSUSP[31:0]
Reset value00000000000000000000000000000000

Table 143. AES register map and reset values (continued)

OffsetRegister313029282726252423222120191817161514131211109876543210
0x044AES_SUSP1RSUSP[31:0]
Reset value000000000000000000000000000000000
0x048AES_SUSP2RSUSP[31:0]
Reset value000000000000000000000000000000000
0x04CAES_SUSP3RSUSP[31:0]
Reset value000000000000000000000000000000000
0x050AES_SUSP4RSUSP[31:0]
Reset value000000000000000000000000000000000
0x054AES_SUSP5RSUSP[31:0]
Reset value000000000000000000000000000000000
0x058AES_SUSP6RSUSP[31:0]
Reset value000000000000000000000000000000000
0x05CAES_SUSP7RSUSP[31:0]
Reset value000000000000000000000000000000000
0x060-0x3FFReservedRes.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.

Refer to Section 2.6 on page 72 for the register boundary addresses.