Security Mechanism RTL87x3EP

This document is about the following content for RTL87x3EP:

1. How to enable secure features on a non-secure IC.

2. How to generate an ECDSA signature key.

3. How to prepare ECDSA signed images for the secure IC.

For secure IC, the secure mechanism can be activated in the boot flow. It can trigger the eFuse legality verification and enable integrity and authenticity validation for the images. For non-secure IC, only some parts of the fields in the image header are checked, and the integrity verification of the image is usually disabled for time consumption. If the IC is being used in non-secure status in the project and does not need to be enabled to secure status, please skip this document.

Note

Users can check the IC secure status by clicking Check Secure Boot button on the RD_Download page of MPPG Tool.

Secure Mechanism

The secure mechanism is used in the boot procedure. It is related to the ECDSA signature and verification of the image.

Secure Boot

Secure boot is used to enhance security authentication for the images in the boot procedure. eFuse verification is also used for secure boot. Various algorithm mechanisms are used for the images in the different procedures. These mechanisms include ECDSA signature, AES CMAC, AES ECB algorithm, AES CBC algorithm, SHA256 algorithm, and CRC algorithm. The usage scenarios of these algorithms are as follows:

• The ECDSA signature verification is used in the image authentication procedure, regardless of whether it is the first time to boot.

• The AES CMAC is used in the key generation, and it is not used in image integrity check for RTL87x3EP.

• The image header contains fields for SHA256 value and CRC value. The SHA256 value is used to check the image integrity during OTA upgrade procedures. Also, the SHA256 algorithm is also used in the ECDSA public key hash verification procedure. The CRC value can be used for the image integrity check for non-secure IC. The integrity checking by CRC is usually disabled due to the time consumption.

• The AES ECB algorithm is used in eFuse key management, while the AES CBC algorithm is used in the image encryption and decryption procedure for the RAM code in the image.

• The ECDSA algorithm and AES algorithm for images are used in conjunction with the key management mechanism in the eFuse. The AES keys for image RAM code decryption are specific to the IC part number and are protected by RTK as proprietary information. The ECDSA keys, on the other hand, can be generated and held privately by users. It is important for users to adhere to the ECDSA verification procedure.

In the ECDSA signature verification procedure, there are two essential checking points for the images:

1. The ECDSA public key in the image is checked against the ECDSA public key hash stored in the eFuse. This ensures that the public key used for verification is trusted and matches the expected signature key.

2. The ECDSA signature in the image is verified to ensure the integrity and authenticity of the image. This signature serves as a cryptographic proof that the image has not been altered or tampered with.

If the secure boot status is enabled, the ECDSA public key hash needs to be burned into the eFuse of the IC. Additionally, all important images, such as the application image developed by users, need to be signed before downloading into flash. With the tool provided by RTK, different users can generate their own unique ECDSA key. By bonding the chip with the key, potential risks resulting from image leakage by users can be prevented.

If User A and User B generate ECDSA keys separately, their ECDSA keys will be different and private. If User A wants to modify the images to run on User B's device, User A will not get User B's ECDSA key. As a result, the modified images cannot run on User B's device. Additionally, since the ECDSA keys between User A and User B are different, their images cannot run on each other's devices. Therefore, protecting the ECDSA key is very important.

If the IC is initially in a non-secure status, it will transition to a secure status when a user bonds an ECDSA key with the IC.

Note

Secure boot is not designed to prevent images in flash from being unintentionally or maliciously damaged. It is designed to avoid the following situations:

1. Acquiring and tampering with the user's images by hackers: Secure boot helps protect against unauthorized access to and modification of the user's images by validating the integrity and authenticity of the images using ECDSA verification procedures.

2. Attempts to re-run the acquired and modified images in the user's IC: Secure boot ensures that only trusted and validated images can be executed on the device, preventing modified images from running and potentially compromising the customer's product behavior.

ECDSA Signature

This document will reference several important concepts about ECDSA signature, which are clarified below:

1. ECDSA Sign: It refers to the action of applying an ECDSA signature on the image using the tool provided by RTK.

2. ECDSA Verify: It refers to the action of performing ECDSA verification on the images stored in flash by the secure bootloader.

3. ECDSA Key: It refers to the ECDSA private key in PEM format generated by the ECDSA key generator tool provided by RTK. This key is intended to be kept by users and used for ECDSA signing of their images.

4. ECDSA Public Key Hash: It refers to the SHA256 hash file in binary format that is generated by the ECDSA key generator tool. This file is intended to be kept by users and used for burning into eFuse. The secure bootloader will check whether the ECDSA public key hash matches with the ECDSA public key in the image header during image authentication.

Chapter Reading Guide

