1 Secure Boot and Signature Header Generation

Secure boot, which verifies application software at each system startup, is a critical feature for IoT architecture. It offers numerous benefits in safeguarding the embedded system. Serving as the foundation for maintaining the integrity of application code and firmware updates, secure boot ensures that if unauthorized software is introduced into the system, the compromised authentication process prevents the device from executing the intrusive application

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.

Secure boot architecture necessitates that the ROM boot code is aware of the specific locations within the embedded Flash where the application image and its corresponding signature are stored. This is crucial for performing integrity checks. The collection of this location information is referred to as the signature header, which must be affixed to the beginning of the actual application image. Additionally, the signature header must be programmed at a predetermined, fixed location in the embedded Flash memory so that the ROM bootloader can easily locate and access it. After successful authentication, the ROM bootloader proceeds to the application's starting address as specified in the signature header to initiate the execution of the application.

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 software development environment which MPLABX must have the facility to accommodate this extra special step which is different from any other Microchip products. A special python (jython) based script is involved in signature calculation 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.

Important:

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.