RISC-V dual-core TEE security system and method integrated with lightweight ASCON engine

Abstract

The invention discloses an RISC-V dual-core TEE security system and method integrated with a lightweight ASCON engine. The system adopts a three-stage physical bus isolation architecture, wherein a first-stage AHB is exclusively accessed by a security core (TEE), so that physical isolation of a BootROM and a starting program is realized; the second-stage AHB constrains the access authority of a non-secure kernel (REE) through a dynamic IOPMP firewall and supports cascade extension of multi-stage storage domain table entries, a CFG register defines configurable authority granularity, and an ADDR register realizes dynamic combination of a base address and an offset mask; and the third-stage bus separates peripheral resources through the secure / non-secure APB bridge. A lightweight cryptographic engine is innovatively integrated, authentication encryption, decryption verification and hash abstract are supported, and the side channel attack resistance is enhanced through time sequence jitter and power consumption balance. A randomized base address and a real-time decryption verification mechanism are adopted in the safe starting process, and the starting efficiency is remarkably improved. The system effectively resists side channel attacks in the scene of the Internet of Things, and the inter-core communication performance and the resource utilization rate are optimized.

Description

Technical Field

[0001] This invention relates to the field of embedded system security technology, specifically a security system and method for a dual-core Trusted Execution Environment (TEE) based on the RISC-V architecture, particularly suitable for resource-constrained IoT terminal devices. Hardware-level security protection and energy efficiency optimization are achieved through a co-design of a physically isolated bus architecture and a lightweight ASCON cryptographic engine. Background Technology

[0002] In the field of embedded system security, current mainstream technologies suffer from significant performance bottlenecks and security shortcomings. The traditional ARM TrustZone architecture employs a time-division multiplexing bus mechanism, requiring a latency of over 500ns for switching between the secure and insecure worlds (based on actual test data from Xilinx Zynq-7020), resulting in a performance loss of over 30% in high-real-time application scenarios. This frequent switching mechanism leads to severe throughput degradation in high-concurrency IoT scenarios.

[0003] Meanwhile, Internet Address Access Firewalls (IOPMP) generally employ a static rule configuration model, making them unable to dynamically respond to emerging threats such as zero-day vulnerability attacks. Fixed address permission policies create security blind spots when encountering attack vector mutations; for example, malicious code can bypass fixed address rules and tamper with critical registers. Furthermore, traditional Chinese cryptographic algorithm hardware modules (such as SM2 / SM4) consume over 15K LUTs of resources. When deployed in resource-constrained IoT terminals, this forces developers to compromise between security strength and device energy efficiency, severely hindering the widespread application of lightweight security chips. Summary of the Invention

[0004] To address the aforementioned issues, this invention provides a RISC-V dual-core TEE security system and method integrating a lightweight ASCON engine. It comprises six core components: a three-level physical isolation bus architecture, a dynamic IOPMP firewall, a lightweight cryptographic engine, a secure boot chain, a dual-channel inter-core communication mechanism, and a peripheral resource isolation module. Each component is interconnected via a dedicated bus to form a closed-loop security protection system.

[0005] This architecture completely eliminates the performance bottleneck of traditional time-sharing multiplexing through hardware-level signal isolation design. The secure isolation layer bus allows the secure processor core to exclusively access the boot memory module and secure boot unit, achieving physical-level execution environment isolation. The resource sharing layer bus enables controllable sharing of secure domains through dynamic access control, and the mounted encryption engine unit provides the system with core cryptographic computing capabilities.

[0006] The dynamic IOPMP firewall is a scalable access control hub, featuring a programmable table structure and a real-time response mechanism. The table structure supports multi-level memory domain management and dynamic address range configuration, defining fine-grained permission levels through the CFG register and dynamically setting protected area boundaries through the ADDR register. The real-time response mechanism automatically switches rules when a set threshold is met during bus idle periods, and the permission conflict arbiter uses a hardware-level logic gate array for efficient decision-making.

[0007] The lightweight cryptographic engine integrates an authentication and encryption module, a decryption and verification processing unit, and a hash digest generator into a single functional unit. The authentication and encryption module employs a side-channel attack resistant design, using a timing randomization controller to balance the power consumption characteristics of the operation; the decryption and verification unit implements real-time tag verification to ensure data immutability; and the hash digest module supports data compression output of arbitrary length.

