CC3220SF: Boot procedure, Secure boot and Encryption.

Hi Harish,

Uniflash will run a series of commands on the CC32xx to build and unpack the device filesystem on the external serial flash. As part of this process, the file table is built, and the files provided through Uniflash such as your application binary, the servicepack, other files such as certs are flashed. The files which are flagged as secured will be encrypted by the CC32xx, and a hash of the file will be computed and signed. Each file signature will be stored in the file table so that the CC32xx can determine file integrity and authenticity as needed.

The 20 byte hash appended to the application binary is a special step unique to the CC32xxSF variants, where the program code is copied to internal flash from external flash. The internal flash contents are hashed and compared by the bootloader against that 20 byte hash to ensure that its contents match the signed binary on the external flash.

The secure boot comes in where the file integrity of the binary is checked at every boot. So if the external flash contents have been corrupted or deliberately modified, the file signature will no longer match the contents on the flash. The bootloader will fail to boot the device image and return a security warning error. If too many security errors are accumulated, the device will lock itself so that brute force attacks cannot be performed.

The encryption of each file transferred through uniflash is actually handled through unique AES keys per file. As each encrypted file is loaded into memory, they are decrypted on the fly by the CC32xx AES hardware crypto modules. The unique AES keys are generated by the device on file creation, and stored in the file table. The file table itself is also encrypted and authenticated much like any other encrypted file, except that the encryption keys are derived from a unique 256bit hardware secret unique to each CC32xx device. As such, each file table will be encrypted and authenticated with a unique set of keys per device, preventing attacks where you simply transfer the full contents of serial flash to another CC32xx for decryption.

Let me know if you need more clarification on the secure boot implementation of the CC32xx or have further questions on the security enablers of the device.

Regards,

Michael

Hi Michael, 

Thanks for the quick response. somehow after referring through the documents I am confused. I request you to answer to my questions mentioned below that may clear my confusion. I request you to answer point by point marked in green color 

Uniflash will run a series of commands on the CC32xx to build and unpack the device filesystem on the external serial flash. As part of this process, the file table is built, and the files provided through Uniflash such as your application binary, the servicepack, other files such as certs are flashed. The files which are flagged as secured will be encrypted by the CC32xx, and a hash of the file will be computed and signed. Each file signature will be stored in the file table so that the CC32xx can determine file integrity and authenticity as needed.

From the above statement I understand that there is a file table associated with each flash and it also contains the signature and associated keys for decryption. Is my understanding correct?

The file will be first encrypted then hash will be computed, and the resultant Hash is signed? Is my understanding correct.

The 20 byte hash appended to the application binary is a special step unique to the CC32xxSF variants, where the program code is copied to internal flash from external flash. The internal flash contents are hashed and compared by the bootloader against that 20 byte hash to ensure that its contents match the signed binary on the external flash.

Ok, I understand these 20 bytes appended to the binary is used while copying the binary from external flash to internal flash to check the integrity. But before that to detect any changes in the external flash the SHA-1 Hash is used which was stored in "/sys/mcuflashimghash.bin". Is my understanding correct? please refer to the Figure 21-13 from the below document.

http://www.ti.com/lit/ug/swru465/swru465.pdf

The secure boot comes in where the file integrity of the binary is checked at every boot. So if the external flash contents have been corrupted or deliberately modified, the file signature will no longer match the contents on the flash. The bootloader will fail to boot the device image and return a security warning error. If too many security errors are accumulated, the device will lock itself so that brute force attacks cannot be performed.

From this I can understand that, signature of the binary is checked when there is a change detected on the external flash binary by comparing the SHA-1 hash. Is my understanding correct? On every boot the signature is not verified.

The signature is calculated after encryption or before?

Does Uniflash verify the signature when it is flashed, or the bootloader when the image is flashed using the Uniflash tool.

The encryption of each file transferred through uniflash is actually handled through unique AES keys per file. As each encrypted file is loaded into memory, they are decrypted on the fly by the CC32xx AES hardware crypto modules. The unique AES keys are generated by the device on file creation, and stored in the file table. The file table itself is also encrypted and authenticated much like any other encrypted file, except that the encryption keys are derived from a unique 256bit hardware secret unique to each CC32xx device. As such, each file table will be encrypted and authenticated with a unique set of keys per device, preventing attacks where you simply transfer the full contents of serial flash to another CC32xx for decryption.

I understand when a “Secure” option is selected in a file properties in Uniflash the files are encrypted, and what happens when we select option “Vendor” and give the File Token ? . Is this file token is the encryption/decryption KEY ? And the same is added in the file table?

 The boot loader will read the decryption key from file table and decrypt the binary file ?

OTA

