Secure Boot on PIC32CM LS60 Curiosity Pro Evaluation Kit Using MPLAB® Harmony v3 Software Framework: Step 3

Now, both the Secure Bootloader and test application projects are created and the code is added. Let us test on target to see the results.

Step 3.1: Generate the PIC32CM LS60 User Row Configurations for the Test Application Project

1

Generate the test application's Unified Binary. A Unified Binary is a single executable file generated by MPLAB® X Integrated Development Environment (IDE) using the Secure and Non-Secure HEX files. This can be used to program both Secure and Non-Secure regions together.

Note: The pre-built test application HEX and unified binary are kept in the HEX folder.

  • You can ignore the following steps if you have not modified the test application project.
  • Open and build the test application's Non-Secure project in the MPLAB X IDE, i.e.,
<Your_Secure_Bootloader_Downloaded_Path>/pic32cm_ls60_cpro_secure_boot/firmware/test_app/NonSecure/firmware/pic32cm_ls60_cpro_NonSecure.X
  • This will also build the mandatory Secure project.

2

The Secure Bootloader project consists of the following scripts folder which has the following files. These files will be used to run the test application.

scripts folder path:
<Your_Secure_Bootloader_Downloaded_Path>/pic32cm_ls60_cpro_secure_boot/scripts

scripts folder files:

  • application_user_configurations_in.txt: This is the input file consisting of PIC32CM LS60 User Row Bitfield configurations for the test application.
  • application_user_configurations_out.txt: This is the output file that has the CRC information calculated using the Python® script for the given input file application_user_configurations_in.txt.
  • btl_dev_cfg_gen.py: Used to generate the device configuration
  • btl_host.py: Used to load the test application binary from Host-PC to the target device over UART
  • secure_bootloader_with_tpds.c: This is the device configuration file for the Secure Bootloader project.
  • secure_bootloader_with_tpds_and_application.c: This is the device configuration file for the Secure Bootloader and test application project.

Step 3.1.1: Steps to Generate the PIC32CM LS60 User Row Configurations for the Test Application Project

The pre-generated application_user_configurations_out.txt configuration file will be used by the btl_host.py script to update the fuse configurations while programming the test application.

Note: The following steps show how the application_user_configurations_out.txt file was generated based on the device and project configurations. You can ignore the following steps if you have not modified the project configurations.

1

If modified then the input file application_user_configurations_in.txt needs to be generated based on the new device and project configuration and then passed to the btl_dev_cfg_gen.py script file to generate the output file application_user_configurations_out.txt.

2

The application_user_configurations_in.txt file consists of only the User Row Fuse configurations for the test application's Non-Secure application project i.e., app_pic32cm_ls60_cpro_NonSecure project and it is generated by looking at the applications device and project configurations.

3

To know how this file is generated, open the above app_pic32cm_ls60_cpro_NonSecure project in MCC and check the Device & Project Configuration under the System module. For example, the Memory Configurations of the test application can be seen in the accompanying image.

app_mem_cfg.png

4

For more information on application_user_configurations_in.txt generation, visit the "Bootloader Device Configuration Input" page.

5

Go to the
<Your_Secure_Bootloader_Downloaded_Path>/pic32cm_ls60_cpro_secure_boot/scripts folder and execute the following command to show the Help menu for the script.

python btl_dev_cfg_gen.py --help
script_help_01.png

6

The syntax for generating the device configuration output file is:

python btl_dev_cfg_gen.py -v -f <device_config_input_file.txt> -o <device_config_output_file.txt>

7

Now, to generate the CRC for the fuse settings, execute the following command:

python btl_dev_cfg_gen.py -v -f application_user_configurations_in.txt -o application_user_configurations_out.txt
script_help_02.png

8

The application_user_configurations_out.txt configuration file will be used later by the btl_host.py to update the fuse configurations while programming the test application using Secure Bootloader.

Step 3.2: Secure Boot Configuration | Provisioning | Secure Booting

Step 3.2.1: Secure Boot Provisioning

Steps to program and provision the Secure bootloader code using Mirochip's Trust Platform Design Suite (TPDS).

1

  • Perform the hardware setup steps mentioned in the lab objective, if not done already.
  • Open the TPDS application and select the TrustFlex use case, i.e., Secure Boot-PIC32CMLS60.
  • This use case will sign an application HEX file to support Secure Boot in combination with the ATECC608 embedded into the PIC32CM LS60.
  • The application that is to be signed must be generated as per the current datasheet for Secure Boot.
tpds_01.png

2

Generate a Private/Public key pair: Click on Option 1 to Generate a Private/Public key pair to perform the factory programming of the default binary and wait for the response OK.

Note: If you get an error response. Follow the below-mentioned step.

  • Press the reset button on the PIC32CM LS60 Curiosity Pro Evaluation Kit to sync with TPDS. Then jump to Step 3.

