37. Cryptographic processor (CRYP)

37.1 CRYP introduction

The cryptographic processor (CRYP) encrypts or decrypts data in compliance with the advanced encryption standard (AES) defined by NIST.

CRYP supports ECB, CBC, CTR, GCM, GMAC, and CCM chaining modes for key sizes of 128, 192 or 256 bits. CRYP has the possibility to load by hardware the key stored in SAES peripheral, under SAES control.

The peripheral supports both single and fixed DMA burst transfers for incoming and outgoing data (two DMA channels are required). CRYP also includes input and output FIFOs for better performance.

37.2 CRYP main features

37.3 CRYP implementation

The devices have one CRYP 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 338. CRYP versus SAES features

Modes or features (1)CRYPSAES
ECB, CBC chainingXX
CTR, CCM, GCM chainingXX
AES 128-bit ECB encryption in cycles14480
DHUK and BHK key selection-X
Resistance to side-channel attacks-X
Shared key between SAES and CRYPX
Key size in bits128, 192, 256128, 256

1. X = supported.

37.4 CRYP functional description

37.4.1 CRYP block diagram

The figure below shows the block diagram of the cryptographic processor.

Figure 372. CRYP block diagram

CRYP block diagram showing internal components like AHB interface, registers, FIFOs, AES Core, DMA, and IRQ interfaces connected to external signals like 32-bit AHB2 bus, crypt_hclk, and shared key from SAES.

The block diagram illustrates the internal architecture of the CRYP processor. On the left, external connections include a 32-bit AHB2 bus, crypt_hclk (clock), crypt_in_dma, crypt_out_dma, and crypt_it (interrupt). The internal components are as follows:

Reference code MSv66816V1 is located in the bottom right corner.

CRYP block diagram showing internal components like AHB interface, registers, FIFOs, AES Core, DMA, and IRQ interfaces connected to external signals like 32-bit AHB2 bus, crypt_hclk, and shared key from SAES.

37.4.2 CRYP internal signals

Table 339 describes the user relevant internal signals interfacing the CRYP peripheral.

Table 339. CRYP internal input/output signals

Signal nameSignal typeDescription
cryp_hclkDigital inputAHB clock
cryp_itDigital outputCRYP interrupt request
cryp_in_dmaDigital input/outputCRYP incoming data FIFO DMA request/ acknowledge
cryp_out_dmaDigital input/outputCRYP processed data FIFO DMA request/ acknowledge

37.4.3 CRYP reset and clocks

The CRYP peripheral is clocked by the AHB clock.

The CRYP has a dedicated reset bit in the RCC.

37.4.4 CRYP symmetric cipher implementation

The cryptographic processor (CRYP) 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 340 . Those functions can be certified NIST PUB 140-3.

Table 340. CRYP approved AES symmetric key functions

OperationsAlgorithmSpecificationKey size in bitsChaining modes
Encryption, decryptionAESFIPS PUB 197
NIST SP800-38A
128, 192, 256ECB, CBC, CTR
Authenticated encryption or decryptionNIST SP800-38C
NIST SP800-38D
GCM, CCM
Cipher-based message authentication codeNIST SP800-38DGMAC

CRYP 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 CRYP processing, following the sequence described in Section 37.4.8 .

37.4.5 CRYP encryption/ decryption typical usage

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

Figure 373. Encryption/ decryption typical usage

Flowchart illustrating the typical usage of CRYP encryption/ decryption. The process starts with 'Start' leading to 'Initialization'. From 'Initialization', it checks 'ECB or CBC decryption?'. If 'Yes', it goes to 'Round key preparation'. If 'No', it goes to 'Data append'. Both 'Round key preparation' and 'Data append' lead to 'Last block?'. From 'Last block?', if 'No', it loops back to 'Data append'. If 'Yes', it checks 'All bytes valid?'. If 'Yes', it goes to 'Finalize'. If 'No', it checks 'ECB or CBC chaining?'. If 'Yes', it goes to 'Data stealing'. If 'No', it goes to 'Data padding'. Both 'Data padding' and 'Data stealing' lead to 'Finalize'. 'Finalize' leads to 'End'. A small code 'MSv66120V1' is in the bottom right corner.
graph TD
    Start([Start]) --> Init([Initialization])
    Init --> ECB_CBC_Dec{ECB or CBC decryption?}
    ECB_CBC_Dec -- Yes --> RoundKey([Round key preparation])
    ECB_CBC_Dec -- No --> DataAppend([Data append])
    RoundKey --> LastBlock{Last block?}
    DataAppend --> LastBlock
    LastBlock -- No --> DataAppend
    LastBlock -- Yes --> AllBytesValid{All bytes valid?}
    AllBytesValid -- Yes --> Finalize([Finalize])
    AllBytesValid -- No --> ECB_CBC_Chaining{ECB or CBC chaining?}
    ECB_CBC_Chaining -- Yes --> DataStealing([Data stealing])
    ECB_CBC_Chaining -- No --> DataPadding([Data padding])
    DataPadding --> Finalize
    DataStealing --> Finalize
    Finalize --> End([End])
  
Flowchart illustrating the typical usage of CRYP encryption/ decryption. The process starts with 'Start' leading to 'Initialization'. From 'Initialization', it checks 'ECB or CBC decryption?'. If 'Yes', it goes to 'Round key preparation'. If 'No', it goes to 'Data append'. Both 'Round key preparation' and 'Data append' lead to 'Last block?'. From 'Last block?', if 'No', it loops back to 'Data append'. If 'Yes', it checks 'All bytes valid?'. If 'Yes', it goes to 'Finalize'. If 'No', it checks 'ECB or CBC chaining?'. If 'Yes', it goes to 'Data stealing'. If 'No', it goes to 'Data padding'. Both 'Data padding' and 'Data stealing' lead to 'Finalize'. 'Finalize' leads to 'End'. A small code 'MSv66120V1' is in the bottom right corner.

Initialization

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

Data append

This section describes different ways of appending data for processing. For ECB or CBC chaining modes, refer to Section 37.4.7: CRYP 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.

General conditions for data processing

The CRYP is busy and processing data (BUSY flag set) when all the conditions below are met:

It is possible to clear the CRYPTEN bit while BUSY bit is set. In this case the ongoing AES processing first completes (that is, the word results are written to the output FIFO) before the BUSY bit is cleared by hardware.

Note: If the application needs to suspend a message to process another one with a higher priority, refer to Section 37.4.8: CRYP suspend and resume operations .

Appending data using the CPU in polling mode

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

  1. 1. When KEYVALID is set, enable CRYP by setting the CRYPTEN bit of the CRYP_CR register (if not already done).
  2. 2. Repeat the following subsequence until the payload is entirely processed:
    1. a) Write data in the input FIFO (one block or until the FIFO is full).
    2. b) Repeat until the second last block of data has been processed:
      • – Wait until the not-empty flag OFNE is set, then read the output FIFO (one block or until the FIFO is empty).
      • – Wait until the not-full flag IFNF is set, then write the input FIFO (one block or until the FIFO is full), except if it is the last block.
    3. c) The BUSY bit is set automatically by CRYP. At the end of the processing, the BUSY bit is cleared and both FIFOs are empty (input FIFO empty flag IFEM is set, output FIFO not-empty flag OFNE is cleared).
    4. d) If the next processing block is the last block, pad the data with zeros to obtain a complete block (when applicable), 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). This operation must be performed after checking that the BUSY bit is cleared.
  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 CRYP peripheral by clearing CRYPTEN.

Note: 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 CRYP peripheral to control the data append, through the following sequence:

  1. 1. Enable interrupts from CRYP, by setting the INIM and OUTIM bits of the CRYP_IMSCR register.
  2. 2. When KEYVALID is set, enable the CRYP peripheral, by setting CRYPTEN (if not already done).
  3. 3. Handle the data in the CRYP interrupt service routine that manages the input FIFO. Upon each interrupt:
    1. a) 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 (using NPBLB[3:0] bitfield) in case of GCM payload encryption or CCM payload decryption (otherwise the tag computation is wrong). This operation must be performed after checking that the BUSY bit is cleared. After that load the block into the input FIFO.
    2. b) If the next processing block is not the last block, load the data into the input FIFO. Application can load only one block (4 words), or load data until the input FIFO is full.
    3. c) After the last word of data has been written, disable the input FIFO interrupts by clearing the INIM bit (if applicable), then quit the interrupt service routine.
  1. 4. Handle the data in the CRYP interrupt service routine that manages the output FIFO. Upon each interrupt:
    1. a) Read data from the output FIFO. Application can read only one block (4 words), or read data until the FIFO is empty.
    2. b) When the last word of the message has been read, INIM and BUSY bits are cleared and both FIFOs are empty (IFEM is set, OFNE is cleared). Disable the output FIFO interrupt by clearing the OUTIM bit, and disable the peripheral by clearing the CRYPTEN bit.
    3. c) 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 quit the interrupt service routine.

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

Appending data using the DMA

With this method, all the transfers and processing are managed by DMA and CRYP. 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 CRYP peripheral input and the processed data from the CRYP peripheral output to the memory, as described in Section 37.6: CRYP 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 block. 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 CRYP to compute a correct tag.
  3. 3. When KEYVALID is set, enable the CRYP peripheral, by setting CRYPTEN (if not already done).
  4. 4. Enable DMA requests, by setting DIEN and DOEN of the CRYP_DMACR register.
  5. 5. Upon DMA interrupt indicating the transfer completion, get the CRYP-processed data from the memory. Both FIFOs are normally empty and BUSY flag is cleared.

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

