Node access trusted authentication method for coherent hub interface protocol

Abstract

The present application relates to the field of chip security, and provides a node access trusted authentication method for coherent hub interface protocol, which comprises the following steps: a security management and control node receives an authentication request message sent by a request node of a new chain, wherein the authentication request message multiplexes reserved fields in a request channel of the coherent hub interface protocol to carry to-be-authenticated information; the security management and control node analyzes the authentication request message, performs trusted identity authentication on the request node based on the to-be-authenticated information, and generates an authentication result; when the authentication result is successful, the security management and control node notifies the source identifier of the request node to each master node in the system, and receives confirmation responses returned by each master node; and the security management and control node returns an authentication response message to the request node according to the authentication result. The present application solves the problem of lack of unified trusted identity authentication in the prior art for multi-core system-on-chip node access, and realizes unified node access trusted authentication based on the CHI protocol.

Description

Technical Field

[0001] This invention relates to the field of chip security, and in particular to a trusted authentication method for node access oriented to a coherent hub interface protocol. Background Technology

[0002] The Coherent Hub Interface (CHI) protocol is a next-generation AMBA bus protocol defined by ARM, widely used in high-performance multi-core System-on-Chip (SoC) systems to achieve efficient cache-coherent communication between multi-core processors and between the processor and external devices. Under the CHI protocol architecture, the system includes different types of nodes such as Request Nodes (RNs) and Home Nodes (HNs), and each node interacts with data through physical links such as the Request Channel (REQ Channel) and Data Channel (DAT Channel).

[0003] Currently, in multi-core on-chip systems, once a new node powers on and initializes or is connected to the system via hot-plugging and completes link initialization with the link establishment module, existing technologies typically allow the node to communicate directly with the master node without any authentication process. While some multi-core chip designs have introduced trusted authentication functions, such as using distributed verification schemes based on digital certificates, setting up independent authentication modules in each region and implementing cross-domain node authentication via custom or standard buses, these schemes are not deeply integrated with the native architecture of the CHI protocol. This requires the additional deployment of heterogeneous authentication systems, increasing system integration complexity. Furthermore, the lack of a unified authentication receiving node leads to chaotic addressing of authentication requests from new nodes, making it difficult to achieve standardized identity access control.

[0004] Therefore, how to provide a unified, low-overhead trusted authentication mechanism for multi-core on-chip systems while adhering to the CHI protocol specifications, in order to identify the legitimacy of access nodes and prevent illegal or malicious nodes from causing security risks such as data leakage or business tampering to the system, is an important issue that the industry urgently needs to address. Summary of the Invention

[0005] This invention provides a trusted authentication method for node access based on the coherent hub interface protocol, which solves the problem of lack of unified trusted identity authentication for node access in multi-core on-chip systems in the prior art, and realizes unified trusted authentication for node access based on the CHI protocol.

[0006] This invention provides a node access trusted authentication method for coherent hub interface protocols, comprising the following steps: The security control node receives an authentication request message sent by the requesting node of the newly established chain. The authentication request message uses a reserved field in the request channel of the coherent hub interface protocol to carry the authentication information. The security control node parses the authentication request message, performs trusted identity authentication on the requesting node based on the authentication information, and generates an authentication result; When the authentication result is successful, the security control node notifies each master node in the system of the source identifier of the requesting node and receives the confirmation response returned by each master node. The security control node returns an authentication response message to the requesting node based on the authentication result; Wherein, the authentication result indicates that the requesting node has successfully obtained the permission to communicate with the master node.

[0007] According to the present invention, a node access trusted authentication method for a coherent hub interface protocol is provided. Before the security management node receives the authentication request message sent by the requesting node of the newly established chain, the method further includes: the requesting node of the newly established chain completing link initialization with the security management node; obtaining the request packet sent by the requesting node of the newly established chain; determining whether the opcode of the request packet is a preset authentication request opcode; if not, discarding the request packet; if so, performing compliance processing on the request packet and sending the processed request packet as the authentication request message to the security management node.

[0008] According to the present invention, a node access trusted authentication method for a coherent hub interface protocol is provided. The compliance processing of the request packet includes the following steps: modifying the service quality priority field of the request packet to the lowest priority; modifying the target identifier field of the request packet to the source identifier value of the security management node; and modifying the request transaction identifier field of the request packet to a preset value.

[0009] According to the present invention, a node access trusted authentication method for a coherent hub interface protocol is provided. The security management node parses the authentication request message, performs trusted identity authentication on the requesting node based on the information to be authenticated, and generates an authentication result. Specifically, the method includes: determining whether it is an authentication request based on the opcode of the authentication request message, and discarding it if it is not; caching the information to be authenticated in the authentication request message into a buffer data structure corresponding to the source identifier based on the source identifier; generating an authentication packet when the authentication information segment corresponding to the source identifier is received completely or the reception times out; and performing trusted identity authentication on the authentication packet to generate an authentication result.

[0010] According to the present invention, a node access trusted authentication method for a coherent hub interface protocol is provided. When the authentication result is successful, the security management node notifies the source identifier of the requesting node to each master node in the system. Specifically, the method includes: the security management node generating a broadcast notification message, the broadcast notification message reusing the request channel of the coherent hub interface protocol, its operation code being a preset broadcast notification operation code, and its reserved field carrying the source identifier of the successfully authenticated requesting node; and sending the broadcast notification message to each master node respectively.

[0011] According to the present invention, a node access trusted authentication method for a coherent hub interface protocol is provided, wherein a threshold module is provided at the entry point of the master node, and the threshold module maintains an identifier threshold record table; the method further includes: the threshold module receiving a request packet sent by the requesting node of the newly established chain; determining whether the source identifier in the request packet exists in the identifier threshold record table; if it exists, the request packet is allowed to access the master node; if it does not exist, it further determines whether the source identifier of the request packet is the source identifier of the security management node, and whether the operation code is the broadcast notification operation code; if so, the successfully authenticated source identifier is extracted from the request packet and recorded in the identifier threshold record table, and the confirmation response is returned through the response channel of the coherent hub interface protocol.

[0012] The present invention also provides a node access trusted authentication device for a coherent hub interface protocol, comprising the following modules: The authentication control module is used by the security management node to receive authentication request messages sent by the requesting node of the newly established chain. The authentication request message reuses the reserved fields in the request channel of the coherent hub interface protocol to carry the authentication information. The security identification module is used by the security control node to parse the authentication request message, perform trusted identity authentication on the requesting node based on the authentication information, and generate an authentication result. The broadcast notification module is used to notify the source identifier of the requesting node to each master node in the system when the authentication result is successful, and to receive the confirmation response returned by each master node. An authentication response module is used by the security control node to return an authentication response message to the requesting node based on the authentication result; wherein, if the authentication result is successful, the requesting node obtains the permission to communicate with the master node.

[0013] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a node access trusted authentication method for any of the coherent hub interface protocols described above.

[0014] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a node access trusted authentication method for a coherent hub interface protocol as described above.

[0015] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements a node access trusted authentication method for any of the aforementioned coherent hub interface protocols.

[0016] This invention provides a trusted authentication method for node access based on a coherent hub interface protocol, which has the following advantages: By adding an independent security management node as a unified authentication receiver, the problem of chaotic addressing of authentication requests from new nodes is solved, and standardized identity access control is achieved; at the same time, the authentication request message reuses reserved fields in the request channel of the coherent hub interface protocol to carry the authentication information, without modifying the original protocol field definitions, and smoothly integrates the trusted authentication function for node access without destroying the compatibility of existing protocols and system architecture; in addition, after successful authentication, the security management node notifies each master node of the source identifier of the requesting node and receives the confirmation response, ensuring that the master nodes can identify legitimate nodes, thereby effectively preventing illegal or malicious nodes from accessing the system and ensuring the data security and business integrity of multi-core on-chip systems. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 This is a flowchart illustrating the node access trusted authentication method for coherent hub interface protocols provided by the present invention.

[0019] Figure 2 This is a system interconnection structure block diagram of the access security management node provided by the present invention.

[0020] Figure 3 This is a flowchart of the chain-building module provided by the present invention.

[0021] Figure 4 This is a flowchart of the security control node function provided by the present invention.

