Hi Philippe and Marko, Thank you for the prompt replies!
>> 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. The patch "lib: ecdsa: Add support for loading ECDSA public key from FDT" (commit 8d3a9ab3ca506bd4546e0a336115ae523a571010) resolves this issue. After cherry-picking this commit into my branch, I'm successfully able to verify the signature from the host machine using tools/fit_check_sign. With that patch, verification is done with the public key embedded in the control DTB by tools/mkimage. > 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. I'm not very knowledgeable in this area but from what I've found, the public key can be derived from the x/y point values stored in the DTB. If MBED wants the uncompressed public key, it's just a matter of concatenating a prefix "04"+x-point+y-point [1]. Although this wouldn't necessarily generalize the process like you suggest, I wonder if something like embedding an X.509 certificate containing information would be more appropriate to that end. I've just started looking through the MBED library and it seems to have some facilities for working with certificates. >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. I would very much appreciate if you could share what you have so far. Hopefully the patch for using tools/fit_check_sign will help in your development as well. Thanks, Jonny Green [1] https://learnmeabitcoin.com/technical/keys/public-key/#uncompressed -----Original Message----- From: Philippe Reynes <[email protected]> Sent: Friday, January 30, 2026 8:33 AM To: Marko Mäkelä <[email protected]>; Jonny Green <[email protected]> Cc: [email protected]; [email protected] Subject: Re: lib: ecdsa: Verifying signature on target 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
