No. CC3235SF currently only supports up to 2048b keys.

Which CA have you checked? (we are aware of the problem with DigiCert but not with other CAs).

Hi Kobi,

I have checked Commodo, Sectigo, digicert and Global Sign. The resellers told me, that they have change their policies concerning the key length in spring this year.

Thanks. We are checking this.

In the meantime, please check the option of using Self Signed certificate and using you own catalog. See https://www.ti.com/lit/pdf/swru547 for details.

Br,

Kobi

Hi Kobi,

Thank you for the reference to document SWRU547a.

For your information: Since 01.01.2021, official CAs only issue code signature certificates with a key length greater than 3072 bits.

After reading the document SWRU547a, there are some open questions that the document does not answer or omits.

The aim of the following description is to create a vendor-specific code signature certificate to secure the firmware of our CC3235MODSF project.

I am not a specialist in the generation of certificates. Therefore, it is important for us to check the procedure described below with TI. A faulty OTP content will inevitably lead to an unusable CC3235SF module or device.

Before generating the OTP content and the certificate list, a vendor-specific root CA certificate and a code signature certificate are required. As described in document SWUP332A, we used OpenSSL to generate the keys and certificates.

Procedure for key and certificate generation

Create a vendor specific root CA certificate

1. Generation of a self-signed root CA certificate "my-root-ca.crt" including the private key "my-root-ca-key.key". The key file "my-root-ca-key.key" is not encrypted with a password.

          openssl req -x509 -sha256 -days 3650 -newkey rsa:2048 -nodes -keyout my-root-ca-key.key -out my-root-ca.crt

2. Convert the certificate "my-root-ca.crt" into DER and PEM format.

          openssl x509 -in my-root-ca.crt -outform der -out my-root-ca.der

          openssl x509 -in my-root-ca.crt -outform pem -out my-root-ca.pem

3. Convert private key "my-root-ca-key.key" into PEM format.

         openssl rsa -in my-root-ca-key.key -out my-root-ca-key.pem

Create a vendor specific Code Signature Certificate

1. Generation of a code signature request "my-code-cert.csr" with private key "my-code-cert-key.key"

          openssl req -newkey rsa:2048 -sha256 -nodes -keyout my-code-cert-key.key -out my-code-cert.csr

2. Signing the CSR file "my-code-cert.csr" with "my-root-ca.crt".

         openssl x509 -req -CA my-root-ca.crt -CAkey my-root-ca-key.key -in my-code-cert.csr -out my-code-cert-ca.crt -days 3650

3. Convert the code signature certificate “my-code-cert-ca.crt“ into DER and PEM format.

           openssl x509 -in my-code-cert-ca.crt -outform der -out my-code-cert-ca.der

           openssl x509 -in my-code-cert-ca.crt -outform pem -out my-code-cert-ca.pem

4. Convert private key "my-code-cert-key.key" into the PEM format.

          openssl rsa -in my-code-cert-key.key -out my-code-cert-ca-key.pem

Generate the certificate catalogue for a CC3235SF device

The certificate catalogue is generated with the "SLImageCreator" according to document SWRU547a.

1. Copy the certificates "my-root-ca.der" and "my-code-cert-ca.der" into the directory "C:\Certs\KnownCAs". All other certificates and keys are in the directory "C:\Certificates".

2. Generation of the certificate catalogue "my-cert-catalog-20211022.lst".

          SLImageCreator.exe tools make_cert_catalog --cert_folder "C:\Certs\KnownCAs" --out_file "C:\Certs\my-cert-catalog-
         20211022.lst"

3. Signing the certificate catalogue "my-cert-catalog-20211022.lst" with "my-root-ca-key.pem".

         SLImageCreator.exe tools sign --file "C:\Certs\my-cert-catalog-20211022.lst" --priv "C:\Certificates\my-root-ca-key.pem"
         --out_file "C:\Certs\my-cert-catalog-20211022.lst.signed.bin" --fmt "BINARY_SHA2"

Creating the OTP content for a CC3235SF device

The OTP content is created with the "SLImageCreator" according to document SWRU547a.

1. Generate OTP metadata file

          SLImageCreator.exe tools meta --cert "C:\Certificates\my-root-ca.pem" --out_file "C:\OTP\evotron-ca_otp.meta"
         --mac "000000000000" --usechain

2. Signing the metadata file

         SLImageCreator.exe tools sign --file "C:\OTP\evotron-ca_otp.meta" --priv "C:\Certificates\my-root-ca-key.pem"
        --out_file "C:\OTP\evotron-ca_otp.meta.sig" --fmt "BINARY_SHA2"

