System for secure data transmission

Abstract

The invention discloses a system for secure data transmission. Systems, computer program products, and methods for secure data transmission are described. An example system includes a first endpoint device, an intermediate device, and a second endpoint device. A first endpoint device determines format requirements for a communication link between the first endpoint device and an intermediate device and a communication link between the intermediate device and a second endpoint device. Based on the format requirements, the first endpoint device configures a data packet for transmission such that when a data packet is received at the intermediate device, the data packet is reconfigured and routed to the second endpoint device. When the second endpoint device receives a data packet, it verifies the data packet to confirm that the data packet maintains its integrity throughout the transmission.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Application No. 63 / 542,449, filed on October 4, 2023, the contents of which are hereby incorporated by reference in their entirety. Technical Field

[0003] Example embodiments of the present invention are directed to systems for secure data transmission. Background Art

[0004] High-speed interconnects such as Peripheral Component Interconnect Express (PCIe) and Compute Express Link (CXL) have driven data-driven applications but have also raised security concerns. Integrity and Data Encryption (IDE) mechanisms in such high-speed interconnect structures ensure the security of data transmission by encrypting data packets. However, current limitations restrict flexible transmission modes, leading to complexity and hindering system performance. Challenges arise when data needs to switch between transmission modes, resulting in conversion errors of encrypted packets.

[0005] Applicants have recognized many deficiencies and problems associated with secure data transmission using high-speed interconnect technologies. Many of these recognized problems have been addressed by developing solutions included in the embodiments of the present disclosure, many examples of which are described in detail herein. Summary of the invention

[0006] Thus, systems, methods, and computer program products are provided for secure data transmission.

[0007] In one aspect, a system for secure data transmission is provided. The system includes: a first endpoint device, wherein the first endpoint device is configured to: configure a data packet for transmission based on characteristics of a first communication link, wherein the first communication link is configured to facilitate data transmission in a first transmission format; and transmit the data packet via the first communication link; an intermediate device, which is operably coupled to the first endpoint device via the first communication link, wherein the intermediate device is configured to: receive the data packet; reconfigure the data packet for transmission based on characteristics of a second communication link associated with the intermediate device, wherein the second communication link is configured to facilitate data transmission in a second transmission format; and transmit the data packet via the second communication link; and a second endpoint device, which is operably coupled to the intermediate device via the second communication link, wherein the second endpoint device is configured to: receive the data packet.

[0008] In some embodiments, the first endpoint device, when configuring the data packet for transmission, is further configured to: determine that the first communication link is configured to facilitate data transmission in the first transmission format, and the second communication link is configured to facilitate data transmission in the second transmission format; and in response to determining that the first communication link is configured to facilitate data transmission in the first transmission format, and the second communication link is configured to facilitate data transmission in the second transmission format: initially configure the data packet in the second transmission format; encrypt the data packet; convert the encrypted data packet from the second transmission format to the first transmission format; and transmit the encrypted data packet in the first transmission format via the first communication link.

[0009] In some embodiments, the first transmission format is a flit mode format and the second transmission format is a non-flit mode format.

[0010] In some embodiments, the first endpoint device is configured to encrypt the data packet using an integrity and data encryption (IDE) mechanism.

[0011] In some embodiments, the first endpoint device is also configured, when encrypting the data packet, to: generate a transmitted message authentication code (MAC) for the encrypted data packet based at least on a packet component associated with the data packet and an encryption key associated with the IDE mechanism; and embed the transmitted MAC into the encrypted data packet.

[0012] In some embodiments, the first endpoint device, when converting the encrypted data packet, is further configured to: convert the transmitted MAC embedded in the encrypted packet from the second transmission format to the first transmission format.

[0013] In some embodiments, the intermediate device is also configured, when reconfiguring the data packet for transmission, to: receive the encrypted data packet in the first transmission format from the first endpoint device; convert the encrypted data packet from the first transmission format to the second transmission format; and transmit the encrypted data packet in the second transmission format via the second communication link.

[0014] In some embodiments, the intermediate device, when converting the encrypted packet, is further configured to: convert the transmitted MAC embedded in the encrypted packet from the first transmission format to the second transmission format.

[0015] In some embodiments, the second endpoint device is further configured to: receive the encrypted data packet in the second transmission format from the intermediate device; generate a recalculated MAC for the received encrypted data packet based at least on the packet components associated with the data packet and an encryption key associated with the IDE mechanism; determine whether the recalculated MAC matches the transmitted MAC embedded in the encrypted data packet; and confirm the integrity of the data packet if the recalculated MAC matches the transmitted MAC embedded in the encrypted data packet.

[0016] In some embodiments, the first communication link and the second communication link are associated with a high-speed interconnect technology, and wherein the data packet is a transport layer packet (TLP).

[0017] In another aspect, a method for configuring a data packet is provided. The method includes: determining that a first communication link is configured to facilitate data transmission in a first transmission format and a second communication link is configured to facilitate data transmission in a second transmission format; and in response to determining that the first communication link is configured to facilitate data transmission in the first transmission format and the second communication link is configured to facilitate data transmission in the second transmission format: initially configuring a data packet in the second transmission format; encrypting the data packet; converting the encrypted data packet from the second transmission format to the first transmission format; and transmitting the encrypted data packet in the first transmission format via the first communication link.

[0018] In yet another aspect, a computer program product for configuring a data packet is provided. The computer program product includes a non-transitory computer-readable medium, the non-transitory computer-readable medium including instructions, which, when executed by a processor, cause a device to: determine that a first communication link is configured to facilitate data transmission in a first transmission format and a second communication link is configured to facilitate data transmission in a second transmission format; and in response to determining that the first communication link is configured to facilitate data transmission in the first transmission format and the second communication link is configured to facilitate data transmission in the second transmission format: initially configure a data packet in the second transmission format; encrypt the data packet; convert the encrypted data packet from the second transmission format to the first transmission format; and transmit the encrypted data packet in the first transmission format via the first communication link.

[0019] The above invention content is provided only for the purpose of summarizing some example embodiments to provide a basic understanding of some aspects of the present disclosure. Therefore, it should be understood that the above embodiments are merely examples and should not be interpreted as narrowing the scope or spirit of the present disclosure in any way. It should be understood that the scope of the present disclosure also covers many potential embodiments in addition to the embodiments summarized here, some of which will be further described below. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Having generally described certain example embodiments of the present disclosure above, reference will now be made to the accompanying drawings. The components shown in the drawings may or may not be present in certain embodiments described herein. Some embodiments may include fewer (or more) components than those shown in the drawings.

[0021] Figure 1 An example system environment for secure data transmission according to an embodiment of the present invention is shown;