[0008] The secure boot chain constructs a hardware-level root of trust verification mechanism, including a root of trust verification unit, a dynamic loading mechanism, and an address randomization component. The root of trust verification unit performs self-checks and integrity verification of the boot code, and verifies the root of trust digest value in real time through a cryptographic engine. The dynamic loading mechanism enables secure transmission and real-time decryption of the encrypted image, and the address randomization component generates discrete boot addresses, effectively defending against fixed-location injection attacks.

[0009] The inter-core communication dual-channel mechanism consists of a dedicated command transmission channel and a bulk data transmission channel. The command channel employs a low-latency design, suitable for control command transmission; the data channel supports high-capacity secure transmission, achieving intelligent strategy selection through a data feature analysis unit. The adaptive transmission protocol automatically switches processing modes based on data type: control signals are transmitted directly, configuration parameters undergo hash authentication, and sensitive data is protected by encryption.

[0010] The peripheral resource isolation module establishes a terminal security defense line, including a secure peripheral access controller and a non-secure peripheral connection channel. An access permission verifier monitors bus access requests in real time, and the hardware blocking execution unit immediately triggers a protection mechanism upon detecting unauthorized operations, generating a specific error code and interrupting the illegal access process. This physical isolation design eliminates the risk of inter-chip bus exposure at the hardware level.

[0011] The six core components work together through a three-level bus architecture: the secure boot chain initializes the trusted state of the system, the cryptographic engine provides secure computing services, the inter-core communication mechanism ensures secure data interaction, the IOPMP firewall dynamically adjusts access policies, and the peripheral isolation module implements terminal protection, forming a complete hardware-level security closed loop. Attached Figure Description

[0012] Figure 1 This is a diagram of a RISC-V dual-core TEE security system architecture integrating a lightweight ASCON engine.

[0013] Figure 2 It is a dual-core TEE SoC system technology roadmap that integrates a lightweight ASCON engine into a RISC-V dual-core TEE security system.

[0014] Figure 3 It is a trusted chain of a RISC-V dual-core TEE security system that integrates a lightweight ASCON engine.

[0015] Figure 4 It is a dual-core isolated extension technology route for a RISC-V dual-core TEE security system that integrates a lightweight ASCON engine.

[0016] Figure 5 It is the PMU of a RISC-V dual-core TEE security system that integrates a lightweight ASCON engine.

[0017] Figure 6 It is a command mailbox module structure of a RISC-V dual-core TEE security system that integrates a lightweight ASCON engine.

[0018] Figure 7 It is a data mailbox module structure of a RISC-V dual-core TEE security system that integrates a lightweight ASCON engine.

[0019] Figure 8 This is a schematic diagram of the ASCON cryptographic engine in a RISC-V dual-core TEE security system that integrates a lightweight ASCON engine.

[0020] Figure 9 This is a schematic diagram of the summary extraction module of a RISC-V dual-core TEE security system that integrates a lightweight ASCON engine.

[0021] Figure 10 This is a schematic diagram of the encryption module of a RISC-V dual-core TEE security system that integrates a lightweight ASCON engine.

[0022] Figure 11 This is a schematic diagram of the decryption module of a RISC-V dual-core TEE security system that integrates a lightweight ASCON engine.

[0023] Figure 12 It is an access security check module for a RISC-V dual-core TEE security system that integrates a lightweight ASCON engine.

[0024] Figure 13 It is the IOPMP main configuration module of a RISC-V dual-core TEE security system that integrates a lightweight ASCON engine.

[0025] Figure 14This is the overall design diagram of the flash controller of a RISC-V dual-core TEE security system integrating a lightweight ASCON engine. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to the embodiments and accompanying drawings.

[0027] This invention utilizes a RISC-V processor (E902) to design a minimal system supporting TEE, building a secure prototype of TEE for the RISC-V processor. It extends the secure core to construct a dual-core TEE secure architecture, where one E902 core serves as the secure core, running Secure World (TEE) programs, and the other E902 core serves as the non-secure core, running Unsecured World (REE) programs. This dual-core approach achieves physical isolation of the CPU.

[0028] Design an IOPMP (Physical Address Access Firewall) to ensure that the master device in the insecure world (including insecure CPUs and insecure peripherals) cannot access resources in the secure world, including memory and MMIO.

[0029] Communication between the E902 secure core and the non-secure core requires the use of a Mailbox device.

