Skip to content

drivers: crypto: stm32: h7: add AES CCM and GCM support#93189

Open
GeorgeCGV wants to merge 11 commits intozephyrproject-rtos:mainfrom
GeorgeCGV:stm32_crypto_h7_aes_ccm_gcm
Open

drivers: crypto: stm32: h7: add AES CCM and GCM support#93189
GeorgeCGV wants to merge 11 commits intozephyrproject-rtos:mainfrom
GeorgeCGV:stm32_crypto_h7_aes_ccm_gcm

Conversation

@GeorgeCGV
Copy link
Contributor

@GeorgeCGV GeorgeCGV commented Jul 16, 2025

Adds support for AES-CCM and AES-GCM cipher modes.

The support is limited to the following STM32 H7 SoCs:
STM32H723XX, STM32H725XX, STM32H730XX, STM32H730XXQ, and STM32H735XX, as they share the same reference manual.

Note: testing was performed on the STM32H730XX.

Crypto sample output:

Cipher Sample
ECB Mode
Output length (encryption): 16
ECB mode ENCRYPT - Match
Output length (decryption): 16
ECB mode DECRYPT - Match
CBC Mode
Output length (encryption): 80
CBC mode ENCRYPT - Match
Output length (decryption): 64
CBC mode DECRYPT - Match
CTR Mode
Output length (encryption): 64
CTR mode ENCRYPT - Match
Output length (decryption): 64
CTR mode DECRYPT - Match
CCM Mode
Output length (encryption): 23
CCM mode ENCRYPT - Match
Output length (decryption): 23
CCM mode DECRYPT - Match
GCM Mode
Output length (encryption): 42
GCM mode ENCRYPT - Match
Output length (decryption): 42
GCM mode DECRYPT - Match

The pull request is open for review but not yet ready to be merged (therefore, labeled DNM) due to an issue in the STM32 H7 HAL related to GCM tag generation during decryption: STMicroelectronics/stm32h7xx-hal-driver#88.

@github-actions github-actions bot requested review from ceolin and erwango July 16, 2025 09:53
@GeorgeCGV GeorgeCGV added the DNM This PR should not be merged (Do Not Merge) label Jul 16, 2025
@GeorgeCGV GeorgeCGV force-pushed the stm32_crypto_h7_aes_ccm_gcm branch 2 times, most recently from 55c625f to 6aa8470 Compare July 16, 2025 10:07
@GeorgeCGV GeorgeCGV force-pushed the stm32_crypto_h7_aes_ccm_gcm branch from 6aa8470 to 167348a Compare July 22, 2025 08:12
@zephyrbot zephyrbot requested a review from etienne-lms July 22, 2025 08:13
@GeorgeCGV GeorgeCGV force-pushed the stm32_crypto_h7_aes_ccm_gcm branch 2 times, most recently from 9c47b93 to e494b35 Compare July 22, 2025 12:36
@GeorgeCGV GeorgeCGV requested a review from mathieuchopstm July 22, 2025 13:13
Copy link
Contributor

@mathieuchopstm mathieuchopstm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if, instead of hardcoded SoCs in Kconfig, we shouldn't create a new compatible for the IP embedded in H7, as it is also used on other series so the code can probably shared (e.g., STM32F72xx/F73xx).

This can always be integrated later, so OK for me in current state..

@GeorgeCGV GeorgeCGV force-pushed the stm32_crypto_h7_aes_ccm_gcm branch from e494b35 to 420a6b9 Compare July 22, 2025 15:20
@GeorgeCGV
Copy link
Contributor Author

I'm wondering if, instead of hardcoded SoCs in Kconfig, we shouldn't create a new compatible for the IP embedded in H7, as it is also used on other series so the code can probably shared (e.g., STM32F72xx/F73xx).

Ideally, as more boards are tested and the necessary adjustments are made, this condition will no longer be needed. It is mainly here because testing is performed on the STM32H730XX, which shares the same RM with STM32H723XX, STM32H725XX, STM32H730XXQ, and STM32H735XX.

mathieuchopstm
mathieuchopstm previously approved these changes Jul 22, 2025
Copy link
Member

@erwango erwango left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if, instead of hardcoded SoCs in Kconfig, we shouldn't create a new compatible for the IP embedded in H7, as it is also used on other series so the code can probably shared (e.g., STM32F72xx/F73xx).

It will be harder to impose to the next ones if this is done this way today. Let's do it now.

@GeorgeCGV
Copy link
Contributor Author

@erwango @mathieuchopstm reworked the memory comparison approach.
The Kconfig no longer has dependencies on any particular SoC.

I guess depending on mbedtls is ok for ct memcmp.

@erwango
Copy link
Member

erwango commented Jul 24, 2025

The Kconfig no longer has dependencies on any particular SoC.

It still does actually. Did you push the right branch ?

@GeorgeCGV
Copy link
Contributor Author

GeorgeCGV commented Jul 29, 2025

The Kconfig no longer has dependencies on any particular SoC.

It still does actually. Did you push the right branch ?

Do you mean? (.c, not Kconfig)

#if defined(CONFIG_SOC_STM32H723XX) || defined(CONFIG_SOC_STM32H725XX) ||	\
	defined(CONFIG_SOC_STM32H730XX) || defined(CONFIG_SOC_STM32H730XXQ) ||	\
	defined(CONFIG_SOC_STM32H735XX)
#define STM32_CRYPTO_GCM_CCM_SUPPORT 1
#endif

The most recent push to Kconfig includes a new option that relies on the mbedtls.

mathieuchopstm
mathieuchopstm previously approved these changes Oct 21, 2025
etienne-lms
etienne-lms previously approved these changes Oct 22, 2025
Copy link
Contributor