[0022] Figure 5 This is a schematic diagram of the node access trusted authentication device for coherent hub interface protocols provided by the present invention.

[0023] Figure 6 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0025] The following is combined with Figures 1-6 The embodiments of the present invention are described in detail.

[0026] The node access trusted authentication method for coherent hub interface protocol provided in this embodiment of the invention is executed by a node access trusted authentication device for coherent hub interface protocol. This device can be configured in a computer, which can be a local computer or a cloud computer. The local computer can be a computer, tablet, etc., and no specific limitation is made here.

[0027] Figure 1 This is a flowchart illustrating the node access trusted authentication method for coherent hub interface protocols provided by the present invention, as shown below. Figure 1 As shown, the method includes the following steps: S110, the security control node receives the authentication request message sent by the requesting node of the newly established chain. The authentication request message reuses the reserved fields in the request channel of the coherent hub interface protocol to carry the authentication information.

[0028] S120: The security control node parses the authentication request message, performs trusted identity authentication on the requesting node based on the information to be authenticated, and generates the authentication result.

[0029] S130. When the authentication result is successful, the security control node will notify each master node in the system of the source identifier of the requesting node and receive the confirmation response returned by each master node.

[0030] S140. Based on the authentication result, the security control node returns an authentication response message to the requesting node. The requesting node that successfully authenticates gains permission to communicate with the master node.

[0031] Specifically, the security control node first receives the authentication request message sent by the requesting node of the newly established chain. The authentication request message is transmitted using the request channel (REQ Channel) of the Coherent Hub Interface Protocol (CHI protocol). Its opcode field is set to a preset authentication request opcode value (e.g., 0x3F), the source identifier (SrcID) field is a globally unique hardware identifier for the requesting node, the target identifier (TgtID) field is set to the source identifier value of the security control node after compliance processing by the chain establishment module, and the request transaction identifier (TxnID) field is set to a preset value (e.g., 0). The authentication request message carries the information to be authenticated through a reserved field (RSVDC field) in the CHI protocol request channel. This RSVDC field is 32 bits wide, with the high 8 bits reserved, the middle 8 bits indicating the sequence number of the currently transmitted authentication information fragment, and the low 16 bits carrying the authentication information data fragment. When the length of the information to be authenticated exceeds 16 bits, the requesting node transmits it in fragments using multiple authentication request messages, with the fragment sequence number in each message increasing sequentially.

[0032] Upon receiving an authentication request message, the security management node first determines whether it is an authentication request based on whether its opcode matches the preset authentication request opcode. If not, the message is discarded. If it is, the security management node caches the authentication information carried by each fragment into a buffer data structure corresponding to that source identifier, based on the source identifier in the authentication request message. Specifically, the security management node internally maintains a buffer data structure with a depth equal to the total number of requesting nodes in the system. Each entry includes the authentication algorithm mode (Auth_mode), the received fragment count (Flit_cnt), the source identifier (SrcID), and the set of data to be authenticated (Auth_data). When the first authentication request message for a certain source identifier is received, the security management node starts the corresponding timeout counter (time_out_reg) and determines the maximum number of fragment transmissions (Max_Flit_cnt_reg) based on the preset authentication algorithm corresponding to that source identifier. For each received fragment, the authentication information data of the lower 16 bits of the RSVDC field is stored in the corresponding position of Auth_data, and the received fragment count is incremented by 1. When the received segment count reaches the maximum number of segment transmissions, the information to be authenticated is considered to have been received completely, and an authentication packet is generated; or when the timeout counter reaches the preset maximum value and has not been received completely, a reception timeout is triggered, and the currently received information is also generated into an authentication packet.

[0033] The security control node performs trusted identity authentication on the packet to be authenticated. This embodiment supports multiple authentication algorithms, and calls the corresponding algorithm based on the authentication algorithm mode field in the packet to be authenticated. After authentication is completed, an authentication result is generated, including success or failure.

[0034] When authentication is successful, the security control node notifies all master nodes in the system of the source identifier of the successfully authenticated requesting node. Specifically, the security control node internally stores a list of identifiers for all master nodes (e.g., the identifiers for the four master nodes are 0x10, 0x20, 0x30, and 0x40). The security control node generates a broadcast notification message, which reuses the CHI protocol request channel. Its opcode is set to a preset broadcast notification opcode (e.g., 0x3E), the reserved field (RSVDC) carries the source identifier of the successfully authenticated requesting node, and the target identifier field is set to the identifier of each master node. The security control node sends the broadcast notification message to each master node sequentially and then waits for each master node to return an acknowledgment response. Upon receiving the broadcast notification message, the master node extracts the successfully authenticated source identifier from its reserved field, adds the source identifier to its local identifier threshold record table, and then returns a broadcast response message through the CHI protocol response channel (CRSP Channel), with the opcode set to a preset broadcast response opcode (e.g., 0x15). A response counter (rsp_cnt) is set within the security management node, with an initial value of 0. The response counter is incremented by 1 for each broadcast response message received. When the value of the response counter equals the total number of master nodes, it means that acknowledgment responses from all master nodes have been received.

[0035] Based on the authentication result, the security control node returns an authentication response message to the requesting node. The authentication response message is transmitted using the CHI protocol's Data Access Channel (DAT Channel), with its opcode set to a preset authentication response opcode (e.g., 0xF). The data field carries authentication result information: for example, 0x0 represents authentication failure, 0x1 represents authentication success, and 0x2 represents authentication timeout. The destination identifier field of the authentication response message is set to the requesting node's source identifier, and the source identifier field is set to the security control node's identifier. After receiving the authentication response message, if the authentication result is successful, the requesting node gains permission to communicate with the master node; if the authentication result is unsuccessful, it cannot communicate with the master node.

[0036] This embodiment solves the problem of chaotic authentication request addressing when new nodes connect by adding a security management node as a unified authentication receiver, and realizes standardized identity access control. By reusing reserved fields in the CHI protocol request channel to carry the authentication information, the native protocol field definitions are not modified, and node access trusted authentication function is smoothly integrated without compromising the compatibility of existing protocols and system architecture. After successful authentication, the security management node notifies each master node of the source identifier of the requesting node and receives the confirmation response, ensuring that the master nodes can identify legitimate nodes, effectively preventing illegal or malicious nodes from accessing the system, and ensuring the data security and business integrity of the multi-core on-chip system. At the same time, by setting a timeout counter and a buffered data structure, the resources of the security management node are not occupied by a single node for a long time, improving the robustness of the authentication process.

[0037] According to the present invention, a node access trusted authentication method for a coherent hub interface protocol is provided. Before the security management node receives the authentication request message sent by the requesting node of the newly established chain, the method further includes: the requesting node of the newly established chain completing link initialization with the security management node; obtaining the request packet sent by the requesting node of the newly established chain; determining whether the opcode of the request packet is a preset authentication request opcode; if not, discarding the request packet; if so, performing compliance processing on the request packet, and sending the processed request packet as an authentication request message to the security management node.

[0038] Specifically, the link establishment module first completes link initialization with the requesting node of the newly established link. The link establishment module includes a link establishment function block and an authentication control function block. The link establishment function block is responsible for converting CHI protocol layer data packets into link layer transport packets and managing the physical link initialization process. When a new requesting node connects to the system and successfully establishes a link with the link establishment module, the link establishment module obtains the request packet sent by the requesting node of the newly established link. The link establishment module has an authentication flag register (auth_flag), which is initially set to 0, indicating that the current node has not been authenticated. It also has an authentication count register (auth_cnt), initially set to a preset threshold (e.g., 5), used to record the number of times authentication is allowed.

