Signing FSBL image using keys stored in AWS KMS

[meetalipatel]

Objective

Sign STM32MP23 firmware using AWS KMS ECDSA P-256 keys instead of local private keys, to enable cloud-based signing workflow.

• Hardware: STM32MP23 series
• Header Version: 0x00020200 (v2.2.0)
• Signing Algorithm: ECDSA_SHA_256 (P-256 NIST / secp256r1)

Development and Issues summary as follows

We have followed following ways to sign binaries externally

1. Using external HSM - SoftHSM
   • This method shows the exact same issue mentioned in community thread
     Error: Invalid Header version value
     Header v2.2 accepts 8 public keys
   • If we skip the header version argument, the signing tool fails with CKR_OBJECT_HANDLE_INVALID error.
2. Using PKCS#11 solution along with aws-kms-pkcs11
   • With this method too, we face similar errors as mentioned in #1.
   • With header version 2.2 argument, it gives Invalid header error
   • If we skip the header version argument, the signing tool fails with CKR_OBJECT_HANDLE_INVALID error.

3. Developed a custom signing script (Compatible with the STM32 Signing workflow)

   • Firmware signed is rejected by STM32MP2 boot ROM during authentication.

For custom signing script

Firmware signed with AWS KMS ECDSA signatures is rejected by STM32MP2 boot ROM during authentication, despite:

• Header construction being identical to STM32 signing tool output (except Image signature)
  • Authentication, Pad and Post header 2.2 information are identical to sign image generated by STM32 signing tool which is working. (Validated using STM32_SigningTool_CLI -dump).
  • This proves that extracted public key from AWS KMS and local PEM are identical.
• Signature format matching STM32 signing tool (Signature Format: raw r|s, 64 bytes, big-endian)
• SHA256 Hash is calculated from header version field (offset 0x48) to end of image.
• AWS KMS verify() API confirming the signature is mathematically valid for the hash.

WORKAROUND:

The image signature field (offset - 0x04) is updated to match the signed binaries generated by the STM32 signing tool using the local PEM key (Refer). The signed firmware boots successfully on the same hardware.

Workaround confirms STM32 header generated by script matches the STM32 header specification except image signature field.

Signing Workflow followed:

1. Read unsigned firmware
2. Align image length to 32 bytes
3. Build authentication extension with public key hashes
4. Build padding extension (Currently used same as generated by Firmware signed with local PEM key using STM32 tool)
5. Calculate SHA256 hash of signed region (from 0x48 to end of image)
6. Sign hash using AWS KMS Sign API (MessageType='DIGEST', SigningAlgorithm='ECDSA_SHA_256')
7. Convert DER signature (70 bytes) to raw r|s format (64 bytes) (Also tried normalised s)
8. Write signature at offset 0x04
9. Write signed firmware to output file

STM32MP2 boot ROM should accept AWS KMS-generated signatures if header construction matches STM32 specification. 

Questions for ST Community

1. Does STM32MP2 boot ROM have any specific requirements for ECDSA signature generation beyond standard ECDSA validation?
2. Are there any additional signature verification steps in boot ROM not documented in the public specification?
3. Is low-S normalization required or prohibited by STM32 boot ROM?
4. Are there any constraints on the nonce/k-value generation that AWS KMS might not satisfy?
5. Has anyone successfully used AWS KMS (or similar cloud HSM services) for STM32MP2 firmware signing?

Thanks & Regards

Meetali Patel