Secure session hardware acceleration system and method based on zero-trust architecture

Abstract

The invention provides a security session hardware acceleration system and method based on a zero-trust architecture. The system comprises a gateway control platform and a hardware data platform, the gateway control platform comprises a policy management module PAP, a policy decision module PDP and a gateway main CPU control unit; the hardware data platform comprises a secure session context acceleration engine ESC Engine and an encryption engine, and the secure session context acceleration engine ESC Engine comprises a high-speed policy execution unit PEU, a secure context storage unit SCU and a temporary zero clearing and control unit ZTCU; the gateway control platform transmits a compiled strategy to the hardware data platform through a bus and transmits an attribute key generated by analyzing an access request to the hardware data platform, and the hardware data platform generates a strategy decision and a security key and provides encryption and decryption services of application data, security storage of hardware isolation and an instantaneous zero clearing mechanism. According to the method, a zero-trust architecture is established by using hardware, and the safety performance is improved while low delay is realized.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to a data access system and method based on a zero-trust architecture. Background Technology

[0002] Zero Trust Network Access (ZTNA) architecture aims to completely replace the traditional Virtual Private Network (VPN) model, especially in scenarios where external users access internal application services. A major security flaw of traditional VPNs is that once a user establishes an authenticated connection, they gain encrypted access to the entire local network (LAN). This wide-area, network-layer connection method contradicts the Principle of Least Privilege; if a user's device is compromised, attackers can move laterally within the internal network. In stark contrast, the core of ZTNA is establishing a one-to-one encrypted connection between a user device and a specific application or service through a Policy Enforcement Point (PEP). This model requires the gateway to continuously authenticate and assess device posture before each application session begins and even during the session. To achieve this, the ZTNA gateway must query various attribute information in real time, including user identity, device health score, geolocation, and application sensitivity. In high-concurrency, large-scale deployment environments, this continuous and dynamic authentication mechanism poses a significant challenge to the gateway's performance. The Policy Decision Point (PDP) is responsible for receiving access requests from the PEP and executing decisions based on a complex set of attributes. If PDP relies on traditional software databases or external cloud services for policy lookup and risk scoring calculations, it introduces microseconds or even milliseconds of latency in each application access request. When handling tens or even hundreds of thousands of concurrent sessions, this decision latency becomes a major bottleneck in system throughput, affecting user experience and limiting the ability to deploy ZTNA on a large scale.

[0003] To address the high-performance requirements of network security devices, the industry also employs hardware acceleration technologies such as ASICs (Application-Specific Integrated Circuits) and FPGAs (Field-Programmable Gate Arrays). Existing general-purpose next-generation firewall (NGFW) accelerators, such as Fortinet's SPU / vSPU processor series, primarily focus on optimizing the performance of basic data flows. Their functions include firewall processing of L3 / L4 traffic, VPN tunnel acceleration, IPSec / CAPWAP encryption offloading, and SSL / TLS decryption acceleration and signature matching for general intrusion prevention systems (IPS) provided by the Content Processor (CP9). These functions improve the processing speed of the network and transport layers to some extent.

[0004] However, existing hardware acceleration designs do not provide corresponding optimization paths for ZTNA's unique dynamic, multi-attribute policy lookup and secure session context management. ZTNA's security core lies in complex ABAC (Attribute-Based Access Control)-based policy decisions, which are control flow-intensive tasks. General-purpose ASICs typically lack the ability to handle such high-dimensional, complex lookups. Therefore, in the existing architecture, the core decision logic (PDP) in the ZTNA architecture, as well as the management of application-layer session keys and contexts, still primarily rely on general-purpose microprocessors (CPUs) and software. This makes decision latency and sensitive data security new performance and security bottlenecks.

[0005] Current hardware acceleration solutions focus on data flow acceleration, while the innovation required for ZTNA should concentrate on accelerating control flow and session context. Solving the latency problem of complex policy decisions under high concurrency, and ensuring the absolute isolation and destruction of dynamically generated session keys throughout their lifecycle, constitute the current technological gap in the ZTNA hardware field. Therefore, there is an urgent need to research a zero-trust gateway hardware acceleration design scheme that can simultaneously achieve low latency and orders of magnitude improvements in performance and security. Summary of the Invention

[0006] The technical problem to be solved by the present invention is to provide a secure session hardware acceleration system and method based on a zero-trust architecture, which simultaneously solves the problems of policy decision delay and session security management.

[0007] In a first aspect, the present invention provides a secure session hardware acceleration system based on a zero-trust architecture, the system comprising a gateway control platform and a hardware data platform; The gateway control platform includes a policy management module (PAP), a policy decision module (PDP), and a gateway main CPU control unit. The strategy management module PAP is used to send strategy intents to the strategy decision module PDP; The policy decision module (PDP) is used to compile high-level policies into TCAM-recognizable (value, mask) pairs and transmit the compiled policies to the hardware data platform via the bus. The gateway main CPU control unit is used to process data plane services and session management, and to send session lifecycle management signals to the hardware data platform; The hardware data platform includes a Secure Session Context Acceleration Engine (ESC Engine) and an encryption engine. The Secure Session Context Acceleration Engine (ESC Engine) includes a High-Speed ​​Policy Execution Unit (PEU), a Secure Context Storage Unit (SCU), and a Temporary Clearing and Control Unit (ZTCU). The high-speed policy execution unit (PEU) is used to perform nanosecond-level policy decision-making after receiving the attribute key and generate a security key for the security context storage unit (SCU). The Security Context Storage Unit (SCU) is used to provide hardware-isolated secure storage for dynamic session contexts and is zeroed out under the control of the ZTCU. The temporary zeroing and control unit ZTCU is used to listen for trigger events and control the security context storage unit SCU to instantly destroy sensitive data. The encryption engine is used to process the encryption and decryption of application data, including obtaining the session key of the Security Context Storage Unit (SCU) and receiving / sending data streams to the High-Speed ​​Policy Execution Unit (PEU).

