A data processing method, device and storage medium

Abstract

The application is suitable for the field of data security protection of integrated circuits, and provides a data processing method, equipment and storage medium, wherein the method comprises: maintaining, at a sending end and a receiving end, a sequence number register corresponding to different types of transaction layer data packets (TLPs) for each integrity data encryption (IDE) stream; the sending end calculates a first message authentication code (MAC) based on a current sequence number of the sequence number register of the corresponding type maintained locally when sending a TLP to the receiving end, and appends the first MAC to the TLP for sending; and the receiving end calculates a second MAC based on an expected sequence number of the sequence number register of the corresponding type maintained locally when receiving the TLP, and compares the second MAC with the first MAC received to verify the TLP. The scheme can realize secure transmission protection of TLPs of the same type.

Description

Technical Field

[0001] This application belongs to the field of data security protection for integrated circuits, and particularly relates to a data processing method, device and storage medium. Background Technology

[0002] With the surge in bandwidth demands from data centers and high-performance computing, high-speed interconnect technologies such as high-speed peripheral component interconnects and compute fast interconnects are widely used. To ensure data transmission security, standards have introduced integrity and data encryption mechanisms. Existing integrity and data encryption technologies provide basic replay protection for different types of transaction-level data packets through counters.

[0003] However, this mechanism has a major flaw: it cannot effectively protect against security threats between data packets of the same type at the transaction layer. Attackers can exploit this vulnerability to insert, delete, replay, or reorder consecutive data packets of the same type at the transaction layer without the receiving end being aware of it, posing a serious data security risk. Summary of the Invention

[0004] This application provides a data processing method, device, and storage medium to achieve secure protection for the transmission of data packets of the same type at the transaction layer.

[0005] The first aspect of this application provides a data processing method, including:

[0006] At both the sending and receiving ends, a sequence number register corresponding to the Transaction Layer Packet (TLP) is maintained for each integrity data encryption IDE stream;

[0007] When the sending end sends a TLP to the receiving end, it calculates the first message authentication code (MAC) based on the current sequence number of the corresponding type of sequence number register maintained locally, and appends the first MAC to the TLP for transmission.

[0008] When receiving a TLP, the receiving end calculates a second MAC based on the expected sequence number of the corresponding type of sequence number register maintained locally, and compares the second MAC with the received first MAC to verify the TLP.

[0009] A second aspect of this application provides a transmitting device for implementing the method described in the first aspect, comprising:

[0010] At least three sequence number registers are used to maintain sequence numbers for TLPs of publish request, non-publish request, and completion message types, respectively.

[0011] A third aspect of this application provides a receiving device for implementing the method described in the first aspect, comprising:

[0012] At least three sequence number registers are used to maintain expected sequence numbers for TLPs of publish requests, non-publish requests, and completion message types, respectively. The sequence number registers include an out-of-order compensation value field, an out-of-order flag field, and an overflow flag field.

[0013] A fourth aspect of this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the method described in the first aspect.

[0014] The fifth aspect of this application provides a computer program product including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in an electronic device, a processor in the electronic device performs the steps of the method described in the first aspect above.

[0015] The above-described scheme in this application maintains a sequence number register corresponding to the TLP type for each IDE stream, and incorporates the sequence number into the calculation and verification process of MAC at the sending and receiving ends. This enables transmission verification of TLPs of the same type without occupying transmission bandwidth, achieving secure transmission protection of TLPs of the same type with extremely low hardware overhead, and filling a key gap in the existing IDE security mechanism. Attached Figure Description

[0016] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the preferred embodiments below. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0017] Figure 1 This is a hardware structure outline of some embodiments of this application. Figure 1 ;

[0018] Figure 2 This is a schematic diagram of a fault during data transmission in some embodiments of this application;

[0019] Figure 3 This is a schematic diagram illustrating another fault during data transmission in some embodiments of this application;

[0020] Figure 4 This is another fault diagram in the data transmission process of some embodiments of this application;

[0021] Figure 5 This is a schematic diagram illustrating another failure during data transmission in some embodiments of this application;

[0022] Figure 6This is a hardware structure outline of some embodiments of this application. Figure 2 ;

[0023] Figure 7 This is a flowchart illustrating a data processing method according to some embodiments of this application;

[0024] Figure 8 This is a structural diagram of the computer device provided in the embodiments of this application. Detailed Implementation

[0025] The embodiments of the technical solution of this application will now be described in detail with reference to the accompanying drawings. These embodiments are only used to more clearly illustrate the technical solution of this application and are therefore merely examples, and should not be used to limit the scope of protection of this application.

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the application; the terms “comprising” and “having”, and any variations thereof, in the specification, claims, and foregoing description of the drawings are intended to cover non-exclusive inclusion.

[0027] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0028] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0029] In the description of the embodiments in this application, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this document generally indicates that the preceding and following related objects have an "or" relationship.

[0030] The following detailed description, in conjunction with the accompanying drawings and specific embodiments, provides a detailed explanation of a PCIe CXL IDE replay and reordering protection scheme according to this application. Those skilled in the art will understand that these descriptions are exemplary and not intended to limit the scope of protection of this application.

[0031] Before describing the solutions in this application, the terms used in the embodiments will be explained.

[0032] PCIe (Peripheral Component Interconnect Express).

[0033] CXL (Compute Express Link);

[0034] IDE (Integrity and Data Encryption);

[0035] The PCIe CXL IDE protocol is used for hardware-level security protection. It is embedded in the two high-speed interconnect bus standards, PCIe and CXL, to provide integrity and data encryption protection for data transmitted on the line. At the hardware level, it provides end-to-end, high-performance confidentiality and integrity protection for high-speed data flowing within servers and data centers.

[0036] MAC (Message Authentication Code);

[0037] AES-GCM (Advanced Encryption Standard - Galois / Counter Mode).

[0038] PCI-SIG (Peripheral Component Interconnect Special Interest Group).

[0039] TLP (Transaction Layer Packet);

[0040] PR (Posted Request);

[0041] NPR (Non-Posted Request);

[0042] CPL (Completion Message);

[0043] PCRC (Protocol Cyclic Redundancy Check).

[0044] Replay protection is used to prevent attackers from repeatedly sending a previously intercepted, valid old data packet.

[0045] Reordering protection is used to prevent attackers from disrupting or delaying the normal arrival order of data packets.