Users can refer to the different parts of this document as follows:

1. The secure EVB has already been bonded with the RTK default ECDSA key, so there is no need to burn any key hash into the EVB. Users only need to follow the instructions in Sign Images by Resign Tool to do the re-sign step with the default key.

2. The secure IC for MP, provided directly by RTK, has not been bonded with any ECDSA key. Users should refer to MP Flow for Secure-Enabled Chip to undergo the entire validation process.

3. If users need to convert the IC from a non-secure state to a secure state, skip to the chapter MP Flow for Secure-Enabled Chip to complete the whole validation process. The non-secure IC will be changed into a secure state once the ECDSA public key hash is burned into the eFuse.

Prerequisites

The images should be signed by the ECDSA private key, and the ECDSA public key hash should be burned on the eFuse. These operations depend on the related tools.

Toolset

First, please ensure that you have the following tools prepared:

• ECDSA Key Generator (v1.2 or above) for RTL87x3EP: This tool is used to generate the customer's own ECDSA key and public key hash.

• Re-sign Tool (v3.9 or above): This tool is used to re-sign images that require re-signing.

• MPPG Tool (version that supports RTL87x3EP):

  • Use the pack function under the tool menu of the MPPG Tool to pack the signed images.

  • Use the tool to download the packed signed images into flash.

  • Use the tool to burn the ECDSA public key hash into eFuse. Note that this step is only required once for each IC. The ECDSA public key hash can be written on the eFuse alone by bypass downloading packed images.

Images

Please prepare the images that need to be downloaded for the project. Note that data-type images are usually not authenticated by the ECDSA signature in the secure boot flow. Examples of data-type images include system config image, APP UI parameter image, DSP UI parameter image, and user data image. However, the authentication rules can be updated in the boot patch image, so which images require signatures may vary depending on the specific project.

Take the default images for the primary device provided in the bin directory of the RTL87x3EP SDK package as an example, there are 16 images listed below to be downloaded.

Images under the bank directory are shown in the following figure:

RTL87x3EP Images

Images generated by the MCUConfig Tool are shown in the following figure:

RTL87x3EP Configuration Images

The image type and image name mapping table for RTL87x3EP is shown in the following table:

RTL87x3EP Images Table

No.	Image Type	Image Name
1	System Config Image	SYSTEM_Config_xxxx.bin
2	Boot Patch 0 Image	boot_patch0_xxxx.bin
3	Boot Patch 1 Image	boot_patch1_xxxx.bin
4	Platform Extension Image	platform_ext_image_xxxx.bin
5	Bluetooth Controller Extension Image	lowerstack_ext_image_xxxx.bin
6	Bluetooth Host Image	upperstack_xxxx.bin
7	VP Data Image	VPData_xxxx.bin
8	OTA Header Image	OTAHeader_xxxx.bin
9	System Patch Image	sys_patch_xxxx.bin
10	Stack Patch Image	stack_patch_xxxx.bin
11	Application Image	app_xxxx.bin
12	Application UI Parameter Image	App_Config_xxxx.bin
13	DSP System Image	dsp_sys_image_xxxx.bin
14	DSP Application Image	dsp_app_image_xxxx.bin
15	DSP UI Parameter Image	dsp_config_image_xxxx.bin
16	Extension Image 0	ext_image0xxxxx.bin
17	User Data 1 Image	user_data1xxxxx.bin

MP Flow for Secure-Enabled Chip

The main purpose of validation on a secure chip is to establish a bond between the chip and an ECDSA key. Note that this process only needs to be done once for a new secure chip.

For a new secure chip, please guarantee the following four points:

1. Ensure there is a well-kept ECDSA key (e.g., default_ecdsa_key.pem) and its corresponding public key hash (e.g., default_ecdsa_key_hash.bin).

2. Public key hash should be downloaded into eFuse (note that this step can only be performed in MP mode of MPPG Tool).

3. The images that need to be re-signed should be re-signed.

4. Make sure the images that have been re-signed with the correct ECDSA key are downloaded into flash memory of the secure chip.

For a validated secure chip, please make sure the following two points:

1. The images that need to be re-signed should be re-signed with the correct ECDSA key.

2. The correctly signed images should be downloaded into flash.

Generate ECDSA Key and Key Hash by ECDSA Key Generator

ECDSA key generator tool is a Windows command-line tool.

Open the command window in the directory of tool\Gadgets\ecdsa_key_generator.exe and input the command:

ecdsa_key_generator.exe -g file_name

Then a key named file_name and its corresponding hash will be generated.

For example, if a key file named ecdsa_key is to be generated, just input the command as shown in the following figure:

ecdsa_key_generator.exe -g ecdsa_key

