Overview 

This blog includes :

1. Overview of Relevant i.MX Security Features
2. Recommended i.MX RT Security Settings for Production
3. Recommended Stand Alone Programming (SAP) Image Encryption for Production
4. Integration of the Secure Boot Utility Within the Image Creation Utility
5. Creating a Secure Boot Programming Image for i.MX RT1011 [Video Demonstration]

Overview of Relevant i.MX Security Features

1. Run Signed Firmware Only

The i.MX RT series supports a secure boot process which will only allow application code signed with specific certificates to run. Generally, on a one time basis, you will generate a group of four signing certificates which are stored in a PEKeyFile collection.  Programming the hash of these certificates into the fuses of an i.MX RT device with other appropriate settings will cause the i.MX device to only boot code that is signed with one of those certificates.

The effect of this feature is that you can program an i.MX device during production to only ever boot application code that you have signed. This can be used to prevent malicious, unauthorized, or corrupt code from running in your product.

The original certificates are not programmed into the fuses of the device and as such remain in your private keeping. Only the hash values of the certificates are programmed into the fuses and only the public part of the certificate is included with your application.

A PEKeyFile collection contains the set of four signing certificates and can be connected to any number of secure boot projects.

2. Application Firmware Encryption 

In addition to the signed code option, there is an option to also encrypt the application code as well. The application code is stored in an encrypted form in the internal/external memory. In most cases, the processor will run directly from the encrypted memory in a process called Execute In Place (XIP). The decryption happens on the fly with the on-chip BEE or OTFAD  modules. Alternately, the encrypted code can also be decrypted on bootup, stored to RAM, and run out of RAM. Running the application from RAM may present moderate performance benefits compared to encrypted XIP, but if the RAM is external to the processor it is vulnerable to being read out. 

Generally, on a one-time basis for a particular product (or product line), the user will generate an AES cryptography key that PEmicro refers to as the “Encrypted Boot Key”. This key is used, sometimes with other randomized keys, to encrypt the application code prior to its being stored to flash. If the Encrypted Boot Key is programmed into the fuses of an i.MX RT device with other appropriate settings, the i.MX device will gain the ability to run from, and decrypt, application code which has been encrypted with the same Encrypted Boot Key. 

There is no requirement that an i.MX processor which has an Encrypted Boot Key programmed into its fuses runs only encrypted binaries. The processor can run either signed or signed+encrypted applications.

The advantage of encrypting the user application is that it is a strong defense against product copying. If the application is unencrypted and it is stored in external memory, it could be copied, signed with a different certificate (or left unsigned), and run on a blank new i.MX device. Encrypting the application with the Encrypted Boot Key prevents this. Without a copy of the Encrypted Boot Key, the application code is unreadable and, even if copied, another i.MX device wouldn’t know how to decrypt it. 

A PEKeyFile Collection can contain any number of Encrypted Boot Keys.

3. Restricting JTAG Access with a Password

In order to prevent debug access to the device after production programming, fuses can be set to either disable the debug module or to enable Secure JTAG Mode. Secure JTAG mode requires that the debug/programming hardware use a password during connection. Without the appropriate password,  Secure JTAG mode does not allow read/write memory or execute code access through the debug module. 

If the correct password is provided, normal JTAG/SWD mode may be used to debug or reprogram the device. 

PEmicro utilities store JTAG Passwords, along with Signing Certificates and Encrypted Boot Keys, in a single PEKeyFile collection file (.peKeyFile). The PEKeyFile stores a single set of four Signing Certificates and an unlimited number of JTAG Passwords and Encrypted Boot Keys. Many secure boot projects can share these same security elements.

Having Secure JTAG access to the device after factory programming can be useful in order to reprogram the device or do failure analysis later.

PEMicro recommends either enabling Secure JTAG mode or disabling the JTAG port altogether in cases where security is important. PEMicro’s Cyclone Programmers and Multilink debug interfaces support Secure JTAG mode.

