A trusted access system for open interconnection in the Lingqu Interconnection system

Abstract

This invention relates to the field of heterogeneous interconnection and hardware security technology, specifically to a trusted access system for open interconnection within the Lingqu interconnection system. The system includes third-party devices, an internal Lingqu interconnection network, and an IO interconnection chip deployed between the two. The IO interconnection chip, acting as a trusted access gateway, includes: a control and management module for port link establishment, authentication, authorization, and key switching; a security management module for generating a root key and deriving session keys based on a hardware trust root; and a data plane processing module for authentication tag verification, replay detection, and anomaly isolation and demotion. This invention uses the IO interconnection chip as a hardware-level trusted access gateway to achieve tight coupling between authentication and port, blocking unauthorized access; it also relies on fine-grained replay protection per channel to ensure performance and security; and it supports fine-grained isolation during anomalies, reducing operational complexity and balancing hardware trust, high performance, and business continuity.

Description

Technical Field

[0001] This invention relates to the field of heterogeneous interconnection and hardware security technology, specifically to a trusted access system for open interconnection of the Lingqu interconnection system. Background Technology

[0002] As computer architecture evolves towards heterogeneous computing and decoupling, interconnect architectures are shifting from closed and homogeneous to open and diversified. The UnifiedBus (UB) interconnect system, as an open interconnect architecture, aims to build a unified interconnect ecosystem, supporting the access of heterogeneous devices from different types and manufacturers, encompassing various hardware resources such as third-party GPUs, network interface cards (NICs), switches or interconnect devices, dedicated accelerators, and storage controllers. These devices can access the unified interconnect domain through various physical bearer forms, including in-package interconnects, chip-to-chip (C2C) interconnects, and network interconnects (such as UB over Ethernet, UBoE). In engineering implementation, IO interconnect chips (such as IO Dies or interconnect SoCs) serve as key components on the access side, responsible for providing diverse port types, implementing protocol adaptation and bridging, and carrying interconnect-related control and forwarding functions, thereby achieving seamless connection between heterogeneous devices and the interconnect domain at the hardware level.

[0003] However, in open access scenarios, existing interconnect security mechanisms are ill-equipped to address the new security challenges brought about by the openness of the supply chain and the universality of interfaces, and mainly suffer from the following significant shortcomings: 1) Lack of hardware-level closed-loop trusted access control points. Usually, access devices are trusted by default or managed by software whitelists. It is difficult to block unauthorized and counterfeit devices at the hardware level when devices are connected. The security boundary is vague and the attack response is delayed. 2) The authentication and authorization mechanism is not tightly coupled with the link establishment process of different port forms (such as encapsulation, C2C, network interconnection). This not only introduces additional protocol interaction overhead, but also makes it difficult to effectively bind link configuration parameters to authentication credentials, leaving opportunities for downgrade attacks, tampering and replay attacks. 3) Anti-replay protection often uses a single counter or coarse-grained sliding window. In multi-queue (such as virtual channel VC), multi-channel and out-of-order concurrent transaction models, it is easy to make misjudgments or force the window to be widened, resulting in a reduction in security protection strength or serious impact on interconnection performance. 4) Key rotation lacks effective guarantees for business continuity. The rotation process usually requires interrupting the link, rebuilding the connection, or waiting for all in-transit transactions to complete. It relies heavily on software intervention and can cause unacceptable business jitter in latency-sensitive systems. 5) When security events such as authentication failure, replay anomalies, or key inconsistencies occur, existing solutions often adopt coarse-grained handling methods such as hard disconnection of the entire link or complete system restart. They lack fine-grained isolation and demotion strategies based on port, channel, or transaction type. They also lack standardized event cause codes and statistical telemetry capabilities, which greatly increases the complexity of operation and maintenance and system recovery time.

[0004] The above reasons together make it difficult for existing technologies to simultaneously meet the multi-dimensional security requirements of hardware-level trusted access, tightly coupled protocol security, high-performance anti-replay, seamless key rotation for services, and refined isolation and maintenance in open and heterogeneous interconnection domains. Summary of the Invention

[0005] To address the above technical problems, this invention provides a technical solution for a trusted access system for open interconnection in the Lingqu Interconnection system.

[0006] The technical problem solved by this invention can be achieved using the following technical solution: A trusted access system for open interconnection of the Lingqu Interconnection system, comprising a third-party device, an internal Lingqu interconnection network, and an IO interconnection chip. The IO interconnection chip, acting as a trusted access gateway, is deployed between the third-party device and the internal Lingqu interconnection network. The IO interconnection chip includes: a control management module, used for establishing and negotiating port links with the third-party device, identity authentication, authorization decisions, and key version switching management; a security management module, connected to the control management module, used for generating root keys and device identifiers based on hardware trust roots, and deriving session keys based on random numbers exchanged by the control management module during identity authentication; and a data plane processing module, connected to the security management module, used for generating or verifying authentication tags for data plane packets or micro-chips, performing anti-replay detection by channel or queue, and performing isolation or demotion operations when abnormal events occur.

[0007] Preferably, the control and management module includes: a link establishment and authentication state machine, used to establish or negotiate a port link with the third-party device and perform identity authentication with the third-party device; a policy and authorization unit, connected to the link establishment and authentication state machine, used to determine the access permission range of the third-party device based on the identity information and policy configuration of the third-party device; and a key rotation unit, connected to both the link establishment and authentication state machine and the policy and authorization unit, wherein the key rotation unit supports parallel key versioning and is used to complete key rotation without downtime; the security management module includes: a hardware trust root unit, used to generate a root key and device identifier based on a one-time programmable memory, an electronic fuse, or physically cloning-unique technology; and a session key derivation unit, connected to both the one-time programmable memory, an electronic fuse, or a physically cloning-unique technology. The component trust root unit and the key rotation unit are used to generate session keys based on the root key and the random numbers exchanged with the authentication state machine during the identity authentication process, and derive subkeys; the data plane processing module includes: a data plane authentication tag unit, connected to the session key derivation unit, used to generate or verify authentication tags for the data plane messages or micro-pieces, wherein the authentication tag is a message authentication code or an authentication encryption tag with associated data; an anti-replay unit, connected to the data plane authentication tag unit, used to maintain an anti-replay window by channel or queue to perform anti-replay detection; and an isolation and degrading unit, connected to the data plane authentication tag unit and the key rotation unit respectively, used to perform rate limiting, closing, rejection or disconnection operations by port, channel or transaction type when an abnormal event occurs.

[0008] Preferably, the link establishment and authentication state machine specifically performs the following operations: after establishing, training, or negotiating a port link with the third-party device, it enters a state capable of carrying control information and generates a link parameter summary, which includes rate, channel mapping, negotiation capability, and training results; it exchanges an access declaration with the third-party device, which includes a device identifier, a local random number, a device capability summary, and the link parameter summary; and it receives an authentication certificate sent by the third-party device, the expression of which is: AUTH_PROOF= MAC / signature(DeviceID || nonce_D || nonce_IO || link_params_digest || capability_digest), Wherein, AUTH_PROOF represents authentication proof, MAC represents message authentication code, DeviceID represents device identifier, nonce_D represents the first random number generated by the third-party device, nonce_IO represents the second random number generated by the IO interconnect chip, link_params_digest represents link parameter digest, capability_digest represents capability digest, and || represents cascading operation; The authentication certificate is verified to complete the identity authentication of the third-party device, and the authentication result is returned to the third-party device. The expression for the authentication result is: AUTH_RESULT (OK / FAIL), AUTH_RESULT represents the authentication result, OK indicates successful authentication, and FAIL indicates authentication failure.