[0046] Cloud computing is undergoing a major transformation as more and more devices enter the market and drive the exponential growth of cloud data. With the increasing number of "hyperscale" cloud providers in the big data and analytics field, the proliferation of 5G for rapid IoT connectivity, and the widespread use of AI for raw data processing and semantic extraction, the volume of connected data is surging and data vulnerabilities are becoming more severe.

[0047] To keep pace with the rapid growth of data, the industry is driving innovation in interface and storage technologies to support increased capacity and performance, and to meet the demands of more accelerated integration and new computing architectures. High-speed I / O interconnect interfaces such as PCI Express® (PCIe®) 5.0 / 6.0 and Compute Express Link™ (CXL™) 2.0 are proliferating.

[0048] To prevent critical information from being compromised, replaced, modified, or stolen by attackers, the system architecture must protect cloud data containing this critical information, and the high-speed I / O interconnects used must be secure from the outset.

[0049] As attacks become increasingly sophisticated, security standards must be continuously adjusted to better protect sensitive data and communications. To this end, the PCI-SIG and CXL standards organizations added IDE security requirements to the PCIe 5.0 and CXL 2.0 specifications in late 2020. This security feature was also adopted in subsequent PCIe 6.0 / 7.0 and CXL 3.0 interconnects.

[0050] In IDE technology, IDE provides confidentiality, integrity, reordering, and replay protection for the TLP and flow control units of PCIe / CXL, ensuring that data on the line cannot be spied on, tampered with, deleted, inserted, or replayed. IDE is based on the AES-GCM encryption and decryption algorithm and a built-in counter at the transceiver end, and receives keys from authentication and key management security components.

[0051] An IDE stream is a logical security context or secure channel. It defines a complete security environment, including a shared key, initialization vector, and stream identifier. It can simultaneously protect all types of TLPs flowing through it, with each type of TLP forming a sub-stream within an IDE stream. Optionally, the TLP type can include: Publish Request (PR), Non-Publish Request (NPR), and Completion Message (CPL).

[0052] The following sections will explain the implementation schemes for confidentiality, integrity, and replay protection in the aforementioned IDE technology, one by one, during some implementation processes.

[0053] Optionally, the Integrity and Data Encryption Transaction Layer (IDE TLP) packet format may include fields such as IDE TLP Prefix, Other End-End Prefixes, Header, Data, and IDE TLP MAC. Except for the other end-end prefixes, which are optional, the remaining TLP fields are generally mandatory.

[0054] The IDE TLP Prefix field is used to identify and configure integrity and data encryption transaction layer packets. Its format includes the following key fields:

[0055] M bit: Indicates whether MAC is included;

[0056] K bit: Indicates the key set used, and needs to be updated synchronously when switching keys;

[0057] T bit: indicates whether the TLP comes from a trusted execution environment;

