STM32L486: Trouble decrypting AES-256 ECB data but OK with encrypting??

[Jennifer D]

Posted on July 21, 2017 at 15:49

Hi all :

I am using the STM32L4xx Stm Cube drivers for AES-256 ECB encryption on the STM32L4 Although the encrypted data comes out perfectly, the decrypted encrypted data is not the original plaintext. To be clear: I am not using the X crypto library, but instead the

https://github.com/labapart/polymcu/blob/master/Device/ST/STM32L4xx_HAL_Driver/Inc/stm32l4xx_hal_cryp.h

and

https://github.com/labapart/polymcu/blob/master/Device/ST/STM32L4xx_HAL_Driver/Inc/stm32l4xx_hal_cryp_ex.h

modules that are included in the from the STM Cube STM32L4xx HAL Drivers.

Some info about the code:

-The MX_AES_Init function uses

HAL_CRYP_Init to initialize the AESmodule

- I am using this API to encrypt and decrypt data:

HAL_CRYP_AESECB_Encrypt_IT

-After the encryption, I deinit the AES module change the operating mode to decrypt and re init using the HAL init function

- I tried setting the original operating mode to decrypt and feeding in the encrypted output, but I get the same incorrect decrypted data instead of the original plaintext I added .

When I try to decrypt the cipher_text array back to the plain_text array it doesn't work, but the encrypted data is correct according to

http://www.cryptogrium.com/aes-encryption-online-ecb.html

.

uint8_t plain_text[64] =

{ 0x6b, 0xc1, 0xbe, 0xe2, 0x2e, 0x40, 0x9f, 0x96, 0xe9, 0x3d, 0x7e, 0x11, 0x73, 0x93, 0x17, 0x2a, 0xae, 0x2d, 0x8a, 0x57, 0x1e, 0x03, 0xac, 0x9c, 0x9e, 0xb7, 0x6f, 0xac, 0x45, 0xaf, 0x8e, 0x51, 0x30, 0xc8, 0x1c, 0x46, 0xa3, 0x5c, 0xe4, 0x11, 0xe5, 0xfb, 0xc1, 0x19, 0x1a, 0x0a, 0x52, 0xef, 0xf6, 0x9f, 0x24, 0x45, 0xdf, 0x4f, 0x9b, 0x17, 0xad, 0x2b, 0x41, 0x7b, 0xe6, 0x6c, 0x37, 0x10 };

uint8_t Key[32] =

{ 0x60, 0x3d, 0xeb, 0x10, 0x15, 0xca, 0x71, 0xbe, 0x2b, 0x73, 0xae, 0xf0, 0x85, 0x7d, 0x77, 0x81, 0x1f, 0x35, 0x2c, 0x07, 0x3b, 0x61, 0x08, 0xd7, 0x2d, 0x98, 0x10, 0xa3, 0x09, 0x14, 0xdf, 0xf4, };

const uint8_t ciphertext[64] =

{ 0xf3, 0xee, 0xd1, 0xbd, 0xb5, 0xd2, 0xa0, 0x3c, 0x06, 0x4b, 0x5a, 0x7e, 0x3d, 0xb1, 0x81, 0xf8, 0x59, 0x1c, 0xcb, 0x10, 0xd4, 0x10, 0xed, 0x26, 0xdc, 0x5b, 0xa7, 0x4a, 0x31, 0x36, 0x28, 0x70, 0xb6, 0xed, 0x21, 0xb9, 0x9c, 0xa6, 0xf4, 0xf9, 0xf1, 0x53, 0xe7, 0xb1, 0xbe, 0xaf, 0xed, 0x1d, 0x23, 0x30, 0x4b, 0x7a, 0x39, 0xf9, 0xf3, 0xff, 0x06, 0x7d, 0x8d, 0x8f, 0x9e, 0x24, 0xec, 0xc7 };

Not sure what to do next....Thanks in advance for any help.##

#aes #encryption #crypto-aes-encrypt-stm32 #stm32l486 #crypto-aes-decrypt #aes-256 Note: this post was migrated and contained many threaded conversations, some content may be missing.

[LMI2]

Posted on July 27, 2017 at 17:13

This is still active? Now I can say what was the first thought in my mind. It is very easy to encrypt something, I have done several encrypters. But decrypters are a  scarse resource. I have made only one matching my encrypter.

But have no fear. Backup are made by the NSA. After all, ST got some kind of certificate for the module from USA/NSA? (There was an announcement about that in the former forum.)

[Tesla DeLorean]

Posted on July 27, 2017 at 18:14

This is a whole lot of nonsense. The NSA/GCHQ might well know of weakness in the algorithm, and ECB would certainly make you prone to simpler cryptanalysis, but AES is an open standard, the code is open, and there's no where to stuff/hide out-of-band data. Pretty much any nation state is recording internet traffic in some form or fashion, to think otherwise is delusional. End-to-End encryption certainly makes the job of doing anything with the data orders of magnitude more difficult, which is why so many governments seek to interfere with private communications, and limit its application.

Crypto requires an export license in the US to ship outside, ST is a European company and this tech seems to have no problem getting into the hands of Iran, North Korea, China, et al. I can likely buy ST crypto parts out of China from eBay easier than I can from Mouser/DigiKey.

ST does FIPS certification because it proves the thing does the test cases properly, but you'd kind of want your AES to perform AES properly, right? Inherent weakness are going to be there however you try to bake it.

[STOne-32]

Posted on July 27, 2017 at 23:38

Dear all, 

Our certified CAVP NIST algorithms are based on pure software implementation to be the same for all STM32 MCUs even not including the HW acceleration such as AES-256 described on top of this thread. Back, To original message,  Our moderators will be back to You ASAP after full analysis what is going wrong with the decryption. 

Cheers 

STOne -32 

[Jennifer D]

Posted on July 27, 2017 at 23:44

Thanks you STOne-32. Yes I am the ECB firmware encryption for the STM32lL486

[Amel NASRI · Accepted solution]

Posted on August 02, 2017 at 19:02

Hi

‌,

Tests are made on an STM32L486 device using the same configuration as yours and the decryption process worked as expected.

I attach to this post the code used for our test. Could you please use it and let us know the result?

It will be interesting also to share your .ioc file + your updated main.c file.

This should help us to do further checks.

-Amel

________________ Attachments : main_ecb.c.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HySk&d=%2Fa%2F0X0000000b9B%2F1HAi5wE7NFyS.KFUua7Sb43QFIRDfWhY0WiSUK_Tt6E&asPdf=false

[Jennifer D]

Posted on August 31, 2017 at 18:48

Hi Amel, 

Thanks for the help. I wasn't waiting until the AES encryption state was ready. Thanks again!

Jennifer