3. Generating the OTP .inf file

          SLImageCreator.exe tools inf --algo 2 --sign1 "C:\OTP\evotron-ca_otp.meta.sig"
         --sign2 "C:\OTP\evotron-ca_otp.meta.sig" --meta "C:\OTP\evotron-ca_otp.meta" --out_file "C:\OTP\evotron-ca_otp.inf"

The file "evotron-ca_otp.inf" has been created in the directory "C:\OTP", refer screenshot.

The next screenshot shows the structure of our vendor-specific certificate catalogue.

Generating an OTA image with our vendor-specific certificate catalogue

The OTA image is created with "UniFlash" V 6.4.0.

1. Selection of the certificate catalogue

2. Including the TI service pack

3. Adding the certificates

4. Adding the MCU image

5. Generation of the OTA file with "Skip Security”

I have uploaded the generated TAR archive for checking.

20211021153136_CC3220SF_DCC240x.tar

Kobi,

Please would you be so kind to check or let check my procedure. The OTP can only be programmed once. If there is an error or fallacy in my procedure, then a CC3235SF is unusable.  Silicon is rare and expensive.

Many thanks in advance for your kind assistance.

Kind regards

Ulrich

Hi Kobi,

Thank you for your kind support, but I have some more questions.

1. So far, I have not been able to install the vendor-specific certificates. So far I have done the following:

I have generated the following certificates and keys:

- root CA certificate "evotron-root-ca",
- Code signature "dcc2404-cert-ca", signed with root CA
- OTA signature "ota-dcc2404-cert-ca", signed with the code signature

After this I have generated the certificate catalogues and the OTP info file according to the instructions.

Now I am trying to load the certificate catalogue, the certificates, the OTP and the MCU image in the CC2'3235SF with the UniFlash 6.0.0 and somehow I am not able to get any further. I am right in assuming that the OTP is programmed via UART0 and not via OTA. Is this assumption correct? Section 7.4 on page 13 of the SWRU547A document says the following:

The last sentence of section 7.4 says that the MCU image must be signed with the root CA key. Does this only apply to this one image with the OTP content? Can all other MCU images without OTP content subsequently be signed with the code signature certificate?

2. Then another question regarding the encryption of the OTA bundle. Where in the UniFlash tool is it specified which certificate is to be used to encrypt the OTA bundle.

Kind regards,

Ulrich

Hi Ulrich,

Only for the catalog update you need the OTP private key (since the catalog is signed by it). For other OTA updates that do not involve the catalog, you can use whatever key you like but the matching public key (the certificate) must resides already in the file system and its filename must be updated accordingly in the MCU code that handles OTA.

Please refer to:

• <SDK installation directory>/tools/cc32xx_tools/ota-example-cert for examples of the key. Read the short README file for the required key type
• look at OtaArchive.c and look for OTA_CERTIFICATE_NAME definition that states the OTA certificate filename

Regards,

Shlomi

Hi Shlomi,

Thanks for your reply to my second question. But the second question is only a side show.

I have the problem with the vendor specific code signing certificate. I have found an solved issue in the e2e where Kobi told the custumer that the OTP does not support certificate chains. Please refer here: https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/912445/cc3235sf-vendor-specific-certificate-catalog-and-otp---not-working

That is why I have generated a vendor specific root CA with key as described above. Then I have generated a vendor specific certificate catalog containing the root CA only and a OTP inf-file as described above.

After this I use UniFlash 6.0.0 as Kobi told me to test the vendor specific certificate. I have add the generated vendor specific certificate catalog,

the service pack, the certificate

and the MCU-Image signed with the private key of my-root-ca.pem. Then I have start the programming using UART0. Uniflash prepares some files, one with a size 94708 of and another with a size of 1008 and than the image programming runs up to 99%. At the end it fails with:

I don't know what is the reason for that issue.

Regards,

Ulrich

Hi,

First, using an old Uniflash would only work on Gen2 devices, i.e. CC3220. For Gen3, the older Uniflash does not have the bug so whatever you flashed to the OTP is already flashed and you cannot change it.

However, I still don't see an issue with the procedure as you included the root CA certificate in the OTP section and also included it in the catalog.

The error you get usually indicates that authentication of the mcuflashimage fails when tested against the catalog.

What certificate are you using with mcuflashimage? is it the your root CA?

Shlomi

Hi Shlomi,

I have use my root CA to sign the mcuflashimage.

But I beleave that the OTP is not programmed because I can flash the CC3235SF with the certificates of the playground.