@etienne-lms etienne-lms left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry for the late feedback. Looks all good to me.

@erwango
Copy link
Member

erwango commented Oct 22, 2025

@GeorgeCGV Can you confirm this is still blocked at HAL level ? (Hence the DNM)

@GeorgeCGV
Copy link
Contributor Author

GeorgeCGV commented Oct 24, 2025

@erwango yes, unfortunately. No updates from ST regarding the HAL issue - STMicroelectronics/stm32h7xx-hal-driver#88.
Perhaps the DNM can be removed to facilitate the identification of issues in other families. On H7, the GCM won't work entirely, but CCM does.

@GeorgeCGV GeorgeCGV dismissed stale reviews from etienne-lms and mathieuchopstm via 1545157 October 29, 2025 11:39
@GeorgeCGV GeorgeCGV force-pushed the stm32_crypto_h7_aes_ccm_gcm branch from 2d11890 to 1545157 Compare October 29, 2025 11:39
@GeorgeCGV
Copy link
Contributor Author

Rebased

@etienne-lms
Copy link
Contributor

For info, the issue in the HAL has been addressed internally. Hopefully to be available in the next HAL release.

In the meantime, @GeorgeCGV, do you want to have at least CCM functional and introduce a st,ccm-supported DT property enable the feature on H7?

For info, I've been through the STM32 SoCs series and those that have a CRYP instance actually support GCM and CCM. The issue for extending your changes to all SoCs is that some SOCs have specific HAL APIs that do not match the H7 ones you used in your implementation here. Once crypto_stm32.c driver adapted done, we would be able to fully remove the gcm-ccm-supported DT property.

Saying that, I realize that maybe your patch could enable STM32_CRYPTO_GCM_CCM_SUPPORT (in crypto_stm32.c) only for known supported SoCs (that is currently when CONFIG_SOC_SERIES_STM32H7X=y) and removing DT property gcm-ccm-supported.

@mathieuchopstm mathieuchopstm added this to the v4.4.0 milestone Oct 30, 2025
@GeorgeCGV
Copy link
Contributor Author

GeorgeCGV commented Dec 18, 2025

@etienne-lms, there is no rush to upstream this.

Saying that, I realize that maybe your patch could enable STM32_CRYPTO_GCM_CCM_SUPPORT (in crypto_stm32.c) only for known supported SoCs (that is currently when CONFIG_SOC_SERIES_STM32H7X=y) and removing DT property gcm-ccm-supported.

This is how it used to be at the beginning of the PR. The discussions then led to the creation of the DT property.

GeorgeCGV and others added 11 commits December 18, 2025 10:39
Device semaphore handling is being moved out of the do_aes function.
This is necessary to support upcoming GCM and CCM modes,
which require the semaphore to be held during tag generation.

Signed-off-by: Georgij Černyšiov <geo.cgv@gmail.com>
Marks default case for cipher mode as unreachable.

Signed-off-by: Georgij Černyšiov <geo.cgv@gmail.com>
Adds a gcm-ccm-supported property to the crypto driver.
This allows to enable or disable support for AES GCM and CCM,
providing flexibility to remove the functionality
if it's not needed.

Signed-off-by: Georgij Černyšiov <geo.cgv@gmail.com>
Enables AES GCM and CCM support for the crypto driver.

Signed-off-by: Georgij Černyšiov <geo.cgv@gmail.com>
Adds AES GCM and CCM support for:
* H723XX
* H725XX
* H730XX, H730XXQ
* H735XX

Note: To use CCM with additional authenticated data (AD),
the heap memory pool size must be large enough to
accommodate the AD length, rounded up to the nearest
multiple of 16 bytes. For an AD length of 8 bytes,
the heap size must be at least 16 bytes. For an AD
length of 17 bytes, you'll need at least 32 bytes.

Signed-off-by: Georgij Černyšiov <geo.cgv@gmail.com>
* Use if, endif to scope the configuration options.
* Add an option to use mbedtls_ct_memcmp instead of memcmp.

Signed-off-by: Georgij Černyšiov <geo.cgv@gmail.com>
Adds constant time comparison to replace memcmp.

Co-Authored-By: Etienne Carriere <etienne.carriere@st.com>
Signed-off-by: Georgij Černyšiov <geo.cgv@gmail.com>
Enables crypto peripheral for the board.

Signed-off-by: Georgij Černyšiov <geo.cgv@gmail.com>
Enables AES GCM and CCM support for the crypto driver.

Signed-off-by: Georgij Černyšiov <geo.cgv@gmail.com>
Enables AES GCM and CCM support for the crypto driver.

Signed-off-by: Georgij Černyšiov <geo.cgv@gmail.com>
The AES CCM AD (Additional Authenticated Data) relies on
dynamic memory allocation, the heap memory pool size
must be greater than zero.

This commit sets the heap memory one block size when you
enable crypto with CCM support. This ensures that the crypto
sample can be built and run.

Signed-off-by: Georgij Černyšiov <geo.cgv@gmail.com>
@GeorgeCGV GeorgeCGV force-pushed the stm32_crypto_h7_aes_ccm_gcm branch from 1545157 to f247a32 Compare December 18, 2025 09:55
@zephyrbot zephyrbot requested a review from juickar December 18, 2025 09:57
@GeorgeCGV
Copy link
Contributor Author

Rebased, and a minor ccm fix: gcm_params were used at one place instead of ccm_params.

@GeorgeCGV
Copy link
Contributor Author

GeorgeCGV commented Jan 15, 2026

A new issue STMicroelectronics/stm32h7xx-hal-driver#104 has been discovered in the CubeH7 HAL related to the AES CCM.

Fixing this inside the driver is not practical, because it would require allocating an aligned copy of the payload, which adds unnecessary overhead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

6 participants