[0008] Furthermore, the hardware data platform is mounted on an FPGA chip and connected to the gateway control platform via PCIe and a network port.

[0009] Furthermore, the high-speed policy execution unit (PEU) specifically includes a policy TCAM module, a priority encoder, a decision result RAM, a key generator, and a Reg-CAM module; The policy TCAM module is used to receive attribute keys, complete all policy rule matching within a single clock cycle, and output the matching line results to the priority encoder. The priority encoder is used to select the highest priority address to the decision result RAM when multiple rules are matched. The decision result RAM is used to store the final action corresponding to each policy rule, and outputs the action according to the address of the priority encoder; The key generator is activated after the policy allows, generates a key block, and sends it to the Reg-CAM module; The Reg-CAM module is used to verify the uniqueness of the key, and after successful verification, it is sent to the Security Context Storage Unit (SCU).

[0010] Furthermore, the Security Context Storage Unit (SCU) includes an HDCSA hardware dynamic allocator, a secure SRAM module, and a memory protection unit (MPU). The HDCSA hardware dynamic allocator is used to manage the allocation of secure SRAM and, in conjunction with the temporary zeroing and control unit ZTCU, reclaims memory after zeroing. The secure SRAM module is used to store session keys and context, and to receive temporary clear signals and clear signals from the control unit ZTCU; The memory protection unit (MPU) is used to restrict access to the secure SRAM module, allowing only authorized master devices (such as HDCSA and PEU) to access it, and intercepting illegal access requests.

[0011] Furthermore, the temporary zeroing and control unit ZTCU includes a tamper-proof sensor interface, a session management signal receiver, a zeroing control state machine, a dynamic noise generator, and an instantaneous zeroing circuit; The tamper-proof sensor interface is used to receive tamper alarms from the chassis and environmental sensors, and converts physical attack signals into the highest priority reset trigger signal; The session management signal receiver is used to receive session lifecycle management signals sent by the gateway main CPU control unit; The reset control state machine is used to receive different trigger signals and initiate the reset sequence; The dynamic noise generator is activated during operations such as key generation and clearing to actively generate random noise, masking the chip's power consumption and electromagnetic characteristics during sensitive operations. The instantaneous zeroing circuit is used to physically zero a specified address of the secure SRAM module.

[0012] Secondly, the present invention provides a secure session hardware acceleration method based on a zero-trust architecture, the method being implemented based on the system described in the first aspect, the method comprising the following steps: Step S1: The gateway control platform parses the access request, generates an attribute key, and transmits the attribute key to the hardware data platform. Step S2: After receiving the attribute key, the policy TCAM module completes the "allow / deny" decision within nanoseconds through parallel matching and priority encoder. If the decision is to deny, the process ends; otherwise, proceed to step S3. Step S3: Generate a temporary session key and verify its uniqueness; Step S4: Allocate space in the secure SRAM module isolated from the general system environment through the HDCSA hardware dynamic allocator, and store the temporary session key and the corresponding context in the space; Step S5: Establish an encrypted data channel and perform session processing; Step S6: Monitor the session in real time. When a session terminates or a corresponding event signal occurs, trigger the instantaneous clearing circuit to destroy the specified memory data in nanoseconds. Step S7: Reclaim the memory block and terminate the session.

[0013] Furthermore, step S6 specifically includes: real-time monitoring of the entire session process; if the session terminates normally, a session lifecycle management signal is sent to the temporary clearing and control unit ZTCU through the gateway main CPU module to trigger the destruction of specified memory data. If the verification fails continuously, the temporary zeroing and control unit ZTCU will be triggered by the high-speed policy execution unit PEU to destroy the specified memory data. If the alteration is physical, the temporary reset and control unit ZTCU will be triggered by the sensor to destroy the specified memory data.

[0014] One or more technical solutions provided by this invention have at least the following technical effects or advantages: (1) Nanosecond-level policy decision-making capability: Through the TCAM hardware parallel processing mechanism in PEU, the latency of dynamic policy decision-making is reduced from the microsecond level of traditional software to the nanosecond level (10-100 ns). This single-cycle, parallel matching capability makes continuous verification no longer a performance bottleneck, providing efficient processing speed for high-concurrency zero-trust networks.

[0015] (2) Hardware-level dynamic key protection mechanism: The dynamic session key is protected by the hardware isolation TEE environment of the SCU, so that it is completely isolated from the general computing environment, thus solving the problem of isolation and security management of dynamic session key.

[0016] (3) Hardware-level instantaneous data clearing mechanism: Through the nanosecond-level (10-100 ns) physical clearing mechanism of ZTCU, the sensitive data is "destroyed immediately", ensuring that the data is destroyed instantly and irreversibly at the end of its life cycle. This effectively resists physical and side-channel attacks and solves the problems of sensitive data residue and physical attacks. Attached Figure Description

[0017] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0018] Figure 1 This is a schematic diagram of a secure session hardware acceleration system based on a zero-trust architecture according to Embodiment 1 of the present invention; Figure 2 This is an execution flowchart of a secure session hardware acceleration method based on a zero-trust architecture according to Embodiment 2 of the present invention; Figure 3 This is a flowchart illustrating the internal data processing of the secure session context acceleration engine in a specific embodiment of the present invention. Detailed Implementation