[0030] The system implements a secure boot scheme. To start the secure CPU core, the software image needs to be validated for legitimacy and securely configured before the non-secure CPU core can be started.

[0031] I. Technical Approach

[0032] By physically isolating the secure kernel from the insecure kernel, the encryption and decryption operations within the secure space are isolated from the system software and application software under the REE, thus creating an isolated execution environment. However, the software programs running on the processor in the isolated environment are not necessarily trustworthy and may be tampered with, which means that the secure kernel is not necessarily secure. Therefore, we implemented secure boot, established a root of trust, and built a chain of trust, thereby turning the isolated environment into a trustworthy execution environment.

[0033] The technical approach and related extended components involved in the design, such as Figure 2 As shown.

[0034] For secure boot, we establish a core trusted metric root with Bootrom as the basis for trust.

[0035] After the Bootrom starts, it uses the ASCON cryptographic algorithm to measure the integrity of the Bootcode, TEE application, and REE application step by step, according to the system startup sequence. Integrity measurement involves calculating hash values ​​for features related to program integrity. The hash values ​​stored in the secure area are continuously expanded through iterative calculations, and finally, integrity verification is performed to determine whether the platform's state is trustworthy. This constructs a trusted chain from Bootrom to TEE to REE.

[0036] For isolation protection, we have expanded the original Wujian 100SOC single core with a security core (processor E902) and implemented bus isolation to build a new first-level bus. Through the bus architecture, we integrate the security processor core, Bootrom, instruction RAM, data RAM and ASCON cryptographic engine, etc., and connect it as the master device to the second-level bus connected to the non-security core to achieve physical isolation.

[0037] For dual-core communication, a Mailbox mechanism is established and access security attributes are extended. To effectively control and hierarchically manage the insecure core, an independent power supply system is designed, with the secure core controlling the startup of the insecure core according to the startup sequence. To restrict the insecure core's access to certain peripherals or storage areas, a hardware address firewall IOPMP is designed to isolate the secure and insecure cores' external access, while also restricting IOPMP access to SRAM. It also enables fine-grained hierarchical security partitioning and reconfigurable operations to ensure interactive security.

[0038] II. Secure SoC Architecture (I) Dual-core Isolated Secure SoC Architecture Based on Wujian100

[0039] Based on the Wujian100SoC open-source platform, a dual-core secure SoC is built, with the system architecture as follows: Figure 1 As shown.

[0040] This security system mainly consists of two isolated parts: the isolation between the secure kernel and the non-secure kernel, and the isolation between the non-secure kernel and peripherals, some memory, and other resources.

[0041] The secure core and the non-secure core are isolated by physical isolation. That is, the secure core has independent bus, memory and I / O resources, thus forming the TEE, while the non-secure core and its related resources form the non-secure area REE.

[0042] The secure core and the non-secure core communicate only through the Mailbox module mounted on the secondary bus, and data exchange is achieved through shared memory.

[0043] The isolation of peripheral resources and some memory resources is achieved by using IOPMP to build a "firewall" for resource access, preventing REE from accessing and controlling protected memory, MMIO and peripherals.

[0044] (II) Isolated Execution Environment

[0045] 1. Dual-core isolation

[0046] The design adopts a homogeneous dual-core architecture, with both processors using the XuanTie E902 core.

[0047] ZYNQ's ARM dual-core design shares a portion of memory space through DDR3. Although the address spaces of the two cores are divided, unauthorized users can still access the memory area of ​​the other core through methods such as memory overflow.

[0048] To prevent unauthorized users from accessing secure area resources through non-secure kernels, we integrated the security processor and related components through a new AHB bus and connected it as a master device to the next level bus, achieving bus isolation and eliminating access to and modification of secure resources by non-secure kernel system software and application software.

[0049] 2. Mailbox inter-core communication

[0050] One method to achieve synchronization and communication between two processor cores is through a message mailbox and inter-core interrupts. A set of message mailbox registers and interrupt registers allows for the exchange of commands or short messages between cores. During startup, processor polling can also be used to achieve inter-core synchronization to simplify the process.

[0051] For the transmission of big data, dual-core processes can communicate by reading and writing through a shared storage area according to an agreed-upon interaction protocol. Here, it is necessary to solve the restriction on read and write permissions for the secure core and the insecure core. That is, one part is designated as the writable area of ​​the secure core and the read-only area of ​​the insecure core; the other part is designated as the writable area of ​​the insecure core.