[0039] The chain-building module determines whether the opcode of the obtained request packet is a preset authentication request opcode (e.g., 0x3F). Specifically, when the authentication identifier register is 0, it indicates that the current node is not authenticated, and the chain-building module compares the opcode of the request packet. If the opcode is not equal to the preset authentication request opcode, the chain-building module directly discards the request packet, and the request packet will not enter the subsequent routing module for transmission. If the opcode is equal to the preset authentication request opcode, the chain-building module performs compliance processing on the request packet. Compliance processing includes: modifying the Quality of Service (QoS) field of the request packet to the lowest priority (e.g., 0); modifying the target identifier field (TgtID) of the request packet to the source identifier value of the security management node; and modifying the request transaction identifier field (TxnID) of the request packet to a preset value (e.g., 0). Through the above compliance processing, unauthenticated nodes can be prevented from arbitrarily sending non-compliant authentication request packets, ensuring that the target of authentication request messages is uniformly directed to the security management node. After completing the compliance processing, the chain-building module sends the processed request packet as an authentication request message to the security management node. If an authenticated node loses its connection and re-establishes it during system operation, the authentication identifier register will be reset to 0. Once the connection is successfully re-established, the authentication request process described above needs to be executed again.

[0040] This embodiment achieves pre-filtering and standardization of requests from unauthenticated nodes by performing opcode judgment and compliance processing on the request packets sent by the new chain requesting nodes in the chain establishment module before sending authentication request packets to the security management node. This prevents unauthenticated nodes from sending unauthenticated requests that interfere with the normal operation of the system. By directly discarding non-compliant request packets, illegal requests are avoided from consuming interconnection network bandwidth. Through unified compliance processing of legitimate authentication request packets (modifying service quality priority, target identifier, and transaction identifier), it is ensured that authentication request packets can be accurately and with low priority sent to the security management node. This establishes a standardized pre-channel for subsequent unified trusted identity authentication, improving the reliability of the authentication process and the stability of the system.

[0041] According to the present invention, a node access trusted authentication method for a coherent hub interface protocol is provided, which performs compliance processing on request packets, including the following steps: modifying the service quality priority field of the request packet to the lowest priority; modifying the target identifier field of the request packet to the source identifier value of the security control node; and modifying the request transaction identifier field of the request packet to a preset value.

[0042] Specifically, the chain-building module modifies the Quality of Service (QoS) priority field of the request packet to the lowest priority. In the CHI protocol, the QoS priority field is used to identify the transmission priority of a message, with a value of 0 representing the lowest priority. To prevent unauthenticated nodes from occupying high-priority transmission resources during the authentication process and crowding out normal business messages, the chain-building module fixes the value of this field to 0. Secondly, the chain-building module modifies the target identifier field of the request packet to the source identifier value of the security management node. Unauthenticated nodes cannot know the source identifier of the security management node; allowing them to set their own target identifier field could lead to authentication request packets being incorrectly routed or dropped. Therefore, the chain-building module forcibly modifies the target identifier field to a globally unique source identifier value pre-configured in the system by the security management node, ensuring that authentication request packets can be accurately routed to the security management node.

[0043] The chain-building module modifies the request transaction identifier field of the request packet to a preset value. The request transaction identifier field is used to uniquely identify a transaction. Unauthenticated nodes may set this field uncontrollably. To avoid transaction identifier conflicts or management chaos, the chain-building module forcibly modifies this field to a preset value (e.g., 0). This compliance processing is executed in the authentication control function block of the chain-building module, and is only triggered when the authentication identifier register indicates that the current node is unauthenticated and the request packet opcode is determined to be the preset authentication request opcode. After completing the above modification, the chain-building module sends the processed request packet as an authentication request message to the security management node.

[0044] This embodiment achieves standardized preprocessing of authentication requests from unauthenticated nodes by uniformly modifying the service quality priority field, target identifier field, and request transaction identifier field of the request packet for compliance. By forcibly setting the service quality priority field to the lowest priority, it effectively prevents authentication requests from unauthenticated nodes from occupying high-priority transmission resources, ensuring the transmission bandwidth of normal business packets in the system. By forcibly modifying the target identifier field to the source identifier value of the security control node, it ensures that authentication request packets can be accurately routed to a unified authentication receiver, solving the problem of chaotic addressing of authentication requests. By forcibly modifying the request transaction identifier field to a preset value, it avoids transaction management conflicts caused by unauthenticated nodes due to improper transaction identifier settings, improving the standardization and reliability of the authentication process.

[0045] According to the present invention, a node access trusted authentication method for a coherent hub interface protocol is provided. The security control node parses the authentication request message, performs trusted identity authentication on the requesting node based on the information to be authenticated, and generates an authentication result. Specifically, the method includes: determining whether it is an authentication request based on the opcode of the authentication request message; if not, discarding it; caching the information to be authenticated in the authentication request message into a buffer data structure corresponding to the source identifier; generating an authentication packet when the authentication information segment corresponding to the source identifier is fully received or the reception times out; and performing trusted identity authentication on the authentication packet to generate an authentication result.

[0046] In one embodiment of the present invention, the information to be authenticated reuses a reserved field in the request channel of the CHI protocol. The reserved field includes an authentication information fragment sequence number subfield and an authentication information data subfield. According to the value of the authentication information fragment sequence number subfield, the data fragments carried by the authentication information data subfield are sequentially spliced ​​together to form a complete information to be authenticated.

[0047] Specifically, the process by which the security control node parses authentication request messages and performs trusted identity authentication is as follows. The security control node internally includes a request packet filtering function block, a request packet buffering function block, and a security authentication function block. First, upon receiving an authentication request message, the request packet filtering function block determines whether it is an authentication request based on the message's opcode field. Specifically, the request packet filtering function block checks whether the opcode is equal to a preset authentication request opcode (e.g., 0x3F). If the opcode is not equal to this preset value, the request packet is discarded; if it is equal, the request packet is sent to the request packet buffering function block.

[0048] The request packet buffering function block caches the authentication information carried in the authentication request message into a buffer data structure corresponding to the source identifier, based on the source identifier in the authentication request message. The authentication information reuses the reserved field (RSVDC field) in the CHI protocol request channel. This reserved field includes an authentication information fragment sequence number subfield and an authentication information data subfield. In this embodiment, the RSVDC field has a bit width of 32 bits, where RSVDC[23:16] is the authentication information fragment sequence number subfield and RSVDC[15:0] is the authentication information data subfield.

[0049] The request packet buffering function block concatenates the data fragments carried in the authentication information data subfield according to the value of the authentication information fragment sequence number subfield to form a complete authentication information. Specifically, when the first authentication request message of a certain source identifier is received, the request packet buffering function block reads the fragment sequence number indicated by RSVDC[23:16] (e.g., the first fragment) and stores the 16-bit data fragment of RSVDC[15:0] into the corresponding position of the authentication data set field (e.g., Auth_data[15:0]). When the second authentication request message of the same source identifier is received, the fragment sequence number (e.g., the second fragment) is read, and the data fragment of RSVDC[15:0] is stored into the position of Auth_data[31:16], and so on. Each time a fragment is stored, the received fragment count field is incremented by 1. When the received fragment count reaches the maximum fragment transmission count corresponding to the source identifier, it indicates that the complete authentication information has been concatenated and the authentication packet is generated. For example, when the authentication algorithm mode is Auth_mode0, the complete authentication information is 128 bits, and the maximum number of fragment transmissions is 8 (16 bits each); when it is Auth_mode1, the complete authentication information is 256 bits, and the maximum number of fragment transmissions is 16; when it is Auth_mode2, the complete authentication information is 512 bits, and the maximum number of fragment transmissions is 32. For different authentication request messages with the same source identifier, the data fragments are concatenated sequentially according to the value of the authentication information fragment sequence number subfield until a complete authentication information is formed.

[0050] The request packet buffering function block also has an authentication timeout counter (time_out_reg). When the first authentication request packet for a certain source identifier arrives, the corresponding timeout counter starts counting. If the timeout counter reaches the preset maximum value and the information to be authenticated has not been completely received, a reception timeout is triggered. At this time, the currently received information is used to generate an authentication packet and marked with a timeout flag.

[0051] The security authentication function block performs trusted identity authentication on the packet to be authenticated. Based on the determined authentication algorithm mode field in the packet, the security authentication function block calls the corresponding trusted identity authentication algorithm (e.g., digital signature verification, identity digest verification, or key verification). After authentication, it generates an authentication result, which includes whether the authentication was successful or failed, and records the source identifier corresponding to the authentication result.