3

Again press Option 1 - Generate Private/Public key. In this step, the public key required to verify the SecureBoot is stored in Slot 15. This time a pop-up appears to Generate a Private/Public key, as shown in the accompanying image.

tpds_02.png

4

After successful execution of Option 1, a green tick mark appears in Option 1 as shown in the accompanying image, and check the log window for the message "Executed Step-1 Successfully".

tpds_03.png

5

Generate the IOPROT Key: The communication between the PIC32CM LS60 microcontroller and the ATECC608B is encrypted using an I/O Protection Key (IOPROTKEY). This unique key is initially provisioned in both the ATECC608B Slot 6 and the microcontroller BOCOR NVM Configuration Row (IOPROTKEY).

6

After the successful execution of Option 2, a green tick mark appears in Option 2 as shown in the accompanying image, and check the log window for the message "Executed Step-2 Successfully".

tpds_04.png

7

In this step, the digest and signature will be generated for the Secure Bootloader HEX file.

  • Copy the Secure Bootloader pic32cm_ls60_cpro_Secure.X.production.hex file from:
  • <Your_Secure_Bootloader_Project_Path>/secure_boot/hex/secure_bootloader to
  • <user_path>/.trustplatform/pic32cmls60_secure_boot
  • Load HEX file, calculate digest and signature: Select Option 3 to load the Secure Bootloader HEX file from the TPDS Trust platform folder i.e., <user_path>/.trustplatform/pic32cmls60_secure_boot to calculate the digest and signature.
tpds_05.png

8

After the successful execution of Option 3, a green tick mark appears in Option 3 as shown in the accompanying image, and check the log window for the message "Executed Step-3 Successfully".

tpds_06.png

9

Save new application HEX: Select Option 4 to save the new application HEX. i.e., the TPDS generates a new HEX file with the name signed HEX which has the digest and the Elliptic Curve Digital Signature Algorithm (ECDSA) signature stored at the end of the BOOT region Secure Bootloader HEX file.

10

After the successful execution of Option 4, a green tick mark appears in Option 4 as shown in the accompanying image, and check the log window for the message "Executed Step-4 Successfully".

tpds_07.png

11

Calculate digest, send encrypted digest, and verify the signature: Select Option 5 to program the signed HEX onto PIC32CM LS60 Curiosity Pro Evaluation Kit. In this step, the Host MCU calculates the SHA-256 digest and sends the encrypted digest and signatures to be verified through ECDSA. Then Secure Boot execution will authenticate the application code.

12

After the successful execution of Option 5, a green tick mark appears in Option 5 as shown in the accompanying image, and check the log window for the message "Executed Step-5 Successfully".

tpds_08.png

13

This completes the use case execution. i.e., the provisioning flow of PIC32CM LS60 MCU.

  • Reset or power cycle the device.

Step 3.2.2: Running the Secure Bootloader Application

1

The successful running of the Secure Bootloader is indicated by turning the green LED0 ON.

  • A green LED (LED0) on the PIC32CM LS60 Curiosity Pro Evaluation Kit turns ON when the Secure Bootloader is running.
    • Open MPLAB X IDE and you can check the Configuration Bits by going to Window > Target Memory Views > Configuration Bits in the MPLAB X IDE
    • The Secure Bootloader fuse configuration bits are stored in the secure_bootloader_with_tpds.c file.
      • Here, you can see that the BOOTROM_BOOTOPT value is set to 0x5, which enables the Secure Boot.
      • Also, check the BOOTKEY which is set by the user, and IOPROTKEY which is stored by the TPDS.

2

Receive the test application image over UART from a PC by running a Python script. The successful receiving of the test application is indicated by toggling the red LED.

  • Open the Virtual Debug COM port and set the baud rate to 115200.
  • Connect the Type-A male to Mini-B USB cable to Mini-B USB-UART Click on board to receive the test application firmware from the Host-PC.
    • Note: Install USB-UART serial driver if not installed on your PC.
  • Go to the following Secure Bootloader scripts folder path, and open the command prompt to run the bootloader host script btl_host.py.

scripts folder path:
<Your_Secure_Bootloader_Downloaded_Path>/pic32cm_ls60_cpro_secure_boot/scripts

  • Execute the following command to show the help menu for the btl_host.py script.
python btl_host.py --help
script_help.png
  • Copy pic32cm_ls60_cpro_NonSecure.X.production.unified.bin from C:/secure_boot/hex/test_app to <Your_Secure_Bootloader_Downloaded_Path>/pic32cm_ls60_cpro_secure_boot/scripts
  • The following command sends the test application's Unified binary from Host-PC to the PIC32CM LS60 Curiosity Pro Evaluation Kit and updates the User Row fuse configurations bits.
    • Note: Replace the COM port number with the USB-UART Serial COM port which is enumerated when you connect the Type-A male to Mini-B USB cable to Mini-B USB-UART Click on board.
