33. AES hardware accelerator (AES)

This section only applies to STM32U385/366/3C5 products.

33.1 AES introduction

The AES hardware accelerator (AES) encrypts or decrypts data in compliance with the advanced encryption standard (AES) defined by NIST.

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

AES has the possibility to load by hardware the key stored in SAES peripheral, under SAES control.

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

33.2 AES main features

• • Compliant with NIST FIPS publication 197 “ Advanced encryption standard (AES) ” (November 2001)
• • Encryption and decryption with multiple chaining modes:
  • – Electronic codebook (ECB) mode
  • – Cipher block chaining (CBC) mode
  • – Counter (CTR) mode
  • – Galois counter mode (GCM)
  • – Galois message authentication code (GMAC) mode
  • – Counter with CBC-MAC (CCM) mode
• • 128-bit data block processing, supporting cipher key lengths of 128-bit and 256-bit
  • – 51 or 75 clock cycle latency in ECB mode for processing one 128-bit block with, respectively, 128-bit or 256-bit key
• • Using dedicated key bus, optional key sharing with side-channel resistant SAES peripheral (shared-key mode), controlled by SAES
• • Integrated key scheduler to compute the last round key for ECB/CBC decryption
• • 256-bit of write-only registers for storing cryptographic keys (eight 32-bit registers)
• • 128-bit of registers for storing initialization vectors (four 32-bit registers)
• • 32-bit buffer for data input and output
• • Automatic data flow control supporting two direct memory access (DMA) channels, one for incoming data, one for processed data. Only single transfers are supported.
• • Data-swapping logic to support 1-, 8-, 16-, or 32-bit data

• • AMBA AHB slave peripheral, accessible through 32-bit word single accesses only. Other access types generate an AHB error, and other than 32-bit writes may corrupt the register content.
• • Possibility for software (in CPU mode only, not in DMA mode) to suspend a message if AES needs to process another message with a higher priority, then resume the original message

33.3 AES implementation

The devices have one AES peripheral, implemented as per the following table. It can use the key generated by the SAES peripheral. For comparison, the SAES peripheral is also included in the table.

Table 301. AES versus SAES features

1. X = supported.

33.4 AES functional description

33.4.1 AES block diagram

Figure 314 shows the block diagram of AES.

Figure 314. AES block diagram

33.4.2 AES internal signals

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

Table 302. AES internal input/output signals

33.4.3 AES reset and clocks

The AES peripheral is clocked by the AHB bus clock. It has a dedicated reset bit controlled through the RCC.

33.4.4 AES symmetric cipher implementation

The AES hardware accelerator (AES) is a 32-bit AHB peripheral that encrypts or decrypts 16-byte blocks of data using the advanced encryption standard (AES). It also implements a set of approved AES symmetric key security functions summarized in Table 303. Those functions can be certified NIST PUB 140-3.

Table 303. AES approved symmetric key functions

AES can be used directly by the CPU, or indirectly, using two DMA channels (one for the plaintext, one for the ciphertext).

It is possible to suspend then resume any AES processing, following the sequence described in Section 33.4.8 .

33.4.5 AES encryption or decryption typical usage

The following figure shows a typical operation for encryption or decryption.

Figure 315. Encryption/ decryption typical usage

graph TD
    Start([Start]) --> Init([Initialization])
    Init --> Dec{ECB or CBC decryption?}
    Dec -- Yes --> RoundKey([Round key preparation])
    Dec -- No --> DataAppend([Data append])
    RoundKey --> LastBlock{Last block?}
    DataAppend --> LastBlock
    LastBlock -- No --> DataAppend
    LastBlock -- Yes --> AllBytesValid{All bytes valid?}
    AllBytesValid -- No --> DataPadding([Data padding])
    AllBytesValid -- Yes --> Finalize([Finalize])
    DataPadding --> Chaining{ECB or CBC chaining?}
    Chaining -- Yes --> DataStealing([Data stealing])
    Chaining -- No --> Finalize
    DataStealing --> Finalize
    Finalize --> End([End])
  

Initialization

The AES peripheral is initialized according to the chaining mode. Refer to Section 33.4.9: AES basic chaining modes (ECB, CBC) and Section 33.4.10: AES counter (CTR) mode for details.

Data append

This section describes different ways of appending data for processing. For ECB or CBC chaining modes, refer to Section 33.4.7: AES ciphertext stealing and data padding if the size of data to process is not a multiple of 16 bytes. The last block management in these cases is more complex than what is described in this section.

Appending data using the CPU in polling mode

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

1. 1. Enable the AES peripheral when KEYVALID is set, by setting the EN bit of the AES_CR register (if not already done).
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_ISR register, then read the four data words from the AES_DOUTR register.
   3. c) Clear the CCF flag, by setting the CCF bit of the AES_ICR register.
   4. d) If the next processing block is the last block, pad (when applicable) the data with zeros to obtain a complete block, and specify the number of non-valid bytes (using NPBLB[3:0]) in case of GCM payload encryption or CCM payload decryption (otherwise the tag computation is wrong).
3. 3. As the data block just processed is the last block of the message, optionally discard the data that is not part of the message/payload, then disable the AES peripheral by clearing EN.

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[3:0] bitfield is not used in header phase of GCM, GMAC and CCM chaining modes.

Appending data using the CPU in interrupt mode

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_IER register.
2. 2. Enable the AES peripheral when KEYVALID is set, by setting EN (if not already done).
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 each 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 CCF bit of the AES_ICR register.
   3. c) If the next processing block is the last block of the message, pad (when applicable) the data with zeros to obtain a complete block, and specify the number of non-valid bytes (through NPBLB[3:0]) in case of GCM payload encryption or CCM payload decryption (otherwise the tag computation is wrong). Then proceed with point 4e).
   4. d) If the data block just processed is the last block of the message, optionally discard the data that are not part of the message/payload, then disable the AES peripheral by clearing EN 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. The NPBLB[3:0] bitfield is not used in the header phase of GCM, GMAC, and CCM chaining modes.

Appending data using DMA

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

1. 1. If the last block of the message to process is shorter than 16 bytes, prepare the last four-word data block 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 33.6: AES DMA requests . Configure the DMA controller so as to generate an interrupt on transfer completion. For GCM payload encryption or CCM payload decryption, the DMA transfer must not include the last four-word block if padded with zeros. The sequence described in Appending data using the CPU in polling mode must be used instead for this last block, because the NPBLB[3:0] bitfield must be set up before processing the block, for AES to compute a correct tag.
3. 3. Enable the AES peripheral when KEYVALID is set, by setting EN (if not already done).
4. 4. Enable DMA requests, by setting DMAINEN and DMAOUTEN.
5. 5. Upon DMA interrupt indicating the transfer completion, get the AES-processed data from the memory.

When appending data using DMA, the suspend/resume operation as described in Section 33.4.8 is not supported.

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.