[0019] The technical solution in this application embodiment follows the following general idea: This invention proposes an innovative hardware acceleration architecture for zero-trust security gateways—the Ephemeral Security Session Context Acceleration Engine. Session Context (ESC Engine). The ESC Engine is a key hardware module deployed in the ZTNA gateway data plane, specifically designed to manage and accelerate the lifecycle of zero-trust sessions with high dynamic and security requirements. The innovation of the ESC Engine lies in integrating three complementary key hardware security and performance technologies into a unified, cohesive acceleration module to achieve session processing throughput and security levels unattainable by traditional solutions. 1. High-speed Policy Execution Unit (PEU): Employs Content Addressable Memory (CAM) technology to harden the dynamic policy decision-making process, achieving nanosecond-level multi-attribute matching decisions.

[0020] 2. Secure Context Unit (SCU): Employs a hardware isolation mechanism (similar to a dedicated Trusted Execution Environment (TEE)) to store session ephemeral keys and real-time security state to combat software-level and side-channel attacks.

[0021] 3. Zeroization and Tamper Control Unit (ZTCU): Employs a dedicated hardware zeroing circuit as a self-destruct mechanism to ensure that sensitive data can be destroyed within nanoseconds when a session ends or a security violation occurs.

[0022] The core technical solution of the Secure Session Context Acceleration Engine (ESC Engine) of this invention revolves around three collaborative hardware units, simultaneously addressing issues such as policy decision latency, sensitive data residue and physical attacks, as well as the isolation and secure management of dynamic session keys. This invention hardens key security and performance functions into the hardware logic, implementing a hardware-triggered instantaneous zeroing mechanism, achieving orders-of-magnitude improvements in both performance and security.

[0023] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods. Example 1

[0024] like Figure 1 and Figure 3 As shown, this embodiment provides a secure session hardware acceleration system based on a zero-trust architecture, the system including a gateway control platform and a hardware data platform; The gateway control platform includes a policy management module (PAP), a policy decision module (PDP), and a gateway main CPU control unit. The strategy management module PAP is used to send strategy intents to the strategy decision module PDP; The policy decision module PDP acts as a policy compiler, which is used to compile high-level policies into (value, mask) pairs that can be recognized by TCAM, and transmit the compiled policies to the hardware data platform (written into the TCAM and decision result RAM of PEU) via the bus. The gateway main CPU control unit is used to process data plane services and session management, and to send session lifecycle management signals (such as normal termination) to the hardware data platform. The hardware data platform includes a Secure Session Context Acceleration Engine (ESC Engine) and an encryption engine. The Secure Session Context Acceleration Engine (ESC Engine) includes a High-Speed ​​Policy Execution Unit (PEU), a Secure Context Storage Unit (SCU), and a Temporary Clearing and Control Unit (ZTCU). The high-speed policy execution unit (PEU) is used to perform nanosecond-level policy decision-making after receiving the attribute key and generate a security key for the security context storage unit (SCU). The Security Context Storage Unit (SCU) is used to provide hardware-isolated secure storage for dynamic session contexts and is zeroed out under the control of the ZTCU. The temporary zeroing and control unit ZTCU is used to listen for trigger events and control the security context storage unit SCU to instantly destroy sensitive data. The encryption engine is used to process the encryption and decryption of application data, including obtaining the session key of the Security Context Storage Unit (SCU) and receiving / sending data streams to the High-Speed ​​Policy Execution Unit (PEU).

[0025] The Secure Session Context Acceleration Engine (ESC Engine) is deployed inside the ZTNA gateway (as a PEP) and can exist in the form of a high-performance FPGA SmartNIC or a custom ASIC. It is directly connected to the gateway's network encryption / decryption module (i.e., a general network encryption / decryption scheme, adapted to the specific gateway) and the high-speed interface bus. If the data plane (hardware acceleration) is implemented inside the FPGA, then the high-speed interface bus connects the gateway's internal CPU and FPGA.

[0026] In the workflow, the ZTNA gateway's software control plane (PAP / PDP) is responsible for policy generation, management, and compilation. These policies are compiled into a TCAM-recognizable format and updated to the ESC Engine in real time via a secure channel. In the data plane, the ESC Engine's PEU intercepts all application access requests. The PEU utilizes its internal high-speed mechanisms to enforce policies and collaborates with the SCU to manage the session's encryption keys and context state.

[0027] ESC Engine addresses the challenge of extending the TEE concept from static root key protection to dynamic session state management under high concurrency. Because ZTNA sessions generate a large number of ephemeral keys with extremely short lifecycles, traditional solutions relying on operating systems (OS) or general-purpose hardware are inefficient in dynamic resource allocation and reclamation. ESC Engine eliminates software-level latency and vulnerability risks by hardening these functions.

[0028] Preferably, the hardware data platform is mounted on an FPGA chip and connected to the gateway control platform via PCIe and a network port.

[0029] Preferably, the high-speed policy execution unit (PEU) serves as the decision-making brain and specifically includes a policy TCAM module, a priority encoder, a decision result RAM, a key generator, and a Reg-CAM module. The policy TCAM module acts as a parallel matcher, receiving attribute keys, completing all policy rule matching within a single clock cycle, and outputting the matching line results to the priority encoder. The priority encoder is used to select the highest priority address to the decision result RAM when multiple rules are matched. The decision result RAM is used to store the final action corresponding to each policy rule, and outputs the action according to the address of the priority encoder; The key generator is activated after the policy allows it to generate a highly random key block and send it to the Reg-CAM module; The Reg-CAM module acts as a key deduplication device to verify the uniqueness of the key, and after successful verification, it is sent to the Security Context Storage Unit (SCU) (which acts as a safe).

[0030] Zero-trust policy formulation relies on complex logical judgments based on multiple dynamic input attribute sets, such as user roles, device status, and real-time risk scores. In a software environment, handling such multi-attribute decisions requires complex database queries and logical chain judgments, significantly increasing policy decision latency. This invention, PEU, addresses this challenge by employing ternary content-addressable memory (TCAM). The core advantage of TCAM lies in its support for tri-state matching (0, 1, "don't care") and parallel lookup of all memory entries within a single clock cycle.

