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.

[Tesla DeLorean]

Posted on July 23, 2017 at 03:37

Data does appear to be correct for AES-ECB, I don't have an STM32L486 to tinker with. Perhaps you can create a free-standing example that compiles?

[Jennifer D]

Posted on July 23, 2017 at 19:44

Hi Clive One - 

I did try a free standing example with an array of the encrypted data and the key from above and I get the same incorrect decrypted data. I went as far as to look at the data in memory in both builds and even there it is incorrect (but always the same incorrect decrypted data). This makes me feel like theres a bug in the drivers? Or maybe I need to do something with the decrypted data after running the API function?? But that doesn't make sense to me either. 

Thanks for the help.

-Jennifer

[Tesla DeLorean]

Posted on July 23, 2017 at 20:35

It's hard for me to debug remotely and blind, if the API was a complete bust for encrypt-decrypt cycle then I suspect to see a lot more forum traffic. That said the chips with the encryption engine have a much more limited user base. The AES engine in the F215 performed quite robustly. One would hope that ST did at least some minimal functional testing of the library/API.

[Jennifer D]

Posted on July 26, 2017 at 22:42

DAHMEN.IMEN

‌ Could you help me with this?

[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]

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