[0022] Figure 2 shows an example endpoint device circuit for secure data transmission according to an embodiment of the present invention;

[0023] Figure 3 An example method for configuring data packets at an endpoint device for secure data transmission according to an embodiment of the present invention is shown;

[0024] Figure 4 An example method for reconfiguring data packets at an intermediate device for endpoint routing according to an embodiment of the present invention is shown; and

[0025] Figure 5 An example method for verifying the integrity of a data packet at an endpoint device according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0026] Overview

[0027] The development of high-speed interconnect technologies such as Peripheral Component Interconnect Express (PCIe) and Compute Express Link (CXL) has promoted the rapid expansion of data-driven applications in cloud computing, artificial intelligence, analytics, edge computing, etc. At the same time, this development has also brought security challenges, especially in terms of data integrity and confidentiality.

[0028] Integrity and Data Encryption (IDE) mechanisms have been developed to protect encrypted data transmission within these interconnect frameworks. The primary function of IDE is to encrypt data packets, specifically transaction layer packets (TLPs), to ensure that information remains secure and unaltered during transmission between different endpoint devices within a computing environment. IDE is used to maintain data integrity (ensuring that data is accurate and identical to its original form) and confidentiality (ensuring that sensitive information remains accessible only to authorized entities). IDE operates by applying cryptographic algorithms to data packets, thereby providing a layer of protection against unauthorized access and tampering.

[0029] Flit mode and non-flit mode are two different modes or formats for data packet transmission in high-speed interconnect technologies such as PCIe. In flit mode, data transmission is organized into smaller, flow-controlled units called flow control numbers or "flits". Flits are generally used for interconnects that require high efficiency and the ability to handle different data sizes and traffic conditions. Flit mode is characterized by being designed as a more fine-grained and flexible packet transmission process that can adapt to a dynamic range of data burst sizes. It is particularly suitable for environments with highly variable bandwidth requirements and can help optimize the utilization of interconnect capacity. On the other hand, non-flit mode operates without breaking packets into smaller units. It transmits larger, more static blocks of data, which can be more straightforward but less flexible than flit mode. Non-flit mode is generally used in scenarios where data traffic is predictable and consistent, allowing for simpler flow control mechanisms.

[0030] The current IDE specification requires data packets (especially TLPs) to maintain a uniform transfer mode - either all in flit mode or all in non-flit mode. Current systems require different segments or "islands" within the high-speed interconnect structure to operate exclusively in one transfer mode. This limitation inhibits system flexibility and increases the complexity of system architecture.

[0031] The transfer of data between two endpoints occurs when one endpoint device or component sends data to another endpoint device or component within a computing system. During this transfer, data may pass through intermediate devices (e.g., switches) that facilitate and direct the flow of data. In a conventional configuration, when an intermediate device encounters a data packet that needs to be changed from flit mode to non-flit mode or vice versa, it performs this conversion seamlessly for standard packets. However, for encrypted data packets (or IDE packets), intermediate devices are typically not configured to convert between transmission modes. If a switch detects an encrypted data packet that requires a mode conversion, it will generate an error message indicating that it cannot convert the encrypted data packet between flit mode and non-flit mode.

[0032] Embodiments of the present invention incorporate a novel approach to encrypted data packet transmission by modifying the behavior of a switch using IDE capability and control registers. The IDE capability register is an addressable memory location within a switch that indicates its ability to handle IDE packets. The IDE capability register holds specific values ​​that inform the logic of the intermediate device whether it can support conversion between flit mode and non-flit mode. By setting different bits in this register, embodiments of the present invention can configure the primary and secondary sides of the intermediate device to either flit mode or non-flit mode as required by the transmission requirements. On the other hand, the IDE control register directs the operation of the intermediate device regarding the translation of encrypted data packets. For type 1 functions associated with the intermediate device, different bit settings enable or disable the translation feature. When configured to enable translation, the intermediate device can be configured to convert encrypted data packets from non-flit mode to flit mode or vice versa, depending on the direction of the data flow and the specific requirements of the packet destination. By setting the IDE capability and control registers, the ports on the intermediate device can be informed how to handle encrypted data packets. When these registers are configured to enable translation, the intermediate device recognizes the encrypted data packets and can apply the necessary translation rules. This process ensures that the packet maintains its encryption status and integrity while being adapted to the appropriate transport mode.

[0033] In addition to modifying the behavior of intermediate devices, embodiments of the present invention also consider transmission strategies at the source for packet handling in a mixed mode environment. Specifically, in the process of preparing data packets for transmission, the source (e.g., a source endpoint device) can be configured to initially configure the data packets for non-flit mode data packet transmission. This initial configuration is guided by the settings in the IDE control register (offset 08h). For endpoint-related type 0 functions, the control register can indicate whether the conversion is generally enabled or selectively enabled based on communication requirements. After the data packets are configured for non-flit mode data packet transmission, the source can be configured to encrypt the data packets. As part of the IDE process, a message authentication code (MAC) can be used to ensure the security and integrity of the data packets. The MAC can be a unique signature (e.g., a cryptographic checksum) generated based on the content of the packet and the encryption key used. The MAC is then attached to the encrypted packet.

[0034] Subsequently, the source can be configured to convert the encrypted packets, now with MACs, from non-flit mode to flit mode. During the conversion process, the structure and format of the encrypted data packets can be changed to conform to the requirements of flit mode transmission. However, while the format of the packet and the MAC can be changed to accommodate flit mode, the intrinsic value and integrity of the MAC can be preserved. After converting the encrypted packets, the source can be configured to transmit the packets to the destination. In scenarios where selective stream conversion is enabled, as determined by the selective IDE stream control register, specific streams to be subjected to conversion can be specified to achieve greater control and flexibility in data transmission.

[0035] During transmission, an encrypted data packet with a MAC may arrive at an intermediate device. The intermediate device may convert the encrypted data packet from a flit mode to a non-flit mode. After the intermediate device converts the packet to a non-flit mode, it may forward the packet toward its intended destination. Upon arrival at the destination, the MAC may be used to verify the integrity of the packet. This verification may involve recalculating the MAC based on the contents of the received packet and comparing the recalculated MAC with the MAC received in the data packet. If the recalculated MAC aligns with the received MAC, the destination device may confirm that the packet maintained its integrity throughout the transmission process.

