SK-AM69: Keywriter Error validating BMPK key

Hi,

One more, I see in the first case cert's sizes are:

1701 secondary_cert.bin
5407 primary_cert.bin 

In doc I see that:

• OTP keywriter firmware supports a maximum certificate length of 5400 bytes.
• This length is for individual certificates, and not the x509cert/final_certificate.bin. Check size of primary_cert.bin and seconday_cert.bin (optional depending on BMPK). If certificate length exceeds the supported limit, the keys can be programmed using incremental approach.

I don't want to write any additional custom data in extended OTP.

I'am not sure if this is a cause of my issue with bmpk validation by SoC.

Also I don't known why this size is bigger that limit 5400 while in case of last transition for smpk, smek the size of primary_cert.bin is 4031 ?

And finally if potentially is not possible to run special version of  HS_SE-keywriter again, how I can change the KEYREV to 2 for bmpk usage instead smpk ?

BR,

Dariusz Gasiorowski

Hi Dariusz,

You are probably missing some step somewhere, everything doesn't look alright.

Your log from M4 doesn't look right. It should have lot more text output. Please see an example OTP KeyWriter log.

I suspect that you used a regular TIFS binary instead of a KeyWriter binary while generating your keywriter image.

Dariusz Gasiorowski said:

-----------------------
SoC ID Header Info:
-----------------------
NumBlocks : 2
-----------------------
SoC ID Public ROM Info:
-----------------------
SubBlockId : 1
SubBlockSize : 26
DeviceName : j7aep
DeviceType : HSFS
DMSC ROM Version : [0, 1, 8, 0]
R5 ROM Version : [0, 1, 8, 0]

The device still stayed as HS-FS, if this is indeed your output of the successful run from the new certificate where you thought you programmed the SMPK and SMEK. So, even this doesn't look right.

Dariusz Gasiorowski said:

However I discover that for this keywriter cert was used k3_dev_mpk.pem copied by /generate_test_binaries.sh which I unfortunately not remove.

This is our TI Dummy Key, which is what all the provided HS-SE signed images work with. This is a safer key to play with for conversion of your initial board, rather than a totally random generated key (if you do that everytime you convert a new board, you would have to store those keys for you to sign application images to boot on those boards). So, I recommend the known dummy key above over a random key during your initial KeyWriter testing.

Dariusz Gasiorowski said:

There are some binaries eg.  tifs-hs-enc.bin or tifs-hs-fs-enc.bin in this folder but I am tnot sure if are correct for keywriter..

ti-processor-sdk-rtos-j784s4-evm-09_01_00_06/pdk_j784s4_09_01_00_22/packages/ti/drv/sciclient/soc/V6/

These are regular TIFS binaries to run on HS-FS or HS-SE TI Dummy Key devices, and are not applicable for KeyWriter at all.  

Dariusz Gasiorowski said:

- is it possible to check on PC/linux the generated keys before to get similar output as return SoC ?

I am not sure what you are asking here. Are you asking for a emulated run? If so, there is no such support. The commands do generate the verify_hash.csv file that stores the values expected.

Dariusz Gasiorowski said:

- or is it possible use SoC to run keywriter to check all validation but not make the final transition eg.:maybe by disabling  OTP_VppEn() or not use the --keycnt 2 --keycnt-wp --keyrev 1 during keywriter cert generation (I'am not sure about default setting in case lack of this switches ) ?

Yes, I do recommend this though you can't read the programmed keys directly from the device afterwards. You have to rely on the M4 log here.

I recommend that you use the first test binary to begin with that programs a harmless MSV efuse to ensure that your process is ok before generating more complex keywriter images.

Dariusz Gasiorowski said:

And finally if potentially is not possible to run special version of  HS_SE-keywriter again, how I can change the KEYREV to 2 for bmpk usage instead smpk ?

There is no HS-SE KeyWriter. Once the device is converted once to HS-SE, you cannot run KeyWriter again. SMPK and BMPK has to be programmed before you program the keycnt and keyrev efuses.

regards

Suman

regards

Suman

Hi Suman,

Thank you for your input. I made mistake during paste of the uart boot mode log which you pointed. That was version before transition and  this shows HSFS. Sorry for this mistake.

The correct after success transition is:

-----------------------
SoC ID Header Info:
-----------------------
NumBlocks : 2
-----------------------
SoC ID Public ROM Info:
-----------------------
SubBlockId : 1
SubBlockSize : 26
DeviceName : j7aep
DeviceType : HSSE
DMSC ROM Version : [0, 1, 8, 0]
R5 ROM Version : [0, 1, 8, 0]
-----------------------
SoC ID Secure ROM Info:
-----------------------
Sec SubBlockId : 2
Sec SubBlockSize : 166
Sec Prime : 0
Sec Key Revision : 1
Sec Key Count : 1
Sec TI MPK Hash : 2b28ecde967b79d61619f89cf299205c36d179cacb2b1c5a7f16e3169cc879602122d07ad47ae878a46e243c6f5078c04a5452faceeccb00d0453a5a5e6420da
Sec Cust MPK Hash : 1f6002b07cd9b0b7c47d9ca8d1aae57b8e8784a12f636b2b760d7d98a18f189760dfd0f23e2b0cb10ec7edc7c6edac3d9bdfefe0eddc3fff7fe9ad875195527d
Sec Unique ID : fd7b7761f98bac1f4138ce3e043d673af1b72646c85d8f5151565acfb41cdedb

and M4 core during keywriter success operation:

* SMPKH, SMEK:
Programmed 11/11 rows successfully
Programmed 2/2 rows successfully
Programmed 11/11 rows successfully
Programmed 2/2 rows successfully
Programmed 11/11 rows successfully
Programmed 2/2 rows successfully

* KEYCNT:
[u32] keycnt: 0x0
Programmed 2/2 rows successfully
[u32] keycnt: 0x1

* KEYREV:
[u32] keyrev: 0x0
Programmed 2/2 rows successfully
[u32] keyrev: 0x1

And hash confirm that k3_dev_mpk.pem  was used by keywriter. This also confirm my previous note that I use correct TIFS: 

- ti-fs-keywriter.bin  and ti_fek_public.pem was copy from OTP_KEYWRITER_ADD_ON_j784s4_08_06_00_14\addon\ 

Booting  SPL-Uboot signed by this TI key also works: "Authentication passed". And next u-boot.img Signed by other key not pass validation  as expected eg:

Trying to boot from MMC2
ti_sci system-controller@44083000: Message not acknowledgedAuthentication failed !
### ERROR ### Please RESET the board ###

So, still in this context I don't known what is a missing step. I suppose that the issue can with bigger size of primary cert as I described in the second post.

Based on these correct logs how can I test it regarding MSV:

"I recommend that you use the first test binary to begin with that programs a harmless MSV efuse to ensure that your process is ok before generating more complex keywriter images."

And regrading:

"There is no HS-SE KeyWriter. Once the device is converted once to HS-SE, you cannot run KeyWriter again. SMPK and BMPK has to be programmed before you program the keycnt and keyrev efuses."

So, for /gen_keywr_cert.sh -t keys/ti_fek_public.pem -a keys/aes256.key --smpk keys/smpk.pem  --smek keys/smek.key  --bmpk keys/bmpk.pem  --bmek keys/bmek.key --keycnt 2 --keycnt-wp --keyrev 1

That smp.pem is active key, but I want to switch to bmp how can I change the keyrev to 2 ? Via run time application is there sample code ?

BR,

Dariusz Gasiorowski

Hi Dariusz,

Dariusz Gasiorowski said:

Sec TI MPK Hash : 2b28ecde967b79d61619f89cf299205c36d179cacb2b1c5a7f16e3169cc879602122d07ad47ae878a46e243c6f5078c04a5452faceeccb00d0453a5a5e6420da
Sec Cust MPK Hash : 1f6002b07cd9b0b7c47d9ca8d1aae57b8e8784a12f636b2b760d7d98a18f189760dfd0f23e2b0cb10ec7edc7c6edac3d9bdfefe0eddc3fff7fe9ad875195527d
Sec Unique ID : fd7b7761f98bac1f4138ce3e043d673af1b72646c85d8f5151565acfb41cdedb

Ok, your new log looks good. The device is converted to HS-SE, and the Sec Cust MPK Hash indeed reflects the TI Dummy Key.

Dariusz Gasiorowski said:

And hash confirm that k3_dev_mpk.pem  was used by keywriter. This also confirm my previous note that I use correct TIFS: 

Indeed.

Dariusz Gasiorowski said:

I suppose that the issue can with bigger size of primary cert as I described in the second post.

I suppose so. We have a default keywriter image that does everything, and I don't recall the certificate size being larger. I need to double-check on this again.

Dariusz Gasiorowski said:

Based on these correct logs how can I test it regarding MSV:

"I recommend that you use the first test binary to begin with that programs a harmless MSV efuse to ensure that your process is ok before generating more complex keywriter images."

Not any more on this successfully converted sample. You would have to try this on a new HS-FS board.

Dariusz Gasiorowski said:

That smp.pem is active key, but I want to switch to bmp how can I change the keyrev to 2 ? Via run time application is there sample code ?

Yes, this has to be runtime using a TI-SCI call. Please also note that this requires the VPP EFuse to be enabled (requires regulator driver support).

We do not have any such reference or example code.

regards

Suman

Thanks Suman for your support. 

I am very curious to double check of keywriter cer generation it depend of the  number key passed to ./gen_keywr_cert.sh.

Eg:

~/ti-processor-sdk-rtos-j784s4-evm-09_01_00_06/pdk_j784s4_09_01_00_22/packages/ti/boot/keywriter/scripts$ ./gen_keywr_cert.sh -g
# Generating dummy keys in keys/ folder

~/ti-processor-sdk-rtos-j784s4-evm-09_01_00_06/pdk_j784s4_09_01_00_22/packages/ti/boot/keywriter/scripts$ ./gen_keywr_cert.sh -t keys/ti_fek_public.pem -a keys/aes256.key --smpk keys/smpk.pem --smek keys/smek.key --bmpk keys/bmpk.pem --bmek keys/bmek.key --keycnt 2 --keycnt-wp --keyrev 1
# Using Key Count: 0x00000003
# Using Key Rev: 0x00000001
Generating Dual signed certificate!!
# encrypt aes256 key with tifek public part
# encrypt SMPK-priv signed aes256 key(hash) with tifek public part
# encrypt smpk-pub hash using aes256 key
writing RSA key
# encrypt smek (sym key) using aes256 key
# encrypt BMPK-priv signed aes256 key(hash) with tifek public part
# encrypt bmpk-pub hash using aes256 key
writing RSA key
# encrypt bmek (sym key) using aes256 key
1701 secondary_cert.bin
5413 primary_cert.bin
7114 ../x509cert/final_certificate.bin
# SHA512 Hashes of keys are stored in verify_hash.csv for reference..

~/ti-processor-sdk-rtos-j784s4-evm-09_01_00_06/pdk_j784s4_09_01_00_22/packages/ti/boot/keywriter/scripts$ ./gen_keywr_cert.sh -t keys/ti_fek_public.pem -a keys/aes256.key --smpk keys/smpk.pem -s-wp --smek keys/smek.key --smek-wp --bmpk keys/bmpk.pem -b-wp --bmek keys/bmek.key --bmek-wp --keycnt 2 --keycnt-wp --keyrev 1
# Using Key Count: 0x00000003
# Using Key Rev: 0x00000001
Generating Dual signed certificate!!
# encrypt aes256 key with tifek public part
# encrypt SMPK-priv signed aes256 key(hash) with tifek public part
# encrypt smpk-pub hash using aes256 key
writing RSA key
# encrypt smek (sym key) using aes256 key
# encrypt BMPK-priv signed aes256 key(hash) with tifek public part
# encrypt bmpk-pub hash using aes256 key
writing RSA key
# encrypt bmek (sym key) using aes256 key
1701 secondary_cert.bin
5407 primary_cert.bin
7108 ../x509cert/final_certificate.bin
# SHA512 Hashes of keys are stored in verify_hash.csv for reference..

~/ti-processor-sdk-rtos-j784s4-evm-09_01_00_06/pdk_j784s4_09_01_00_22/packages/ti/boot/keywriter/scripts$ ./gen_keywr_cert.sh -t keys/ti_fek_public.pem -a keys/aes256.key --smpk keys/smpk.pem -s-wp --smek keys/smek.key --smek-wp --keycnt 1 --keycnt-wp --keyrev 1
# Using Key Count: 0x00000001
# Using Key Rev: 0x00000001
Generating Single signed certificate!!
# encrypt aes256 key with tifek public part
# encrypt SMPK-priv signed aes256 key(hash) with tifek public part
# encrypt smpk-pub hash using aes256 key
writing RSA key
# encrypt smek (sym key) using aes256 key
4027 primary_cert.bin
4027 ../x509cert/final_certificate.bin
# SHA512 Hashes of keys are stored in verify_hash.csv for reference..

Looks like only using smpk and smek size of primary_cert.bin is less that 5400....

And again what really means the write protection used for smp,smek, etc in context OTP and one transition HS-FS to HS-SE pass by the keywrtiter ?

BR,

Dariusz Gasiorowski

Hi Dariusz,

Dariusz Gasiorowski said:

I am very curious to double check of keywriter cer generation it depend of the  number key passed to ./gen_keywr_cert.sh.

Correct, the certificate generation does depend on the parameters you invoke with, as it changes the certificate configuration text it generates from the template. You can look through the contents of prim_cert_config.txt and sec_cert_config.txt that are generated in the configs file.

These form the input config files for the  certificate creation command. 

Dariusz Gasiorowski said:

Looks like only using smpk and smek size of primary_cert.bin is less that 5400....

Hmm, the same commands above generates the certificates within the bounds for me on my Ubuntu machine. What Ubuntu version are you on?

suman@Irmo:/nhome/sdk/ti-processor-sdk-rtos-j784s4-evm-09_01_00_06/pdk_j784s4_09_01_00_22/packages/ti/boot/keywriter/scripts$ ./gen_keywr_cert.sh -t keys/ti_fek_public.pem -a keys/aes256.key --smpk keys/smpk.pem -s-wp --smek keys/smek.key --smek-wp --bmpk keys/bmpk.pem -b-wp --bmek keys/bmek.key --bmek-wp --keycnt 2 --keycnt-wp --keyrev 1
# Using Key Count: 0x00000003
# Using Key Rev: 0x00000001
Generating Dual signed certificate!!
# encrypt aes256 key with tifek public part
# encrypt SMPK-priv signed aes256 key(hash) with tifek public part
# encrypt smpk-pub hash using aes256 key
writing RSA key
# encrypt smek (sym key) using aes256 key
# encrypt BMPK-priv signed aes256 key(hash) with tifek public part
# encrypt bmpk-pub hash using aes256 key
writing RSA key
# encrypt bmek (sym key) using aes256 key
1668    secondary_cert.bin
5376    primary_cert.bin
7044    ../x509cert/final_certificate.bin
# SHA512 Hashes of keys are stored in verify_hash.csv for reference..
suman@Irmo:/nhome/sdk/ti-processor-sdk-rtos-j784s4-evm-09_01_00_06/pdk_j784s4_09_01_00_22/packages/ti/boot/keywriter/scripts$
suman@Irmo:/nhome/sdk/ti-processor-sdk-rtos-j784s4-evm-09_01_00_06/pdk_j784s4_09_01_00_22/packages/ti/boot/keywriter/scripts$ ./gen_keywr_cert.sh -t keys/ti_fek_public.pem -a keys/aes256.key --smpk keys/smpk.pem -s-wp --smek keys/smek.key --smek-wp --keycnt 1 --keycnt-wp --keyrev 1
# Using Key Count: 0x00000001
# Using Key Rev: 0x00000001
Generating Single signed certificate!!
# encrypt aes256 key with tifek public part
# encrypt SMPK-priv signed aes256 key(hash) with tifek public part
# encrypt smpk-pub hash using aes256 key
writing RSA key
# encrypt smek (sym key) using aes256 key
3996    primary_cert.bin
3996    ../x509cert/final_certificate.bin
# SHA512 Hashes of keys are stored in verify_hash.csv for reference..
suman@Irmo:/nhome/sdk/ti-processor-sdk-rtos-j784s4-evm-09_01_00_06/pdk_j784s4_09_01_00_22/packages/ti/boot/keywriter/scripts$

Dariusz Gasiorowski said:

And again what really means the write protection used for smp,smek, etc in context OTP and one transition HS-FS to HS-SE pass by the keywrtiter ?

write-protection also enforced read-protection, and these do hinder the reading of the hash keys even from the TIFS firmware. You can never over-write the keys once a device is converted to HS-SE. 

On a multiple-pass option, it does allow you to override the SMPKH when you don't finalize the conversion. Until the conversion is complete, you don't see the proper hash in the UART parser output.

regards

Suman

Hi Suman,

Thank you very much for double check.

I use   Ubuntu 23.04 on the windows WSL2.

I also want to note that maybe important can be openssl version. Currently I use 

OpenSSL 3.0.8 7 Feb 2023

And original gen_keywr_cert_helpers.sh show openssl error about deprecated 'rsault' command. To fix this I use recommended pkeyutl command as below:

 The Openssl error log will show: "The command rsautl was deprecated in version 3.0. Use 'pkeyutl' instead."

  then I fix  packages\ti\boot\keywriter\scripts\gen_keywr_cert_helpers.sh eg only in this 222 line ( the raw_encrypt was not called  and probably require more changes due to switch parameters  changes in pkeyutl):

# encrypt <PUBLIC-KEY.PEM> <DATA> <ENCRYPTED-OUTPUT>
encrypt(){
    # openssl rsautl -encrypt -inkey "$1" -pubin -in "$2" -out "$3"
    openssl pkeyutl -encrypt -inkey "$1" -pubin -in "$2" -out "$3"      222 line
}

What is your's Openssl  version ? And are you use such fix or maybe you have some newer version this script ?

Seems like prim_cert_config.txt is output file generated based on the config_template.txt (I use default version from this PDK 09_01_00_22). When inside this file I comment unused msv OJD then I get smaller size :

5377    primary_cert.bin

but I not test the next HS_FS to HS-SE transition  operation.

"write-protection also enforced read-protection, and these do hinder the reading of the hash keys even from the TIFS firmware". This is very important comment, so that means I should not use write protect  for keys when I want to get/read these Derived version of keys Hash (eg DSMPKH) inside application via TISCI request - right ?

BR,

Dariusz Gasiorowski

Hi Dariusz,

Dariusz Gasiorowski said:

I use   Ubuntu 23.04 on the windows WSL2.

I also want to note that maybe important can be openssl version. Currently I use 

OpenSSL 3.0.8 7 Feb 2023

This is the most likely difference.

My logs above are from a Ubuntu 18.04.6 System, and the OpenSSL version is older,

OpenSSL 1.1.1  11 Sep 2018.

The 9.x SDKs formally have moved to using Ubuntu 22.04, and I can get these numbers from a different machine I have.

Ubuntu 23.04 is definitely not used within TI, but I don't think the Ubuntu version matters, it would primarily be the OpenSSL version, as the certificate is generated using the standard openssl command.

Dariusz Gasiorowski said:

This is very important comment, so that means I should not use write protect  for keys when I want to get/read these Derived version of keys Hash (eg DSMPKH) inside application via TISCI request - right ?

There is no such thing as DSMPKH, only DKEK and from 9.x SDK onwards, the new DSMEK. DSMPKH is not needed given the assymetric nature of the SMPK.

I think this mostly should be fine AFAIK (DKEK works for sure). The protections are for reading the registers from the TIFS core itself, the derived key logic relies on the Crypto Accelerator which can read the keys in h/w (no s/w exposure).

regards

Suman

Hi Suman,

Yes, please provide the result from another machine especially for OpenSSL v3.xx. I expect similar results to mine.

So, I think the write protect for all stored keys can be used  as  more secure. And in this case,  still will  be possible to obtain e.g. DSMEK via TISCI request.

In TISCI doc there is only information about DKEK and DSMEK. What about DBMEK?

Is there also possibility to get DBMEK in case for example switching to backup as active key via keyrev = 2 for keycnt = 2   ? 

BR,

Dariusz Gasiorowski

Hi Dariusz,

Dariusz Gasiorowski said:

Yes, please provide the result from another machine especially for OpenSSL v3.xx. I expect similar results to mine.

Yes, will do. I hope to give you an update on either 02/08 or 02/09.

I don't have a Ubuntu 23.04, but only have a Ubuntu 22.04 (our recommended LTS). I am not sure if the OpenSSL version is the same on 22.04.

Dariusz Gasiorowski said:

So, I think the write protect for all stored keys can be used  as  more secure. And in this case,  still will  be possible to obtain e.g. DSMEK via TISCI request.

The API and interfaces for retrieving DSMEK look the same as DKEK, there will be an internal processing through the Crypto Accelerator, so I am expecting same behavior. Anyway, I will double-confirm with the development team for my next response.

Dariusz Gasiorowski said:

What about DBMEK?

Is there also possibility to get DBMEK in case for example switching to backup as active key via keyrev = 2 for keycnt = 2   ? 

I will confirm the behavior, whether this API applies to the active key or needs to be done separately. If latter, we definitely do not have a separate API/support.

regards

Suman

Hi Suman,

OK. Thanks. 

Additionally, Is it possible to compare some how the received DSMEK  values  with SMEKH or SMEK  to check that are really match ? Or generate on PC  via some special script the DSMEK based on the SMEK input ? 

BR,

Dariusz Gasiorowski

Hi Dariusz,

Dariusz Gasiorowski said:

Additionally, Is it possible to compare some how the received DSMEK  values  with SMEKH or SMEK  to check that are really match ? Or generate on PC  via some special script the DSMEK based on the SMEK input ? 

No, this is not possible. The SMEK is a symmetric key used for encryption and is expected to reside only on a HSM server.

regards

Suman

Hi Suman,

Any progress regarding promised double check for /gen_keywr_cert.sh on newest OpenSSL?

And in the meantime. I can't unlock Jtag on this HS-SE board even I add in cert for SPL-Uboot build in openssl.py below  debug unlock for

Hi Dariusz,

Dariusz Gasiorowski said:

And in the meantime. I can't unlock Jtag on this HS-SE board even I add in cert for SPL-Uboot build in openssl.py below  debug unlock for

Please file a separate ticket for this, this is unrelated to the current thread title.

regards

Suman

Hi Suman,

Thank you for test confirmation. Could you describe how the multi-pass looks like in this case?

As I wrote in one of the previous posts, deleting eg. msv from  template reduces the size of certs - which I think can also be a workaround  for one-pass keywriter for this dual signed certificate ?

BR,

Dariusz Gasiorowski

Hi Dariusz,

Dariusz Gasiorowski said:

deleting eg. msv from  template reduces the size of certs - which I think can also be a workaround  for one-pass keywriter for this dual signed certificate ?

The options are all what you choose for the certificate, so the certificate size limitations may or may not be a concern depending on all the options chosen. If you don't think MSV is needed for you, and skipping it brings the size below the max limit, then that should suffice for you.

Please note that the keyrev and keycnt efuses are the key. Programming these will turn the device from HS-FS to HS-SE, and you can no longer run the KeyWriter after that.  

The secondary certificate is not an issue, as it is well short of the ceritificate size limit.

regards

Suman