[PATCH 0/5] Enable ECDSA FIT verification for stm32mp
This series is based on the latest master, so no patch dependencies. Q: Will there be a software-only implementation of ECDSA ? A: That is the goal, so that we can have more extensive testing with the sandbox. I don not have the bandwidth to implement it. There has been an initial poer of software ecdsa here: https://github.com/timr11/u-boot/tree/ecdsa-vrf-1 Q: Can more code be shared with the RSA verification path? A: Probably yes. Mostly having to do with parsing the "/signature" node and "key-name-hint"s in the u-boot FDT. Although there isn't any copypasted RSA code, or code with substantial similarity. Changes since v5: - Fixed clang warning stemming from test/dm/ecdsa.c Changes since v4: - Use U_BOOT_CRYPTO_ALGO() to add ECDSA to .u_boot_list - No need to #define IMAGE_ENABLE_VERIFY_ECDSA - Use ut_asserteq(x, -ENODEV) instead of ut_assert(x == -ENODEV) Changes since v3: - Remove unused ecdsa_check_key() function Changes since v2: - Spell out "elliptic curve" in Kconfig (Although RSA isn't spelled out) Changes since v1: - Add test to make sure the UCLASS is enabled - Fix check against wrong sig_len in ecdsa_romapi.c - s/U_BOOT_DEVICE/U_BOOT_DRVINFO/ - Use "if(!ret)" instead of "if (ret == 0)" - Use uclass_first_device_err() instead of uclass_fi Alexandru Gagniuc (5): dm: crypto: Define UCLASS API for ECDSA signature verification lib: ecdsa: Implement UCLASS_ECDSA verification on target arm: stm32mp1: Implement ECDSA signature verification Kconfig: FIT_SIGNATURE should not select RSA_VERIFY test: dm: Add test for ECDSA UCLASS support arch/arm/mach-stm32mp/Kconfig| 9 ++ arch/arm/mach-stm32mp/Makefile | 1 + arch/arm/mach-stm32mp/ecdsa_romapi.c | 102 common/Kconfig.boot | 8 +- configs/sandbox_defconfig| 2 + include/crypto/ecdsa-uclass.h| 39 include/dm/uclass-id.h | 1 + lib/Kconfig | 1 + lib/Makefile | 1 + lib/ecdsa/Kconfig| 23 + lib/ecdsa/Makefile | 1 + lib/ecdsa/ecdsa-verify.c | 134 +++ test/dm/Makefile | 1 + test/dm/ecdsa.c | 38 14 files changed, 357 insertions(+), 4 deletions(-) create mode 100644 arch/arm/mach-stm32mp/ecdsa_romapi.c create mode 100644 include/crypto/ecdsa-uclass.h create mode 100644 lib/ecdsa/Kconfig create mode 100644 lib/ecdsa/Makefile create mode 100644 lib/ecdsa/ecdsa-verify.c create mode 100644 test/dm/ecdsa.c -- 2.31.1
Re: [PATCH 0/5] Enable ECDSA FIT verification for stm32mp
Hi Patrick, On 2/9/21 9:08 AM, Patrick DELAUNAY wrote: [snip] For information, today the STMicroelectronics expected that the boot sequence for secure boot (with closed STM32MP1 devices) is the trusted boot chain. TF-A (BL2) => OP-TEE or => U-Boot => OS TF-A (BL32) BL2 is authenticated by ROM code, with EDCSA support. I next OpenSTLinux release (and soon after in upstream) STMicroelectronics will add FIP support for STM32MP15x; TF-A FIP allows to boot Kernel after TF-A BL2 if you want to skip U-Boot TF-A (BL2) => FIP (OP-TEE + Kernel) And the FIP allow authentication with certificate for 'secured boot' with a complete chain of trust. https://trustedfirmware-a.readthedocs.io/en/latest/index.html So the ECDSA support in SPL for STM32MP15x will be not actively supported by STMicroelectronics for product design. The boot flow I'm working on will use an authenticated BL2 as well: ROM -> SPL(BL2) -> FIT(OP-TEE -> Linux) I'm using this to boot to a 3D application very fast (a couple of seconds max). It's really cool. I even wrote a utility for signing SPL images for the ROM code to check [1]. I had looked at FIP images briefly a few months back. I didn't see any advantage over the FIT format. I also wanted to have as little code as possible, so avoiding TF-A made sense. There were also some major issues with syncing the clock tree between linux and TF-A. TF-A was a beautiful disaster. Maybe that changed, but given I have a working proof of concept, I doubt I'll be re-engineering the boot flow. I realize there won't be any STM support for SPL. openstlinux seems to have moved away from SPL. I've gotten a lot of enthusiastic support from u-boot members, as a number of people seem to really like this chip (meself included). Alex [1] https://github.com/mrnuke/stm32mp-keygen
Re: [PATCH 0/5] Enable ECDSA FIT verification for stm32mp
Hi Alexandru, On 1/11/21 4:41 PM, Alexandru Gagniuc wrote: This series is Part II of the ECDSA saga. It applies on top of [1]: * > [PATCH v4 0/6] Add support for ECDSA image signing (with test) > > I've designed the UCLASS_ECDSA such that it aligns with the ROM API > of the stm32mp. Instead of splitting the verification into (1) curve > operations and (2) modular exponentiation, I've concatenated > everything in a 'verify' step. It would be impossible to split the > steps and use the stm32mp ROM for verification. > > Should more granular control be required, this API could be extended > at a later time. Until we have more hardware supporting ECDSA, this > is purely speculative. > > The ROM API of the stm32mp is passed in 'r0' when the FSBL is > called. While we can save 'r0' in SPL, this series does not implement > a mechanism to pass this to u-boot. Thus the ROM API, and ECDSA > verification are only available for SPL. Although extending this to > u-boot by adding the ROM address to the FDT blob, implementing and > verifying this is beyond the scope of this series. For information, today the STMicroelectronics expected that the boot sequence for secure boot (with closed STM32MP1 devices) is the trusted boot chain. TF-A (BL2) => OP-TEE or => U-Boot => OS TF-A (BL32) BL2 is authenticated by ROM code, with EDCSA support. I next OpenSTLinux release (and soon after in upstream) STMicroelectronics will add FIP support for STM32MP15x; TF-A FIP allows to boot Kernel after TF-A BL2 if you want to skip U-Boot TF-A (BL2) => FIP (OP-TEE + Kernel) And the FIP allow authentication with certificate for 'secured boot' with a complete chain of trust. https://trustedfirmware-a.readthedocs.io/en/latest/index.html So the ECDSA support in SPL for STM32MP15x will be not actively supported by STMicroelectronics for product design. > [1] https://lists.denx.de/pipermail/u-boot/2021-January/436935.html > > Alexandru Gagniuc (5): dm: crypto: Define UCLASS API for ECDSA > signature verification lib: ecdsa: Add skeleton to implement ecdsa > verification in u-boot lib: ecdsa: Implement signature verification > for crypto_algo API arm: stm32mp1: Implement ECDSA signature > verification Kconfig: FIT_SIGNATURE should not select RSA_VERIFY > > arch/arm/mach-stm32mp/Kconfig | 9 ++ > arch/arm/mach-stm32mp/Makefile | 1 + > arch/arm/mach-stm32mp/ecdsa_romapi.c | 106 ++ > common/Kconfig.boot | 8 +- > include/crypto/ecdsa-uclass.h | 39 > include/dm/uclass-id.h | 1 + include/image.h > | 10 +-- include/u-boot/rsa.h | 2 +- lib/Kconfig > | 1 + lib/Makefile | 1 + > lib/ecdsa/Kconfig | 23 + lib/ecdsa/Makefile > | 1 + lib/ecdsa/ecdsa-verify.c | 128 > +++ 13 files changed, 320 insertions(+), 10 > deletions(-) create mode 100644 arch/arm/mach-stm32mp/ecdsa_romapi.c > create mode 100644 include/crypto/ecdsa-uclass.h create mode 100644 > lib/ecdsa/Kconfig create mode 100644 lib/ecdsa/Makefile create mode > 100644 lib/ecdsa/ecdsa-verify.c > Regards Patrick
[PATCH 0/5] Enable ECDSA FIT verification for stm32mp
This series is Part II of the ECDSA saga. It applies on top of [1]: * [PATCH v4 0/6] Add support for ECDSA image signing (with test) I've designed the UCLASS_ECDSA such that it aligns with the ROM API of the stm32mp. Instead of splitting the verification into (1) curve operations and (2) modular exponentiation, I've concatenated everything in a 'verify' step. It would be impossible to split the steps and use the stm32mp ROM for verification. Should more granular control be required, this API could be extended at a later time. Until we have more hardware supporting ECDSA, this is purely speculative. The ROM API of the stm32mp is passed in 'r0' when the FSBL is called. While we can save 'r0' in SPL, this series does not implement a mechanism to pass this to u-boot. Thus the ROM API, and ECDSA verification are only available for SPL. Although extending this to u-boot by adding the ROM address to the FDT blob, implementing and verifying this is beyond the scope of this series. [1] https://lists.denx.de/pipermail/u-boot/2021-January/436935.html Alexandru Gagniuc (5): dm: crypto: Define UCLASS API for ECDSA signature verification lib: ecdsa: Add skeleton to implement ecdsa verification in u-boot lib: ecdsa: Implement signature verification for crypto_algo API arm: stm32mp1: Implement ECDSA signature verification Kconfig: FIT_SIGNATURE should not select RSA_VERIFY arch/arm/mach-stm32mp/Kconfig| 9 ++ arch/arm/mach-stm32mp/Makefile | 1 + arch/arm/mach-stm32mp/ecdsa_romapi.c | 106 ++ common/Kconfig.boot | 8 +- include/crypto/ecdsa-uclass.h| 39 include/dm/uclass-id.h | 1 + include/image.h | 10 +-- include/u-boot/rsa.h | 2 +- lib/Kconfig | 1 + lib/Makefile | 1 + lib/ecdsa/Kconfig| 23 + lib/ecdsa/Makefile | 1 + lib/ecdsa/ecdsa-verify.c | 128 +++ 13 files changed, 320 insertions(+), 10 deletions(-) create mode 100644 arch/arm/mach-stm32mp/ecdsa_romapi.c create mode 100644 include/crypto/ecdsa-uclass.h create mode 100644 lib/ecdsa/Kconfig create mode 100644 lib/ecdsa/Makefile create mode 100644 lib/ecdsa/ecdsa-verify.c -- 2.26.2
