1 Secure Boot and Signature Header Generation

Attention: Do not skip reading this section

The secure boot, or the authentication of application software upon every system start up is an essential component for the IoT design. It provides many advantages for protecting the embedded system. It is the basis for securing the integrity of application code, and any firmware update. If an intruder manages to insert their software on the system, with a secure boot flow, the authentication/integrity fails and device can not run the application introduced by the intruder.

PIC32CXBZ3/WBZ35 family of devices implement ROM based immutable secure boot.

With the immutable boot code present on the device, application code that is loaded on the device is authenticated upon every boot. Application code can be changed but the cryptographic authentication ensures that the application code changes are always signed by a trusted entity. This action always happens because the ROM boot code is always executed first upon boot. Only the owner of a private key can load trusted application code on the device.

In order to support this architecture, ROM boot code should know where the application image present in embedded flash and where the signature present in order to do the integrity check. All these informations are called as signature header and this header should be appended on top of the acutal application image. Also, this signature header to be programmed in known fixed location in embedded Flash for the ROM bootloader to pick up. Once the authentication is done, ROM bootloader will jump to application start address which is mentioned in the signature header.

ROM bootloader supports 3 types of image authentication:

0: None

1: ECDSA p256 + SHA-256

2: ECDSA p384 + SHA-384

The "None" authentication method, does not do signature verification, but simply jumps to application start address. So, even with "None" authentication method the "signature header" to be part of application image, for the bootloader to know the start address of the application and to know about authentication method.

No matter authenticated image or plain image, the signature header generation and appending the signature header at the fixed address is mandatory step for PIC32CXBZ3/WBZ35 family of devices. The SW development environment which MPLABX should have the facility to accomadate this extra special step which is different from any other Microchip products. A special python (jython) based script is involved in signature calcualtion and signature header generation and loading/ appending the signature header in acutal application image. This script called as properties_device.py which is included in device family pack (DFP) gets invoked by MPLABX at the post-build process.

Note:
Without this script, and the hex image generated by MPLABX will not run on the PIC32CXBZ3/WBZ35 family of devices.
Important:
Very important note for PIC32CXBZ3/WBZ35 family of devices: The generated image with signature header is represented as "..X.production.signed.hex" and created in dist\default\production. While programming the application image from IPE programming tool, it is important to use this signed.hex only. The Microchip conventional .production.hex will no longer work for PIC32CXBZ3/WBZ35 family of devices.
The authentication method selection is done in the project → Properties → Header. By default "None" authentication method is used, and do not select anyother authentication method, as they are not yet supported.