X-CUBE-CRYPTOLIB computed SHA256 hash wrong

[Martin42]

Hello,

I would like to use the X-CUBE-CRYPTOLIB to calculate a SHA256 with a key. My implementation or the example HMAC_SHA2_AuthenticateVerify works in STM32CubeIDE 1.13.1 for an STM32L432KCU microcontroller.

Source: https://www.st.com/en/embedded-software/x-cube-cryptolib.html

To rule out the possibility that the example project has implemented something that I forgot to copy into Atollic Studio, I created a new project in STM32CubeIDE and integrated the X-CUBE-CRYPTOLIB there as I did in Atollic Studio. The hash was calculated correctly there.

Now my problem:

The development environment Atollic TrueSTUDIO for STM32 9.3.0 is used for an existing project. I would like to use the X-CUBE-CRYPTOLIB there. If I put the "simple" example there, then the hash is calculated incorrectly.

The error occurs on the line if (memcmp(Expected_Tag, Computed_Tag, computed_size) != 0) because the Computed_Tag was not calculated correctly.

What could be the reason?

  /* Initialize cryptographic library */
  if (cmox_initialize(NULL) != CMOX_INIT_SUCCESS)
  {
    Error_Handler();
  }

  /* --------------------------------------------------------------------------
   * SINGLE CALL USAGE
   * --------------------------------------------------------------------------
   */

  /* Compute directly the authentication tag passing all the needed parameters */
  retval = cmox_mac_compute(CMOX_HMAC_SHA256_ALGO,     /* Use HMAC SHA256 algorithm */
                            Message, sizeof(Message),  /* Message to authenticate */
                            Key, sizeof(Key),          /* HMAC Key to use */
                            NULL, 0,                   /* Custom data */
                            Computed_Tag,              /* Data buffer to receive generated authnetication tag */
                            sizeof(Expected_Tag),      /* Expected authentication tag size */
                            &computed_size);           /* Generated tag size */

  /* Verify API returned value */
  if (retval != CMOX_MAC_SUCCESS)
  {
    Error_Handler();
  }

  /* Verify generated data size is the expected one */
  if (computed_size != sizeof(Expected_Tag))
  {
    Error_Handler();
  }

  /* Verify generated data are the expected ones */
  if (memcmp(Expected_Tag, Computed_Tag, computed_size) != 0)
  {
    Error_Handler();
  }

  /* Verify directly the message passing all the needed parameters */
  retval = cmox_mac_verify(CMOX_HMAC_SHA256_ALGO,     /* Use HMAC SHA256 algorithm */
                           Message, sizeof(Message),  /* Message to authenticate */
                           Key, sizeof(Key),          /* HMAC Key to use */
                           NULL, 0,                   /* Custom data */
                           Expected_Tag,              /* Authentication tag */
                           sizeof(Expected_Tag));     /* tag size */

  /* Verify API returned value */
  if (retval != CMOX_MAC_AUTH_SUCCESS)
  {
    Error_Handler();
  }

computed  

[Tesla DeLorean]

Is the CRC Peripheral clock enabled?

[Martin42]

Do you mean that with CRC Peripheral clock?

With STM32CubeIDE 1.13.1 it doesn't matter whether this is activated or not. The correct hash always comes out.

[Tesla DeLorean]

ST frequently ties their software to STM32 hardware via test patterns it queries against the CRC unit.

[Martin42]

I have the firmware running on the same board.

Is it possible that the library works differently with the new compiler?

[STea]

Hello @Martin42 ,

as mentioned by tesla you need to make sure that the CRC is activated you can also deactivate the FPU implementation and select a pure software implementation for the cryptolib.

Check also the selected complier target of the library you are including in the cryptolib config.h file and make sure the GCC compiler is selected this should work in Atollic TrueSTUDIO for STM32 9.3.0 if it is working with cubeIde I think as they are both based on GCC. Make sure you are selecting the proper library for your project as the library is distributed with different compiled versions for different compilers and different cortex. Don't forget to check for your compiler optimization also because it may affect the results depending on the version of the lib you are including high speed or high size optimization. check this video for more details.

You can refer to this tutorial to get to know more about the proper way to integrate Cryptolib into your project.

BR

[Tesla DeLorean]

Perhaps make the code more free standing and compliable. With the test patterns and test data.

You could also submit as an Online Support Request from the support page.

[Martin42]

Hello,

thanks for the answers.

I tried again to implement an ECDSA calculation in Atollic TrueSTUDIO 9.3. To do this, I first implemented it in STM32CubeIDE 1.13.1, which is calculated correctly so far.

Unfortunately, the calculation in Atollic TrueSTUDIO 9.3 is again wrong when checking "

/* Verify generated data are the expected ones */" 
memcmp(Computed_Signature, Known_Signature, computed_size) != 0)

Now I have set the FPU implementation to software implementation.

Then I get the compiler error message:

C:\Users\SCHEIT~1\AppData\Local\Temp\ccfOhuhd.s:799: Error: selected processor does not support `vstmdbeq r0!,{s16-s31}' in Thumb mode
C:\Users\SCHEIT~1\AppData\Local\Temp\ccfOhuhd.s:801: Error: instruction not allowed in IT block -- `stmdb r0!,{r4-r11,r14}'
C:\Users\SCHEIT~1\AppData\Local\Temp\ccfOhuhd.s:821: Error: selected processor does not support `vldmiaeq r0!,{s16-s31}' in Thumb mode
C:\Users\SCHEIT~1\AppData\Local\Temp\ccfOhuhd.s:823: Error: instruction not allowed in IT block -- `msr psp,r0'

I guess I misunderstood how to set it up, right?

In STM32CubeIDE 1.13.1 i have the Floating Point set to Hardware implementation and it works.

[Tesla DeLorean]

Well it's complaining that the intermediate .S file it's generated has FPU instructions in the stream for some reason. Could be a tools or caching issue, or necessitating a "Rebuild All" scenario as the goal posts have moved, and it should rebuild the dependencies.

Could be a tool bug, or selective file level configuration (library) that's conflicting with the new choices.

You'll have to get into this with ST, they do that through the Online Support portal and ticketing system.  https://ols.st.com/s/

[Martin42]

I submit an Online Support Request.

Thank you.