STM32 MCUs Security

Hi everybody,I wonder if it is possible to configure the X-CUBE-SBSFU expansion to use external serial flash chip instead of internal memory. Any ideas, application note?regardsMikhail

Hello,Can X-CUBE-SBSFU source code work with STM32H7 (STM32H743) too ?In the getting started it is said:"It comes with an example implementation running on the NUCLEO-L476RG, NUCLEO-L432KC, B-L475E-IOT01A, 32L496GDISCOVERY, NUCLEO-G071RB, 32F413HDISCOVERY, and 32F769IDISCOVERY platforms.".Thank,ranran

Hello.I downloaded and tried your "Secure boot & secure firmware update software expansion for STM32Cube" solution.https://www.st.com/en/embedded-software/x-cube-sbsfu.htmlIt works great on my Nucleo-64 board, and the next step what I wanted to do is port it to my own MCU (STM32F2xx).Here comes my question: Do you have any guide that shows step-by-step what to do exactly?I started with SECoreBin. I created a project for my own MCU. Changed the HAL, but got errors. I realized that, my MCU had sectors, instead of pages, okay, I changed that to fit my needs. Then I still got errors regarding the CRC, okay I changed that also. etc. etc. etc. Now I can compile everything (in the SECoreBin project), but I get linker errors. I probably have to change something in the linker script.So the bottom line is: whatever I do, I face a new problem. I am kinda lost in this work. This is why I need some kind of step-by-step guide. If such thing exists.Or an alternative question: Can I request an off

Hi guys,I am testing the CRC hardware of the STM32F722ZE in the NUCLEO board, but doesn't get a right result.The CRC keys are: Poly=0x1021 and INIT value=0x1D0FMy two data input of 16-bit wide is: [0]=0x0031 [1]=0x0032.Some CRC calculators gives 0xEA94, but STM32 gives 0x5197My code: // config   CRC->INIT=0x1D0F;            // init value   CRC->POL=0x1021;            // Poly   CRC->CR=0x0008;               // No reverses. 16-bit poly// calculating function:   uint16_t val;   CRC->CR|=CRC_CR_RESET;      // Reset   while (length>0)   {      val=*data;      CRC->DR=val;   &

Hi!When switching RDP from level 0 to level 1, the program stops working. Switched using code in the program, as well as using the ST Visual Programmer. The result is the same.Code suchFLASH-> OPTKEYR = FLASH_OPTKEY1; FLASH-> OPTKEYR = FLASH_OPTKEY2;   while (FLASH-> SR & FLASH_SR_BSY); * (((__ IO uint8_t *) & FLASH-> OPTCR) +1) = uint8_t 0x55U; FLASH-> OPTCR | = FLASH_OPTCR_OPTSTRT; __DSB (); while (FLASH-> SR & FLASH_SR_BSY); FLASH-> OPTCR | = FLASH_OPTCR_OPTLOCK;The code is written according to the processor manual. In X-CUBE-PCROP, everything seems to be the same, except that they additionally remove the flash lock. Unlocking the flash does not help, checked.Maybe in what system register the flag should be set, or what other settings to make?

I am working with STM32F407 in a project with crypto library.With IAR 7 compiler version all is oknow I would like to use a more recent version of the compiler IAR 8.11.1 but the link fail with Warning[Lt009]: Inconsistent wchar_t size          crypto.o(M4_CryptoFW_RngHW_2_0_6.a) has wchar_t size 16 bits            app_485.o and 85 other objects have wchar_t size 32 bits IAR change the wchar_t definition. I downloaded again the M4_CryptoFW_RngHW_2_0_6.a but is the same of my previous copy. I downloaded also the STM32CubeExpansion_Crypto_V3.1.0 but I don't use the HAL library in my project and I have some errors in linker of undefined functions. (Without using HAL I can't include stm32f4xx_hal_cryp.c and stm32f4xx_hal_cryp_ex.c in my project)There is a version of the crypto library that does not use HAL and is compiled for a recent version of IAR ? thanks

Posted on June 08, 2013 at 11:56Hi, I am looking to understand exactly what CRC support the STM32F103 provides when interfacing with an SD card using an SPI channel and no DMA. I am using an Olimex STM32-P103 development platform and have successfully transmitted CMD8 to a SanDisk 2GB (class 2) SD card (at 280KHz) but only when I pre-calculate the 6-byte command as follows. 40 00 00 00 00 95. The reply data that is returned in this case is valid. I would like to use the built in CRC capability of the interface to calculate the final CRC byte but this is where things go wrong. I now transmit 40 00 00 00 00 and on the final 00 byte set the CRCNEXT bit in the CR1 control register. I do indeed get a sixth byte transmission but it is not the required 95 (this I verified by viewing the MOSI signal using an oscilloscope). My questions are as follows. (*) In order for the calculated CRC value to be useful only the low 7-bits should be used which need to be shifted left 1-bit position and a LS