Generate ECDSA Key Pair and Public Key Hash

Three files will be generated in the current directory:

1. ecdsa_key.pem: It is the ECDSA private key needed by the re-sign tool to sign images. Keep this file secure and ensure it is properly backed up.

2. ecdsa_key.pub: It is an appendant ECDSA public key, which has no practical role for validation and can be ignored.

3. ecdsa_key.bin: It is the ECDSA public key hash file needed by the MPPG Tool to validate a new secure chip.

In addition to the ECDSA key generator tool, a default ECDSA key and its corresponding public key hash file are provided in the SDK and secure tool package by RTK.

Note

The default ECDSA key is provided for all SDK users by RTK. For customers in the development phase, the default ECDSA key can be used to validate secure chips quickly and reduce the risk of the chaos of key management caused by the generation of multiple keys. However, this ease of use will eliminate secure boot's security advantages. Therefore, it is strongly recommended that users use the tool to generate their own ECDSA key and hash in the MP stage and keep them safely to really protect their products.

Sign Images by Resign Tool

Re-sign tool is a Windows command-line tool. It's under the tool\Gadgets\resign_tool directory of the SDK. It can be used to re-sign a single image or all the images in a directory at one time.

Re-sign command line for a single image is as follows:

resign_tool.exe -f img_file.bin -k ecdsa_key.pem

Re-sign command line for all images in a directory command line is as follows:

resign_tool.exe -d resign_imgs_dir -k ecdsa_key.pem

The flow about how to re-sign images by the re-sign tool and ECDSA private key (generated in Generate ECDSA Key and Key Hash by ECDSA Key Generator) is described below:

1. Create a new directory named resign_image in the resign_tool_amd64_v3.9 directory.

2. Copy the images that need to be re-signed or all SDK images (refer to Images) to the resign_image directory.

3. Copy ecdsa_key.pem generated in Generate ECDSA Key and Key Hash by ECDSA Key Generator to the re-sign tool directory. Open the command window in this directory and input the command.

For RTL87x3EP, re-sign images in a directory as shown in the following figure:

RTL87x3EP Re-sign Images under the Directory

For RTL87x3EP, re-sign a single image as shown in the following figure:

RTL87x3EP Re-sign Single Image

Note

1. The file content and file name of images will change after being re-signed.

2. Some old versions of Windows systems may fail with the re-sign tool. If users encounter this problem, please refer to the usage document in the tool directory to solve it.

3. The re-sign tool v3.9 or above supports re-signing a single image or images in a directory for RTL87x3EP.

4. The re-sign tool may update in the future. Get the re-sign tool under tool\Gadgets\resign_tool directory of the SDK.

Pack Images by MPPG Tool

If the user only needs to enable the secure feature for the IC, and doesn't need to download the packed image in MP mode of MPPG Tool, ignore this part and skip to Download Public Key Hash by MPPG Tool.

In MP mode of MPPG Tool, only the packed images processed by the pack function can be downloaded. The image pack function is integrated in MPPG Tool under the menu Tool ‣ Pack. Using this tool, all images to be downloaded into flash can be packed into one file.

First, select the IC Series and IC Type on the MPPG Tool start page.

The flow of pack function is described below, taking RTL87x3EP pack images as an example:

1. Copy all the images (including images that do not need to be signed in SDK and images that have been re-signed) to a folder (e.g., imgs_for_pack) before packing.

2. Open the pack function integrated in MPPG Tool through the menu Tool ‣ Pack, and select For MP mode.

   

   Open Pack Image Function

3. Click the Load Flash Layout... button to load flash map.ini, e.g., RTL87x3EP-SDK-Vx.x.x.x\bin\flash_map_config\flash_4M.

   

   Load Flash Layout File

4. Choose Bank0 or Bank1 and click Add File(s) ... button to add all the images in imgs_for_pack directory. For different applications, the supported image types are different.

   

   Add Images to Pack

5. After the images are loaded in, the log window in the lower right corner will prompt whether the information such as images format, version, address, and so on has all passed by checking.

   

   Check Image Loading Log

6. Click Pack ... button to see the pack done prompt window.

   

   Pack Images

7. The packed image (image_pack_bank0-xxxxxxxxx.bin) will be generated in the selected directory.

   

   Generate Packed Image

Note

For validated secure chips (that is, ECDSA key hash has been downloaded into eFuse), packing images before downloading is not necessary. The RD mode provided by MPPG Tool can support single image downloading. Refer to MPPG Tool in Tool Set.

Download Public Key Hash by MPPG Tool