[0058] P bit: Indicates whether PCRC (included in the TLP's Data) is included; only valid when M bit is set.

[0059] Sub-Stream and Stream_ID: ID numbers used to identify IDE sub-streams (PR, NPR, CPL) and IDE streams;

[0060] PR_Sent_Counter: Used for communication of related counters between the sender and receiver. It is used when the substream type is NPR and CPL, but not when it is PR.

[0061] In addition to transmitting IDE TLP, the sending and receiving ends also transmit IDE Messages, specifically including IDE Fail Messages and IDE Sync Messages.

[0062] The IDE Fail Message is primarily used to report errors to the peer when there are IDE encryption / decryption or MAC calculation errors. The IDE Sync Message is mainly used for synchronizing counters between the sending and receiving ends.

[0063] Under the IDE mechanism, sub-streams (PR, NPR, CPL) are configured for each IDE's encrypted stream based on the message type. Each sub-stream has its own independent 128-bit key and 96-bit initialization vector (IV) used for AES-GCM encryption and decryption.

[0064] The confidentiality of the IDE is primarily achieved through the AES algorithm of the AES-GCM engine at the sending end encrypting the IDE TLP and the AES algorithm of the AES-GCM engine at the receiving end decrypting the TLP. This requires the use of authentication and key management security components to configure the IDE stream, keys, and initialization vector. During TLP transmission, only the Data segment of the data packet undergoes encryption and decryption.

[0065] The integrity of the IDE is mainly achieved through the GCM algorithm of the AES-GCM engine, which calculates the MAC for each field segment of the IDE TLP, including IDE TLP Prefix, Other End-End Prefixes, Header, and Data, and performs authentication processing.

[0066] During message authentication, the AES-GCM engine in the sending end calculates the MAC for each field in the TLP using the key and MAC algorithm, and then writes the MAC into the TLP and sends it to the receiving end. After receiving the TLP, the receiving end calculates a MAC for the TLP based on the key and MAC algorithm, and compares the MAC with the MAC carried in the TLP. If the two are the same, the TLP is considered to be genuine and its integrity has been verified; otherwise, it is considered to have a problem.

[0067] The IDE TLP replay protection rules that need to be maintained include anti-interference packet, anti-packet loss, and anti-replay packet rules. Under the IDE TLP ordering rules that need to be maintained, during the transmission of different types of TLPs, the transmission order of PR is allowed to exceed NPR and CPL, but not to exceed the same type of PR; the transmission order of NPR is allowed to exceed CPL, but not to exceed NPR and PR; CPL is not allowed to exceed any type of TLP, and TLPs of the same type are not allowed to exceed each other.

[0068] IDE replay and reordering protection is mainly implemented through dedicated counters at the sending and receiving ends. The current IDE mechanism allows each IDE stream (i.e., the encrypted stream of the IDE) to independently maintain two sets of counters, as follows:

[0069] The sending end maintains two 8-bit counters for each IDE stream: PR_Sent_Counter-NPR and PR_Sent_Counter-CPL.

[0070] PR_Sent_Counter-NPR is used to count the number of PRs sent since the last NPR or IDE synchronization message.

[0071] PR_Sent_Counter-CPL is used to count the number of PRs sent since the last CPL or IDE synchronization message was sent.

[0072] The sending end's operation rules are as follows:

[0073] When establishing the IDE stream and entering a safe initial state, the values ​​of the two counters are initialized to 0.

[0074] Both counters increment by 1 for each PR transaction layer data packet belonging to this IDE stream sent.

[0075] When sending an NPR transaction layer packet, the current value of PR_Sent_Counter - NPR is filled into the PR_Sent_Counter field of its transaction layer packet prefix; then the counter is cleared.

[0076] When sending a CPL transaction layer data packet, the current PR_Sent_Counter-CPL value is filled into the PR_Sent_Counter field of the prefix of its transaction layer data packet; then the counter is cleared.

[0077] When either counter reaches 245, an IDE Sync message must be sent to synchronize the counters on both the receiver and sender. Alternatively, it can be sent proactively at other times. Before each IDE Sync message is sent, both counters are incremented by 1; after the Sync message is constructed, both counters are then reset to zero.

[0078] The receiver maintains two 64-bit counters for each IDE stream: PR_Received_Counter-NPR and PR_Received_Counter-CPL.

[0079] PR_Received_Counter-NPR is used to count the number of PRs received since the last NPR was received.

[0080] PR_Received_Counter-CPL is used to count the number of PRs received since the last CPL was received.

[0081] Some operating rules for the receiving end during implementation:

[0082] When establishing the IDE stream and entering a safe initial state, the values ​​of the two counters are initialized to 0.

[0083] Each time a PR transaction layer data packet for this IDE stream is received, both counters are incremented by 1.

[0084] When an NPR transaction layer data packet is received, the current value of PR_Received_Counter-NPR is subtracted from the PR_Sent_Counter value in its IDE prefix; the value of PR_Received_Counter-NPR is then updated to the result of the subtraction; if the counter underflows, it is considered an IDE error.

[0085] When a CPL transaction layer data packet is received, the value of PR_Received_Counter-CPL is subtracted from the value of PR_Sent_Counter; the value of PR_Received_Counter-CPL is then updated to the result of the subtraction; if the counter underflows, it is considered an IDE error.

[0086] When an IDE Sync message is received, the local PR_Received_Counter-NPR value is subtracted from the PR_Sent_Counter-NPR value carried in the message; the local PR_Received_Counter-CPL value is subtracted from the PR_Sent_Counter-CPL value carried in the message; if either counter underflows, it is considered an IDE error.

[0087] The hardware system described above can be partially or entirely integrated into a PCIe / CXL device that supports IDE functionality. See also... Figure 1 As shown in the figure, a data transmission interaction system is formed by two sets of transmitting ends (IDE TX) and receiving ends (IDE RX).

[0088] Each set of transmitters and receivers is equipped with an AES (Advanced Encryption Standard) controller, an AES data packetizer, an IDE stream controller, and a TLP data packetizer. The transmitter also includes an IDE message processor. Within each set of transmitters and receivers, the IDE TX connects to the TX processing module in the PCIe / CXL controller, and the IDE RX connects to the RX processing module in the PCIe / CXL controller. The PCIe / CXL controller is connected to the physical layer. The two sets of transmitters (IDE TX) and receivers (IDE RX) are connected via their respective physical layers and PCIe / CXL links, enabling data transfer between different sets of devices.

[0089] In the above implementation, the confidentiality and integrity of IDE are ensured, but its replay and reordering protection has significant problems. This is mainly reflected in the near absence of protection against similar TLPs, making it vulnerable to attacks when switches, retimers, or dedicated devices are present on the PCIe transmission link. The following are some examples of situations where protection is not possible:

[0090] Combination Figure 2-5 As shown, taking a PR (Programmable Message Password) as an example, during the process of sending a PR from the sender to the receiver, data transmission may encounter faults such as packet insertion, packet loss, replay, and reordering. Figure 2 As shown, an attacker might transmit an insertion packet PRx to the receiving end, or as... Figure 3 As shown, an attacker could cause PR1 to be lost, or as... Figure 4 As shown, an attacker could cause PR1 to be transmitted a second time to the receiving end, or as... Figure 5 As shown, PR1, which is sent first by the sender, is transmitted to the receiver after PR2. A similar situation exists when the TLP type is NPR and CPL.

[0091] The above-described implementation of the PCIe / CXL IDE protocol has insufficient protection against replay and reordering of the same type of TLP.

[0092] In this regard, this embodiment also provides a hardware system and method for implementing enhanced replay and reordering protection in the PCIe / CXL IDE protocol. It is used to accurately detect fine-grained reordering, replay, insertion, and packet loss of the same type of TLP with minimal hardware resources and without additional PCIe transmission data bandwidth. This fills a key gap in the PCIe / CXL IDE security mechanism. At the same time, the solution in this embodiment can also effectively improve the decryption complexity of MAC generated based on AES-GCM encryption in the IDE.

[0093] The hardware system described above can be partially or entirely integrated into a PCIe / CXL device that supports IDE functionality. See also... Figure 6 As shown, this hardware system is... Figure 1 The difference lies in the addition of segmentation registers at both the receiving and transmitting ends. These segmentation registers are specifically located in the AES controllers at both the transmitting and receiving ends.

[0094] Based on this, combined Figure 7 As shown in the embodiments of this application, a data processing method is provided, including:

[0095] Step 701: At the sending and receiving ends, maintain a sequence number register corresponding to the different types of TLPs for each IDE stream.

[0096] Optionally, different types of TLPs include at least publish requests (PRs), non-publish requests (NPRs), and completion messages (CPLs) to meet the processing needs of different types of transaction layer packets.

[0097] A serial number is a unique, incrementing (or cyclically advancing) identification number assigned sequentially to each TLP of the same type.

[0098] In some embodiments of this application, in addition to maintaining an independent counter for each IDE stream, a sequence number register is added to both the sending and receiving ends. Optionally, the sequence number register can be a segment register.

[0099] Optionally, the sending end maintains a first number of 8-bit counters and a second number of 64-bit sequence number registers for each IDE stream. The receiving end maintains a first number of 64-bit counters and a second number of 64-bit segment registers for each IDE stream. The number of bits in the counters and sequence number registers can be selected according to actual needs and is not limited thereto.

[0100] Optionally, the first quantity can be 2, and the second quantity can be 3.

[0101] The counter is used to ensure the integrity of transmitted data and to encrypt the data. Specifically, the counter mode specified in AES-GCM can be used to implement the relevant functions.

[0102] Optionally, the sequence number register is a segmented register, which contains a package offset field for auto-incrementing and cyclic counting, and a random epoch field.

[0103] The segment register in the receiver contains a packing offset field and a random epoch field.

[0104] In the packaging offset field, this field is incremented by 1 for each TLP of the same type sent, providing a local, continuous, and predictable short-term sequence identifier for each TLP. It can be automatically reset to zero after it is full, handling the sequence counting and cycling of daily data transmissions with minimal hardware cost.

[0105] The initial value of the random epoch field comes from the random initialization vector (IV) used by AES-GCM. The IV is provided by the upper-layer security protocol and is an unpredictable random number to the attacker. This makes the entire sequence number random from the beginning, and the attacker cannot deduce the starting point or pattern of the sequence number. This field is incremented by 1 only when the packet offset field completes a full cycle and carries over. The random epoch is not explicitly transmitted in the data packet but is implicit in the MAC calculation. Attackers cannot directly steal or observe it, thus making it impossible to forge a TLP with a future or legitimate sequence number, greatly raising the barrier to replay and forgery attacks.

[0106] Optionally, the segment register in the transmitting end also includes an overflow flag field. This flag is set to 1 when the random epoch field has also completed a full cycle from its initial value (an extreme case after an extremely long process). Once this flag is set, the hardware forces an update of the key and IV. After the update, all registers are reinitialized, the sequence number space is completely refreshed, and the system enters a new security cycle. This design ensures the long-term security of the system.

[0107] The receiver's registers also contain a packing offset field and a random epoch field, which function mirrored those of the sender and are used to generate the expected sequence number for verifying the MAC sent from the sender.

[0108] In addition, optionally, the receiver's register also includes two fields dedicated to fault tolerance and attack detection: an out-of-order compensation value field and an out-of-order flag field.

[0109] The out-of-order compensation range is used to tolerate genuine out-of-order delivery and limit the attack window. In high-speed systems, due to differences in physical paths, TLPs may experience slight order discrepancies (e.g., TLP-N arrives a few clock cycles later than TLP-N+1). This range allows the receiver to dynamically adjust the sequence number used for verification by trying different compensation values ​​within a small window (e.g., ±7) around the expected value (N). If the adjusted MAC verification is successful, it indicates that the TLP is legitimate but out of order, and the system can continue to operate. This compensation value is strictly limited to a very small range (e.g., ±7). If an attacker attempts to insert or replay a TLP with a sequence number outside this window (e.g., skipping many packets), the system will be unable to match it by adjusting the compensation value, thus immediately detecting a malicious attack rather than ordinary out-of-order delivery.

[0110] The out-of-order flag field is set when the receiver successfully verifies a TLP by adjusting the out-of-order compensation value. This flag is a "soft" alert that tells the upper-layer software, "The current link may have experienced unstable out-of-order delivery, but the hardware has handled it automatically." The software can use this flag for monitoring, logging, or diagnostics without immediately interrupting communication, thus improving system availability and manageability.

[0111] In some embodiments of this application, in addition to maintaining two sets of counters independently for each IDE stream, three sets of segment registers are added to each IDE stream.

[0112] For example, the sending end maintains two 8-bit counters and three 64-bit segment registers for each IDE stream to perform data statistics for different types of TLPs being sent:

[0113] PR_Sent_Counter-NPR (8 bits): Counts the number of PRs sent since the last NPR or IDE Sync message.

[0114] PR_Sent_Counter-CPL (8 bits): Counts the number of PRs sent since the last CPL or IDE Sync message was sent.

[0115] PR_Sent_Reg (64 bits): Counts the sequence number (random epoch + packing offset) and overflow (OV) bits of the PR type TLP sent since the IDE stream was established and the KEY / IV was updated.

[0116] NPR_Sent_Reg (64 bits): Statistics on the sequence number (random epoch + wrapper offset) and overflow bit of the NPR type TLP sent since the IDE stream was established and the KEY / IV was updated.

[0117] CPL_Sent_Reg (64 bits): Counts the sequence number (random epoch + package offset) and overflow bit of the CPL type TLP sent since the IDE stream was established and the KEY / IV was updated.

[0118] Optionally, in the above PR / NPR / CPL_Sent_Reg register structure, the lower 32 bits are an auto-incrementing cyclic counter field, the middle 27 bits (bits 32-58) are a random epoch field, and the highest bit is an overflow field.

[0119] The receiving end maintains two 64-bit counters and three 64-bit segment registers for each IDE stream, and performs data statistics for different types of received TLPs respectively:

[0120] PR_Received_Counter-NPR (64-bit): Counts the number of PRs received since the last NPR was received.

[0121] PR_Received_Counter-CPL (64-bit): Counts the number of PRs received since the last CPL was received.

[0122] PR_Recv_Reg (64-bit): Counts the sequence number (random epoch + packaging offset) of the received PR type TLP since the IDE stream was established and the KEY / IV was updated, the out-of-order compensation value field (Sign + Bias), and the out-of-order flag field (Flag).

[0123] NPR_Recv_Reg (64-bit): The sequence number (random epoch + packaging offset) of the received NPR type TLP since the IDE stream was established and the KEY / IV was updated. It includes an out-of-order compensation value field and an out-of-order flag field.

[0124] CPL_Recv_Reg (64-bit): The sequence number (random epoch + packaging offset) of the received CPL type TLP since the IDE stream was established and the KEY / IV was updated. It includes an out-of-order compensation value field and an out-of-order flag field.

[0125] Optionally, in the above PR / NPR / CPL_Recv_Reg register structure, the lower 32 bits are an auto-incrementing cyclic counter field, the middle 27 bits (bits 32-58) are a random epoch field, the next 4 bits are an out-of-order compensation value field (Sign+Bias, bits 59-62, supporting compensation values ​​from -7 to +7), and the highest bit is the out-of-order flag field (Flag).

[0126] The above-mentioned structural features form the basis for achieving fine-grained replay and reordering protection for the same type of TLP in the PCIe / CXL IDE protocol in the embodiments of this application without occupying transmission bandwidth.

[0127] In an optional implementation, the method further includes:

[0128] In both the sending and receiving ends, when initializing the IDE stream, a random value is generated based on the initialization vector of the initial state allocated to the IDE stream, and the random epoch field is initialized to the random value; or, in both the sending and receiving ends, when updating the key and initialization vector of the IDE stream, a random value is generated based on the updated initialization vector, and the random epoch field is initialized to the random value.

[0129] In an optional implementation, when initializing the IDE stream, the sending and receiving ends generate the same random value based on the same initialization vector of the initial state, and initialize the random epoch field in their respective sequence number registers to the random value; or, when updating the key and initialization vector of the IDE stream, the sending and receiving ends generate the same random value based on the updated initialization vector, and initialize the random epoch field in their respective sequence number registers to the random value.

[0130] Step 702: When the sending end sends the TLP to the receiving end, it calculates the first MAC based on the current sequence number of the corresponding type of sequence number register maintained locally, and appends the first MAC to the TLP for transmission.

[0131] In an optional implementation, the sequence number register maintained by the sender also includes an overflow flag field. When the packaging offset field returns to zero after completing a counting cycle, causing the value of the random epoch field to roll back, the sender sets the overflow flag in the overflow flag field; when the overflow flag is set, an update to the key and initialization vector of the IDE stream is triggered.

[0132] In this embodiment of the application, the specific data processing method includes both a sending end and a receiving end. The specific implementation method of the sending end is as follows:

[0133] In the sending end operation process, taking the processed TLP as a PR (Publish Request) as an example, the detailed workflow of the sending end is as follows:

[0134] 1. Initialization: When an IDE stream is established, or when the key / initialization vector (IV) is updated, the sender controller initializes the PR_Sent_Reg segment register for that IDE stream. Specifically, the lower 27 bits are taken from the 96-bit IV used by the AES-GCM engine and filled into the random epoch field (bits 32-58) of PR_Sent_Reg; its packing offset field (bits 0-31) and overflow flag field (bit 63) are cleared. The packing offset field and the random epoch field together form a 59-bit PR sequence number register (PRSequence ID Reg).

[0135] 2. Processing PR TLP:

[0136] When a PR TLP needs to be sent, the sending controller first increments the two 8-bit counters, PR_Sent_Counter-NPR and PR_Sent_Counter-CPL, by 1.

[0137] Subsequently, the AES-GCM engine performs MAC calculations. Unlike existing technologies, the MAC calculation inputs in this embodiment include not only the TLP prefix, packet header, and data segment, but also the value of the current sequence number register (PR Sequence IDReg) corresponding to the PR.

[0138] The calculated MAC is placed in the IDE TLP MAC field of the TLP. Subsequently, the complete IDE TLP is sent to the physical link.

[0139] After TLP is successfully sent, the value of PR Sequence ID Reg is incremented by 1 (that is, the packaging offset field is incremented, and if it overflows, it is carried over to the random epoch field).

[0140] 3. Handling NPR / CPL TLP:

[0141] When sending an NPR TLP, the process is similar to that of a PR, but the operation target is the NPR_Sent_Reg register. Simultaneously, the current PR_Sent_Counter - NPR value needs to be filled into the IDE prefix of the TLP, and then the counter is cleared.

[0142] When sending CPL TLP, the operation target is the CPL_Sent_Reg register, and the counter is cleared after the PR_Sent_Counter-CPL value is filled into the IDE prefix.

[0143] 4. Register maintenance and key update:

[0144] When the wrapper offset field of PR_Sent_Reg returns to zero from its maximum value, the random epoch field is incremented by 1.

[0145] If the value of the random epoch field cycles back to the initial value minus one, the overflow flag of PR_Sent_Reg is set. Once the overflow flag of the Sent_Reg register corresponding to any type of TLP is set, the sender must initiate a key / IV update (by sending an IDE TLP with K bit=1) and reinitialize all Sent_Reg registers after the update.

[0146] In one implementation process, the operating rules of the sending end are as follows:

[0147] When the IDE stream is established and the system enters a safe initial state (IV and Key are configured), the PR_Sent_Counter and NPR / CPL counters are initialized to 0. The random epoch field in the three segmented registers PR / NPR / CPL_Sent_Reg is initialized to the lower 27 bits of the 96-bit IV value used in AES-GCM, and all other fields are cleared to zero. The 32-bit auto-incrementing cyclic counter field and the 27-bit random epoch field are combined into a 59-bit PR / NPR / CPL sequence ID register (PR / NPR / CPLsequence ID Reg).

[0148] For each PR TLP belonging to this IDE stream transmitted, both the PR_Sent_Counter and NPR / CPL counters are incremented by 1. The lower 59 bits of the PR_Sent_Reg register, representing the current value of the sequence number register, are retrieved and added to the MAC calculation process of AES-GCM. This MAC is then used to replace the original MAC in the IDE PR TLP and sent to the receiving end. After transmission is complete, the PR sequenceID Reg register is incremented by 1.

[0149] When sending the NPR TLP belonging to this IDE stream, the current PR_Sent_Counter - NPR value is filled into the PR_Sent_Counter field of its IDE prefix; then the counter is cleared. The lower 59 bits of the NPR_Sent_Reg register, representing the current value of the sequence number register, are taken and added to the MAC calculation process of AES-GCM, and this MAC replaces the original MAC in the IDE PR TLP and is sent to the receiving end. After transmission is complete, the NPR sequence ID Reg register is incremented by 1.

[0150] When sending a CPL TLP belonging to this IDE stream, the current PR_Sent_Counter-CPL value is filled into its IDE prefix; then the counter is cleared. The lower 59 bits of the CPL_Sent_Reg register, representing the current value of the sequence number register, are taken and added to the MAC calculation process of AES-GCM, and this MAC replaces the original MAC in the IDE PR TLP before being sent to the receiving end. After transmission is complete, the CPL sequence ID Reg register is incremented by 1.

[0151] When either PR_Sent_Counter-NPR / CPL counter reaches 245, an IDE Sync message must be sent to synchronize the transceiver counters. Alternatively, it can be sent proactively at other times. Before each IDE Sync message is sent, both counters are incremented by 1; after the Sync message is constructed, both counters are cleared.

[0152] In the IDE stream, for each PR / NPR / CPL type TLP sent, the 32-bit auto-incrementing cyclic counter field in the corresponding PR / NPR / CPL_Sent_Reg is incremented by one. When the 32-bit auto-incrementing cyclic counter field is full, it is reset to zero and re-accumulated. The 27-bit random epoch field is incremented by one. When the 27-bit random epoch completes one cycle from the initial value back to the initial value -1, the OV (overflow) bit in PR / NPR / CPL_Sent_Reg is set to 1. When the OV (overflow) bit in any PR / NPR / CPL_Sent_Reg register is 1, an IDE TLP with K bit=1 in the Prefix must be sent to update the current Key / IV value of the backup IDE Stream's Key / IV and initialize the PR / NPR / CPL_Sent_Reg register at the sending end.

[0153] Step 703: When receiving a TLP, the receiving end calculates a second MAC based on the expected sequence number of the corresponding type of sequence number register maintained locally, and compares the second MAC with the received first MAC to verify the TLP.

[0154] Specifically, verifying the TLP involves verifying its integrity and sequence correctness.

[0155] In an optional implementation, the sequence number register maintained by the receiving end further includes an out-of-order compensation value field. Correspondingly, step 703 compares the second MAC with the received first MAC to verify the TLP, including:

[0156] In the receiving end, when the second MAC is compared with the received first MAC and the first MAC is determined to have failed to be verified based on the comparison result, the value of the out-of-order compensation range is adjusted within a preset range to obtain the adjusted expected sequence number.

[0157] The second MAC is recalculated based on the adjusted expected sequence number, and the recalculated second MAC is compared with the first MAC to re-verify the TLP.

[0158] This process, with the help of the maintained sequence number register, uses the out-of-order compensation value field within it to attempt to adjust the expected sequence number with different compensation values. Based on this, the MAC value is recalculated, and the MAC carried in the received TLP is verified. Out-of-order anomalies within the normal range of legitimate TLPs are eliminated to ensure normal data transmission and processing.

[0159] Optionally, the sequence number register maintained by the receiver may also include an out-of-order flag field.

[0160] Correspondingly, step 703, which compares the second MAC with the received first MAC to verify the TLP, also includes:

[0161] If the TLP is successfully verified within the preset number of adjustments during the re-verification process, an out-of-order flag is set in the out-of-order flag field.

[0162] If the verification fails within the preset number of adjustments, an error will be reported.

[0163] Through the above processing, it is possible to effectively record abnormal situations and effectively report errors for transmitted data that fails to be verified. Under the condition of excluding abnormal situations within the normal range, it is possible to effectively verify and detect security threats in the abnormal range between TLPs of the same type, and realize secure transmission protection for TLPs of the same type.

[0164] In this embodiment of the application, the specific data processing method includes both a sending end and a receiving end. The specific implementation method of the receiving end is as follows:

[0165] In the receiving end operation process, taking the processed TLP as a PR (Publish Request) as an example, the detailed workflow of the receiving end is as follows:

[0166] 1. Initialization: Symmetrical to the sender, the receiver initializes the random epoch field of PR_Recv_Reg with the lower 27 bits of the IV when the IDE stream is established or the key / IV is updated, and clears the packaging offset field, the out-of-order compensation value field (Sign+Bias, bits 59-62) and the out-of-order flag field (Flag, bit 63) to form a local PR expected sequence number register, which has an expected sequence number.

[0167] 2. MAC verification:

[0168] Upon receiving a PR TLP, the receiver controller first increments PR_Received_Counter-NPR and PR_Received_Counter-CPL by 1.

[0169] The AES-GCM engine begins verifying the MAC. It uses the locally maintained PR expected sequence number (i.e., the lower 59 bits of PR_Recv_Reg) and the result of adding the out-of-order compensation value (Sign+Bias) as one of the inputs to recalculate the MAC.

[0170] First round of verification: The receiving end directly compares the calculated MAC with the MAC carried in the TLP. If they match, the verification passes.

[0171] 3. Out-of-order processing:

[0172] If the first round of verification fails, the receiver's control logic initiates an out-of-order compensation mechanism. It can adjust the values ​​of the out-of-order compensation range sequentially according to the order of "0, +1, -1, +2, -2, ..., +7, -7".

[0173] For each adjusted compensation value, the AES-GCM engine recalculates the MAC and compares it with the received MAC. This process may involve up to 15 attempts (covering a range of ±7).

[0174] Successful scenario: If the MAC comparison succeeds within 15 attempts, it means the TLP is valid but out of order. The receiver sets the out-of-order flag in PR_Recv_Reg and maintains this valid compensation value when processing subsequent PR TLPs until the next key / IV update. Subsequently, the PR expected sequence number register is incremented by 1, and the TLP is reported normally.

[0175] Failure scenario: If more than 15 attempts fail, it is considered an IDE error (such as a replay attack or severe tampering). The receiving end will trigger the error handling process (such as reporting an IDE Fail Message), clear the out-of-order compensation field and the out-of-order flag field, and restore the initial verification state.

[0176] 4. Handling NPR / CPL TLP:

[0177] The process is similar to PR, but the operation targets are the NPR_Recv_Reg and CPL_Recv_Reg registers, respectively. Simultaneously, the corresponding PR_Received_Counter counter needs to be updated based on the PR_Sent_Counter value in the TLPIDE prefix, and an underflow check needs to be performed.

[0178] In one implementation process, the operating rules of the receiving end are as follows:

[0179] When the IDE stream is established and the system enters a safe initial state (IV and Key are configured), the PR_Received_Counter and NPR / CPL counters are initialized to 0. The random epoch field in the three segmented registers PR / NPR / CPL_Recv_Reg is initialized to the lower 27 bits of the 96-bit IV value used in AES-GCM, and all other fields are cleared to zero. The 32-bit auto-incrementing cyclic counter field and the 27-bit random epoch field are combined into a 59-bit PR / NPR / CPL sequence ID register (PR / NPR / CPL sequence ID Reg).

[0180] For each PR TLP received from this IDE stream, both PR_Sent_Counter-NPR / CPL counters are incremented by 1. The lower 59 bits of the PR_Recv_Reg register, representing the current value of the sequence number register, are added to the out-of-order compensation value (Sign+Bias) and incorporated into the AES-GCM MAC calculation process. This MAC is then compared with the original MAC in the received PR IDE TLP. If the MAC comparison results match, the IDE transmission is considered successful, and the PR sequence ID Reg register is incremented by 1, while the out-of-order flag field (Flag) is cleared. If the MAC comparison results do not match, the out-of-order compensation value is adjusted according to the principle of center priority followed by diffusion (e.g., if the initial compensation value is 0, it is adjusted sequentially as 0, +1, -1, +2, -2…), and the MAC is recalculated and compared again. If the comparison is successful within 15 compensation value adjustments, the out-of-order flag field (Flag) is set, and the IDE is considered out-of-order. Afterward, the out-of-order compensation value (Sign+Bias) remains unchanged and is incorporated into the MAC calculation of the next PR IDE TLP. If the compensation value is adjusted more than 15 times, it is considered an IDE error, and the out-of-order flag field (Flag) will be cleared to zero.

[0181] Upon receiving an NPR TLP for this IDE stream, the current PR_Received_Counter - NPR is subtracted from the PR_Sent_Counter value in its IDE prefix, and PR_Received_Counter - NPR is updated to the result of the subtraction. If the counter underflows, it is considered an IDE error. The lower 59 bits of the NPR_Recv_Reg register, representing the current value of the sequence number register, are added to the out-of-order compensation value (Sign + Bias) and incorporated into the MAC calculation process of AES-GCM. This MAC is then compared with the original MAC in the received NPR IDE TLP. If the MAC comparison result matches, the IDE transmission is considered successful, and the NPR sequence ID Reg register is incremented by 1, while the out-of-order flag field is cleared. If the MAC comparison result does not match, the out-of-order compensation value is adjusted according to the principle of center priority followed by diffusion (e.g., if the initial compensation value is 0, it is adjusted sequentially according to 0, +1, -1, +2, -2...), and the MAC is recalculated and compared again. If the compensation value adjustment is successful within 15 attempts, the out-of-order flag field (Flag) is set, and the system is considered to have an out-of-order IDE. Afterward, the out-of-order compensation value field (Sign+Bias) remains unchanged and is incorporated into the MAC calculation of the next NPR IDE TLP. If the compensation value adjustment exceeds 15 attempts, it is considered an IDE error, and the out-of-order flag field (Flag) is cleared to zero.

[0182] Upon receiving a CPL TLP of this IDE stream, the PR_Sent_Counter value is subtracted from PR_Received_Counter - CPL, and PR_Received_Counter - CPL is updated to the result of the subtraction. If the counter underflows, it is considered an IDE error. The lower 59 bits of the CPL_Recv_Reg register, representing the current value of the sequence number register, are added to the out-of-order compensation field (Sign + Bias) and incorporated into the MAC calculation process of AES-GCM. This MAC is then compared with the MAC carried in the received CPL IDETLP. If the MAC comparison result matches, the IDE transmission is considered successful, and the PRsequence ID Reg register is incremented by 1, while the out-of-order flag field is cleared. If the MAC comparison result does not match, the out-of-order compensation value is adjusted according to the principle of center priority followed by diffusion (e.g., if the initial compensation value is 0, it is adjusted sequentially according to 0, +1, -1, +2, -2…), and the MAC is recalculated and compared again. If the compensation value adjustment is successful within 15 attempts, the out-of-order flag field (Flag) is set, and the result is considered an out-of-order IDE. Afterward, the out-of-order compensation value field (Sign+Bias) remains unchanged and is incorporated into the MAC calculation of the next CPLIDE TLP. If the compensation value adjustment exceeds 15 attempts, it is considered an IDE error, and the out-of-order flag field (Flag) is cleared to zero.

[0183] When an IDE Sync message is received, the local PR_Received_Counter-NPR is subtracted from the PR_Sent_Counter-NPR value carried in the message; the local PR_Received_Counter-CPL is subtracted from the PR_Sent_Counter-CPL value carried in the message; if either counter underflows, it is considered an IDE error.

[0184] In the IDE stream, upon receiving a PR / NPR / CPL type TLP, the 32-bit auto-incrementing cyclic counter field in the corresponding PR / NPR / CPL_Recv_Reg is incremented by one. When the 32-bit auto-incrementing cyclic counter field is full, it is reset to zero and re-accumulated. The 27-bit random epoch field is incremented by one. When an IDE TLP with K bit=1 in the prefix is ​​received, the Key / IV value of the backup IDE Stream is updated to the current Key / IV value, and the PR / NPR / CPL_Recv_Reg register at the sending end is initialized.

[0185] Through the implementation of the above embodiments, the embodiments of this application have achieved the following significant effects:

[0186] The above process can effectively detect illegal TLPs inserted into continuous PR TLP streams. The receiving end calculates and verifies the MAC based on the sequence number, and triggers error reporting in a timely manner when verification fails.

[0187] Furthermore, in some cases, when two consecutive PR TLPs are swapped (reordered) due to link delay, the receiver successfully verifies the second TLP by activating the out-of-order compensation mechanism (e.g., adjusting the compensation value to +1) and marks it as out of order, but without interrupting communication, thus ensuring the robustness of the system.

[0188] Furthermore, the entire process described above utilizes minimal hardware resources; the transceiver only requires adding three segment registers to each IDE stream, without the need for additional TLP buffers or RAM. During data transmission, the sequence number is implicitly transmitted via MAC, without occupying any extra bits in the TLP, thus not consuming PCIe transmission bandwidth and incurring zero overhead on PCIe / CXL effective bandwidth. This application's method enhances security while meeting the stringent bandwidth and hardware efficiency requirements of high-performance computing.

[0189] In order to address the serious lack of protection against replay and reordering of the same type of TLP in the existing PCIe IDE technology, this application embodiment achieves precise detection of fine-grained reordering, replay, insertion, and packet loss of the same type of TLP using very few hardware resources and without additionally occupying the data bandwidth of PCIe transmission, filling a key gap in the PCIe / CXL IDE security mechanism.

[0190] Meanwhile, in the above embodiments, the Random Epoch field is updated with the update of the random IV written by the secure channel, and the implicit sequence number (random epoch + wrapper offset) is not reflected in the IDE TLP, making it impossible for attackers to predict the sequence number. It is also difficult to forge the MAC calculated based on the sequence number field, thus increasing the complexity of MAC decryption in IDE AES-GCM and making it more difficult to implement reordering and replay attacks.

[0191] Meanwhile, in some implementations, the PR / NPR / CPL Sequence ID Reg can be used up to 59 bits (32-bit random epoch + 27-bit wrapper offset), supporting continuous transmission of 259 IDE TLPs with unique serial numbers. Based on the current mainstream PCIe X32 Gen5 maximum bandwidth rate of 128GB / s, even with the smallest continuous transmission of the IDE TLP (24B in size: 4B IDE Prefix + 12B Header + 0B Data + 8B PL & DLL consumption), it can still sustain continuous transmission for 1165 days (3.2 years) with unique serial numbers. These unique serial numbers further increase the difficulty of reordering / replay attacks, improving the security of IDE transmission.

[0192] Furthermore, in the above embodiments of this application, the out-of-order compensation value range (Sign+Bias) is used at the receiving end to sensitively identify reordering and replay attacks within a certain range (the sequence number can be tentatively set to ±7 range in this embodiment) without affecting the subsequent normal transmission of IDE TLPs. The identified attacks are marked with an out-of-order flag, which marks potentially erroneous IDE TLPs. After the attacks are reported, the system software makes the final decision on whether to operate on the PCIe link and IDE stream, providing a decision basis for the upper-layer system software and ensuring the security of data transmission.

[0193] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0194] In the above embodiments of this application, the various embodiments and implementation methods can be combined with each other, and there is no obstacle to their combination due to the separate description of the embodiments and implementation methods. The implementation processes of the various embodiments and implementation methods can be referred to each other, and features can be integrated to form an overall solution that includes the technical features of the various embodiments or implementation methods.