Caution: It is important for the DMA controller to empty the CRYP output FIFO buffer before filling the CRYP input FIFO buffer. To ensure this, configure the DMA controller to prioritize transfers from CRYP to memory over those from memory to CRYP.

37.4.6 CRYP 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.

Figure 374. Typical operation with authentication

Flowchart illustrating the typical operation with authentication. The process starts with 'Start' leading to 'Initialization', then 'Header phase init', and 'Header data append'. A loop exists for header data until 'Last block?' is 'Yes'. If 'Yes', it checks 'All bytes valid?'. If 'No', it goes to 'Data padding'. If 'Yes', it checks 'cipher-based* authentication?'. If 'Yes', it goes to 'Finalization'. If 'No', it goes to 'Payload phase init'. 'Payload phase init' leads to 'Payload data append', which has a loop until 'Last block?' is 'Yes'. If 'Yes', it checks 'All bytes valid?'. If 'No', it goes to 'Data padding'. If 'Yes', it goes to 'Finalization'. Both 'Data padding' paths lead to 'Finalization', which leads to 'End'. A note indicates '* such as GMAC'. The diagram is labeled MSV66121V1.
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?}
    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
    DataPaddingHeader --> Finalization
    DataPaddingPayload --> Finalization
    Finalization --> End([End])
    style * such as GMAC
  
Flowchart illustrating the typical operation with authentication. The process starts with 'Start' leading to 'Initialization', then 'Header phase init', and 'Header data append'. A loop exists for header data until 'Last block?' is 'Yes'. If 'Yes', it checks 'All bytes valid?'. If 'No', it goes to 'Data padding'. If 'Yes', it checks 'cipher-based* authentication?'. If 'Yes', it goes to 'Finalization'. If 'No', it goes to 'Payload phase init'. 'Payload phase init' leads to 'Payload data append', which has a loop until 'Last block?' is 'Yes'. If 'Yes', it checks 'All bytes valid?'. If 'No', it goes to 'Data padding'. If 'Yes', it goes to 'Finalization'. Both 'Data padding' paths lead to 'Finalization', which leads to 'End'. A note indicates '* such as GMAC'. The diagram is labeled MSV66121V1.

Section 37.4.11: CRYP AES Galois/counter mode (GCM) and Section 37.4.13: CRYP AES Counter with CBC-MAC (CCM) describe detailed sequences supported by CRYP.

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

37.4.7 CRYP ciphertext stealing and data padding

When using 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 CRYP 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 other modes 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 CRYP 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.

37.4.8 CRYP 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 CRYP is enabled again, to receive a next data block.

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

Figure 375. Example of suspend mode management

Diagram illustrating suspend and resume operations for Message 1 and Message 2.

The diagram illustrates the flow of data blocks for two messages, Message 1 and Message 2, through a cryptographic processor. Message 1 consists of six 128-bit blocks. The first three blocks are processed, then a 'CRYP suspend sequence' is triggered by a 'New higher priority message 2 to be processed'. Message 2, consisting of two 128-bit blocks, is then processed. After Message 2, a 'CRYP resume sequence' is triggered, and Message 1's processing resumes with the fourth block, continuing through the sixth block and beyond (indicated by '...').

Diagram illustrating suspend and resume operations for Message 1 and Message 2.

Detailed descriptions of suspend and resume operations are provided in the sections dedicated to each chaining mode.

37.4.9 CRYP 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 mode, a special key scheduling is required before processing the first block.

Figure 376 and Figure 377 describe the electronic codebook (ECB) chaining implementation in encryption and decryption, respectively. To select this chaining mode, write ALGOMODE[3:0] with 0x4.

Figure 376. ECB encryption

Diagram of ECB encryption showing two blocks, Block 1 and Block 2, processed independently. Each block has a DIN (plaintext), a Swap management block, an Encrypt block, and a DOUT (ciphertext). A KEY is input to the Encrypt block. DATATYPE[1:0] is input to the Swap management blocks. A legend indicates that white boxes are input and grey boxes are output.

Block 1

DIN (plaintext P1)

DATATYPE[1:0] → Swap management

KEY → Encrypt

↓ I1

↓ O1

DATATYPE[1:0] → Swap management

DOUT (ciphertext C1)

Block 2

DIN (plaintext P2)

DATATYPE[1:0] → Swap management

KEY → Encrypt

↓ I2

↓ O2

DATATYPE[1:0] → Swap management

DOUT (ciphertext C2)

Legend

input

output

MSv69563V1

Diagram of ECB encryption showing two blocks, Block 1 and Block 2, processed independently. Each block has a DIN (plaintext), a Swap management block, an Encrypt block, and a DOUT (ciphertext). A KEY is input to the Encrypt block. DATATYPE[1:0] is input to the Swap management blocks. A legend indicates that white boxes are input and grey boxes are output.

Figure 377. ECB decryption

Diagram of ECB decryption showing two blocks, Block 1 and Block 2, processed independently. Each block has a DIN (ciphertext), a Swap management block, a Decrypt block, and a DOUT (plaintext). A KEY is input to the Decrypt block. DATATYPE[1:0] is input to the Swap management blocks. A legend indicates that white boxes are input and grey boxes are output.

Block 1

DIN (ciphertext C1)

DATATYPE[1:0] → Swap management

KEY → Decrypt

↓ I1

↓ O1

DATATYPE[1:0] → Swap management

DOUT (plaintext P1)

Block 2

DIN (ciphertext C2)

DATATYPE[1:0] → Swap management

KEY → Decrypt

↓ I2

↓ O2

DATATYPE[1:0] → Swap management

DOUT (plaintext P2)

Legend

input

output

MSv69564V1

Diagram of ECB decryption showing two blocks, Block 1 and Block 2, processed independently. Each block has a DIN (ciphertext), a Swap management block, a Decrypt block, and a DOUT (plaintext). A KEY is input to the Decrypt block. DATATYPE[1:0] is input to the Swap management blocks. A legend indicates that white boxes are input and grey boxes are output.

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

Figure 378 and Figure 379 describe the cipher block chaining (CBC) implementation in encryption and decryption, respectively. To select this chaining mode, write ALGOMODE[3:0] with 0x5.

Figure 378. CBC encryption

Diagram of CBC encryption showing two blocks. Block 1 takes plaintext P1, an IV, and a key to produce ciphertext C1. Block 2 takes plaintext P2, the previous ciphertext C1 as an IV, and a key to produce ciphertext C2. Both blocks include 'Swap management' and XOR operations.

The diagram illustrates the CBC encryption process for two blocks. Block 1 : DIN (plaintext P1) is input to a 'Swap management' block. The output of 'Swap management' is XORed with an IV (from DATATYPE[1:0]) to produce P1'. P1' is then processed by a 'Block cipher encryption' block using a KEY to produce O1. O1 is then processed by another 'Swap management' block to produce DOUT (ciphertext C1). Block 2 : DIN (plaintext P2) is input to a 'Swap management' block. The output is XORed with the previous ciphertext C1 (acting as the IV) to produce P2'. P2' is processed by a 'Block cipher encryption' block using a KEY to produce O2. O2 is then processed by another 'Swap management' block to produce DOUT (ciphertext C2). A legend indicates that light gray boxes are inputs, dark gray boxes are outputs, and the circle with a cross symbol represents XOR.

Diagram of CBC encryption showing two blocks. Block 1 takes plaintext P1, an IV, and a key to produce ciphertext C1. Block 2 takes plaintext P2, the previous ciphertext C1 as an IV, and a key to produce ciphertext C2. Both blocks include 'Swap management' and XOR operations.

Figure 379. CBC decryption

Diagram of CBC decryption showing two blocks. Block 1 takes ciphertext C1 and a key to produce plaintext P1. Block 2 takes ciphertext C2, the previous ciphertext C1 as an IV, and a key to produce plaintext P2. Both blocks include 'Swap management' and XOR operations.

The diagram illustrates the CBC decryption process for two blocks. Block 1 : DIN (ciphertext C1) is input to a 'Swap management' block. The output is processed by a 'Decrypt' block using a KEY to produce O1. O1 is then XORed with an IV (from DATATYPE[1:0]) to produce P1'. P1' is then processed by another 'Swap management' block to produce DOUT (plaintext P1). Block 2 : DIN (ciphertext C2) is input to a 'Swap management' block. The output is processed by a 'Decrypt' block using a KEY to produce O2. O2 is then XORed with the previous ciphertext C1 (acting as the IV) to produce P2'. P2' is then processed by another 'Swap management' block to produce DOUT (plaintext P2). A legend indicates that light gray boxes are inputs, dark gray boxes are outputs, and the circle with a cross symbol represents XOR.

Diagram of CBC decryption showing two blocks. Block 1 takes ciphertext C1 and a key to produce plaintext P1. Block 2 takes ciphertext C2, the previous ciphertext C1 as an IV, and a key to produce plaintext P2. Both blocks include 'Swap management' and XOR operations.

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

ECB/CBC encryption process

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

  1. 1. Disable the CRYP peripheral by clearing CRYPTEN.
  2. 2. Flush the FIFOs by setting FFLUSH.
  3. 3. Initialize the CRYP_CR register as follows:
    1. a) Select ECB or CBC chaining mode (write ALGOMODE[3:0] with 0x4 or 0x5) in encryption mode (ALGODIR = 0).
    2. b) Configure the data type through DATATYPE[1:0].
    3. c) Configure the key size through KEYSIZE.
    4. d) Select the key mode using KMOD[1:0]: if the key is coming from SAES peripheral, set KMOD[1:0] to 0x2, else keep it at 0x0.
  4. 4. Write the initialization vector into the CRYP_IVxL/R registers if CBC mode is selected in the previous step.
  5. 5. Write the key into the CRYP_KxL/R registers if KMOD[1:0] is 0x0. If KMOD[1:0] = 0x2, the key is being transferred from the SAES peripheral (see Section 37.4.14 ).
  6. 6. Wait until KEYVALID is set (the key loading completed).
  7. 7. Enable CRYP by setting CRYPTEN.
  8. 8. Append cleartext data:
    1. a) 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 37.4.7 .
    2. b) Append the cleartext block into CRYP as described in Section 37.4.5 , then read the CRYP_DOUTR register to save the ciphertext block(s), MSB first.
    3. c) Repeat the step b) until the third-last plaintext block is encrypted. For the last two blocks, follow the steps a) and b) .
  9. 9. Finalize the sequence: disable the CRYP peripheral, by clearing CRYPTEN.