A PEKeyFile collection can contain any number of I.MX passwords

4. Locking Sensitive Security Fuses

There are fuses which have sensitive values in them, most notably the fuses which hold the Encrypted Boot Key and JTAG password. One of the advantages of the PEmicro Cyclone programming solution is that the programming images produced are totally self-contained and encrypted. That means the values of sensitive keys are protected during the manufacturing process and from anyone handling the programming data. 

Once the keys are programmed into the target device itself, it is recommended that they are locked against any future read operation.  When “Lock Fuses” is enabled in the Secure Boot Utility, the Cyclone will lock the sensitive fuses against read/write directly after programming them. Application code running on the device, as well as accesses from debug interfaces, will not be able to read the values of these sensitive fuses.  

Even though the signing, encryption, and JTAG password/disable features should prevent access to reading these fuses, PEmicro recommends permanently restricting (“Locking”) access to these sensitive fuses as a security measure.

PEmicro’s Image Creation and Secure Boot Utilities

PEmicro’s Image Creation Utility is a graphical user interface which allows a user to define all the inputs needed to build a stand alone programming image. A Stand Alone Programming eSAP image contains all firmware files, fuse definitions, power settings, debug settings, serialization, algorithms and more needed during programming and is encrypted to protect its contents. The Image Creation Utility generates a configuration file (.CFG) used by the SAP Image Compiler to build the image.

i.MX RT10xx applications being built for production require additional security settings to facilitate signing and encrypting application code as well as the ability to generate all the necessary fuse files, keys, certificates, and passwords. PEMicro includes the graphical Secure Boot Utility, conveniently integrated into the Image Creation Utility, to handle these details. The Secure Boot Utility is detailed in a separate blog post (this blog post discusses how it is integrated into the Image Creation Utility). The Secure Boot Utility is launched from within Image Creation:

The Secure Boot Utility creates/saves a Secure Boot Project File (.SBP) on exit, which is later used to build parts of the eSAP Image. 

Recommended i.MX RT Security Settings for Production

The Secure Boot Utility has two main types of settings which affect the security of the i.MX application : 1) Application Settings and 2) Device Settings. Application settings are related to the signing and encryption of application code, and Device Settings deal with restricting access to chip resources like JTAG and sensitive fuses. As you change many of these settings, the security profile of the i.MX RT device will change. The good news is that the Secure Boot Utility has a security overview tab which analyzes the Secure Boot Settings for vulnerabilities.  PEmicro’s recommendation is to check the Security Overview whenever changes are made to the Security settings in the Secure Boot Utility, and to remove any vulnerabilities noted. Here are the most important settings:

To make sure the target processor will only run signed code, it should be “Closed”.

To make sure the code being programmed is encrypted, and that the target device has the keys necessary to run encrypted code, the Secure Boot Mode should be set to OTFAD or BEE (one or the other is used, depending upon device) :

To lock sensitive fuses (Boot Encryption Key and JTAG Password) from future access, Lock Fuses should be set to “Yes” :

JTAG Status should be set to either permanently disabled (“No Debug”) or be password protected (“Secure JTAG”) :

Recommended Stand Alone Programming (SAP) Image Encryption for Production

A stand-alone programming image can be encrypted when it’s created. Regardless of whether encryption is used, the user does not have direct access to the contents of the programming image as all data is encoded in a sophisticated fashion and embedded into a single file. Adding a layer of industry standard cryptography substantially hardens this protective shell.  PEmicro recommends encryption for cases where the customer wants to:

1. Restrict the programming image to be used only on specific Cyclone units. These Cyclones would need to be provisioned with the same cryptography key that the image was encrypted with.

2. Restrict programming to a particular date range or programming count

3. Make it virtually impossible to reverse engineer the contents of the programming image

When an encrypted image is saved to disk, it will have an .esap extension (.sap is the extension for un-encrypted). PEmicro utilities and the Cyclone display will both clearly show when an image is encrypted.Details of image encryption can be found here.

