lib: ecdsa: Verifying signature on target

[Philippe Reynes]

Hi Marko,


Le 30/01/2026 à 09:58, Marko Mäkelä a écrit :
>
> This Mail comes from Outside of SoftAtHome: Do not answer, click links 
> or open attachments unless you recognize the sender and know the 
> content is safe.
>
> Thu, Jan 29, 2026 at 10:18:03PM +0000, Jonny Green wrote:
>> Hello,
>>
>> I am implementing FIT booting with an ECDSA signature. I am building
>> from a TI fork of U-Boot that is based off of v2025.01 from the
>> mainline repo.
>
> Nice. I have been meaning to do the same;
> https://lists.denx.de/pipermail/u-boot/2025-November/602918.html 
>
> contains some notes.
>
>> However, attempts to boot on the target with the signed u-boot.img and
>> generated .itb are failing. Debug printouts show that the call to
>> ecdsa_verify in ecdsa-verify.c is failing after calling
>> uclass_first_device_err: "ECDSA: Could not find ECDSA implementation:
>> -19".
>
> I only found some implementations for some specific firmware or
> hardware. In mbedtls there is an implementation, which I have been
> intending to write an interface for. A first challenge was to actually
> include the mbedtls in the build. The attached patch would introduce
> CONFIG_ECDSA_MBEDTLS.
>
> A challenge with the Kconfig system is that you can create an "overlay"
> of a default configuration that adds things, but you cannot remove
> things that are part of the default configuration. Here's an example of
> adding things (without modifying any existing files in u-boot):
>
> cat > configs/a53_defconfig << "EOF"
> #include <configs/phycore_am62x_a53_defconfig>
> CONFIG_FIT_SIGNATURE=y
> CONFIG_ECDSA=y
> CONFIG_ECDSA_VERIFY=y
> EOF
>
> The above actually is how I was originally experimenting with ECDSA.
> Currently, I am using a Raspberry Pi 4. I figured out that there is a
> lower-level configuration interface:
>
> make rpi_4_defconfig &&
> scripts/config -e FIT_SIGNATURE -e ECDSA -e SHA256 -e ECDSA_VERIFY \
> -d BOOTSTD \
> -e MBEDTLS_LIB -e MBEDTLS_LIB_CRYPTO -e ECDSA_MBEDTLS \
> -e SHA256_MBEDTLS -e SHA256_SMALLER -e MBEDTLS_LIB_X509 -d HKDF_MBEDTLS \
> -d LEGACY_HASHING_AND_CRYPTO &&
> make -j$(nproc) CROSS_COMPILE=aarch64-linux-gnu-
>
> If the LEGACY_HASHING_AND_CRYPTO were not disabled, it would override
> any MBEDTLS parameters.
>

I am working on this topic, but I haven't published any patches because 
it is not finished yet.
I have added the support of ecdsa using mbedtls. I need to add a 
"software driver" that can be called
by ecdsa_verify when no hardware supports ecdsa.

>> Other debugging steps I've taken:
>> * Ensured public key is present in the booted image via inspection 
>> with fdt
>> * Ensured relevant config values are set: ECDSA, ECDSA_VERIFY, 
>> FIT_SIGNATURE
>> * Attempted to get trace information from the boot attempt, but it
>> appears my board does not support the required clock
>
> One problem that I noticed is that the ECDSA signature verification in
> fit_check_sign needs access to the private key. Were you able to fix it
> so that only a public key is needed, like it is the case with the RSA
> signature verification?
>

I haven't looked this part yet, so I will also have to manage it.

> Also, I understood that u-boot prefers to store a parsed RSA or ECDSA
> key in the FIT in its own pre-parsed way, while the MBEDTLS library
> would apparently input the raw key. This problem would have to be solved
> in some way. Maybe, by just embedding the key in binary form in a FDT
> node and letting MBEDTLS parse it? This would of course require some
> changes to fit_check_sign and other tools as well.
>
> Storing the key in the canonical format would seem to make it easier to
> add further algorithms. I'm actually not that interested in ECDSA; my
> ultimate goal would be to integrate an algorithm that is expected to be
> safe against attacks based on quantum computers.

In summary, supporting ecdsa on platform without hardware support of ecdsa
is in state "work in progress" on my side.
If you can wait, I will publish my work asap (not this week), otherwise, 
if you want I may
provide my work "as is" but if it not finished.

>
> With best regards,
>
>        Marko Mäkelä

Regards,
Philippe