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