[0036] Embodiments of the present disclosure will be described more fully below with reference to the accompanying drawings, in which some, but not all, embodiments of the present disclosure are shown. In fact, the present disclosure can be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein; rather, these embodiments are provided so that the present disclosure satisfies applicable legal requirements. Therefore, it should be understood that each of the blocks in the block diagrams and flow charts can be implemented in the following forms: a computer program product; a complete hardware embodiment; a complete firmware embodiment; a combination of hardware, a computer program product, and / or firmware; and / or an apparatus, system, computing device, computing entity, and / or the like that implements instructions, operations, steps, and similar words that can be used interchangeably (e.g., executable instructions, instructions for execution, program code, and / or similar words) on a computer-readable storage medium for execution. For example, the retrieval, loading, and execution of the code can be performed sequentially, so that one instruction is retrieved, loaded, and executed at a time. In some exemplary embodiments, the retrieval, loading, and / or execution can be performed in parallel, so that multiple instructions are retrieved, loaded, and / or executed together. Therefore, such an embodiment can produce a specially configured machine that performs the steps or operations specified in the block diagrams and flow chart illustrations. Therefore, the block diagrams and flow chart illustrations support various combinations of embodiments for performing the specified instructions, operations or steps.

[0037] Where possible, any term expressed in the singular herein is meant to include the plural form, and vice versa, unless expressly stated otherwise. In addition, as used herein, the terms "a" and / or "an" shall mean "one or more", even though the phrase "one or more" is also used herein. In addition, when it is said herein that something is "based on" something else, it may also be based on one or more other things. In other words, as used herein, "based on" means "based at least in part on" or "based at least in part on", unless expressly stated otherwise. The same number always refers to the same element.

[0038] As used herein, "operably coupled" may mean that the components are electronically or optically coupled to each other and / or in electrical or optical communication. Furthermore, "operably coupled" may mean that the components may be integrally formed with each other, or may be formed separately and coupled together. Furthermore, "operably coupled" may mean that the components may be directly connected to each other, or may be connected to each other via one or more components (e.g., connectors) located between the components that are operably coupled together. Furthermore, "operably coupled" may mean that the components are removable from each other or that the components are permanently coupled together.

[0039] As used herein, "interconnect" may indicate that each component is linked directly or indirectly to every other component or switch in the network, thereby allowing seamless data transfer and communication between all components.

[0040] As used herein, "determining" may encompass various actions. For example, "determining" may include calculating, computing, processing, deriving, investigating, ascertaining, etc. In addition, "determining" may also include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory), etc. In addition, "determining" may include parsing, selecting, choosing, calculating, establishing, etc. Determining may also include ascertaining whether a parameter meets a predetermined standard, including whether a threshold has been reached, passed, exceeded, or satisfied, etc.

[0041] It should be understood that the word “exemplary” as used herein means “serving as an example, instance, or illustration.” Any implementation described herein as “exemplary” is not necessarily to be construed as advantageous over other implementations.

[0042] Furthermore, from this disclosure, it will be apparent to those of ordinary skill in the art that the terms "substantially" and "approximately" mean that the referenced element or the related description is accurate within an applicable engineering tolerance.

[0043] Example system environment

[0044] Figure 1 An example system environment 100 for secure data transmission according to an embodiment of the present invention is shown. In the context of the present invention, Figure 1As shown, the system environment 100 can be configured to facilitate secure data transmission through a high-speed interconnection framework or structure. Specifically, for the purpose of secure data communication, the system environment 100 can utilize a PCIe structure (serial computer expansion bus standard) to establish a network of devices (e.g., endpoint devices, intermediate devices, and / or similar devices as described in more detail herein). The architecture of the PCIe structure provides an extensible point-to-point topology that enables a direct, secure communication link to be established between endpoint devices, between intermediate devices, and / or between an endpoint device and an intermediate device. Therefore, in a specific embodiment, the present invention focuses on optimizing the secure transmission of data packets within the PCIe structure by utilizing the inherent architectural advantages of PCIe, thereby providing a powerful framework for secure data communication between endpoint devices within the system environment 100. Figure 1 Only one example of an embodiment of system environment 100 is shown, and it should be understood that in other embodiments, one or more of the systems, units and / or devices may be combined into a single system, unit or device, or may be composed of multiple systems, units or devices. In addition, it should be understood that reference to the PCIe structure is illustrative rather than prescriptive. The described system environment 100 need not be limited to the PCIe structure, and may adapt to alternative high-speed interconnect technologies. In this case, the configuration of the system environment 100 may be modified to meet the specific requirements of any selected high-speed interconnect technology.

[0045] like Figure 1 As shown, the system environment 100 may include multiple endpoint devices 102, 104, 106, 108, an intermediate device 110, and a root complex 105. The multiple endpoint devices 102, 104, 106, 108 may refer to devices that act as communication termination points within a PCIe structure. Therefore, the multiple endpoint devices 102, 104, 106, 108 may be peripheral devices connected to the system, such as network cards, graphics processing units (GPUs) network interface cards (NICs), storage controllers / adapters, field programmable gate arrays (FPGAs) accelerators, sound cards / audio interfaces, artificial intelligence (AI) / machine learning (ML) accelerators, etc. In certain embodiments, the multiple endpoint devices 102, 104, 106, 108 may not relay data from other devices; instead, they may generate or consume data. On the other hand, as Figure 1 As shown, the middleware 110 may refer to a switching device within a PCIe fabric that can route data between different points in the system environment 100, including routing data between multiple endpoint devices. Thus, the middleware 110 may manage the flow of information between the multiple endpoint devices 102, 104, 106, 108 and potentially other components within the system environment 100.

[0046] The root complex 105 may be the primary interface within the PCIe fabric for connecting peripheral devices (e.g., multiple endpoint devices 102, 104, 106, 108 and intermediate devices 110) to the PCIe fabric. The root complex may be configured to manage communications between external components (e.g., a host processor) and peripheral devices. The root complex may include root ports 101, 103 that allow the root complex 105 to interface with peripheral devices, manage configuration for discovering and configuring peripheral devices, and manage data paths for routing data between external components and peripheral devices.

[0047] A plurality of endpoint devices 102, 104, 106, 108, an intermediate device 110, and a root complex 105 may be operably coupled via a communication link. Each communication link may be configured to operate in at least two different modes: a flit-based mode and a non-flit mode. These modes define the format and management of data transmission over a PCIe link to meet different bandwidth, latency, and data integrity requirements. A flit mode communication link (e.g., a communication link 107) may be configured to optimize the efficiency and reliability of data transmission, particularly in environments requiring high bandwidth and low latency. In flit mode, data packets may be divided into smaller units called "flits" (flow control numbers). A flit may refer to the basic unit of data transmission in this mode, thereby enabling fine-grained flow control and error checking. This mode is particularly beneficial for applications that require reliable data transmission over long distances within a PCIe structure. The data format in the flit mode may be constructed around efficient processing of these smaller data units. Each flit may include payload data and header information including routing, flow control, and error detection codes.