[0052] (III) Trusted Execution Environment

[0053] 1. Root of Trust and Chain of Trust

[0054] The entire system startup process includes bootcode, TEE application, and REE application. The bootcode in the bootrom is used as the root of trust, and verification is performed step by step from the bootcode to the REE application.

[0055] Trusted link transmission in the system, such as Figure 3 As shown.

[0056] The Trusted Chain (TCG) is centered on the TEE security core and starts with the Bootcode, assuming absolute trustworthiness. The TCG defines three roots of trust: the Root of Trust for Measurement (RTM), the Root of Trust for Storage (RTS), and the Root of Trust for Report (RTR). The RTS and RTR are stored in an immutable trusted security chip. In this design, the RTM is the measurement value of the Bootcode stored in the BootROM, while the RTS consists of the Platform Configuration Register (PCR) and encryption / decryption keys within the trusted security chip.

[0057] 2. Safe Start

[0058] This design offers two startup methods:

[0059] First, the REE application and TEE application are downloaded to the corresponding instruction RAM and data RAM respectively via JTAG. After the bootrom starts, the TEE program is run, and finally the REE application is run.

[0060] Secondly, the REE and TEE applications are downloaded to the Flash memory respectively. After the bootrom starts, it loads the REE and TEE programs and performs integrity measurement and encryption / decryption operations, ultimately completing the same process as the first one.

[0061] 3. Security services provided by TEE

[0062] After building a trusted execution environment based on dual cores, users can be provided with a number of security services, including cryptographic services, secure storage services, and secure peripherals.

[0063] The cryptographic service is mainly implemented through the hardware-based ASCON cryptographic engine, which provides symmetric encryption of data, digest extraction, digest generation, and data authentication.

[0064] Secure storage primarily ensures the security of the keys used for encryption and decryption. This is a secure environment based on bus isolation. It uses dedicated hardware storage blocks within the secure zone to store key information and other critical user information, effectively overcoming the shortcomings of traditional data encryption systems, namely, that key data stored in external storage is easily stolen or destroyed.

[0065] Security peripherals are implemented by adding an access rule checking module for REEs (Remote Access Providers) to the SOC's bus communication architecture; this is essentially an address-based hardware firewall, IOPMP. This restricts or monitors read and write operations to peripherals or memory by non-secure kernels.

[0066] 3.1 ASCON Cryptographic Engine

[0067] The ASCON cryptographic engine is an encryption algorithm core that integrates multiple cryptographic algorithms. The computation engine includes three algorithms from the ASCON algorithm family: authentication encryption, decryption, and digest extraction. The ASCON computation engine designed in this competition integrates a standard AHB interface and is mounted on the AHB-isolated bus.

[0068] 3.2 IOPMP

[0069] In the platform, the master station on the bus can access the slave devices, just like on the RISC-V bus.

[0070] Introducing I / O peripherals such as DMA (Direct Memory Access Unit) can improve system performance, but it can also expose the system to vulnerabilities such as DMA attacks.

[0071] This design uses the Physical Memory Protection Unit (IOPMP) of the input / output device to regulate access from the bus host.

[0072] IOPMP functions similarly to a hardware firewall. This design primarily utilizes the communication architecture of integrated SOC components, such as the AHB / APB bus, designing two types of IOPMPs at the source and destination ends. The source end (SIOPMP) is located closer to the master device, and the destination end (DIOPMP) is located closer to the slave device. IOPMPs are distributed between MMIO or SRAM and the bus interface, restricting read and write operations on non-secure kernel resources.

[0073] III. Hardware Design and Main Module Introduction of the Security SoC System

[0074] 1. Dual-core isolated extension

[0075] On the existing Wujian 100SOC single-core architecture, a new AHB bus is added as the master device to connect to the original first-level bus (hereinafter referred to as the second-level bus). The new first-level bus integrates various components and only provides the bus output interface to the outside, forming a secure TEE. This makes it impossible for the outside to interfere with the execution of the modules inside the TEE.

[0076] Meanwhile, to ensure safe startup, a power management unit independent of the REE was designed; and to address many issues with program execution in the AMP asymmetric multi-core processing mode under dual-core conditions, some structures in the E902 kernel were modified.

