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. 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. 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 on i.MX RT processors requires programming of two distinct regions: 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: The Secure Boot Utility produces both the flash and fuse contents required to enable secure boot: 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. Next, we will specify the unsigned user application. Our example uses a blinking LED project compiled in NXP’s MCUXpresso toolchain. 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: 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. 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. 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. 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. 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. 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. 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 demonstrationWhat is Secure Boot?
Video Overview - Secure Boot Concepts and Utility Overview
Enabling Secure Boot
Secure Boot Utility
Secure Boot Utility Walkthrough
Keys/Certificates
User Application
Secure Boot Mode and Signing Certificate
Flash Configuration
Additional Options
Reviewing Changes
Generating the boot image
Output Files
Programming to target board
Production Programming
Tags related to this Blog Post
Cyclone
Cyclone FX
Multilink
Multilink FX
Prog ACMP
NXP
Production Programming
Debug