[0195] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0196] Based on the same inventive concept, embodiments of this application also provide a transmitting end device for implementing the method described above, comprising:

[0197] At least three sequence number registers are used to maintain sequence numbers for TLPs of publish request, non-publish request, and completion message types, respectively.

[0198] Based on the same inventive concept, embodiments of this application also provide a receiving end device for implementing the method described above, comprising:

[0199] At least three sequence number registers are used to maintain expected sequence numbers for TLPs of publish requests, non-publish requests, and completion message types, respectively. The sequence number registers include an out-of-order compensation value field, an out-of-order flag field, and an overflow flag field.

[0200] The transmitting and receiving devices provided in this application can implement the various processes of the above-described data processing method embodiments and achieve the same technical effect. Therefore, the specific limitations of the transmitting and receiving devices provided in this application can be found in the limitations of the data processing method above. To avoid repetition, they will not be repeated here.

[0201] This embodiment can divide the computing side into functional modules according to the above method. For example, it can be divided into functional modules corresponding to each function, or two or more functions can be integrated into one processing module.

[0202] Figure 8 This is a structural diagram of a computer device provided in an embodiment of this application. Figure 8 As shown, the computer device 8 of this embodiment includes: at least one processor 80 ( Figure 8 (Only one is shown in the diagram), memory 81, and computer program 82 stored in said memory 81 and executable on said at least one processor 80, wherein said processor 80 executes said computer program 82 to implement the steps in any of the above method embodiments.

[0203] The computer device 8 may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 8 may include, but is not limited to, a processor 80 and a memory 81. Those skilled in the art will understand that... Figure 8 This is merely an example of computer device 8 and does not constitute a limitation on computer device 8. It may include more or fewer components than shown, or combine certain components, or different components. For example, the computer device may also include input / output devices, network access devices, buses, etc.

[0204] The processor 80 can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0205] The memory 81 can be an internal storage unit of the computer device 8, such as a hard disk or memory of the computer device 8. The memory 81 can also be an external storage device of the computer device 8, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card equipped on the computer device 8. Furthermore, the memory 81 can include both internal and external storage units of the computer device 8. The memory 81 is used to store the computer program and other programs and data required by the computer device. The memory 81 can also be used to temporarily store data that has been output or will be output.