[0048] On the other hand, a non-flit mode communication link (e.g., communication link 109) can be configured to transmit data packets as entire units, which makes this mode simpler but may be less efficient for certain types of data traffic. Non-flit mode may be suitable for environments where simplicity and compatibility with legacy systems take precedence over the optimized bandwidth and lower latency that can be achieved with flit mode. In non-flit mode, the data format may include larger complete packets that include payload, header, and trailer (for error checking) data, but without the segmentation and reassembly processes inherent to flit mode. This mode may be preferred in systems where data integrity can be adequately managed without the granularity provided by flits, or in systems where the overhead of managing flits does not justify the performance advantage.

[0049] A complex PCIe fabric environment, such as the depicted system environment 100, may include a mix of flit mode 107 and non-flit mode 109 communication links, where communication links connecting components with high throughput and low latency requirements may use flit mode, while connections to legacy or less critical components may use non-flit mode. Figure 1 As shown, endpoint device_A 102 and endpoint device_C 106 can be operably coupled to intermediate device 110 via flit mode communication link 107, respectively; endpoint device_D 108 can be operably coupled to intermediate device 110 via non-flit mode communication link 109; root port_B 103 can be operably coupled to intermediate device 110 via non-flit mode communication link 109; and root port_A 101 can be operably coupled to endpoint device_B 104 via non-flit mode communication link 109.

[0050] It should be understood that the structure of system environment 100 and its components, connections and relationships, and their functions are meant to be exemplary only and are not meant to limit the implementation of the disclosure described and / or claimed in this document. In one example, system environment 100 may include more, fewer, or different components. In another example, some or all of the parts of system environment 100 may be combined into a single part, or all of the parts of environment 100 may be divided into two or more different parts.

[0051] Example Endpoint Device Circuit

[0052] Figure 2 An example endpoint device circuit 102 for secure data transmission according to an embodiment of the present invention is shown. As described herein, multiple endpoint devices 102, 104, 106, 108 may embody the same or substantially similar structural configuration. Therefore, although the subsequent description focuses on the device circuit of endpoint device_A 102, it should be understood that other endpoint devices (e.g., endpoint device_B 104, endpoint device_C 106 and / or endpoint device_D 108) may have similar or substantially equivalent device circuits. The parallelism of structure and function between multiple endpoint devices 102, 104, 106, 108 means that, unless otherwise specified, the descriptions, illustrations, and technical details related to the device circuit of endpoint device_A 102 are equally applicable and representative of the other endpoint devices.

[0053] like Figure 2 As shown, endpoint device_A 102 may include a processor 112 , a memory 114 , input / output circuitry 116 , communication circuitry 118 , packet configuration circuitry 120 , and packet verification circuitry 122 .

[0054] Although the term "circuitry" used herein with respect to components 112-122 is described in some cases using functional language, it should be understood that a particular implementation necessarily includes the use of specific hardware configured to perform the functions associated with the corresponding circuits described herein. It should also be understood that some of these components 112-122 may include similar or common hardware. For example, both sets of circuits may utilize the same use of processors, network interfaces, storage media, etc. to perform their associated functions, so that each set of circuits does not require duplicate hardware. In this regard, it should be understood that some components described in connection with endpoint device_A 102 may be housed together, while other components are housed separately (e.g., a controller that communicates with endpoint device_A 102). Although the term "circuitry" should be broadly understood to include hardware, in some embodiments, the term "circuitry" may also include software for configuring hardware. For example, in some embodiments, a "circuitry" may include processing circuits, storage media, network interfaces, input / output devices, etc. In some embodiments, other elements of endpoint device_A 102 may provide or supplement the functionality of a particular circuit. For example, processor 112 may provide processing functionality, memory 114 may provide storage functionality, communication circuitry 118 may provide network interface functionality, and so on.

[0055] In some embodiments, the processor 112 (and / or a co-processor or auxiliary processor or any other processing circuitry otherwise associated with the processor) may communicate with the memory 114 via a bus to transfer information between components of, for example, the endpoint device_A 102. The memory 114 may be non-transitory and may include, for example, one or more volatile and / or non-volatile memories, or some combination thereof. In other words, for example, the memory 114 may be an electronic storage device (e.g., a non-transitory computer-readable storage medium). The memory 114 may be configured to store information, data, content, applications, instructions, etc. to enable the apparatus (e.g., the endpoint device_A 102) to perform various functions in accordance with example embodiments of the present disclosure.

[0056] Despite Figure 2102 is shown as a single memory, but the memory 114 may include multiple memory components. Multiple memory components may be embodied on a single computing device or distributed across multiple computing devices. In various embodiments, the memory 114 may include, for example, a hard disk, a random access memory, a cache memory, a flash memory, a compact disk read-only memory (CD-ROM), a digital versatile disk read-only memory (DVD-ROM), an optical disk, a circuit configured to store information, or some combination thereof. The memory 114 may be configured to store information, data, applications, instructions, etc., so that the endpoint device_A 102 can implement various functions according to the example embodiments discussed herein. For example, in at least some embodiments, the memory 114 may be configured to cache data for processing by the processor 112. In addition or alternatively, in at least some embodiments, the memory 114 may be configured to store program instructions for execution by the processor 112. The memory 114 may store information in the form of static and / or dynamic information. The stored information may be stored and / or used by the endpoint device_A 102 in the process of performing its functions.

[0057] The processor 112 may be embodied in a variety of different ways, and may, for example, include one or more processing devices configured to execute independently. In addition or alternatively, the processor 112 may include one or more processors configured in series via a bus to enable independent execution of instructions, pipelining, and / or multithreading. For example, the processor 112 may be embodied as a variety of devices, including one or more microprocessors with an attached digital signal processor, one or more processors without an attached digital signal processor, one or more coprocessors, one or more multi-core processors, one or more controllers, processing circuits, one or more computers, various other processing elements (including integrated circuits, such as, for example, application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs)), or some combination thereof. The use of the term "processing circuit" may be understood to include a single-core processor, a multi-core processor, multiple processors within a device, and / or a remote or "cloud" processor. Therefore, although Figure 2 102 is shown as a single processor, but in some embodiments, the processor 112 may include multiple processors. The multiple processors may be embodied on a single computing device, or may be distributed across multiple such devices that are collectively configured to function as the endpoint device_A 102. The multiple processors may be in operable communication with each other and may be collectively configured to perform one or more functions of the endpoint device_A 102 described herein.

