CC3220MODA: Public Keys, Private Keys or Both? for CC3220MODA with SF, Self Signed Certificate Authority

Hello Kobi,

Thanks for warning me about Gen1 and Gen2. This is the first I have heard.

In addition to the Gen1 document above, I spend lots of time last week with SWPU332A, and SWRU547A and several OpenSSL tutorials and Youtube videos.

I remain very confused about the vocabulary and the big picture of private key, public key, CSR and Trusted Root CA catalogs.

I remain doubtful of the TI documentation too.  In SWPU332A on page 13 section 2.1 is the openssl command which is described as making a private key and the CSR.

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

A few paragraphs later is another command which generates a CSR from an available private key.

openssl req -key in.key -new -out out.csr

I do not see how the public key gets to the CSR in the second case where the existing key is used to make a CSR.

There is no instruction that allows me to check the generated files.

Since these files will ultimatly be involved with a One Time Programing of the cc3220MODASF I sure want to get it right.

Still feeling confused.

Hello Kobi,

I am making some progress. Using a fictitious company name (ACME Conglomerate Inc.)  I practiced making some private key and CSR files using the command from page 13 of SWPU332A.  "openssl req -newkey rsa:2048 -sha256 -nodes -keyout out.key -out out.csr"

Using the command you provided above for reading the CSR I get results showing the public key and the fictitious company information.

So for an ACME Conglomerate self signed certificate I think I have everything I need. The private key, file name "out.key" the CSR file name "out.csr" and something like your openssl example but modified to use and existing key.

Would it be something like, "openssl req -nodes -in out.csr -x509 -days 365 -out certificate.pem" ?  Guess I will try. Perhaps I need to give it the private key too?  Yup seams like it.  "openssl req -nodes -key out.key -in out.csr -x509 -days 365 -out certificate.pem"

So now I think I have a self signed x509 certificate.

I wonder, how can I be sure?

At this point I have three important files.

File: "out.key" is the ACME Conglomerate Inc. HQ private key
File: "out.csr" is the ACME Conglomerate Inc. certificate signing request with the public key and company information.
File: "certificate.pem" is the ACME Conglomerate Inc. self signed x509 certificate.

The "certificate.pem" is my catalog of CA but I think I read I need it in DER format.  So I have to convert it.

I think the other two files are in PEM format which is acceptable for Uniflash image creation.

Getting back to this I found instructions for changing a certificate from PEM to DER at this web site: poftut.com/convert-der-pem-pem-der-certificate-format-openssl/

I used the command: openssl x509 -inform PEM -outform DER -text -in certificate.pem -out certificate.der and generated the new file: certificate.der