[0206] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0207] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0208] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0209] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0210] The units described as separate components may or may not be physically separate. 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0211] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0212] If the integrated module / unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can also be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include: any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium can be appropriately added or removed according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electrical carrier signals and telecommunication signals.

[0213] The methods described in this application can be implemented in whole or in part by a computer program product. When the computer program product is run on a computer device, the computer device can execute the steps in the various method embodiments described above.

[0214] The embodiments described above are merely illustrative of the technical solutions of this application and are not intended to limit it. Although this application 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. 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 this application, and should all be included within the protection scope of this application. The various embodiments of this application can be referred to, combined with, and applied to each other.

Claims

1. A data processing method, characterized by, include: At both the sending and receiving ends, a sequence number register corresponding to the Transaction Layer Packet (TLP) is maintained for each integrity and data encryption IDE stream; When the sending end sends a TLP to the receiving end, it calculates the first message authentication code (MAC) based on the current sequence number of the corresponding type of sequence number register maintained locally, and appends the first MAC to the TLP for transmission. When receiving a TLP, the receiving end calculates a second MAC based on the expected sequence number of the corresponding type of sequence number register maintained locally, and compares the second MAC with the received first MAC to verify the TLP.

2. The method of claim 1, wherein, The sequence number register is a segmented register, which includes a package offset field for auto-incrementing and cyclic counting, and a random epoch field.