The NPBLB[3:0] bitfield is not used in the header phase of GCM, GMAC, and CCM chaining modes.

33.4.6 AES authenticated encryption, decryption, and cipher-based message authentication

The following figure shows a typical operation for authenticated encryption or decryption, and for cipher-based message authentication.

graph TD
    Start([Start]) --> Init([Initialization])
    Init --> HeaderInit([Header phase init])
    HeaderInit --> HeaderDataAppend([Header data append])
    HeaderDataAppend --> LastBlockHeader{Last block?}
    LastBlockHeader -- No --> HeaderDataAppend
    LastBlockHeader -- Yes --> AllBytesValidHeader{All bytes valid?}
    AllBytesValidHeader -- No --> DataPaddingHeader([Data padding])
    AllBytesValidHeader -- Yes --> CipherAuth{cipher-based* authentication?}
    DataPaddingHeader --> CipherAuth
    CipherAuth -- Yes --> Finalization([Finalization])
    CipherAuth -- No --> PayloadInit([Payload phase init])
    PayloadInit --> PayloadDataAppend([Payload data append])
    PayloadDataAppend --> LastBlockPayload{Last block?}
    LastBlockPayload -- No --> PayloadDataAppend
    LastBlockPayload -- Yes --> AllBytesValidPayload{All bytes valid?}
    AllBytesValidPayload -- No --> DataPaddingPayload([Data padding])
    AllBytesValidPayload -- Yes --> Finalization
    DataPaddingPayload --> Finalization
    Finalization --> End([End])
  

Section 33.4.11: AES Galois/counter mode (GCM) and Section 33.4.13: AES counter with CBC-MAC (CCM) describe detailed sequences supported by AES.

Cipher-based message authentication flow omits the payload phase, as shown in the figure. Detailed sequence supported by AES is described in Section 33.4.12: AES Galois message authentication code (GMAC) .

33.4.7 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 (16 bytes), the application must use ciphertext stealing techniques 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 AES does not implement 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, in modes other than ECB or CBC, an incomplete input data block (that is, a block with input data shorter than 16 bytes) 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. Since AES does not implement automatic data padding operation to the last block , the application must follow the recommendation given in this document to manage messages the size of which is not a multiple of 16 bytes.

33.4.8 AES suspend and resume operations

A message can be suspended to process another message with a higher priority. When the higher-priority message is sent, the suspended message can resume. This applies to both encryption and decryption mode.

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

The suspend and resume operations are only supported when AES is used in CPU mode, not in DMA mode.

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

Figure 317. Example of suspend mode management

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

33.4.9 AES basic chaining modes (ECB, CBC)

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. When decrypting in ECB, a special key scheduling is required before processing the first block.

Figure 318 and Figure 319 describe the electronic codebook (ECB) chaining implementation in encryption and in decryption, respectively. To select ECB chaining mode, write CHMOD[2:0] with 0x0.

Figure 318. ECB encryption

Figure 319. ECB decryption

In CBC encryption 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. When decrypting in CBC, a special key scheduling is required before processing the first block.

Figure 320 and Figure 321 describe the cipher block chaining (CBC) implementation in encryption and in decryption, respectively. To select this chaining mode, write CHMOD[2:0] with 0x1.

Figure 320. CBC encryption

Figure 321. CBC decryption

For more details, refer to NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation .

ECB and CBC encryption process

This process is described in Section 33.4.5 , with the following sequence of events:

1. Disable the AES peripheral, by clearing EN.
2. Initialize the AES_CR register as follows:
   • Select ECB or CBC chaining mode (write CHMOD[2:0] with 0x0 or 0x1) in encryption mode (write MODE[1:0] with 0x0).
   • Configure the data type, through DATATYPE[1:0].
   • Configure the key size, through KEYSIZE.
   • Select the key mode, using KMOD[1:0]. If the key comes from the SAES peripheral, write KMOD[1:0] with 0x2, otherwise keep it at 0x0.
3. Write the initialization vector into the AES_IVRx registers if CBC mode is selected in the previous step.
4. Write the key into the AES_KEYRx registers if KMOD[1:0] is at 0x0. If KMOD[1:0] is at 0x2, the key is transferred from the SAES peripheral (see Section 33.4.14 ).
5. Wait until KEYVALID is set (the key loading completed).
6. Enable the AES peripheral, by setting EN.
7. Append cleartext data:
   1. If it is the second-last or the last block and the plaintext size of the message is not a multiple of 16 bytes, follow the guidance in Section 33.4.7 .
   2. Append the cleartext block into AES as described in Section 33.4.5 , then read the AES_DOUTR register four times to save the ciphertext block.
   3. Repeat the step b) until the third-last plaintext block is encrypted. For the last two blocks, follow the steps a) and b) .
8. Finalize the sequence: disable the AES peripheral, by clearing EN.

ECB/CBC decryption process

This process is described in Section 33.4.5 , with the following sequence of events:

1. 1. Disable the AES peripheral, by clearing EN.
2. 2. Initialize the AES_CR register as follows:
   • – Select the key derivation mode (write MODE[1:0] with 0x1). The CHMOD[2:0] bitfield is not significant during this operation.
   • – Configure the data type, through DATATYPE[1:0].
   • – Configure the key size, through KEYSIZE.
   • – Select the key mode, using KMOD[1:0]. If the key comes from the SAES peripheral, write KMOD[1:0] with 0x2, otherwise keep it at 0x0.
3. 3. Write the key into the AES_KEYRx registers if KMOD[1:0] is at 0x0. If KMOD[1:0] is at 0x2, the key is transferred from the SAES peripheral (see Section 33.4.14 ).
4. 4. Wait until KEYVALID is set (the key loading completed).
5. 5. Enable the AES peripheral, by setting EN. The peripheral immediately starts an AES round for key preparation.
6. 6. Wait until the CCF flag in the AES_ISR register is set.
7. 7. Clear the CCF flag, by setting the CCF bit of the AES_ICR register. The decryption key is available in the AES core and AES is disabled automatically.
8. 8. Select ECB or CBC chaining mode (write CHMOD[2:0] with 0x0 or 0x1) in decryption mode (write MODE[1:0] with 0x2). Do not change other parameters.
9. 9. Write the initialization vector into the AES_IVRx registers if CBC mode is selected in the previous step.
10. 10. Enable the AES peripheral, by setting EN.
11. 11. Append encrypted data:
    1. a) If it is the second-last or the last block and the ciphertext size of the message is not a multiple of 16 bytes, follow the guidance in Section 33.4.7 .
    2. b) Append the ciphertext block into AES as described in Section 33.4.5 , then read the AES_DOUTR register four times to save the cleartext block (MSB first).
    3. c) Repeat the step b ) until the third-last ciphertext block is decrypted. For the last two blocks, follow the steps a ) and b ).
12. 12. Finalize the sequence: disable the AES peripheral, by clearing EN.