[0052] This embodiment fragments the information to be authenticated by reusing reserved fields in the CHI protocol request channel. It utilizes the authentication information fragment sequence number subfield and the authentication information data subfield within the reserved fields to identify and carry fragmented information, achieving variable-length transmission of the information to be authenticated without modifying the original protocol fields. By sequentially concatenating the data fragments according to the value of the authentication information fragment sequence number subfield, it supports the assembly of complete information to be authenticated of different lengths (e.g., 128 bits, 256 bits, 512 bits), adapting to the input requirements of various trusted identity authentication algorithms. By setting a reception timeout mechanism, it proactively terminates and generates a packet to be authenticated if the complete message is not received within a specified time, preventing a single request node from occupying authentication resources for an extended period, thus improving the robustness of the authentication process and the utilization rate of system resources.

[0053] According to the present invention, a node access trusted authentication method for a coherent hub interface protocol is provided. When the authentication result is successful, the security management node notifies the source identifier of the requesting node to each master node in the system. Specifically, the method includes: the security management node generating a broadcast notification message, which reuses the request channel of the coherent hub interface protocol, its operation code is a preset broadcast notification operation code, and its reserved field carries the source identifier of the successfully authenticated requesting node; and sending the broadcast notification message to each master node respectively.

[0054] Specifically, when the security management node successfully authenticates the trusted identity of the requesting node, it executes the source identifier notification process through the broadcast notification function block. The broadcast notification function block stores a list of master node identifiers that need to be notified. For example, in the system of this embodiment, it stores four master node identifiers: 0x10, 0x20, 0x30, and 0x40. The broadcast notification function block first temporarily stores the successful authentication result and the corresponding requesting node source identifier in a first-in-first-out queue. The capacity of this queue is the same as the number of authentication results that the system can support for simultaneous notification (e.g., a capacity of 4). The broadcast notification function block reads an authentication result from the first-in-first-out queue and then generates a broadcast notification message. The broadcast notification message is transmitted using the request channel in the CHI protocol, and its opcode field is set to a preset broadcast notification opcode, for example, in this embodiment, the opcode is equal to 0x3E. The reserved field (RSVDC field) of this message is used to carry the source identifier of the successfully authenticated requesting node, and the bit width of this field is the same as the node identifier bit width in the system. The target identifier field (TgtID) of the broadcast notification message is set to the identifier value of each master node in sequence.

[0055] The broadcast notification function block sends broadcast notification messages sequentially to each master node through the request channel. For example, it sends one broadcast notification message to one master node every clock cycle until all four master nodes have received the notification. Within the broadcast notification function block, a response counter (rsp_cnt) is set, initially set to 0. This counter records the number of broadcast response messages received through the CHI protocol response channel (CRSP Channel). When the opcode in a received broadcast response message equals the preset broadcast response opcode (e.g., 0x15), the response counter is incremented by 1. When the response counter reaches the total number of master nodes, it indicates that all master nodes have successfully received the broadcast notification message and returned an acknowledgment response; at this point, the response counter is reset to 0. During the process of sending broadcast notification messages and waiting for acknowledgment responses, newly entered authentication result information is cached in a first-in-first-out queue. It will only enter the next broadcast notification process after the current broadcast notification process has ended.

[0056] This embodiment generates broadcast notification messages through the security control node and sends them to each master node. By utilizing the CHI protocol request channel and reserved fields to carry the source identifier of the successfully authenticated node, the authentication results are synchronized and uniformly updated on the master node side, ensuring the consistency and reliability of access control. By setting a response counter to count the confirmation responses returned by the master nodes, it is ensured that all master nodes receive the authentication success notification before continuing the subsequent process, avoiding access inconsistencies caused by some master nodes not being synchronized. By using a first-in-first-out queue to cache multiple authentication result information, batch notifications are supported in scenarios with consecutive successful authentication, improving the system's processing efficiency in multi-node access scenarios.

[0057] According to the present invention, a node access trusted authentication method for a coherent hub interface protocol is provided. A threshold module is set at the entry point of the master node, and the threshold module maintains an identifier threshold record table. The method further includes: the threshold module receiving a request packet from a requesting node creating a new chain; determining whether the source identifier in the request packet exists in the identifier threshold record table; if it exists, allowing the request packet to access the master node; if it does not exist, further determining whether the source identifier of the request packet is the source identifier of a security control node, and whether the opcode is a broadcast notification opcode; if so, extracting the successfully authenticated source identifier from the request packet and recording it in the identifier threshold record table, and returning a confirmation response through the response channel of the coherent hub interface protocol.

[0058] Specifically, each master node in the system has a threshold module at its entry point. This threshold module maintains an identification threshold record table. The capacity of the identification threshold record table is the same as the total number of request nodes that can be supported for access in the current system. For example, in this embodiment, the total number of request nodes is 4, so the capacity of the identification threshold record table is 4. This identification threshold record table can only be updated by the security control node, and the record table stores the source identifiers of request nodes that have been successfully authenticated and have the authority to access the master node.

[0059] The access control process of the threshold module is as follows: The threshold module first receives a request packet from the request channel. Then, the threshold module performs a first-level judgment on the request packet, checking whether the source identifier field in the request packet exists in the identifier threshold record table. If the source identifier can be found in the identifier threshold record table, it indicates that the request node has passed trusted identity authentication, and the threshold module allows the request packet to enter the master node and execute the subsequent read and write access process. If the corresponding source identifier is not found in the identifier threshold record table, the second-level judgment is then performed.

[0060] In the second-level judgment, the threshold module further determines whether the source identifier of the request packet is equal to the source identifier of the security management node, and whether the opcode of the request packet is a preset broadcast notification opcode (e.g., 0x3E). If both conditions are met, it indicates that the request packet is a broadcast notification message sent by the security management node, the purpose of which is to update the identifier threshold record table. At this time, the threshold module reads the reserved fields in the request packet, extracts the source identifier (auth_srcid) of the successfully authenticated request node from the reserved fields, and records the source identifier in the identifier threshold record table. After recording, the threshold module generates a broadcast response message, which is returned through the response channel of the CHI protocol. In the broadcast response message, the opcode is set to the preset broadcast response opcode (e.g., 0x15), the source identifier field is set to the identifier of the current master node, and the target identifier field is set to the source identifier of the security management node. If the source identifier of the request packet is not equal to the source identifier of the security management node, or the opcode is not a broadcast notification opcode, the threshold module directly discards the request packet and does not allow the request packet to access the master node.

[0061] This embodiment achieves precise access control for legitimate request nodes by setting a threshold module at the entry point of each master node and maintaining an identifier threshold record table, ensuring that only successfully authenticated request nodes can access the master node. Through a two-level judgment mechanism, it first verifies whether the source identifier of ordinary request nodes is in the record table, and then verifies the broadcast notification message from the security management node. This ensures both efficient processing of regular access and timely synchronization of newly authenticated nodes. By allowing only the security management node to update the identifier threshold record table, it prevents unauthorized nodes from tampering with the access whitelist, enhancing system security. After completing the record table update, the threshold module returns a confirmation response through a response channel, achieving reliable handshake confirmation with the security management node and ensuring the integrity and reliability of the authentication notification process.

[0062] In one embodiment of the present invention, an authentication identifier register and an authentication count register are set in the chain establishment module; when the authentication identifier register indicates that authentication has not been performed and the value of the authentication count register reaches a preset authentication count threshold, or when the authentication identifier register indicates that authentication has been successful, the chain establishment module discards all subsequent request packets sent by the requesting end node to close the authentication channel.

[0063] Specifically, the chain establishment module includes an authentication flag register and an authentication count register. The authentication flag register (auth_flag) indicates the authentication status of the current requesting node. Its initial reset value is 0, indicating that the current node has not been authenticated. When the requesting node successfully passes trusted identity authentication, this register is set to 1, indicating that the current node has been successfully authenticated. The authentication count register (auth_cnt) records the number of times the current requesting node is allowed to authenticate. Its initial reset value is a preset authentication count threshold (e.g., 5), used to limit the maximum number of authentication attempts a node can make.

