[EXTERNAL] Re: How would I do signature verification of standalone binary?

[Simon Glass]

Hi Fabian,

Firstly, please can you drop your signature as it is not correct for a
public mailing list.

On Tue, 14 Jan 2025 at 08:12, Koch, Fabian <Fabian.Koch at hima.com> wrote:
>
> Hey Simon,
>
> Thanks for getting back to me.
>
> > So long as you put your image in a configuration, it can be verified.
> > The question is whether you can load it.
>
> Yes. Meanwhile I got far enough to have a signed FIT image, a u-boot.img which contains the pub-key in a dtb and the means to load it all using "imxtract" which also does the signature verification.
>
> So my usecase might just work without any modifications to u-boot sources.
>
> I only need to confirm whether this can be secure enough against attacks.

If you are just using a signed image, then there is no protection
against a mix-and-match attack. Are you using a signed configuration?
The best approach is to use a signed configuration and then just a
hash for each image.

> > bootm assumes it is booting an OS. It does not support IH_TYPE_FIRMWARE as a type.
> I currently use "standalone" in the FIT source
>
> > You could write a new command to handle that, perhaps.
> I wanted to stay as close as possible to vanilla u-boot (or at least vanilla TI-SDK u-boot) in order to not have to do as much work when upgrading later on.

OK. Patches are welcome, though.

>
> > SPL does support loading firmware, but you are running U-Boot proper so that isn't very useful.
> Honestly, we could probably ditch u-boot proper for our usecase, but again staying very close to the TI SDK, (which instead finally loads a Linux kernel of course) we have been going this road so far.
> Might be worth checking if we can just use SPL only, also saving on boot time.
> Can you point me to how the rest (loading, verification) would look there in SPL only?
> Still a signed FIT image with "standalone" I suppose?

You need to enable full FIT in SPL, but yes, it should work in a similar way.

>
> > For your command, you could call fit_config_verify() to verify the config, then fit_image_load() to load the image you want.
> Both "iminfo" and "imxtract" which I currently tried run through fit_image_check_sig() eventually, and in the .dtb I marked the image as "required" to be verified.
> Doing the negative test of loading an unsigned FIT resulted in both commands failing and yielding a 1 as return value.
> So my current plan is to do some basic bootcmd like:
>
> If imxtract does not fail, use "go" to jump to the entry point, Else fail the boot
>
> Then I would try the "u-boot hardening" tips I found so far (like disabling cli and console, hard-code the env, and set the delay to -2)
>
> If you have any more ideas on how to make this more robust, please let me know.

That seems good to me, although I'm not a security expert!

>
> >> [long signature with legalese]
> > [can you please drop this as it is not correct for a public mailing
> > list?]
>
> It is auto-inserted by (I suspect) the company MTA, so I don't think I can, sorry.
> I tried to send this as a plaintext mail at least, maybe that makes it a bit more bearable.

OK, please raise it with your IT people as it does create confusion
and may make others reluctant to reply.

>
>
> Kind regards and happy new year
> Fabian
> Informationspflicht nach Art. 13 und 14 DS-GVO: https://www.hima.com/de/informationen-DSGVO Information obligation according to Art. 13 and 14 DS-GVO: https://www.hima.com/en/information-GDPR
>

Happy New Year!

[..]

Regards,
Simon