Suspend/resume operations in ECB/CBC modes

The suspend and resume operations are only supported when AES is used in CPU mode, not in DMA mode.

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

1. 1. Wait until the CCF flag in the AES_ISR register is set (computation completed).
2. 2. Read four times the AES_DOUTR register to save the last processed block.
3. 3. Clear the CCF flag, by setting the CCF bit of the AES_ICR register.
4. 4. Save initialization vector registers (only required in CBC mode as the AES_IVRx registers are altered during the data processing).

1. 5. Disable the AES peripheral, by clearing EN.
2. 6. Save the AES_CR register and clear the key registers if they are not needed, to process the higher-priority message.

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

1. 1. Disable the AES peripheral, by clearing EN.
2. 2. Restore the AES_CR register (with correct KEYSIZE) then restore the AES_KEYRx registers. If KMOD[1:0] is at 0x2, the key must be transferred again from the SAES peripheral (see Section 33.4.14 ).
3. 3. Prepare the decryption key, as described in ECB/CBC decryption process (only required for ECB or CBC decryption).
4. 4. Restore the AES_IVRx registers, using the saved configuration (only required in CBC mode).
5. 5. Enable the AES peripheral, by setting EN.

Note: It is not required to save the key registers as the application knows the original key.

33.4.10 AES counter (CTR) mode

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. Unlike with ECB and CBC modes, no key scheduling is required for the CTR decryption since the AES core is always used in encryption mode.

A typical message construction in CTR mode is given in Figure 322 .

Figure 322. Message construction in CTR mode

The structure of this message is:

• • A 16-byte initial counter block (ICB), composed of two distinct fields:
  • – Initialization vector (IV) : a 96-bit value that must be unique for each encryption cycle with a given key.
  • – Counter : a 32-bit big-endian integer that is incremented each time a block processing is completed. The initial value of the counter must be set to 1.
• • The plaintext P is encrypted as ciphertext C, with a known length. This length can be non-multiple of 16 bytes, in which case a plaintext padding is required.

For more details, refer to NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation .

CTR encryption and decryption

Figure 323 describes the counter (CTR) chaining implementation in the AES peripheral (encryption). To select this chaining mode, write CHMOD[2:0] with 0x2.

Figure 323. CTR encryption

Initialization vectors in AES must be initialized as shown in Table 304.

Table 304. Counter mode initialization vector definition

CTR encryption and decryption process

This process is described in Section 33.4.5, with the following sequence of events:

1. Disable the AES peripheral, by clearing EN.
2. Initialize the AES_CR register:
   • Select CTR chaining mode (write CHMOD[2:0] with 0x2) in encryption or decryption mode (write MODE[1:0] with 0x0 or 0x2).
   • Configure the data type, through DATATYPE[1:0].
   • Configure the key size, through KEYSIZE.
   • Select the key mode, using KMOD[1:0]. If the key comes from the SAES peripheral, write KMOD[1:0] with 0x2, otherwise keep it at 0x0.
3. Write the initialization vector into the AES_IVRx registers according to Table 304.
4. Write the key into the AES_KEYRx registers if KMOD[1:0] is at 0x0. If KMOD[1:0] is at 0x2, the key is transferred from the SAES peripheral (see Section 33.4.14).
5. Wait until KEYVALID is set (the key loading completed).
6. Enable the AES peripheral, by setting EN.

1. 7. Append data:
   1. a) If it is the last block and the plaintext (encryption) or ciphertext (decryption) size in the block is less than 16 bytes, pad the remainder of the block with zeros.
   2. b) Append the data block into AES as described in Section 33.4.5 , then read the AES_DOUTR register four times to save the resulting block (MSB first).
   3. c) Repeat the step b) until the second-last block is processed. For the last block of plaintext (encryption only), follow the steps a) and b) . For the last block, discard the bits that are not part of the message when the last block is smaller than 16 bytes.
2. 8. Finalize the sequence: disable the AES peripheral, by clearing EN.

Suspend/resume operations in CTR mode

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

The suspend and resume operations are only supported when AES is used in CPU mode, not in DMA mode.

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

33.4.11 AES Galois/counter mode (GCM)

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).

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. The following figure shows a typical message construction in GCM mode.

Figure 324. Message construction in GCM

The message has the following structure:

• • 16-byte initial counter block (ICB) , composed of two distinct fields:
  • – Initialization vector (IV) : a 96-bit value that must be unique for each encryption cycle with a given key. The GCM standard supports IVs with less than 96 bits, but in this case strict rules apply.
  • – Counter : a 32-bit big-endian integer that is incremented each time a block processing is completed. According to NIST specification, the counter value is 0x2 when processing the first block of payload.
• • Authenticated header AAD (also known as additional authentication data) has a known length \( \text{Len}(A) \) that may be a non-multiple of 16 bytes, and must not exceed \( 2^{64} - 1 \) bits. This part of the message is only authenticated, not encrypted.
• • Plaintext message P is both authenticated and encrypted as ciphertext C, with a known length \( \text{Len}(P) \) that may be non-multiple of 16 bytes, and cannot exceed \( 2^{32} - 2 \) 16-byte blocks.
• • Last block contains the AAD header length (bits [32:63]) and the payload length (bits [96:127]) information, as shown in Table 306 .

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.

For more details, refer to NIST Special Publication 800-38D, Recommendation for Block Cipher Modes of Operation - Galois/Counter Mode (GCM) and GMAC .

Figure 325 describes the GCM chaining implementation in the AES peripheral (encryption). To select this chaining mode, write CHMOD[2:0] with 0x3.

Figure 325. GCM authenticated encryption

The first counter block (CB1) is derived from the initial counter block ICB by the application software, as defined in Table 305.

Table 305. Initialization of IV registers in GCM mode

The last block of a GCM message contains the AAD header length and the payload length information, as shown in Table 306.

Table 306. GCM last block definition

GCM encryption and decryption process

This process is described in Section 33.4.6 , with the following sequence of events:

GCM initialize

1. 1. Disable the AES peripheral, by clearing EN.
2. 2. Initialize the AES_CR register:
   • – Select GCM chaining mode (write CHMOD[2:0] with 0x3) in encryption or decryption mode (write MODE[1:0] with 0x0 or 0x2). Do not write MODE[1:0] with 0x1.
   • – Configure the data type, through DATATYPE[1:0]
   • – Configure the key size, through KEYSIZE.
   • – Select the key mode, using KMOD[1:0]. If the key comes from the SAES peripheral, write KMOD[1:0] with 0x2, otherwise keep it at 0x0.
   • – Select the GCM initialization phase, by writing CPHASE[1:0] with 0x0.