This file looks like:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            7a:1c:71:e8:f8:a4:72:5a:14:9c:b9:57:23:11:f0:c5:14:6c:76:aa
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, ST = NY, L = New York, O = ACME Conglomerate Inc., OU = HQ, CN = http://acmeconglomerate.com, emailAddress = admin@acmeconglomerate.com
        Validity
            Not Before: Aug 14 18:44:15 2019 GMT
            Not After : Aug 13 18:44:15 2020 GMT
        Subject: C = US, ST = NY, L = New York, O = ACME Conglomerate Inc., OU = HQ, CN = http://acmeconglomerate.com, emailAddress = admin@acmeconglomerate.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Modulus:
                    00:dd:49:59:d2:43:83:05:86:c8:f8:6b:ef:11:a6:
                    5b:c9:1c:14:d3:83:ae:13:d9:18:51:62:b3:dd:98:
                    72:7f:28:82:e4:a2:ae:b3:34:18:7b:f1:0b:df:0e:
                    1c:7c:3a:9e:6a:43:14:07:a5:fc:ab:ef:34:12:b5:
                    f2:1d:10:32:45:75:67:d6:ec:55:51:1f:4f:07:17:
                    ff:e6:5f:e0:3b:a2:cd:69:ac:85:2a:33:f3:72:c8:
                    40:c4:17:a7:6f:85:c9:54:ad:57:ac:be:c6:45:22:
                    b6:20:17:24:5a:05:b7:1a:e4:75:80:a5:36:b1:a8:
                    03:6a:87:0c:9c:90:0d:05:00:9c:5e:7a:d3:8f:27:
                    0e:b2:ce:46:ca:54:01:8e:02:8a:a8:9a:9f:3a:cb:
                    4c:d9:cc:de:1b:a8:06:09:d9:40:1c:2d:50:bd:12:
                    df:43:d2:d5:48:4f:a9:9b:c2:e8:49:65:14:7e:ee:
                    29:f3:bc:1b:45:e5:65:09:3c:2a:7a:85:86:c4:0b:
                    2a:20:ce:b9:06:aa:22:c8:55:4d:c5:01:1e:b1:ef:
                    5f:da:00:da:a3:c3:fa:db:6c:21:4d:84:c0:e8:55:
                    7c:05:47:c0:b9:96:30:85:0c:5b:50:98:d3:ee:fe:
                    d9:40:7e:8b:19:70:67:9a:23:a8:86:36:8d:86:1f:
                    6e:43
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                21:99:CA:D9:E1:15:45:C4:64:42:17:E8:83:51:A6:F7:DA:A3:FB:DF
            X509v3 Authority Key Identifier: 
                keyid:21:99:CA:D9:E1:15:45:C4:64:42:17:E8:83:51:A6:F7:DA:A3:FB:DF

            X509v3 Basic Constraints: critical
                CA:TRUE
    Signature Algorithm: sha256WithRSAEncryption
         c1:06:b7:70:08:0e:15:b3:59:9c:05:f3:98:f9:1a:b5:1f:25:
         3b:09:3a:f0:ce:71:9f:df:fc:af:74:23:78:ac:f8:85:f8:1f:
         74:6d:e9:58:cf:f8:94:e5:e2:5f:5c:f8:c8:6d:34:d9:99:e3:
         5c:75:eb:33:0a:b0:9c:77:c4:8e:8b:35:19:c2:2c:6a:d5:1b:
         84:50:5c:43:f5:34:dc:52:23:e6:23:a9:0d:db:73:86:df:4a:
         46:3c:5b:49:53:db:8b:d4:68:a0:39:ef:b3:45:f0:2d:9b:73:
         eb:41:dc:47:cb:c4:f5:0c:19:28:f7:82:e8:60:47:58:03:9f:
         9f:93:ec:9e:b4:34:c3:41:65:2b:41:f4:5d:25:1b:0f:37:79:
         bc:8f:3b:16:c2:34:23:42:f3:4c:58:f4:b1:8c:c7:12:30:ca:
         00:79:f4:b3:da:d9:16:37:8e:bf:9e:27:55:f1:26:7b:4d:aa:
         71:59:ce:cb:70:61:5d:3d:63:c8:71:03:2d:63:42:57:45:75:
         76:49:9e:d7:ee:5f:b1:4e:f9:9c:4a:ac:04:ce:98:c7:5a:0e:
         da:38:0d:29:41:81:e0:19:35:f2:43:20:90:c4:8b:a4:22:80:
         4e:59:72:5b:a9:95:40:3e:f3:7c:2a:06:ce:8d:3c:38:c6:16:
         3a:e8:42:43
0‚;0‚# zqèø¤rZœ¹W#ðÅlvª0
	*†H†÷
 0¬10	UUS10	UNY10UNew York10U
ACME Conglomerate Inc.10	UHQ1$0"Uacmeconglomerate.com1)0'	*†H†÷
	admin@acmeconglomerate.com0
190814184415Z
200813184415Z0¬10	UUS10	UNY10UNew York10U
ACME Conglomerate Inc.10	UHQ1$0"Uacmeconglomerate.com1)0'	*†H†÷
	admin@acmeconglomerate.com0‚"0
	*†H†÷
 ‚ 0‚
