STM32 Trusted Package Creator NO SUPPORT FOR H743

[Robmar]

The  "Introduction to secure firmware install (SFI) for STM32 MCUs" AN4992 does not list the H743 as a supported device.

The Secure Programming tab of the latest Cube Programmer V2-18-0 (Jan 20205) states it only supports STM32U0-5 & WBA.
Yet the SFI/SFIx tab isn't disabled when connected to an H743VIT6 board.
And the STM32 Trusted Package Creator allows the STM32H7 MCU to be selected as a target.

Does anyone think that's not going to be confusing to STM clients new this (mine) field?

The "STM32 Trusted Package Creator tool software description" User Manual UM2238 runs to 30+ pages of technical description, very far from user friendly.

The STM Wiki "How to deploy SSP using a step-by-step approach" only focuses on the STM32MP1 and uses hard coded values specific to that MCU.

The only video on YouTube is by Ruchit Naik a security engineer at STM who uses an AI voice.
At 3.55 into the video a chart is listed that includes STM32H7 series, but in the list the H743 is excluded!

Clearly adding encryption to the data transfer from Cube Programmer to the STM32H743 boot loader would be very easy (I could do it in a coupe of hours if I had the source code),
So why has STM MCU managers decided to blacklist the H743?

[Pavel A.]

And don't you know this yet? H743 lacks the 'security' stuff present in H753. Can you use H753 instead?

If you are locked to H743, it still may be possible to make a satisfying secure boot & update solution, but it will be harder and more limited.

> So why has STM MCU managers decided to blacklist the H743?

Because they want to sell H753.

> Clearly adding encryption to the data transfer from Cube Programmer to the STM32H743 boot loader would be very easy 

Sure enough, but how will you protect the crypto keys from reading by hackers? How will you prevent someone from making unauthorized devices with your firmware?  If this is not a concern, maybe SFI is too much of complication. Simple beats complicated, not always but often.

[Robmar]

Come off it Pavel what you're saying is nonsense, STM are just forcing H74X users to change MCU on the pathetic excuse of missing hardware security features in their more expensive MCUs.

You're going to tell me that the 480 MHz Cortex-M7 can't run a decent encryption algorithm?!

And because of this we now have to implement custom security code?!

I just had to learn and write the USB driver code for the H473 because the STM samples don't work or won't handle composite devices, now I have to write the security code too!

Pathetic support, not to mention loathsome manipulation by STM management!

[Pavel A.]

> You're going to tell me that the 480 MHz Cortex-M7 can't run a decent encryption algorithm?!

No, I'm going to tell that many STM32s come in pairs: fully crypto enabled and crypto-less, to escape export complications or whatever. So in case of the H753/H743 pair, the former has some proprietary magic needed to create so called root of trust for the ST SFI technology.

As for performance, the H753's crypto accelerators (CRYP and HASH) are nice to have but not critical for install & update task, as you wrote. But the ability to protect the root crypto secrets is lacking for the poor 2nd class users.

The whole 'security' thing is about creating inequality and privilege: someone can get in, but others cannot.

[Robmar]

Expensive "magic" hardware is not needed for the secure encryption of a binary file, its just a dishonest marketing ploy, the STM32H753VIT6 is TRIPLE the cost of the 743 version on Digikey at 100+ quantities.

Microsoft forced people to pay $300 a question for tech support, Apple programmed their phones to go slow after a year or two, both got big fines, and STM is pushing encryption hardware where it's just not needed in most cases.

This undermines any hope of customer loyalty.