3. 3. Write the initialization vector in AES_IVRx registers according to Table 305 .
4. 4. Write the key into the AES_KEYRx registers if KMOD[1:0] is at 0x0. If KMOD[1:0] is at 0x2, the key is transferred from the SAES peripheral (see Section 33.4.14 ).
5. 5. Wait until KEYVALID is set (the key loading completed).
6. 6. Set EN to start the calculation of the hash key. EN is automatically cleared when the calculation is completed.
7. 7. Wait until the CCF flag is set in the AES_ISR register, indicating that the GCM hash subkey (H) computation is completed.
8. 8. Clear the CCF flag by setting the CCF bit of the AES_ICR register.

GCM header phase

1. 9. Initialize header phase:
   1. a) Select the GCM header phase, by writing 0x1 to CPHASE[1:0]. Do not change the other configurations written during GCM initialization.
   2. b) Enable the AES peripheral, by setting EN.
2. 10. Append header data:
   1. a) If it is the last block and the AAD in the block is smaller than 16 bytes, pad the remainder of the block with zeros.
   2. b) Append the data block into AES as described in Section 33.4.5 .
   3. c) Repeat the step b) until the second-last AAD data block is processed. For the last block, follow the steps a) and b) .

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

No data are read during header phase.

GCM payload phase

1. 11. Initialize payload phase:
   1. a) Select the GCM payload phase, by writing CPHASE[1:0] with 0x2. Do not change the other configurations written during GCM initialization.
   2. b) If the header phase is skipped, enable the AES peripheral by setting EN.

1. 12. Append payload data:
   1. a) If it is the last block and the message in the block is smaller than 16 bytes, pad the remainder of the block with zeros.
   2. b) Append the data block into AES as described in Section 33.4.5 , then read the AES_DOUTR register four times to save the resulting block
   3. c) Repeat the step b) until the second-last plaintext block is encrypted or until the last block of ciphertext is decrypted. For the last block of plaintext (encryption only), follow the steps a) and b) . For the last block, discard the bits that are not part of the payload when the last block is smaller than 16 bytes.

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

GCM finalization

1. 13. Select the GCM final phase, by writing CPHASE[1:0] with 0x3. Do not change the other configurations written during GCM initialization.
2. 14. Write the final GCM block into the AES_DINR register. It is the concatenated AAD bit and payload bit lengths, as shown in Table 306 .
3. 15. Wait until the CCF flag in the AES_ISR register is set.
4. 16. Get the GCM authentication tag, by reading the AES_DOUTR register four times.
5. 17. Clear the CCF flag, by setting the CCF bit of the AES_ICR register.
6. 18. Disable the AES peripheral, by clearing EN. If it is an authenticated decryption, compare the generated tag with the expected tag passed with the message.

Note: In the final phase, data are 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

The suspend and resume operations are only supported when AES is used in CPU mode, not in DMA mode.

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

1. 1. Wait until the CCF flag in the AES_ISR register is set (computation completed).
2. 2. In the payload phase, read four times the AES_DOUTR register to save the last-processed block.
3. 3. Clear the CCF flag of the AES_ISR register, by setting the CCF bit of the AES_ICR register. When GCM encryption payload phase is selected, verify that BUSY is cleared in AES_SR, to ensure that GF2mul hash function is completed.
4. 4. Save the AES_SUSPRx registers in the memory.
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 EN.
7. 7. Save the current AES_CR configuration in the memory. Key registers do not need to be saved as the original key value is known by the application.

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

1. 1. Disable the AES peripheral, by clearing EN.
2. 2. Write the suspend register values, previously saved in the memory, back into their corresponding AES_SUSPRx registers.
3. 3. 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.
4. 4. Restore the initial setting values in the AES_CR and AES_KEYRx registers if KMOD[1:0] is at 0x0. If KMOD[1:0] is at 0x2, the key is transferred from the SAES peripheral (see Section 33.4.14 ).
5. 5. Enable the AES peripheral, by setting EN.

33.4.12 AES Galois message authentication code (GMAC)

The Galois message authentication code (GMAC) allows the authentication of a plaintext, generating the corresponding tag information (also known as message authentication code).

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). The following figure shows typical message construction for GMAC.

Figure 326. Message construction in GMAC mode

For more details, refer to NIST Special Publication 800-38D, Recommendation for Block Cipher Modes of Operation - Galois/Counter Mode (GCM) and GMAC .

Figure 327 describes the GMAC chaining implementation in the AES peripheral. To select this chaining mode, write CHMOD[2:0] with 0x3.

Figure 327. GMAC authentication mode

The GMAC algorithm corresponds to the GCM algorithm applied on a message that only contains 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.

33.4.13 AES counter with CBC-MAC (CCM)

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 counter mode processing. It uses cipher block chaining technique to generate the message authentication code. This is commonly called CBC-MAC.

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

The following figure shows typical message construction for CCM.

Figure 328. Message construction in CCM mode

The structure of the message is:

• • 16-byte first authentication block (B0) , composed of three distinct fields:
  • – Q : a bit string representation of the octet length of P (Len(P))
  • – Nonce (N) : a single-use value (that is, a new nonce must be assigned to each new communication) of Len(N) size. The sum Len(N) + Len(P) must be equal to 15 bytes.
  • – Flags : most significant octet containing four flags for control information, as specified by the standard. It contains two 3-bit strings to encode the values t (MAC length expressed in bytes) and Q (plaintext length such that \( \text{Len}(P) < 2^{8Q} \) bytes). The counter blocks range associated to Q is equal to \( 2^{8Q-4} \) , that is, if the maximum value of Q is 8, the counter blocks used in cipher must be on 60 bits.
• • 16-byte blocks (B) associated to the associated data (A).
  This part of the message is only authenticated, not encrypted. This section has a known length Len(A) that can be a non-multiple of 16 bytes (see Figure 328). The standard also states that, on MSB bits of the first message block (B1), 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 Len(P). This length can be a non-multiple of 16 bytes (see Figure 328).
• • Encrypted MAC (T) of length Len(T) appended to the ciphertext C of overall length 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 (Len(N) = 56 bits or 7 bytes)
A: 00010203 04050607 (Len(A) = 64 bits or 8 bytes)
P: 20212223 (Len(P) = 32 bits or 4 bytes)
T: 6084341B (Len(T) = 32 bits or t = 4)
B0: 4F101112 13141516 00000000 00000004
B1: 00080001 02030405 06070000 00000000
B2: 20212223 00000000 00000000 00000000
CTR0: 0710111213 141516 00000000 00000000
CTR1: 0710111213 141516 00000000 00000001

For more details, refer to NIST Special Publication 800-38C, Recommendation for Block Cipher Modes of Operation - The CCM Mode for Authentication and Confidentiality .

Figure 329 describes the CCM chaining implementation in the AES peripheral (encryption). To select this chaining mode, write CHMOD[2:0] with 0x4.

Figure 329. CCM mode authenticated encryption

The first block of a CCM message (B0) must be prepared by the application as defined in Table 307.

1. 1. The five most significant bits are cleared (flag bits).
2. 2. Q length bits are cleared, except for the bit 0 that is set.

