Freescale Semiconductor Application Note Document Number: AN4555 Rev. 1, 05/2013 Secure Boot with i.MX28 HAB Version 4 1 1.1 Introduction Purpose The purpose of this application note is to explain how to perform a secure boot on i.MX28 applications processors with High Assurance Boot version 4 (HAB v4). This includes steps on how to generate signed images and configure the IC to run securely using freely available tools provided by Freescale.
Introduction digital signatures. HAB provides a mechanism to establish a root of trust for the remaining software components. The i.MX28 ROM is architecturally quite different from other i.MX ROMs that support HAB v4. The differences in image format and encrypted boot mechanism are substantial, and hence this separate application note should be used rather than the generic application note for HAB v4. The encrypted boot for i.
Introduction 1.4 Definitions, acronyms, and abbreviations Table 1. Definitions, acronyms, and abbreviations Term/Acronym Definition BD file Boot descriptor file, an input file to Elftosb that describes the flow of boot and different binary and elf images included in the final SB file. Bootlet A bootlet is an image that can be executed on i.MX28 processor using ROM command CALL HAB.
i.MX28 security architecture overview Table 1. Definitions, acronyms, and abbreviations (continued) 1.5 Term/Acronym Definition SRK Super Root Key, an RSA key pair which forms the start of the boot-time authentication chain. The SRK private keys are held by the CA. Unless explicitly noted, SRK in this document refers to the public key only. SRK Table Super Root Key Table, HAB v4 uses an SRK Table with maximum length of up to four (4) keys, allowing selection of the SRK used for a particular image.
i.MX28 security architecture overview The HAB library, embedded in the processor ROM, contains functions to authenticate an image as well as initialize and test security hardware. The same library functions can be called from later boot stages to extend the boot chain past the stage immediately after the Boot ROM. The areas of an image that HAB verifies are completely customizable through a series of commands that are interpreted by HAB.
i.MX28 security architecture overview Figure 1. Secure boot flow from device 2.3 HAB Public Key Infrastructure HAB authentication is based on public key cryptography using the RSA algorithm in which image data is signed offline using a series of private keys. The resulting signed image data then is verified on i.MX28 using the corresponding public keys. This key structure is known as a Public Key Infrastructure (PKI) tree. Secure Boot with i.MX28 HAB Version 4, Rev.
i.MX28 security architecture overview Figure 2 gives an example of a typical PKI tree that is generated by the Freescale Code Signing Tools. Figure 2. HAB v4 enabled devices typical PKI tree For further information on the PKI tree used for HAB v4, see the HAB CST User Guide as mentioned in the Section 1.5, “References.” The details of digital signature authentication with the RSA algorithm are beyond the scope of this document.
Designing for code signing The arrows in Figure 3 show the authentication flow. For example, the SRK is used to authenticate both the CSF key certificate and the image key certificates. There are several important features to note. First, each key can certify multiple instances of the objects beneath it. For example, a single SRK can certify multiple CSF keys, a single CSF key can authenticate multiple CSFs (for example, on different product revisions), and a single image key can certify multiple images.
Designing for code signing is defined in the High Assurance Boot Version 4 Application Programming Interface Reference Manual included in the Freescale Code Signing Tool release package. The memory location of the RVT differs for each member of the family. In this case, the location of the RVT for MX28 is documented in the i.MX28 Applications Processor Reference Manual. 3.1.
Designing for code signing the boot image,” which discusses how the IVT is used in the signed image. Also see the i.MX28 Applications Processor Reference Manual for more detailed description of IVT data structure. NOTE The i.MX28 ROM requires that the IVT is followed by an unsigned 32-bit integer in memory containing the size of entire image including IVT and CSF data. See Boot Modes chapter of the i.MX28 Reference Manual for more details. 3.1.
Designing for code signing 3.1.4 Image layout When performing a secure boot on an i.MX28 processor, the image must contain a correctly formatted image vector table (IVT) with a valid header and pointers. The loader inside ROM first loads the image from boot media. The image data is then passed through the DCP (Data Co-Processor) where it will be decrypted (if it is an encrypted image) and placed at the destination address. As mentioned earlier in Section 2.
Designing for code signing The IVT can appear anywhere before, in between or after the Image Data but not at address 0. Otherwise *self in IVT points to NULL and is interpreted by HAB library as an invalid address. The Image Length field as mentioned earlier must immediately follow the IVT and is the length of entire image data including IVT and CSF data. 3.1.6 Secure boot—image layout The SEC_CONFIG fuse field tells HAB whether the device is to boot securely or not.
Designing for code signing Figure 5. Typical memory layout of a signed image The IVT can appear anywhere before, in between, or after Image Data but not at address 0. Otherwise *self in IVT points to NULL and that will be interpreted by HAB library as an invalid address. Also the CSF and associated data (SRK Table, Signatures and Certificates) need not be concatenated together but it is the default output of the CST.
Designing for code signing The first CSF in the boot sequence must contain an Install SRK command to install a single SRK from the SRK Table provided. Also, it must contain an Install CSFK command to install the CSF key prior to CSF authentication. Subsequent CSFs in the boot sequence do not require Install SRK and Install CSFK commands. Every CSF must contain an Authenticate CSF command to authenticate the CSF contents using the CSF key.
Designing for code signing ../linux/srktool –h 4 –t SRK_1_2_3_4_table.bin –e SRK_1_2_3_4_fuse.bin –d sha256 –c ./SRK1_sha256_2048_65537_v3_ca_crt.pem,./SRK2_sha256_2048_65537_v3_ca_crt.pem,./SRK3_sh a256_2048_65537_v3_ca_crt.pem,./ SRK4_sha256_2048_65537_v3_ca_crt.pem –f 1 For details on key generation with the CST, see HAB CST User Guide. NOTE Section 6, “Manage the electrical fuses,” provides guidance on how to blow fuses, and which fuses must be blown for a secure product. 3.2.
Designing for code signing /* reserve this area to store HAB related data such as * CSF commands, certificates and signatures */ __hab_data = .; . = . + 0x2000; __hab_data_end = .; /* place the __hab_data memory region before the .bss * region to avoid being over written at runtime and to * keep the u-boot binary as small as possible */ . = ALIGN(4); .bss : { *(.bss) } } 2. The next step is to add the IVT data structure, image length and symbol name input_ivt to locate the IVT data structure in memory.
Signed U-Boot and Linux kernel example // Absolute address of the Boot Data: may be NULL, but not // interpreted any further by HAB NULL, // Absolute address of the IVT (const void*) (&input_ivt), // Absolute address of the image CSF (CSF data generated by cst) (const void*) (&__hab_data), // Reserved in this version of HAB: should be zero.
Signed U-Boot and Linux kernel example Figure 6. Players in the generation of signed boot image Figure 6 above shows the tools and steps for code signing a bootable image for i.MX28 processor. The prerequisites are: • Linux machine set up to perform builds of the i.MX28 BSP • Freescale CST • Freescale elftosb tool • Objcopy utility Here are the steps to generate signed u-boot SB file: 1. The source code changes described in section 3.3 are required for power_prep, boot_prep and u-boot. 2.
Signed U-Boot and Linux kernel example The HAB data is generated using the code signing tool. Section 8, “Example CSF text files for reference,” illustrates sample CSF files including u-boot.csf and boot_prep.csf. cst –o boot_prep_hab_data < boot_prep.csf cst –o power_prep_hab_data < power_prep.csf cst –o uboot_hab_data < u-boot.csf 4. Finally the elftosb tool is used to generate the signed SB file. Elftosb is described in Section 5.2, “IMX_ELFTOSB_TOOL.” ./elftosb -z -V -f imx28 -c ./uboot_ivt.
Signed U-Boot and Linux kernel example 4.1 Sample boot descriptor file used for u-boot Image // i.MX28 ROM command script to load and run U-Boot options { flags = 0x01; } sources { power_prep = "power_prep"; power_prep_bin="power_prep.bin"; power_prep_hab_data="power_prep_hab_data"; boot_prep = "boot_prep"; boot_prep_bin ="boot_prep.bin"; boot_prep_hab_data="boot_prep_hab_data"; u_boot = "u-boot"; u_boot_bin="u-boot_pad.
Signed U-Boot and Linux kernel example // Load and call u_boot - ELF ARM image //---------------------------------------------------------load u_boot_bin > 0x41008000; load u_boot; load uboot_hab_data > u_boot:__hab_data; hab jump u_boot:input_ivt; } 4.2 Sample boot descriptor file used for Linux kernel image // i.MX28 ROM command script to load and run Linux kernel options { flags = 0x01; } sources { power_prep = "./power_prep"; power_prep_bin = "./power_prep.bin"; power_prep_hab_data = ".
Encrypted boot and Elftosb //---------------------------------------------------------load boot_prep_bin > 0x10; load boot_prep; load boot_prep_hab_data > boot_prep:__hab_data; hab call boot_prep:input_ivt; //---------------------------------------------------------// Prepare to boot Linux //---------------------------------------------------------load linux_prep_bin > 0x2000; load linux_prep; load linux_prep_hab_data > linux_prep:__hab_data; hab call linux_prep:input_ivt; //-----------------------------
Manage the electrical fuses The package contains executable elftosb.exe for Windows and elftosb for UNIX. See the documentation available in the package for detailed explanation of elftosb and the image encryption and decryption process 6 Manage the electrical fuses 6.1 Tools to blow the fuses For programming any fuse on i.MX28, Freescale recommends using the IMX_OTP_TOOLS package available on freescale.com, search for “IMX_OTP_TOOLS.
Manage the electrical fuses On Windows (Keygen.exe), cryptographically secure RNG APIs in the OS are used to generate the random key. On Linux (Keygen), /dev/random is used to generate the random key. 6.4 Recommendations on i.MX28 fuse configuration During production, it is suggested to change the SEC_CONFIG of the chip to Closed configuration only once the programming, provisioning, validation and other pre-production steps are working successfully in Open configuration.
Development and debug tips The otp_burner.py script uses the binary SRK hash file to generate an executable image that can program fuses. The output image otp_init.sb resulting from otp_burner.py is then downloaded to i.MX28 using BitInit.exe. The i.MX28 must be connected in USB recovery mode in order for BitInit.exe to download the SB file to internal RAM on the device. When executed on i.MX28 otp_init.sb programs the SRK fuses. Using these tools will ensure SRK and other fuses are programmed correctly.
Example CSF text files for reference /* Display HAB Failure events */ while (hab_rvt_report_event(HAB_FAILURE, index, event_data, &bytes) == HAB_SUCCESS) { printf("\n"); printf("---------HAB Event %d -----------------\n", index + 1); printf("event data:\n"); /* display_event will simply prints out the contents of events_data */ display_event(event_data, bytes); printf("\n"); bytes = sizeof(event_data); index++; } /* Check reason for stopping */ if (hab_rvt_report_event(HAB_STS_ANY, index, NULL, &bytes) ==
Example CSF text files for reference Engine Configuration = 0 Certificate Format = X509 Signature Format = CMS [Install SRK] File = "../crts/srk_tbl1_2_3_4.bin" # Specify the index of the SRK in the SRK Table Source index = 0 [Install CSFK] File = "../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem" [Authenticate CSF] [Install Key] Verification index = 0 Target index = 2 File = "../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.
Example CSF text files for reference [Install CSFK] File = "../crts/CSF1_1_sha256_2048_65537_v3_usr_crt.pem" [Authenticate CSF] [Install Key] Verification index = 0 Target index = 2 File = "../crts/IMG1_1_sha256_2048_65537_v3_usr_crt.pem" # Sign entire linux_prep image # Blocks have the following definition: # Base address of the binary file, Offset, Length of block in bytes [Authenticate Data] Verification index = 2 Engine = DCP Blocks = 0x00002000 0x0 0x4000 "linux_prep.bin” 8.
Example CSF text files for reference # Sign entire linux_prep image # Sign entire zImage # Blocks have the following definition: # Base address of the binary file, Offset, Length of block in bytes [Authenticate Data] Verification index = 2 Engine = DCP Blocks = 0x00002000 0x0 0x4000 "linux_kernel.bin", \ 0x40008000 0x0 0x2DA030 "zImage" 8.4 Boot_prep CSF example [Header] Version = 4.
Revision history 9 Revision history Table 2 provides a revision history for this application note. Table 2. Document revision history Rev. Number Date 1 05/13 0 08/2012 Substantive Change(s) • • • • Added RVT term and definition to Table 1,“Definitions, acronyms, and abbreviations.” Added reference to i.MX28 Reference Manual in Section 1.5, “References.” Added note about RSA public key sizes to Section 2.1, “ROM bootstrap code and HAB library.” Added information regarding the RVT in Section 3.
How to Reach Us: Information in this document is provided solely to enable system and software Home Page: freescale.com implementers to use Freescale products. There are no express or implied copyright Web Support: freescale.com/support information in this document. licenses granted hereunder to design or fabricate any integrated circuits based on the Freescale reserves the right to make changes without further notice to any products herein.