Ulrich

what if you check the "use vendor certificate catalog" and uncheck the "add otp file" and then flash? does it give you an error?

Shlomi

I have checked tihis too and it gives me the same error.

But I have an idea what's the reason for this behavior. In SWRU455m chapter 8.4.7 is written:

And then I have analyzed the dummy-root-ca-cert of the playground:

Thus this mean, that this is a requirement? If yes, then there is my fault.

Ulrich

Hi,

I don't think this is the issue as the certificate does have CN.

Just for the test, can you remove the mcuflashimg from the user files and make sure you can program?

As I mentioned earlier, I believe that the error is triggered when the certificate used for the mchflashimg is tested against the catalog.

Also, can you share the public certificates you created (not the private key of course)?

Shlomi

Hi Shlomi,

programming without the mcuflashimg runs without an error message.

This is the public certificate which I have created with the following openSSL-command:

openssl req -x509 -sha256 -days 3650 -newkey rsa:2048 -nodes -keyout C:\Certificates\evotron-root-ca-key.key -out C:\Certificates\evotron-root-ca-cert.crt

-----BEGIN CERTIFICATE-----
MIIENzCCAx+gAwIBAgIUJFXLkxtur2C76IKIwrUtnXILlWkwDQYJKoZIhvcNAQEL
BQAwgaoxCzAJBgNVBAYTAkRFMRMwEQYDVQQIDApUaHVlcmluZ2VuMQ0wCwYDVQQH
DARTdWhsMR4wHAYDVQQKDBVldm90cm9uIEdtYkggJiBDby4gS0cxEzARBgNVBAsM
CkNBLWV2b3Ryb24xHTAbBgNVBAMMFGV2b3Ryb24tcm9vdC1jYS1jZXJ0MSMwIQYJ
KoZIhvcNAQkBFhRpbmZvQGV2b3Ryb24tZ21iaC5kZTAeFw0yMTEwMjYxMzQ3Mjha
Fw0zMTEwMjQxMzQ3MjhaMIGqMQswCQYDVQQGEwJERTETMBEGA1UECAwKVGh1ZXJp
bmdlbjENMAsGA1UEBwwEU3VobDEeMBwGA1UECgwVZXZvdHJvbiBHbWJIICYgQ28u
IEtHMRMwEQYDVQQLDApDQS1ldm90cm9uMR0wGwYDVQQDDBRldm90cm9uLXJvb3Qt
Y2EtY2VydDEjMCEGCSqGSIb3DQEJARYUaW5mb0Bldm90cm9uLWdtYmguZGUwggEi
MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDwuFyukvfK9jOf2ZGZYXlIB9r8
+kuX0/B7M8kzjkAKYwJUIEgt0Ut15zxeuBp23opZZj8sErwopnxiaqzY/MfMdi2l
nLs2kor9QG1vQA25xXWiZ3OvdWIlmvkerHrRvI4MN4Ddf1p9oG44mbY6UPoAM4zF
Hjzd4xUyrGxsZvAdrXx8R/JVAfWm5TAOuUor92otN8TRd7+vKeKJWraaT5e/eppL
k0mofrQVyRtG+VgQMH/3KOVEA91DavA/S1U2qos/Gy0pamPfgabgo9dFRYZl/WzG
lf0sMzN0DhqT/o2r7fecxZw1SIQI0o8fc2kT+3KXrU0AmsUuyhpqMUaIqXprAgMB
AAGjUzBRMB0GA1UdDgQWBBQRkKWFcrK9sVq+SOej3DYTgOVMKDAfBgNVHSMEGDAW
gBQRkKWFcrK9sVq+SOej3DYTgOVMKDAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3
DQEBCwUAA4IBAQAX0aQ/a/00gSNZsVyt8h6AoNU0nJrOxFoFiibYLNHMAfxpJ6j5
yBJFF65XwCtVuB81hZdC1fuWl4Ubclo9NGJxNaxR39qQYPaorgXIhLhrmHvLdPau
ui05KdlAyMC0PUKNHB9LrTiNFsbgKklJ/ReW+5cBcbjD4SAVC5h1xIWebfcGl+S3
xAqKWBU1AvjHTtHJJiogSVY62TEDmsm/5Ci1daBKtOnkCuYw/ZT/O0eb2rFBiQFB
VJRXMFlM6hnxSP4aTACCOK6gO6KkoAnv2fgu3rKWcRdJvaOA0O+Fwb1PfxJ4bY/E
bRZI4kQxaNonIFzUe0WCpKGVESKYJRWKuEGb
-----END CERTIFICATE-----