‚ ÝIYÒCƒ†Èøkï¦[ÉÓƒ®ÙQb³Ý˜r(‚䢮³4{ñß|:žjC¥ü«ï4µò2EugÖìUQOÿæ_à;¢Íi¬…*3órÈ@ħo…ÉT­W¬¾ÆE"¶ $Z·äu€¥6±¨j‡œ
 œ^zӏ'²ÎFÊTŽŠ¨šŸ:ËLÙÌÞ¨	Ù@-P½ßCÒÕHO©›ÂèIe~î)ó¼Eåe	<*z…†Ä* ιª"ÈUMűï_Ú Ú£ÃúÛl!M„ÀèU|GÀ¹–0…[P˜ÓîþÙ@~‹pgš#¨†6†nC £S0Q0U!™ÊÙáEÄdBèƒQ¦÷Ú£ûß0U#0€!™ÊÙáEÄdBèƒQ¦÷Ú£ûß0Uÿ0ÿ0
	*†H†÷
 ‚ Á·p³Yœó˜ùµ%;	:ðÎqŸßü¯t#x¬ø…øtméXÏø”åâ_\øÈm4Ù™ã\uë3
°œwÄŽ‹5Â,jÕ„P\Cõ4ÜR#æ#©
Ûs†ßJF<[ISÛ‹Ôh 9ï³Eð-›sëAÜGËÄõ(÷‚è`GXŸŸ“ìž´4ÃAe+Aô]%7y¼;Â4#BóLXô±ŒÇ0Ê yô³ÚÙ7Ž¿ž'Uñ&{MªqYÎËpa]=cÈq-cBWEuvIž×î_±NùœJ¬Î˜ÇZÚ8
)Aà5òC Ä‹¤"€NYr[©•@>ó|*΍<8Æ:èBC

So I am guessing this is success for my catalog in DER format.

Kobi,

By "vendor specific catalog" you mean the file "certificate.der" I created above, correct?

Then using Uniflash are the files for image creation loaded like this:

Where the "source File is the private key in the out.key file?
And where the Signature Source File is the self signed certificate.der?

And what if anything do I put in the box below Add OTP file?

Hi,

Do you want to use self signed certificate for code signing in production mode? In this case you should follow http://www.ti.com/lit/pdf/swru547. But as Kobi said I highly recommanded to use code signing certificate from supported CA (for example I use DigiCert). Usage of Vendor Device Authentication is pretty limiting because it need to be used Uniflash to uploading vendor certificate catalog into OTP memory. And cannot be used Embedded programming/gang programming only.

Jan

Oops looks like the command should have been with out the "-text" option. Try again

openssl x509 -inform PEM -outform DER -in certificate.pem -out certificate2.der

I will deleted the version of the file with text and rename the second file back to: certificate.der

Hello Jan,

Regarding, "Do you want to use self signed certificate for code signing in production mode? In this case you should follow http://www.ti.com/lit/pdf/swru547. "
We will go with self signed.  I have explained to our management / product marketing that our use of insecure WiFi and sockets makes the product vulnerable to easy MIM attacks and that therefor our product should never be used where personal or equipment safety is required. I await their requirements change.

Regarding, "...pretty limiting because it need to be used Uniflash to uploading vendor certificate catalog into OTP memory. And cannot be used Embedded programming/gang programming only."
Our estimated annual production is about 300 units so we have a cycle time of 2080/300 or 6.9 hours per unit to program.

Thanks,

Hi,

From my point of view is much easier to buy certificate from CA (e.g. DigiCert code signing for $474) than have complication with self signed certficate and uploading into OTA part of serial flash. Usage of certificate from CA is much easier, but choice is yours.

Jan

Hello Kobi,

Sorry for taking so long to work on this. I sure wish I could have focused only on this task to completion.

Regarding,

"1. you will need to create the another key pair (i.e. private key and self signed certificate). I'll refer to it those "catalog key pair" as opposed to the "code-signing key pair.  "

At first I though this what some sources I have read might be calling an intermediate authority aka, IA?  but the IA is not making a self signed certificate. It is only the root that self signs.

Perhaps it is the other way around.

Kobie,

Regarding, "4. store the "catalog public key" on the flash in one-time-programming (OTP) section."

This is very helpful. I was very confused about which key this would be, the private or public.

It will be like this:

I think the root of my confusion is that (IIRC) the MCU image is signed by Uniflash with the private key and that had me thinking the private key was in OTP and that for generating key pairs (certificate signing requests)  for SSL TLS the private key was programed into OTP too.

Sorry if this is painful for you, I am struggling against mistaken understanding and no consistency in file naming conventions in the many OpenSSL resources I have been reading and watching on Youtube.

Thanks,

Kobi,

Let me restate.

2 key pairs:  ONE and TWO

1. Private key ONE will sign your MCU image and secure files. The certificate (public key ONE) should be included in the catalog and the certificate needs to be stored as user file in the File System.

2. Private key TWO will sign the catalog. The public key TWO will be stored in the OTP sector.

After a three day weekend I am not sure if this is a sensible question, but would key ONE be described as an intermediate authority and key TWO a root authority or would such vocabulary be not applicable?

Thanks