Is the public key used for the wireless coprocessor firmware images and unencrypted header/footer documented and available somewhere?

Tim.N · ‎2020-10-29

I'd like to validate that a given wireless firmware image will install before attempting to erase the existing wireless firmware stack (we have external storage via SPI that we download updates into). Since the firmware images are signed so that the FUS stack can validate the firmware images, I was wondering if the signature is in plaintext such that you can validate the image with the existing file format without needing the decryption key (which is inside the FUS image).

That requires the following properties:

The public key used to sign the images is public
The header and/or footer of the images are in plaintext

Otherwise, I can just wrap in my own format if required but was hoping the existing file format already covered this. Additionally, ideally there'd also be a signed plaintext portion of the image containing the image details (version information, and stack type).

Thanks in advance!

Tim.N · ‎2020-11-08

Hi all -

In case anyone else is looking for it, I was able to extract the public key from the FUS image. Here it is in case anyone else wants to validate their firmware binaries before invoking FUS:

-----BEGIN PUBLIC KEY-----

MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE4G3DuozpSOTxJSp2X7QSfcwoHQnN

WTlQY3Z3i+dHphMo8KDfiPAZV3eKnmhrxD3V0u7ee+6w3k4nTq7avJoYOA==

-----END PUBLIC KEY-----

Thanks,

Tim

View solution in original post

Remi QUINTIN · ‎2020-11-03

A customer can’t encrypt/sign his own code (because we don’t provide ST Symmetric key AES-128 GCM)

Only ST code can be encrypted and signed for FUS.

Authentication is based on RSA ECC Prime256v1 (NIST P-256) and HASH-256

Customer can sign any code he wants (ST code or his own code).

It will be authenticated at first stage by FUS but authentication will fail at second stage if it is not ST code.

(because customer doesn’t have ST private/public keys).

Customer signature is over ST signature (it doesn’t replace it).

Tim.N · ‎2020-11-03

Hi Remi -

I think you misunderstood; I want to validate that a given firmware file was signed by ST before erasing the existing wireless firmware image for upgrading to the new firmware file. Is this possible?

To do so it'd require:

The public key (not the private, which is required for signing)
The format of the header/footer containing the signature
The signature has to be over the encrypted version of the firmware image (what we see), and the signature must be in plaintext

Otherwise, I can just sign firmware images as "blessed" but it'd be nicer if I could just validate the ST firmware files directly without having to add my own wrapper.

Thanks!

Tim

Tim.N · ‎2020-11-03

Hi @Remi QUINTIN -

I did a little more digging today, and I did find the footer format documented inside AN5185 section 6.4. Additionally, in section 4, it states that if a user TAG is added, that it's computed using ECC Prime256v1 and a SHA256 hash. Presumably the ST tag is also using the same algorithm. Here are the decoded headers, for instance, for the latest light_fw.bin stack:

stm32wb5x_BLE_Stack_light_fw.bin
ST Signature found from 123136 to 123156
footer magic: d3a12c5e
source:     87
size:       64
major:      34
minor:      17
subversion: 0
branch:     4
build:      5
Signature:
0000: 09 79 48 24 5f da 35 5b 2f 41 33 3d 98 88 cd 46 
0010: d3 f7 c7 2e f8 72 19 3d 1d c1 63 fb 26 87 77 3d 
0020: 32 35 6a e3 fd 39 c8 73 b9 79 bb ed c7 6b 2f eb 
0030: 0d 8a 53 be c3 d7 ab c9 2c 1c 8e ca bc 32 6f f2 
 
Wireless stack image found from 123052 to 123072
data: cd ab cd ab cd ab cd ab
sram2a:     18
sram2b:     13
flash:      31
major:      1
minor:      9
subversion: 0
branch:     0
build:      2

Regardless I cannot find the public portion of the ECC key used for signing these images in any documentation. Am I missing this somewhere? (Again, I'm not looking for the private portion of the key; only the portion that allows me to validate that an image was indeed signed by ST so that I can pre-validate it in the firmware before erasing and programming the internal flash; we have external flash where images are downloaded to.)