AES supports counters up to 64 bits, as specified by NIST.

CCM encryption and decryption process

This process is described in Section 33.4.6 , with the following sequence of events:

CCM initialize

1. 1. Disable the AES peripheral, by clearing EN.
2. 2. Initialize the AES_CR register:
   • – Select CCM chaining mode (write CHMOD[2:0] with 0x4) in encryption or decryption mode (write MODE[1:0] with 0x0 or 0x2). Do not write MODE[1:0] with 0x1.
   • – Configure the data type, through DATATYPE[1:0]
   • – Configure the key size, through KEYSIZE.
   • – Select the key mode, using KMOD[1:0]. If the key comes from the SAES peripheral, write KMOD[1:0] with 0x2, otherwise keep it at 0x0.
   • – Select the CCM initialization phase, by writing CPHASE[1:0] with 0x0.
3. 3. Write the B0 data in AES_IVRx registers according to Table 307 .
4. 4. Write the key into the AES_KEYRx registers if KMOD[1:0] is at 0x0. If KMOD[1:0] is at 0x2, the key is transferred from the SAES peripheral (see Section 33.4.14 ).
5. 5. Wait until KEYVALID is set (the key loading completed).
6. 6. Set EN to start the first mask calculation. The EN bit is automatically cleared when the calculation is completed.
7. 7. Wait until the CCF flag in the AES_ISR register is set.
8. 8. Clear the CCF flag, by setting the CCF bit of the AES_ICR register.

CCM header phase

1. 9. Initialize header phase:
   1. a) Prepare the first block of the (B1) data associated with the message, in accordance with CCM chaining rules.
   2. b) Select the CCM header phase, by writing CPHASE[1:0] with 0x1. Do not change the other configurations written during the CCM initialization.
   3. c) Enable the AES peripheral, by setting EN.
2. 10. Append header data:
   1. a) If it is the last block and the associated data in the block is smaller than 16 bytes, pad the remainder of the block with zeros.
   2. b) Append the data block into AES as described in Section 33.4.5 .
   3. c) Repeat the step b) until the second-last associated data block is processed. For the last block, follow the steps a) and b) .

Note: This phase can be skipped if there is no associated data, that is, \( Len(A) = 0 \)
No data are read during the header phase.

CCM payload phase

1. 11. Initialize payload phase:
   1. a) Select the CCM payload phase, by writing CPHASE[1:0] with 0x2. Do not change the other configurations written during the CCM initialization.
   2. b) If the header phase is skipped, enable the AES peripheral, by setting EN.
2. 12. Append payload data:
   1. a) In encryption only, if it is the last block and the plaintext in the block is smaller than 16 bytes, pad the remainder of the block with zeros.
   2. b) Append the data block into AES as described in Section 33.4.5 , then read the AES_DOUTR register four times to save the resulting block.
   3. c) Repeat the step b) until the second-last plaintext block is encrypted or until the last block of ciphertext is decrypted. For the last block of plaintext (encryption only), follow the steps a) and b). For the last block, discard the bits that are not part of the payload when the last block is smaller than 16 bytes.

Note: This phase can be skipped if there is no payload, that is, \( Len(P) = 0 \) or \( Len(C) = Len(T) \) .
Remove \( LSB_{Len(T)}(C) \) encrypted tag information when decrypting ciphertext C.

CCM finalization

1. 13. Select the CCM final phase, by writing CPHASE[1:0] with 0x3. Do not change the other configurations written during the CCM initialization.
2. 14. Wait until CCF flag in the AES_ISR register is set.
3. 15. Get the CCM authentication tag, by reading the AES_DOUTR register four times.
4. 16. Clear the CCF flag, by setting the CCF bit of the AES_ICR register.
5. 17. Disable the AES peripheral, by clearing EN. If it is an authenticated decryption, compare the generated tag with the expected tag passed with the message. Mask the authentication tag output with tag length to obtain a valid tag.

Note: In the final phase, swapping is applied to tag data read from AES_DOUTR register.
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 and resume operations in CCM mode

The suspend and resume operations are only supported when AES is used in CPU mode, not in DMA mode.

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

1. 1. Wait until the CCF flag of the AES_ISR register is set (computation completed).
2. 2. In the payload phase, read four times the AES_DOUTR register to save the last-processed block.
3. 3. Clear the CCF flag in the AES_ISR register, by setting the CCF bit of the AES_ICR register.
4. 4. Save the AES_SUSPRx registers in the memory.
5. 5. Save the IV registers as they are altered during the data processing.
6. 6. Disable the AES peripheral, by clearing EN.

1. 7. Save the current AES_CR configuration in the memory. Key registers do not need to be saved as the original key value is known by the application.

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

1. 1. Disable the AES peripheral, by clearing EN.
2. 2. Write the suspend register values, previously saved in the memory, back into their corresponding AES_SUSPRx registers.
3. 3. Restore AES_IVRx registers using the saved configuration.
4. 4. Restore the initial setting values in the AES_CR and AES_KEYRx registers if KMOD[1:0] is at 0x0. If KMOD[1:0] is at 0x2, the key must be transferred again from the SAES peripheral (see Section 33.4.14 ).
5. 5. Enable the AES peripheral, by setting EN.

33.4.14 AES key sharing with secure AES co-processor

The AES peripheral can use the SAES peripheral as security co-processor. The secure application prepares the key in the robust SAES peripheral and when it is ready, the AES application can load this prepared key through a dedicated hardware key bus.

The recommended sequence is described hereafter and in the section SAES operations with shared keys in the SAES section of this document.

1. 1. In SAES peripheral, the application encrypts (wraps) the key to share in Shared-key mode (KMOD[1:0] at 0x2).
2. 2. Each time the shared key is required in AES peripheral, the application decrypts it in the SAES peripheral in Shared-key mode (KMOD[1:0] at 0x2).
3. 3. Once the shared key is decrypted (unwrapped) and loaded in SAES_KEYRx registers it can be shared with AES. To load the shared key in AES, the application sets KEYSIZE as appropriate and writes KMOD[1:0] with 0x2. When KEYVALID is cleared, the key is automatically transferred by hardware into the AES_KEYRx registers and the BUSY flag in the AES_SR register set.
4. 4. Once the key transfer is completed, the BUSY flag is cleared and the KEYVALID flag set in the AES_SR register. If KEYVALID is not set when BUSY bit is cleared, or if the KEIF flag is set in the AES_ISR register, either the KEYSIZE value is incorrect or an unexpected event occurred during the transfer (such as DPA error, tamper event or KEYVALID cleared before the end of the transfer). When such errors occur, reset both peripherals through their IPRST bits and restart the whole key sharing process.

When the key sharing sequence is completed, the AES is initialized with a valid, shared key. The application can then process data in normal key mode, by writing KMOD[1:0] with 0x0.

Note: This sequence in AES peripheral can be run multiple times (for example, to manage a suspend/resume situation), as long as SAES peripheral is unused and duly remains in key sharing state.