I'd like to use the CRC peripheral to check the validity of a code image in memory. I'm planning on generating a CRC during the build process, and adding the value to the end of the image when it's built. I'm using the Python function crcmod.mkCrcFun with the polynomial set to 0x14D11CDB7 and the initial value set to 0xFFFFFFFF. I understand that some descriptions of the poly value leave off the starting '1'. I'm assuming this is the case for theCRC peripheral description. mkCrcFun doesn't like the value 0x4D11CDB7.So far the values generated by each method don't match. Can anyone tell me:Is the polynomial implementation for the CRC peripheral actually 0x14D11CDB7?Is there anything else that might be different between the two implementation?Is there another option in Python that would produce a matching CRC?Thanks.

Hi, Presently I'm calculating CRC using HAL and going forward would like to calculate it using DMA to save some CPU usage.I read in application note AN4187 about calculating CRC using DMA but it explicitly mentions only applicable for F0, F1, F2, F3, F4, L1 series. I'm not sure whether this functionality is available in STM32F7 series because application note is quite old (June 2013). I tried to configure STM32F765's DMA for CRC but didn't succeed (by taking reference from AN4187 application source code). I also tried MX cube code generator for CRC but it did not give option of adding DMA. STM32F7xx reference manual have no mention of this feature. I want to know if this is feasible. Any information/direction on it would be helpful.Thanks,Shriram 

I'm trying to run AES CCM encryption on STM32F746G-Disco board in hw-accelerated mode. Tried to use CryptoLib 3.1.2 and low level Examples from 756-Eval board. For some reason there is no working example supplied by ST that implements this mode with HW acceleration on 746. CryptoLib works good, but only in FW mode (unaccelerated). Having tried to adapt HAL example (\Examples\CRYP\CRYP_AES_CCM) from 756 board, I encounter timeout in HAL_CRYPEx_AESCCM_Encrypt() call.Is CRYP supposed to work in this mode in 746NG at all? Ref man does not tell it shouldn't. Can anybody point me to what should be adjusted for it to work, compared to 756?Thank you!Vladimir

When I set my SPI to full duplex mode and CRC is enabled then what should be the value of bufferSize in HAL_SPI_TransmitReceive_DMA(&hspi1, (uint8_t*)aTxBuffer, (uint8_t *)aRxBuffer, bufferSize ) function?for ex size of buffers is 4 bytes (excluding CRC bytes). Then What should be the value of bufferSize in following function?: HAL_SPI_TransmitReceive_DMA(&hspi1, (uint8_t*)aTxBuffer, (uint8_t *)aRxBuffer, bufferSize ).Note: CRC is enabled on both master and slave side.

using the STM32 Crypt processor I could successfully encrypt and decrypt plaintext using AES GCM (STM32 cryptographic library version V1.5.0). The stm contoller that I am using is STM32F479NIHx. Simultaneously, there is another crypto project in the PC side using the polarssl library (Version polarssl-1.2.15) with the same AES GCM encrypt/decrypt parts. It also working fine.However, the problem is that when using the same AES256 key, IV array (size 12), plaintext, header (AAD), the STM32F4 and the PC generates different ciphers and tags. Their lengths are the same across the platforms but the content is totally different.So it becomes impossible to encrypt in PC and try to decrypt the cipher in STM32F4.