[0064] The chain establishment module controls the closure of the authentication channel based on the values ​​of the two registers mentioned above. Specifically, when the authentication flag register indicates no authentication (auth_flag equals 0) and the authentication count register reaches the preset authentication count threshold (auth_cnt equals 0), it indicates that the requesting node has attempted authentication a preset number of times without success. The chain establishment module closes the node's authentication channel, discards all subsequent request packets sent by the requesting node, and no longer allows it to initiate authentication requests. Alternatively, when the authentication flag register indicates successful authentication (auth_flag equals 1), it indicates that the requesting node has passed trusted identity authentication. The chain establishment module also closes the node's authentication channel and discards all subsequent request packets sent by the requesting node to prevent the node from performing duplicate authentication and consuming channel resources.

[0065] After the authentication channel is closed, the chain-building module discards request packets as follows: when both the authentication identifier register and the authentication count register are 0, the chain-building module discards all received request packets without any routing or transmission processing. For cases where the authentication channel is closed after successful authentication, the chain-building module also determines the closure by checking the target identifier field in the request packet: if the target identifier field of the request packet equals the source identifier value of the security control node, then the request packet is considered a duplicate authentication request, and the chain-building module discards the request packet.

[0066] The authentication count register (auth_cnt) is assigned a corresponding physical address, allowing successfully authenticated nodes to modify its value via this address. For example, the system management node or security control node can dynamically adjust the authentication count threshold. If an authenticated node experiences a connection loss and re-establishes the connection during system operation, the authentication identifier register is reset to 0. The complete authentication process must be re-executed after the connection is successfully re-established.

[0067] This embodiment constructs a closed-loop control mechanism for the authentication channel by setting an authentication identifier register and an authentication count register in the chain establishment module, realizing automatic opening and closing management of the authentication channel. When a node successfully authenticates, the authentication channel is immediately closed, effectively preventing legitimate nodes from continuously sending authentication request packets due to hardware abnormalities or malicious behavior, thus occupying the request channel bandwidth and ensuring the transmission resources of normal business messages. When the number of authentication attempts of an unauthenticated node reaches a preset threshold, its authentication channel is proactively closed, avoiding continuous malicious authentication attacks by illegal nodes on security management nodes, and improving the system's security protection capabilities and resource utilization efficiency.

[0068] The present invention will be further illustrated below through complete embodiments.

[0069] This invention is designed based on the native architecture of the CHI protocol. Without modifying the bit width and meaning of the natively defined fields, it adds an independent security management node module and reasonably reuses the reserved fields of the protocol to realize the carrying of authentication-related information and response interaction. This not only does not damage the native system, but also is compatible with multiple versions of the CHI protocol and smoothly realizes the trusted authentication function for node access.

[0070] Figure 2 The diagram shows the interconnection structure of the system access security management node. All modules in the diagram are connected to the CHI interface bus.

[0071] In a system without access to a security management node, the system execution flow is as follows: After the system reset is successful, the request node (0, 1, 2) successfully connects to the link building module, the master node (0, 1, 2, 3) successfully connects to the link building module, and the link building module fails to connect to the empty request node.

[0072] The requesting node (0, 1, 2) can communicate normally with the master node (0, 1, 2, 3).

[0073] Insert request node 3 at the "empty request node" position. Request node 3 is successfully linked to the link building module.

[0074] Request node 3 can communicate normally with the master node (0, 1, 2, 3).

[0075] In a system connected to a security management node, the system execution flow is as follows: After the system reset is successful, the request node (0, 1, 2) successfully connects to the chain building module, the master node (0, 1, 2, 3) successfully connects to the chain building module, the empty request node fails to connect to the chain building module, and the security control node successfully connects to the chain building module.

[0076] The requesting node (0, 1, 2) sends an authentication request packet to the security management node and waits for the security management node to return the authentication result information.

[0077] If authentication is successful at the security control node, the security control node sends the source ID of the requesting node (0,1,2) to the master node (0,1,2,3), and then sends an authentication response packet indicating successful authentication to the requesting node (0,1,2). If authentication fails, it only sends an authentication response packet indicating failure to the requesting node (0,1,2).

[0078] Only after the requesting node (0, 1, 2) receives the successful authentication response packet can it send a request packet to communicate with the master node (0, 1, 2, 3); the master node (0, 1, 2, 3) can process the request normally only after recognizing the authenticated source ID.

[0079] Insert request node 3 at the "empty request node" position. Request node 3 is successfully linked to the link building module.

[0080] Request node 3 sends an authentication request packet to the security management node and waits for the security management node to return the authentication result information.

[0081] If authentication is successful at the security control node, the security control node packages the source ID of the successfully authenticated requesting node 3 into a request notification packet and sends it to the master node (0, 1, 2, 3), waiting for a response indicating completion of receiving the request notification packet. Then, the security control node sends a successful authentication response packet to the requesting node 3. If authentication fails at the security control node, it only sends a failed authentication response packet to the requesting node 3.

[0082] Only after request node 3 receives the authentication success response packet can it send a request packet to communicate with the master node (0, 1, 2, 3) to complete the node access trusted authentication process.

[0083] The specific implementation process is as follows: Step 1: Define the authentication request message format and authentication response message format respectively, formulate the corresponding encoding, and define the specific meaning of each bit in the reserved field.

[0084] The authentication request message is transmitted using the Request Channel (REQ Channel) in the CHI protocol. The key fields of the original protocol and their meanings include: Quality of Service Priority (QoS); Command field (Opcode), where 0x3B-0x3F are reserved values; Source ID field (SrcID), a globally unique ID identifier; Target ID field (TgtID), the ID identifier sent by the target of the request; Request Transaction ID field (TxnID); and Request Channel Reserved Field (RSVDC). For more detailed explanations, please refer to the protocol.

[0085] After extending the original CHI protocol field definitions, the authentication request message uses key fields as follows: The QoS field is used when sending authentication request messages. Nodes that fail to authenticate cannot use the QoS field. In this embodiment, a QoS value of 0 indicates the lowest priority of the request message's service quality.

[0086] The Opcode field is the instruction encoding of the authentication request message. In this embodiment, Opcode is equal to 0x3F.

[0087] The SrcID field conforms to the uniqueness of node hardware identifiers in the current NoC architecture.

[0088] The TgtID field identifies the target node ID of the authentication request message. Nodes that fail authentication cannot control the TgtID value. The value of this field in the authentication request message is equal to the source ID value of the security management node.

[0089] The TxnID field is the ID identifier for the authentication request message. Nodes that fail to authenticate cannot control the TxnID value.

[0090] The RSVDC field is the field for authentication information carried in the authentication request message. The RSVDC field has a width of 32 bits, with the following bit allocation: RSVDC[31:24] are reserved bits for future expansion; RSVDC[23:16] is the authentication information segment number, identifying which authentication information segment is being transmitted; and RSVDC[15:0] is the authentication information data segment. This bit width allocation is for illustrative purposes only; the number of bits can be increased or decreased according to system requirements, and this is not limited here.

[0091] The authentication response message is transmitted using the Data Channel (DAT Channel) in the CHI protocol. The key fields of the original protocol used include: QoS field, Opcode field, SrcID field, TgtID field, TxnID field, and Data field. The Data field is responsible for carrying the data to be transmitted, while values ​​0x8-0xA and 0xE-0xF in the Opcode field are reserved. For more detailed explanations, please refer to the protocol.

[0092] After extending the original CHI protocol field definitions, the authentication response message uses key fields as follows: The QoS field is fixed at 0 when sending an authentication response message.

[0093] The Opcode field is the instruction encoding of the authentication response message. In this embodiment, Opcode is equal to 0xF.

[0094] The SrcID field is the ID identifier of the node that initiated the authentication response message.

[0095] The TgtID field identifies the target node ID to which the authentication response message is sent.

[0096] The TxnID field is the transaction ID of the authentication response message, and its value is fixed at 0.

[0097] The Data field contains the authentication response result information. 0x0 indicates authentication failure, 0x1 indicates authentication success, and 0x2 indicates authentication timeout.

[0098] Broadcast notification messages are transmitted using the Request Channel (REQ Channel) in the CHI protocol. After extensions based on the original CHI protocol field definitions, the use of key fields in broadcast notification messages is as follows: The QoS field is fixed at 0 when sending a broadcast notification message.

[0099] The Opcode field is the instruction code for the broadcast notification message. In this embodiment, Opcode is set to 0x3E.

