what is the FIPS certification available for X-CUBE-CRYPTOLIB ?? I see NIST-CAVP Certification which is FIPS 186, what is the difference from FIPS 140-2/140-3 complaint. is both are same ?

[SPati.7]

We are looking for FIPS 140-2 / 140-3 certified Secure Boot loader implemented with help of X-CUBE-CRYPT LIB for STM32H753VI MCU.

if i see NIST-CAVP certification, it is mentioned as STM32L4 series, then is thios same certificate is applicable for STM32H7 ?? if not is STM will help us to get FIPS certification for STM32H7 series as well ..??

Please share the details as much as possible on this.

@Jocelyn RICARD​  can you help with this FIPS or can you redirect to someone who handles FIPS certification.

[Jocelyn RICARD]

Hello @SPati.7​ ,

Please check our wiki page related to our X-CUBE-CRYPTOLIB about validation through NIST CAVP here

This concerns the cryptolib V4.

In this version, the library is associated to each Cortex-M and not to specific STM32.

For old version 3.1, only L4 went through this functional validation. But exact same code was used to compile on other chips.

The CAVP allows you to reach certify your product with FIPS 140-2 certification level 1 and level 2

?

Best regards

Jocelyn

[SPati.7]

@Jocelyn RICARD​  We are not sure as of now, whether CAVP certification will suffice to get FIPS 140-2.

We don't have enough expertise to confirm this, and we are looking now.

So from V4, we have NIST-CAVP certification for Cortex M7 as well. is this current CRYPTO library version ??

[SPati.7]

@Jocelyn RICARD​  Where does Option Bytes stored which is persistent across power cycles ?? is it inside System Flash or User Flash ??

Trying to understand RD LVL 2 protection, how it works and at what stage it apply ??

Can you help with these details ??

[Jocelyn RICARD]

Hi @SPati.7​ ,

Yes cryptolib V4 is the current version.

About FIPS 140-2, CAVP is necessary but not enough as far as I know. That's all I can say.

Option bytes are very specific part of the flash.

Yes they are persistent, and contain a self error correction.

They are loaded before actual cortex startup to ensure adequate boot sequence, flash protections, platform setup.

The RDP Level 2 is the highest flash readout protection level.

When you switch to level 2 you forbid any option byte modification except for flash bank swap.

STM32 H7 also supports a memory protection feature available only on crypto enabled part numbers, that increases the level of security by creating an added isolation for bootloader.

You can find all details in the reference manual and also in the MOOC Security features available on youtube

Best regards

Jocelyn

[Fred]

Hi,

there is this document providing maybe more details:

https://www.st.com/content/ccc/resource/sales_and_marketing/presentation/product_presentation/group0/79/b4/63/20/21/53/47/54/fips_cavp_certification/files/fips_cavp_certification.pdf/jcr:content/translations/en.fips_cavp_certification.pdf

But I will also ask some colleagues.

Regarding RDP Level 2, please be careful with this because once you configure the product in RDP level 2 then it is locked and you cannot go back to another (more permissive) RDP Level. This means that your product is "frozen" unless the firmware you have already programmed in it allows you to do firmware update.

[SPati.7]

Thanks @Jocelyn RICARD​  For details.

I have one quick question, is the Secure Bootloader whatever, OEM built with help of Secure Engine & SBSFU together, is it going to sit in System Memory of Flash as mentioned below ??

 

I think, System Memory accessible by only ST right ??

So where is the location of OEM Secure Bootloader flashed for one time ?? is it on Bank1 Sector 1 ?? then what resides in System Memory Boot location ??

[Fred]

For STM32H753, the Unique Entry Point is in System Flash and you cannot change this code that will jump into the secure user memory area in user flash containing the X-CUBE-SBSFU.

X-CUBE-SBSFU goes in user flash so you can modify the code and flash your own version of this OEM bootloader. Nevertheless, it is protected by secure memory so you won't have runtime secure services.

[Fred]

I think you can use the validation number from the link I indicated in the previous post with this web site:

https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/validation-search?searchMode=validation&validationNumber=3971&productType=-1&ipp=25

Then you get this kind of information:

https://csrc.nist.gov/projects/cryptographic-algorithm-validation-program/details?product=5441

This is for X-CUBE-CRYPTOLIB so V3.

With V4, the latest information is here:

https://wiki.st.com/stm32mcu/wiki/Security:Cryptographic_Library_Certifications