Regards

Ulrich

Hi Shlomi,

I have read the documents SWRU547A and SWPU332A again. So am I right in the following:

I must generate 2 certificates, a vendor root CA “my-root-ca-cert” and a code signing certificate “my-app-ca-cert”.

The OTP inf-file “my-otp.inf” contains the vendor root CA “my-root-ca-cert.pem”. This certificate is generated with the openSSL command:

openssl req -x509 -sha256 -days 3650 -newkey rsa:2048 -nodes -keyout C:\Certificates\my-root-ca-key.key -out C:\Certificates\my-root-ca-cert.crt

The certificate catalog contains the code signature certificate “my-app-ca-cert.der”. The Certificate catalog is signed with the private key of “my-root-ca-cert”. The code signature certificate is generated with the openSSL command:

openssl req -x509 -sha256 -days 3650 -newkey rsa:2048 -nodes -keyout C:\Certificates\my-app-ca-key.key -out C:\Certificates\my-app-ca-cert.crt

The private key of “my-app-ca-cert” is used to sign the MCU Image.

Both certificates “my-root-ca-cert” and “my-app-ca-cert” are placed in PEM-format in the root of the programming image.

If I understand chapter 2.2 of SWPU332A right, than the CN of the code signing certificate "my-app-ca-cert" must be "my-app-ca-cert".

So I will try this tomorrow.

Regards,

Ulrich

Good morning Slomi,

I have done this as you have recommended, but it doesn't run. Every time the same error message.

So I have analysed the TI playground certificates "dummy-root-ca-cert" and "dummy-trusted ca-cert" you see the following, "dummy-trusted-ca-cert" is signed by "dummy-root-ca-cert". Both are stored in DER-format in the playground.

So I have done this too, that meas:

The certificate "my-root-ca-cert" as above mentioned is stored in the OTP and the certificate catalog is signed with the private key of "my-root-ca-cert"..

I have generated a root certificate for my app "my-app-root-cert". This is stored in the certificate catalog. And I have generated the code signature for my app "my-app-ca-cert" which is signed by "my-app-root-cert".

So the OTP contains the public key for encrypting the certificate catalog. The certificate catalog contains "my-app-root-ca", the public key for encrypting the code signing certificate "my-app-ca-cert". The code signing certificate encrypts the mcuflashimg.

I have tested this without any success. It is frustrating!

Questions:

1. Is there something special to know for the generation of the custumer certificate, which is stored in the OTP. I have done this with the following openSSL command:

openssl req -x509 -sha256 -days 3650 -newkey rsa:2048 -nodes -keyout C:\Certificates\evotron-root-ca-key.key -out C:\Certificates\evotron-root-ca-cert.crt

The public key of this certificate is shown above.

2. Are there any other recommendation then the CN of the certificate concerning the generation of the code signature certificate? I have generated the certificate with the following openSSL comand:

openssl req -x509 -sha256 -days 3650 -newkey rsa:2048 -nodes -keyout C:\Certificates\my-app-ca-key.key -out C:\Certificates\my-app-ca-cert.crt

The public key is shown here:

-----BEGIN CERTIFICATE-----
MIIELTCCAxWgAwIBAgIUAMmxzgBOyFrKK9en0gMt+5ly510wDQYJKoZIhvcNAQEL
BQAwgaUxCzAJBgNVBAYTAkRFMRMwEQYDVQQIDApUaHVlcmluZ2VuMQ0wCwYDVQQH
DARTdWhsMR4wHAYDVQQKDBVldm90cm9uIEdtYkggJiBDby4gS0cxEzARBgNVBAsM
CkNBLWV2b3Ryb24xGDAWBgNVBAMMD2RjYzI0MDQtY2EtY2VydDEjMCEGCSqGSIb3
DQEJARYUaW5mb0Bldm90cm9uLWdtYmguZGUwHhcNMjExMDI3MDkwNDAzWhcNMzEx
MDI1MDkwNDAzWjCBpTELMAkGA1UEBhMCREUxEzARBgNVBAgMClRodWVyaW5nZW4x
DTALBgNVBAcMBFN1aGwxHjAcBgNVBAoMFWV2b3Ryb24gR21iSCAmIENvLiBLRzET
MBEGA1UECwwKQ0EtZXZvdHJvbjEYMBYGA1UEAwwPZGNjMjQwNC1jYS1jZXJ0MSMw
IQYJKoZIhvcNAQkBFhRpbmZvQGV2b3Ryb24tZ21iaC5kZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBALFcDkMyZ2jCgmU5OHk9eXmYlvwkRcH2Vuw7o+Sw
jRwaFw/FBtt+JsnlLPb175G8rHLj1Mq9a4nhxJS/MsF+phEeFOnHrHm4XMea+JxJ
Y6WppFId2J0DK51+6CTcBssII8UbvOxSFaxx3G1KdvlYfjY3VCNQSHpCNDvXZz7Q
b+Y4KLUCKEXG0+/JgDBsiStNvxju67jn4T3JJ3XwWTGnM5AqsQEsQttCRVMVyr+E
5ZUjwPBDqyrX80k9I2dftzY7g9FP2NLw+KTzjsjAmVwHvP7nk85AWCMyqyNVbFRm
89QOEfudGkNkviNe+Ykao8WJTdKUjJXopqtFBzM8lPMPruUCAwEAAaNTMFEwHQYD
VR0OBBYEFHoIldNcn+uCDSgB8UbqIFPSdlEUMB8GA1UdIwQYMBaAFHoIldNcn+uC
DSgB8UbqIFPSdlEUMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQELBQADggEB
AChm2MVL2r6WEWkurQxp3UKPaNeq/XnnxOaqdMoP61yj+SYse+E6f8lo26Gz9CNm
Hp8jLJTN4V5mycXH2P7SM7F7wRrexdx2Pq+WPeM1DjWSM6uI9uwXFSweI63/jE++
5d2TOFAUJcjIoNS7J0Chth3hnZt2jFqvBtbS+U629MPZI8kOFs23Gshc1ZXRCdA/
LIff3ZfVEymTEnXLqQOGXMO/8jEetg7tqpMa200mz9SxmfR/rN0Mw66JdeanXJbB
YaBQvxZI/T9ZBBIa2F3T+6G5RaI3cZouxzeFGmtMXeVLHNvm3ROlgTCQUAt0ou0q
MOmyyvg/yZH0rDkNVqbtgQc=
-----END CERTIFICATE-----

3. The playground certificates don't have a file extension. Is this a recommendation?

4. Are there any oher hints?

Shlomi,

I have a CC3220SF LaunchPad too. So if this feature in the UniFlash 6.0.0 exists. Could you recommend what to do.

Ulrich

Hi Shlomi,

Maybe the generation of the OTP inf-file makes the problem. I have done this as follows:

SLImageCreator.exe tools meta --cert "C:\Certificates\evotron-root-ca-cert.pem" --out_file "C:\Certificates\OTP\evotron-root-ca-otp.meta" --mac "000000000000" --usechain

Option --usechain is the option for signature 2, is this correct?

The next step:

SLImageCreator.exe tools sign --file "C:\Certificates\OTP\evotron-root-ca-otp.meta" --priv "C:\Certificates\evotron-root-ca-key.pem" --out_file "C:\Certificates\OTP\evotron-root-ca-otp.meta.sig" --fmt "BINARY_SHA2"

And at last:

SLImageCreator.exe tools inf --algo 2 --sign1 "C:\Certificates\OTP\evotron-root-ca-otp.meta.sig" --sign2 "C:\Certificates\OTP\evotron-root-ca-otp.meta.sig" --meta "C:\Certificates\OTP\evotron-root-ca-otp.meta" --out_file "C:\Certificates\OTP\evotron-root-ca-otp.inf"

I am ask me what's wrong.

Regards,

Ulrich

Hi,

I am a little confused with all the certificate names. Can you elaborate?

what eventually goes into the catalog?

is my_app_root_cert and my_app_root_ca the same?

What you need is to make sure your chain is linked OK as the example with the dummy_trusted_ca_cert you provided, i.e. the "Issued To" and "Issued By" are linked as expected.

If I take your my-app-ca-cert.crt which is the higher certificate in the chain, it seems like a self signed certificate which doesn't link to my_app_root_cert. see picture below:

Since this certificate is not in the catalog, it would fail.

What I suggest just for the test is to sign the mchflashimg directly with the lower certificate in the chain that you know for sure exists in the catalog.

Let me know if it works.

Shlomi

Ulrich Pahl1 said:

I have filled in the field "email address" when generating the certificate.This causes the error message "FS_WRONG_SIGNATURE", eroor code -10289. The sl_FsClose() interprets the certificate wrong or could not find the certificate in the firmware bundle.

Curious, was the solution to leave the email address field blank when generating the certificate?  Thanks.

David R.

Hi David, yes you must leave email address blank when generating your certificate or you will have an error.