Note: KEYSIZE and ALGOMODE[3:0] must be written before the key, as explained above.
KMOD[1:0] = 0x2 (shared key) must be written after ALGOMODE[3:0] or at the same time.

ECB/CBC decryption process

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

  1. 1. Disable the CRYP peripheral, by clearing CRYPTEN.
  2. 2. Flush the FIFOs by setting FFLUSH.
  3. 3. Initialize the CRYP_CR register as follows:
    1. a) Select the key derivation mode (write ALGOMODE[3:0] with 0x7) in encryption mode (ALGODIR= 0).
    2. b) Configure the data type through DATATYPE[1:0].
    3. c) Configure the key size through KEYSIZE.
    4. d) Select the key mode, using KMOD[1:0]: if the key is coming from SAES peripheral set KMOD[1:0] to 0x2, else keep it at 0x0.
  4. 4. Write the key into the CRYP_KxL/R registers if KMOD[1:0] is 0x0. If KMOD[1:0]= 0x2, the key is being transferred from the SAES peripheral (see Section 37.4.14 ).
  5. 5. Wait until KEYVALID is set (the key loading completed).
  6. 6. Enable the CRYP peripheral by setting CRYPTEN. The peripheral immediately starts an AES round for key preparation, setting the BUSY bit.
  7. 7. Wait until the BUSY bit is cleared, then select ECB or CBC chaining mode (write ALGOMODE[3:0] with 0x4 or 0x5) in decryption mode (ALGODIR = 1). Do not change other parameters.
  8. 8. Write the initialization vector into the CRYP_IVxL/R registers if CBC mode is selected in the previous step.
  9. 9. Enable CRYP by setting CRYPTEN.
  10. 10. 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 37.4.7 .
    2. b) Append the ciphertext block into CRYP as described in Section 37.4.5 , then read the CRYP_DOUTR register to save the plaintext block(s), 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) .
  11. 11. Finalize the sequence: disable the CRYP peripheral, by clearing CRYPTEN.

Note: KEYSIZE and ALGOMODE[3:0] must be written before the key, as explained above.
KMOD[1:0] = 0x2 (shared key) must be written after ALGOMODE[3:0] or at the same time.

Suspend and resume operations in ECB/CBC modes

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

  1. 1. If DMA is used, stop the CRYP DMA transfers to the input FIFO by clearing the DIEN bit of the CRYP_DMACR register.
  2. 2. Wait until both FIFOs are empty (IFEM = 1 and OFNE = 0 in CRYP_SR) and the BUSY bit is cleared.
  3. 3. If DMA is used, stop the CRYP DMA transfers from the output FIFO, by clearing the DOEN bit of the CRYP_DMACR register.
  4. 4. Disable the CRYP peripheral, by clearing CRYPTEN.
  5. 5. Save the CRYP_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:

Note: Key registers do not need to be saved as the original key value is known by the application.

37.4.10 CRYP counter mode (CTR)

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

Figure 380. Message construction in CTR mode

Diagram illustrating message construction in CTR mode. It shows a large rectangular area representing memory. On the right side, a '16-byte bound' is indicated by two vertical lines. Below this bound, a box labeled 'ICB' (Initial Counter Block) is shown. A diagonal line points from the bottom left of the main area towards the ICB box. Another diagonal line points from the ICB box towards the bottom right of the main area.
Diagram illustrating message construction in CTR mode. It shows a large rectangular area representing memory. On the right side, a '16-byte bound' is indicated by two vertical lines. Below this bound, a box labeled 'ICB' (Initial Counter Block) is shown. A diagonal line points from the bottom left of the main area towards the ICB box. Another diagonal line points from the ICB box towards the bottom right of the main area.

The structure of this message is:

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

CTR encryption and decryption

Figure 381 describes the counter (CTR) chaining implementation in the CRYP peripheral (encryption). To select this chaining mode, write ALGOMODE[3:0] with 0x6.

Figure 381. CTR encryption

Diagram of CTR encryption showing two blocks, Block 1 and Block 2. Each block consists of an IVI (Nonce + 32-bit counter) being encrypted with a KEY to produce an output (O1, O2). This output is XORed with the plaintext (DIN, P1, P2) via a Swap management block to produce the ciphertext (DOUT, C1, C2). The counter is incremented for the next block. A legend indicates input, output, and XOR symbols.

The diagram illustrates the CTR encryption process across two blocks, Block 1 and Block 2. In Block 1, the IVI (Nonce + 32-bit counter) is input to an 'Encrypt' block along with a 'KEY'. The 'Encrypt' block produces an output 'O1'. 'O1' is XORed with the plaintext 'DIN (plaintext P1)' (which passes through a 'Swap management' block controlled by 'DATATYPE[1:0]') to produce the ciphertext 'DOUT (ciphertext C1)'. The counter is incremented by '+1' and passed to Block 2. In Block 2, the incremented counter is input to another 'Encrypt' block with the same 'KEY' to produce 'O2'. 'O2' is XORed with 'DIN (plaintext P2)' (via another 'Swap management' block) to produce 'DOUT (ciphertext C2)'. A legend defines the symbols: light gray for input, dark gray for output, and a circle with an 'X' for XOR.

Diagram of CTR encryption showing two blocks, Block 1 and Block 2. Each block consists of an IVI (Nonce + 32-bit counter) being encrypted with a KEY to produce an output (O1, O2). This output is XORed with the plaintext (DIN, P1, P2) via a Swap management block to produce the ciphertext (DOUT, C1, C2). The counter is incremented for the next block. A legend indicates input, output, and XOR symbols.

Initialization vectors in CRYP must be initialized as shown in Table 341 .

Table 341. Counter mode initialization vector definition

CRYP_IV0LR[31:0]CRYP_IV0RR[31:0]CRYP_IV1LR[31:0]CRYP_IV1RR[31:0]
IVI[127:96]IVI[95:64]IVI[63:32]IVI[31:0]
32-bit counter = 0x1

CTR encryption and decryption process

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

  1. 1. Disable the CRYP peripheral, by clearing CRYPTEN.
  2. 2. Flush the FIFOs by setting FFLUSH.
  3. 3. Initialize the CRYP_CR register as follows:
    1. a) Select CTR chaining mode (write ALGOMODE[3:0] with 0x6) in encryption or decryption mode (write ALGODIR with 0 or 1).
    2. b) Configure the data type through DATATYPE[1:0].
    3. c) Configure the key size through KEYSIZE.
    4. d) Select the key mode, using KMOD[1:0]: if the key is coming from SAES peripheral set KMOD[1:0] to 0x2 else keep it at 0x0.
  4. 4. Write the initialization vector into the CRYP_IVxL/R registers according to Table 341 .
  5. 5. Write the key into the CRYP_KxL/R registers if KMOD[1:0] is 0x0. If KMOD[1:0]= 0x2 the key is being transferred from the SAES peripheral (see Section 37.4.14 ).
  6. 6. Wait until KEYVALID is set (the key loading completed).
  7. 7. Enable CRYP by setting CRYPTEN.
  8. 8. 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 CRYP as described in Section 37.4.5 , then read the CRYP_DOUTR register to save the resulting block(s), 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.
  9. 9. Finalize the sequence: disable the CRYP peripheral, by clearing CRYPTEN.

Note: KEYSIZE and ALGOMODE[3:0] must be written before the key, as explained above.
KMOD[1:0] = 0x2 (shared key) must be written after ALGOMODE[3:0] or at the same time.

Suspend and 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 37.4.9: CRYP basic chaining modes (ECB, CBC) .

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

37.4.11 CRYP AES Galois/counter mode (GCM)

The AES Galois/counter mode (GCM) enables 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 382. Message construction in GCM

Figure 382: Message construction in GCM. The diagram shows the layout of data blocks for GCM processing. It starts with a 16-byte Initial Counter Block (ICB) divided into a 96-bit Initialization Vector (IV) and a 32-bit Counter based on 4-byte boundaries. Following this is the Additional Authenticated Data (AAD) of length Len(A), which is padded with zeros to a 16-byte boundary. Then comes the Plaintext (P) of length Len(P), also padded with zeros to a 16-byte boundary. The AAD and Plaintext are processed by an 'authenticate' block. The Plaintext is also processed by an 'encrypt' block to produce the Authenticated & encrypted ciphertext (C), which is then further processed by an 'auth.' block. Finally, a 'Last block' containing the 64-bit lengths of AAD and C ([Len(A)]64 and [Len(C)]64) is processed to generate the final Authentication tag (T).
Figure 382: Message construction in GCM. The diagram shows the layout of data blocks for GCM processing. It starts with a 16-byte Initial Counter Block (ICB) divided into a 96-bit Initialization Vector (IV) and a 32-bit Counter based on 4-byte boundaries. Following this is the Additional Authenticated Data (AAD) of length Len(A), which is padded with zeros to a 16-byte boundary. Then comes the Plaintext (P) of length Len(P), also padded with zeros to a 16-byte boundary. The AAD and Plaintext are processed by an 'authenticate' block. The Plaintext is also processed by an 'encrypt' block to produce the Authenticated & encrypted ciphertext (C), which is then further processed by an 'auth.' block. Finally, a 'Last block' containing the 64-bit lengths of AAD and C ([Len(A)]64 and [Len(C)]64) is processed to generate the final Authentication tag (T).