[0031] Example of attribute compilation and matching: 1. Attribute Encoding: Dynamic attribute values ​​from distributed policy information points (PIPs), such as identity provider (IdP) or endpoint protection (EPP) systems (e.g., risk scores from 0 to 100, whether MFA has been completed) are compiled into a fixed-length binary lookup key.

[0032] 2. TCAM Lookup: The PEU inputs the lookup key into the TCAM. By utilizing the TCAM's masking mechanism, irrelevant attribute bits in the policy can be set to the "Don't Care" state. This allows the PEU to complete complex ZTNA policy matching with extremely low latency (typically within tens to hundreds of nanoseconds), thereby hardening the core decision-making function of the PDP and achieving performance far superior to software PDPs that require hundreds of microseconds of latency.

[0033] 3. Priority decision: If multiple policy entries match simultaneously, TCAM's built-in priority encoder can quickly determine the unique, highest priority decision (allow or deny) based on preset policy priority rules.

[0034] Furthermore, the PEU of this invention integrates a register-based content-addressable memory (Reg-CAM) to accelerate the generation and real-time verification of non-repeating key streams.

[0035] Preferably, the Security Context Storage Unit (SCU) includes an HDCSA hardware dynamic allocator, a secure SRAM module, and a memory protection unit (MPU). The HDCSA hardware dynamic allocator is used to manage the allocation of secure SRAM and, in conjunction with the temporary zeroing and control unit ZTCU, reclaims memory after zeroing. The secure SRAM module is used to store session keys and context, and to receive temporary clear signals and clear signals from the control unit ZTCU; The memory protection unit (MPU) is used to restrict access to the secure SRAM module, allowing only authorized master devices (such as HDCSA and PEU) to access it, and intercepting illegal access requests.

[0036] The Security Context Storage Unit (SCU) of this invention is the heart of the ESC Engine, specifically designed to store all highly sensitive session data, including ephemeral keys, authentication session tokens, and real-time risk scores. This dynamic data is highly fluid and has a very short lifespan, requiring the highest level of protection. The SCU's memory (high-reliability SRAM) is designed as a dedicated hardware-isolated area, functionally equivalent to ZTNA's session-specific Trusted Execution Environment (TEE) or Secure Element. Its isolation mechanism is as follows: Hardware Bus Arbitration: The isolation in this invention is achieved through a dedicated hardware mechanism, rather than relying on software or operating system (OS) security configurations. This hardware mechanism, through the Memory Protection Unit (MPU) and a dedicated system bus port, ensures that general-purpose CPUs or standard execution environments cannot control, read, or modify the contents of the SCU. Traditional TEEs are primarily used to protect static secrets (such as root keys), but this invention's SCU extends this security concept to protecting highly fluid, short-lifespan dynamic secrets. This isolation mechanism increases the difficulty of launching software security attacks because sensitive data is protected behind a hardware layer that is beyond the control of other execution environments. Side-channel basic defense: The physical layout and power supply system of the SCU memory area of ​​this invention adopts Xilinx FPGA-based layout, routing and power consumption optimization. Through physical shielding and power balancing design, a basic defense layer is formed against side-channel attacks such as electromagnetic radiation and power analysis.

[0037] Furthermore, another challenge in large-scale ZTNA deployment lies in the rapid, efficient, and secure allocation and reclamation of millions of short-lived session contexts. Traditional software heap management is vulnerable to memory allocation vulnerabilities (such as heap overflows), and reclamation operations (such as `free()` or garbage collection) introduce unpredictable latency. The HDCSA of this invention is a dedicated hardware logic within the SCU designed to address the security and efficiency issues of dynamic memory management. It manages a pre-allocated, hardware-isolated memory pool. HDCSA uses hardware-implemented memory management strategies, such as Segregated Free Lists based on dedicated pointers. This structure allows for the rapid location, allocation, and release of fixed-size session context blocks, avoiding the complex metadata maintenance and fragmentation issues of software allocators. HDCSA bypasses the OS-level memory allocation mechanism. Its management metadata (such as free lists and pointers) is also stored in isolated hardware, preventing software-level exploits from compromising or tampering with the integrity of the session context. Simultaneously, HDCSA's release operations are designed to be directly associated with the ZTCU. When a session is logically released, HDCSA can immediately trigger ZTCU to perform an instantaneous zeroing process before reclaiming the memory block, ensuring that the sensitive data stored in the memory block has been physically destroyed before it is reused or released to the system.

[0038] Preferably, the temporary zeroing and control unit ZTCU includes a tamper-proof sensor interface, a session management signal receiver, a zeroing control state machine, a dynamic noise generator, and an instantaneous zeroing circuit; The tamper-proof sensor interface is used to receive tamper alarms from the chassis and environmental sensors, and converts physical attack signals into the highest priority reset trigger signal; The session management signal receiver is used to receive session lifecycle management signals sent by the gateway main CPU control unit; The reset control state machine serves as the event processing center, used to receive different trigger signals (including software, hardware, and physical trigger signals) and initiate the reset sequence; The dynamic noise generator serves as a side-channel countermeasure, activated during operations such as key generation and clearing to actively generate random noise, masking the chip's power consumption and electromagnetic characteristics during sensitive operations, thus providing active defense. The instantaneous zeroing circuit serves as a data destruction execution unit, used to physically zero out a specified address of the secure SRAM module.

