A SoC security protection architecture based on hardware native dual-domain physical isolation and a central security hub access control module

Abstract

ABSTRACT: The application discloses a kind of based on hardware native dual-domain physical isolation SoC security protection architecture and central security hub access control module, and it is related to integrated circuit security technical field.Architecture contains: open general operating domain, operating non-security application;Closed core security solidification domain, store security data;And deployment in the central security hub access control unit between dual-domain.Dual-domain is separated by isolation structure on layout, with independent power supply and clock, realize full hardware physical break.Central security hub is connected in system bus, including hardware finite state machine, access control storage unit and audit log unit;Finite state machine monitors cross-domain access and controls bus on-off;Audit log generates tamper-evident record for each cross-domain access.The application realizes chip bottom layer native full hardware physical isolation, improves the data security and inter-domain fault isolation capability of SoC in car standard and high-trust scenario.

Description

Technical Field

[0001] This invention relates to the fields of integrated circuit design, SoC system-on-a-chip security architecture, automotive-grade functional safety, and high-reliability computing technology. Specifically, it relates to a chip-level security protection module equipped with an independent hardware arbitration unit and realizing dual-domain full hardware physical isolation, which is particularly suitable for neuromorphic in-memory computing chips, in-vehicle intelligent computing units, and personal AI terminals with stringent requirements for data security and operational reliability. Background Technology

[0002] With the rapid development of artificial intelligence and Internet of Things technologies, the security requirements for core chip data, user privacy information, and system underlying keys are increasing exponentially. At the same time, automotive-grade scenarios are placing stringent requirements on chip operational reliability, anti-interference capabilities, and failure prevention capabilities in accordance with the ISO 26262 standard.

[0003] Current mainstream chip security solutions in the industry generally employ technologies such as software access control, logical address partitioning, TEE trusted execution environments, or security islands. These solutions are essentially software isolation or semi-hardware isolation: they only divide areas through software protocols and logical permissions; the chip's internal bus, storage resources, and clock power still share physical paths, failing to achieve true physical isolation. Once the operating system is compromised or the underlying drivers are tampered with, attackers can directly bypass protection and obtain core data, making high-level security isolation impossible.

[0004] Meanwhile, existing security solutions are mostly external add-on modules or software layer patches, which cannot be deeply integrated with the underlying architecture of high-performance computing chips (such as neuromorphic in-memory computing chips), and lack independent hardware-level access control arbitration units, thus failing to achieve the core requirements of "application domain failures not affecting core data, core data not being accessible, and stable operation in extreme environments".

[0005] Based on this, the present invention proposes a hardware native dual-domain physical isolation and central security hub access control protection architecture, which realizes inter-domain isolation and arbitration through independent hardware circuits, filling the technical gap in the industry in the field of underlying native, full hardware physical isolation. Summary of the Invention

[0006] To address the vulnerabilities of existing chip security solutions, such as soft isolation vulnerabilities, easy leakage of core data, and insufficient automotive-grade reliability, this invention provides a hardware-native dual-domain physical isolation and central security hub access control module. This module achieves full hardware physical isolation between the chip's internal normal operating domain and core security domain. Through an independent central security hub, it implements hardware-level control over inter-domain permissions, effectively blocking unauthorized access while meeting automotive-grade high-reliability operation requirements. It is perfectly compatible with neuromorphic in-memory computing chips and various high-security SoCs.

[0007] A SoC security architecture based on native dual-domain physical isolation is proposed. The overall architecture consists of three parts: an open general operation domain, a closed core security embedded domain, and a central security hub hardware access control unit. All three parts are native hardware circuits at the chip level, with no software involved in the core control logic.

[0008] The ordinary operating domain and the core security solidified domain are physically separated in terms of layout design, circuit path, storage array, clock link, power supply branch, bus interface, etc. They are separated by a physical isolation ring protection zone and there is no direct electrical connection across domains. The central security hub access control unit is a pure hardware arbitration circuit, deployed in the physical isolation zone area between the two domains. It is the only data interaction channel between the two domains and is responsible for the verification, authorization, interception, transfer and access audit log recording of all cross-domain data.

[0009] The general operation domain is dedicated to running third-party general applications and non-core computing tasks. It allows for failures such as program crashes, virus intrusions, and system anomalies, and these failures are limited to this domain and will not spread across domains. The core security solidified domain is dedicated to the closed storage of core memory data, user personality parameters, globally unique UUID identifiers, and core operating logic. It is physically isolated throughout and can only interact with data through authorized instructions from the central security hub.

[0010] The normal operating domain and the core security hardened domain use independent power management units and clock trees, and are separated by physical isolation rings to prevent data crosstalk and unauthorized intrusion from the hardware level.

[0011] The central security hub contains: Hardware Finite State Machine (FSM): Directly coupled to the system bus address lines and control lines, it monitors access requests at the clock cycle level; One-time programmable (OP) storage arrays: A fixed basic whitelist strategy; Hardware access audit log unit: Every cross-domain access (allowed / blocked / abnormal) is written to an immutable log by the hardware; Error response generation circuit: In case of unauthorized access, pull the bus ready signal low and return a hardware error code within a single clock cycle.