33.4.15 AES data registers and data swapping

Data input and output

A 16-byte data block enters 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 16-byte data block is retrieved from the AES peripheral with four successive 32-bit word reads of 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 four 32-bit words of a 16-byte data block must be stored in the memory consecutively and in big-endian order, that is, with the most significant word on the lowest address. See Table 308 “no swapping” option for details.

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 DATATYPE[1:0]. The selection applies to both AES input and output.

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

The AES data swapping feature is summarized in Table 308 and Figure 330 .

Table 308. AES data swapping example

Table 308. AES data swapping example (continued)

Figure 330. 128-bit block construction according to the data type

Data padding

Figure 330 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:

• • 84 message bits, with DATATYPE[1:0] = 0x0
• • 48 message bits, with DATATYPE[1:0] = 0x1
• • 56 message bits, with DATATYPE[1:0] = 0x2
• • 34 message bits, with DATATYPE[1:0] = 0x3

33.4.16 AES key registers

The eight AES_KEYRx write-only registers store the encryption or decryption key information, as shown on Table 309. Reads are not allowed for security reason.

Note: In memory and in AES key registers, keys are stored in little-endian format, with most significant byte on the highest address.

Table 309. Key endianness in AES_KEYRx registers (128/256-bit keys)

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

Write operations to the AES_KEYRx registers are ignored when AES peripheral is enabled (EN bit set). The application must check this before modifying key registers.

The entire key must be written before starting an AES computation.

In normal key mode (KMOD[1:0] at 0x0), the key registers must always be written in either ascending or descending order. The write sequence becomes:

• • AES_KEYRx (x = 0 to 3 or x=3 to 0) for KEYSIZE cleared
• • AES_KEYRx (x = 0 to 7 or x=7 to 0) for KEYSIZE set

Note: KEYSIZE must be written before the key.

As soon as the first key register is written, the KEYVALID flag is cleared. Once the key registers writing sequence is completed, KEYVALID is set and EN becomes writable. If an error occurs, KEYVALID is cleared and KEIF set (see Section 33.4.18).

33.4.17 AES initialization vector registers

The four AES_IVRx registers store the initialization vector (IV) information, as shown in Table 310. They can only be written if the AES peripheral is disabled (EN cleared).

Note: In memory and in AES IV registers, initialization vectors are stored in little-endian format, with most significant byte on the highest address.

Table 310. IVI bitfield spread over AES_IVRx registers

Initialization vector information depends on the chaining mode selected. When used, AES_IVRx registers are updated upon each AES computation cycle (useful for managing suspend mode).

The initialization vector registers are not affected by the data swapping feature controlled through DATATYPE[1:0].

33.4.18 AES error management

The AES peripheral manages the errors described in this section.

Read error flag (RDERRF)

Unexpected read attempt of the AES_DOUTR register returns zero, setting the RDERRF flag and the RWEIF flag. RDERRF is triggered during the computation phase or during the input phase.

Note: AES is not disabled when RDERRF rises and it continues processing.

An interrupt is generated if the RWEIE bit is set. For more details, refer to Section 33.5: AES interrupts .

The RDERRF and RWEIF flags are cleared by setting the RWEIF bit of the AES_ICR register.

Write error flag (WRERRF)

Unexpected write attempt of the AES_DINR register is ignored, setting the WRERRF and the RWEIF flags. WRERRF is triggered during the computation phase or during the output phase.

Note: AES is not disabled when WRERRF rises and it continues processing.

An interrupt is generated if the RWEIE bit is set. For more details, refer to Section 33.5: AES interrupts .

The WRERRF and RWEIF flags are cleared by setting the RWEIF bit of the AES_ICR register.

Key error interrupt flag (KEIF)

There are multiple sources of errors that set the KEIF flag of the AES_ISR register and clear the KEYVALID bit of the AES_SR register:

• • Key writing sequence error: triggered upon detecting an incorrect sequence of writing key registers. See Section 33.4.16: AES key registers for details.
• • Key sharing size mismatch error: triggered when KMOD[1:0] is at 0x2 and KEYSIZE in AES peripheral does not match KEYSIZE in SAES peripheral.

• • Key sharing error: triggered upon failing transfer of SAES shared key to AES peripheral. See Section 33.4.14: AES key sharing with secure AES co-processor for details.

The KEIF flag is cleared with corresponding bit of the AES_ICR register. An interrupt is generated if the KEIE bit of the AES_IER register is set. For more details, refer to Section 33.5: AES interrupts .

Upon a key sharing error, reset both AES and SAES peripherals through the IPRST bit of their corresponding control register, then restart the key sharing sequence.

Note: For any key error, clear KEIF flag prior to disabling and re-configuring AES.

33.5 AES interrupts

There are multiple individual maskable interrupt sources generated by the AES peripheral to signal the following events:

• • computation completed (CCF)
• • read error (RDERRF)
• • write error (WRERRF)
• • key error (KEIF)

See Section 33.4.18: AES error management for details on AES errors.

These sources are combined into a common interrupt signal from the AES peripheral that connects to the Cortex® CPU interrupt controller. Application can enable or disable AES interrupt sources individually by setting/clearing the corresponding enable bit of the AES_IER register.

The status of the individual maskable interrupt sources can be read from the AES_ISR register. They are cleared by setting the corresponding bit of the AES_ICR register.

Table 311 gives a summary of the available features.

Table 311. AES interrupt requests

1. Bit of the AES_ICR register.

2. Flag of the AES_SR register, mirrored by the flag RWEIF of the AES_ISR register.

33.6 AES DMA requests

The AES peripheral provides an interface to connect to the DMA (direct memory access) controller. The DMA operation is controlled through the DMAINEN and DMAOUTEN bits of the AES_CR register. When key derivation is selected (MODE[1:0] is at 0x1), setting those bits has no effect.

AES only supports single DMA requests.

Suspend and resume operations are not supported in DMA mode.

Detailed usage of DMA with AES can be found in Appending data using DMA subsection of Section 33.4.5: AES encryption or decryption typical usage .

Data input using DMA

Setting DMAINEN enables DMA writing into AES. AES then initiates, during the input phase, a set of single DMA requests for each 16-byte data block to write to the AES_DINR register (quadruple 32-bit word, MSB first).

Note: According to the algorithm and the mode selected, special padding / ciphertext stealing might be required (see Section 33.4.7 ).

Data output using DMA

Setting DMAOUTEN enables DMA reading from AES. AES then initiates, during the output phase, a set of single DMA requests for each 16-byte data block to read from the AES_DOUTR register (quadruple 32-bit word, MSB first).

After the output phase, at the end of processing of a 16-byte data block, AES switches automatically to a new input phase for the next data block, if any.

In DMA mode, 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 managing the data transfers by software.

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

Stopping DMA transfers