[0039] The Instantaneous Zeroing and Security Control Unit (ZTCU) is also a core security innovation of this invention, designed to completely eliminate memory remnants of session keys and other sensitive context data after session termination or security events, thereby effectively resisting cold start attacks, data residue attacks, and advanced physical analysis attacks. The ZTCU of this invention employs an instantaneous hardware zeroing mechanism based on an innovative SRAM design, rather than relying on time-consuming software overwriting or system power-off. This invention can utilize SRAM charge removal technology: this is key to achieving nanosecond-level zeroing. Through dedicated circuit design, the ZTCU can quickly remove the charge state in SRAM memory cells, randomizing or zeroing their contents in an extremely short time. Using this mechanism, the erase operation can be completed on a nanosecond timescale (e.g., one technique can complete erasure in <10 ns), improving efficiency by tens of thousands of times compared to solutions relying on traditional power management or power-off (which typically take hundreds of microseconds, such as 295 μs). Furthermore, the ZTCU of this invention can also be combined with existing Memory Built-in-Self-Test (MBIST) hardware to quickly initialize the target memory block to all zeros through special test or write modes, serving as an auxiliary or redundant means of instantaneous zeroing.

[0040] ZTCU's functionality extends beyond routine zeroing upon session termination; it also serves as the gateway's physical security response center, integrating the zeroing mechanism with proactive defense technologies.

[0041] Tamper Responsiveness: The ZTCU integrates physical sensor management logic for the gateway chassis and environment. Upon detecting a physical tampering event (e.g., unauthorized opening of the chassis, ambient temperature or voltage exceeding safe ranges, detection of high-frequency electromagnetic interference, etc.), the ZTCU immediately treats the alarm as a top-level security event. Upon receiving the tampering signal, the ZTCU immediately triggers an instantaneous hardware zeroing circuit, destroying all active session contexts and keys in the SCU. Because the zeroing operation is completed in nanoseconds, it makes it virtually impossible for attackers to complete side-channel data sampling or physical extraction before the data is destroyed, thus substantially eliminating the attack window.

[0042] The Dynamic Noise Generator (DNG) of this invention enables the ZTCU to activate the DNG during critical cryptographic operations (such as Diffie-Hellman key exchange, digital signatures, or session key generation), generating synchronous, high-bandwidth noise within the ESC Engine. This provides side-channel masking: the dynamic noise effectively masks the unique power consumption characteristics and electromagnetic radiation leakage signals generated by the chip during cryptographic operations. Compared to continuously running shields or noise generators, the ZTCU-controlled DNG activates precisely when needed, is more energy-efficient, and more accurately counters side-channel attacks targeting specific operations.

[0043] The above technical solution will be further explained below in conjunction with the data stream processing process: The high-speed policy execution unit (PEU) is essentially an ultra-high-speed, parallel pattern matcher. Its circuit logic is built around the TCAM and the control logic surrounding it.

[0044] Core components and data flow: 1. Input registers / latches: Logic: Temporarily store the pre-encoded, fixed-length, binary digital signature "attribute key" sent from the gateway software.

[0045] Circuit: A set of D flip-flops.

