PEmicro Blog

Using PEmicro's Secure Boot Utility for NXP's i.MX RT10xx/RT11xx

Nov 02, 2020

NXP’s i.MX RT10xx and RT11xx devices come with an advanced set of security features which provide a sophisticated level of protection for devices in the field. PEmicro’s Secure Boot Utility is a graphical user interface which configures Secure Boot for applications running on these devices and sets device security features to inhibit copying or misuse.  Functionality includes signing and encrypting applications, generating keys and certificates, setting security fuses, and running a security analysis of all settings.

The Secure Boot Utility automates building secure boot binary files and is used in the process of generating encrypted secure boot programming images for manufacturing.  The goal is to make sure the user's application data is secure in both the manufacturing stage and when devices are deployed in the field. The tool includes a security analyzer which grades the user's security choices based on how secure it will leave the device after programming.

The Secure Boot Utility is integrated into the Cyclone production programming software and included with the PROGARM programming software.

What is Secure Boot?

Protecting embedded systems from attacks continues to be a major concern for developers. As these attacks become more sophisticated, processors are implementing more advanced security measures to prevent their systems from being compromised. One such example is the secure boot options available on NXP’s i.MX RT processors.

Video Overview - Secure Boot Concepts and Utility Overview

Once playing, gear icon can be used to adjust streaming quality.

The fundamental principle of secure boot is that the embedded system should only run trusted, authorized code. This is achieved by using asymmetric cryptography to include a digital signature with the application code. Any modification to the code requires a new signature to be calculated. During boot-up, only the presence of a valid signature allows the application code to execute. The application code together with the digital signature is called a signed image.

Most i.MX RT processors rely on external flash storage (QSPI, HyperFlash, etc.) to store application code. External flash is often a security weakness, and i.MX RT secure boot supports AES128 encryption of the signed image to prevent attackers from viewing the plaintext code/data. This forms the signed+encrypted image.

Enabling Secure Boot

Enabling secure boot on i.MX RT processors requires programming of two distinct regions:

  • The signed or signed+encrypted image is programmed to flash memory (usually external flash, but certain devices like the IMXRT1064 have internal flash)
  • The secure boot options are configured by writing to the eFuses on the i.MX RT processor.


Secure Boot Utility

Secure boot on i.MX RT provides many advantages, but is often very challenging to configure correctly. During development, secure boot is typically left disabled to make debugging easier. For many users, properly enabling secure boot and transitioning to production is a daunting task - there are many distinct steps involved, and it is very difficult to narrow down the problem when things are not working. PEmicro’s Secure Boot Utility simplifies the entire secure boot process by providing an intuitive user interface that provides informative feedback during each step. User input is straightforward but also flexible enough to accommodate custom configurations. It addresses all of the typical challenges faced by users, such as:

  • Unsigned image variations: The Secure Boot Utility is able to handle any type of unsigned image produced by compiler toolchains. Common variations are images where the Image Vector Table (IVT) or Flash Configuration block is absent, and images that execute in RAM vs. FLASH. The utility inspects the unsigned image and reacts appropriately to produce the correct output files.
  • eFuse options: The Secure Boot Utility determines all of the necessary eFuse values to enable the secure boot settings based on the user’s inputs. The user is also allowed to specify custom eFuse values, if needed. Because the eFuses are one-time programmable, this avoids situations where boards are bricked due to misprogrammed fuse values.
  • Sensitive security information: All security information is saved into a single PEKeyFile collection, alleviating the need to maintain private/public key certificates, AES keys, and secure JTAG passwords separately. This information can be shared across different products, and the keys/passwords can be given descriptive names (e.g., ProductA Encryption Key) for ease of use. During production programming, the stand-alone programming files used by PEmicro’s Cyclone products do not expose any security information (more details below).

The Secure Boot Utility produces both the flash and fuse contents required to enable secure boot:

Secure Boot Utility Walkthrough

The Secure Boot Utility is separated into two sections: user inputs and real-time feedback. As user inputs are changed, the utility provides informative details on the effect of those changes. In this walkthrough, we will go through an example of enabling a signed+encrypted (OTFAD) image on the iMXRT1011. The Secure Boot Utility User Manual contains additional technical information and details beyond the scope of this walkthrough.


After selecting the Processor part number, we need to create a new Key Collection file which will store all security information:

We are now prompted to specify where the private/public certificates come from. These certificates are used to produce the secure boot digital signature. Previously generated certificates can be imported manually or from a MCUXpresso Secure Provisioning Tool workspace. In this example, we will rely on the Secure Boot Utility to generate brand new certificates, and we save the key collection with the “project_keys.pekeyfile” filename.

User Application

Next, we will specify the unsigned user application. Our example uses a blinking LED project compiled in NXP’s MCUXpresso toolchain. 

Secure Boot Mode and Signing Certificate

Next we specify the desired Secure Boot mode and the certificate we would like to use for the digital signature. We will use the first certificate here (SRK1). For the secure boot mode, we will select OTFAD to produce a signed+encrypted image:

Signed+encrypted images require an AES key for encryption, so we will create a new key named “Product A Key” with a random value. Users who have previously programmed the SW_GP2 fuse can manually specify a 16-byte value instead of using a random value: 

Flash Configuration

For the Flash Configuration block, the Secure Boot Utility has a number of preset options (SPI, Hyperflash) with customizable values. These options are appropriate for user applications that are missing the flash configuration block. Since our application built in MCUXpresso contains both the IVT and the Flash Configuration block, we will choose the “Preserve from User Application” setting here.

Additional Options

Finally, the last user input section allows us to specify any custom eFuses that we’d like to program as well as the security settings. We set the Security Configuration to Closed to force the processor to only boot images with a valid digital signature.

Reviewing Changes

As the inputs are changed, the numerous information tabs in the Feedback section of the utility will update in real-time. We can review these details to gain insight into the various aspects of secure boot.

The Flash Output Overview tab analyzes the unsigned user application and provides details on what the output boot image will look like. Here we can verify that the application will execute in place as a Flash image and our Flash Configuration block will be left unmodified.

The Fuse Output Overview tab details all eFuses that will be programmed. Any custom fuses will also appear here. 

Finally, the Security Overview tab will analyze how secure our product will be using the given options. We see that there are some glaring weaknesses in our setup. An attacker can gain unauthorized debug access and potentially duplicate our product because we did not enable any JTAG security and did not lock the sensitive secure boot fuses. For users who are still in development, it is ok to move ahead with these warnings, but for production, these security flaws must be addressed.

Generating the boot image

We are now ready to click on the “Generate Boot Image” button. The Build Results log will provide feedback of the build process and alert the user if there are any errors. 

Output Files

The Secure Boot Utility creates three output files:

  • The .srec file contains the signed+encrypted image. This will be programmed into the flash.

  • The .OPT file contains the values to be programmed into the fuses of the iMX RT processor.

  • The .cfg file is a PEmicro compatible programming script that contains the proper sequence to program the flash and fuse contents. 

Programming to target board

Inspecting the .cfg file shows us the sequence of commands to program our board for secure boot. In our example, we can observe the distinct the flash and fuse programming sections:

NOTE: The "SS" command in the example above has since been replaced with the "QO" command (.s19, hex, elf) or "QB" command (.bin) depending on the type of data file. Please refer to this article.

These commands are compatible with PEmicro’s Cyclone production programmers and  PEmicro’s PROGACMP programming software. After programming is complete, secure boot is enabled on the target board. 

Production Programming

PEmicro’s Cyclone Image Creation Utility can automatically link a Secure Boot Utility project (.sbp) file to the image creation process. Each time a Cyclone image is created, the Secure Boot Utility is automatically invoked to generate the latest flash (.srec) and fuse (.OPT) files to be included into the image. This helps streamline the secure boot process for users ready to move into the production programming phase of their projects.

Production programming also presents unique security challenges. Sensitive security information that must be programmed (AES Encrypted Boot Key, Secure JTAG password) cannot be inadvertently exposed during the programming process. The stand-alone programming (SAP) files used by the Cyclone allow this sensitive information to be encapsulated and given to a third-party contract manufacturer without allowing the sensitive information to be accessed. The Stand Alone Programming Image (eSAP) can be encrypted so that it is only usable on Cyclone which have been provisioned with the appropriate cryptography keys. The build process of an eSAP image looks like this:

For more information on production programming with secure boot, please see our follow-up article with video demonstration

Tags related to this Blog Post

Cyclone     Cyclone FX     Multilink     Multilink FX     Prog ACMP     NXP     Production Programming     Debug