Detailed explanation of Allwinner R128 RTOS security solution functions

aleksib

Detailed explanation of Allwinner R128 RTOS security solution functions [Copy link]

 

This chapter introduces the functions of the security solution under R128. The complete security solution is based on the standard solution extension, covering hardware security, hardware encryption and decryption engine, secure boot, secure system, secure storage and other aspects.

Configuration file related

This article involves some configuration files, which are explained here.

env*.cfg configuration file path:

board/<chip>/<board>/configs/env*.cfg

sys_config.fex path:

image_header.cfg path:

board/<chip>/<board>/configs/image_header.template.cfg

sys_partition*.fex path:

Features

The following security features are supported on the R128 FreeRTOS system:

Security Hardware

The following figure is a TrustZone-based SoC architecture reference implementation provided by ARM for M33 Star

When the CPU fetches instructions or accesses data, it enters the AHB bus with security attributes after being reviewed by the SAU and IDAU.

Since the SAU/IDAU mechanism is only applicable to the Arm M33 Star processor, the AHB device uses the following two methods to identify and respond to these accesses with security attributes:

1. The first is that the security attributes of the peripheral can be identified when it is designed;
2. The second type requires the help of other controllers, such as the PPC in the figure above. Developers set PPC to set different access rules for different peripherals. Similarly, MPC is used to set the security attributes of the memory area.

Some peripherals on R128 can identify security attributes, such as CE, DMA, etc. Most peripherals need to use SPC to configure their security attributes. PPC corresponds to SPC on R128, MPC corresponds to SMC on R128, TZMA corresponds to SPC on R128, and SMC on SMC on SMC.

Introduction to Arm M33 Star TrustZone

Arm M33 Star TrustZone is similar to the TrustZone of the Arm A series. In design, the processor has secure and non-secure states, and non-secure software can only access non-secure memory. Unlike the TrustZone technology in the Arm A processor, the Secure and Normal worlds of the Arm M33 Star are based on memory mapping, and the conversion occurs automatically in exception handling.

Security extension function

In addition to the ARM TrustZone security extension function, the R128 also implements some security hardware in the SoC design to ensure complete security features.

• SMC

The SMC configures the security attributes of the hspsram storage area. This module can be used only in a secure environment.

• TZMA

TZMA is used to configure the security attributes of lspsram, sram, spi flash, dsp sram, csi&vad sram address spaces.

Modules	size
TZMA0	128KB
TZMA1	128KB
TZMA2	256KB
TZMA3	256KB
DSP_TZMA0	256KB
EXPSRAM_TZMA	64KB
LPSRAM_TZMA	8MB
FLASH_TZMA	192MB

• SPC

SPC configures the security attributes of peripherals. This module can only be used in a secure environment.

• CE

CE is the hardware encryption and decryption engine of AW SoC, supporting algorithms such as AES/SHA/RSA.

• TRNG

TRNG is a true random number generator. The random source is 8 independent wake-up oscillators. The frequency jitter is generated by the power supply noise of the analog device, and it is resampled with a low-frequency clock. Then, elastic extraction and entropy extraction are performed, and finally a 128-bit true random number is output.

• SID/efuse

efuse: One-time programmable fuse technology is a type of OTP (One-Time Programmable) memory. The data inside efuse can only change from 0 to 1, not from 1 to 0, and can only be written once.

Secure ID controls the access to efuse. The access to efuse can only be performed through the sid module. Sid itself is non-secure, and both secure and non-secure can access it. However, when accessing efuse through sid, secure efuse can only be accessed by the secure world, and the result of access by the non-secure world is 0.

• Flash Encryption

The Flash Encryption module calculates AES for encryption when writing data to Flash and decrypts data when reading data from Flash. It supports AES real-time encryption and decryption when reading and writing data on SBUS and reading on CBUS. Only supported by Nor Flash.

• Secure Timer and Watchdog

Supports a set of safety timers and a set of safety watchdogs

Hardware encryption and decryption engine