python btl_host.py -v -u even -i COM27 -d PIC32CM -a 0x1000 -f pic32cm_ls60_cpro_NonSecure.X.production.unified.bin -c application_user_configurations_out.txt
  • See the following output on the command prompt.
program_application_01.png
  • Observe the LED1 (Red-LED) blinking while receiving the test application.
  • After receiving the test application's unified binary and update of device configuration bits, remove the Mini-USB from the USB-UART Click board and reset the device.

3

Red LED1 starts toggling indicating Secure and successful test application booting.

  • Now the LED1 (Red-LED) toggles and prints a message in the Virtual COM as shown in the accompanying image, indicating the test application is loaded from the Secure Bootloader.
app_log_01.png
  • Press and hold the Switch SW0 key to trigger the Secure Bootloader to program the test application once again or with the new application.
app_log_02.png
  • Notice that the green LED0 turns ON when the Secure Bootloader is triggered.
    • Now open MPLAB X IDE and check the Device Fuse Configuration Bits after programming the test application. Go to Window > Target Memory Views > Configuration Bits in the MPLAB X IDE. The configuration bits are saved in the secure_bootloader_with_tpds.c file.
    • In this file, notice that only User Row configurations (i.e., USER WORD) are updated based on the Test Application's configuration, whereas the Boot Configuration Row (i.e., BOCOR WORD) is not modified.
    • You can check the diff of the secure_bootloader_with_tpds.c and secure_bootloader_with_tpds_and_application.c present in the scripts folder to see which user configuration bitfields are updated by the Bootloader script based on the application's project configuration.

Step 3.3: Impersonating Bootloader

  1. Open the Secure Bootloader project in the MPLAB X IDE and build the project. Once the build process is complete, the pic32cm_ls60_cpro_Secure.X.production.hex file will be generated in the path where you have created the Secure Bootloader project path. i.e., <Your_Secure_Bootloader_Project_Path>/secure_boot/hex/secure_bootloader.
  2. Program the pic32cm_ls60_cpro_Secure.X.production.hex file using MPLAB X IDE.
  3. Since the Secure Bootloader image does not have the signature appended at the end of the Bootloader image when Flashing using the MPLAB X IDE, the ATECC608 B-based authentication and integrity checks fails.
  4. The Secure Bootloader application fails to Boot. LEDs will go to the OFF state.

Step 3.4: Restoring the Secure Bootloader and Validation

  1. Perform the hardware setup steps mentioned above to restore the Secure Bootloader.
  2. Generate the Secure bootloader HEX file in MPLAB X IDE as mentioned in Step 1.4.13: Build the Secure Bootloader Project.
  3. Follow the steps Step 3.2.1: Secure Boot Provisioning mentioned in TPDS and create the signed hex file and program it using the TPDS.
  4. Then press the Reset button and observe that the green LED0 is turned ON.
  5. This indicates the successful running of the Secure Bootloader.
  6. Follow Step 3.2.2: Running the Secure Bootloader Application to receive the application image over UART from a PC by running a Python script.
  7. The successful receiving of the application is indicated by toggling the red LED1.
  8. Since the Secure Bootloader is restored, the Secure Bootloader and test application work as expected. Red LED1 starts toggling indicating Secure and successful test application booting.
  • Modifying the security configurations by (re)-programming the different NVM Configuration rows (using the NVMCTRL peripheral) is possible but the changes done on these NVM Configuration rows will always be applied only after a new reset sequence happens (through a new Boot ROM execution).
  • The Security Configuration Lock bit, i.e., SECCFGLOCK is set to 1 by default. This means, after exiting the Boot ROM:
    • The security configurations are locked so that no code (even secure) can change them before the next reset sequence.
    • The only way to update the security configurations is to (re)-program the NVM Configuration rows and then reset the device.
    • For more information check the PIC32CM LS00/LS60 Specific Security Features section of the PIC32CM LE00/LS00/LS60 Family Datasheet.

 Results

You successfully created a Secure Bootloader application using the PIC32CM LS60 Curiosity Pro Evaluation and experienced how to develop Secure Bootloader, provisioning steps using the TPDS, and receiving the test application to demonstrate the Secure Booting feature.

 Analysis

In this lab, you have successfully created a project from scratch, added Peripheral Libraries (PLIBs), and Bootloader, and learned how to use PIC32CM LS60 Secure Boot features, TrustZone Configurations, and Bootloader configurations. You also learned how to do the provisioning using the TPDS software.

 Conclusions

In this tutorial, you discovered how to configure the device to configure the Secure Boot features, Arm® TrustZone® configurations, and Bootloader configurations. This tutorial can be used as a reference when you develop a real-time application where the Secure Booting feature is required.

© 2024 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.