PROCESSOR-SDK-AM69: Security AM69 Device Development

Hi Dariusz,

Dariusz Gasiorowski said:

Note:
openssl genpkey -algorithm RSA -out keys/dev.key \ -pkeyopt rsa_keygen_bits:4096 -pkeyopt rsa_keygen_pubexp:65537 $ openssl req -batch -new -x509 -key keys/dev.key -out keys/dev.crt

These are the command used to generate the new set of keys using openssl  if the customer don't want use TI Dummy keys.

Dariusz Gasiorowski said:

I assume that dev.key should be moved and renamed to binman build process into board/ti/key/custMpk.pem?

Correct they key custMpk.pem is the TI dummy keys used to sigen the image if the customer want to use their key they can replace it with their keys.

Dariusz Gasiorowski said:

And where a dev.cert is realy used (looks like for Keywriter operation) (seems not for binman build)?

It just a way of showing how you can generate the signed certificate using the newly generated key.

Dariusz Gasiorowski said:

But based on the old paper https://www.ti.com/lit/an/sprad04/sprad04.pdf?ts=1701160982790&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FTDA4VH-Q1
the gen_keywr_cert.sh -g should be use for new key generation, internally based also on openssl however in different manner. In this process, I guess,
that smpk.pem should be use as custMpk.pem ?

Smpk.pem is same as of custMpk.pem , eventually gen_kewr_cert.sh will make use of openssl command to generate the keys.

Dariusz Gasiorowski said:

Seems like this second described process is better and should be use due to using many other keys like: aes256.key bmek.key bmpk.pem smek.key smpk.pem tifekpub.pem ?
Also seem like the dev.crt (from previous Note) do not contain the same information as x509cert/final_certificate.bin from gen_keywr_cert.sh -s keys/smpk.pem --smek keys/smek.key -t keys/tifekpub.pem -a keys/aes256.key

If you are using keywriiter suggestion would be to use the script mentioned in the PDK . the linux sdk just shows how you can generate the keys but we already incorporated these commands in the shell script ( gen_keywr_cert.sh ) present in the PDK so that it will reduce efforts.

Dariusz Gasiorowski said:

Also seem like the dev.crt (from previous Note) do not contain the same information as x509cert/final_certificate.bin from gen_keywr_cert.sh -s keys/smpk.pem --smek keys/smek.key -t keys/tifekpub.pem -a keys/aes256.key

As i mentioned dev.crt is just way of showing how to generate the certificate using the newly genrated key it is diffrent from the certificate used in the keywritter.

In the above command we are generating the certificate to burn the SMPK/SMEK into the efuses.

Dariusz Gasiorowski said:

My question is how the new key generation process (described at the beginning in Note) is related to the transition HS_FS to HS-SE via Keywriter ?

The above steps just show that if the customer want to generate their own keys how they can do it. better to follow the app note  https://www.ti.com/lit/an/sprad04/sprad04.pdf?ts=1701160982790&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FTDA4VH-Q1

as it contain all the needed script ,so no need to worry about generating the individual keys (aess/smpk,smek...) if you want to flash your own keys.

The app note is well aligned with the process  of converting HS-FS device to HS-SE using keywriter tool.

Dariusz Gasiorowski said:

Could you please provide actual set by step description for entire process for new keys usages for image signing, encryption and the transition to HS-SE for SK-AM69-EVM and SDKv9 SPL-Uboot ?

What ever they private keys you are using/generated during the process of converting the HS-FS sample to the HS-SE, use the same key for signing the images.

Please refer to the TISCI document on the signing process:

https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/secure_boot_signing.html

How image get authentricated by the sysfw.

https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/authentication.html

Dariusz Gasiorowski said:

Bay the way do you have support for separate binman secure signing/encryption process from the make SDK uboot build process ?

Can you elaborate more on this?

Regards
Diwakar

Hi Diwakar,

Thank you for the detailed answers. Now is very clear. I want to ask also about the current binman process SDK v9. Using smpk.pem as custMpk.pem signing is prepared by binman, what about potential/optional backup signing via bmpk.pem - is it  supported now by binman ? How looks this operation (seems like images should be singed by both keys first by SMPK an then by BMPK - how this is related to current binman process and the keywriter or other method to  activate BMPK support (Key Revision and Key Count control) ?). 

And next, how looks the encryption support in context current binman process ? - there is no default sample keys/custMek.pem (smek.pem from key generation script).

Regarding binman clear separation (compilation/linking vs FIT image preparation and singing/encryption by binman) - I made such separation but maybe TI provide such option to make more cleaner separation, specially for  signing/encryption context and that is may question.

Details based on the uboot/binman doc:

'While binman is invoked from within the U-Boot build system([DG]: this is supported by TI), it is also possible to invoke it separately. This is typically used in a production build system, where signing is completed (with real keys) and any missing binaries are provided.

So in practice binman is often used twice:

• once within the U-Boot build system, for development and testing

• again outside U-Boot to assembly and final production images

While the same input binaries are used in each case, you will of course you will need to create your own binman command line, similar to that in cmd_binman in the Makefile. You may find the -I and –toolpath options useful. The device tree file is provided to binman in binary form, so there is no need to have access to the original .dts sources."

Regards,

Dariusz Gasiorowski

Hi Diwakar,

Thank you for your help and explanation. This shows that signing by bmp.pem  should be done without pre-signing by previous smpk.pem (in contrast as simply suggest the picture on https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/key_writer.html#sysfw-pub-keywr-cert-format - but this is for keywriter cert preparation, I see also that this was explained some time ago on this forum - Thanks again).

Regarding encryption possibility in binman process, based on the https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/secure_boot_signing.html  : ".. binary needs to be encrypted first and used as an input to the signing process described above. Some of the values populated in X509 extensions are also modified."

Looks like this is a sequential process: encryption-> signing, so seems, like is not just replace internal openssl request singing to encryption but should be prepared both operations and maybe something more actions...?

Kind regards,

Dariusz Gasiorowski