Hello,I'm trying to integrate latest crypto lib (v. 3.1.2, FW implementation) into my TrueSTUDIO project but encryption with AES-CBC-128 fails.Example project in Fw_Crypto\STM32L0\Projects\STM32L053R8-Nucleo\AES\AES192_CBC fails both encryption and decryption phases.Digging into the issue I reduced key size to 128bits and set Key, IV and Plaintext as all 0's (16B long): encryption works correctly (according to various online AES calculators).Changing a single bit in Plaintext will break encryption: it looks like some data are ignored and some other are read multiple times (always comparing result with online calculators).If I split the 16B of plaintext into 4 groups (4B each - let's call them p1 p2 p3 p4), library behaves as if plaintext was p2 p1 p1 p1: changing bits in p3 and p4 does not change ciphertext (!).What am I missing?Alessandro

Hi, I use STM32L431CCT6 for development.Occasionally, even I have no done any special operation, read out protection mode is enabled.(Level0→Level1)I do not know the cause clearly.Please tell me the cause or ​reproduction method.And is there any solution to this problem?

I found a bug the HAL CRC Module... First of all... when you enable the CRC Module with CubeMX 5.0.1 the MX_CRC_Init() is empty and the peripheral is not initalized!I wrote all the code manualy or copied it from the old CubeMX 4 generated code...This worked BUT... when using hcrc.Init.CRCLength = HAL_CRC_LENGTH_8B the CRC->CR->POLYSIZE Register is set wrong. It is set to 0x01 what means 16 Bit CRC and not 0x02 wicht would be 8 Bit.When you use hcrc.Init.CRCLength = HAL_CRC_LENGTH_16B; the CR->POLYSIZE Register is set to 8 Bit (0x02)... so it seems to be flipped arround... I did no further investigation on this bug... dont know where the problem realy is... But i guess, this is STs task.Best regards

 Latest crypto library(Hardware) has STM332L05X/6x series but not able to find for STM32L083. Where can i find the Hardware STM32 crypto library for STM32L083 Series.

SBSFU work fine on my STM32F767ZI-Nucleo using SBSFU's default MPU configuration. but when I change  sram access to MPU_ACCESS_BUFFERABLE, HardFault occured. How to configure SRAM1 as WBWA?

Is STM32CubeMX v5.01 supoosed to generate CRC intializtion code? All I get is an empty  MX_CRC_Init() function and no handle is created. Is this a bug? I can copy the init code from an example but I'm wondering how/where the CRC clock gets enabled or do I need to worry about this?

When i use STM32F303VCT6 ADC4 Ch4(PB14) without readout protection, it works good, i receives value 0 - 4096, as expected.But after Readout protection become On, value from ch4 adc4 i receives always is 0 - 3, not more

Hi,I need to add the security and encryption to my firmware for the STM32L432KB MCU.Please suggest me that how do It or develop it.Thanks

The question has been asked already, and the answer is generally : look at https://community.st.com/docs/DOC-1557-one-way-to-use-the-x-cube-cryptolib-with-cubemx-and-system-workbenchUnfortunatly, the link is dead.Where can I find this document ?Regards.

Hello, I am using STM32 Cryptographic Library. as the UM, there are 8 .lib file. what is the difference? e.g M3_CryptoFW_RngHW_2_0_6. lib, is it implemented by Hardware? Or what crypto function is implemented by Hardware? does it include all crypto functions(AES, ECC, HASH...)?

Posted on June 20, 2018 at 02:01I want to use AES on the STM32F423 (ie, call CRYP_AES_CBC).  But, 'CRYP' does not seem to be defined for the F423 (unlike many other cpus).  I assume 'CRYP' is not defined since the 423 does not support hashing and other crypto functions.  What is the path to success (bread crumb is fine)?  Thanks.#aes-stm32f423

Hi experts,I am using an STM32F429. I set in the option bytes the read protection level to 1 (with the process specified in the reference manual) and it seems that after writing of the new data into the option bytes finished the MCU automatically issues an bus fault (this occurs always). In the documentation it says that a bus fault may occur if, e.g., a debuger is connected and tries to access the protected areas, but this also happens when no debugger is attached. After resetting the MCU manually everything works fine again.Is this the normal behaviour? I coud not find anything in the datasheets/manuals so far. The only hint in this direction is the comment in the documentation of the F4Cube-HAL libs regarding option byte programming, where it states that a reset will occur and there is no code in the lib-functions to trigger this reset. (I am not using the F4Cube-HAL, i have my own).Any insights are welcome.Additions:It seems that writing a new Value thats also a Level 1 and writing

Posted on April 19, 2017 at 12:18Hello, I would like updating the firmware of an STM32F767ZI using the internal boot loader. I am using the USART3 (PB10 and PB11). In order to transfer the program I am using the program �Flash Loader Demostrator�.My testing application has two parts. A led blink implemented in the main loop and the jump to the internal boot loader implemented in and EXTI interrupt. In that way when I press a button the application jump to the internal boot loader code and starts the updating process.When I press the button and I star the communication with the flash Loader everything seems ok:When I try reading the firmware appear the following message:I try enabling the reading with the Flash Loader:The program informs that the memory will be erased. After the process the result is:When I try reading the program the result is the same as before:If I use the ST_LINK Utility I can read and write the memory without problems. The configuration of the Option Bytes is:I ha