feat: support signing with external signature by sebastian-bantel · Pull Request #4 · embetrix/stm32mp-sign-tool

sebastian-bantel · 2025-12-08T09:31:48Z

As I use a key infrastructure it is not possible to access the private key directly. I rewrote the tool that it can generate the signed image without access to the private key.

add option to create hash to sign
add option to create signed image using public key and external signature file (DER format or raw)
add option to create public key hash from public key file
update tests to cover new functionality
update usage instructions

Thank you for contributing to stm32mp-sign-tool!

By submitting this pull request, you confirm that:

This contribution is your original work or you have the necessary rights to submit it.
You agree to the terms outlined in the project's Contributor License Agreement (CLA).

Copilot

Pull request overview

This PR adds support for external signature generation, enabling use with key infrastructure systems where direct private key access is unavailable. The key enhancement is a two-step signing workflow that separates hash generation from signature application.

Key changes:

Introduced new command-line options (-u, -s, -d) to support external signing workflow
Refactored key loading to handle both private and public keys separately
Added DER signature format parsing with automatic fallback to raw format

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 6 comments.

File	Description
stm32mp-sign-tool.cpp	Core implementation of external signing support, including new functions for public key loading, DER signature parsing, and refactored signing logic
stm32mp-sign-tool_test.sh	Added test cases for public key hash generation and external signing workflow
README.md	Updated documentation with new command-line options and usage examples for two-step signing workflow

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2025-12-08T09:39:29Z

stm32mp-sign-tool_test.sh

+
+# Test sign process with external signing
+# generate hash to sign from image
+openssl ec -in private_key.pem -pubout -out public_key.pem


This line is duplicated from line 48. The public key file is already generated, so this command is redundant and should be removed.

Suggested change

openssl ec -in private_key.pem -pubout -out public_key.pem

right. This line can be dropped

Copilot · 2025-12-08T09:39:29Z

stm32mp-sign-tool.cpp

+        return {};
+    }
+
+    std::vector<unsigned char> r_bytes(der_sig.begin() + static_cast<std::ptrdiff_t>(idx), der_sig.begin() + static_cast<std::ptrdiff_t>(idx + r_len));


[nitpick] The explicit cast to std::ptrdiff_t is unnecessary here. Vector iterators support arithmetic operations directly with size_t values.

Suggested change

std::vector<unsigned char> r_bytes(der_sig.begin() + static_cast<std::ptrdiff_t>(idx), der_sig.begin() + static_cast<std::ptrdiff_t>(idx + r_len));

std::vector<unsigned char> r_bytes(der_sig.begin() + idx, der_sig.begin() + idx + r_len);

those casts are necessary due to sign-conversion errors

/workspaces/meta-sentron/build/workspace/sources/stm32mp-sign-tool-native/stm32mp-sign-tool.cpp:260:58: error: conversion to ‘__gnu_cxx::__normal_iterator<const unsigned char*, std::vector<unsigned char> >::difference_type’ {aka ‘long int’} from ‘size_t’ {aka ‘long unsigned int’} may change the sign of the result [-Werror=sign-conversion] 260 | std::vector<unsigned char> r_bytes(der_sig.begin() + idx, der_sig.begin() + idx + r_len); | ^~~ /workspaces/meta-sentron/build/workspace/sources/stm32mp-sign-tool-native/stm32mp-sign-tool.cpp:260:81: error: conversion to ‘__gnu_cxx::__normal_iterator<const unsigned char*, std::vector<unsigned char> >::difference_type’ {aka ‘long int’} from ‘size_t’ {aka ‘long unsigned int’} may change the sign of the result [-Werror=sign-conversion] 260 | std::vector<unsigned char> r_bytes(der_sig.begin() + idx, der_sig.begin() + idx + r_len); | ^~~ /workspaces/meta-sentron/build/workspace/sources/stm32mp-sign-tool-native/stm32mp-sign-tool.cpp:260:87: error: conversion to ‘__gnu_cxx::__normal_iterator<const unsigned char*, std::vector<unsigned char> >::difference_type’ {aka ‘long int’} from ‘size_t’ {aka ‘long unsigned int’} may change the sign of the result [-Werror=sign-conversion] 260 | std::vector<unsigned char> r_bytes(der_sig.begin() + idx, der_sig.begin() + idx + r_len);

Copilot · 2025-12-08T09:39:29Z

stm32mp-sign-tool.cpp

+        return {};
+    }
+
+    std::vector<unsigned char> s_bytes(der_sig.begin() + static_cast<std::ptrdiff_t>(idx), der_sig.begin() + static_cast<std::ptrdiff_t>(idx + s_len));


[nitpick] The explicit cast to std::ptrdiff_t is unnecessary here. Vector iterators support arithmetic operations directly with size_t values.

those casts are necessary due to sign-conversion errors

Copilot · 2025-12-08T09:39:30Z

stm32mp-sign-tool.cpp

+    std::copy(r_bytes.begin(), r_bytes.end(), raw_sig.begin() + static_cast<std::ptrdiff_t>(32 - r_bytes.size()));
+
+    // Copy s (right-aligned in second 32 bytes)
+    std::copy(s_bytes.begin(), s_bytes.end(), raw_sig.begin() + static_cast<std::ptrdiff_t>(32 + (32 - s_bytes.size())));