[0012] The whitelist is divided into two levels: Factory-preset whitelist (OP array): burned during chip manufacturing, read-only during operation, and cannot be modified by software; Runtime hierarchical whitelist subset (configurable within the security domain): Supports dynamic configuration of temporary access permission subsets by the security kernel within the security domain based on policies, for short-term authorization in legitimate business scenarios.

[0013] Audit logs and whitelist collaboration: Each access records: request source domain, address range, timestamp (hardware clock), UUID root identifier, and allow / block result; Logs are appended in the form of hardware hash chains, are immutable, and can be linked with the UUID tracing module to form a full-chain audit ledger.

[0014] The normal operating domain operates in an open manner, with strong fault tolerance; the core security domain is stored in a closed manner, significantly improving security. The two domains are logically independent, hardware independent, and their failures do not affect each other.

[0015] It features high temperature resistance, vibration resistance, electromagnetic interference resistance, single-event upset protection, and power-loss data retention capabilities. Under extreme operating conditions, the dual-domain isolation architecture remains intact and core data is not lost.

[0016] It deeply integrates core modules such as a hierarchical engine architecture, a cross-generational unified memory protocol, and a cross-hardware memory migration compatibility layer, without additional computing power loss, and operates stably in a collaborative manner. Beneficial effects

[0017] The innovative technical approach is remarkable: This invention abandons the industry-standard soft isolation technology approach and pioneers a chip-level native all-hardware physical dual-domain isolation + independent central security hub architecture. According to the search, it has outstanding substantive features and completely avoids existing patent conflicts.

[0018] Achieving chip-level high-reliability data security: The ordinary operating domain and the core security domain are physically completely isolated. Even if the user system or ordinary application is compromised, it is impossible to physically access the memory data and UUID information in the core security domain, thus achieving "application failures are not affected and core data is highly protected".

[0019] Pure hardware control with extremely strong anti-attack capabilities: The core logic of the entire protection module is implemented through hardware circuits, with a response speed at the clock cycle level. There are no software vulnerabilities or backdoor risks, and the anti-attack and anti-interference capabilities are significantly improved, making it perfectly suitable for demanding scenarios such as automotive, industrial, and high-end privacy protection.

[0020] Deeply adapted to proprietary neuromorphic in-memory computing chip: It is embedded as a native module into the core module system, rather than an external patch, and works seamlessly with the chip's memory and computing logic without occupying redundant hardware resources or affecting the chip's operating efficiency.

[0021] With full coverage of dual scenarios and extremely high commercial value, it simultaneously meets the functional safety requirements of automotive-grade ISO 26262 and the essential needs of high-end users for core data privacy protection. It can be applied to in-vehicle intelligent chips and high-reliability embedded systems, as well as to personal AI large-scale model hardware terminals, with a wide range of patent commercialization and IP licensing scenarios.

[0022] Self-healing and stable operation under extreme conditions: It has hardware-level fault monitoring, abnormal reset and data repair capabilities, and always maintains the effectiveness of dual-domain physical isolation in harsh environments such as high temperature, vibration and electromagnetic interference.

[0023] Hardware-level audit closed loop with full-link traceability: The newly added access audit log unit enables hardware recording and traceability of every cross-domain access. Combined with hierarchical whitelists, it forms a complete security closed loop of "access control + monitoring ledger + root trust", which can be directly used as a dual evidence link for automotive-grade functional safety and information security. Detailed Implementation

[0025] This embodiment provides a SoC security architecture based on native dual-domain physical isolation, integrated within a neuromorphic in-memory computing chip or a general-purpose SoC. During the chip tape-out layout design phase, the chip's interior is divided into three independent physical regions: a normal operating domain, a core security embedded domain, and an isolation zone region located between the two.

[0026] The normal operating domain and the core security hardened domain are physically separated by deep trench isolation technology or guard rings to prevent side-channel attacks and substrate noise interference. In the power supply system, the two domains are connected to independent low-dropout linear regulators or power management units to ensure the physical independence of the power rails; in the clock system, an independent clock buffer tree is used to avoid clock signal crosstalk.

[0027] The central security access control unit is deployed within the isolation zone, and its core circuit connection method is as follows:

[0028] The central security hub access control unit is connected in series between the master and slave ports of the system bus matrix. Bus request signals from the normal operating domain first enter the central security hub, rather than directly reaching the storage controller of the core security hardened domain.

[0029] The central security hub contains a hardware finite state machine, asynchronously reset by the system reset signal and driven by an independent security clock domain. The state machine inputs are connected to the bus address and control lines, while the outputs are connected to the bus arbitration logic, ready signal line control, and error response generation circuitry.