[0058] In an example embodiment, the processor 112 may be configured to execute instructions stored in the memory 114 or otherwise accessible to the processor 112. Alternatively or additionally, the processor 112 may be configured to perform hard-coded functions. Therefore, whether configured by hardware or software methods, or by a combination thereof, the processor 112 may represent an entity (e.g., physically embodied in a circuit) that is capable of performing operations in accordance with embodiments of the present disclosure when configured accordingly. Alternatively, as another example, when the processor 112 is embodied as an executor of software instructions, these instructions may specifically configure the processor 112 to perform one or more algorithms and / or operations described herein when executing these instructions. For example, these instructions, when executed by the processor 112, may cause the endpoint device_A 102 to perform one or more of its functions described herein.

[0059] In some embodiments, endpoint device_A 102 may also include input / output circuitry 116, which in turn may communicate with processor 112 to provide audible, visual, mechanical, or other outputs, and / or, in some embodiments, receive indications of inputs from a user or other source. In this sense, input / output circuitry 116 may include means for performing analog-to-digital and / or digital-to-analog data conversions. Input / output circuitry 116 may include, for example, support for a display, a touch screen, a keyboard, a mouse, an image capture device (e.g., a camera), a microphone, and / or other input / output mechanisms. Input / output circuitry 116 may include a user interface, and may include a web user interface, a mobile application, a kiosk, and the like.

[0060] The processor 112 and / or the user interface circuit including the processor 112 may be configured to control one or more functions or one or more user interface elements of the display via computer program instructions (e.g., software and / or firmware) stored on a memory accessible to the processor 112 (e.g., memory 114, etc.). In some embodiments, various aspects of the input / output circuit 116 may be reduced compared to embodiments in which the endpoint device_A 102 may be implemented as an end-user machine or other type of device designed for complex user interaction. In some embodiments (as with other components discussed herein), the input / output circuit 116 may be eliminated from the endpoint device_A 102. The input / output circuit 116 may communicate with the memory 114, the communication circuit 118, and / or any other component, for example via a bus. Although more than one input / output circuit and / or other components may be included in the endpoint device_A 102, in order to avoid overly complicating the disclosure, Figure 2 Only one is shown (eg, along with other components discussed herein).

[0061] In some embodiments, the communication circuit 118 includes any device, such as a device or circuit embodied in hardware, software, firmware, or a combination of hardware, software, and / or firmware, which is configured to receive and / or send data from / to a network and / or any other device, circuit, or module associated therewith. In this regard, the communication circuit 118 may include, for example, a network interface for implementing communication with a wired or wireless communication network. For example, in some embodiments, the communication circuit 118 may be configured to receive and / or send any data that may be stored by the memory 114 using any protocol that can be used for communication between computing devices. For example, the communication circuit 118 may include one or more communication ports, network interface cards, antennas, transmitters, receivers, buses, switches, routers, modems, and supporting hardware and / or software, and / or firmware / software, or any other device suitable for implementing communication through a network. In addition or alternatively, in some embodiments, the communication circuit 118 may include a circuit for interacting with one or more antennas so as to transmit signals via one or more antennas or process the reception of signals received via one or more antennas. These signals may be transmitted by the endpoint device_A 102 using any of a number of wireless personal area network (PAN) technologies, such as v1.0 to v5.0, Bluetooth Low Energy (BLE), infrared wireless (e.g., IrDA), ultra-wideband (UWB), inductive wireless transmission, etc. In addition, it should be understood that these signals can be transmitted using Wi-Fi, near field communication (NFC), Worldwide Interoperability for Microwave Access (WiMAX), or other proximity-based communication protocols. The communication circuit 118 can additionally or alternatively communicate with the memory 114, the input / output circuit 116, and / or any other component of the endpoint device_A 102, such as via a bus. The communication circuit 118 of the endpoint device_A 102 can also be configured to receive information from various components associated therewith and send information to various components associated therewith.

[0062] In the case where the endpoint device_A 102 is the source of the data packet, the packet configuration circuit 120 can configure the operation mode or format of the data packet transmission, specifically, switching between the flit mode and the non-flit mode according to the requirements of the transmission parameters of the data packet transmission. In addition, the packet configuration circuit 120 can be configured to encrypt the data packet before transmission, which ensures the confidentiality and integrity of the data being transmitted. The encryption algorithm adopted can be dynamically selected based on the security requirements of the communication, and supports symmetric encryption methods and asymmetric encryption methods. In addition, the packet configuration circuit 120 can also be responsible for generating a cryptographic checksum or a digital signature (e.g., a message authentication code (MAC)) and attaching the cryptographic checksum or the digital signature (e.g., a message authentication code (MAC)) to the packet, thereby providing a mechanism for authentication and non-repudiation. Once configured, the packet configuration circuit 120 can interface with the processor 112 to start the transmission of the data packet.

[0063] In the case where endpoint device_A 102 is the destination of the data packet, the packet verification circuit 122 can ensure the authenticity and integrity of the received data packet. For example, upon receiving the data packet, the packet verification circuit 120 can first extract the MAC attached to the packet by the source endpoint device. The packet verification circuit 122 can then recalculate the MAC of the components of the received packet (e.g., header, payload (if any), and / or the like) using the same cryptographic algorithm and key as the source endpoint device. This process allows the recalculated MAC to be compared with the extracted MAC. The match between the two MAC values ​​confirms that the data packet has not been altered or tampered with during transmission, thereby verifying the integrity of the packet. In the event that the MAC values ​​do not match, the packet verification circuit 122 can mark the packet as compromised, which indicates a potential integrity or authenticity problem. Here, the packet verification circuit 122 can interface with the processor 112 to report the verification results and take appropriate measures based on the security policy, such as accepting, rejecting, or marking the data packet for further inspection.

[0064] In some embodiments, the endpoint device_A 102 may include hardware, software, firmware, and / or a combination of these components that are configured to support various aspects of the packet configuration circuit as described herein. It should be understood that in some embodiments, the packet configuration circuit 120 and / or the packet verification circuit 122 may be combined with another circuit of the endpoint device_A 102 (e.g., memory 114, processor 112, input / output circuit 116, and / or communication circuit 118) to perform one or more of such example actions. For example, in some embodiments, the packet configuration circuit 120 and / or the packet verification circuit 122 may utilize a processing circuit (e.g., processor 112, etc.) to form a self-contained subsystem to perform one or more corresponding operations thereof. In another example, and in some embodiments, some or all of the functions of the packet configuration circuit 120 and / or the packet verification circuit 122 may be performed by the processor 112. In this regard, some or all of the example processes and algorithms discussed herein may be performed by at least one processor 112, the packet configuration circuit 120, and / or the packet verification circuit 122. It should also be understood that in some embodiments, the packet configuration circuit 120 and / or the packet verification circuit 122 may include a separate processor, a specially configured FPGA or an ASIC to perform their corresponding functions.