3. The method of claim 2, wherein, The method further includes: In both the sending and receiving ends, when initializing the IDE stream, a random value is generated based on the initialization vector of the initial state allocated to the IDE stream, and the random epoch field is initialized to the random value; or, In both the sending and receiving ends, when updating the key and initialization vector of the IDE stream, a random value is generated based on the updated initialization vector, and the random epoch field is initialized with the random value.

4. The method according to claim 2, characterized in that, The sequence number register maintained by the transmitting end also includes an overflow flag field; When the packaging offset field returns to zero after completing one round of counting and causes the value of the random epoch field to roll back, the sending end sets an overflow flag in the overflow flag field; When the overflow flag is set, an update to the key and initialization vector of the IDE stream is triggered.

5. The method according to claim 2, characterized in that, The sequence number register maintained by the receiving end also includes an out-of-order compensation value field; the step of comparing the second MAC with the received first MAC to verify the TLP includes: In the receiving end, when the second MAC is compared with the received first MAC and the first MAC is determined to be unverified based on the comparison result, the value of the out-of-order compensation value range is adjusted within a preset range to obtain the adjusted expected sequence number. The second MAC is recalculated based on the adjusted expected sequence number, and the recalculated second MAC is compared with the first MAC to re-verify the TLP.

6. The method according to claim 5, characterized in that, The sequence number register maintained by the receiving end also includes an out-of-order flag field; the step of comparing the second MAC with the received first MAC to verify the TLP further includes: If the verification is successful within a preset number of adjustments during the re-verification of TLP, then an out-of-order flag is set in the out-of-order flag field. If the verification fails within the preset number of adjustments, an error will be reported.

7. The method according to claim 5, characterized in that, Different types of TLPs include at least publishing requests, non-publishing requests, and completion messages.

8. A transmitting device for implementing the method as described in any one of claims 1-7, characterized in that, include: At least three sequence number registers are used to maintain sequence numbers for TLPs of publish request, non-publish request, and completion message types, respectively.

9. A receiving device for implementing the method as described in any one of claims 1-7, characterized in that, include: At least three sequence number registers are used to maintain expected sequence numbers for TLPs of publish requests, non-publish requests, and completion message types, respectively. The sequence number registers include an out-of-order compensation value field, an out-of-order flag field, and an overflow flag field.

10. A computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the method as described in any one of claims 1-7.

Images