How is ENC_IMAGE_KEY derived from User Key on Secure Provisioning Tool?

[scott-kooy]

On RT685, I am trying to use "Encrypt + Signed" mode with multi-image in  elftosb.exe. I can generate small apps that are loaded into external ram (with mpi_loader image) and run fine.  But larger apps are giving me a problem.  When I debug, I inspect the OCRAM and find that my image is not fully decrypted by the bootloader.  I do not know why.  Perhaps elftosb is not encrypting it correctly.  Perhaps the bootloader is not decrypting correctly.    For now I am using the shadow registers.  I have not burned any OTP fuses.

I would like to know the correct algorithm for encrypting and decrypting so I can test that it was done correctly.  It says in the user manual:

42.2.3.2 ENC_IMAGE_KEY
• Key used to decrypt encrypted LoadToRam images during boot
• AES256(OTP_MASTER_KEY,
01000000_00000000_00000000_00000000_02000000_00000000_00000000_0000
0000)

Is OTP_MASTER_KEY the same as User Key on the Secure Provisioning Tool? And if so, what does 42.2.3.2 mean?  Does that mean perform AES256 algorithm with key=OTP_MASTER_KEY, data=01000000...., ECB mode?  If not, what does it mean?  I assume once I can derive the ENC_IMAGE_KEY, I can use that as the key, the encrypted image data, and CBC mode with the IV found in the encrypted image file to decrypt the image. Is this correct?

Here is the json file:

{
"family": "rt6xx",
"inputImageFile": "C:/nxp_files/extram_loader.bin",
"multicoreImages": [
{"address": "0x08000000", "file": "C:/nxp_files/RT685EVK.bin"}
],
"imageLinkAddress": "0x80000",
"outputImageExecutionTarget": "RAM",
"outputImageAuthenticationType": "Encrypted + Signed",
"enableTrustZone": false,
"trustZonePresetFile": "",
"enableHwUserModeKeys": false,
"imageBuildNumber": "1",
"rootCertificate0File": "C:/Users/A9DQSZZ/secure_provisioning0/crts/ROT1_sha256_2048_65537_v3_ca_crt.der",
"rootCertificate1File": "C:/Users/A9DQSZZ/secure_provisioning0/crts/ROT2_sha256_2048_65537_v3_ca_crt.der",
"rootCertificate2File": "C:/Users/A9DQSZZ/secure_provisioning0/crts/ROT3_sha256_2048_65537_v3_ca_crt.der",
"rootCertificate3File": "C:/Users/A9DQSZZ/secure_provisioning0/crts/ROT4_sha256_2048_65537_v3_ca_crt.der",
"mainCertChainId": 0,
"mainCertPrivateKeyFile": "C:/Users/A9DQSZZ/secure_provisioning0/keys/ROT1_sha256_2048_65537_v3_ca_key.pem",
"masterBootOutputFile": "C:/Users/A9DQSZZ/secure_provisioning0/bootable_images/extram_loader.bin",
"deviceKeySource": "OTP",
"useKeyStore": false,
"keyStoreFile": "",
"outputImageEncryptionKeyFile": "C:/Users/A9DQSZZ/secure_provisioning0/gen_sb/userkey.txt"
}

[scott-kooy · Accepted solution]

OK I was able to locate the source code for elftosb, so I figured out how to decrypt  myself.  It is a complicated process, but here it is in a nutshell:

1.  ENC_IMAGE_KEY is derived with two 16 byte AES256 ECB transactions: 

AES256-ECB(Key:UserKey (0:15) in Secure Provisioning Tool, Data: 01000000_00000000_00000000_00000000)

AES256-ECB(Key:UserKey (16:31) in Secure Provisioning Tool, Data: 02000000_00000000_00000000_00000000)

2. Copy the fully encrypted header to the first 56 bytes of the encrypted image.  To overwrite the unencrypted 0x20, 0x24, 0x28, and 0x34 vectors with encrypted values. 

3. Delete the HMAC header from the encrypted image (remove bytes 0x40-0x5F)

4. Decrypt the modified image with AES256-CTR with the IV found in the encrypted image after the encrypted header and the derived key.

I was able to do this and was able to decrypt the entire encrypted combined image.

[kerryzhou]

Hi @scott-kooy ,

   Thanks a lot for your conclusion, your learning is valuable.

  If you meet any issues in the future, welcome to create the case and let us know.

Best Regards,

Kerry