MPPG Tool is a Windows tool with a user interface. It is used to download images into flash. There are two modes in this tool: RD mode and MP mode. Please refer to the MPPG Tool User Guide for the specific usage of the two modes. This document will only describe how to download ECDSA key hash to eFuse in MP mode.

For RTL87x3EP, the power supply for the eFuse is dependent on the VBAT. Please make sure the VBAT is charged.

1. Before using MPPG Tool, make sure that the serial port of the device is connected properly and the system is in downloadable mode (aka HCI mode).

2. Open MPPG Tool, first choose the IC Series and IC Type, then click the Confirm button.

   

   Select Chip Type in MPPG Tool Startup Page

3. Click Type in the menu bar and choose MP mode.

   

   Select MP Mode

4. Switch to the MP_Settings interface, and the interface is inoperable at this moment. It is used to protect the setting against arbitrary modification.

5. Click the Unlock button and enter the password in the pop-up window to make the setting interface operable.

   The default unlock password is 1, and users can change the unlock password through the menu Settings ‣ Password Modify. If the user has forgotten the current unlock password, please refer to the UNLOCK_PASSWORD item under the UNLockSetting section in the MPPGToolSetting.ini under the MPPG Tool directory.

   

   Unlock Setting

   

   Input Password

   

   Password Modify Menu

   

   Modify Password

6. Select Write ECDSA Key SHA256 From File and load the ECDSA public key hash file. Select Only write key (bypass download image), then click Lock button. It's used to write the ECDSA public key hash only.

   

   Write ECDSA Public Key SHA256

   If the user wants to download the packed file together, don't select Only write key (bypass download image), and select the packed file, then click Lock button.

   

   Bypass Downloading Image and Only Write Key

7. Switch to the MP_Download interface, and click the Download button to write the public key hash into eFuse, if selecting the packet file, the images will be downloaded to the flash.

   

   Download

Note

For each secure IC, the ECDSA public key hash binary file can only be downloaded once. Repeated downloading will get an error prompt on the MPPG Tool.

FAQs

1. What is the meaning of the log wdt reset(3), sb = 1005, id = 0x2793, bk = 2, lr = 0x10f, sp = 0x2893a0? In the log, id = 0x2793 represents the image ID of the image validated currently. sb = 1005 represents the code line number of the fail operation.

   All the image ID values are as follows (not all image ID are used for RTL87x3EP, refer to Images):

   typedef enum _IMG_ID
   {
       IMG_OCCD        = 0x278E,
       IMG_BOOTPATCH   = 0x278F,
       IMG_OTA         = 0x2790, /* OTA header */
       IMG_SBL         = 0x2791,
       IMG_MCUPATCH    = 0x2792,
       IMG_MCUAPP      = 0x2793,
       IMG_DSPPATCH    = 0x2794,
       IMG_DSPAPP      = 0x2795,
       IMG_MCUDATA     = 0x2796,
       IMG_DSPDATA     = 0x2797,
       IMG_ANC         = 0x2798,
       IMG_EXT1        = 0x2799,
       IMG_EXT2        = 0x279A,
       IMG_EXT3        = 0x279B,
       IMG_PLATFORM    = 0x279C,
       IMG_LOWERSTACK  = 0x279D,
       IMG_UPPERSTACK  = 0x279E,
       IMG_FRAMEWORK   = 0x279F,
       IMG_SYSDATA     = 0x27A0,
       IMAGE_MAX
   } IMG_ID;
   
   typedef enum _PRE_IMG_ID
   {
       PRE_IMG_SYSPATCH         = IMAGE_MAX,
       PRE_IMG_STACKPATCH       = 0x27A2,
       PRE_IMG_UPPERSTACK       = 0x27A3,
       PRE_IMG_VP               = 0x27A4,
       PRE_IMAGE_MAX
   } PRE_IMG_ID;
   

   The line number of 1005 means ECDSA signature verification has failed, and the integrity checking for application image has failed. Maybe the application image on the flash has been modified.

2. What is the meaning of the log wdt reset(3), sb = 993, id = 0x2793, bk = 0, lr = 0x10f, sp = 0x2893a0? In the log, id = 0x2793 which represents the application image. sb = 993 indicates that the ECDSA public key hash verification has failed. User should check the application image has been downloaded to the specified flash address, and the image is signed with the correct ECDSA private key, then check whether the ECDSA public key hash has been burned on the eFuse.

3. What is the meaning of the log port 0, SHA Conflict Error ! in MPPG Tool during the download process of images in MP mode? This log indicates that an incorrect ECDSA key hash is tried to be burned into a secure chip which had already been bonded with another key hash.

4. What is the secure boot normal flow?

   

   Secure Boot Flow for RTL87x3EP

   For RTL87x3EP, there are two boot patch images, and without FSBL image.