The structure of this message is defined as below:

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

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

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

Figure 383 describes the GCM chaining implementation in the CRYP peripheral (encryption). To select this chaining mode, write ALGOMODE[3:0] with 0x6.

Figure 383. GCM authenticated encryption

Diagram of GCM authenticated encryption process showing Init, Header, Payload, and Final stages. The Init stage uses KEY and IV to produce H. The Header stage processes AAD blocks through Swap management and GF2mul to produce a value for the final tag. The Payload stage encrypts plaintext blocks P1 to Pn using CTR mode, with counter blocks CB1 to CBn derived from ICB. The Final stage combines the GF2mul output, length information, and IV to produce the Authentication TAG T.

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

Legend:

MSv69568V1

Diagram of GCM authenticated encryption process showing Init, Header, Payload, and Final stages. The Init stage uses KEY and IV to produce H. The Header stage processes AAD blocks through Swap management and GF2mul to produce a value for the final tag. The Payload stage encrypts plaintext blocks P1 to Pn using CTR mode, with counter blocks CB1 to CBn derived from ICB. The Final stage combines the GF2mul output, length information, and IV to produce the Authentication TAG T.

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

Table 342. GCM mode IVI registers initialization

RegisterCRYP_IV0LR[31:0]CRYP_IV0RR[31:0]CRYP_IV1LR[31:0]CRYP_IV1RR[31:0]
Input dataICB[127:96]ICB[95:64]ICB[63:32]ICB[31:0]
32-bit counter = 0x2

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

Table 343. GCM last block definition

Word order to CRYP_DINRFirst wordSecond wordThird wordFourth word
Input dataAAD length[63:32]AAD length[31:0]Payload length[63:32]Payload length[31:0]

GCM encryption and decryption process

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

GCM initialize

  1. 1. Disable the CRYP peripheral, by clearing CRYPTEN.
  2. 2. Flush the FIFOs by setting FFLUSH.
  3. 3. Initialize the CRYP_CR register:
    1. a) Select GCM chaining mode (write ALGOMODE[3:0] with 0x8) in encryption or decryption mode (write ALGODIR with 0 or 1).
    2. b) Configure the data type through DATATYPE[1:0]
    3. c) Configure the key size through KEYSIZE.
    4. d) Select the key mode, using KMOD[1:0]: if the key is coming from SAES peripheral set KMOD[1:0] to 0x2 else keep it at 0x0.
    5. e) Select the GCM initialization phase, by writing 0x0 to GCM_CCMPH[1:0]
  4. 4. Write the initialization vector in CRYP_IVxL/R registers according to Table 342 .
  5. 5. Write the key in CRYP_KxL/R registers if KMOD[1:0] is 0x0. If KMOD[1:0]= 0x2, the key is being transferred from the SAES peripheral (see Section 37.4.14 ).
  6. 6. Wait until KEYVALID is set (the key loading completed).
  7. 7. Set CRYPTEN to start the calculation of the hash key. CRYPTEN is automatically cleared when the calculation is complete.
  8. 8. Wait for the CRYPTEN bit to be cleared, indicating that the GCM hash subkey (H) computation is complete.

GCM header phase

  1. 9. Initialize header phase:
    1. a) Select the GCM header phase, by writing 0x1 to GCM_CCMPH[1:0]. Do not change the other configurations written during GCM initialization.
    2. b) Set CRYPTEN to start accepting data.
  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 into CRYP as described in Section 37.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) .
  3. 11. Wait until the BUSY flag is cleared.

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. 12. Initialize payload phase:
    1. a) Disable the CRYP peripheral, by clearing CRYPTEN.
    2. b) Select the GCM payload phase, by writing GCM_CCMPH[1:0] with 0x2. Do not change the other configurations written during GCM initialization.
    3. c) Enable the CRYP peripheral by setting CRYPTEN, to start accepting data.
  2. 13. 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 into CRYP as described in Section 37.4.5 , then read the CRYP_DOUTR register to save the resulting block(s).
    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.
  3. 14. Wait until the BUSY flag is cleared.

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

GCM finalization
  1. 15. Select the GCM final phase, by writing GCM_CCMPH[1:0] with 0x3, and clear the ALGODIR bit (encryption). Do not change the other configurations written during GCM initialization.
  2. 16. Write the final GCM block into the CRYP_DINR register. It is the concatenated AAD bit and payload bit lengths, as shown in Table 343 .
  3. 17. Wait until the OFNE flag in the CRYP_SR register is set.
  4. 18. Get the GCM authentication tag, by reading the CRYP_DOUTR register four times.
  5. 19. Disable the CRYP peripheral, by clearing CRYPTEN. 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 CRYP_DINR normally (no swapping).

Suspend and resume operations in GCM mode

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

  1. 1. If DMA is used, stop the CRYP DMA transfers to the input FIFO, by clearing DIEN bit of the CRYP_DMACR register.
  2. 2. Wait until both FIFOs are empty (IFEM = 1 and OFNE = 0 in CRYP_SR) and the BUSY bit is cleared.
  3. 3. In the payload phase, if DMA is used, stop the CRYP DMA transfers from the output FIFO, by clearing the DOEN bit of the CRYP_DMACR register.
  4. 4. Disable the CRYP by clearing CRYPTEN.
  5. 5. Save the current CRYP_CR configuration in the memory. Key registers do not need to be saved as the original key value is known by the application.
  6. 6. In the payload phase, save the CRYP_IVxL/R registers as, during the data processing, they changed from their initial values. In the header phase, this step is not required.
  7. 7. Save the CRYP_CSGCMCCMRx and CRYP_CSGCMRx registers in memory.
  8. 8. If DMA is used, save the DMA controller status (pointer for CRYP input data transfers, number of remaining bytes, and so on). In the payload phase, also save pointer for CRYP output data transfers.

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 remaining input FIFO transfers. In the payload phase, also configure the DMA controller for the remaining output FIFO transfers.
  2. 2. Disable the CRYP peripheral, by clearing CRYPTEN.
  3. 3. Restore the initial setting values in the CRYP_CR and CRYP_KxL/R registers. If KMOD[1:0]= 0x2 the key needs to be transferred again from the SAES peripheral (see Section 37.4.14 ).
  4. 4. Write the suspend register values, previously saved in the memory, back into their corresponding CRYP_CSGCMCCMRx and CRYP_CSGCMRx registers.
  5. 5. In the payload phase, write the initialization vector register values, previously saved in the memory, back into their corresponding CRYP_IVxL/R registers. In the header phase, write initial setting values back into the CRYP_IVxL/R registers.
  6. 6. Enable the CRYP peripheral by setting CRYPTEN.
  7. 7. If DMA is used, enable CRYP DMA requests, by setting DIEN (and DOEN if in payload phase).

37.4.12 CRYP AES Galois message authentication code (GMAC)

The Galois message authentication code (GMAC) enables 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 384. Message construction in GMAC mode

Diagram of message construction in GMAC mode showing ICB, Authenticated data, and Authentication tag (T) with 16-byte and 4-byte boundaries.

The diagram illustrates the message construction for GMAC. It shows a sequence of blocks starting with an Initialization Vector (IV) and Counter (4-byte boundaries) followed by an ICB (16-byte boundary). The main part is 'Authenticated data' of length 'Len(A)', which is split into 16-byte blocks. The last block is followed by a 'Last block' containing '0' and padding. 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'.

Diagram of message construction in GMAC mode showing ICB, Authenticated data, and Authentication tag (T) with 16-byte and 4-byte boundaries.

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

Figure 385 describes the GMAC chaining implementation in the CRYP peripheral. To select this chaining mode, write ALGOMODE[3:0] with 0x6.

Figure 385. GMAC authentication mode

Diagram of GMAC authentication mode showing four steps: (1) Init, (2) Header, and (4) Final, with a legend for input, output, and XOR operations.

The diagram shows the GMAC chaining implementation in three visible steps:

A legend indicates that white boxes are 'input', grey boxes are 'output', and a circle with a cross represents 'XOR'.

Diagram of GMAC authentication mode showing four steps: (1) Init, (2) Header, and (4) Final, with a legend for input, output, and XOR operations.

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 for the GCM, except that the payload phase is omitted.

Suspend and resume operations in GMAC

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

37.4.13 CRYP AES Counter with CBC-MAC (CCM)

The AES counter with cipher block chaining-message authentication code (CCM) algorithm enables 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 CBC-MAC as an authentication mode outside the context of the CCM specification.

The following figure shows typical message construction for CCM.

Figure 386. Message construction in CCM mode

Diagram of CCM message construction showing block B0, Associated data (A), Plaintext (P), and Tag (T).

The diagram illustrates the message construction in CCM mode. It shows the structure of the message blocks and the flow of data through authentication and encryption. The message is composed of several fields: B0 (16-byte first authentication block), Associated data (A), Plaintext (P), and Enc (T) (ciphertext and tag). B0 is further detailed as containing flags, Nonce (N), and Q. The diagram also shows the flow of data through 'authenticate' and 'encrypt' processes, resulting in 'Authenticated & encrypted ciphertext (C)' and 'MAC (T)'. The diagram includes 16-byte and 4-byte boundaries, and zero padding is indicated.

Len(A)Len(P)Len(T)
B0[a] 32
[a] 16
Associated data (A)0 (padding)Plaintext (P)0 (padding)Enc (T)