[0077] Dual-core isolated expansion technology route such as Figure 4 As shown.

[0078] 1.1 Bus and Interface Isolation

[0079] Bus isolation hardware design mainly consists of bus design, address mapping space reallocation, and peripheral expansion.

[0080] The AHB bus structure in the Wujian 100SoC has been simplified, removing some redundant dummy slave / master components. The security processor core (Xuantie E902), BootRom, IRAM, DRAM, and ASCON cryptographic engine are integrated through the standard communication bus AHB.

[0081] The address mapping of the primary bus and the secondary bus is reallocated. The address mapping on the REE bus starts from address 0x9000_0000 to 0x9000_FFFF. The address space is allocated without changing the original address space of the REE bus and the tight IP space in the core.

[0082] In the peripheral section, a JTAG interface was added for early-stage security kernel verification.

[0083] 1.2 Independent Power Management Unit

[0084] This design adds a Power Management Unit (PMU) independent of the non-safety core. It is controlled only by the safety core. Through the PMU, the safety core can enable or disable the non-safety core at any time. Its main function is to ensure that the safety core can only be started via the PMU after the REE program integrity verification during safe startup. The PMU unit is designed as follows: Figure 5 It is mounted on the APB bus and consists of an APB security adapter, a configuration register, and a reset and clock signal control unit.

[0085] 1.3 Randomized Startup Address

[0086] After bus isolation is performed, the address mapping of the instruction RAM of TEE and REE is different, which is related to the linker script in the SDK compilation.

[0087] The MEMORY command in the linker script defines the memory space, which is the physical address space of the actual instructions.

[0088] Since the non-secure core initializes its PC starting from 0x0000_0000 after being woken up, but because the address mapping of the REE instruction RAM is 0x9000_0000, the non-secure core cannot access the correct instruction address space after being woken up.

[0089] Therefore, we modified the relevant signals for PC reset of E902. The reset PC value and the mapping range of IRAM address space on the bus can be configured through the start address register of the PMU unit. By generating an address that conforms to the bus address mapping rules and space partitioning in software, the start address and access space of REE can be randomized to a certain extent, which increases the difficulty of illegally tampering with software instructions.

[0090] 2. Mailbox module

[0091] Mailbox is designed to achieve two functions: first, to enable separate access to commands and data; and second, to restrict access permissions for dual-core security.

[0092] First, based on the different types of access messages, it is divided into command mailbox module and data mailbox module, which physically distinguishes commands and data; second, the command and data mailbox modules are further subdivided into modules for access from the secure core to the non-secure core and modules for access from the non-secure core to the secure core according to access permissions, which ensures that different hosts have different access permissions from the physical interface, thereby ensuring the information security of inter-core communication.

[0093] The command mailbox module is divided into a command mailbox module for secure kernels to non-secure kernels and a command mailbox module for non-secure kernels to secure kernels, depending on the access permissions. Both modules consist of an AHB bus interface component and a command mailbox component, and each has its own independent AHB bus interface. The structural difference is that the access permissions for different hosts are different, while the rest of the structure is the same.

[0094] The command mailbox module structure is as follows: Figure 6 As shown.

[0095] The data mailbox module is divided into a secure core-to-non-secure core data mailbox module and a non-secure core-to-secure core data mailbox module, based on different access permissions. Both modules consist of an AHB bus interface component and a data mailbox component. The structural difference lies in the different access permissions granted to different hosts; all other structural aspects are identical.

[0096] The data mailbox module structure is as follows: Figure 7 As shown.

[0097] 3. ASCON cryptographic engine module

[0098] The ASCON cryptographic algorithm requires obfuscating and spreading the input data. Therefore, each subsequent operation depends on the result of the previous operation. This algorithm structure means that the digest extraction and encryption / decryption processes cannot be performed in parallel to improve efficiency. Instead, efficiency can only be improved by shortening the combinational logic path and thus increasing the frequency. To facilitate flexible cutting of critical paths, handshake signals are added to the data path to control the algorithm. This allows for flexible changes to the path delay of the combinational logic while keeping the control logic unchanged.

[0099] The ASCON cryptographic engine encapsulates each independent algorithm module into a single module, facilitating future expansion. The schematic diagram of the ASCON cryptographic engine is shown below. Figure 8 As shown.

[0100] 3.1 Summary Extraction Module

[0101] The principle diagram of the abstract extraction module is as follows: Figure 9 As shown.