[0009] Preferably, the policy and authorization unit performs the following operations: receiving the device identity, device capability summary, and port type of the third-party device transmitted by the link establishment and authentication state machine; and, based on a pre-configured least privilege policy, invoking an authorization decision function to generate an authorization decision, wherein the expression of the authorization decision function is: Authorization(Identity, Capability, PortType, Polity), Wherein, Authorization represents the authorization decision function, Identity represents the device identity, Capability represents the device capability summary, PortType represents the port type, and Polity represents the least privilege policy. The least privilege policy is: only the control channel is opened before authorization is granted, and the data channel is opened only after authorization is granted. Based on the authorization decision, an allow list or a disallow rule is output, expressed as: AllowList(channel / transaction / permission) + EnforceRules Here, AllowList represents the set of resources that are allowed to be used after authorization is granted, including port sessions, channels or queues, transaction types or command sets; EnforceRules represents the enforcement rules that are executed when authorization is denied or restricted, including denying access, rate limiting or isolation.

[0010] Preferably, the key rotation unit performs the following operations: entering a preparation state to generate or load key materials for the next key version; entering a dual reception state to simultaneously receive data plane messages or micro-pieces of the current key version and the next key version, and maintaining independent anti-replay windows for the current key version and the next key version respectively; entering a submission state after the switching conditions are met to switch the next key version to the current key version and clear the old key version state; and entering a rollback state when key rotation fails to revert to the next key version and trigger isolation or retry operations.

[0011] Preferably, the session key derivation unit performs the following operations: receiving the root key provided by the hardware trust root unit and the first and second random numbers exchanged by the link establishment and authentication state machine during the identity authentication process; and calling the key derivation function to generate a session key, wherein the expression of the key derivation function is: KeyDerive(nonce_D, nonce_IO, RootKey), Wherein, KeyDerive represents the key derivation function, nonce_D represents the first random number, nonce_IO represents the second random number, and RootKey represents the root key; a data plane subkey, a control plane subkey, and a key update subkey are derived from the session key; the data plane subkey is passed to the data plane authentication tag unit, the control plane subkey is passed to the control management module, and the key update subkey is passed to the key rotation unit.

[0012] Preferably, the anti-replay unit performs the following operations: establishing an anti-replay window for each channel or queue, the anti-replay window including a window base sequence number and a bitmap; receiving data plane messages or micro-pieces and extracting the data sequence number carried by the data plane messages or micro-pieces; determining whether the data sequence number meets a preset condition: BaseSeq≤Seq≤BaseSeq +W - 1, where BaseSeq represents the window base sequence number, Seq represents the data sequence number, and W represents the width of the bitmap; when the preset condition is met, calculating the offset: Offset = Seq - BaseSeq is used to check the value of the Offset bit in the bitmap. If the value of the Offset bit in the bitmap is 0, the data plane message or micro-piece is received and the Offset bit in the bitmap is set to 1. If the value of the Offset bit in the bitmap is 1, a replay exception is triggered. When the data sequence number exceeds the preset condition, sliding or resynchronization is triggered, the window base sequence number is updated, the slide-out bit of the bitmap is cleared to zero, and the currently received data plane message or micro-piece is processed according to the offset calculation method.

[0013] Preferably, the IO interconnect chip further includes a telemetry and auditing module, which is connected to the data plane processing module and is used to collect and output the cause code, counter value, key rotation status and abnormal mode summary of abnormal events.

[0014] Preferably, the I / O interconnect chip integrates multiple port forms, including in-package interconnect ports, board-level or system-level chip-to-chip interconnect ports, and network interconnect ports; the third-party device accesses the I / O interconnect chip through the port forms; the Lingqu internal interconnect network is used to receive traffic authenticated and authorized by the I / O interconnect chip.

[0015] A trusted access method for open interconnection in the Lingqu Interconnection system, applied to a trusted access system for open interconnection in the Lingqu Interconnection system as described above, includes: Step S1, the IO interconnection chip and a third-party device perform port link establishment, training, or negotiation, and generate a link parameter digest; Step S2, the IO interconnection chip and the third-party device exchange access declarations, the access declarations including device identifier, local random number, device capability digest, and the link parameter digest; Step S3, the IO interconnection chip receives and verifies the authentication certificate provided by the third-party device to complete the identity authentication of the third-party device, and returns the authentication result to the third-party device; Step S4, the IO interconnection chip, based on the device identity and device... The system generates an authorization decision based on the capability summary, port type, and pre-configured minimum permission policy, and outputs an allowed list or a non-compliance rule based on the authorization decision; Step S5: The IO interconnect chip generates a session key based on the root key and the local random number exchanged during the authentication process, and derives a sub-key from the session key; Step S6: The IO interconnect chip generates or verifies authentication tags for data plane packets or micro-chips, and maintains an anti-replay window by channel or queue to perform anti-replay detection; Step S7: The IO interconnect chip issues update materials through the control channel, enters the key version parallel period, performs non-stop key rotation, switches the next key version to the current key version after the switching conditions are met, and enters a rollback state and triggers isolation or retry operations when the switching fails.

[0016] Beneficial effects: This invention deploys the IO interconnect chip as a hardware-level trusted access gateway, constructing a closed-loop access control point at the physical level. When third-party devices access the network, it achieves tight coupling between identity authentication and port configuration based on a hardware root of trust and dynamically derived keys, effectively blocking unauthorized and counterfeit device access and eliminating the risks of downgrade attacks and replay tampering. Simultaneously, relying on a fine-grained anti-replay detection mechanism based on channels or queues, this invention maintains strict security strength while ensuring high-performance processing of out-of-order transactions across multiple queues. Furthermore, key version switching management avoids link interruptions and service jitter during the rotation process. In addition, this invention supports fine-grained isolation or demotion operations in the event of abnormal events, replacing the traditional hard disconnection of the entire link, significantly reducing operational complexity and recovery time.

[0017] As can be seen, in open and heterogeneous interconnection scenarios, this invention systematically takes into account key security requirements such as hardware-level trusted access, tightly coupled protocol security, high-performance anti-replay, seamless key rotation for services, and refined isolation and maintenance. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of the Lingqu Open Access System structure of the present invention; Figure 2 This is a block diagram of the trusted access internal functional modules of the IO interconnect chip of the present invention; Figure 3 This is a timing diagram of port link establishment coupling authentication in this invention; Figure 4 This is the state machine diagram of the anti-replay window and key version parallel period of the present invention; Figure 5 This is a flowchart of the method of the present invention. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0021] The present invention will be further described below with reference to the accompanying drawings and specific embodiments, but this is not intended to limit the scope of the invention.

[0022] Reference Figure 1 and Figure 2This invention provides a trusted access system for open interconnection within the Lingqu interconnection system, comprising a third-party device, a Lingqu internal interconnection network 200, and an IO interconnection chip 100. The IO interconnection chip 100 serves as a trusted access gateway, deployed between the third-party device and the Lingqu internal interconnection network 200. The IO interconnection chip 100 includes: a control management module 110, used for establishing and negotiating port links with the third-party device, identity authentication, authorization decisions, and key version switching management; a security management module 120, connected to the control management module 110, used for generating root keys and device identifiers based on hardware trust roots, and deriving session keys based on random numbers exchanged by the control management module 110 during identity authentication; and a data plane processing module 130, connected to the security management module 120, used for generating or verifying authentication tags for data plane packets or micro-chips, performing anti-replay detection by channel or queue, and performing isolation or demotion operations when abnormal events occur.