B0 detail: [ flags | Nonce (N) | Q ]

Diagram of CCM message construction showing block B0, Associated data (A), Plaintext (P), and Tag (T).

The structure of the message is:

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

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 0x7 bytes)
A: 00010203 04050607 ( \( \text{Len}(A) = 64 \) bits or 0x8 bytes)
P: 20212223 ( \( \text{Len}(P) = 32 \) bits i.e. \( Q = 0x4 \) 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
\( \text{CTR}_0 \) : 0710111213 141516 00000000 00000000
\( \text{CTR}_1 \) : 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 387 describes the CCM chaining implementation in the CRYP peripheral (encryption). To select this chaining mode, write ALGOMODE[3:0] with 0x9.

Figure 387. CCM mode authenticated encryption

Diagram of CCM mode authenticated encryption showing Init, Header, Payload, and Final stages.

The diagram illustrates the CCM chaining implementation for encryption, divided into four main stages:

Legend:

MSv69570V1

Diagram of CCM mode authenticated encryption showing Init, Header, Payload, and Final stages.

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

Table 344. CCM mode IVI registers initialization

RegisterCRYP_IV0LR[31:0]CRYP_IV0RR[31:0]CRYP_IV1LR[31:0]CRYP_IV1RR[31:0]
Input dataB0[127:96] (1)B0[95:64]B0[63:32]B0[31:0] (2)
  1. 1. The 5 most significant bits are cleared (flag bits).
  2. 2. Q length bits are cleared, except for bit 0 that is set.

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

CCM encryption and decryption process

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

CCM initialize

  1. 1. Disable the CRYP peripheral, by clearing CRYPTEN.
  2. 2. Flush the FIFOs by setting FFLUSH.
  3. 3. Initialize the CRYP_CR register:
    1. a) Select CCM chaining mode (write ALGOMODE[3:0] with 0x9) in encryption or decryption mode (write ALGODIR with 0 or 1).
    2. b) Configure the data type through DATATYPE[1:0]
    3. c) Configure the key size through KEYSIZE.
    4. d) Select the key mode, using KMOD[1:0]: if the key is coming from SAES peripheral set KMOD[1:0] to 0x2 else keep it at 0x0.
    5. e) Select the CCM initialization phase, by writing 0x0 to GCM_CCMPH[1:0]
  4. 4. Write the initialization vector into the CRYP_IVxL/R registers with CTR1 information, as defined in Table 344
  5. 5. Write the key in CRYP_KxL/R registers if KMOD[1:0] is 0x0. If KMOD[1:0]= 0x2 the key is being transferred from the SAES peripheral (see Section 37.4.14 ).
  6. 6. Wait until KEYVALID is set (the key loading completed).
  7. 7. Enable the CRYP peripheral by setting CRYPTEN.
  8. 8. Write the B0 data in CRYP_DINR registers according to Table 344 , then wait for the CRYPTEN bit to be cleared.

Note: In this initialization phase, data have to be inserted normally (no swapping).

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 GCM header phase, by writing GCM_CCMPH[1:0] with 0x1. Do not change the other configurations written during the GCM initialization.
    3. c) Set CRYPTEN to start accepting data.
  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 into CRYP as described in Section 37.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) .
  3. 11. Wait until the BUSY flag is cleared.

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. 12. Initialize payload phase:
    1. a) Disable the CRYP peripheral, by clearing CRYPTEN.
    2. b) Select the GCM payload phase, by writing GCM_CCMPH[1:0] with 0x2. Do not change the other configurations written during GCM initialization.
    3. c) Enable the CRYP peripheral by setting CRYPTEN, to start accepting data.
  2. 13. 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 into CRYP as described in Section 37.4.5 , then read the CRYP_DOUTR register to save the resulting block(s).
    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.
  3. 14. Wait until the BUSY flag is cleared.

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. 15. Select the GCM final phase, by writing GCM_CCMPH[1:0] with 0x3, and clear the ALGODIR bit (encryption). Do not change the other configurations written during GCM initialization.
  2. 16. Write the CTR0 information into the CRYP_DINR register. CTR0 information is described in Table 344 , with the bit[0] cleared.
  3. 17. Wait until the OFNE flag in the CRYP_SR register is set.
  4. 18. Get the CCM authentication tag, by reading the CRYP_DOUTR register four times.
  5. 19. Disable the CRYP peripheral by clearing CRYPTEN. 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 this final phase, data have to be inserted normally (no swapping).

Suspend and 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 CRYP DMA transfers to the input FIFO, by clearing DIEN bit of the CRYP_DMACR register.
  2. 2. Wait until both FIFOs are empty (IFEM = 1 and OFNE = 0 in CRYP_SR) and the BUSY bit is cleared.
  3. 3. In the payload phase, if DMA is used, stop the CRYP DMA transfers from the output FIFO, by clearing the DOEN bit of the CRYP_DMACR register.
  4. 4. Disable the CRYP by clearing CRYPTEN.
  5. 5. Save the current CRYP_CR configuration in the memory. Key registers do not need to be saved as the original key value is known by the application.
  6. 6. In the payload phase, save the CRYP_IVxL/R registers as, during the data processing, they changed from their initial values. In the header phase, this step is not required.
  7. 7. Save the CRYP_CSGCMCCMRx registers in the memory.
  8. 8. If DMA is used, save the DMA controller status (pointer for CRYP input data transfers, number of remaining bytes, and so on). In the payload phase, also save pointer for CRYP output data transfers.

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 remaining input FIFO transfers. In the payload phase, also configure the DMA controller for the remaining output FIFO transfers.
  2. 2. Disable the CRYP peripheral, by clearing CRYPTEN.
  3. 3. Restore the initial setting values in the CRYP_CR and CRYP_KxL/R registers. If KMOD[1:0]= 0x2 the key needs to be transferred again from the SAES peripheral (see Section 37.4.14 ).
  4. 4. Write the suspend register values, previously saved in the memory, back into their corresponding CRYP_CSGCMCCMRx registers.
  5. 5. In the payload phase, write the initialization vector register values, previously saved in the memory, back into their corresponding CRYP_IVxL/R registers. In the header phase, write initial setting values back into the CRYP_IVxL/R registers.
  6. 6. Enable the CRYP peripheral by setting CRYPTEN.
  7. 7. If DMA is used, enable CRYP DMA requests, by setting DIEN (and DOEN if in payload phase).

37.4.14 AES key sharing with secure AES co-processor

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

The recommended sequence is described hereafter and in section SAES operations with shared keys in section Secure AES coprocessor (SAES) of this document.

  1. 1. In SAES peripheral, the application encrypts the key to share in shared-key mode (KMOD[1:0] at 0x2). When applicable, the proper CRYP instance must be selected through KSHAREID[1:0].
  2. 2. Each time the shared key is required in the CRYP peripheral, the application decrypts it in the SAES peripheral in shared-key mode (KMOD[1:0] at 0x2). When applicable, the proper CRYP instance must be selected through KSHAREID[1:0].
  3. 3. Once the shared key is decrypted and loaded in SAES_KEYRx registers it can be shared with CRYP. To load the shared key in CRYP, 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 CRYP_KxL/R registers and the BUSY flag in the CRYP_SR register set.
  4. 4. Once the key transfer is complete, the BUSY flag is cleared and the KEYVALID flag set in the CRYP_SR register. If KEYVALID is not set when BUSY bit is cleared, or if the KERF flag is set in the CRYP_SR register, it means that the KEYSIZE value is incorrect or an unexpected event occurred during the transfer (such as DPA error, tamper event or KEYVALID in SAES_SR 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 complete, the CRYP 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 CRYP 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.

When sharing keys KEYSIZE in CRYP must be identical to SAES value (128 or 256 bits).

37.4.15 CRYP data registers and data swapping

Data input and output

A 16-byte data block enters the CRYP peripheral with four successive 32-bit word writes into the CRYP_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 CRYP peripheral with four successive 32-bit word reads of the CRYP_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 345 “no swapping” option for details.

Data swapping

The CRYP peripheral can be configured to perform a bit-, a byte-, a half-word-, or no swapping on the input data word in the CRYP input FIFO, before loading it to the AES processing core, and on the data output from the AES processing core, before sending it to the CRYP output FIFO. 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]. The selection applies both to the input and the output of the CRYP, except in GCM/CCM final phase (data must be inserted normally).

Note: The data in CRYP key registers (CRYP_KxL/R) and initialization vector registers (CRYP_IVxL/R) are not sensitive to the swap mode selection.

The CRYP data swapping feature is summarized in Table 345 and Figure 388 .

Table 345. AES data swapping example

