Home  icon  Articles  icon  Secure Boot with eSOMiMX6

bulat-icon  Articles  
 
 

[+]  Articles

  
     
   

Secure Boot with eSOMiMX6
  System on module  Introduction  
  System on module  Secure Boot in iMX6  
  System on module  Binaries to be secured in Linux Embedded Systems  
  System on module  Secure Boot Implementation with eSOMiMX6  
  System on module  References  
 

1. Introduction
 
Security continues to be an increasingly important concern in the design of modern systems where the embedded or handheld devices are getting connected and are more and more involved in network communications. For security consideration, it is necessary that the hardware has some mechanism to ensure that the software it is running can be trusted. So OEM can utilize it to make their product reject any system image which is not authorized for running. Secure boot is a process through which the embedded system determines whether the system’s image is trusted or not. This blog discusses about the secure boot feature supported by iMX6 processor and how secure boot is implemented in eSOMiMX6 SOM module using this feature.

2. Secure Boot in iMX6

iMX6 has a key feature of the boot ROM - the ability to perform a secure boot or High Assurance Boot (HAB). This is supported by the HAB security library which is a subcomponent of the ROM code.
HAB uses a combination of hardware and software together with a Public Key Infrastructure (PKI) protocol to protect the system from executing unauthorized programs. Before the HAB allows a user's image to execute, the image must be signed. The signing process is done during the image build process by the private key holder and the signatures are then included as part of the final Program Image. If configured to do so, the ROM verifies the signatures using the public keys included in the Program Image.
A secure boot with HAB can be performed on all boot devices supported on the chip in addition to the Serial Downloader. The HAB library in the boot ROM also provides API functions, allowing additional boot chain components (boot loaders) to extend the secure boot chain.

2.1 Public Key and Private Key pair generation

An asymmetric encryption is adopted to implement the HAB feature. The OEM can use an utility provided by NXP to generate private key and corresponding public key pairs. For any system image they want to release, the private key is used to do the encryption. This encryption generates a unique identifier for the image which is called a certificate. The public key is also attached to the image. Before applying the new system, the public key is used to decrypt the certificate. Then, a comparison is performed to check if the certificate and the image match. The image is considered "trusted" only if a match occurs. Otherwise the image is deemed as "unsafe" and will not be permitted to be loaded and run. This process is called authentication. A hacker can only have access to the public key. As per the property of asymmetric encryption, private key, which the OEM uses, cannot be deduced from that. Without the private key, the hacker cannot attach a valid certificate for his malicious system image. HAB will reject it in a very early stage. The OEM will burn the digest (hash) of the public key to the eFuses of i.MX 6 chip. Once burned, it cannot be modified. This prevents the possibility of the hacker using another pair of private and public key to cheat.
Public Key and Private Key pair generation

2.2 Fusing hash of public key into iMX6
 
OEM uses NXP utility (code signing tool) to create a private / public key pair . The Hash of the public key is programed into the efuse of iMX6. So the hacker cannot use a different public / private key pair. Once the efuses are programmed it cannot be reprogrammed.

2.3 Image Signing

 
The certificate is generated by encrypting the hash of image using the private key produced by NXP utility.
Image Signing
Signing an image can be done in two ways.
1. Fixed size signed image.
In this method, the details of location of public key and certificate in signed image are fixed. Padding is used to fix the size of each area. Below is layout of fixed size signed image.
Fixed size signed imag
2. Variable size signed image.
In this method, the details of location of public key and certificate in signed image are varied and no padding is used.

2.4 Authentication Process by Boot ROM in iMX6
 
When iMX6 processor is powered on it will start authenticating the signed image programmed in boot device. It involves following.
  • Read public key value in signed image. Calculate hash value for that public key.
  • Compare the calculated public key hash value with the fused public key hash value.
  • If comparison is success, go to next step. Otherwise stop booting this signed image.
  • Using the public key, decrypt the Certificate to get hash value of actual image.
  • Using the public key, digest the actual image to get hash value.
  • Compare these two hash values.
  • If Comparison is a success, image is authenticated. Otherwise it is not authenticated and stops booting this image.
Authentication Process by Boot ROM in iMX6

3. Binaries to be secured in Linux Embedded Systems
 
Generally an embedded system has the following three kinds of software for serving a dedicated work.
  • Boot loader - First software code run by processor in embedded system when powering it on.
  • Kernel - The OS system (like Linux and Android) which does all resource (devices, memory) management with help of respective device drivers and allows application to access devices.
  • Root File System - Collection of applications and its dependent library files, configuration files.

4. Secure Boot Implementation with eSOMiMX6
 
e-con Systems made the secure boot work with eSOMIM6 module successfully. e-con followed the below steps to implement the secure boot with eSOMiMX6.
  • Generation of pair key and programming hash of public key into efuse registers of iMX6. Note that this efuse is one time programmable. It has to be done correctly. Otherwise the system cannot be used even in Serial Download Mode.
  • HAB configuration is set to Closed Mode. There are two modes: 1. Open 2. Closed
    • In Open mode, the HAB tries to authenticate the image. If it fails, it will through errors but allows the system to boot the authenticate failure image.
    • In Closed mode, the HAB will not allow the system to boot the authenticate failure image.
  • Modifying boot loader source to use HAB library to authenticate image before booting
  • Signing boot loader image
  • Preparing rootfs as ramdisk image
  • Preparing ramdisk image as part of kernel image
  • Signing device tree binary
  • Signing ramdisk integrated kernel image
  • Programming signed images (bootloader, device tree and integrated kernel) into boot device

5. References

top-icon