We are using AWS OTA agent, what happens when the ota is downloaded? will it replace the file after signature verification and then reboot? 

it will be helpful if you can explain the procedure of OTA how this secure boot work 

Thanks,

Harish

Hi Harish,

My responses inline:

From the above statement I understand that there is a file table associated with each flash and it also contains the signature and associated keys for decryption. Is my understanding correct?

Yes

The file will be first encrypted then hash will be computed, and the resultant Hash is signed? Is my understanding correct.

The file is hashed and signed, then encrypted.

Ok, I understand these 20 bytes appended to the binary is used while copying the binary from external flash to internal flash to check the integrity. But before that to detect any changes in the external flash the SHA-1 Hash is used which was stored in "/sys/mcuflashimghash.bin". Is my understanding correct? please refer to the Figure 21-13 from the below document.

http://www.ti.com/lit/ug/swru465/swru465.pdf

That is correct

From this I can understand that, signature of the binary is checked when there is a change detected on the external flash binary by comparing the SHA-1 hash. Is my understanding correct? On every boot the signature is not verified.

The signature is checked every boot. The bootloader will check the contents of the internal flash on every boot, to ensure that it matches the recorded hash. The hash saved on the serial flash is encrypted and signed itself, so effectively the internal flash will be checked against this signature on every boot.

The signature is calculated after encryption or before?

The SHA-1 hash is calculated before encryption, as the contents of the internal flash are not encrypted.

Does Uniflash verify the signature when it is flashed, or the bootloader when the image is flashed using the Uniflash tool.

 The bootloader performs all file encryption and signing. Uniflash only sends the UART bootloader commands and file data for the bootloader to work with. If you were to provide the incorrect file signature for a file, the bootloader is what returns the file write error for Uniflash to display.

I understand when a “Secure” option is selected in a file properties in Uniflash the files are encrypted, and what happens when we select option “Vendor” and give the File Token ? . Is this file token is the encryption/decryption KEY ? And the same is added in the file table?

The file token is not the encryption key of the file. It is an access key that allows you to control read/write/delete file accesses. Setting this to "Vendor" allows you to provide a known token so that your application can use the sl_Fs*() filesystem APIs to access your file. Without setting that flag, only the NWP will have access to those files.

 The boot loader will read the decryption key from file table and decrypt the binary file ?

Yes, the bootloader and the NWP core in general will be able to access the file table with the decryption keys for all files stored on as 'secure' on the filesystem.

OTA

We are using AWS OTA agent, what happens when the ota is downloaded? will it replace the file after signature verification and then reboot? 

I am not familiar with the AWS OTA method, but effectively what should happen assuming that the OTA works is that it will download the mcuflashimg.bin file, overwrite the old file with the newly downloaded copy. Then, on the next boot, the bootloader will see that the mcuflashimg.bin has changed, update the hash accordingly, and download the new mcuflashimg contents to the internal flash. From an application code perspective, there isn't anything that needs to be done other than download and overwrite the mcuflashimg. The bootloader will take care of the rest.

Regards,

Michael

Hi Michael,

Thanks for the answers and quick response. I really appreciate it, most of my questions are cleared. I have some more questions on this can you answer the below.

Question 1:

 The signature is checked every boot. The bootloader will check the contents of the internal flash on every boot, to ensure that it matches the recorded hash. The hash saved on the serial flash is encrypted and signed itself, so effectively the internal flash will be checked against this signature on every boot.

From the above statement the Hash you are referring is SHA -1 Hash calculated automatically when the image is transferred from the serial flash to on-chip flash. the same hash is also used to check any changes in the serial flash binary. Does the 20 bytes hash(appended to the binary) is included when the SHA -1 Hash is calculated from the external serial flash?

If yes, then the image on on-chip flash does not contain the 20 bytes hash? Then how will the Hash Mach happen?

Question 2:

 According to my understanding the bootloader will check for any new image on the serial flash, this is detected using SHA-1 Hash which was stored in "/sys/mcuflashimghash.bin". any change in the content of the serial flash the Hash will mismatch. That indicates either a new image or tamper attempt. In case of tamper attempt the On-Chip flash is mass erased. If it detects the new image it will copy the image to On-Chip flash

Now the question is how does boot loader differentiate between tamper attempt and new code, does it verify the signature before copying to the on-chip flash? After copying to on-chip flash it will verify the 20 bytes hash but before copying any checks are performed?. after copying the 20 bytes does not match the internal flash binary is already over written.

what if the 20 bytes Hash is also tampered to match ?

Question 3:

How the encryption and the signature will be handed during OTA? If I replace a secure binary flashed using Uniflash through and then call boot loader, how will boot loader will do encryption and update the file table?

Thanks,

Harish