[0100] The SrcID field is the ID identifier of the node that initiated the broadcast notification message.

[0101] The TgtID field identifies the target node ID to which the broadcast notification message is sent.

[0102] The TxnID field is the transaction ID of the broadcast notification message, and its value is fixed at 0.

[0103] The RSVDC field is the authentication source ID value carried in the broadcast notification message. The bit width used is the same as that of the node ID identifier in the system.

[0104] Broadcast response messages are transmitted using the Response Channel (CRSP Channel) in the CHI protocol, where the Opcode field (0x15-0x1B) is reserved. After extending the original CHI protocol field definitions, the use of key fields in broadcast response messages is as follows: The QoS field is fixed at 0 when sending a broadcast response message.

[0105] The Opcode field is the instruction encoding of the broadcast response message. In this embodiment, Opcode is set to 0x15.

[0106] The SrcID field is the ID identifier of the node that initiated the broadcast response message.

[0107] The TgtID field identifies the target node ID to which the broadcast response message is sent.

[0108] The TxnID field is the transaction ID of the broadcast response message, and its value is fixed at 0.

[0109] Step 2: Based on the original link initialization function of the link building module, add control functions for authentication requests.

[0110] The functional flowchart of the chain building module is as follows: Figure 3 As shown, the new node connects to the system, initializes the link with the link establishment module, and successfully establishes the link.

[0111] The new node begins sending authentication requests, which are then processed for compliance in the chain building module.

[0112] After compliance processing, the authentication request is sent out from the chain building module, and then the system waits for the authentication response to determine whether the authentication was successful.

[0113] If the authentication response indicates successful authentication, record the success result and close the authentication channel. If the authentication response indicates failed authentication, record the number of authentication attempts. When the number of authentication attempts reaches a preset threshold, close the authentication channel.

[0114] The specific implementation of the chain establishment module is as follows: The link establishment module includes a link establishment function block and an authentication control function block. The link establishment function block, implemented based on the CHI protocol, converts protocol layer data packets into link layer transport packets and manages physical link initialization. The authentication control function block is a functional unit extended based on the CHI protocol in this embodiment.

[0115] The following section focuses on the authentication control function block in the chain building module, which uses the REQ channel and the RDAT channel.

[0116] In the chain establishment module, the auth_flag (authentication flag) register is configured. This register prevents nodes to be authenticated from sending authentication request messages that violate the rules. The initial value of auth_flag is 0. Specific functional descriptions are as follows: When `auth_flag` is 0, it indicates that the current node is not authenticated. If a node to be authenticated sends a request packet, the system first checks if the `Opcode` field in the request packet is equal to the authentication request instruction code 0x3F. If the `Opcode` is not equal to 0x3F, the request packet will be discarded and will not enter the routing module for transmission. If the `Opcode` is equal to 0x3F, then some fields in the request packet are modified, including: the `QoS` field is modified to 0, the `TgtID` field is modified to the source ID value of the security management node, and the `TxnID` field is modified to 0. This prevents unauthenticated nodes from arbitrarily sending unauthorized authentication request packets.

[0117] When auth_flag is 1, it indicates that the current node has successfully authenticated. The node can then send request packets normally. The authentication channel is closed, disallowing duplicate authentication. The closure method is: check the TgtID field in the request packet; if the TgtID field equals the source ID value of the security management node, the request packet is discarded.

[0118] If an authenticated node loses its connection during system operation, auth_flag will be reset to 0, and the authentication process will need to be re-executed after the connection is successfully established.

[0119] In the chain establishment module, the `auth_cnt` (authentication count) register is configured. This register indicates the number of authentication attempts allowed for the node to be authenticated. The initial reset value of `auth_cnt` is 5. Each time an authentication response packet is received, `auth_cnt` is decremented by 1. When `auth_cnt` equals 0, the authentication channel is closed. The closure method is as follows: when both `auth_flag` and `auth_cnt` are 0, all subsequent request packets are discarded. When `auth_flag` equals 1, `auth_cnt` has no actual functional effect regardless of its value. A corresponding physical address is allocated to the `auth_cnt` register, allowing successfully authenticated nodes to modify the value of `auth_cnt`.

[0120] Step 3: Upon receiving the authentication request, the security control node performs authentication according to the preset security authentication algorithm. If authentication fails, it returns a failure response. If authentication succeeds, it first notifies the master node of the successfully authenticated node's ID, waits for the master node to return a completion response, and then returns an authentication success response to the requesting node.

[0121] The functional flowchart of the security control node is as follows: Figure 4As shown, when a security control node receives a request packet, it determines whether it is an authentication request packet. If it is, it proceeds to the next processing step; otherwise, it discards the request packet.

[0122] The request packet information is saved based on the source ID, a packet to be authenticated is generated, and request packets are continuously received until the packet to be authenticated for the current source ID meets the authentication requirements. A reception timeout mechanism is set; if the reception times out, authentication is considered to have failed. If the reception times out, the authentication response device is directly notified to issue an authentication failure response.

[0123] The packets to be authenticated are entered into the authentication module in sequence for authentication. If authentication fails, the authentication response device is directly notified to issue an authentication failure response. If authentication succeeds, the process proceeds to the next step.

[0124] The source ID identifier of successful authentication is notified to the master node. After the notification ends, wait for the notification completion response. After receiving the completion response of all notifications, notify the authentication response device.

[0125] If the authentication response device receives an authentication success message, it returns an authentication success response packet to the node that requested authentication; if it receives an authentication failure message, it returns an authentication failure response packet to the node that requested authentication.

[0126] The specific implementation of security control nodes is as follows: The security control node includes the following functional blocks: request packet filtering, request packet buffering, security authentication, broadcast notification, and response.

[0127] When the request packet filtering function block receives a request packet, it first checks whether the Opcode field of the request packet is equal to 0x3F. If it is not equal to 0x3F, the request packet is discarded; if it is equal to 0x3F, the request packet is sent to the request packet buffer function block.

[0128] The request packet buffering function block is responsible for collecting and buffering the content of request packets, generating a packet to be authenticated that meets the authentication requirements. Within the request packet buffering function block, a buffer data structure based on the number of nodes in the system is set up to store the packet to be authenticated. For example, in the system of the current embodiment, the total number of request nodes is 4, so a buffer data structure with a depth of 4 is defined, which can support authentication by 4 nodes simultaneously. The format of the packet to be authenticated is shown in Table 1. Table 1

[0129] `Auth_mode` identifies the trusted authentication algorithm used by the corresponding node; `Flit_cnt` records how many times the authentication information has been transmitted from the current source ID; `SrcID` identifies which requesting node the authentication information originated from; `Auth_data` is a collection of authentication information fragments, and the data width of `Auth_data` is determined by the maximum complete authentication information width supported by the trusted authentication algorithm. Specifically: The `Auth_mode` parameter determines the trusted authentication algorithms allowed for the current source ID, as well as the maximum number of times the authentication fragment to be transmitted under the current authentication algorithm. Specifically: The security management node supports three authentication algorithms. The source ID information and the maximum number of transmissions for each authentication algorithm are shown below: When Auth_mode0 is used, it is used when the source ID is 0. The complete information to be authenticated is 128 bits, so the maximum number of transmissions for the information to be authenticated fragment is 8.

[0130] When Auth_mode1 is used, it is used when the source ID is 1 or 2. The complete authentication information is 256 bits, and the maximum number of times the authentication information fragment can be transmitted is 16.

[0131] When using Auth_mode2, the source ID is 3 or other values. The complete authentication information is 512 bits, so the maximum number of times the authentication information fragment can be transmitted is 32.

[0132] The maximum number of transmissions of the aforementioned segment of information to be authenticated is calculated based on the 16-bit segment of information to be authenticated transmitted per transmission as defined by RSVDC in the REQ channel. Different nodes use different authentication methods.

[0133] The authentication timeout counter (time_out_reg) and timeout flag (time_out_flag) are set, both initially set to 0. The number of timeout counters depends on the number of authentication requests that can be received simultaneously, and counting begins when the first request packet from the current source ID enters the request packet buffer function block. When the authentication timeout counter reaches its preset maximum value, regardless of whether the authentication request is complete, time_out_flag is set to 1, and then the corresponding source ID value and time_out_flag are transmitted to the response function block. In this embodiment, there are four authentication timeout counters, namely time_out_reg (0, 1, 2, 3). The bit width of the timeout counter can be set according to the main frequency; in this embodiment, it is set to 32 bits.

