Problem with ST cryptographic library (CMOX) AES CBC encryption
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2024-09-10 06:23 AM
We are doing updates on a project which uses STM32H747 and ST cryptographic library (CMOX) / X-CUBE-CRYPTOLIB. It encrypts and decrypts data using these two functions:
- cmox_cipher_encrypt(CMOX_AES_CBC_ENC_ALGO, ....
- cmox_cipher_decrypt(CMOX_AES_CBC_DEC_ALGO, ...
The project requires some refactoring and while doing that, odd things appeared, such as:
- There is an "initialization sequence" of doing a dummy encrypt and decrypt. No real initialization function is called.
- The key is 256 bit and data is aligned to 256 bits / 32 bytes, but IV is 128 bits.
But the main problem is that sometimes encryption creates bad cipher. I compared it with AES tools on the PC. It tends to happen on the first real encryption, not during "initialization". I know that when refactoring code, it is likely that something break it, but a lot has been done to figure it out, such as:
- Code review of changes.
- Googling.
- Upgrading the library to latest v4.2.0 (but only header files changed, precompiled library was same).
- Verifying that CRC-32 peripheral is activated
- Checking and increasing stack memory.
- Checking and increasing heap memory.
- Disabling data cache.
- Disable CPU speculative mode.
- Disabling interrupts during encryption.
- Using lowest compiler optimization.
Didn't find a pattern for failure.
What troubles me is those two odd things. It looks like previous developer hit some issue also and made a workaround. So maybe the change just unmasked the hidden issue. So I tried to sort it out. I called cmox_initialize prior to dummy encrypt, no help. I also used 256-bit IV but then the encryption function returns CMOX_CIPHER_ERR_BAD_PARAMETER. When I used 128-bit key and IV the function tells it's okay, but it still fails to encrypt properly sometimes. Since it's precompiled code, it is not easy to debug the reason behind it.
What also bothers me is lack of clear block size selection (AES128, AES192, AES256), unclarity in documentation and redundancy in implementation - one can technically tell encryption function to use decryption algorithm:
- cmox_cipher_encrypt(CMOX_AES_CBC_DEC_ALGO, ....
The workaround right now is to decrypt every encrypted message and if there's a mismatch, repeat again. This is obviously inefficient solution.
- Labels:
-
Bug-report
-
Cryptography
-
STM32 Security
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
2024-09-10 08:48 AM
Hello @mkrk,
Regarding sizes. The AES block size is always 128 bits whatever the key size.
This means that IV is always 128 bits and data only need 128 bits alignment.
Do you have a code snippet or small project that allows reproducing your issue ?
Best regards
Jocelyn