DATATYPE[1:0]Swapping performedData block
System memory data (big-endian)
0x0No swappingBlock[127..64]: 0x04EEF672 2E04CE96
Block[63..0]: 0x4E6F7720 69732074
Address @, word[127..96]: 0x04EE F672
Address @ + 0x4, word[95..64]: 0x2E04 CE96
Address @ + 0x8, word[63..32]: 0x4E6F 7720
Address @ + 0xC, word[31..0]: 0x6973 2074
0x1Half-word (16-bit) swappingBlock[63..0]: 0x 4E6F 7720 6973 2074
Address @, word[63..32]: 0x7720 4E6F
Address @ + 0x4, word[31..0]: 0x2074 6973
0x2Byte (8-bit) swappingBlock[63..0]: 0x 4E 6F 77 20 69 73 20 74
Address @, word[63..32]: 0x2077 6F4E
Address @ + 0x4, word[31..0]: 0x74 20 73 69
0x3Bit swappingBlock[63..32]: 0x4E6F 7720
0100 1110 0110 1111 0111 0111 0010 0000
Block[31..0]: 0x6973 2074
0110 1001 0111 0011 0010 0000 0111 0100
Address @, word[63..32]: 0x04EE F672
0000 0100 1110 1110 1111 0110 0111 0010
Address @ + 0x4, word[31..0]: 0x2E04 CE96
0010 1110 0000 0100 1100 1110 1001 0110
Figure 388. 128-bit block construction according to the data type Diagram showing 128-bit block construction for DATATYPE[1:0] = 00 (no swapping). It displays four words (Word 3, Word 2, Word 1, Word 0) with their respective bit ranges (D127-D96, D95-D64, D63-D32, D31-D0). Arrows indicate the order of write to CRYP_DINR / read from CRYP_DOUTR (1, 2, 3, 4). The data is mapped directly without swapping. Diagram showing 128-bit block construction for DATATYPE[1:0] = 01 (16-bit half-word swapping). Within each 32-bit word, the two 16-bit half-words are swapped. For example, in Word 3, bits D127..D112 and D111..D96 are swapped. Arrows indicate the order of write/read (1, 2, 3, 4). Diagram showing 128-bit block construction for DATATYPE[1:0] = 10 (8-bit byte swapping). Within each 32-bit word, the four 8-bit bytes are reversed in order. For example, in Word 3, the byte order is changed from (D127..D120, D119..D112, D111..D104, D103..D96) to (D103..D96, D111..D104, D119..D112, D127..D120). Arrows indicate the order of write/read (1, 2, 3, 4). Diagram showing 128-bit block construction for DATATYPE[1:0] = 11 (bit swapping). Within each 32-bit word, the order of all 32 bits is reversed. For example, in Word 0, D31 becomes the new D0 position and D0 becomes the new D31 position. Arrows indicate the order of write/read (1, 2, 3, 4).

DATATYPE[1:0] = 00: no swapping

DATATYPE[1:0] = 01: 16-bit (half-word) swapping

DATATYPE[1:0] = 10: 8-bit (byte) swapping

DATATYPE[1:0] = 11: bit swapping

Legend:

MSv43721V3

Diagram showing 128-bit block construction for DATATYPE[1:0] = 00 (no swapping). It displays four words (Word 3, Word 2, Word 1, Word 0) with their respective bit ranges (D127-D96, D95-D64, D63-D32, D31-D0). Arrows indicate the order of write to CRYP_DINR / read from CRYP_DOUTR (1, 2, 3, 4). The data is mapped directly without swapping. Diagram showing 128-bit block construction for DATATYPE[1:0] = 01 (16-bit half-word swapping). Within each 32-bit word, the two 16-bit half-words are swapped. For example, in Word 3, bits D127..D112 and D111..D96 are swapped. Arrows indicate the order of write/read (1, 2, 3, 4). Diagram showing 128-bit block construction for DATATYPE[1:0] = 10 (8-bit byte swapping). Within each 32-bit word, the four 8-bit bytes are reversed in order. For example, in Word 3, the byte order is changed from (D127..D120, D119..D112, D111..D104, D103..D96) to (D103..D96, D111..D104, D119..D112, D127..D120). Arrows indicate the order of write/read (1, 2, 3, 4). Diagram showing 128-bit block construction for DATATYPE[1:0] = 11 (bit swapping). Within each 32-bit word, the order of all 32 bits is reversed. For example, in Word 0, D31 becomes the new D0 position and D0 becomes the new D31 position. Arrows indicate the order of write/read (1, 2, 3, 4).

Data padding

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

37.4.16 CRYP key registers

The eight CRYP_KxR/LR write-only registers store the encryption or decryption key information, as shown in Table 346 . Reads are not allowed for security reason.

Note: In memory and in CRYP key registers, keys are stored in big-endian format, with most significant byte on the lowest address.

Table 346. Key endianness in CRYP_KxR/LR registers (128/192/256-bit keys)

K0LR[31:0]K0RR[31:0]K1LR[31:0]K1RR[31:0]K2LR[31:0]K2RR[31:0]K3LR[31:0]K3RR[31:0]
----k[127:96]k[95:64]k[63:32]k[31:0]
K0LR[31:0]K0RR[31:0]K1LR[31:0]K1RR[31:0]K2LR[31:0]K2RR[31:0]K3LR[31:0]K3RR[31:0]
--k[191:160]k[159:128]k[127:96]k[95:64]k[63:32]k[31:0]
K0LR[31:0]K0RR[31:0]K1LR[31:0]K1RR[31:0]K2LR[31:0]K2RR[31:0]K3LR[31:0]K3RR[31:0]
k[255:224]k[223:192]k[191:160]k[159:128]k[127:96]k[95:64]k[63:32]k[31:0]

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

Write operations to the CRYP_KxL/R registers are ignored when BUSY bit is 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 (in ascending order):

Note: KEYSIZE must be written before the key.

As soon as the first key register is written, the KEYVALID bit is cleared. Once the key registers writing sequence is complete, KEYVALID is set and CRYPTEN bit becomes writable. If an error occurs, KEYVALID is cleared and KERF set (see Section 37.4.18 ).

37.4.17 CRYP initialization vector registers

The four CRYP_IVxR/LR registers store the initialization vector (IVI) information, as shown in Table 347 . They can only be written if BUSY bit is cleared.

Note: In memory and in CRYP IVI registers, initialization vectors are stored in big-endian format, with most significant byte on the lowest address.

Table 347. Initialization vector endianness in CRYP_IVxR registers (AES)

CRYP_IV0L[31:0]CRYP_IV0R[31:0]CRYP_IV1L[31:0]CRYP_IV1R[31:0]
IVI[127:96]IVI[95:64]IVI[63:32]IVI[31:0]

Initialization vector information depend on the chaining mode selected. When used, CRYP_IVxR/LR 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 by DATATYPE[1:0].

37.4.18 CRYP error management

The CRYP peripheral manages the errors described in this section.

Key error flag (KERF)

There are multiple sources of errors that set the KERF flag and clear the KEYVALID bit of the CRYP_SR register:

Upon a key writing sequence error, KERF flag is cleared when a correct key writing sequence starts.

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

Note: For any key error, clear KERF flag prior to setting CRYPTEN.

37.5 CRYP interrupts

There are two individual maskable interrupt sources generated by the CRYP peripheral to signal the following events:

These sources are combined into a common interrupt signal from the CRYP peripheral that connects to the Arm ® Cortex ® interrupt controller. The application can enable or disable CRYP interrupt sources individually by setting/clearing the corresponding mask bit of the CRYP_IMSCR register. The status of the individual source of event flags can be read from the CRYP_SR register.

The global status of the two source of interrupts can be read either from the CRYP_RISR register (raw, that is unmasked), or from the CRYP_MISR register (masked).

Table 348 gives a summary of the available features.

Table 348. CRYP interrupt requests

Interrupt acronymInterrupt eventEvent flagEnable bitInterrupt clear method
in CRYP_xISR (1)in CRYP_SR
CRYPOutput FIFO fullOUTRIS (not masked)
OUTMIS (masked)
OFFUOUTIM (2) and
CRYPEN
Read one data from output FIFO
Output FIFO not emptyOFNERead all data from output FIFO
Input FIFO not fullINRIS (not masked)
INMIS (masked)
IFNFINIM (2) and
CRYPEN
Write data until input FIFO is full
Input FIFO emptyIFEMWrite at least one word in input FIFO

1. Flag of the CRYP_RISR register (unmasked or raw), or CRYP_MISR register (masked).

2. Bit of the CRYP_IMSCR register.

Output FIFO service interrupt (OUTMIS)

The output FIFO service interrupt is asserted when there is one or more (32-bit word) data items in the output FIFO. This interrupt is cleared by reading data from the output FIFO until there is no valid (32-bit) word left (that is, when the interrupt follows the state of the output FIFO not empty flag OFNE).

The output FIFO service interrupt OUTMIS is active also when CRYP is disabled.

Consequently, when CRYPEN bit is cleared, the OUTMIS bit is not cleared when the output FIFO is not empty.

Input FIFO service interrupt (INMIS)

The input FIFO service interrupt is asserted when there are less than four words in the input FIFO. It is cleared by performing write operations to the input FIFO until it holds four or more words.

The input FIFO service interrupt INMIS is active only when CRYP is enabled. Consequently, when CRYPEN bit is cleared, the INMIS bit stay low even if the input FIFO is empty.

37.6 CRYP DMA requests

The CRYP peripheral provides an interface to connect to the DMA (direct memory access) controller. The DMA operation is controlled through the DIEN and DOEN bits of the CRYP_DMAGR register.

Detailed usage of DMA with CRYP can be found in Appending data using the DMA subsection of Section 37.4.5: CRYP encryption/ decryption typical usage .

Data input using DMA

Setting DIEN enables DMA writing into CRYP. The CRYP then initiates, during the input phase, a DMA request for each 16-byte data block to write to the CRYP_DINR register (quadruple 32-bit word, MSB first).

The CRYP supports both single and burst DMA transfers. Recommended configuration is fixed burst size of four words.

CRYP issues a DMA transfer request to its input FIFO every time a 16-bytes block has been read from the FIFO.

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

Data output using DMA

Setting DOEN enables DMA reading from CRYP. The CRYP then initiates, during the output phase, a DMA request for each 16-byte data block to read from the CRYP_DOUTR register (quadruple 32-bit word, MSB first).

The CRYP supports both single and burst DMA transfers. Recommended configuration is fixed burst size of four words.

CRYP issues a DMA transfer request from output FIFO every time one 16-byte block has been written into the FIFO.

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 CRYP is disabled (CRYPEN cleared) or the DMA enable bit (DIEN for input data, DOEN for output data) is cleared.