Modifying Secure Boot Settings in the Image Creation Utility

The Secure Boot Utility is integrated into the Image Creation Utility, as seen here:

The Link/Create Secure Boot Project button allows for specifying or creating a Secure Boot Project and linking it to the current Image Creation configuration. The Edit Secure Boot Project button launches the Secure Boot Utility, which allows the user to modify the secure boot settings. The Clear button unlinks a linked Secure Boot Project. 

Whenever the Secure Boot Project is edited/changed from the Image Creation Utility, or the Regenerate Programming Sequence button is clicked, the user is given the option of updating the programming sequence script in the Image Creation Configuration to match the Secure Boot Project settings. It is generally recommended to update the programming sequence script, though any changes you previously made to the programming sequence script will be lost.  

The checkbox labelled “Auto-build Signed Binaries …. during SAP image creation process” causes the Image Creation process to build the intermediate signed or signed+encrypted application from the unsigned application input, as well as a fuse file containing all security options based on the linked Secure Boot Project, each time an eSAP image is created. In the example above, evkmimxrt1010_iled_blinky_final.srec and evkmimxrt1010_iled_blinky_fuses.OPT would be built each time just prior to the eSAP programming image being built. 

The build process for this case can be seen here:

Based on the settings in the Secure Boot Project file, the Secure Boot Utility Command-Line Compiler generates intermediate flash/fuse output files which are then consumed by the SAP Image Compiler when creating the stand alone programming image. These intermediate files are:

Secured Application File : This is an S-record file which contains all application data, tables required for the bootloader to boot the application, and all appropriate signatures and hashes needed to boot in the appropriate mode. The source application binary and the specific certificates/keys used to encrypt/sign the application data are specified in the Secure Boot Project file.

Aggregate Fuse Configuration File : This is an options file (.opt) which describes the total set of fuses to be programmed as part of the stand-alone process. This includes user-specified fuses in addition to all fuses needed to implement the security selections in the Secure Boot Project file.

Note that these intermediate output files are referenced in the auto-generated programming script which was imported into the Image Creation configuration :

This reference, in the programming sequence script in the Image Creation configuration, is what causes these intermediate binaries to be captured into the eSAP programming image, and is used to program the target processor. In the example above, the signed application file is programmed with the appropriate external flash programming algorithm and the fuses file is programmed with the i.MX RT1011 OTP algorithm (One Time Programmable Fuse Region). Once the script is imported from the Secure Boot Project, it can be modified. This allows detailed changes to be made to the programming sequence used in the eSAP image. 

Creating a Secure Boot Programming Image for i.MX RT1011 [Video]

The following video gives a demonstration of how to use the Image Creation Utility in concert with the integrated Secure Boot Utility to generate a Stand Alone Programming Image which secures an NXP i.MX RT1011 processor:

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

Video Follow-Up

Where is the first video describing secure boot referenced by this video?

Included in the Secure Boot Utility blog post. 

Where do I get the Image Creation Utility featured in this video?

Download the Cyclone LC & Cyclone FX installation software and then run the Cyclone Image Creation Utility. The latest installation software also contains the Secure Boot Utility for i.MX RT10xx/RT11xx devices. 

When a Secure JTAG password is created, is the description string the password?

No. We ask for a password description in order to allow the user to keep track of the password. The password is a randomly generated value using cryptography libraries. Often a Secure JTAG password will be shared between products and/or product lines and is saved in the PEKeyFile collection.

The video shows creating a cryptography key to encrypt an eSap image. Is this a common event?

No. In general you will create a PEImageKey only infrequently. Often a single PEImageKey will be universally used by a company or for production at a specific manufacturing location. Encrypting with a PEImageKey allows your programming images to only be loaded onto Cyclones which have a copy of the exact same PEImageKey. Even without using cryptography, settings within a programming image would be hard to access as they are heavily encoded. Using cryptography makes reverse engineering virtually impossible.