[0065] Additionally or alternatively, in some embodiments, the packet configuration circuit 120 and / or the packet verification circuit 122 may use the memory 114 to store the collected information. For example, in some implementations, the packet configuration circuit 120 and / or the packet verification circuit 122 may include hardware, software, firmware, and / or a combination thereof that interacts with the memory 114 to send, retrieve, update, and / or store data.

[0066] Thus, a non-transitory computer-readable storage medium (e.g., which may be memory 114) may be configured to store firmware, one or more applications, and / or other software, including instructions and / or other computer-readable program code portions that may be executed to instruct the operation of endpoint device_A 102 to implement various operations, including the examples described herein. Thus, a series of computer-readable program code portions may be embodied in one or more computer program products and may be used with devices, endpoint device_A 102, databases, and / or other programmable devices to produce the machine-implemented processes discussed herein. It is also noted that all or part of the information discussed herein may be based on data received, generated, and / or maintained by one or more components of endpoint device_A 102. In some embodiments, one or more external systems (e.g., remote cloud computing and / or data storage systems) may also be utilized to provide at least some of the functionality discussed herein.

[0067] It should be recognized that, as described herein, the structure of endpoint device_A 102 represents only one embodiment among many potential configurations. This particular structure of endpoint device_A 102 is described as showing a specific arrangement and interaction of its components (including data processing units, network interfaces, and packet configuration circuits), which together contribute to its comprehensive network capabilities. However, this outlined configuration is not definitive or limiting. The structure of endpoint device_A 102 and its integrated components can be varied to adapt to different network paradigms, technological developments, and specific application requirements. Alternative embodiments of endpoint device_A 102 may employ different types of processors, such as advanced multi-core CPUs or dedicated GPUs, different network interfaces (such as SmartNICs or advanced wireless modules), and various methods for managing network events and communications. In addition, the scalability, data processing technology, and network integration methods of endpoint device_A 102 may vary greatly based on the target operating environment and functional elements. Therefore, although the present disclosure describes a potential structure of endpoint device_A 102, it should be understood that this represents only one example in the broader field of network-enabled devices. Thus, the scope of the present invention is not limited to this single form, but can be extended to various other forms, technologies and configurations.

[0068] Example method for configuring data packets at an endpoint device for secure data transmission