[0102] The digest extraction algorithm mainly consists of three steps: initialization, information absorption, and compressed hashing.

[0103] (1) The initialization step is to integrate configuration information and provide an initial data flow.

[0104] (2) The information absorption step is to diffuse and confuse the information to be extracted from the summary.

[0105] (3) The compression hashing step is to extract a digest from the processed data stream.

[0106] The controlled architecture section is the core of the algorithm and also the data path in the digital circuit. Since the information obtained from the initialization of the digest extraction algorithm is fixed, the result is directly calculated in advance and fixed through assignment statements, and merged with the information absorption component, thereby reducing hardware overhead and latency. The receive data buffer, with a size of 512B, is used to store the data to be extracted into the digest and is controlled by the state machine to input data into the information absorption component. The control register group is used to store the configuration signals of the algorithm, and the configuration signals are used as external inputs to control the behavior of the state machine. The transmit digest buffer, with a size of 512B, is used to store the digest after extraction and is controlled by the state machine to extract the digest from the compressed hash component.

[0107] 3.2 Encryption Module

[0108] The schematic diagram of the encryption module is as follows Figure 10 As shown.

[0109] The encryption algorithm mainly consists of four steps: initialization, data association, plaintext encryption, and tag extraction.

[0110] (1) The initialization step is to integrate configuration information and password information to provide an initial data stream;

[0111] (2) The data association step is to integrate the association information into the encrypted data stream;

[0112] (3) The plaintext encryption step is to encrypt the plaintext and output it;

[0113] (4) The tag extraction step involves extracting tags from the plaintext, similar to a digest, which are used during decryption to compare with the tags extracted during decryption.

[0114] The signatures are compared to verify the correctness and completeness of the data.

[0115] The controlled architecture is the core of the algorithm and also the data path in the digital circuit. The controlled framework in the diagram consists of four parts, corresponding one-to-one with the four steps in the encryption algorithm: The receive plaintext buffer, 1KB in size, stores the plaintext to be encrypted and is fed into the plaintext encryption component via a state machine; the control register group stores the algorithm's configuration signals and cryptographic information, such as association information, keys, and random numbers, with the configuration signals acting as external inputs to control the state machine's behavior; and the send ciphertext buffer, 1KB in size, stores the encrypted ciphertext and is extracted from the plaintext encryption component via a state machine.

[0116] 3.3 Decryption Module

[0117] The schematic diagram of the decryption module is as follows: Figure 11 As shown.

[0118] The decryption algorithm mainly consists of four steps: initialization, data association, ciphertext decryption, and tag extraction.

[0119] (1) The initialization step is to integrate configuration information and password information to provide an initial data stream;

[0120] (2) The data association step is to integrate the associated information into the decrypted data stream;

[0121] (3) The ciphertext decryption step is to decrypt the ciphertext and output the plaintext;

[0122] (4) The tag extraction step is to extract tags from the ciphertext and compare them with the tags generated during encryption to verify the correctness and integrity of the data.

[0123] The controlled architecture is the core of the algorithm and also the data path in the digital circuit. The controlled framework in the diagram consists of four parts, corresponding one-to-one with the four steps in the decryption algorithm: The receive ciphertext buffer, 1KB in size, stores the ciphertext to be decrypted and is fed into the ciphertext decryption component via a state machine; the control register group stores the algorithm's configuration signals and cryptographic information, such as association information, keys, and random numbers, with the configuration signals acting as external inputs to control the state machine's behavior; and the send plaintext buffer, 1KB in size, stores the decrypted plaintext and is extracted from the ciphertext decryption component via a state machine.

[0124] 4. IOPMO Design

[0125] IOPMP primarily utilizes the communication architecture of integrated SoC components, such as the AXI / APB bus. It designs two types of IOPMP at the source and destination ends: the source end refers to the side closer to the master device, and the destination end refers to the side closer to the slave device. IOPMP is distributed between MMIO or SRAM memory and the bus interface, restricting read and write operations on non-secure access resources.

[0126] 4.1 Access Security Check Module

[0127] Access security check module such as Figure 12 As shown.

[0128] (1) Control section. The core of the control section is the state machine. The control section of IOPMP at the source end and the destination end is the same.

[0129] The IDLE state is the idle mode, which initializes the system and waits for the function to start. When the permission check function is enabled, it enters the RULECHECK state.