[0030] The data output of the one-time programmable memory array is connected to the comparator input of the hardware finite state machine, and the basic whitelist policy is embedded in the array. At the same time, a set of configurable hierarchical whitelist subset registers is added in the core security domain, which is dynamically written and managed by the security kernel according to the security policy, forming a two-layer whitelist mechanism of "factory-embedded + runtime hierarchical".

[0031] A hardware access audit log unit is integrated within the central security hub, including: Minimalist hardware log storage area (independent storage array within the security domain); The hash chain generation logic is used to generate a summary for each log entry and append it to the end of the chain; The interface for linking with the UUID module binds logs to the device root identifier.

[0032] Workflow: Each time a cross-domain access request enters the central security hub, the audit log unit synchronously collects: request source domain ID, address range, timestamp, UUID, and allow / block result; The hardware calculates the hash value of the record and concatenates it with the hash of the preceding chain's tail to form an immutable audit chain; Logs can only be read by secure kernels within a security domain; ordinary operating domains have no permission to read or modify them.

[0033] When the hardware finite state machine detects an illegal address access request, it outputs a truncation signal, pulls the bus ready signal line low, and physically blocks data transmission; at the same time, it outputs a hardware-level error response to the requester, and the violation event is recorded by the audit log unit.

[0034] During the FPGA prototyping phase, the aforementioned circuit connections are instantiated using a hardware description language. When a normal operating domain initiates an access request to the core security embedded domain, the request signal enters the central security hub: The hardware finite state machine extracts the request address and performs a hardware comparison with the OP whitelist and hierarchical whitelist subsets; If authorization is granted, the state machine allows the bus path to be opened, and the audit log unit records this legitimate access (including UUID and timestamp). If the authorization fails, the state machine pulls the ready signal low and returns an error within a single clock cycle, while the audit log records the details of the unauthorized access. The security kernel within the core security domain can read audit logs in the background and associate them with UUID traceability data to form a complete cross-domain access ledger and traceability link.

[0035] This embodiment can be independently integrated as an IP core into various automotive chips, embedded chips, and neuromorphic in-memory computing chips, or it can be externally connected to storage systems and smart terminal devices, adapting to various hardware forms and offering flexible application scenarios.

Claims

1. A SoC security protection architecture based on hardware-native dual-domain physical isolation, characterized in that, Include: An open, normal operating domain, configured to run non-security level applications; A closed, core, secure, and permanently configured domain is used to store security-grade data. The central security access control unit is deployed between the ordinary operating domain and the core security solidified domain. The ordinary operating domain and the core security solidified domain are separated by an isolation structure in the physical layout and have independent power management units and clock trees; The central security access control unit is connected in series in the system bus matrix and includes a hardware finite state machine, a storage unit configured with access control policies, and a hardware access audit log unit. The hardware finite state machine is configured to monitor cross-domain access requests based on hardware logic and control the opening or closing of the bus path according to the access control policy. The hardware access audit log unit is configured to generate and store an immutable access record for each cross-domain access. The access record includes at least the request source domain identifier, access address range, timestamp, device globally unique identifier (UUID), and access result.

2. The protective architecture according to claim 1, characterized in that, The storage unit is a one-time programmable storage array. The access control policy is physically embedded in the one-time programmable storage array during the chip manufacturing stage and cannot be modified by software during the chip operation stage. It further includes a runtime hierarchical whitelist subset configuration register, which is located in the core security fixed domain and can be dynamically written and managed by the security kernel according to the security policy, forming a two-layer authorization mechanism of factory-fixed whitelist and runtime hierarchical whitelist.

3. The protective architecture according to claim 1, characterized in that, The hardware finite state machine is directly coupled to the bus address line and the bus ready signal line; when an unauthorized address is detected, the hardware finite state machine is configured to pull the bus ready signal line low within a single clock cycle to block data transmission and generate a hardware-level error response.

4. The protective architecture according to claim 1, characterized in that, The isolation structure includes deep trench isolation or a guard ring, used to physically block substrate noise and side channel signal transmission.

5. The protective architecture according to claim 1, characterized in that, The normal operating domain and the core security solidified domain are each connected to an independent low-dropout linear regulator to achieve physical isolation of the power rails.

6. The protective architecture according to claim 1, characterized in that, The central security access control unit also includes an error response generation circuit, configured to send a hardware-level error response signal to the requester when cross-domain access is blocked.

7. The protective architecture according to claim 1, characterized in that, The hardware access audit log unit includes hash chain generation logic, which concatenates the hash value of each access record with the hash of the preceding chain tail to form an immutable audit chain; the audit chain can only be read by the security kernel within the core security hardened domain.

8. A neuromorphic in-memory computing chip or a high-security SoC, characterized in that, Integrate the SoC security protection architecture based on hardware native dual-domain physical isolation as described in any one of claims 1 to 7.

9. A vehicle-grade in-vehicle intelligent hardware or a personal AI large-scale model terminal, characterized in that: The built-in protection architecture according to any one of claims 1 to 7 enables hardware-level physical security protection and full-link access auditing of core data.