CE: Crypto Engine, a hardware encryption and decryption module in AW SoC, supports multiple symmetric, asymmetric, and digest generation algorithms. It includes two sets of secure and non-secure interfaces.

The CE driver supports the following algorithms, but the encryption algorithms supported by the CE hardware encryption module are not limited to the following algorithms.

algorithm	support
AESECB128/192/256	√
AESCBC128/192/256	√
AESCTR128/192/256	√
AESOFB128/192/256	√
AESCFB8128/192/256	√
HASHMD5	√
HASHSHA1	√
HASHSHA224	√
HASHSHA256	√
HASHSHA384	√
HASHSHA512	√
RSA512	√
RSA1024	√
RSA2048	√

The specific CE interface can be found in CE | R128 Documents , and TRNG can be found in TRNG | R128 Documents . I will not go into details here.

Secure Boot

Secure firmware build

The packaging process and packaging format of secure firmware are similar to those of non-secure firmware. Only signature information is added to each image based on the original non-secure packaging method.

source envsetup.sh
lunch_rtos R128_xxx_m33
mrtos clean
mrtos_menuconfig # 开启CONFIG_COMPONENTS_TFM。注：非安全固件需关闭
mrtos
createkeys # 创建签名密钥，无需每次执行
pack s # 打包安全固件

After pack s is completed, the secure firmware is generated and located in the out directory. The file name is rtos_freertos_{BOARD}_uart0_secure_[8|16]Mnor_v[NUM].img. v[NUM] indicates the firmware version information, and NUM is the version number, which is determined by the secure firmware version number (see Section 4.7).

Before packaging secure firmware for the first time, you must run createkeys once to create your own signing key and keep the created key safe. A new key will be generated each time createkeys is executed, so you do not need to execute it every time unless you need to change the key.

Secure firmware configuration

Before packaging and generating secure firmware, you need to ensure that TFM is turned on. Execute mrtos menuconfig on the M33 core to enter the configuration main interface and perform the following configuration:

System components >
    aw components >
        TFM Support >
            [*] TFM support

Only secure firmware needs to start TFM, non-secure firmware needs to turn it off, and only M33 supports TFM.

Start the process

R128 contains three processors, namely M33 (ARM), C906 (RISCV), and HIFI5 (DSP). Only M33 supports security isolation.

Considering security, the system must be in a safe state when Brom starts, so M33 is selected as the startup core.

R128 uses different boot processes for NOR and NAND solutions. For NOR solution, the secure boot process is shown in the figure below. There is no uboot in the boot process, and boot0 directly boots the secure and non-secure OS, where brom, boot0, and S-OS are in the secure domain, and M33 N-OS, DSP OS, and RISC-V OS are in the non-secure domain.

EEWORLDLINKTK1

Signature Verification

R128 supports two signature verification methods, one is software ECC256 algorithm, the other is hardware SHA256RSA2048 algorithm. The default is SHA256RSA2048 algorithm. The specific signature verification method is configured in the board/R128s2/pro/configs/image_header.template.cfg configuration file. Select the specific signature verification algorithm as shown below:

"magic" : "AWIH",
"hversion" : "0.5",
"pversion" : "0",
"key_type" : "rsa", #rsa/ecc
"image" : {"max_size": "16384K"},

After configuring the signature algorithm key_type, when creating a key and executing createkeys, the corresponding key will be automatically generated according to the configuration file, and the corresponding signature verification algorithm will be used to sign the firmware package when executing the packaging command.

Chain of Trust

During the entire secure boot process of R128, the root public key hash in efuse is used as the starting point, and layer-by-layer verification is performed to ensure that each layer of firmware runs normally without tampering.

During the implementation process, each layer can use different signing keys to fully ensure security.

Burn rotpk.bin and secure enable bit

There are several ways to burn rotpk.bin and secure enable bit:

1. Use PhoenixSuit to burn the secure firmware. When the secure firmware is burned, the secure enable bit in efuse will be burned automatically.
2. Use efuse or TFM console command to burn rotpk.bin into the efuse of the device. For the specific operation method, see Section 5.5 TFM Usage Examples.