[0130] The RULECHECK state monitors the data flowing through the bus architecture. When configuration is enabled, it enters the CONFIGWAIT state.

[0131] The CONFIGWAIT state is in a state of waiting for configuration. During this state, the IOPMP check rules and address-related registers have been reset. However, if a data transfer on the bus is not complete, it will wait and continue to use the old rules for checking. Once a bus transfer is complete, it will block further data transmission, and IOPMP will enter configuration mode.

[0132] In the CONFIGSTART state, IOPMP begins updating the check rules and address information. Once the update is complete, it will return to RULECHECK, and the bus will resume normal operation. If the check is turned off, it will return to IDLE mode and wait to be turned on.

[0133] (2) Execution rule check section. This part is the IOPMP data path, and the source and destination IOPMP are different.

[0134] In the source-side IOPMP, access from the non-secure core master device to the bus, and from the non-secure core to the bus slave device, all require security checks by the source-side IOPMP. Since the address mapping of each component on the bus is fixed after the SoC design, the source-side IOPMP fixes the address mapping range of the slave device. It first performs address matching to obtain the peripheral type and related permissions accessed by the REE master. Then, it compares the read / write operation with the access permissions. If the permissions are met, access is granted and data is sent to the bus; otherwise, the access fails and an error message is returned.

[0135] The destination IOPMP is located between the APB bus and the protected peripheral. The destination hardware firewall inspection module is divided into register-based address partitioning and memory-based address partitioning. The inspection module uses the prot signal to unrestrict access from the TEE, bypassing the permission check logic; for access from the REE, it first calculates the restricted starting address and address mask according to the set address partitioning mode, then performs address matching on the bus input address to obtain the address range and related permissions of the REE master, and then compares the access read and write operations with the security rules. If the permissions are met, access is allowed; otherwise, access fails and an error message is returned.

[0136] 4.2 Access Rule Configuration Module

[0137] The access rule configuration module is designed as follows: Figure 13 As shown.

[0138] This design proposes an IOPMP-TBus bus architecture that integrates the IOPMP configuration master module with each IOPMP slave module (including source IOPMP and destination IOPMP). The configuration master module is mounted on the first-level bus of the TEE, so that only the security core can read and write each IOPMP slave module, thus realizing the reconfigurability of IOPMP.

[0139] (1) Overview of IOPMP Registers Seven registers were designed to address the different functions of IOPMP at the source and destination ends.

[0140] (2) IOPMP register configuration process

[0141] Each IOPMP slave module has its own device number, and the IOPMP configuration master module accesses each slave module through the device number.

[0142] First, the security kernel writes the device number of the accessed slave module to the configuration enable register and enables it;

[0143] Then, write the addresses of the security rules or restrictions to the registers that need to be configured;

[0144] Finally, after configuration is complete, you need to disable the reset configuration enable register;

[0145] This completes the configuration of a slave device.

[0146] 5. Flash Controller Design

[0147] The overall design diagram of the Flash controller is as follows: Figure 14 As shown.

[0148] The Flash controller consists of a four-layer design: system bus interface layer, IP control register buffer layer, IP core logic layer, and IP interface layer.

[0149] The system bus interface layer is used for APB bus request routing, which distributes bus requests to access the Flash controller to the data transmit buffer tx_buf, the control register group ctrl regs, and the data receive buffer rx_buf.

[0150] The IP control register buffer layer is used to implement the control register group and provide the interface for software control.

[0151] The data transmission buffer is used to buffer data to be written to the Flash device; the data reception buffer is used to buffer data read from the Flash.

[0152] The core IP logic layer implements the data path for SPI timing generation and the control state machine for Flash-related instructions. Specifically, the `spi_tx` module serially transmits 8-bit data, with its output signal corresponding to the MOSI signal of the SPI protocol; the `spi_clk` module generates a synchronization clock, with its output signal corresponding to the CLK signal of the SPI protocol; the `spi_rx` module converts serial single-bit signals into 8-bit parallel data, with its input data signal corresponding to the MISO signal of the SPI protocol; and the `spi_delay` module generates timing signals required for Flash instruction execution to control logic and implement state transitions.

[0153] The IP interface layer then outputs signals related to the 2-wire SPI protocol.