37.7 CRYP processing time

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

Table 349. Processing latency for ECB, CBC and CTR

Key sizeMode of operationChaining algorithmClock cycles
128 bitsencryption or decryption (1)ECD, CBC, CTR14
key preparation-12
192 bitsencryption or decryption (1)ECD, CBC, CTR16
key preparation-14
256 bitsencryption or decryption (1)ECD, CBC, CTR18
key preparation-16

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

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

Key sizeMode of operationChaining algorithmInitialization phaseHeader phasePayload phaseFinal phase
128 bitsencryption or decryptionGCM24101414
CCM12142514
192 bitsGCM28101616
CCM14162916
256 bitsGCM32101818
CCM16183318

37.8 CRYP registers

These registers are accessible through 32-bit word single accesses only (otherwise an AHB error is generated, and write accesses are ignored).

37.8.1 CRYP control register (CRYP_CR)

Address offset: 0x00

Reset value: 0x0000 0000

31302928272625242322212019181716
IPRSTRes.Res.Res.Res.Res.KMOD[1:0]NPBLB[3:0]ALGOM
ODE[3]
Res.GCM_CCMPH
[1:0]
rwrwrwrwrwrwrwrwrwrw

1514131211109876543210
CRYPENFFLUSHRes.Res.Res.Res.KEYSIZE[1:0]DATATYPE[1:0]ALGOMODE[2:0]ALGODIRRes.Res.
rwrwrwrwrwrwrwrwrwrw

Bit 31 IPRST : CRYP peripheral software reset

Setting the bit resets the CRYP peripheral, putting all registers to their default values, except the IPRST bit itself.

This bit must be kept cleared while writing any configuration registers.

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

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

This bitfield defines how the CRYP 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 CRYP peripheral automatically loads its key registers with the data stored in the SAES key registers. The key value is available in CRYP key registers when BUSY bit is cleared and KEYVALID is set in the CRYP_SR register. Key error flag KERF is set otherwise in the CRYP_SR register.

Others: Reserved

Attempts to write the bitfield are ignored when BUSY is set.

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.

Attempts to write the bitfield are ignored when BUSY is set.

Bit 18 Reserved, must be kept at reset value.

Bits 17:16 GCM_CCMPH[1:0] : GCM or CCM phase selection

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

Attempts to write the bitfield are ignored when BUSY is set.

Bit 15 CRYPEN : CRYP enable

This bit enables/disables the CRYP peripheral.

0: CRYP disabled

1: CRYP enabled

This bit is automatically cleared by hardware upon the completion of the key preparation (ALGOMODE[3:0] at 0x7) and upon the completion of GCM/GMAC/CCM initialization phase. The bit cannot be set as long as KEYVALID is cleared.

Bit 14 FFLUSH : FIFO flush

This bit enables/disables the flushing of CRYP input and output FIFOs. Reading this bit always returns 0.

0: No effect

1: FIFO flush enabled

When CRYPEN is cleared, writing this bit to 1 flushes both input and output FIFOs (that is read and write pointers of the FIFOs are reset).

FFLUSH bit must be set when BUSY is cleared, otherwise the FIFO is flushed, but the block being processed may be pushed into the output FIFO just after the flush operation, resulting in a non-empty FIFO condition.

Attempts to write FFLUSH are ignored when CRYPEN is set.

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

Bits 9:8 KEYSIZE[1:0] : Key size selection

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

0x0: 128-bits

0x1: 192 bits

0x2: 256 bits

0x3: Reserved

When KEYSIZE is changed, KEYVALID bit is cleared.

Attempts to write the bitfield are ignored when BUSY is set.

Bits 7:6 DATATYPE[1:0] : Data type

This bitfield defines the format of data written in the CRYP_DINR register or read from the CRYP_DOUTR register, through selecting the mode of data swapping. This swapping is defined in Section 37.4.15: CRYP 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.

Bits 19, 5:3 ALGOMODE[3:0] : Algorithm mode

This bitfield selects the AES algorithm/chaining mode.

0x4: Electronic codebook (ECB)

0x5: Cipher Block Chaining (CBC)

0x6: Counter mode (CTR)

0x7: AES key preparation for ECB or CBC decryption

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

0x9: Counter with CBC-MAC (CCM)

Others: Reserved

Attempts to write the bitfield are ignored when BUSY is set.

Bit 2 ALGODIR : Algorithm direction

This bit selects the algorithm direction.

0: Encryption

1: Decryption

Attempts to write the bitfield are ignored when BUSY is set.

Bits 1:0 Reserved, must be kept at reset value.

37.8.2 CRYP status register (CRYP_SR)

Address offset: 0x04

Reset value: 0x0000 0003

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.KEY
VALID
KERFRes.BUSYOFFUOFNEIFNFIFEM
rrrrrrr

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

Bit 7 KEYVALID : Key valid flag

This read-only bit is set by hardware when the key of size defined by KEYSIZE is loaded in CRYP_KxR/LR key registers.

0: Key not valid

1: Key valid

The CRYPTEN 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 KERF flag is set and KEYVALID remains cleared.

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

If set, KERF must be cleared, otherwise KEYVALID cannot be set. For further information on key loading, refer to Section 37.4.16: CRYP key registers .

Bit 6 KERF : Key error flag

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

0: No key error detected

1: Key information failed to load into key registers

KERF is triggered upon any of the following errors:

KERF must be cleared by the application software, otherwise KEYVALID cannot be set. It can be done through IPRST bit of CRYP_CR, or when a correct key writing sequence starts.

Bit 5 Reserved, must be kept at reset value.

Bit 4 BUSY : Busy bit

This flag indicates whether CRYP is idle or busy.

0: Idle

1: Busy

CRYP is flagged as idle when disabled (CRYPTEN = 0) or when the AES core is not processing any data. It happens when the last processing has completed, or CRYP is waiting for enough data in the input FIFO or enough free space in the output FIFO (that is in each case at least 4 words).

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

Bit 3 OFFU : Output FIFO full flag

0: Output FIFO is not full

1: Output FIFO is full

Bit 2 OFNE : Output FIFO not empty flag

0: Output FIFO is empty

1: Output FIFO is not empty

Bit 1 IFNF : Input FIFO not full flag

0: Input FIFO is full

1: Input FIFO is not full

Bit 0 IFEM : Input FIFO empty flag

0: Input FIFO is not empty

1: Input FIFO is empty

37.8.3 CRYP data input register (CRYP_DINR)

Address offset: 0x08

Reset value: 0x0000 0000

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

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

A four-fold sequential write to this bitfield during the Input phase results in pushing a complete 16-byte block into the CRYP input FIFO. From the first to the fourth write, the corresponding data weights are [127:96], [95:64], [63:32], and [31:0].

Input FIFO can receive up to two 16-byte blocks of plaintext (when encrypting) or ciphertext (when decrypting).

If EN bit is set in CRYP_CR register, when at least four 32-bit words have been pushed into the input FIFO, and when at least four 32-bit words are free in the output FIFO, the CRYP automatically starts an encryption or decryption process, setting the BUSY bit.

Reading this register pops data off the input FIFO (oldest value is returned). The data present in the input FIFO are returned only if CRYPTEN is cleared (undefined value is returned otherwise). Following one or more reads the FIFO must be flushed (setting the FFLUSH bit) prior to processing new data.

37.8.4 CRYP data output register (CRYP_DOUTR)

Address offset: 0x0C

Reset value: 0x0000 0000

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

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

A four-fold sequential read to this bitfield during the output phase results in retrieving a complete 16-byte block from the CRYP output FIFO. From the first to the fourth read, the corresponding data weights are [127:96], [95:64], [63:32], and [31:0].

Output FIFO can store up to two 16-byte blocks of plaintext (when decrypting) or ciphertext (when encrypting).

When the output FIFO is empty a read returns an undefined value. Writes are ignored.

37.8.5 CRYP DMA control register (CRYP_DMACR)

Address offset: 0x10

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.Res.Res.DOENDIEN
rwrw

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

Bit 1 DOEN : DMA output enable

When this bit is set, DMA requests are automatically generated by the peripheral during the output data phase.

0: Outgoing data transfer from CRYP via DMA is disabled

1: Outgoing data transfer from CRYP via DMA is enabled

Bit 0 DIEN : DMA input enable

When this bit is set, DMA requests are automatically generated by the peripheral during the input data phase.

0: Incoming data transfer to CRYP via DMA is disabled

1: Incoming data transfer to CRYP via DMA is enabled

37.8.6 CRYP interrupt mask set/clear register (CRYP_IMSCR)

Address offset: 0x14

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.Res.Res.OUTIMINIM
rwrw

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

Bit 1 OUTIM : Output FIFO service interrupt mask

This bit enables or disables (masks) the CRYP output FIFO service interrupt generation when OUTRIS is set.

0: Output FIFO interrupt is disabled (masked), masked interrupt status (OUTMIS) stays cleared

1: Output FIFO interrupt is enabled (not masked)

Bit 0 INIM : Input FIFO service interrupt mask

This bit enables or disables (masks) the CRYP input FIFO service interrupt generation when INRIS is set.

37.8.7 CRYP raw interrupt status register (CRYP_RISR)

Address offset: 0x18

Reset value: 0x0000 0001

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.Res.Res.OUTRISINRIS
rr

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

Bit 1 OUTRIS : Output FIFO service raw interrupt status

This read-only bit is set by hardware when an output FIFO flag (OFFU or OFNE) is set in CRYP_SR register, regardless of the OUTIM mask bit value in CRYP_IMSCR register.

Bit 0 INRIS : Input FIFO service raw interrupt status