[0023] Specifically, in this embodiment of the invention, in open interconnection scenarios, the lack of hardware-level trusted access control, security vulnerabilities caused by the decoupling of authentication mechanisms and port links, the difficulty in balancing anti-replay protection strength and performance under multi-queue transaction models, the interruption of business continuity due to key rotation, and the difficulty in maintaining coarse-grained security event handling are addressed by deploying the IO interconnection chip 100 as a trusted access gateway, integrating control management, security management, and data plane processing modules 130. Hardware root of trust (RoT) is used to achieve tight coupling authentication of device identity and port link status, fine-grained anti-replay detection is performed by channel or queue, and business-insensitive key version switching and fine-grained isolation and demotion under abnormal events are supported. This avoids system security gaps and performance losses caused by access blind spots, degradation attacks, replay misjudgments, key rotation jitter, and hard disconnection of the entire link. It achieves unified collaboration of hardware-level trusted access, tightly coupled protocol security, high-performance anti-replay, business continuity, and fine-grained operation and maintenance in heterogeneous open interconnection domains.

[0024] Specifically, in actual deployment, the IO interconnect chip 100 (IO, Input / Output) UnifiedBus (UB) access-side gateway provides one or more UB port forms, such as in-package interconnect ports, board-level or system-level chip-to-chip interconnect ports, and network interconnect ports (e.g., UBoE), and performs trusted access and security control. The physical connection establishment or negotiation process of different port forms may be different, but the trusted access logic of the present invention can be reused within the IO interconnect chip 100.

[0025] Accordingly, refer to Figure 1Third-party devices access various heterogeneous computing or storage units of the I / O interconnect chip 100 through the aforementioned port configuration. These third-party devices manifest as multiple Unified Processing Units (UBPUs), specifically: a central processing unit (CPU) 301, a neural network processing unit (NPU) 302, a storage processing unit (SSU) 303, a graphics processing unit (GPU) 304, a switch 305, a network interface card (NIC) 306, a data processing unit (DPU) 307, a memory 308, a co-processor 309, and a domain-specific processor 310. The CPU 301 internally includes a CPU core and a cache, while the neural network processing unit 302 internally includes an artificial intelligence (AI) core. The CORE and Cache memory, the storage processing unit 303 includes a storage processor (Storage) and a high-bandwidth memory (HBM), and the graphics processing unit 304 includes a graphics processor (Graphics) and a high-bandwidth memory (HBM). Each Lingyu protocol processing unit (UBPU) is connected to the Lingyu input / output interface (UBIO) through its internal on-chip network (NoC), and after trusted access through the IO interconnect chip 100, it enters the Lingqu internal interconnect network 200 (UB Fabric). The UB Fabric is used to receive traffic authenticated and authorized by the IO interconnect chip 100. The UBIO is the port side of the IO interconnect chip 100, responsible for trusted access interaction with the UB Fabric. The Lingqu input / output interface (UBIO) further includes a Lingyu controller (UBController) and a Lingyu memory management unit (UMMU) inside the IO interconnect chip 100, which are used to complete security and forwarding functions such as link control, identity authentication and address mapping.