All DMA request signals are de-asserted when AES is disabled (EN cleared) or the DMA enable bit (DMAINEN for input data, DMAOUTEN for output data) is cleared.

33.7 AES processing latency

The following tables provide the 16-byte data block processing latency per operating mode.

Table 312. Processing latency for ECB, CBC and CTR

1. Excluding key preparation time (ECB and CBC only).

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

33.8 AES registers

The registers are accessible through 32-bit word single accesses only. Other access types generate an AHB error, and other than 32-bit writes may corrupt the register content.

33.8.1 AES control register (AES_CR)

Address offset: 0x000

Reset value: 0x0000 0000

Bit 31 IPRST : AES peripheral software reset

Setting the bit resets the AES peripheral, putting all registers to their default values, except the IPRST bit itself. Hence, any key-relative data are lost. For this reason, it is recommended to set the bit before handing over the AES to a less secure application.

The bit must be kept low while writing any configuration registers.

Bits 30:26 Reserved, must be kept at reset value.

Bits 25:24 KMOD[1:0] : Key mode selection

The bitfield defines how the AES key can be used by the application. KEYSIZE must be correctly initialized when setting KMOD[1:0] different from zero.

0x0: Normal key mode. Key registers are freely usable.

0x2: Shared key mode. If shared key mode is properly initialized in SAES peripheral, the AES peripheral automatically loads its key registers with the data stored in the SAES key registers. The key value is available in AES key registers when BUSY bit is cleared and KEYVALID is set in the AES_SR register. Key error flag KEIF is set otherwise in the AES_ISR register.

Others: Reserved

Attempts to write the bitfield are ignored when BUSY is set, as well as when EN is set before the write access and it is not cleared by that write access.

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

This padding information must be filled by software before processing the last block of GCM payload encryption or CCM payload decryption, otherwise authentication tag computation is incorrect.

0x0: All bytes are valid (no padding)

0x1: Padding for the last LSB byte

...

0xF: Padding for the 15 LSB bytes of last block.

Bit 19 Reserved, must be kept at reset value.

This bitfield defines the key length in bits of the key used by AES.

0: 128-bit

1: 256-bit

Attempts to write the bit are ignored when BUSY is set, as well as when the EN 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.

This bitfield selects the phase, applicable only with GCM, GMAC or CCM chaining modes.

0x0: Initialization phase

0x1: Header phase

0x2: Payload phase

0x3: Final phase

This bit enables automatic generation of DMA requests during the data phase, for outgoing data transfers from AES via DMA.

0: Disable

1: Enable

Setting this bit is ignored when MODE[1:0] is at 0x1 (key derivation).

This bit enables automatic generation of DMA requests during the data phase, for incoming data transfers to AES via DMA.

0: Disable

1: Enable

Setting this bit is ignored when MODE[1:0] is at 0x1 (key derivation).

Bits 10:7 Reserved, must be kept at reset value.

This bitfield selects the AES chaining mode:

0x0: Electronic codebook (ECB)

0x1: Cipher-block chaining (CBC)

0x2: Counter mode (CTR)

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

0x4: Counter with CBC-MAC (CCM)

others: Reserved

Attempts to write the bitfield are ignored when BUSY is set, as well as when EN is set before the write access and it is not cleared by that write access.

This bitfield selects the AES operating mode:

0x0: Encryption

0x1: Key derivation (or key preparation), for ECB/CBC decryption only

0x2: Decryption

0x3: Reserved

Attempts to write the bitfield are ignored when BUSY is set, as well as when EN is set before the write access and it is not cleared by that write access.

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. This swapping is defined in Section 33.4.15: AES data registers and data swapping .

0x0: No swapping (32-bit data).

0x1: Half-word swapping (16-bit data)

0x2: Byte swapping (8-bit data)

0x3: Bit-level swapping

Attempts to write the bitfield are ignored when BUSY is set, as well as when EN is set before the write access and it is not cleared by that write access.

This bit enables/disables the AES peripheral.

0: Disable

1: Enable

At any moment, clearing then setting the bit re-initializes the AES peripheral. When KMOD[1:0] is different from 0x0, using IPRST bit is recommended instead.

This bit is automatically cleared by hardware upon the completion of the key preparation (MODE[1:0] at 0x1) and upon the completion of GCM/GMAC/CCM initialization phase.

• – The bit cannot be set as long as KEYVALID is cleared

33.8.2 AES status register (AES_SR)

Address offset: 0x004

Reset value: 0x0000 0000

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

This bit is set by hardware when the key of size defined by KEYSIZE is loaded in AES_KEYRx key registers.

0: Key not valid

1: Key valid

The EN bit can only be set when KEYVALID is set.

In normal mode when KMOD[1:0] is at zero, the key must be written in the key registers in the correct sequence, otherwise the KEIF flag is set and KEYVALID remains cleared.

When KMOD[1:0] is different from zero, the BUSY flag is automatically set by AES. When the key is loaded successfully, BUSY is cleared and KEYVALID set. Upon an error, KEIF is usually set, BUSY cleared and KEYVALID remains cleared.

If set, KEIF must be cleared through the AES_ICR register, otherwise KEYVALID cannot be set. See the KEIF flag description for more details.

For further information on key loading, refer to Section 33.4.16: AES key registers .

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

Bit 3 BUSY : Busy

This flag indicates whether AES is idle or busy.

0: Idle

1: Busy

AES is flagged as idle when disabled (when EN is low) or when the last processing is completed.

AES is flagged as busy when processing a block data, preparing a key (ECB or CBC decryption only), or transferring a shared key from the SAES peripheral.

When GCM encryption payload phase is selected, this flag must be at zero before suspending current process to manage a higher-priority message.

Bit 2 WRERRF : Write error flag

This bit is set when an unexpected write to the AES_DINR register occurred. When set WRERRF bit has no impact on the AES operations.

0: No error

1: Unexpected write to AES_DINR register occurred during computation or data output phase.

The flag setting generates an interrupt if the RWEIE bit of the AES_IER register is set.

The flag is cleared by setting the RWEIF bit of the AES_ICR register.

Bit 1 RDERRF : Read error flag

This bit is set when an unexpected read to the AES_DOUTR register occurred. When set RDERRF bit has no impact on the AES operations.

0: No error

1: Unexpected read to AES_DOUTR register occurred during computation or data input phase.

The flag setting generates an interrupt if the RWEIE bit of the AES_IER register is set.

The flag is cleared by setting the RWEIF bit of the AES_ICR register.

Bit 0 Reserved, must be kept at reset value.

33.8.3 AES data input register (AES_DINR)

Address offset: 0x008

Reset value: 0x0000 0000

Bits 31:0 DIN[31:0] : Data input

A four-fold sequential write to this bitfield during the Input phase results in writing a complete 16-bytes 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 16-bytes input buffer.

Reads return zero.

33.8.4 AES data output register (AES_DOUTr)

Address offset: 0x00C