[0046] 2. TCAM array: Logic: This is the core of PEU. It's a huge table where each "cell" stores a policy rule (e.g., IF Role = Administrator AND Health != High Risk THEN Allow). What's special about TCAM is that each cell can store 0, 1, or "X" (it doesn't matter).

[0047] Circuit: Each TCAM unit consists of multiple transistors, capable of comparing the input key with its stored value in parallel. When the input key matches a (value, mask) stored in a row, that row outputs a '1' (match signal); otherwise, it outputs a '0'.

[0048] 3. Matching line: Logic: One line is drawn from each row of the TCAM array. During the search cycle, all matching lines are precharged to a high level. If a row does not match, its matching line is discharged to a low level; if it matches, it remains high.

[0049] Circuit: Physical metal wires connecting all TCAM units in a row.

[0050] 4. Priority encoder: Logic: Multiple policy lines may match simultaneously (e.g., a general policy and a more specific policy both match). The priority encoder scans all high-level matching lines and outputs the index of the line with the smallest address number (or the pre-defined highest priority).

[0051] Circuit: A combinational logic circuit whose inputs are multiple matching lines and whose output is the binary address of the matching line.

[0052] 5. Decision result storage: Logic: A small, high-speed SRAM. It uses the "row address" output by the priority encoder as the address to directly read the final decision action corresponding to that row (e.g., 00 = deny, 01 = allow, 10 = secondary authentication required).

[0053] Circuit: A small SRAM module.

[0054] 6. Reg-CAM and Keystream Verification: Logic: This is a separate CAM used to store recently used key blocks. When the key generator produces a new key block, the PEU sends it as the input key to the Reg-CAM.

[0055] Circuitry: Similar to the main TCAM, but possibly smaller. It checks all entries in parallel.

[0056] Results: If a match is found (meaning the key is duplicated), a "key conflict" signal is triggered, notifying the key generator to regenerate. If there is no match, the key is marked as secure and usable.

[0057] PEU workflow (within one clock cycle): 1. Loading: The attribute key is latched into the input register.

[0058] 2. Comparison: The input key is broadcast to the entire TCAM array. Comparisons are performed in parallel across all rows.

[0059] 3. Decision: After the matching line results stabilize, the priority encoder finds the highest priority matching line.

[0060] 4. Output: Based on the matching row address, read the action from the decision result memory and output it to the gateway.

[0061] The core concept of the attribute key input to the PEU in this invention is a fixed-length, binary digital signature that encapsulates all security context information of an access request. It is not plaintext, but rather a product of standardization and encoding by the gateway software. Attributes from different sources (such as IdP and EPP) and in different formats (such as the string "Admin" and the numerical score 85) are standardized into a fixed format. Fixed-length binary strings are more suitable for parallel hardware comparison in TCAM, improving efficiency and hiding the complexity of the policy from the hardware, which only needs to process 0s and 1s. For example, when a request arrives at the ZTNA gateway, the gateway's software module collects attributes from multiple policy information points in real time, then performs attribute encoding and key generation (gateway software -> PEP / PDP). The gateway's PDP (policy decision point) has an attribute encoding table, which is predefined and acts as a "dictionary" for both hardware and software. By looking up the collected attributes in the table to obtain the corresponding binary values, and then concatenating these binary values ​​bit by bit, a unique attribute key is obtained, which is the "attribute key" ultimately input into the PEU's TCAM for lookup.

[0062] Managing a TCAM is a software-driven process that spans multiple levels and involves the collaboration of various components. However, its command center is a central policy manager (usually located on a cloud management platform or local control center), rather than a single gateway itself. Detailed steps of the management process: Step 1: Policy Definition (Global Control Plane - Cloud / Central Platform) Location: The security administrator logs into a centralized cloud management platform (such as Zscaler ZeroTrust Portal, Cisco SecureX, or Palo Alto Networks Prisma Access).

[0063] Action: Administrators define advanced security policies through a graphical interface or a declarative language.

[0064] For example: Allow role = Finance Manager and device health > 80, access application = Finance System and resource sensitivity = High, and the geographical location must be on the company network.

[0065] Output: The platform generates a platform-independent, standardized policy description file (e.g., using JSON or a specific DSL).

[0066] Step 2: Policy compilation and distribution (Global -> Gateway control plane) 1. Distribution: The central platform distributes the new policy document to all relevant ZTNA gateways under its jurisdiction.

[0067] 2. Reception: The control plane (PDP component) of each gateway receives this policy file.

[0068] 3. Compilation (Critical Step): The compiler in the PDP software on the gateway begins working: Analyze advanced strategies; Query the local attribute coding table (the table where "Financial Manager" is changed to 011 and "High" is changed to 11); Generate the corresponding TCAM (value, mask) triples and decision actions; Calculate the priority to determine the physical location (row number) of this new entry in the TCAM array; Step 3: Hardware Configuration (Gateway Control Plane -> Gateway Data Plane) Action: The gateway's PDP writes the compiled TCAM entries to the TCAM array and decision result memory of the ESC Engine hardware through a secure, privileged driver and configuration bus (such as the PCIe configuration space or a dedicated memory-mapped I / O interface).

[0069] Features: This operation requires the highest level of system privileges, which are absolutely inaccessible to ordinary applications or users, ensuring the security of TCAM content.

[0070] Step 4: Policy Execution (Gateway Data Plane - Pure Hardware) Subsequently, the attributes of each data packet arriving at this gateway will be encoded into attribute keys and sent to TCAM.

[0071] TCAM completes matching and outputs a decision (allow / deny / re-authenticate) within nanoseconds without any software intervention.

[0072] This decision is directly returned to the gateway's PEP for executing connection actions.

[0073] The Security Context Memory Unit (SCU) is essentially an isolated, secure memory with a hardware manager.

[0074] Core components and data flow: 1. Hardware-isolated secure SRAM: Logical: A physically independent storage area, a memory region that cannot be directly accessed by a general-purpose CPU, used to store session keys and context.

[0075] Circuitry: Isolation is achieved from the port via a memory protection unit (MPU) and a dedicated system bus.

[0076] The Memory Protection Unit (MPU) / Address Decoder is a hardware circuit that checks the address of all access requests from the system bus. The MPU only allows access if the address of an access request from a specific, trusted module within the ESC Engine (such as the HDCSA) falls within the address range of the SCU; otherwise, it rejects the request.

[0077] Dedicated Slave Interface: The SCU has a dedicated slave port on the system bus (such as the AXI bus). The address range of this port is mapped to a protected range and only responds to transactions from authorized master devices.

[0078] FPGA implementation: In FPGAs, this is typically achieved in the following way: Block RAM (BRAM) using FPGA: One or more BRAMs are dedicated to the SCU. The BRAM itself is a physically independent storage unit.

[0079] Custom AXI Slave Controller: Design a custom AXI slave module that includes address decoding and access control logic. This logic verifies whether the AXI_AWID or AXI_ARID (transaction ID, which encodes master device information) is on the whitelist.

[0080] Firewall rules: In the AXI interconnect structure, you can set "firewall" rules to directly block illegal access paths at this layer.

[0081] 2. Hardware Dynamic Session Context Allocator (HDCSA): Logic: This is a "memory allocator" implemented in hardware logic, which manages the SCU SRAM memory pool, is responsible for the allocation and release of the isolated memory pool, and replaces software memory allocation (such as malloc / free) to achieve fast, deterministic and safe dynamic memory management.

[0082] Circuit: Free list register set: A set of hardware registers, each storing a pointer to a free memory block. For efficiency, a "segmented free list" strategy is used, that is, different lists are maintained for session contexts of different sizes (such as small sessions and large sessions).

[0083] Allocation State Machine: A hardwired state machine. When it receives an "allocation" request, it retrieves the first pointer from the corresponding free list register, returns it to the requester, and then updates the pointer value in the register.

[0084] 1. Received an "allocation" request and the required size.

[0085] 2. The state machine selects the corresponding free list based on the size.

[0086] 3. Retrieve the pointer from the head register of the list.

[0087] 4. Return the pointer to the requester and update the register value at the head of the list to the address of the next free block.

[0088] Release state machine: When it receives a "release" request (from ZTCU), it inserts the pointer of the memory block to be released back at the head of the corresponding free list.

[0089] 1. Received a "release" request and memory block pointer from ZTCU.

[0090] 2. The state machine inserts the memory block back into the head of the corresponding free list.

[0091] 3. Update the header register.

[0092] FPGA implementation: State Machine: A finite state machine is implemented using FPGA logic units (LUT, FF) to execute allocation and release algorithms.

[0093] Register set: Uses distributed RAM or registers to store the head pointers of multiple free lists.

[0094] Linked list management: The first few bytes of each free memory block are used to store the address of the next free block (i.e., an embedded linked list). HDCSA operates on these pointers.

[0095] 3. Secure data pathway: Objective: To ensure that sensitive data (such as keys) is not eavesdropped on when it is transmitted within the ESC Engine.

[0096] Logic: A dedicated point-to-point data bus is established between the PEU (Key Generator), SCU (Secure BRAM), and the encryption engine. This bus does not pass through the shared system bus, thus isolating it from other potentially compromised modules in the system.

[0097] Circuitry: These pathways are private, bypassing the main system bus of the gateway and connecting directly within the ESC Engine, reducing the possibility of eavesdropping. During FPGA placement and routing, manual placement constraints can be used to physically place these related modules (PEU, SCU, encryption core) closer together, ensuring that the traces between them are as short as possible and do not pass through untrusted areas.

[0098] 3. Instantaneous Reset and Safety Control Unit (ZTCU) Circuit Logic The ZTCU is essentially an event-driven, ultra-high-speed erase controller.

[0099] Core components and data flow: 1. Event listeners and triggers: Logic: Continuously monitor multiple event sources: Software trigger: "Session terminate" command from the gateway software.

[0100] Hardware trigger: "Continuous verification failed" signal from PEU.

[0101] Physical trigger: Signals from physical tamper-proof sensors (such as chassis switches, temperature sensors, voltage glitch detectors).

[0102] Circuit: A set of input pins and simple logic gates are used to detect the rising edge or level change of the above signal.

[0103] 2. Clear control state machine: Logic: Once a triggering event is detected, this state machine immediately starts the clearing sequence.

[0104] Circuit: A hardwired state machine that generates the following control signals: Send a "ready to release" signal to the HDCSA of the SCU.

[0105] Send a clear mode signal to the SCU SRAM.

[0106] 3. Instantaneous reset circuit (the core of the core): Logic: This is key to achieving nanosecond-level zeroing. There are two main methods: Forced SRAM charge removal: Using an additional transistor, when the reset signal is active, the bit line of the SRAM cell is momentarily short-circuited to the bit line NOT, or it is forcibly pulled to a specific level (VDD or GND), thus destroying its stored charge state. This process is very fast, typically completed within a few clock cycles.

[0107] MBIST Zeroing Assist: Utilizes the "memory built-in self-test" circuitry already present during chip testing. MBIST typically has the function of writing a specific pattern (such as all zeros) to all addresses. ZTCU can hijack this function, triggering MBIST to perform a "write all zeros" operation on the target SRAM block.

[0108] 4. Dynamic Noise Generator (DNG): Logic: During sensitive operations (such as key generation), random electrical noise is generated to overwhelm the actual power consumption and electromagnetic characteristics.

[0109] Circuit: A pseudo-random number generator whose output drives an analog switch to rapidly switch the charging and discharging of some redundant logic gates or capacitors, thereby generating wideband noise on the power line.

[0110] ZTCU workflow: 1. Trigger: Detect any reset trigger signal.

[0111] 2. Addressing: Obtain the address of the memory block that needs to be zeroed from HDCSA or the event source.

[0112] 3. Execution: Within a single or a few clock cycles, the "instantaneous clear circuit" is activated to apply a clear voltage / MBIST mode to the SRAM cell at the target address.

[0113] 4. Confirmation: After the zeroing is completed, notify HDCSA that the memory block is safe and can be reclaimed.

[0114] In summary, the circuit logic of the PEU is "parallel comparison -> priority decision". The circuit logic of the SCU is "hardware isolation -> hardware management allocation". The circuit logic of the ZTCU is "event listening -> triggering instantaneous physical erase". Together, these three components compress the "query-decision-allocation-cleanup" process, which requires thousands of instructions in the software, into a hardware pipeline operation controlled by hard-wired logic that is completed within a few clock cycles, thereby achieving orders-of-magnitude performance improvements and enhanced security. Example 2

[0115] like Figure 2 and Figure 3 As shown, this embodiment provides a secure session hardware acceleration method based on a zero-trust architecture. The method is implemented based on the system described above and includes the following steps: Step S1: The gateway control platform parses the access request, generates an attribute key, and transmits the attribute key to the hardware data platform. Step S2: After receiving the attribute key, the policy TCAM module completes the "allow / deny" decision within nanoseconds through parallel matching and priority encoder. If the decision is to deny, the process ends; otherwise, proceed to step S3. Step S3: Generate a temporary session key and verify its uniqueness; Step S4: Allocate space in the secure SRAM module isolated from the general system environment through the HDCSA hardware dynamic allocator, and store the temporary session key and the corresponding context in the space; Step S5: Establish an encrypted data channel and perform session processing; Step S6: Monitor the session in real time. When a session terminates or a corresponding event signal occurs, trigger the instantaneous clearing circuit to destroy the specified memory data in nanoseconds. Step S7: Reclaim the memory block and terminate the session. Only after ZTCU confirms that the sensitive data in the target memory block has been completely destroyed will the HDCSA logic mark the memory block as available and reclaim it to the free list.

[0116] Preferably, step S6 specifically includes: real-time monitoring of the entire session process; if a session terminates normally (session logical termination) occurs, a session lifecycle management signal is sent to the temporary clearing and control unit ZTCU through the gateway main CPU module to trigger the destruction of specified memory data. If the verification fails continuously (the PEU decision changes the existing connection state to Deny), the temporary zeroing and control unit ZTCU is triggered through the high-speed policy execution unit PEU to destroy the specified memory data. In the event of physical tampering, the temporary zeroing and control unit ZTCU is triggered by the sensor to destroy the specified memory data. Specifically, to destroy the specified memory data, the ZTCU immediately activates its dedicated instantaneous hardware zeroing circuit to perform nanosecond-level (<10 ns) charge removal or MBIST zeroing operations on the SCU memory block corresponding to the session.

[0117] The technical solutions provided in this application embodiment have at least the following technical effects or advantages: The ESC Engine described in this invention, through deep collaboration and functional hardening of three hardware units—PEU, SCU, and ZTCU—builds a zero-trust security gateway hardware acceleration engine that integrates ultra-high-speed policy decision-making, hardware-level key protection, and instantaneous data lifecycle management. This fundamentally solves the core challenges faced by ZTNA in high-performance, high-security scenarios and provides a key hardware foundation for large-scale, high-level security zero-trust network deployment.

[0118] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A secure session hardware acceleration system based on a zero-trust architecture, characterized in that: The system includes a gateway control platform and a hardware data platform; The gateway control platform includes a policy management module (PAP), a policy decision module (PDP), and a gateway main CPU control unit. The strategy management module (PAP) is used to send strategy intents to the strategy decision module (PDP). The policy decision module (PDP) is used to compile high-level policies into TCAM-recognizable (value, mask) pairs and transmit the compiled policies to the hardware data platform via the bus. The gateway main CPU control unit is used to process data plane services and session management, and to send session lifecycle management signals to the hardware data platform; The hardware data platform includes a Secure Session Context Acceleration Engine (ESC Engine) and an encryption engine. The Secure Session Context Acceleration Engine (ESC Engine) includes a High-Speed ​​Policy Execution Unit (PEU), a Secure Context Storage Unit (SCU), and a Temporary Clearing and Control Unit (ZTCU). The high-speed policy execution unit (PEU) is used to perform nanosecond-level policy decision-making after receiving the attribute key and generate a security key for the security context storage unit (SCU). The Security Context Storage Unit (SCU) is used to provide hardware-isolated secure storage for dynamic session contexts and is zeroed out under the control of the ZTCU. The temporary zeroing and control unit ZTCU is used to listen for trigger events and control the security context storage unit SCU to instantly destroy sensitive data. The encryption engine is used to process the encryption and decryption of application data, including obtaining the session key of the Security Context Storage Unit (SCU) and receiving / sending data streams to the High-Speed ​​Policy Execution Unit (PEU).

2. The system according to claim 1, characterized in that: The hardware data platform is mounted on an FPGA chip and connected to the gateway control platform via PCIe and a network port.

3. The system according to claim 1, characterized in that: The high-speed policy execution unit (PEU) specifically includes a policy TCAM module, a priority encoder, a decision result RAM, a key generator, and a Reg-CAM module. The policy TCAM module is used to receive attribute keys, complete all policy rule matching within a single clock cycle, and output the matching line results to the priority encoder. The priority encoder is used to select the highest priority address to the decision result RAM when multiple rules are matched. The decision result RAM is used to store the final action corresponding to each policy rule, and outputs the action according to the address of the priority encoder; The key generator is activated after the policy allows, generates a key block, and sends it to the Reg-CAM module; The Reg-CAM module is used to verify the uniqueness of the key, and after successful verification, it is sent to the Security Context Storage Unit (SCU).

4. The system according to claim 1, characterized in that: The Security Context Storage Unit (SCU) includes an HDCSA hardware dynamic allocator, a secure SRAM module, and a memory protection unit (MPU). The HDCSA hardware dynamic allocator is used to manage the allocation of secure SRAM and, in conjunction with the temporary zeroing and control unit ZTCU, reclaims memory after zeroing. The secure SRAM module is used to store session keys and context, and to receive temporary clear signals and clear signals from the control unit ZTCU; The memory protection unit (MPU) is used to restrict access to the secure SRAM module, allowing only authorized master devices to access it and intercepting illegal access requests.

5. The system according to claim 1, characterized in that: The temporary zeroing and control unit (ZTCU) includes a tamper-proof sensor interface, a session management signal receiver, a zeroing control state machine, a dynamic noise generator, and an instantaneous zeroing circuit. The tamper-proof sensor interface is used to receive tamper alarms from the chassis and environmental sensors, and converts physical attack signals into the highest priority reset trigger signal; The session management signal receiver is used to receive session lifecycle management signals sent by the gateway main CPU control unit; The reset control state machine is used to receive different trigger signals and initiate the reset sequence; The dynamic noise generator is activated during operations such as key generation and clearing to actively generate random noise, masking the chip's power consumption and electromagnetic characteristics during sensitive operations. The instantaneous zeroing circuit is used to physically zero a specified address of the secure SRAM module.

6. A hardware acceleration method for secure sessions based on a zero-trust architecture, characterized in that: The method is implemented based on the system described in any one of claims 1-5, and the method includes the following steps: Step S1: The gateway control platform parses the access request, generates an attribute key, and transmits the attribute key to the hardware data platform. Step S2: After receiving the attribute key, the policy TCAM module completes the "allow / deny" decision within nanoseconds through parallel matching and priority encoder. If the decision is to deny, the process ends; otherwise, proceed to step S3. Step S3: Generate a temporary session key and verify its uniqueness; Step S4: Allocate space in the secure SRAM module isolated from the general system environment through the HDCSA hardware dynamic allocator, and store the temporary session key and the corresponding context in the space; Step S5: Establish an encrypted data channel and perform session processing; Step S6: Monitor the session in real time. When a session terminates or a corresponding event signal occurs, trigger the instantaneous clearing circuit to destroy the specified memory data in nanoseconds. Step S7: Reclaim the memory block and terminate the session.

7. The method according to claim 6, characterized in that: Step S6 specifically includes: real-time monitoring of the entire session process; if the session terminates normally, a session lifecycle management signal is sent to the temporary clearing and control unit ZTCU through the gateway main CPU module to trigger the destruction of specified memory data. If the verification fails continuously, the temporary zeroing and control unit ZTCU will be triggered by the high-speed policy execution unit PEU to destroy the specified memory data. If the alteration is physical, the temporary reset and control unit ZTCU will be triggered by the sensor to destroy the specified memory data.

Images