CC3235S: Signed MCU Image in Gangimage: Certificate file name

Hi Johann,

A couple of ideas come to mind:

1. Can you try Program Image (Create & Program) in Uniflash to program a LaunchPad? This will skip the gang programming step. I want to isolate this issue as either a Uniflash issue or file location issue.

2. The certificate files should be located in the root folder. 

3. The certificate chain should be valid. The certificates are self-signed and each certificate must reference a prior level up to the root certificate. Here is a visual depiction:

In case you have not found these yet, the SimpleLink Certificate Handling Guide and UniFlash ImageCreator Guide may be helpful.

Thanks,
Jacob

Hi Jacob,

thank you for your reply. 
Re 3) Yes, i've done that. Our verification path looks like this "My Signing Certificate" (actual name differs) -> "DigiCert Trusted Root G4" (intermediate certificate) -> root catalog.
I've added both certificates to the gang image (with their Common Name attribute as the filename) and selected our certificate for the mcuimg.

In your picture, the vendor certificate is labeled as "Cert-XXX.der" - this doesn't match what the reference document says about the gangimage layout - the filename is the Common Name of the certificate without extension, correct?

After some more fiddling I've upgraded the SL_ERROR_FS_FILE_NOT_EXISTS to a SL_ERROR_FS_CERT_CHAIN_ERROR_SECURITY_ALERT (-10292) during gang programming.

According to other threads (e.g. https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/639835/cc3220-fs_security_alert_cert_chain_error-when-loading-image), this relates to the chain not being trusted.
How can i verify that the chain I've added to the gang image is indeed trusted up to the root catalog? The SimpleLink CC32xx Root Certificate Catalog page only lists the name of the root certificates.

I found another little piece of information in the docs:

After an updated service pack is used, the firmware supports additional certificate chain verification types:
– RSA 1024 to 4096
– SHA 1-512

Such certificates can be used within an OTA update, but not during production line.

Our certificate is indeed RSA-4096, which should be fine with the latest Servicepack, right? However:

Such certificates can be used within an OTA update, but not during production line.

Does that mean, a gangimage can only contain signatures created with certificates up to 2048 bit?

Hi Johann,

How can i verify that the chain I've added to the gang image is indeed trusted up to the root catalog? 

If you are using Windows, you can rename your certificate to be a .cer, so Windows recognizes the file as a certificate. Then, you can see where the certificate is issued. My picture above attemps to show you this; the root certificate is issued to itself. All other certificates must have a trail back to the root certificate. 

Does that mean, a gangimage can only contain signatures created with certificates up to 2048 bit?

You are correct. At first, the gang image only supports signatures with 256 or 128 bytes (depending on algorithm).

From Certificates Handling Guide:

Afterward, with OTA flashing, the signatures can be much larger (4096 in the case of RSA):

This is due to limitations of the ROM.

Best regards,

Jacob

Jacob B. said:

If you are using Windows, you can rename your certificate to be a .cer, so Windows recognizes the file as a certificate. Then, you can see where the certificate is issued. My picture above attemps to show you this; the root certificate is issued to itself. All other certificates must have a trail back to the root certificate. 

This only tells me if the Windows system can verify the chain up to the root in the Windows trust store. It doesn't tell me whether or not all the intermediate certificates are properly stored in the Gangimage and the intermediate certificate ends up in the TI trusted root catalog.


re: 2048 bits limitation: I'll try to get another signing certificate with 2048 bits.

Hi Johann,

Johann Schmitz said:

This only tells me if the Windows system can verify the chain up to the root in the Windows trust store. It doesn't tell me whether or not all the intermediate certificates are properly stored in the Gangimage and the intermediate certificate ends up in the TI trusted root catalog.

Just to make sure we've ruled common issues out, first, make sure your certificates are all located in the root folder. Next, make sure that your root certificate has issued a certificate to itself. Then, the other intermediate certificates should have a reference path to the root certificate. For example:

Is this what your certificate chain looks like?

Thanks,
Jacob

Hi Jacob,

This is our certificate chain:

Root:
Issuer: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Trusted Root G4
Subject: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Trusted Root G4

Intermediate:
Issuer: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Trusted Root G4
Subject: C = US, O = "DigiCert, Inc.", CN = DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1


Vendor:
Issuer: C = US, O = "DigiCert, Inc.", CN = DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1
Subject: ...


The three files validate properly with openssl:

$ openssl verify -verbose -CAfile <(cat DigiCertCA.crt TrustedRoot.crt) signing-cert.crt
signing-cert.crt: OK


I've add all three files (as DER) to the gang image, as DigiCert Trusted Root G4, DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1 and signing-cert

Now i'm trying to write a new secure file. I've validated that the signature is correct:

$ openssl dgst -verify signing.pubkey.pem -signature ../mcuimg.bin.sig ../mcuimg.bin
Verified OK

When I use 

sl_FsClose(fd, "signing-cert", signature, signature_len);

I always get the error -10290: SL_ERROR_FS_WRONG_SIGNATURE_OR_CERTIFIC_NAME_LENGTH.

Is there any way to manually confirm that the chain properly ends up in the TI root catalog? The Readme of the certificate catalog lists "DigiCert Trusted Root G4" but that doesn't mean it's referring to the very same certificate.

Hi Johann,

Your certificate chain looks correct to me. I'm going to check and see if I can reproduce this or another engineer has an idea. 

I'll respond to this thread by Wednesday.

Thanks,

Jacob

We support the DigiCert Trusted Root G4 (and any other root CA mentioned in the file), but the problem relates to the "DigiCert Trusted G4 Code Signing RSA4096 SHA384 2021 CA1".

We are not  supporting SHA384 and RSA4096 in our bootloader ROM code (as mentioned these method can be supported only after OTA) - so gang programming will fail.

There seems to be a problem with DigiCert currently since they only use SHA384 in their new set of intermediate and root CA certs.

Currently we can only recommend to get a certificate from another CA.

Br,

Kobi 

Hi Kobi,

Jacob already explained this issue further up in the thread.

This error happens during OTA too, where, according to the user guide, with an up-to-date service pack and root catalog signatures created with keys > 2048bit should be supported.

Hey Johann,

Please allow me another day to look into this for you. I'll give you more information tomorrow.

Thanks,
Jacob

Hi Johann,

Based on your mention of the error during OTA, I think Network Processor logs will help here. Can you follow this guide (Section 20) to provide us with logs?

Thanks,

Jacob