Reset value: 0x0000 0000

Bits 31:0 DOUT[31:0] : Data output

This read-only bitfield fetches a 32-bit output buffer. A four-fold sequential read of this bitfield, upon the computation completion (CCF flag set), virtually reads a complete 16-byte 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].

33.8.5 AES key register 0 (AES_KEYR0)

Address offset: 0x010

Reset value: 0x0000 0000

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

These are bits [31:0] of the write-only bitfield KEY[255:0] AES encryption or decryption key, depending on the MODE[1:0] bitfield of the AES_CR register.

Writes to AES_KEYRx registers are ignored when AES is enabled (EN bit set). When the key comes from the SAES peripheral (KMOD[1:0] at 0x2), writes to key registers are also ignored and they result in setting the KEIF bit of the AES_ISR register.

With KMOD[1:0] at 0x0, a special writing sequence is required. In this sequence, any valid write to AES_KEYRx register clears the KEYVALID flag except for the sequence-completing write that sets it. Also refer to the description of the KEYVALID flag in the AES_SR register.

33.8.6 AES key register 1 (AES_KEYR1)

Address offset: 0x014

Reset value: 0x0000 0000

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 and for information relative to writing AES_KEYRx registers.

33.8.7 AES key register 2 (AES_KEYR2)

Address offset: 0x018

Reset value: 0x0000 0000

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 and for information relative to writing AES_KEYRx registers.

33.8.8 AES key register 3 (AES_KEYR3)

Address offset: 0x01C

Reset value: 0x0000 0000

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 and for information relative to writing AES_KEYRx registers.

33.8.9 AES initialization vector register 0 (AES_IVR0)

Address offset: 0x020

Reset value: 0x0000 0000

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

AES_IVRx registers store the 128-bit initialization vector or the nonce, depending on the chaining mode selected. This value is updated by hardware after each computation round (when applicable). Write to this register is ignored when EN bit is set in AES_CR register

33.8.10 AES initialization vector register 1 (AES_IVR1)

Address offset: 0x024

Reset value: 0x0000 0000

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.

33.8.11 AES initialization vector register 2 (AES_IVR2)

Address offset: 0x028

Reset value: 0x0000 0000

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.

33.8.12 AES initialization vector register 3 (AES_IVR3)

Address offset: 0x02C

Reset value: 0x0000 0000

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.

33.8.13 AES key register 4 (AES_KEYR4)

Address offset: 0x030

Reset value: 0x0000 0000

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 and for information relative to writing AES_KEYRx registers.

33.8.14 AES key register 5 (AES_KEYR5)

Address offset: 0x034

Reset value: 0x0000 0000

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 and for information relative to writing AES_KEYRx registers.

33.8.15 AES key register 6 (AES_KEYR6)

Address offset: 0x038

Reset value: 0x0000 0000

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 and for information relative to writing AES_KEYRx registers.

33.8.16 AES key register 7 (AES_KEYR7)

Address offset: 0x03C

Reset value: 0x0000 0000

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 and for information relative to writing AES_KEYRx registers.

33.8.17 AES suspend registers (AES_SUSPRx)

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

Reset value: 0x0000 0000

Bits 31:0 SUSP[31:0] : Suspend data

AES_SUSPRx registers contain the complete internal register states of the AES when the GCM, GMAC or CCM processing of the current task is suspended to process a higher-priority task. Refer to Section 33.4.8: AES suspend and resume operations for more details.

Clearing EN bit of the AES_CR register clears this register to zero.

AES_SUSPRx registers are not used in other chaining modes than GCM, GMAC or CCM.

33.8.18 AES interrupt enable register (AES_IER)

Address offset: 0x300

Reset value: 0x0000 0000

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

Bit 2 KEIE : Key error interrupt enable

This bit enables or disables (masks) the AES interrupt generation when KEIF (key error flag) is set.

0: Disabled (masked)

1: Enabled (not masked)

Bit 1 RWEIE : Read or write error interrupt enable

This bit enables or disables (masks) the AES interrupt generation when RWEIF (read and/or write error flag) is set.

0: Disabled (masked)

1: Enabled (not masked)

Bit 0 CCFIE : Computation complete flag interrupt enable

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

0: Disabled (masked)

1: Enabled (not masked)

33.8.19 AES interrupt status register (AES_ISR)

Address offset: 0x304

Reset value: 0x0000 0000

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

Bit 2 KEIF : Key error interrupt flag

This read-only bit is set by hardware when the key information fails to load into key registers.

0: No key error detected

1: Key information failed to load into key registers

The flag setting generates an interrupt if the KEIE bit of the AES_IER register is set. It also clears the key registers and the KEYVALID flag in the AES_SR register.

The flag is cleared by setting the corresponding bit of the AES_ICR register.

KEIF is raised upon any of the following events:

• -AES_KEYRx register write does not respect the correct order. (For KEYSIZE cleared, AES_KEYR0 then AES_KEYR1 then AES_KEYR2 then AES_KEYR3 register, or reverse. For KEYSIZE set, AES_KEYR0 then AES_KEYR1 then AES_KEYR2 then AES_KEYR3 then AES_KEYR4 then AES_KEYR5 then AES_KEYR6 then AES_KEYR7, or reverse).

• -AES fails to load the key shared by the SAES peripheral (KMOD[1:0] = 0x2).

KEIF must be cleared by the application software, otherwise KEYVALID cannot be set.

Bit 1 RWEIF : Read or write error interrupt flag

This read-only bit is set by hardware when a RDERRF or a WRERRF error flag is set in the AES_SR register.

0: No read or write error detected

1: Read or write error detected

The flag setting generates an interrupt if the RWEIE bit of the AES_IER register is set.

The flag is cleared by setting the corresponding bit of the AES_ICR register.

The flag has no meaning when key derivation mode is selected.

See the AES_SR register for details.

Bit 0 CCF : Computation complete flag

This flag indicates whether the computation is completed. It is significant only when the DMAOUTEN bit is cleared, and it may stay high when DMAOUTEN is set.

0: Not completed

1: Completed

The flag setting generates an interrupt if the CCFIE bit of the AES_IER register is set.

The flag is cleared by setting the corresponding bit of the AES_ICR register.

33.8.20 AES interrupt clear register (AES_ICR)

Address offset: 0x308

Reset value: 0x0000 0000

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

Bit 2 KEIF : Key error interrupt flag clear

Setting this bit clears the KEIF status bit of the AES_ISR register.

Bit 1 RWEIF : Read or write error interrupt flag clear

Setting this bit clears the RWEIF status bit of the AES_ISR register, and clears both RDERRF and WRERRF flags in the AES_SR register.

Bit 0 CCF : Computation complete flag clear

Setting this bit clears the CCF status bit of the AES_ISR register.

33.8.21 AES register map

Table 314. AES register map and reset values

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

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

Refer to Section 2.3: Memory organization for the register boundary addresses.