[0134] For example, a requesting node with source ID 3 sends an authentication request packet. The authentication request packet enters the request packet buffering function block through the request packet filtering function block. First, it checks whether there is an authentication information packet with the same source ID in the buffer data structure. For example, if there is no authentication information packet with the same source ID in the current buffer data structure, the authentication information fragment count (Flit_cnt_reg) starts counting from 0. Judging from the source ID of 3, it can be known that the authentication algorithm to be used is Auth_mode2, so the maximum number of authentication information fragment transmissions (Max_Flit_cnt_reg) is 32. At the same time, by judging the value of RSVDC[23:16] in the authentication request packet, RSVDC[15:0] is saved to the corresponding Auth_data. For example, if the authentication request packet RSVDC[23:16] indicates the second authentication information fragment, then RSVDC[15:0] is saved to Auth_data[31:16], and so on. Simultaneously, the authentication timeout counter `time_out_reg3` for the current source ID begins counting, occurring on the rising edge of each clock cycle, regardless of whether an authentication request packet arrives. `Flit_cnt_reg` is also incremented by 1. After calculation, the corresponding information is saved to the corresponding data location, such as storing `Auth_mode2` in `Auth_mode`, `Flit_cnt_reg` in `Flit_cnt`, the source ID value in `SrcID`, and `RSVDC[15:0]` in the bits corresponding to the `Auth_data` segment.

[0135] When the next authentication request packet arrives, the system first checks if a packet with the same source ID exists in the buffer data structure. If no packet with the same source ID exists, the same operation described above is performed. If a packet with the same source ID exists, taking an authentication request source ID of 3 as an example, the `Flit_cnt` field is read and stored in `Flit_cnt_reg`, then incremented by 1 and stored back in the `Flit_cnt` field. The `Auth_mode` field indicates that the authentication algorithm is `Auth_mode2`, so the current `Max_Flit_cnt_reg` is 32. `Max_Flit_cnt_reg` is compared with `Flit_cnt_reg`. If they are equal, the authentication packet is considered successfully received; otherwise, the receiving state continues. Simultaneously, the location of the `Auth_data` field where the current authentication information needs to be stored is calculated and stored in the corresponding `Auth_data` field. Meanwhile, the timeout counter (`time_out_reg3`) continues to count.

[0136] Subsequent authentication request packets will be processed according to the above steps, and will not be repeated here.

[0137] When Max_Flit_cnt_reg equals Flit_cnt_reg, the reception is considered complete. Then, the contents of the buffer data structure corresponding to the current source ID are read out, a packet to be authenticated is generated, and it is transmitted to the security authentication module for authentication. Simultaneously, all buffer resources corresponding to the source ID are released, and the used registers are reset.

[0138] If Max_Flit_cnt_reg is not equal to Flit_cnt_reg, but the timeout counter corresponding to the source ID reaches its maximum value, the receive timeout mechanism is triggered, and time_out_flag is set to 1. Then, the contents of the buffer data structure corresponding to the current source ID are read out, and the source ID value SrcID and time_out_flag are transmitted to the response function block. The authentication timeout mechanism can prevent a node from consuming security management node resources due to timeout. When used in conjunction with auth_cnt in the chain establishment module, if the number of authentication attempts exceeds the threshold, the current node will no longer be allowed to authenticate, thereby better protecting the stability of the system.

[0139] The security authentication function block is responsible for performing trusted identity authentication on the packet to be authenticated. It invokes the corresponding trusted identity authentication algorithm based on the Auth_mode field in the packet. Trusted identity authentication employs authentication algorithms commonly used in this field, including but not limited to digital signature verification, identity digest verification, and key verification algorithms. This invention does not limit the specific trusted identity authentication algorithm.

[0140] In the security authentication function block, the authentication result (auth_result) and the authentication source ID (auth_srcid) are set. `auth_result` identifies the authentication result: 0 indicates authentication failure, and 1 indicates authentication success. `auth_srcid` identifies the authentication source ID, and its value is equal to the `SrcID` field in the packet to be authenticated. When `auth_result` equals 0, `auth_result` and `auth_srcid` are passed to the response function block for further processing. When `auth_result` equals 1, `auth_result` and `auth_srcid` are passed to the broadcast notification function block for further processing.

[0141] The broadcast notification function block is responsible for sending the successfully authenticated node ID information to the master node, waiting for the master node to return a completion response, and then notifying the response function block to process the response. Details are as follows: The broadcast notification function block uses the REQ and CRSP channels in the CHI protocol. Internally, the broadcast notification function block stores the master node IDs that need to be notified. In this embodiment, four master node IDs are stored: 0x10, 0x20, 0x30, and 0x40.

[0142] When the broadcast notification function block receives auth_result and auth_srcid, it first caches auth_result and auth_srcid using FIFO. The capacity of FIFO is 4, which can support caching 4 authentication result information.

[0143] In the current embodiment, the broadcast notification function block reads an authentication result from the FIFO and then generates four broadcast notification messages. The Opcode field is equal to 0x3E, the RSVDC field is equal to auth_srcid, and the TgtID field is the master node ID (0x10, 0x20, 0x30, and 0x40 respectively). One broadcast notification message is sent every clock cycle using the REQ channel. A response counter (rsp_cnt) is set in the broadcast notification function block, initially set to 0. rsp_cnt records the number of times the Opcode field on the CRSP channel equals 0x15. When rsp_cnt reaches 4 times, it indicates that all broadcast response messages have been received. Then, rsp_cnt is reset to 0. Finally, the current authentication result information auth_result and auth_srcid are transmitted to the response function block.

[0144] During the process of sending broadcast notification messages and waiting to receive broadcast response messages, newly entered authentication result information will be cached in a preset FIFO and will only be able to enter the next broadcast notification process after the previous broadcast notification process ends.

[0145] A threshold module is set at the entry point of the REQ request channel on each master node. This module maintains an ID threshold record table; only requests with the same SrcID as those recorded in the table can access the current master node. The specific implementation is as follows: The capacity of the ID threshold record table is the same as the total number of request nodes that can be supported for access in the current system. In this embodiment, the capacity of the ID threshold record table is 4. The ID threshold record table can only be updated by security control nodes.

[0146] When the threshold module receives a REQ request packet, it first performs a first-level judgment, checking whether the SrcID field in the request packet is the same as that in the ID threshold record table. If they are the same, the request packet proceeds to the master node for subsequent read / write access. If the corresponding SrcID for the request packet is not found in the ID threshold record table, it proceeds to the second-level judgment.

[0147] In the second-level judgment, it checks whether the SrcID of the request packet is equal to the security management node ID. If the SrcID is equal, it checks the Opcode field in the request packet. If Opcode equals 0x3E, it indicates a request to update the ID threshold record table. The threshold module then reads the RSVDC field from the REQ request and records the corresponding auth_srcid in the field into the ID threshold record table. After recording, a broadcast response message is generated: where Opcode equals 0x15, SrcID is the current master node ID, and TgtID is the security management node ID, and it is returned via the CRSP channel. If the SrcID of the request packet is not equal to the security management node ID, the request packet is discarded, and access to the current master node is not possible.

[0148] The response function block is responsible for responding to authentication requests, using the RDAT channel in the CHI protocol. Details are as follows: When the time_out_flag and the corresponding source ID value are received, the values ​​of each field in the RDAT channel are as follows: QoS field: fixed value 0; Opcode field: Opcode equals 0xF; SrcID field: ID value of the security management node; TgtID field: the received corresponding source ID value; TxnID field: fixed value 0; Data field: 0x2. Then, the values ​​of each field are packaged and returned through the RDAT channel.

[0149] Similarly, when auth_result and auth_srcid are received, the Data field is 0x0 when auth_result equals 0, and 0x1 when auth_result equals 1. When a response is issued from the security management node, the complete authentication process of a node ends, and the resources used by the current source ID during the authentication process are released.