[0154] This invention constructs a dual-core physically isolated security system based on the RISC-V architecture. It achieves hardware-level isolation between the secure core (TEE) and the non-secure core (REE) through a three-level bus architecture. The secure core exclusively uses the AHB-isolated bus to connect the BootROM, instruction RAM, and the ASCON lightweight cryptographic engine, completely eliminating the performance bottleneck of traditional time-sharing architectures. It innovatively integrates a dynamic IOPMP firewall, supporting fine-grained permission reconfiguration at runtime and real-time interception of unauthorized access. Simultaneously, it constructs a three-level trusted chain "BootROM→TEE→REE," combined with the ASCON algorithm to achieve program signature verification and address randomization boot, effectively defending against firmware tampering and code injection attacks. Furthermore, the collaborative design of the Mailbox dual-channel communication mechanism and the hardware Flash controller significantly improves system energy efficiency while ensuring secure data transmission between cores. This system overcomes the security challenges of lightweight terminals, achieving a 30% performance improvement and a 42.7% reduction in resource consumption compared to the TrustZone architecture, providing IoT devices with a hardware-level security foundation certified by CC EAL4+.

[0155] The above description is merely a specific embodiment of the present invention. Any feature disclosed in this specification may be replaced by other equivalent or similar features unless otherwise specified. All disclosed features, or steps in all methods or processes, may be combined in any way except for mutually exclusive features and / or steps.

Claims

1. A RISC-V dual-core TEE security system and method integrating a lightweight ASCON engine, characterized in that... include: Both the secure processor core and the non-secure processor core adopt the RISC-V architecture. The three-level hierarchical bus architecture, in which the first-level AHB bus connects the security processor core, the boot storage module and the security boot unit to form a physically isolated environment; The second-level AHB bus connects the encryption engine unit to the main memory and restricts the access permissions of insecure processor cores through a hardware firewall; the third-level AHB bus separates peripheral resources from insecure AHB buses through a secure AHB bus.

2. The system according to claim 1, characterized in that: The hardware firewall is a dynamic access control module, which includes four configurable storage domains. Each storage domain has eight programmable entries. Each entry includes a CFG register that defines the read and write permission levels and an ADDR register that defines the address range. It supports cascading expansion of entries to achieve fine-grained access control.

3. The system according to claim 1, characterized in that: The encryption engine unit integrates authentication encryption mode, decryption verification mode, and hash digest mode; the authentication encryption mode supports 128-bit keys and random numbers; the decryption verification mode performs real-time tag integrity verification; and the hash digest mode outputs a 256-bit fixed-length digest.

4. The system according to claim 3, characterized in that: The encryption engine unit includes a side-channel resistant design, specifically a timing jitter circuit that implements a clock disturbance of 50±15 nanoseconds, and a dynamic capacitor array that provides ±5% current fluctuation compensation.

5. The system according to claim 1, characterized in that... Includes a secure boot method: the secure processor core executes the primary boot program in the BootROM; and loads the encrypted secondary boot program into secure memory via the secure SPI interface. Call the encryption engine to perform decryption and hash integrity verification; After the verification is successful, the non-secure processor core boot address is dynamically generated. This address is the base address 0x9000_0000 plus a random offset. Finally, the non-secure processor core reset signal is released and execution jumps to the dynamic address.

6. The system according to claim 1, characterized in that... Includes an inter-core communication mechanism: This mechanism has a dual Mailbox structure with a command channel and a data channel; the command channel uses 256 bytes of single-port RAM to achieve low-security direct access; the data channel uses 512 bytes of dual-port RAM to achieve high-security encryption authentication.

7. The system according to claim 6, characterized in that: The communication protocol employs a multi-level security strategy: direct transmission mode is used when the data length is less than or equal to 64 bytes; hash integrity authentication mode is used when the data length is greater than 64 bytes but less than or equal to 512 bytes; and authentication-encrypted transmission mode is used when the data length is greater than 512 bytes.

8. The system according to claim 1, characterized in that: Peripheral resource isolation is achieved by having secure peripherals access the secure APB bus and insecure peripherals access the insecure APB bus. The hardware firewall blocks insecure processors from accessing the secure APB bus.

9. The system according to claim 2, characterized in that: The reconfiguration process of the dynamic access control module includes the security processor core updating entries through a dedicated configuration bus; the old rules remain in effect during the entry update; and the new rules are switched when the bus idle period reaches a set threshold.

Images