[nitpick] The explicit cast to std::ptrdiff_t is unnecessary here. Vector iterators support arithmetic operations directly with size_t values.

Suggested change

std::copy(r_bytes.begin(), r_bytes.end(), raw_sig.begin() + static_cast<std::ptrdiff_t>(32 - r_bytes.size()));

// Copy s (right-aligned in second 32 bytes)

std::copy(s_bytes.begin(), s_bytes.end(), raw_sig.begin() + static_cast<std::ptrdiff_t>(32 + (32 - s_bytes.size())));

std::copy(r_bytes.begin(), r_bytes.end(), raw_sig.begin() + (32 - r_bytes.size()));

// Copy s (right-aligned in second 32 bytes)

std::copy(s_bytes.begin(), s_bytes.end(), raw_sig.begin() + (32 + (32 - s_bytes.size())));

those casts are necessary due to sign-conversion errors

Copilot · 2025-12-08T09:39:30Z

stm32mp-sign-tool.cpp

+    std::copy(r_bytes.begin(), r_bytes.end(), raw_sig.begin() + static_cast<std::ptrdiff_t>(32 - r_bytes.size()));
+
+    // Copy s (right-aligned in second 32 bytes)
+    std::copy(s_bytes.begin(), s_bytes.end(), raw_sig.begin() + static_cast<std::ptrdiff_t>(32 + (32 - s_bytes.size())));


[nitpick] The explicit cast to std::ptrdiff_t is unnecessary here. Vector iterators support arithmetic operations directly with size_t values.

Suggested change

std::copy(s_bytes.begin(), s_bytes.end(), raw_sig.begin() + static_cast<std::ptrdiff_t>(32 + (32 - s_bytes.size())));

std::copy(s_bytes.begin(), s_bytes.end(), raw_sig.begin() + (32 + (32 - s_bytes.size())));

those casts are necessary due to sign-conversion errors

Copilot · 2025-12-08T09:39:30Z

stm32mp-sign-tool.cpp

+    std::cout << "  -o  Output signed image file" << std::endl;
+    std::cout << "  -h  Output file for public key hash" << std::endl;
+    std::cout << "  -s  Output file for hash to sign" << std::endl;
+    std::cout << "  -d  Input signature file (DER format)" << std::endl;


The help text states 'DER format' only, but the implementation accepts both DER and raw 64-byte signatures. Update to '-d Input signature file (DER or raw format)' for accuracy.

Suggested change

std::cout << " -d Input signature file (DER format)" << std::endl;

std::cout << " -d Input signature file (DER or raw format)" << std::endl;

added suggestion

embetrix · 2025-12-08T11:11:58Z

Hi @sebastian-bantel,

what kind of key infrastructure are you using?
this tool already supports HSM based signing through PKCS#11, so I’m a bit hesitant to add additional code paths for what seems to be a rather niche usage of this feature.

From my perspective this MR increases the code complexity for a very specific use case.

Could you explain why the existing PKCS#11 support is not sufficient for your setup, and which requirements are still missing?

As for the hash generation I’m using the combined hash-and-sign operation directly in a single step to avoid extra public key handing code:

Example of usage in yocto:

https://github.com/embetrix/meta-stm32mp15x/blob/scarthgap/classes/stm32mp15x-sign.bbclass#L14

embetrix · 2025-12-08T11:04:26Z

stm32mp-sign-tool.cpp