[0069] Figure 3 An example method for configuring a data packet at an endpoint device (eg, a first endpoint device) for secure data transmission according to an embodiment of the present invention is shown. Figure 1 and Figure 3 The data packet may be a transport layer packet (TLP), which is used to transmit data and commands between endpoint devices within a PCIe structure. As described herein, a complex PCIe structure environment (e.g., Figure 1 The system environment 100 shown may include communication links that facilitate the transmission of data in different formats. Therefore, the first endpoint device, when configuring a data packet for transmission, determines the characteristics of each communication link in the route of the data packet from a source (e.g., the first endpoint device) to a destination (e.g., the second endpoint device). This may include determining whether the communication link is configured for a first transmission format (e.g., a flit mode, which is preferred for high-speed, low-latency transmission) or a second transmission format (e.g., a non-flit mode, suitable for less urgent data transmission). Based on determining the characteristics of each communication link, the first endpoint device can configure the data packet for transmission accordingly.

[0070] For example, the first endpoint device may be endpoint device_A 102 (eg, Figure 1 ), and the second endpoint device may be endpoint device_B 104 (as shown Figure 1For a data packet sent by endpoint device_A 102 to reach endpoint device_B 104, it may pass through intermediate device 110 (such as Figure 1 ), via root port_B 103 (as shown Figure 1 ) to the root complex 105 (as shown Figure 1 ), and can be connected via root port_A 101 (as shown Figure 1 As shown) arrive at endpoint_B 104. Figure 1 As shown, routing of data packets from endpoint device_A 102 to endpoint device_B 104 may include communication links that facilitate transmission of data in both a flit mode and a non-flit mode. For example, the communication link between endpoint device_A 102 and intermediate device 110 may facilitate transmission of data in a first transmission format (e.g., flit mode), while the communication link between intermediate device 110 and root port_B 103 and the communication link between root port_A 101 and endpoint device_B 104 may facilitate transmission of data in a second transmission format (e.g., non-flit mode). Because the destination (the second endpoint device in this example (e.g., endpoint device_B 102)) may receive data packets via a communication link that facilitates transmission of data in the second transmission format, the source (the first endpoint device in this example (e.g., endpoint device_A 104)) may initially configure the data packets in the second transmission format. In particular embodiments, even if the second endpoint device receives the data packet via a communication link that facilitates transmission of data in the first communication format, the source (the first endpoint device) may initially configure the data packet in the second transmission format. Therefore, as Figure 3 As shown in block 302 of , the method may initially configure the data packet in a second transmission format.

[0071] After initially configuring the data packet in the second transmission format, the method may further encrypt the data packet, as shown in block 304, for example, by using an integrity and data encryption (IDE) mechanism. The IDE mechanism may be a comprehensive security protocol designed to protect data integrity and confidentiality during transmission. The mechanism may employ various encryption algorithms, such as the Advanced Encryption Standard (AES) and Rivest-Shamir-Adleman (RSA), to encode the data into a format that can only be read by the intended recipient. The encryption algorithm may be implemented using an encryption key that acts as a secure medium through which the sender locks the data and the receiver unlocks the data. The choice of an encryption algorithm and the corresponding key length may directly affect the security level of the transmitted data; for example, AES with a key size of 128, 192, or 256 bits may be used, each of which provides a progressively higher level of security.

[0072] In addition to encrypting data packets using the IDE mechanism, a message authentication code (MAC) (e.g., a transmitted MAC) can also be generated for the encrypted data packets. The MAC can be used as a verification tool, which ensures that the received data matches the sent data without any modification. In a specific embodiment, the MAC can be generated based on the packet components associated with the data packet (e.g., header, payload (if any), trailer, etc.) and the encryption key from the IDE mechanism. The MAC can then be attached to the encrypted data packet. By attaching the MAC to the encrypted data packet, the method can ensure that any tampering or modification of the data during transmission can be detected, thereby maintaining the authenticity and integrity of the data.

[0073] As shown in block 306, the method may convert the encrypted data packet from the second transmission format to the first transmission format. After initially configuring the encrypted data packet to the second transmission format, the method may convert the encrypted data packet from the second transmission format to the first transmission format to accommodate specific requirements of the communication link characteristics. Given that the communication link 107 between the first endpoint device (e.g., endpoint device_A 102) and the intermediate device (e.g., intermediate device 110) facilitates data transmission in the first transmission format (e.g., flit mode), the encrypted data packet may be converted accordingly before being transmitted to the intermediate device. In a specific embodiment, when converting the encrypted data packet, the transmitted MAC embedded in the encrypted data packet may also be converted to the first transmission format. Although the transmitted MAC is converted to the first transmission format, the inherent value of the MAC itself may remain unchanged; only its format is changed to meet the specifications required for transmission on the communication link 107 between the first endpoint device (e.g., endpoint device_A 102) and the intermediate device (e.g., intermediate device 110). In other embodiments, when converting the encrypted data packet, the transmitted MAC embedded in the encrypted data packet may remain unchanged.

[0074] As shown in block 308, the method may transmit the encrypted data packet in the first transmission format via the first communication link. Specifically, the encrypted data packet in the first transmission format is transmitted via the first communication link (e.g., Figure 1 The communication link 107) is transmitted to the intermediate device.

[0075] In some embodiments, a first endpoint device may configure a data packet as described herein regardless of the specific characteristics of a communication link in the data packet's route from the first endpoint device to the second endpoint device. In the event that the communication channel between the first endpoint device and the second endpoint device exclusively supports non-flit mode transmissions (e.g., the second transmission format), the first endpoint device may still configure the data packet to be transmitted in flit mode (e.g., the first transmission format). In this case, the transmitted data packet continues to traverse the communication link. However, certain advantages inherent to flit mode (e.g., potentially higher efficiency and adaptability to variable bandwidth) may not be fully realized.

[0076] Example method for reconfiguring data packets at an intermediate device for endpoint routing

[0077] Figure 4 An example method for reconfiguring data packets at an intermediate device for endpoint routing according to an embodiment of the present invention is shown. As shown in block 402, the method may start from a first endpoint device (e.g., Figure 1 The endpoint device_A102 in the middle receives the encrypted data packet in the first transmission format. As described herein, the middle device (e.g., Figure 1 The intermediate device 110 in the system may be a switch configured to manage and facilitate data flows between various components (eg, devices) of the system. Thus, the intermediate device may act as a router that directs data packet flows between endpoint devices.

[0078] As shown in block 404, the method can convert the encrypted data packet from a first transmission format to a second transmission format. As described herein, in conventional implementations, an intermediate device (e.g., a switch) is typically not equipped to convert between different transmission formats of data packets encrypted using an IDE mechanism. If a conventional intermediate device encounters an encrypted data packet that needs to be transformed from one transmission mode to another transmission mode, the conventional intermediate device will generate an error message, which signals that it cannot perform the conversion between the flit mode and the non-flit mode of the encrypted data packet (according to the previous example). In order to overcome these limitations, an intermediate device (e.g., intermediate device 110) according to an embodiment of the present invention can be configured to automatically process the conversion of the encrypted data packet from a first transmission format to a second transmission format (or vice versa, as indicated by the data path).

[0079] Specifically, the IDE capability and control registers of the intermediate device can be configured so that the intermediate device can determine the need for format conversion (e.g., converting an encrypted data packet from a first transmission format to a second transmission format) and automatically convert the encrypted data packet. The IDE capability register can be a dedicated memory location within a PCIe device (e.g., an intermediate device or an endpoint device) that indicates the device's support for processing encrypted data packets. The IDE capability register can store information that conveys the device's ability to process encrypted data according to the IDE protocol. This may include the device's support for encryption algorithms, the device's key management, and the device's ability to convert encrypted data packets between different transmission formats when necessary. By setting different bits in the register, the primary (e.g., receiving) side and the secondary (e.g., transmitting) side of the intermediate device can be configured to operate in the first transmission format or the second transmission format as required by the transmission requirements.

[0080] On the other hand, the IDE control registers can be used to manage the actual operation of the encryption and decryption process, including by allowing the system or device to enable or disable encryption, select encryption keys, manage key exchanges, and set operating parameters for how encrypted data should be processed. In other words, the control registers actively manage the encryption lifecycle and instruct the device how to process encrypted data. Functions within the middleware can be classified into two main types: type 0 and type 1. Type 1 functions can be applied to middleware that manages data flows between different components of the PCIe structure. The configuration space of the type 1 function may include registers that can be programmed to control various operating parameters, including the ability to convert data transmission formats, such as from non-flit mode to flit mode, and vice versa. By setting the IDE capability and control registers, the ports on the middleware can be told how to handle encrypted data packets. When these registers are configured to enable conversion, the middleware can identify encrypted data packets, determine that format conversion is required, and apply the necessary conversion rules.

[0081] As shown in block 406, the method may transmit the encrypted data packet in the second transmission format via the second communication link. Specifically, the encrypted data packet in the second transmission format is transmitted to the root complex via the second communication link, specifically Figure 1 root_port B 103 as shown.

[0082] Example method for verifying the integrity of a data packet at an endpoint device

[0083] Figure 5 An example method for verifying the integrity of a data packet at an endpoint device according to an embodiment of the present invention is shown. As shown in block 502, the method may be performed from an intermediate device (e.g., Figure 1The intermediate device 110 in the second transmission format receives the encrypted data packet in the second transmission format. When the encrypted data packet arrives at the destination (e.g., the second endpoint device), the destination endpoint device can be configured to initiate a process of decrypting and verifying the integrity of the data in the data packet. Figure 1 In the example shown, a second endpoint device (e.g., endpoint device_B 104) may receive an encrypted data packet from root complex 105 via root complex port_A 101. The transmission format of the communication link 109 between intermediate device 110 and root port_B 103 may be the same as the transmission format (the second transmission format in this example) of the communication link 109 between root port_A 101 and endpoint device_B 104. Therefore, the encrypted data packet may not require additional conversion. After successful decryption, the second endpoint device may then check the MAC attached to the transmission of the encrypted data packet before transmission.

[0084] The method may generate a MAC (e.g., a recalculated MAC) for the received encrypted data packet based at least on packet components associated with the data packet and an encryption key associated with the IDE mechanism, as shown in block 504. To check the transmitted MAC, the second endpoint device may calculate its own MAC (e.g., a recalculated MAC) based on the received data and the shared secret encryption key used in the encryption process.

[0085] The method may determine whether the recalculated MAC matches the transmitted MAC embedded in the encrypted data packet, as shown in block 508. After generating the recalculated MAC, the second endpoint device may compare the recalculated MAC to the transmitted MAC embedded in the encrypted data packet. If the two MACs match, the second endpoint device may confirm that the integrity of the data has been preserved and the packet is authenticated as authentic and has not been tampered with.

[0086] The method may verify the integrity of the data packet if the recalculated MAC matches the transmitted MAC embedded in the encrypted data packet, as shown in block 510. After verifying the integrity of the data packet, the second endpoint device may send an acknowledgement to the source (e.g., the first endpoint device) indicating that the data packet has been successfully received and verified.

[0087] Those skilled in the art to which these embodiments belong will appreciate many modifications and other embodiments of the disclosure set forth herein, having benefited from the foregoing description and the teachings presented in the associated drawings. Although these figures only illustrate certain components of the methods and systems described herein, it is to be understood that various other components may also be a part of the disclosure herein. In addition, in some cases, the above method may include fewer steps, while in other cases, the method may include additional steps. In some cases, the steps of the above method and the modifications to the steps may be performed in any order and in any combination.

[0088] Therefore, it is to be understood that the disclosure is not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims.Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

1. A system for secure data transmission, the system comprising: A first endpoint device, wherein the first endpoint device is configured to: configuring a data packet for transmission based on characteristics of a first communications link, wherein the first communications link is configured to facilitate data transmission in a first transmission format; as well as transmitting the data packet via the first communication link; an intermediate device operably coupled to the first endpoint device via the first communication link, wherein the intermediate device is configured to: receiving the data packet; reconfiguring the data packet for transmission based on characteristics of a second communication link associated with the intermediate device, wherein the second communication link is configured to facilitate data transmission in a second transmission format; as well as transmitting the data packet via the second communication link; as well as a second endpoint device operably coupled to the intermediate device via the second communication link, wherein the second endpoint device is configured to: The data packet is received.

2. The system of claim 1, wherein the first endpoint device, when configuring the data packet for transmission, is further configured to: determining that the first communications link is configured to facilitate data transmission in the first transmission format and the second communications link is configured to facilitate data transmission in the second transmission format; as well as In response to determining that the first communication link is configured to facilitate data transmission in the first transmission format and the second communication link is configured to facilitate data transmission in the second transmission format, initially configuring the data packet in the second transmission format; encrypting the data packet; converting the encrypted data packets from the second transmission format to the first transmission format; as well as The encrypted data packets are transmitted in the first transmission format via the first communication link.

3. The system of claim 2, wherein the first transmission format is a flit mode format and the second transmission format is a non-flit mode format.

4. The system of claim 2, wherein the first endpoint device is configured to encrypt the data packet using an integrity and data encryption (IDE) mechanism.

5. The system of claim 4, wherein the first endpoint device, when encrypting the data packet, is further configured to: generating a transmitted message authentication code MAC for the encrypted data packet based at least on a packet component associated with the data packet and an encryption key associated with the IDE mechanism; and The transmitted MAC is embedded in the encrypted data packet.

6. The system of claim 5, wherein the first endpoint device, when translating the encrypted data packet, is further configured to: The transmitted MAC embedded in the encrypted data packet is converted from the second transmission format to the first transmission format.

7. The system of claim 5, wherein the intermediate device, when reconfiguring the data packet for transmission, is further configured to: receiving the encrypted data packets in the first transmission format from the first endpoint device; converting the encrypted data packets from the first transmission format to the second transmission format; and The encrypted data packets are transmitted in the second transmission format via the second communication link.

8. The system of claim 7, wherein the intermediate device, when converting the encrypted data packet, is further configured to: The transmitted MAC embedded in the encrypted data packet is converted from the first transmission format to the second transmission format.

9. The system of claim 7, wherein the second endpoint device is further configured to: receiving the encrypted data packets in the second transmission format from the intermediate device; generating a recomputed MAC for the received encrypted data packet based at least on the packet components associated with the data packet and the encryption key associated with the IDE mechanism; determining whether the recomputed MAC matches the transmitted MAC embedded in the encrypted data packet; as well as In the event that the recomputed MAC matches the transmitted MAC embedded in the encrypted data packet, the integrity of the data packet is confirmed.

10. The system of claim 1, wherein the first communication link and the second communication link are associated with a high-speed interconnect technology, and wherein the data packets are transport layer packets (TLPs).

11. A method for configuring a data packet, the method comprising: determining that the first communication link is configured to facilitate data transmission in a first transmission format and the second communication link is configured to facilitate data transmission in a second transmission format; as well as In response to determining that the first communication link is configured to facilitate data transmission in the first transmission format and the second communication link is configured to facilitate data transmission in the second transmission format, initially configuring a data packet in said second transmission format; encrypting the data packet; converting the encrypted data packets from the second transmission format to the first transmission format; as well as The encrypted data packets are transmitted in the first transmission format via the first communication link.

12. The method of claim 11, wherein the first transmission format is a flit mode format and the second transmission format is a non-flit mode format.

13. The method according to claim 11, wherein the method further comprises: The data packets are encrypted using integrity and data encryption IDE mechanism.

14. The method of claim 13, wherein encrypting the data packet further comprises: generating a transmitted message authentication code MAC for the encrypted data packet based at least on a packet component associated with the data packet and an encryption key associated with the IDE mechanism; as well as The transmitted MAC is embedded in the encrypted data packet.

15. The method of claim 14, wherein converting the encrypted data packet further comprises: The transmitted MAC embedded in the encrypted data packet is converted from the second transmission format to the first transmission format.

16. A computer program product for configuring a data packet, the computer program product comprising a non-transitory computer readable medium, the non-transitory computer readable medium comprising instructions which, when executed by a processor, cause a device to: determining that the first communication link is configured to facilitate data transmission in a first transmission format and the second communication link is configured to facilitate data transmission in a second transmission format; as well as In response to determining that the first communication link is configured to facilitate data transmission in the first transmission format and the second communication link is configured to facilitate data transmission in the second transmission format, initially configuring a data packet in said second transmission format; encrypting the data packet; converting the encrypted data packets from the second transmission format to the first transmission format; as well as The encrypted data packets are transmitted in the first transmission format via the first communication link.

17. The computer program product of claim 16, wherein the first transmission format is a flit mode format and the second transmission format is a non-flit mode format.

18. The computer program product of claim 16, wherein the instructions for encrypting the data packet, when executed by a processor, cause the device to encrypt the data packet using an integrity and data encryption (IDE) mechanism.

19. The computer program product of claim 18, wherein the instructions for encrypting the data packet, when executed by a processor, cause the device to: generating a transmitted message authentication code MAC for the encrypted data packet based at least on a packet component associated with the data packet and an encryption key associated with the IDE mechanism; and The transmitted MAC is embedded in the encrypted data packet.

20. The computer program product of claim 19, wherein the instructions for converting the encrypted data packet, when executed by a processor, cause the device to: The transmitted MAC embedded in the encrypted data packet is converted from the second transmission format to the first transmission format.

Images