This read-only bit is set by hardware when an input FIFO flag (IFNF or IFEM) is set in CRYP_SR register, regardless of the INIM mask bit value in CRYP_IMSCR register.

37.8.8 CRYP masked interrupt status register (CRYP_MISR)

Address offset: 0x1C

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.Res.Res.OUTMISINMIS
rr

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

Bit 1 OUTMIS : Output FIFO service masked interrupt status

This read-only bit is set by hardware when an output FIFO flag (OFFU or OFNE) is set in CRYP_SR register. If the OUTIM mask bit is cleared in CRYP_IMSCR register, the OUTMIS bit stays cleared (masked).

0: No output FIFO event detected or OUTIM mask cleared in CRYP_IMSCR

1: Output FIFO full or not empty detected, with an interrupt pending

The OUTMIS bit is cleared by reading data from the output FIFO until OFNE flag is cleared (output FIFO empty). It is not cleared by disabling CRYP with CRYPTEN bit.

Bit 0 INMIS : Input FIFO service masked interrupt status

This read-only bit is set by hardware when an input FIFO flag (IFNF or IFEM) is set in CRYP_SR register. If the INIM mask bit is cleared in CRYP_IMSCR register, the INMIS bit stays cleared (masked).

0: No input FIFO event detected or INIM mask cleared in CRYP_IMSCR or CRYPTEN bit cleared.

1: Input FIFO empty or not full detected, with an interrupt pending

The INMIS bit is cleared by writing data to the input FIFO until IFEM flag is cleared (there is at least one word in input FIFO), or by clearing CRYPTEN,

When CRYP is disabled, INMIS bit stays low even if the input FIFO is empty.

37.8.9 CRYP key register 0L (CRYP_K0LR)

Address offset: 0x20

Reset value: 0x0000 0000

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

Bits 31:0 K[255:224] : Key bit x (x = 255 to 224)

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

Write to CRYP_KxR/LR registers is ignored when CRYP is busy (BUSY bit set). When key is coming from the SAES peripheral (KMOD[1:0] = 0x2), write is also ignored. With KMOD[1:0] at 0x0, a special writing sequence is required. In this sequence, any valid write to CRYP_KxR/LR 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 CRYP_SR register.

37.8.10 CRYP key register 0R (CRYP_K0RR)

Address offset: 0x24

Reset value: 0x0000 0000

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

Bits 31:0 K[223:192] : Key bit x (x = 223 to 192)

This write-only bitfield contains the bits [223:192] of the AES encryption or decryption key, depending on the operating mode.
Refer to the CRYP_K0LR register for information relative to writing CRYP_KxR/LR registers.

37.8.11 CRYP key register 1L (CRYP_K1LR)

Address offset: 0x28

Reset value: 0x0000 0000

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

Bits 31:0 K[191:160] : Key bit x (x = 191 to 160)

This write-only bitfield contains the bits [191:160] of the AES encryption or decryption key, depending on the operating mode.
Refer to the CRYP_K0LR register for information relative to writing CRYP_KxR/LR registers.

37.8.12 CRYP key register 1R (CRYP_K1RR)

Address offset: 0x2C

Reset value: 0x0000 0000

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

Bits 31:0 K[159:128] : Key bit x (x = 159 to 128)

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

Refer to the CRYP_K0LR register for information relative to writing CRYP_KxR/LR registers.

37.8.13 CRYP key register 2L (CRYP_K2LR)

Address offset: 0x30

Reset value: 0x0000 0000

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

Bits 31:0 K[127:96] : Key bit x (x = 127 to 96)

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

Refer to the CRYP_K0LR register for information relative to writing CRYP_KxR/LR registers.

37.8.14 CRYP key register 2R (CRYP_K2RR)

Address offset: 0x34

Reset value: 0x0000 0000

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

Bits 31:0 K[95:64] : Key bit x (x = 95 to 64)

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

Refer to the CRYP_K0LR register for information relative to writing CRYP_KxR/LR registers.

37.8.15 CRYP key register 3L (CRYP_K3LR)

Address offset: 0x38

Reset value: 0x0000 0000

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

Bits 31:0 K[63:32] : Key bit x (x = 63 to 32)

This write-only bitfield contains the bits [63:32] of the AES encryption or decryption key, depending on the operating mode.
Refer to the CRYP_K0LR register for information relative to writing CRYP_KxR/LR registers.

37.8.16 CRYP key register 3R (CRYP_K3RR)

Address offset: 0x3C

Reset value: 0x0000 0000

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

Bits 31:0 K[31:0] : Key bit x (x = 31 to 0)

This write-only bitfield contains the bits [31:0] of the AES encryption or decryption key, depending on the operating mode.
Refer to the CRYP_K0LR register for information relative to writing CRYP_KxR/LR registers.

37.8.17 CRYP initialization vector register 0L (CRYP_IV0LR)

Address offset: 0x40

Reset value: 0x0000 0000

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

Bits 31:0 IVI[127:96] : Initialization vector bit x (x = 127 to 96)

This bitfield stores the initialization vector bits [127:96] for AES chaining modes other than ECB.

The value stored in CRYP_IVxR/LR registers is updated by hardware after each computation round (when applicable).

Write to this register is ignored when CRYP is busy (BUSY bit set).

37.8.18 CRYP initialization vector register 0R (CRYP_IV0RR)

Address offset: 0x44

Reset value: 0x0000 0000

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

Bits 31:0 IVI[95:64] : Initialization vector bit x (x = 95 to 64)

This bitfield stores the initialization vector bits [95:64] for AES chaining modes other than ECB.

The value stored in CRYP_IVxR/LR registers is updated by hardware after each computation round (when applicable).

Write to this register is ignored when CRYP is busy (BUSY bit set).

37.8.19 CRYP initialization vector register 1L (CRYP_IV1LR)

Address offset: 0x48

Reset value: 0x0000 0000

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

Bits 31:0 IVI[63:32] : Initialization vector bit x (x = 63 to 32)

This bitfield stores the initialization vector bits [63:32] for AES chaining modes other than ECB.

The value stored in CRYP_IVxR/LR registers is updated by hardware after each computation round (when applicable).

Write to this register is ignored when CRYP is busy (BUSY bit set).

37.8.20 CRYP initialization vector register 1R (CRYP_IV1RR)

Address offset: 0x4C

Reset value: 0x0000 0000

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

Bits 31:0 IVI[31:0] : Initialization vector bit x (x = 31 to 0)

This bitfield stores the initialization vector bits [31:0] for AES chaining modes other than ECB.

The value stored in CRYP_IVxR/LR registers is updated by hardware after each computation round (when applicable).

Write to this register is ignored when CRYP is busy (BUSY bit set).

37.8.21 CRYP context swap GCM-CCM registers (CRYP_CSGCMCCMxR)

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

Reset value: 0x0000 0000

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

Bits 31:0 CSGCMCCM[31:0] : Context swap for GCM/GMAC and CCM modes

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

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

37.8.22 CRYP context swap GCM registers (CRYP_CSGCMxR)

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

Reset value: 0x0000 0000

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

Bits 31:0 CSGCM[31:0] : Context swap for GCM/GMAC modes

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

CRYP_CSGCMxR registers are not used in other chaining modes than GCM or GMAC.

37.8.23 CRYP register map

Table 351. CRYP register map and reset values

OffsetRegister name313029282726252423222120191817161514131211109876543210
0x00CRYP_CRIPRSTRes.Res.Res.Res.Res.KMOD[1:0]Res.Res.NPBLB[3:0]Res.Res.ALGOMODE[3]Res.GCM_CCMPH[1:0]Res.CRYPENFFLUSHRes.Res.Res.Res.KEYSIZE[1:0]Res.DATATYPE[1:0]Res.ALGOMODE[2:0]Res.ALGODIRRes.Res.
Reset value00 00 0 0 000 0000 00 00 0 00
0x04CRYP_SRRes.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.Res.KEYVALIDKERFRes.BUSYOFFUOFNEIFNFIFEM
Reset value0000011
0x08CRYP_DINRDIN[31:0]
Reset value00000000000000000000000000000000
0x0CCRYP_DOUTRDOUT[31:0]
Reset value00000000000000000000000000000000
0x10CRYP_DMACRRes.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.DOENDIEN
Reset value00
0x14CRYP_IMSCRRes.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.OUTIMINIM
Reset value00

Table 351. CRYP register map and reset values (continued)

OffsetRegister name313029282726252423222120191817161514131211109876543210
0x18CRYP_RISRRes.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.OUTRISINRIS
Reset value01
0x1CCRYP_MISRRes.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.OUTMISINMIS
Reset value00
0x20CRYP_K0LRK[255:224]
Reset value00000000000000000000000000000000
0x24CRYP_K0RRK[223:192]
Reset value0000000000000000000000000000000
0x38CRYP_K3LRK[63:32]
Reset value0000000000000000000000000000000
0x3CCRYP_K3RRK[31:0]
Reset value0000000000000000000000000000000
0x40CRYP_IV0LRIV[127:96]
Reset value0000000000000000000000000000000
0x44CRYP_IV0RRIV[95:64]
Reset value0000000000000000000000000000000
0x48CRYP_IV1LRIV[63:32]
Reset value0000000000000000000000000000000
0x4CCRYP_IV1RRIV[31:0]
Reset value0000000000000000000000000000000
0x50 + x*
0x4, (x = 0
to 7), last
address
0x6C
CRYP_CSGCMCCMxRCSGCMCCMx[31:0]
Reset value0000000000000000000000000000000
0x70 + x*
0x4, (x = 0
to 7), last
address
0x8C
CRYP_CSGCMxRCSGCMx[31:0]
Reset value0000000000000000000000000000000

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