[0150] The solution of this invention has strong protocol compatibility and does not disrupt the original protocol or system architecture. It achieves accurate and efficient identity authentication through a unified security management node. Once node authentication is successful or the maximum number of authentication attempts is reached, the authentication channel is closed, preventing hardware malfunctions or malicious authentication. This solution has strong adaptability and is very suitable for systems supporting hot-swappable technology.

[0151] The following describes the node access trusted authentication device for coherent hub interface protocols provided by the present invention. The node access trusted authentication device for coherent hub interface protocols described below and the node access trusted authentication method for coherent hub interface protocols described above can be referred to in correspondence with each other.

[0152] like Figure 5The image shows a node access trusted authentication device for a coherent hub interface protocol provided by the present invention, comprising: The authentication control module 510 is used for the security management node to receive authentication request messages sent by the requesting node of the newly established chain, wherein the authentication request message reuses the reserved field in the request channel of the coherent hub interface protocol to carry the authentication information. The security identification module 520 is used by the security control node to parse the authentication request message, perform trusted identity authentication on the requesting node based on the authentication information, and generate an authentication result; The broadcast notification module 530 is used to notify the source identifier of the requesting node to each master node in the system when the authentication result is successful, and to receive the confirmation response returned by each master node. The authentication response module 540 is used by the security control node to return an authentication response message to the requesting node based on the authentication result; wherein, the requesting node with a successful authentication result obtains the permission to communicate with the master node.

[0153] Specifically, the functions of each module in the node access trusted authentication device for the coherent hub interface protocol provided in this embodiment of the invention correspond one-to-one with the operation flow of each step in the above method-like embodiments, and the achieved effects are also the same. For details, please refer to the above embodiments, and this will not be repeated in this embodiment of the invention.

[0154] Figure 6 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 6 As shown, the electronic device may include a processor 610, a communications interface 620, a memory 630, and a communication bus 640, wherein the processor 610, communications interface 620, and memory 630 communicate with each other via the communication bus 640. The processor 610 can call logical instructions in the memory 630 to execute a node access trusted authentication method for a coherent hub interface protocol. This method includes: a security management node receiving an authentication request message sent by a requesting node establishing a new chain, wherein the authentication request message reuses a reserved field in the request channel of the coherent hub interface protocol to carry the information to be authenticated; the security management node parsing the authentication request message, performing trusted identity authentication on the requesting node based on the information to be authenticated, and generating an authentication result; when the authentication result is successful, the security management node notifies each master node in the system of the source identifier of the requesting node and receives confirmation responses returned by each master node; the security management node returning an authentication response message to the requesting node according to the authentication result; wherein the requesting node with a successful authentication result obtains the permission to communicate with the master node.

[0155] Furthermore, the logical instructions in the aforementioned memory 630 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0156] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the node access trusted authentication method for the coherent hub interface protocol provided by the above methods. The method includes: a security management node receiving an authentication request message sent by a requesting node of a newly established chain, wherein the authentication request message reuses a reserved field in the request channel of the coherent hub interface protocol to carry the information to be authenticated; the security management node parsing the authentication request message, performing trusted identity authentication on the requesting node based on the information to be authenticated, and generating an authentication result; when the authentication result is successful, the security management node notifies each master node in the system of the source identifier of the requesting node and receives the confirmation response returned by each master node; the security management node returns an authentication response message to the requesting node according to the authentication result; wherein the requesting node with a successful authentication result obtains the permission to communicate with the master node.

[0157] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements a node access trusted authentication method for a coherent hub interface protocol provided by the methods described above. This method includes: a security management node receiving an authentication request message sent by a requesting node establishing a new chain, wherein the authentication request message reuses a reserved field in the request channel of the coherent hub interface protocol to carry information to be authenticated; the security management node parsing the authentication request message, performing trusted identity authentication on the requesting node based on the information to be authenticated, and generating an authentication result; when the authentication result is successful, the security management node notifies each master node in the system of the source identifier of the requesting node and receives confirmation responses returned by each master node; the security management node returning an authentication response message to the requesting node according to the authentication result; wherein the requesting node with a successful authentication result obtains permission to communicate with the master node.

[0158] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0159] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0160] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A node access trusted authentication method for a coherent hub interface protocol, characterized in that, include: The security control node receives an authentication request message sent by the requesting node of the newly established chain. The authentication request message uses a reserved field in the request channel of the coherent hub interface protocol to carry the authentication information. The security control node parses the authentication request message, performs trusted identity authentication on the requesting node based on the authentication information, and generates an authentication result; When the authentication result is successful, the security control node notifies the source identifier of the requesting node to each master node in the system. Specifically, the security control node generates a broadcast notification message, which reuses the request channel of the coherent hub interface protocol. Its opcode is a preset broadcast notification opcode, and its reserved field carries the source identifier of the successfully authenticated requesting node. The broadcast notification message is then sent to each master node, and the node receives confirmation responses from each master node. The security control node returns an authentication response message to the requesting node based on the authentication result; Wherein, the authentication result indicates that the requesting node has successfully obtained the permission to communicate with the master node.

2. The node access trusted authentication method for coherent hub interface protocols according to claim 1, characterized in that, Before the security control node receives the authentication request message sent by the requesting node of the newly established chain, it also includes: The requesting node and the security control node of the newly established chain complete the link initialization; Obtain the request packet sent by the requesting node of the newly created chain; Determine whether the operation code of the request packet is a preset authentication request operation code; If not, then discard the request packet; If so, the request packet is processed for compliance, and the processed request packet is sent to the security control node as the authentication request message.

3. The node access trusted authentication method for coherent hub interface protocols according to claim 2, characterized in that, The compliance processing of the request packet includes the following steps: Modify the service quality priority field of the request packet to the lowest priority; Modify the target identifier field of the request packet to the source identifier value of the security control node; Modify the request transaction identifier field of the request packet to a preset value.

4. The node access trusted authentication method for coherent hub interface protocols according to claim 1, characterized in that, The security control node parses the authentication request message, performs trusted identity authentication on the requesting node based on the authentication information, and generates an authentication result, specifically including: Determine whether the authentication request is an authentication request based on the opcode of the authentication request message; if not, discard it. Based on the source identifier in the authentication request message, the authentication information is cached in a buffer data structure corresponding to the source identifier; When the information segment to be authenticated corresponding to the source identifier is received completely or the reception times out, an authentication packet is generated. Perform trusted identity authentication on the packet to be authenticated and generate an authentication result.

5. The node access trusted authentication method for coherent hub interface protocols according to claim 1, characterized in that, A threshold module is set at the entrance of the main node, and the threshold module maintains an identification threshold record table; The method further includes: The threshold module receives the request packet sent by the requesting node of the newly established chain; Determine whether the source identifier in the request packet exists in the identifier threshold record table; If it exists, then the request packet is allowed to access the master node; If it does not exist, then it is further determined whether the source identifier of the request packet is the source identifier of the security control node and whether the operation code is the broadcast notification operation code. If so, the source identifier of successful authentication is extracted from the request packet and recorded in the identifier threshold record table, and the confirmation response is returned through the response channel of the coherent hub interface protocol.

6. A node access trusted authentication device for a coherent hub interface protocol, characterized in that, include: The authentication control module is used by the security management node to receive authentication request messages sent by the requesting node of the newly established chain. The authentication request message reuses the reserved fields in the request channel of the coherent hub interface protocol to carry the authentication information. The security identification module is used by the security control node to parse the authentication request message, perform trusted identity authentication on the requesting node based on the authentication information, and generate an authentication result. The broadcast notification module is used to notify the source identifier of the requesting node to each master node in the system when the authentication result is successful, and to receive the confirmation response returned by each master node. An authentication response module is used by the security control node to return an authentication response message to the requesting node based on the authentication result; wherein, if the authentication result is successful, the requesting node obtains the permission to communicate with the master node.

7. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the node access trusted authentication method for coherent hub interface protocols as described in any one of claims 1 to 5.

8. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the node access trusted authentication method for coherent hub interface protocols as described in any one of claims 1 to 5.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the node access trusted authentication method for coherent hub interface protocols as described in any one of claims 1 to 5.

Images