Authentication of the M4 Firmware

Pascal Krumme · ‎2019-11-26

Hi There,

before I go into detail regarding my question I´d like to give some background infos. I have an application in mind that seems like a perfect fit for the STM32MP1 as it would enable me to merge a device which is currently split onto two separate PCBs into a one single board.

What´s different in this application is, that I need to be able to autenticate the integrity of the coprocessor firmware and have a mechanism that allows updating of the fw only if a self-adhesive seal is broken, e.g. by sticking it on top of a dipswitch.

So what I´d like to discuss are possible solutions to this whole chain of problems. As far as I understood the documentation and the slides from the hands on workshop, this all has to be implemented into the ssbl (u-boot) as it is the only modifieable piece of software to be run before execution of the coprocessor firmware starts.

I could imagine doing something like signing the M4 firmware by means of async crypto and storing the signatue alongside with the firmware file. When U-Boot starts, it computes the signature and checks it against the existing and denies further operations if they dont´t match.

Updating the FW would consist of uploading a new one to the completely booted system which then moves it to the uboot flash partition and issues a reboot. During that reboot, uboot recognizes the new file and checks weather are specified switch is flipped and replaces the files and the signatures.

What I´d like to know is if somebody here came across a similar problem and maybe found a different and/or better solution to this problem and weather there is anything planned by ST in this direction in the near future.

Bernard PUEL · ‎2019-12-04

Hello Pascal,

Few questions about this information: "autenticate the integrity of the coprocessor firmware and have a mechanism that allows updating of the fw"

I/ Check:

Do you want to check integrity of the coprocessor firmware only ? (check it is complete)

Or

Do you want to authenticate the coprocessor firmware ? (check it is coming from a trusted build)

II/ When:

Do you want to do this check from above question:

At every boot (like for a secure boot) ?

Or

Only when you update it ?

III/ What:

When you talk about "updating of the fw":

Is it only the coprocessor firmware or the whole system firmware (including Linux side) ?

Is it a OTA firmware update (from network) ? If yes which system partition you would like to upgrade and with which framework (raw and/or Filesystem ones) ?

Many questions .... but makes the pb to solve quite different depending on answers.

Pascal Krumme · ‎2019-12-05

Hi Bernard,

thank you for your reply.

Regarding I/

Indeed I need to do three things

Check the integrity of the Coprocessor FW
Check if the Firmware comes from a trusted source (e.g. hash it and sign the hash with a private key...)
Check if the Firmware has been tampered with (e.g. even replacing a trusted fw with another trusted fw is prohibited if a specific pin is high)

I think 1. is included in 2. as 2. would obviously fail if the firmware gets corrupted.

Regarding II/

All three checks have to be passed on every boot.

Regarding III/

In fact we will need to update the M4 Firmware, the Linux OS and our Application Code over network. The update mechanism for the OS has not been discussed yet, the update mechanism for the application code is proprietary but depends on a std. filesystem

Some details on our application, the M4 runs some rather critical real time code. In fact, after a unit is installed it needs to pass an external inspection. Once this inspection is passed the real time code must not be changed. If it is changed, the unit must go out of service until the inspection is repeated. Obviously we want to separate this from our application code as it happens frequently that we need to change the application while the unit is in use (e.g. the customer comes up with a specific feature he´d like to have a year after the unit was installed).

I hope I answered all you questions sufficiently

Best Regards

Pascal

Bernard PUEL · ‎2019-12-05

Thanks Pascal. I and II clear.

III still clarification:

updating tf-a or u-boot stages is not in your scope right (only Os and or application (bootfs and rootfs partitions) ?
When you talk about "the unit", is it the M4 coprocessor part or an external system (outside stm32mp1 system) ?

Pascal Krumme · ‎2019-12-06

Hi Bernard,

Updating tf-a or u-boot is indeed not in our scope atm, but I believe it could be done with the STM32CubeProgrammer and a technician on site.

The "Unit" is planned to be solely based on the STM32MP1, the M4 firmware I refered to is the one running on the coprocessor of the STM32MP1.

Bernard PUEL · ‎2019-12-06

Hello Pascal,

I think based on current stm32mp1 deliveries, you have all to make your unit work as expected.

I/ For tampering:

see https://wiki.st.com/stm32mpu/wiki/TAMP_internal_peripheral

The ROM code will check M4 integrity at every boot, On tampering the backup registers will be cleared and boot won't be possible.

II/ For M4 firmware authentication:

see https://lwn.net/Articles/571031

You can use FIT. From current boot mechanism, you just need to create a M4 FIT image and add signature check before loading the firmware.

III/ For SW update:

For application update. Use your legacy solution.
For Kernel, you may use rauc (for A/B system update) or ostree (only Diff updates)
If you want to add KErnel authentication, you could use the same as for M4 (FIT)