3. When the secure firmware is burned, parse the secure firmware to get rotpk.bin and write it into efuse, and then set the secure enable bit in efuse to 1. (This method requires the macro CONFIG_SUNXI_BURN_ROTPK_ON_SPRITE=y to be enabled in uboot)

4. For Nand solution, Dragon SN tool is supported to burn rotpk.bin into the efuse of the device.

The hardware characteristics of efuse determine that each bit in efuse can only be programmed once. In addition, efuse is divided into many areas, and most areas can only be programmed once. For details, please refer to the chip SID specification.

After programming the secure enable bit, the device will become a secure device. This operation is irreversible. In the future, only secure firmware can be started, and non-secure firmware cannot be started.

If both the secure enable bit and rotpk.bin are burned, the device can only boot the secure firmware signed with the key corresponding to rotpk.bin; if only the secure enable bit is burned without rotpk.bin, any secure firmware burned on this device can be started. During debugging, only the secure enable bit can be burned, but rotpk.bin must be burned before the device leaves the factory.

Anti-rollback

R128 supports preventing firmware version rollback. During the packaging process, the version information corresponding to pversion in the configuration file image_header.template.cfg will be added to the Image Header of the image.

During the boot process, brom reads the version information in the sboot image header before sboot verification, and compares the version information with the version information saved in the NV area in efuse:

• If the version information in efuse is higher, sboot0 will not be started, and brom will switch to fel for burning.

• If the efuse version is less than or equal to the version in the Image Header, continue to load sboot and verify.

During the sboot startup process, if the efuse version is found to be smaller than the version in the Image Header, this version information will be written to the NV area in the efuse.

The security firmware supports updating up to 32 versions.

Safe mass production method

Support three mass production methods:

1. Use LiveSuit/PhoenixSuit to burn secure firmware, and automatically burn secure bit when firmware burning is completed. After booting, provide console command method to burn rotpk.
2. Offline secure firmware mass production mode, save both secure and non-secure boot0 on flash, the first boot, non-secure boot0, write secure bit in non-secure boot0, restart; the second boot, secure boot0, normal secure boot. rotpk can be written in non-secure boot0, or in the console.
3. For Nand solution, Dragon SN tool is supported to burn efuse, so secure bit can be burned automatically when LiveSuit/PhoenixSuit is used to burn secure firmware, and rotpk can be burned through Dragon SN tool after startup.

Security System

Software system architecture

There is only one secure OS in the R128 system, namely the SOS running on the M33. If other RISCV/DSP need to access secure resources, they will call the M33 NOS across cores, and the M33 NOS will then call the resources of the SOS.

EEWORLDLINKTK2

TFM includes:

• Secure boot. Used to verify the integrity of the NSPE/SPE image.
• TFM Core. Responsible for controlling the isolation and communication between SPE and NSPE.
• Security services, including ITS (Internal Trusted Storage), PS (Protected Storage), etc.

Source code structure

The TFM API interface for non-secure environment calls is placed in the components/aw/tfm directory under M33 rtos. Before compiling the secure M33 RTOS, configure CONFIG_COMPONENTS_TFM to compile the NSC-related API into the M33 RTOS image.

TFM Interface

The non-secure end calls the incoming non-secure end API interface pointer pxCallback

Function prototype

uint32_t tfm_sunxi_nsc_func(Callback_t pxCallback);

parameter:

• pxCallback: non-secure API interface pointer

return value

• The number of times the function was called

Calling Instructions: This function is used for secure and non-secure interaction testing. After calling this function on the non-secure side, it will switch to the secure side. The function will call the passed non-secure side API interface pointer on the secure side.

Burn key_data with a length of key_bit_len to the corresponding secure efuse area according to the given key_name

Function prototype

int tfm_sunxi_efuse_write(char key_name, unsigned char key_data, unsigned int key_bit_len);

parameter:

• key_name: the region name corresponding to efuse
• key_data: data to be burned into efuse
• key_bit_len: length of the data to be burned into efuse

return value

• 0: Success
• Negative number: Failure

Perform encryption and decryption operations on the security end

Function prototype

int tfm_sunxi_aes_with_hardware(crypto_aes_req_ctx_t *aes_ctx);

parameter:

• aes_ctx: crypto_aes_req_ctx_t structure pointer

return value

• Just returns 0: meaningless

Calling instructions: Before calling, please pay attention to the corresponding cache operation of the data key required for encryption and decryption

Set the nonce value required for flashenc on the secure side

Function prototype

void tfm_sunxi_flashenc_set_nonce(uint8_t *nonce);

parameter:

• nonce: nonce value, a total of 6 bytes.

return value

• none

Enable/disable flashing of a specific channel

Function prototype

void tfm_sunxi_flashenc_enable(uint8_t id)/tfm_sunxi_flashenc_disable(uint8_t id);

parameter:

• id: channel index

return value

• none

Setting up flash

Function prototype

void tfm_sunxi_flashenc_config(uint8_t id, uint32_t saddr, uint32_t eaddr, uint32_t *key);

parameter:

• id: channel index
• saddr: set the starting address
• eaddr: the end address of the setting
• key: encryption key

return value

• none

Set the flashenc encryption key

Function prototype

void tfm_sunxi_flashenc_set_key(uint8_t id，uint32_t *key);

parameter:

• id: channel index
• Encryption Key

return value

• none

Set flashenc encryption address range

Function prototype

void tfm_sunxi_flashenc_set_region(uint8_t id, uint32_t saddr, uint32_t eaddr);

parameter:

• id: channel index
• saddr: set the starting address
• eaddr: the end address of the setting

return value

• none

Set ssk in efuse as the encryption key for flashenc

Function prototype

void tfm_sunxi_flashenc_set_ssk_key(uint8_t id);

parameter:

• id: channel index

return value

• none

Jump to TFM security space and use SSK as the key for AES encryption

Function prototype

void tfm_sunxi_aes_encrypt_with_hardware_ssk(uint8_t dst_addr, uint8_t src_addr, int len);

parameter:

• dst_addr: encrypted data storage address
• src_addr: encrypted data storage address
• len: encrypted data length

return value

• none

Dump the value of the corresponding address

Function prototype

void tfm_sunxi_hexdump(const uint32_t *addr, uint32_t num);

parameter:

• addr: starting address
• num: the number of words to dump

return value

• none

Print out the current sau configuration information

Function prototype

 void tfm_sunxi_sau_info_printf(void);

parameter:

• none

return value

• none

Read register value

Function prototype

 uint32_t tfm_sunxi_readl(uint32_t reg);

parameter:

• reg: register address

return value

• Register Value

Write register value

Function prototype

void tfm_sunxi_writel(uint32_t reg, uint32_t value);

parameter:

• reg: register to be written
• value: the value to be written

return value

• none

Read efuse content

Read efuse content function prototype

int tfm_sunxi_efuse_read(char key_name, unsigned char key_data, size_t key_bit_len);

parameter:

• key_name: the region name corresponding to efuse
• key_data: stores the data read from efuse
• key_bit_len: length of the read data

return value

• Negative number: function execution error
• Positive number: the number of bits actually read

TFM Enable Configuration

In the RTOS environment, the M33 core executes mrtos menuconfig to enter the configuration main interface and perform the following configuration:

System components >
    aw components >
        TFM Support >
            [*] TFM support #TFM驱动
            [*] TFM test demo #TFM测试代码

R128 provides four TFM test demos, including tfm_demo, tfm_crypto_demo, tfm_efuse_write and tfm_efuse_read, which are used to test secure and non-secure interactions, non-secure calls to secure encryption interfaces, and reading and writing efuse content (reading and writing efuse requires enabling the efuse driver DRIVERS_EFUSE).

The TFM interface and test demo provided in are located in the lichee/rtos/components/aw/tfm directory.