[0026] In a preferred embodiment of the present invention, the control management module 110 includes: a link establishment and authentication state machine 111 (Bring-up+Auth FSM), used to establish or negotiate coupling with the third-party device and perform identity authentication with the third-party device; a policy and authorization unit 112 (Policy / Authorization), connected to the link establishment and authentication state machine 111, used to determine the access permission range of the third-party device based on the identity information and policy configuration of the third-party device; and a key rotation unit 113 (Epoch Manager), connected to the link establishment and authentication state machine 111 and the policy and authorization unit 112 respectively, wherein the key rotation unit 113 supports parallel key versioning and is used to complete key rotation without downtime; the security management module 120 includes: a hardware trust root unit 121, used to generate a root key and device identifier based on a one-time programmable memory, electronic fuse, or physically cloning-unique technology; and a session key derivation unit 122 (Key The Derivation module (DEM) is connected to the hardware trust root unit 121 and the key rotation unit 113, respectively, and is used to generate a session key based on the root key and the random number exchanged between the link establishment and authentication state machine 111 during the identity authentication process, and derive a sub-key; the data plane processing module 130 includes: a data plane authentication tag unit 131 (Tagger / Verifier), connected to the session key derivation unit 122, used to generate or verify authentication tags for the data plane messages or micro-pieces, wherein the authentication tag is a message authentication code or an authentication encryption tag with associated data; an anti-replay unit 132 (Replay Engine), connected to the data plane authentication tag unit 131, used to maintain an anti-replay window by channel or queue to perform anti-replay detection; and an isolation and degrading unit 133 (Isolation / Quarantine), connected to the data plane authentication tag unit 131 and the key rotation unit 113, used to perform rate limiting, closing, rejection or disconnection operations by port, channel or transaction type when an abnormal event occurs.

[0027] Specifically, in order to achieve hardware-level trusted access, dynamic security policies, and seamless key management for business applications in open interconnection scenarios, refer to Figure 2 In this embodiment of the invention, the IO interconnect chip 100 establishes tight coupling between control plane authentication and port links, derives multi-level keys based on hardware trust roots, and coordinates with the data plane to perform anti-replay and isolation weight reduction in a channel-by-channel fine-grained manner, thus constructing a closed-loop security architecture covering authentication, encryption, key rotation and anomaly handling.

[0028] Specifically, firstly, an integrated state machine for port link establishment and authentication is adopted, tightly coupling the third-party device authentication process with the physical port link establishment or negotiation process. After the link parameter negotiation is completed, a link parameter digest (link_params_digest) is generated and bound to subsequent authentication exchanges, effectively preventing downgrade attacks and link tampering. Secondly, after the third-party device is authenticated, the policy and authorization unit 112 dynamically determines the authorization scope and executes the least privilege opening mechanism based on its device identity, capability digest, port type, and pre-configured policies. This ensures that the system only opens the control channel before authentication and authorization, and opens the corresponding data channel according to the authorization scope after authentication and authorization, achieving precise granting of permissions and effective contraction of the attack surface. Then, based on hardware information... The root unit 121 forms a root key and a device identifier (DeviceID), and combines this with the random number exchanged by the link establishment and authentication state machine 111 during the authentication process. The session key derivation unit 122 then generates a link or port session key, further deriving data subkeys, control subkeys, and update subkeys, thereby achieving hierarchical isolation and flexible management of keys. Simultaneously, the data plane authentication tag unit 131, based on the derived data subkeys, generates or verifies authentication tags for each data plane packet or flit, using Message Authentication Code (MAC) or Authentication Encryption Algorithm (AEAD) with associated data to ensure the integrity and confidentiality of the data plane. The fields of the data plane packet or flit include: Channel / Queue Identifier (Channel_ID / ... VC_ID: Used to identify the virtual channel or queue to which the message belongs, supporting concurrent processing of multiple queues and independent security context management by channel; Key Version (Epoch): Identifies the key version number used by the current message, supporting the parallel existence and identification of multiple key versions during key rotation; Data Sequence Number (Seq): Also known as the anti-replay sequence number, which, together with the key version, constitutes the integrity input for anti-replay detection, used for accurate deduplication in a sliding window; Authentication Tag (Tag): A MAC or AEAD authentication tag generated based on the data plane subkey, used by the receiver to verify the integrity and authenticity of the message; Optional Additional Authentication Data (AAD) The key rotation unit 113 carries metadata that needs to be authenticated but does not need to be encrypted (such as channel identifier, message length, control information, etc.), which is included in the authentication tag calculation scope along with the payload. The payload is the actual data content transmitted, which is protected by encryption when encryption is enabled. Then, since the key rotation unit 113 supports key version parallel period (i.e., epoch parallel period), it can receive the current version key and the next version key at the same time without interrupting the service. After the submission conditions are met, it performs a smooth switch and automatically rolls back and triggers isolation or retry when the switch fails, thereby effectively avoiding link jitter and service interruption during the key rotation process.Furthermore, the anti-replay unit 132 independently maintains a sliding window, namely the anti-replay window (BaseSeq+Bitmap), for each channel or queue (such as virtual channel VC, stream, etc.). This ensures accurate anti-replay detection under an out-of-order multi-queue transaction model, avoiding false positives and performance degradation. Finally, an isolation and deweighting unit 133 is designed to perform rate limiting, closing, rejection, or disconnection operations based on port, channel, or transaction type in the event of authentication failure, replay anomalies, or key inconsistencies. This replaces the traditional hard disconnection of the entire link, significantly reducing operational complexity and recovery time.

[0029] In a preferred embodiment of the present invention, the link establishment and authentication state machine 111 performs the following operations: after establishing, training or negotiating a port link with the third-party device, it enters a state capable of carrying control information and generates a link parameter summary, which includes rate, channel mapping, negotiation capability and training results; it exchanges an access declaration with the third-party device, which includes device identifier, local random number, device capability summary and the link parameter summary. Receive the authentication certificate sent by the third-party device, wherein the expression of the authentication certificate is: AUTH_PROOF= MAC / signature(DeviceID || nonce_D || nonce_IO || link_params_digest || capability_digest), Wherein, AUTH_PROOF represents authentication proof, MAC represents message authentication code, DeviceID represents device identifier, nonce_D represents the first random number generated by the third-party device, nonce_IO represents the second random number generated by the IO interconnect chip 100, link_params_digest represents link parameter digest, capability_digest represents capability digest, and || represents cascading operation; The authentication certificate is verified to complete the identity authentication of the third-party device, and the authentication result is returned to the third-party device. The expression for the authentication result is: AUTH_RESULT (OK / FAIL), AUTH_RESULT represents the authentication result, OK indicates successful authentication, and FAIL indicates authentication failure.

[0030] Specifically, in this embodiment of the invention, the link establishment and authentication state machine 111, as the core component of the control and management module 110, is responsible for tightly coupling the identity authentication process with the physical port link establishment process, so as to ensure that the third-party device completes hardware-level identity verification and authorization binding after completing link training and before the actual data channel is opened.

[0031] Specifically, refer to Figure 3The link establishment and authentication state machine 111 first performs port link establishment (bring-up), training or negotiation operations with the third-party device, completing rate negotiation, lane mapping, capability exchange and training result confirmation. After the link reaches a stable state that can carry control messages or control fragments, it generates a link parameter digest link_params_digest. This link_params_digest covers key parameters such as rate, lane mapping, negotiation capabilities and training results, which are used for subsequent authentication binding to prevent downgrade attacks and link tampering. Then, the link establishment and authentication state machine 111 exchanges access declarations AUTH_HELLO bidirectionally with the third-party device.The access declaration AUTH_HELLO includes the message type MsgType and version number Version, device identifier (DeviceID or its fingerprint, hash), random number nonce_local, capability digest capability_digest, link parameter digest link_params_digest, and other optional extended fields Options; correspondingly, the third-party device sends an AUTH_HELLO message to the IO interconnect chip 100, with the expression: AUTH_HELLO(DeviceID, nonce_D, capability_digest, ... The link establishment and authentication state machine 111 of the IO interconnect chip 100 also sends an AUTH_HELLO message to the third-party device, with the expression: AUTH_HELLO(DeviceID, nonce_IO, capability_digest, link_params_digest), which carries the device ID of the IO interconnect chip 100, the second random number nonce_IO generated by the IO interconnect chip 100, the device capability_digest, and the aforementioned link parameter digest link_params_digest. The link establishment and authentication state machine 111 receives the authentication certificate AUTH_PROOF sent by the third-party device. This authentication certificate AUTH_PROOF is generated by the third-party device based on its hardware root of trust. Its message authentication code MAC or digital signature binds the device identifier, random numbers from both parties, capability digest, and link parameter digest, and can optionally carry extended information such as certificate chain Options, thereby effectively resisting link parameter degradation, capability spoofing, and replay attacks. In scenarios requiring two-way authentication, the IO interconnect chip 100 can also generate its own authentication certificate based on the same structure and send it to the third-party device to achieve trusted mutual recognition at both ends of the link. Subsequently, the link establishment and authentication state machine 111 verifies the authentication certificate AUTH_PROOF at the hardware level. After successful verification, it completes the identity authentication of the third-party device and returns the authentication result AUTH_RESULT to the third-party device. If authentication is successful, the link establishment and authentication state machine 111 will transmit the authentication success result, along with the device identity, capability information, and link parameters, to the policy and authorization unit 112 for subsequent authorization determination; if authentication fails, the link establishment and authentication state machine 111 will maintain an isolated state and refuse to open the data channel.

[0032] In this way, the link establishment and authentication state machine 111 integrates link parameters, random number exchange, two-way identity declaration and authentication verification into a tightly coupled state machine process, which can effectively ensure that third-party devices complete hardware-level trusted access authentication after the physical port link is established and before the actual data path is opened, thus laying a trusted foundation for subsequent key derivation, authorization decision and data plane security protection.

[0033] In a preferred embodiment of the present invention, the policy and authorization unit 112 performs the following operations: receiving the device identity, device capability summary, and port type of the third-party device transmitted by the link establishment and authentication state machine 111; and, based on a pre-configured least privilege policy, invoking an authorization decision function to generate an authorization decision, wherein the expression of the authorization decision function is: Authorization(Identity, Capability, PortType, Polity), Wherein, Authorization represents the authorization decision function, Identity represents the device identity, Capability represents the device capability summary, PortType represents the port type, and Polity represents the least privilege policy. The least privilege policy is: only the control channel is opened before authorization is granted, and the data channel is opened only after authorization is granted. Based on the authorization decision, an allow list or a disallow rule is output, expressed as: AllowList(channel / transaction / permission) + EnforceRules Here, AllowList represents the set of resources that are allowed to be used after authorization is granted, including port sessions, channels or queues, transaction types or command sets; EnforceRules represents the enforcement rules that are executed when authorization is denied or restricted, including denying access, rate limiting or isolation.

[0034] Specifically, in this embodiment of the invention, the strategy and authorization unit 112, as a key component of the control and management module 110, is responsible for executing fine-grained authorization decisions based on the principle of least privilege after the link establishment and authentication state machine 111 completes the authentication of the third-party device, thereby ensuring that the data channel is only opened as needed after the authentication and authorization are passed.

[0035] Specifically, refer to Figure 3First, after the link establishment and authentication state machine 111 completes the authentication of the third-party device, it transmits the successful authentication result, along with the third-party device's device identity, device capability summary, and the port type currently used for access, to the policy and authorization unit 112. After receiving the above information, the policy and authorization unit 112 combines the system's pre-configured least privilege policy, calls the authorization decision function Authorization to make an authorization determination, and generates a clear authorization result based on the output of the authorization decision function.

[0036] If authorization is granted, the allowed list (AllowList) will be output, with the expression: AllowList(channel / transaction / permission), The AllowList specifies in detail the set of resources that are allowed after authorization, such as allowed port sessions, allowed channels or queues (such as virtual channels VC), allowed transaction types or command sets, and corresponding access permissions. At the same time, the policy and authorization unit 112 sends the AllowList to the data plane processing module 130 so that access control for subsequent data plane forwarding can be executed. It also instructs the link establishment and authentication state machine 111 to open the data channel (open (control-only)) while keeping the control channel open, thereby realizing the least privilege opening strategy of "opening the control channel first and then the data channel". If authorization is denied or restricted, then enforce rules (EnforceRules) are output, with the following expression: EnforceRules (deny access / rate limit / isolate), At this time, the policy and authorization unit 112 will trigger corresponding actions according to the enforcement rules (EnforceRules), including denying access, limiting the rate of specific channels or transaction types, or putting the port or device into isolation, thereby ensuring that unauthorized devices cannot obtain data channel access capabilities. Through the close cooperation between the policy and authorization unit 112 and the link establishment and authentication state machine 111, the device identity, capability summary, port type and least privilege policy are organically combined. After authentication, precise authorization decisions and resource allocation are executed, providing a complete closed loop from identity verification to permission control for the entire trusted access system. This effectively ensures the security of heterogeneous device access in open interconnection scenarios, minimizes the attack surface and controls resource access.

[0037] In a preferred embodiment of the present invention, the session key derivation unit 122 performs the following operations: receiving the root key provided by the hardware trust root unit and the first random number and the second random number exchanged by the link establishment and authentication state machine 111 during the identity authentication process; and calling the key derivation function to generate a session key, wherein the expression of the key derivation function is: KeyDerive(nonce_D, nonce_IO, RootKey), Wherein, KeyDerive represents the key derivation function, nonce_D represents the first random number, nonce_IO represents the second random number, and RootKey represents the root key; a data plane subkey, a control plane subkey, and a key update subkey are derived from the session key; the data plane subkey is passed to the data plane authentication tag unit, the control plane subkey is passed to the control management module 110, and the key update subkey is passed to the key rotation unit 113.

[0038] Specifically, in this embodiment of the invention, the session key derivation unit 122, as the core component of the security management module 120, is responsible for generating the session key and its subkeys based on the hardware root of trust and the random numbers exchanged during the authentication process after authentication and authorization are passed. This provides cryptographic protection materials for subsequent control plane, data plane and key updates, and strictly follows the security sequence of "authentication and authorization first, key derivation second, and finally opening the channel with the least privilege".

[0039] Specifically, refer to Figure 3First, after the link establishment and authentication state machine 111 completes the identity authentication of the third-party device, and the policy and authorization unit 112 completes the authorization decision and confirms the authorization, the session key derivation unit 122 receives the root key RootKey provided by the hardware trust root unit 121, and simultaneously receives the first random number nonce_D and the second random number nonce_IO exchanged by the link establishment and authentication state machine 111 during the identity authentication process. Next, the session key derivation unit 122 calls the key derivation function KeyDerive to generate the session key SK_link. By using both random numbers and the root key as input, it ensures that the generated session key is session-unique and valid only for this authentication. Then, the session key derivation unit 122 further derives three subkeys from the generated session key: SK_data: a data plane subkey used for the generation and verification of authentication tags for data plane packets or flits; SK_ctrl: a control plane subkey used for authentication protection of control plane messages; and SK_update: a key update subkey. The key is used for updating material protection during the key rotation process. Simultaneously, each subkey is bound to a key version Epoch to support parallel management of multiple key versions. After key derivation is complete, the session key derivation unit 122 transmits the data plane subkey SK_data to the data plane authentication tag unit 131 for subsequent line-rate encryption / decryption or tag verification of the data plane; it transmits the control plane subkey SK_ctrl to the control management module 110 to protect authentication messages and key update instructions in the control channel; and it transmits the key update subkey SK_update to the key rotation unit 113 to support seamless key rotation operations for subsequent business applications. Specifically, the entire key derivation process occurs after the authorization decision is passed and before the actual data channel is opened. According to the least privilege policy, only the control channel is open at this time to carry control plane protection messages after key derivation. The formal opening of the data channel must be executed after key derivation is completed and the authorized list is issued, thereby ensuring that all data plane traffic is transmitted under session key protection, avoiding unprotected data leakage or unauthorized access.

[0040] Through the aforementioned session key derivation unit 122, the hardware root of trust, authentication random number and key derivation function are combined to generate and distribute key materials after authentication and authorization and before data channel opening. This provides the entire trusted access system with a strict security sequence of "authentication first, authorization later, key derivation later, and data channel opening finally", effectively ensuring the confidentiality, integrity and least privilege principle of data plane and control plane in open interconnection scenarios.

[0041] In a preferred embodiment of the present invention, the key rotation unit 113 performs the following operations: enters a preparation state to generate or load key materials for the next key version; enters a dual reception state to simultaneously receive data plane messages or micro-pieces of the current key version and the next key version, and maintains independent anti-replay windows for the current key version and the next key version respectively; enters a submission state after the switching conditions are met, switches the next key version to the current key version, and clears the old key version state; and enters a rollback state when key rotation fails, cancels the next key version, and triggers isolation or retry operations.

[0042] Specifically, in this embodiment of the invention, the key rotation unit 113, as a key component of the control and management module 110, preferably adopts a key rotation state machine, which is responsible for completing the smooth update of the session key without interrupting the service. By introducing a key version parallel period (i.e., epoch parallel period) mechanism, it realizes fine control and abnormal rollback processing of the key rotation process, thereby ensuring link continuity and data plane security.

[0043] Specifically, refer to Figure 4 The key rotation state machine first enters the PREPARE state. In the PREPARE state, the key rotation unit 113 generates or loads the key material for the next key version (next epoch) according to the key rotation triggering conditions, such as time period, traffic threshold, or policy triggering. The key material includes the session key of the next key version and its derived data plane subkey, control plane subkey, and key update subkey. Then, the key rotation state machine enters the DUAL_ACCEPT state. In the DUAL_ACCEPT state, the key rotation unit 113 simultaneously receives data plane messages or micro-pieces of the current key version (cur epoch) and the next key version (next epoch), and maintains independent anti-replay windows for the current key version and the next key version respectively.

[0044] When the key rotation state machine meets the switching conditions (such as stable operation of the dual-receive state for more than a preset time window and no abnormal events related to the next key detected during the parallel period), it enters the COMMIT state. In the COMMIT state, the key rotation state machine officially switches the next key version to the current key version, updates the active key version number used by the data plane and control plane, and clears the anti-replay window and other state information corresponding to the old key version, thereby completing the seamless key rotation. If an abnormality occurs in the preparation state or dual-receive state (such as key derivation failure, authentication verification error, detection of replay attack or key inconsistency during the parallel period), the key rotation state machine enters the ROLLBACK state, cancels all key materials of the next key version and the associated anti-replay window state, keeps the current key version working, and triggers isolation or retry operations according to the type of abnormality. For example, it notifies the isolation and deweighting unit 133 to perform rate limiting, shutdown or disconnection on the relevant ports or channels, or re-initiates the key rotation process, thereby ensuring that the link can still maintain secure communication capability when the key rotation fails, and avoiding the interruption of the entire link due to rotation abnormality.

[0045] As can be seen, the key rotation unit 113, through the finite state machine design of "preparation-dual acceptance-commit / rollback" and the parallel processing mechanism of independently maintaining anti-replay windows for different key versions, realizes seamless switching of business traffic during key rotation and has the ability to quickly roll back and finely isolate when an anomaly occurs, effectively supporting the business continuity and security robustness of key management in open interconnection scenarios.

[0046] In a preferred embodiment of the present invention, the anti-replay unit 132 performs the following operations: establishing an anti-replay window for each channel or queue, the anti-replay window including a window base sequence number and a bitmap; receiving data plane messages or micro-pieces and extracting the data sequence number carried by the data plane messages or micro-pieces; determining whether the data sequence number meets a preset condition: BaseSeq ≤ Seq ≤ BaseSeq + W - 1, where BaseSeq represents the window base sequence number, Seq represents the data sequence number, and W represents the width of the bitmap; when the preset condition is met, calculating the offset: Offset = Seq -BaseSeq, and check the value of the Offset bit in the bitmap. If the value of the Offset bit in the bitmap is 0, then receive the data plane message or micro-piece and set the Offset bit in the bitmap to 1; if the value of the Offset bit in the bitmap is 1, then trigger a replay exception; when the data sequence number exceeds the preset condition, trigger sliding or resynchronization, update the window base sequence number, clear the slide-out bit of the bitmap to zero, and process the currently received data plane message or micro-piece according to the offset calculation method.

[0047] Specifically, in this embodiment of the invention, the anti-replay unit 132, as the core component of the data plane processing module 130, is responsible for maintaining an independent anti-replay window by channel or queue, accurately performing anti-replay detection under the out-of-order multi-queue transaction model, avoiding misjudgment and performance loss, and working in conjunction with the key rotation unit 113 to support anti-replay protection under the parallel period of multiple key versions.

[0048] Specifically, refer to Figure 4 The anti-replay unit 132 establishes an independent anti-replay window for each channel or queue (such as a virtual channel VC, stream, etc.). Each window consists of a window base sequence number BaseSeq and a bitmap, where the bitmap width is W (i.e., the window size), used to record the reception status of each sequence number within the window. When a data plane message or micro-piece is received, the anti-replay unit 132 extracts the key version Epoch and data sequence number Seq from it, and selects the corresponding anti-replay window for detection based on the current stage of the key rotation state machine (such as single-key mode or cur / next parallel period). When the key rotation unit 113 is in the parallel period, the anti-replay unit 132 maintains two independent windows for the current key version and the next key version simultaneously, thereby ensuring that legitimate messages are not discarded due to version changes during the smooth key switching process. For the selected anti-replay window, the anti-replay unit 132 first determines whether the data sequence number Seq meets the preset condition: BaseSeq ≤ Seq ≤ BaseSeq + W - 1. When the preset condition is met, the anti-replay unit 132 calculates the offset Offset and checks the value of the Offset bit in the bitmap. If the value of the bit is 0, it means that the data sequence number Seq has not received any data. At this time, the data sequence number Seq receives the data plane message or micro-piece and sets the Offset bit in the bitmap to 1, i.e., set bit(Seq-BaseSeq). If the value of the bit is 1, it means that the data sequence number Seq has received data, and a replay exception is triggered, the data is discarded and an alarm is reported. When the data sequence number Seq does not meet the above preset condition (i.e., Seq < BaseSeq or Seq > BaseSeq + W - 1), the anti-replay unit 132 triggers a sliding or resynchronization process. Specifically: for the case where Seq > BaseSeq + W - 1, the window slides forward, the window base sequence number BaseSeq is updated to the new base value, and the corresponding bit of the window that slides out of the bitmap is cleared to zero. Then, the current packet is processed according to the offset calculation method. For the case where Seq < BaseSeq, depending on the system configuration, it can be regarded as an expired packet and discarded directly, or a resynchronization negotiation mechanism is triggered to re-align the sequence number space, so as to ensure safety while being compatible with out-of-order and packet loss retransmission scenarios.

[0049] In this way, the anti-replay unit 132 can independently maintain an anti-replay window for each channel or queue. Combined with the dual-window mechanism under the parallel key rotation period, accurate and efficient anti-replay detection is achieved in the out-of-order multi-queue transaction model. This avoids the decrease in security strength caused by relaxing the window and prevents the impact on interconnection performance due to misjudgment, thus providing a reliable guarantee for data plane security in open interconnection scenarios.

[0050] As a preferred embodiment of the present invention, refer to Figure 2 The IO interconnect chip 100 also includes a telemetry and audit module 140, which is connected to the data plane processing module 130 and is used to collect and output the cause code, counter value, key rotation status and abnormal mode summary of abnormal events.

[0051] Specifically, considering the diverse types of heterogeneous devices and complex security events in open interconnection scenarios, the traditional coarse-grained hard-disconnection method is difficult to provide effective fault location and operation and maintenance support. Based on this, in this embodiment of the invention, a telemetry and auditing module 140 is further designed. This telemetry and auditing module 140 is an optional functional component connected to the data plane processing module 130 to collect and output multi-dimensional security and operation status information, providing standardized data support for system operation and maintenance, anomaly tracing and strategy optimization.

[0052] The telemetry and auditing module 140 mainly outputs the following information: Reason Code: Classifies and encodes security events such as authentication failure, replay anomalies, key inconsistencies, and authorization denials, carrying the event type, trigger port, channel identifier, and specific failure reason, facilitating rapid identification of the root cause by the upper-level management system; Counter Values: Statistics are compiled by port, channel, and event type for key indicators such as the number of successful / failed authentications, the number of replay attacks, the number of successful / failed key rotations, and the number of isolation triggers, supporting real-time monitoring and threshold alarms; Key Rotation Status: Records the current stage of the key rotation unit (e.g., PREPARE, DUAL_ACCEPT, COMMIT, ROLLBACK), the current key version, the duration of the parallel period, and the switching result, assisting in evaluating the health status of key rotation and the effectiveness of business continuity assurance; Anomaly Pattern Summary: Generates anomaly pattern summary by aggregating and analyzing the time series, frequency, distribution channels, and correlations of anomaly events, such as repeated authentication failures on a certain port within a short period or sudden replay attacks on a certain channel, providing a decision-making basis for dynamic adjustment of security policies (e.g., automatic triggering of isolation or rate limiting).

[0053] As can be seen, the telemetry and auditing module 140 outputs underlying security events to the upper-level operation and maintenance system in a structured manner, making the originally "black box" trusted access process observable. When a security event occurs, it can achieve problem location and strategy optimization within minutes or even seconds, which significantly reduces the operation and maintenance complexity and system recovery time under the open interconnection architecture.

[0054] Reference Figure 5 The present invention also includes a trusted access method for open interconnection of the Lingqu Interconnection system, applied to a trusted access system for open interconnection of the Lingqu Interconnection system as described above, comprising: Step S1, the IO interconnection chip 100 performs port link establishment, training or negotiation with a third-party device, and generates a link parameter digest; Step S2, the IO interconnection chip 100 exchanges an access declaration with the third-party device, the access declaration including a device identifier, a local random number, a device capability digest and the link parameter digest; Step S3, the IO interconnection chip 100 receives and verifies the authentication certificate provided by the third-party device to complete the identity authentication of the third-party device, and returns the authentication result to the third-party device; Step S4, the IO interconnection chip 100, based on the device of the third-party device... Step S5: The IO interconnect chip 100 generates an authorization decision based on the identity, device capability summary, port type, and pre-configured least privilege policy, and outputs an allowed list or a disallowed rule based on the authorization decision; Step S6: The IO interconnect chip 100 generates a session key based on the root key and the local random number exchanged during the authentication process, and derives a sub-key from the session key; Step S7: The IO interconnect chip 100 generates or verifies authentication tags for data plane packets or micro-chips, and maintains an anti-replay window by channel or queue to perform anti-replay detection; Step S8: The IO interconnect chip 100 issues update materials through the control channel, enters the key version parallel period, performs non-stop key rotation, switches the next key version to the current key version after the switching conditions are met, and enters a rollback state and triggers isolation or retry operations when the switching fails.

[0055] The following specific embodiment describes the complete implementation process of the aforementioned third-party device gaining trusted access to the Lingqu internal interconnection network 200 through the IO interconnection chip 100: Example 1: A third-party GPU / NIC / Switch connects to the UB's trusted access via the IO interconnect chip 100. Object: Third-party devices access the Lingqu internal interconnection network 200 through a certain UB port of the IO interconnection chip 100. The IO interconnection chip 100 acts as an access gateway, providing control and data channels (which can be mapped to multiple channels, queues, or virtual channels VC). The specific execution steps are as follows: Step 1: Establish port link The IO interconnect chip 100 completes port link establishment and negotiation with third-party devices, and generates link parameter digest link_params_digest.

[0056] Step 2: Swap AUTH_HELLO Both parties exchange DeviceID, nonce, capability_digest, and the previously generated link_params_digest.

[0057] Step 3: Verify AUTH_PROOF and grant authorization The IO interconnect chip 100 verifies AUTH_PROOF. If the verification is successful, the allowed channels, transaction ranges, etc. are determined according to the policy; if the verification fails, isolation is maintained.

[0058] Step 4: Derive session key and enable with minimum privileges The IO interconnect chip 100 derives the data face key SK_data, the control face key SK_ctrl, or the key update subkey SK_update. Only the control channel is opened before authentication, and the data channel is opened after successful authentication.

[0059] Step 5: Line-speed Tag Verification and Anti-replay Data plane messages or satellite images carry the key version Epoch, data sequence number Seq, or authentication tag; the IO interconnect chip 100 performs line-speed verification and window judgment replay, and triggers isolation or demotion when an anomaly occurs.

[0060] Step 6: Non-stop key rotation Updated materials are distributed through the control channel, entering the epoch parallel period. At the same time, the current version (cur) and the next version (next) keys are received, and the switch is performed after the submission conditions are met. In case of failure, the rollback is performed and the system is isolated or retried.

[0061] In summary, this invention proposes a trusted access system for open interconnection in the Lingqu Interconnection system. By deploying the IO interconnection chip 100 as a hardware-level trusted access gateway located at the entrance of the interconnection domain, it integrates a unified state machine for link establishment and authentication, a multi-level key derivation mechanism based on hardware trust roots, a line-speed data plane authentication and channel-based anti-replay engine, a service-insensitive key rotation unit supporting parallel periods, and a fine-grained isolation and deweighting module 140 as well as a telemetry and auditing module. This constructs a closed-loop security architecture that covers physical port access, identity authentication, authorization decision-making, data plane protection, key lifecycle management, and anomaly handling.

[0062] Compared with the prior art, the present invention has the following significant effects: Prior blocking and hardware-level trusted access: Using the IO interconnect chip 100 as the access access point, the identity authentication and authorization decision supported by the hardware trust root is completed during the port link establishment stage, realizing prior blocking of unauthorized and counterfeit devices, fundamentally solving the problems of vague security boundaries and delayed attack response in traditional solutions; Authentication and link tightly coupled: The authentication process is deeply integrated with the port link establishment, training or negotiation process. By binding the link parameter summary with the authentication certificate, it effectively resists downgrade attacks, link tampering and replay replication, while reducing extra handshake round trips and improving access efficiency and determinism. Linear-speed fine-grained anti-replay: The anti-replay window is maintained independently by channel or queue based on the window reference number and bitmap. It achieves accurate replay detection under the premise of supporting multi-channel, multi-queue, and concurrent out-of-order transaction models, avoiding misjudgment or security strength loss caused by traditional coarse-grained sliding windows, and balancing high performance and high security. Seamless key rotation for business operations: Through the parallel key version mechanism, the system supports the parallel reception of the current and next version keys and the maintenance of independent windows without interrupting business operations. It can smoothly switch after the submission conditions are met and automatically roll back in case of failure, effectively ensuring the semantics of transaction completion in transit and the continuous operation of the system. Fine-grained isolation and maintainability: In the event of security incidents such as authentication failure, replay anomalies, or key inconsistencies, it supports fine-grained handling such as rate limiting, closing, rejection, or disconnection based on port, channel, or transaction type, replacing the traditional hard disconnection of the entire link, significantly reducing the fault propagation radius and system recovery time; at the same time, through the telemetry and auditing modules, it outputs standardized cause codes, counters, rotation status, and abnormal mode summaries, providing observable support for operation and maintenance and policy optimization in open interconnection scenarios; Security boundary convergence: All critical security operations (authentication, key derivation, tag generation and verification, anti-replay, key rotation, and isolation disposal) are completed within the hardware security boundary of the IO interconnect chip 100. Key materials are not exposed to the software stack, which effectively reduces the risk of key leakage and dependence on complex software, meeting the lightweight and high security requirements of the open heterogeneous interconnect ecosystem.

[0063] The above description is merely a preferred embodiment of the present invention and does not limit the implementation and protection scope of the present invention. Those skilled in the art should realize that any equivalent substitutions and obvious changes made based on the description and illustrations of the present invention should be included within the protection scope of the present invention.

Claims

1. A trusted access system for open interconnection in the Lingqu Interconnection System, characterized in that, This includes third-party devices, Lingqu's internal interconnect network, and I / O interconnect chips. The IO interconnect chip, acting as a trusted access gateway, is deployed between the third-party device and the Lingqu internal interconnect network. The IO interconnect chip includes: The control and management module is used for establishing and negotiating port links with the third-party device, identity authentication, authorization decisions, and key version switching management. The control and management module includes a key rotation unit, which performs the following operations: Enter the preparation state and generate or load the key materials for the next key version; Entering a dual-reception state, it simultaneously receives data plane messages or micro-pieces of the current key version and the next key version, and maintains independent anti-replay windows for the current key version and the next key version respectively; Once the switching conditions are met, the system enters the submission state, switches the next key version to the current key version, and clears the old key version status. If key rotation fails, the system enters a rollback state, cancels the next key version, and triggers isolation or retry operations. The security management module, connected to the control management module, is used to generate a root key and device identifier based on the hardware trust root, and to derive a session key based on the random number exchanged by the control management module during the identity authentication process. The data plane processing module, connected to the security management module, is used to generate or verify authentication tags for data plane messages or micro-pieces, perform anti-replay detection by channel or queue, and perform isolation or demotion operations when abnormal events occur. The data plane processing module includes an anti-replay unit, which establishes an anti-replay window for each channel or queue to perform anti-replay detection.

2. The trusted access system for open interconnection of the Lingqu Interconnection System according to claim 1, characterized in that, The control and management module includes: A link establishment and authentication state machine is used to establish or negotiate coupling with the third-party device, and to perform identity authentication with the third-party device. The policy and authorization unit, connected to the link establishment and authentication state machine, is used to determine the access permission range of the third-party device based on the identity information and policy configuration of the third-party device; The key rotation unit is connected to the link establishment and authentication state machine and the policy and authorization unit, respectively. The key rotation unit supports parallel key versioning and is used to complete key rotation without stopping the system. The security management module includes: Hardware trust root unit, used to generate root keys and device identifiers based on one-time programmable memory, electronic fuses, or physically unclonable technologies; The session key derivation unit is connected to the hardware trust root unit and the key rotation unit, respectively. It is used to generate a session key based on the root key and the random number exchanged between the link establishment and authentication state machine during the identity authentication process, and derive a subkey. The data plane processing module includes: The data plane authentication tag unit, connected to the session key derivation unit, is used to generate or verify authentication tags for the data plane message or micro-chip. The authentication tag is a message authentication code or an authentication encryption tag with associated data. An anti-replay unit, connected to the data plane authentication tag unit, is used to maintain an anti-replay window by channel or queue to perform anti-replay detection; The isolation and de-weighting unit is connected to the data plane authentication tag unit and the key rotation unit, respectively, and is used to perform rate limiting, closing, rejection or disconnection operations according to port, channel or transaction type when an abnormal event occurs.

3. A trusted access system for open interconnection of the Lingqu Interconnection System according to claim 2, characterized in that, The link establishment and authentication state machine performs the following operations: After establishing, training, or negotiating a port link with the third-party device, the system enters a state capable of carrying control information and generates a link parameter summary, which includes rate, channel mapping, negotiation capability, and training results. Exchange access claims with the third-party device, the access claims including device identifier, local random number, device capability summary and link parameter summary; Receive the authentication certificate sent by the third-party device, wherein the expression of the authentication certificate is: AUTH_PROOF= MAC / signature(DeviceID || nonce_D || nonce_IO || link_params_digest || capability_digest), Wherein, AUTH_PROOF represents authentication proof, MAC represents message authentication code, DeviceID represents device identifier, nonce_D represents the first random number generated by the third-party device, nonce_IO represents the second random number generated by the IO interconnect chip, link_params_digest represents link parameter digest, capability_digest represents capability digest, and || represents cascading operation; The authentication certificate is verified to complete the identity authentication of the third-party device, and the authentication result is returned to the third-party device. The expression for the authentication result is: AUTH_RESULT (OK / FAIL), AUTH_RESULT represents the authentication result, OK indicates successful authentication, and FAIL indicates authentication failure.

4. A trusted access system for open interconnection of the Lingqu Interconnection System according to claim 2, characterized in that, The strategy and authorization unit performs the following operations: Receive the device identity, device capability summary, and port type of the third-party device transmitted by the link establishment and authentication state machine; Based on the pre-configured least privilege policy, an authorization decision function is invoked to generate an authorization decision. The expression of the authorization decision function is as follows: Authorization(Identity, Capability, PortType, Polity), Wherein, Authorization represents the authorization decision function, Identity represents the device identity, Capability represents the device capability summary, PortType represents the port type, and Polity represents the least privilege policy. The least privilege policy is as follows: only the control channel is opened before authorization is granted, and the data channel is opened only after authorization is granted. Based on the authorization decision, the output will either allow a list (AllowList) or not pass the enforcement rules (EnforceRules). The AllowList represents the set of resources that are allowed to be used after authorization. The set of resources includes allowed port sessions, allowed channels or queues, allowed transaction types or command sets, and corresponding access permissions. The EnforceRules, which do not specify the enforcement rules to be executed when authorization is denied or restricted, include denial of access, rate limiting, or isolation.

5. A trusted access system for open interconnection of the Lingqu Interconnection System according to claim 2, characterized in that, The session key derivation unit performs the following operations: Receive the root key provided by the hardware trust root unit and the first and second random numbers exchanged by the link establishment and authentication state machine during the identity authentication process; The key derivation function is invoked to generate the session key, and the expression of the key derivation function is: KeyDerive(nonce_D, nonce_IO, RootKey), Where KeyDerive represents the key derivation function, nonce_D represents the first random number, nonce_IO represents the second random number, and RootKey represents the root key; The data face key, control face key, and key update subkey are derived from the session key; The data plane subkey is transmitted to the data plane authentication tag unit, the control plane subkey is transmitted to the control management module, and the key update subkey is transmitted to the key rotation unit.

6. A trusted access system for open interconnection of the Lingqu Interconnection System according to claim 2, characterized in that, The anti-replay unit performs the following operations: An anti-replay window is established for each channel or queue, and the anti-replay window includes a window reference number and a bitmap; Receive data plane messages or micro-pieces, and extract the data sequence number carried by the data plane messages or micro-pieces; Determine whether the data sequence number meets the preset condition: BaseSeq ≤ Seq ≤ BaseSeq + W - 1, where BaseSeq represents the window base sequence number, Seq represents the data sequence number, and W represents the width of the bitmap; When the preset condition is met, the offset is calculated: Offset = Seq - BaseSeq, and the value of the Offset bit in the bitmap is checked. If the value of the Offset bit in the bitmap is 0, the data plane message or chip is received and the Offset bit in the bitmap is set to 1; if the value of the Offset bit in the bitmap is 1, a replay exception is triggered. When the data sequence number exceeds the preset condition, a sliding or resynchronization is triggered, the window reference sequence number is updated, the slide-out bit of the bitmap is cleared to zero, and the currently received data plane message or micro-piece is processed according to the offset calculation method.

7. A trusted access system for open interconnection of the Lingqu Interconnection System according to claim 1, characterized in that, The I / O interconnect chip also includes a telemetry and auditing module, which is connected to the data plane processing module and is used to collect and output the cause code, counter value, key rotation status and abnormal mode summary of abnormal events.

8. A trusted access system for open interconnection of the Lingqu Interconnection System according to claim 1, characterized in that, The I / O interconnect chip integrates multiple port forms, including in-package interconnect ports, board-level or system-level chip-to-chip interconnect ports, and network interconnect ports. The third-party device connects to the I / O interconnect chip through the port configuration; The Lingqu internal interconnect network is used to receive traffic that has been authenticated and authorized by the IO interconnect chip.

9. A trusted access method for open interconnection in the Lingqu interconnection system, characterized in that, A trusted access system for open interconnection of the Lingqu Interconnection system as described in any one of claims 1-8, comprising: Step S1: The IO interconnect chip establishes, trains, or negotiates a port link with a third-party device and generates a link parameter summary. Step S2, the IO interconnect chip exchanges an access declaration with the third-party device, the access declaration including a device identifier, a local random number, a device capability summary, and a link parameter summary; Step S3: The IO interconnect chip receives and verifies the authentication certificate provided by the third-party device to complete the identity authentication of the third-party device, and returns the authentication result to the third-party device; Step S4: The IO interconnect chip generates an authorization decision based on the device identity, device capability summary, and port type of the third-party device and the pre-configured least privilege policy, and outputs an allowed list or a disqualification rule based on the authorization decision; Step S5: The IO interconnect chip generates a session key based on the root key and the local random number exchanged during the authentication process, and derives a subkey from the session key; Step S6: The IO interconnect chip generates or verifies authentication tags for data plane packets or microchips, and maintains anti-replay windows by channel or queue to perform anti-replay detection. In step S7, the IO interconnect chip sends out updated materials through the control channel, enters the key version parallel period, performs non-stop key rotation, and switches the next key version to the current key version after the switching conditions are met. If the switching fails, it enters the rollback state and triggers isolation or retry operation.

Images