-int hash_pubkey(const char* key_desc, const char* passphrase, const std::string &output_file) {
-    if (!key_desc || output_file.empty()) {
+int load_public_key(const char* key_desc, EC_KEY** ec_key) {


load_public_key
should also handle loading keys from pkcs11 token

added pkcs11 support and tests for this use case

sebastian-bantel · 2025-12-08T12:37:26Z

Hi @sebastian-bantel,

what kind of key infrastructure are you using? this tool already supports HSM based signing through PKCS#11, so I’m a bit hesitant to add additional code paths for what seems to be a rather niche usage of this feature.

From my perspective this MR increases the code complexity for a very specific use case.

Could you explain why the existing PKCS#11 support is not sufficient for your setup, and which requirements are still missing?

As for the hash generation I’m using the combined hash-and-sign operation directly in a single step to avoid extra public key handing code:

Example of usage in yocto:

https://github.com/embetrix/meta-stm32mp15x/blob/scarthgap/classes/stm32mp15x-sign.bbclass#L14

Thanks for the quick response!

In my company we use SignClient CLI from keyfactor: https://docs.keyfactor.com/signserver/7.0/client-cli.
There is maybe an option to use the https://docs.keyfactor.com/container/latest/ejbca/hsm-integration. I will clarify this.

My change decouples the hash generation and signing process and image generation. This should work with every infrastructure.

I also want to sign my images with dev keys during CI build and want to be as close as possible to the real signing process.

embetrix · 2025-12-08T12:50:03Z

@sebastian-bantel

> My change decouples the hash generation and signing process and image generation. This should work with every infrastructure.

=> Okay if addressed in separate PR, it should however handle public key usage from pkcs11 token as well.

> I also want to sign my images with dev keys during CI build and want to be as close as possible to the real signing process:

=>Regarding signing images with dev keys in CI: I already have several customers doing exactly this : either by using separate key slots in the same HSM for development vs. production or by using a SoftHSM that mirrors the real signing setup.

sebastian-bantel · 2025-12-08T13:17:49Z

@embetrix

I will have a look on: pkcs11 tokens

I am not 100% sure how this HSM works but in my company the HSM is stored in a different city. The HSM is indirectly called via SignClient or RestAPI calls.

embetrix · 2025-12-08T14:02:49Z

@sebastian-bantel

The existing implementation already supports Net HSM setups via PKCS#11.
as long as your HSM vendor provides a PKCS#11 library on the host, it doesn’t matter whether the hardware is local or sitting in another city/country, PKCS#11 abstracts that away.

A typical example of this is AWS CloudHSM, which is also accessed via a PKCS#11 client library: https://aws.amazon.com/cloudhsm/
https://docs.aws.amazon.com/cloudhsm/latest/userguide/pkcs11-library.html

If you’d like to integrate a specific HSM setup or need help adapting this to your environment, I can gladly provide commercial support.

- add option to create hash to sign - add option to create signed image using public key and external signature file (DER format or raw) - add option to create public key hash from public key file - update tests to cover new functionality - update usage instructions

sebastian-bantel · 2025-12-10T08:29:42Z

@embetrix

I got an official answer from our signing client department:

Unfortunately, we don’t provide direct access to HSM. OpenSSL provider are also not maintained

From my point of view I need the changes I made

Feel free to merge this pull request or request further changes

embetrix · 2025-12-10T08:51:35Z

@sebastian-bantel :
thanks a lot for the work and all the changes.
I’ll be honest, this introduces quite a big changes to the core code and seems very specific to your project’s requirements. I’d prefer not to merge this into the master code base as it adds extra complexity to the generic path.

What I can do, however, is push your changes to a dedicated branch so you can continue to use and maintain them there ?

Independently of this, I’m planning to introduce changes for signing the new STM32MP23x / STM32MP25x parts as soon as a customer needs it and I’ll keep that implementation as generic/simple as possible.

embetrix · 2025-12-10T08:59:32Z

@sebastian-bantel I’m also wondering how you plan to handle signing of the FIP, FITimage, Software Update and the other components of the secure boot chain: those will also need to be adapted for offline signing.

sebastian-bantel · 2025-12-15T14:11:47Z

@sebastian-bantel I’m also wondering how you plan to handle signing of the FIP, FITimage, Software Update and the other components of the secure boot chain: those will also need to be adapted for offline signing.

@embetrix
thanks for sharing all your information!

As far as I understand now I need to extend cert_create tool to sign the FIP image offline. When I am able to securely boot to u-boot cmd line I can reuse further internal workflows to load FIT image and rootfs securely.

I'm still in discussion with our signing service. They may provide OpenSSL's PKCS#11 ENGINE

embetrix requested a review from Copilot December 8, 2025 09:38

Copilot AI reviewed Dec 8, 2025

View reviewed changes

embetrix self-assigned this Dec 8, 2025

embetrix reviewed Dec 8, 2025

View reviewed changes

sebastian-bantel force-pushed the feat/noPrivatKeyUsage branch from 53eaeac to d4f9fe3 Compare December 10, 2025 08:16

sebastian-bantel force-pushed the feat/noPrivatKeyUsage branch from d4f9fe3 to 9baedc2 Compare December 10, 2025 08:24

	std::vector<unsigned char> r_bytes(der_sig.begin() + static_cast<std::ptrdiff_t>(idx), der_sig.begin() + static_cast<std::ptrdiff_t>(idx + r_len));
	std::vector<unsigned char> r_bytes(der_sig.begin() + idx, der_sig.begin() + idx + r_len);

	std::copy(s_bytes.begin(), s_bytes.end(), raw_sig.begin() + static_cast<std::ptrdiff_t>(32 + (32 - s_bytes.size())));
	std::copy(s_bytes.begin(), s_bytes.end(), raw_sig.begin() + (32 + (32 - s_bytes.size())));

	std::cout << " -d Input signature file (DER format)" << std::endl;
	std::cout << " -d Input signature file (DER or raw format)" << std::endl;

Conversation

sebastian-bantel commented Dec 8, 2025

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI Dec 8, 2025

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

embetrix commented Dec 8, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sebastian-bantel commented Dec 8, 2025

Uh oh!

embetrix commented Dec 8, 2025

Uh oh!

sebastian-bantel commented Dec 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

embetrix commented Dec 8, 2025

Uh oh!

sebastian-bantel commented Dec 10, 2025

Uh oh!

embetrix commented Dec 10, 2025

Uh oh!

embetrix commented Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

sebastian-bantel commented Dec 15, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

sebastian-bantel commented Dec 8, 2025 •

edited

Loading

embetrix commented Dec 10, 2025 •

edited

Loading