System, method and device for encrypted data transmission

Abstract

Disclosed are systems, methods, and devices for encrypting data transmission. Specifically, a network interface controller includes processing circuitry configured to pair with a local root of trust of a host device connected to the network interface controller and provide a key to an encryption device of the host device, enabling the encryption device to use the key to encrypt data of one or more host device applications. The encrypted data is stored in a host device memory. The processing circuitry is configured to share the key with a remote endpoint and forward the encrypted data from the host device memory to the remote endpoint.

Description

Technical Field

[0001] The present disclosure generally relates to systems, devices, and methods for encrypting data transmissions. Background Art

[0002] Modern data centers use a variety of devices and methods for high-speed data exchange, which are vulnerable to malicious attacks, especially when the exchanged data is not encrypted. Summary of the Invention

[0003] In an illustrative embodiment, a network interface controller includes processing circuitry configured to pair with a local root of trust of a host device connected to the network interface controller and provide a key to an encryption device of the host device, enabling the encryption device to use the key to encrypt data of one or more host device applications. The encrypted data is stored in host device memory. The processing circuitry is configured to share the key with a remote endpoint and forward the encrypted data from the host device memory to the remote endpoint. Notably, the processing circuitry is inaccessible to host device application software, and therefore the key is not disclosed to one or more host device applications using the encryption device.

[0004] In an illustrative embodiment, a method includes generating, by a network device connected to a host device, a key and an associated key identifier, establishing, by the network device, a single key domain by sharing the key and the associated key identifier with at least one other network device over a communications network, and performing a remote direct memory access (RDMA) operation within the single key domain to send data encrypted with the key to the at least one other network device over the communications network.

[0005] In an illustrative embodiment, a system includes a first host device and a first network device coupled to the first host device. The first network device implements remote direct memory access (RDMA) operations to exchange encrypted data with a second host device over a communication network. The encrypted data is encrypted using a single key.

[0006] Additional features and advantages are described herein, and will be apparent from the following description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The present disclosure is described in conjunction with the accompanying drawings, which are not necessarily drawn to scale:

[0008] Figure 1 A system according to at least one example embodiment is shown;

[0009] Figure 2 A system according to at least one example embodiment is shown;

[0010] Figure 3A flowchart illustrating a method according to at least one example embodiment is shown;

[0011] Figure 4 a flowchart illustrating a method according to at least one example embodiment; and

[0012] Figure 5 According to at least one example embodiment, Figure 1 and Figure 2 part of the system. DETAILED DESCRIPTION

[0013] The following description provides only examples and is not intended to limit the scope, applicability, or configuration of the claims. Instead, the following description will provide those skilled in the art with an effective description for implementing the described embodiments. It should be understood that various changes may be made to the function and arrangement of elements without departing from the spirit and scope of the appended claims.

[0014] As will be appreciated from the following description, and for reasons of computational efficiency, the components of the system may be arranged at any suitable location within a distributed network of components without affecting the operation of the system.

[0015] Furthermore, it should be understood that the various links connecting the elements may be wired, traced, or wireless links, or any suitable combination thereof, or any other suitable known or later developed element capable of providing data to and / or communicating data with the connected elements. For example, the transmission medium used as the link may be any suitable electrical signal carrier, including coaxial cable, copper wire and optical fiber, electrical traces on a PCB, etc.

[0016] As used herein, the phrases "at least one," "one or more," "or," and "and / or" are open-ended expressions that operate as both conjunctions and transitions. For example, each of the expressions "at least one of A, B, and C," "at least one of A, B, or C," "one or more of A, B, and C," "one or more of A, B, or C," "A, B and / or C," and "A, B, or C" refers to A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together.

[0017] As used herein, the terms "determine," "calculate," and "compute," and variations thereof, are used interchangeably and include any suitable type of method, process, operation, or technique.

[0018] Various aspects of the disclosure will be described with reference to the figures, which may be schematic illustrations of idealized configurations.

[0019] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present disclosure belongs. It will be further understood that terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant art and the present disclosure.

[0020] As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that when used in this specification, the terms "include," "comprising," "containing," "involving," "covering," and / or "covering" specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. The term "and / or" includes any and all combinations of one or more of the associated listed items.

[0021] The inventive concept involves extensions to the intelligent network interface controller (NIC) architecture that enable the exchange of encrypted in-memory buffers between endpoints via remote direct memory access (RDMA) without decrypting the data during the actual transfer. The approach aims to extend the concept of in-use data security for central processing units (CPUs), where data is not stored in clear form (e.g., unencrypted) in main system memory, but is encrypted by the CPU during store operations and decrypted during load (or read) operations, so that the contents of main system memory are always encrypted. The inventive concept encompasses at least the following subsystem extensions: the intelligent NIC implements the concept of a "distributed root of trust" that extends the local root of trust of devices attached to the NIC and allows authenticated machines to share keys across an isolated / hardened NIC-based CPU complex; integrates details for key exchange based on quantum key distribution (QKD); enables the intelligent NIC to interact with a trusted root key management service on the server and negotiate keys with local applications, where the key or keys are then used to exchange encrypted buffers with remote counterparts via RDMA; and introduces host isolation support for the NIC for transmitting key synchronization messages between endpoints as part of the RDMA tunnel establishment sequence.

[0022] The Meltdown and Spectre vulnerabilities, introduced in 2018, rocked the cloud computing industry. In these attacks, attackers exploit CPU side channels, combining speculative execution features with cache hits on modern processors, to allow legitimate applications to dump the entire operating system (OS) kernel's memory footprint. The initial response to these attacks was to disable speculative execution on processors, which significantly reduced CPU performance, and at the software level, the OS kernel was patched to load itself into an arbitrary location at boot time instead of a static one, making interpreting memory dumps difficult, but not impossible.

[0023] However, these mitigations do not address the core issue: data in use (i.e., data stored in main system memory and the caches the CPU operates on) is stored in its unencrypted form in main system memory. Even encrypted disk block caches can be manipulated by the CPU without encryption, exposing significant vulnerabilities. For this reason, CPU vendors have released or are about to release CPUs with in-memory encryption capabilities. The basic function of encrypted memory support is that the CPU (or memory controller) encrypts data when it is stored in memory and decrypts it when the CPU loads it back. Therefore, data stored in memory (beyond a minimum consistency point) is always encrypted. CPUs with encrypted memory support have different operating modes, which can be divided into two main categories: transparent full-memory encryption (everything in memory is encrypted with the same key—referred to as secure memory encryption), and more sophisticated schemes that allow each virtual machine or container (or more specifically, each process) to use a custom key for in-use memory. Because memory contents are always encrypted, illicit memory dumps via side channels have the additional challenge of breaking symmetric key encryption (such as AES) to read the data, which is currently difficult to solve. Although CPU memory encryption engines strive to be more efficient, these encryption engines introduce some latency and consume a lot of power.

[0024] In CPU encrypted memory support, the encryption engine operates on cache line sized blocks and participates in the memory access data path on a per cache line update transaction basis. Dedicated reserved bits of the virtual address of each transaction define whether the transaction payload should be encrypted or decrypted (depending on whether the operation is a store or load operation). In this case, the DMA engine of a peripheral device (such as a smart NIC) can be programmed by the driver to read or write application buffers with encryption support turned on or off. If encryption support is turned off, the peripheral device reads the encrypted application buffer and does not have the key to decode it.

[0025] The inventive concept involves scenarios where two or more remote servers have CPU memory encryption enabled, creating secure memory enclaves that allow for the use of different keys for each application or a single key for multiple applications, and for applications running between them that perform RDMA transfers. The inventive concept creates an isolated, secure single encryption key domain that integrates the security of data in use at each server endpoint with the data-in-motion introduced by RDMA between servers, for two or more applications on different servers that want to exchange data.

[0026] Benefits of using a single key domain between applications that utilize secure memory enclaves that also need to exchange data via RDMA include: the NIC will have encrypted RDMA payloads for free and will not need to utilize additional encryption support, thus consuming less power while still transmitting encrypted data; CPU-based encryption is not in the critical path of the transmission and sometimes occurs early, which enables RDMA to use a low-latency data path that does not go through an encryption offload accelerator while still carrying a symmetrically encrypted payload; payload data sent to the NIC remains encrypted, which further prevents tampering attempts on the Peripheral Component Interconnect Express (PCIe) bus or inside the NIC while the data is being transmitted; and even in cases where the NIC needs to encrypt packets for security reasons (e.g., more frequent key updates, stronger ciphers, encryption of layer 3 and layer 2 headers), the described approach is still beneficial because it eliminates the need for encryption / decryption of buffers at the processor level since the buffers are transmitted encrypted, which contributes to low latency and reduced power consumption.

[0027] In some cases, there are multiple protection domains within a single CPU, and the NIC is the only entity that has the authority to read / write data from all domains to protect that protection domain. This allows the inventive concept to be applied to situations where the encryption authority is a guest virtual machine (VM) and the NIC serves multiple guest VMs.

[0028] In general, the inventive concepts relate to assigning a root of trust to a programmable system on chip (SoC) of a NIC and integrating the NIC root of trust with a local server root of trust and CPU firmware to form a distributed root of trust (e.g., certain root of trust functions are performed by the server's local root of trust, while certain root of trust functions are performed by the root of trust on the NIC). In this case, the NIC becomes an isolated key distributor that securely provides keys to applications running on the host. The NIC can also provide isolated key distribution for several different clients (e.g., VMs) on the same host, while providing security domains for data in use and data in motion using a single encryption key. The inventive concepts also relate to a startup sequence for a security domain for data in use and data in motion for applications running on a system with encrypted memory support and performing RDMA transfers, as well as the integration of quantum key distribution (QKD) with the above-mentioned key distribution scheme.

[0029] Approaches using a single key field between data-in-use and data-in-motion have not been considered, as this approach is primarily applicable to RDMA or custom Data Plane Development Kit (DPDK) solutions that do not require the NIC to read any data on the network buffer to continue packet forwarding, as the data comes from the encrypted main system memory.

[0030] The inventive concept proposes a distributed root of trust for secret key management, characterized by a suitably integrated endpoint on each server host. The distributed root of trust support on each server is provided by a NIC at each server that is hardened and isolated from user applications. Each NIC root of trust can then provide encryption keys to the local server via an isolated channel used by the encrypted memory support of the enabled hardware (e.g., CPU / memory controller). The host processor firmware handles the integration of the trust root provided by the NIC with the local encrypted memory root of trust to form a distributed root of trust. The system can be utilized by a hypervisor or application loader running on each server with hypervisor privileges and handles the synchronization steps between two or more servers so that all applications wishing to establish an RDMA channel can use the same encryption key. Once coordination is complete, the hypervisor / loader on each server forks the application binary (e.g., virtual machine) to set the same key for the local secure memory enclave.

[0031] Example embodiments encompass at least: 1) a distributed root of trust NIC-assisted concept; and 2) forming a single key domain between one or more applications running on different machines and exchanging data using RDMA. Figure 1 and Figure 2 Depicts an example deployment with a two-server setup.

[0032] Some NICs feature an entire processor complex that, in selected configurations, can be completely isolated from the attached host device and controlled from the infrastructure provider through a dedicated network port. In this case, even if, for example, a data center infrastructure provider provides bare metal server access to a third party, the provider can still fully control network-facing traffic by leveraging the CPU complex on the NIC because the CPU complex is completely isolated from the host device software. Example embodiments build on the concept of an isolated, infrastructure provider-controlled CPU complex on the NIC to introduce a distributed root of trust service that allows keys to be securely agreed upon and shared between remote machines through a local root of trust support for each remote machine.

[0033] A local root of trust on a computing system (e.g., Advanced RISC Machine (ARM) Trusted Boot) is a hardware-assisted entity that allows running system software to protect the identity of the platform on which the software is running. This prevents attackers from taking control of the system at a very low level, for example, by preventing the launch of a malicious operating system kernel or by preventing host emulation to trick software into running in an attacker-controlled execution environment (enclave). With the advent of hardware memory encryption, the root of trust role has expanded to provide keys over an out-of-band channel to the encryptor / decryptor hardware that performs cryptographic operations in a controlled manner. Furthermore, secure interfaces exist with the operating system and hypervisor to control which keys are used for which secure execution environments (e.g., VMs). In most cases, the local root of trust is a CPU-based system that is physically isolated from the network and controlled by server firmware (e.g., the Basic Input / Output System (BIOS)), which also provides secure boot services. Consequently, software running on the system is forced to interact with the server firmware to access very specific, well-defined root of trust services.

[0034] The inventive concept relates to a method for adding key exchange functionality to a local root of trust by offloading the network portion of the task to a trusted root of trust service running on a NIC (e.g., the NIC's CPU complex). Each time a NIC is attached to a system's PCI bus or other peripheral interconnect infrastructure (e.g., a server), a system administrator can perform a pairing process between the extended root of trust service running on the NIC's CPU complex and the system's or server's local root of trust. The pairing process can include generating a combined root certificate that uniquely defines a specific server platform instance with the specific instance of the attached NIC. Thereafter, server interconnect access to the NIC CPU complex is physically restricted to circuitry controlled only by the server's local root of trust and / or server firmware. The NIC CPU complex runs a process that acts as part of the root of trust firmware and provides services for secure key exchange with remote counterparts (e.g., other NICs) by leveraging the NIC's network access facilities. The NIC-based distributed root of trust endpoint can then form secure connections with other root of trust endpoints within or outside the data center to exchange keys. The key exchange can be performed using any secure tunneling method, such as VPN and MACsec. At least one example embodiment performs key exchange via a quantum key distribution system (QKD).In addition, a NIC-based distributed root of trust facilitates secure notification (e.g., to a hypervisor) of key exchange completion to form a single key domain.

[0035] A distributed root of trust according to an example embodiment may implement the following operations for key exchange: 1) an administrator has configured a centralized service like DNS or has a hard-coded list of server identifiers available to a root of trust service extension that runs on the NIC to identify one or more remote endpoints that wish to participate in a single key domain, 2) a hypervisor establishes an isolated channel with local server firmware that is dedicated, secure, and cannot be overwritten; 3) the local root of trust receives a request from the hypervisor over the isolated channel via a firmware callback to establish a single key domain with one or more remote endpoints; 4) the local root of trust authenticates the request and relays the request over the isolated channel to a NIC-based root of trust extension (e.g., the NIC root of trust service generates a key using a backend-generated key identifier keyID (e.g., a universally unique identifier) ) pair, and then securely exchange keys with one or more remote endpoints. After key sharing is completed, the key identifier keyID will be returned to the local server firmware (e.g., local root of trust) and from there to the hypervisor for future reference; 5) When the keyID is returned, the hypervisor knows that the key exchange has been performed and can make the key available to the encrypted memory engine of the remote endpoint upon request; 6) During the launch of the application, the hypervisor passes the keyID as a parameter, so the hypervisor's virtual address space can be associated with the key pointed to by the keyID (by using the keyID, the key actually used for data encryption in memory is never leaked, which is consistent with the way encrypted memory operates), and when the keyID is first requested to be installed, the keyID-key pair is consumed and cannot be used again.

[0036] The secure exchange of keyIDs can be the responsibility of the hypervisor. However, there are some inherent security implications if such a communication channel is compromised. First, an eavesdropped keyID cannot be used to decrypt data, as the keyID is simply a reference to the actual key and is not revealed to any application. Furthermore, since the system deletes the key-keyID pair after it has been explicitly requested once, a side channel cannot be established. Therefore, the key can be consumed by both the actual application launch and the side-channel application, making eavesdropping impossible.

[0037] Regarding the actual key exchange, the system can support existing best practices, but in addition, it can be based on quantum key distribution (QKD). In the case of QKD, the key-keyID pair approach is compatible with existing QKD equipment. Therefore, the KeyID exchange is integrated into the described trust flow root in the same spirit, while the key exchange is performed from the QKD quantum channel, making the entire key exchange process quantum secure.

[0038] As described above and below, a distributed root of trust according to example embodiments enables the exchange of keys between remote machines in a coordinated manner. Given that RDMA communications are integrated into the application's virtual address space to completely bypass the CPU, and given that all network plumbing occurs out-of-band, the NIC does not have to read RDMA buffer contents for forwarding operations, so there is a unique opportunity to move encrypted memory content around without actually decrypting the content for network transmission. To this end, endpoints exchanging encrypted memory content over RDMA should use the same keys. Distributed root of trust support according to example embodiments provides this functionality and includes the integration of an RDMA initialization sequence with the distributed root of trust functionality for performing RDMA between encrypted memory systems.

[0039] The RDMA initialization sequence can include the following operations. First, the RDMA coordination software is notified that a virtual machine (VM) or container or a specific process (in the case of high-performance computing (HPC)) will be launched on a specific server with encrypted memory turned on and will also perform RDMA. The coordination software then notifies the hypervisor on each machine that, in addition to the default details required to launch the application, encrypted memory support will be activated and the machine will participate in a single key domain. A specific hypervisor is designated as the key domain master to initiate the distributed root of trust key exchange. After being notified of the established single key domain (i.e., the agreed-upon keys have been exchanged and are available locally on each endpoint), the required application instances can be launched on each server. Given that the keys are the same, the encrypted contents of the virtual address space originating from one application endpoint should be readable by any remote counterpart without any decryption during network transmission. After proper startup as described above, standard RDMA methods can be used for both channel setup and data exchange.

[0040] The above initialization method is not limited to any specific orchestrator or hypervisor or virtualization technology. The steps of establishing a single key domain for the encrypted memory system using a NIC-assisted distributed root of trust can be accomplished through a custom boot process in any suitable application scenario. A hard requirement is that the NIC should not rely on packet information that has been added by applications that use encrypted memory for forwarding operations (for example, DPDK applications may occur) because this packet information is not part of the key domain and the data is encrypted.

[0041] Now refer to Figures 1 to 5 Explain the above-mentioned systems, methods and devices.

[0042] Figure 1A system 100 is shown in accordance with at least one example embodiment. System 100 includes a host device 104, a communication network 108, and a host device 112. In at least one example embodiment, host devices 104 and 112 correspond to one or more of a personal computer (PC), a laptop, a tablet, a smartphone, a server, a collection of servers, and the like. In some embodiments, host devices 104 and 112 may correspond to any suitable type of device that communicates with other devices that are also connected to a general type of communication network 108. As another specific but non-limiting example, host devices 104 and 112 may correspond to network switches of servers that provide information resources, services, and / or applications to user devices, client devices, or other hosts in system 100.

[0043] Examples of communication networks 108 that can be used to connect host devices 104 and 112 include Internet Protocol (IP) networks, Ethernet, InfiniBand (IB) networks, Fibre Channel networks, the Internet, cellular communication networks, wireless communication networks, combinations thereof (e.g., Fibre Channel over Ethernet), variations thereof, and / or the like. In a specific but non-limiting example, communication network 108 implements data transmission between devices 104 and 112 using optical signals. In this case, host devices 104 and 112 and communication network 108 may include waveguides (e.g., optical fibers) that carry optical signals. In a specific but non-limiting example, communication network 108 implements data transmission between host devices 104 and 112 using electrical signals. In this case, host devices 104 and 112 and communication network 108 may include wires (e.g., copper wires) that carry electrical signals. In one embodiment, communication network 108 implements data transmission using both electrical and optical signals.

[0044] Host device 104 includes an attachable network device (also referred to as a network attachment device), such as a network interface controller (NIC) 116 or other suitable network attachment device. Host device 104 includes a set of local trust roots 120, an encryptor / decryptor 124, encrypted memory 128, and a central processing unit (CPU) 132.

[0045] NIC 116 may be a "smart" NIC that includes a CPU complex with at least one CPU 118. CPU 118 may include processing circuitry and / or memory for performing computing tasks, such as tasks associated with controlling data flow on communication network 108. The processing circuitry may include software, hardware, or a combination thereof. For example, the processing circuitry may include memory containing executable instructions and a processor (e.g., a microprocessor) that executes the instructions on the memory. The memory may correspond to any suitable type of memory device or collection of memory devices configured to store instructions. Non-limiting examples of suitable memory devices that may be used include flash memory, random access memory (RAM), read-only memory (ROM), variations thereof, combinations thereof, and the like. In some embodiments, the memory and processor may be integrated into a common device (e.g., a microprocessor may include integrated memory). Additionally or alternatively, the processing circuitry may include hardware, such as an application-specific integrated circuit (ASIC). Other non-limiting examples of processing circuitry include an integrated circuit (IC) chip, a central processing unit (CPU), a general-purpose processing unit (GPU), a microprocessor, a field-programmable gate array (FPGA), a collection of logic gates or transistors, resistors, capacitors, inductors, diodes, and the like. Some or all of the processing circuitry may be provided on a printed circuit board (PCB) or a collection of PCBs. It will be appreciated that any suitable type of electrical component or collection of electrical components may be suitable for inclusion in the processing circuitry. As discussed in greater detail below, the CPU 118 enables the creation of a single key domain for exchanging encrypted data with the host device 112. To this end, the CPU 118 may execute isolated root-of-trust software (e.g., firmware) to extend the local root of trust 120 to form a distributed root of trust between the CPU 118 and the local root of trust 120.

[0046] The local root of trust 120 includes appropriate hardware and / or software for enabling secure communications with other elements of the host device 104 and is trusted by the operating system (OS) of the host device 104. The local root of trust 120 (e.g., Advanced RISC Machine (ARM) Trusted Boot) can be a hardware-assisted entity that allows running system software to protect the identity of the platform on which the software is running. This can prevent attackers from taking control of the system at a very low level, for example, by preventing the launch of a malicious operating system kernel or by preventing host emulation to trick software into running in an attacker-controlled execution environment (enclave). With the advent of hardware memory encryption, the root of trust role has expanded to provide secret keys to the encryptor / decryptor 124 hardware, which performs cryptographic operations in a controlled manner, via an out-of-band channel. In addition, a secure interface exists with the OS and hypervisor 140 to control which keys are used for which secure execution environments (e.g., VMs). The local root of trust 120 can include a CPU-based system that is physically isolated from the communication network 108 and controlled by the host device 104's firmware (e.g., Basic Input Output System (BIOS) firmware), to which the root of trust also provides secure boot services. Thus, software running on host device 104 interacts with host device 104 firmware to access specific, well-defined root-of-trust services.

[0047] In at least one embodiment, the local root of trust 120 implements data encryption functions, detection and reporting of unauthorized changes to the operating system or applications, detection of malware, memory shielding, and / or digital rights management. As discussed in more detail below, the local root of trust 120 is paired with the root of trust of the CPU 118 (also referred to as an extended root of trust) to provide a distributed root of trust for the host device 104.

[0048] The encryptor / decryptor 124 includes suitable hardware and / or software for encrypting data and storing the encrypted data on the encrypted memory 128. The encryptor / decryptor 124 may also include suitable hardware and / or software for decrypting data from the encrypted memory 128. The encryptor / decryptor 124 may encrypt data from the CPU 132 using a key received from the local root of trust 120 over an isolated (secure) channel. The encrypted memory 128 may include volatile and / or non-volatile storage devices. Non-limiting examples of suitable memory devices for the encrypted memory 128 include flash memory, random access memory (RAM), variations thereof, combinations thereof, and the like. The encrypted memory 128 may be the main system memory of the host device 104 (e.g., Figure 1 shown), peripheral-specific memory (e.g., GPU memory), encrypted storage (e.g., NVMe Over Fabric), and / or storage-class memory.

[0049] The set of CPUs 132 may include processing circuitry that is the same as or similar to CPU 118. In one embodiment, CPUs 132 include physical and / or logical processing units that perform operations for corresponding virtual machines (VMs) in the set of VMs 136 created by hypervisor 140. CPUs 132 and VMs 136 may be controlled by hypervisor 140.

[0050] Host device 112 includes an attached network device (also referred to as a network attachment device), such as NIC 144, or other suitable network attachment device. Host device 112 further includes a set of local trust root 148, encryptor / decryptor 152, encrypted memory 156 and central processing unit (CPU) 160.

[0051] NIC 144 may be an "intelligent" NIC that includes a (CPU) complex having at least one CPU 146. CPU 146 may include the same or similar processing circuitry as CPU 118. As discussed in more detail below, CPU 146 (along with CPU 118) implements a single key domain for exchanging encrypted data with host device 104. To this end, CPU 146 may execute isolated root of trust software (e.g., firmware) to extend local root of trust 148 to form a distributed root of trust between CPU 146 and local root of trust 148. Figure 1 As shown, the secure key exchange may occur over a designated secure channel between CPUs 118 and 146. However, it should be understood that one or more control signals for the key exchange may be exchanged over a backend channel.

[0052] Like the local root of trust 120 of the host device 104, the local root of trust 148 includes appropriate hardware and / or software for enabling secure communications with other elements of the host device 112 and is trusted by the operating system (OS) of the host device 112. For example, the local root of trust 148 (e.g., Advanced RISC Machine (ARM) Trusted Boot) can be a hardware-assisted entity that allows running system software to protect the identity of the platform on which the software is running. This can prevent attackers from taking control of the system at a very low level, for example, by preventing a malicious operating system kernel from launching or by preventing host emulation from tricking software into running in an attacker-controlled execution environment (enclave). With the advent of hardware memory encryption, the root of trust role has been expanded to provide secret keys to the encryptor / decryptor 152 hardware, which performs cryptographic operations in a controlled manner, via an out-of-band channel. In addition, secure interfaces exist with the OS and hypervisor 168 to control which keys are used for which secure execution environments (e.g., VMs). The local root of trust 148 may include a CPU-based system that is physically isolated from the communication network 108 and is controlled by firmware (e.g., basic input and output system (BIOS) firmware) of the host device 112 to which the root of trust also provides secure boot services. Thus, software running on the host device 112 interacts with the host device 112 firmware to access specific, well-defined root of trust services.

[0053] In at least one embodiment, the local root of trust 148 implements data encryption functions, detection and reporting of unauthorized changes to the OS or applications, detection of malware, memory shielding, and / or digital rights management. As discussed in more detail below, the local root of trust 148 pairs with the root of trust of the CPU 146 to provide a distributed root of trust for the host device 112.

[0054] The encryptor / decryptor 152 includes suitable hardware and / or software for encrypting data and storing the encrypted data on the encrypted memory 156. The encryptor / decryptor 152 may also include suitable hardware and / or software for decrypting data in the encrypted memory 156. The encryptor / decryptor 152 may encrypt data from the CPU 160 using a key received from the local root of trust 148 over an isolated (secure) channel. The encrypted memory 156 may include volatile and / or non-volatile storage devices. Non-limiting examples of suitable memory devices for the encrypted memory 156 include flash memory, random access memory (RAM), variations thereof, combinations thereof, and the like. The encrypted memory 156 may be the main system memory of the host device 104 (e.g., Figure 1 shown), peripheral-specific memory (e.g., GPU memory), encrypted storage (e.g., NVMe Over Fabric), and / or storage-class memory.

[0055] The set of CPUs 160 may include processing circuitry that is the same as or similar to CPU 118. In one embodiment, CPU 132 comprises physical and / or logical processing units that perform operations for respective virtual machines (VMs) in the set of VMs 164 created by hypervisor 168. CPU 160 and VM 164 may be controlled by hypervisor 168.

[0056] Here, it should be understood that although the various elements of system 100 are shown as separate entities, some elements may be integrated with each other within system 100. In addition, although not explicitly shown, it should be understood that host devices 104 and 112 may include other processing devices, storage devices, and / or communication interfaces that are typically associated with computing tasks such as sending and receiving data. System 100 may also include additional host devices having substantially the same structure as host devices 104 and 112.

[0057] like Figure 1 As shown, NICs 116 and 144 implement secure key exchange between them, for example, by CPUs 118 and 146 executing securely stored key exchange software stored thereon. Some key exchange operations, such as those for controlling the key exchange and / or the actual key exchange, may occur over a secure backend channel between CPUs 118 and 146.

[0058] At this point, it should be understood that host devices 104 and 112 have encrypted memory support. In other words, data stored in memory 128 and 156 (e.g., after a minimum consistency point) is always encrypted. Encrypted memory support has different modes of operation, which can be divided into two main categories: transparent full memory encryption (where everything in memory 128 and 156 is encrypted with the same key—referred to as secure memory encryption); and schemes that allow each virtual machine or each container (or more specifically, each process) to use a custom key for in-use data. Because the memory contents are always encrypted, illicit memory dumps via side channels have the additional challenge of breaking symmetric key encryption (such as AES) to read the data, which is difficult to solve.

[0059] The inventive concept relates to situations where host devices 104 and 112 have memory encryption support enabled, which creates secure memory enclaves that allow different keys (or the same key) to be used for each application. Host devices 104 and 112 can run applications that perform RDMA transfers across communication network 108. In operation, system 100 creates an isolated, secure, single encryption key domain that integrates the security of data in use (i.e., data in memory 128 and 156) for each host device 104 and 112 with the data in motion introduced by RDMA between host devices 104 and 112 for two or more applications that want to exchange data. For example, Figure 1 The encrypted data flow between host devices 104 and 112 is shown, where the encrypted data flow may correspond to an encrypted RDMA transfer of data. It is worth noting that the data remains encrypted throughout the RDMA transfer process and does not need to be decrypted.

[0060] exist

[0061] As discussed in more detail below, system 100 implements a single key domain between applications on host devices 104 and 112, including secure memory enclaves that also need to exchange data via RDMA. Each NIC 116 and 144 has a free encrypted RDMA payload and does not need to provide additional encryption support, thereby consuming less power while transmitting encrypted data.

[0062] In general, the present inventive concepts involve distributing roots of trust to the NIC CPUs 118 and 146 (e.g., using specific hardware and / or software) and integrating each NIC root of trust 120 and 148 with a corresponding local root of trust 120 and 148 to form a distributed root of trust that enables the NICs 116 and 144 to exchange keys, e.g., to perform encrypted RDMA operations between the host devices 104 and 112. In this case, each NIC 116 and 144 acts as an isolated key distributor that securely provides keys to applications running on the host devices 104 and 112. Each NIC 116 and 144 can also provide isolated key distribution to several different clients (e.g., VMs) on the same host, while providing security domains for data in use (e.g., data in memory) and data in motion (e.g., data in transit) with a single encryption key. As discussed in more detail below, the inventive concepts also relate to a boot sequence for secure domains for data-in-use and data-in-motion for applications running on systems with encrypted memory support and performing RDMA transfers, and the integration of quantum key distribution (QKD) employing the above-described key distribution scheme.

[0063] The distributed root of trust for secret key management features endpoints appropriately integrated on each host device 104 and 112. For example, distributed root of trust support on each host device 104 and 112 is provided by NICs 116 and 144 and is hardened and isolated from user applications (e.g., VMs 136 and 164). Each distributed root of trust then provides encryption keys to its host device 104 and 112 via an isolated channel used by hardware-enabled cryptographic memory support devices (e.g., encryptor / decryptor devices 124 and 152). The host device firmware handles integrating the root of trust provided by each NIC with the corresponding local root of trust. System 100 is utilized by hypervisors 140 and 168 (or by an application loader with hypervisor privileges running on each host device 104 and 112), which handle synchronization steps between host devices 104 and 112, enabling applications wishing to establish an RDMA channel to use the same memory encryption key. Once the reconciliation is complete, the hypervisor or loader on each host device 104 / 112 forks the application binary (eg, VM 136 / 164 ) to set the same keys for the local secure memory enclaves 128 and 156 .

[0064] Here, it should be understood that Figure 1 The key exchange in may be performed using a suitable key exchange protocol, such as Internet Key Exchange (IKE), MACsec, IPsec, a virtual private network (VPN), and / or a suitable secure tunneling method.

[0065] Figure 2 1 shows a system 100A according to at least one example embodiment. In addition to system 100A including dedicated QKD devices 172 and 176 and a dedicated QKD channel (e.g., optical fiber), system 100A and Figure 1 The QKD devices 172 and 176 and the QKD channel may include appropriate hardware and / or software for completing the process by exchanging keys according to appropriate QKD methods and protocols. Figure 1 The same key exchange concept as in Figure 2 As shown, system 100A may also include a QKD control channel between CPU 118 and CPU 146 for communicating control signals related to the QKD key exchange. For example, the QKD control channel may use in-band communication to communicate the control signals. In addition, the QKD control channel may also carry a key identifier, while the QKD channel between QKD devices 172 and 176 is an isolated channel for exchanging the actual key associated with the key identifier.

[0066] Example embodiments provide at least the following: 1) a distributed root of trust NIC-assisted concept; 2) forming a single key domain between one or more applications running on different virtual machines and exchanging data using RDMA.

[0067] Figure 3 A method 300 according to at least one example embodiment is shown. The method 300 may be performed by referring to Figure 1 and Figure 2 The present invention is described with reference to the host device 104. Figure 3 operation, but Figure 3 The operations may also be performed on host device 112 or any other host device of system 100 and / or 100A. Figure 3 The operations may involve forming a distributed root of trust in the host device to create a key for encrypting data stored in the encrypted memory 128, where the key is shared with the remote endpoint to enable encrypted data transfer operations.

[0068] Example embodiments relate to a method for adding key exchange functionality to a local root of trust of a host device by offloading the network portion of the task to a root of trust service running on a NIC, such as a CPU complex of the NIC. Thus, operation 304 may include pairing the NIC root of trust (e.g., a root of trust service programmed on the CPU 118) with the local root of trust 120 of the host device 104 connected to the NIC 116 to form a distributed root of trust that is distributed between the local root of trust 120 and the extended root of trust service of the CPU 118. The pairing process may occur each time the NIC 116 is connected to a PCI bus or other peripheral interconnect system of the host device 104 or when the NIC 116 receives an instruction to pair with the host device 104.

[0069] The pairing process in operation 304 may include generating a combined root certificate that uniquely defines the specific host device 104 platform instance and the specific instance of the attached NIC 116. Thereafter, access by the host device 104 to the NIC CPU 118 is physically restricted to being performed by circuitry that can only be controlled by the local root of trust 120 and / or the firmware of the host device 104. As part of the pairing process, the CPU 118 runs a process that is part of the local root of trust firmware to provide services for secure key exchange with a remote counterpart (e.g., other NICs, such as NIC 144) by utilizing the network access capabilities of the NIC 116. Thereafter, the NIC-based distributed root of trust at the host device 104 is ready to form a secure connection with other root of trust endpoints (e.g., the distributed root of trust of the host device 112) within or outside the data center to exchange keys.

[0070] Operation 308 includes providing a key to an encryption device of host device 104 so that the encryption device can encrypt data of one or more host device applications. For example, CPU 118 provides a key to encryptor / decryptor 124 via an isolated channel passed through local root of trust 120. Before providing the key to encryptor / decryptor 124, NIC 116 (or a suitable similar network device) can generate a key and an associated key identifier. For example, CPU 118 includes a random generator that generates a key (e.g., a unique key) and an associated universal unique identifier (UUID) for the key. As discussed in more detail below, the key identifier may be useful because finding the key identifier does not reveal the key. Encryptor / decryptor 124 can use the key to encrypt data of one or more host device applications. One or more host device applications may include an application executed by VM 136.

[0071] Operation 312 includes sharing a key with the remote endpoint. For example, the CPU 118 shares a key with the CPU 146 of the NIC 144 within the host device 112 according to a suitable key sharing technique, which may include back-end communication. For example, the key exchange may be performed using a suitable secure tunneling method such as VPN, IKE, MACsec, etc. At least one example embodiment performs the key exchange via a quantum key distribution system (QKD), such as Figure 2 To identify host device 112 as a remote endpoint, an administrator of system 100 and / or 100A may have a centralized service (eg, Domain Name System (DNS)) or maintain a hard-coded list of host device identifiers that may be used for the distributed root of trust formed in operation 304 .

[0072] In at least one example embodiment, operation 312 includes the hypervisor 140 establishing an isolated channel with a dedicated and secure firmware (i.e., the firmware cannot be overwritten). The local root of trust 120 may receive a request from the hypervisor 140 via a firmware callback to communicate with one or more endpoints (e.g., the host device 112 (see Figure 5 )) establishes a single key domain. The local root of trust 120 can then authenticate the request and relay it over an isolated channel to a distributed root of trust within the NIC 116. The root of trust on the NIC can use the backend to generate a key and associated key identifier pair and securely exchange keys (and in some cases key identifiers) with one or more remote endpoints.

[0073] Operation 316 includes sending a key identifier associated with the key to hypervisor 140 via local root of trust 120 for use by hypervisor 140 when launching one or more host device applications. For example, upon completion of the key exchange, the distributed root of trust at host device 104 securely notifies hypervisor 140 of the key exchange completion, thereby forming a single key domain between host device 104 and any endpoints participating in the secure key exchange. Furthermore, returning the key identifier to hypervisor 140 notifies hypervisor 140 that the key can be made available to the encrypted memory engines of one or more remote endpoints upon request. In at least one example embodiment, the key identifier is passed as a parameter by hypervisor 140 during application launch, such that a portion of the hypervisor's virtual address space is associated with the key. By using the key identifier instead of the key, the key used for encryption is not compromised. Upon requesting installation of a specific key identifier, the specific key identifier and associated key are marked as consumed so that it cannot be reused. At this stage, host device 104 has established a single key domain with one or more endpoints (e.g., host device 112) for exchanging encrypted data via, for example, RDMA.

[0074] Operation 320 includes forwarding encrypted data of one or more host device applications from host device memory (e.g., encrypted memory 128) to a remote endpoint. For example, system 100 and / or 100A may perform an RDMA operation to transfer encrypted data from host device 104 to host device 112 without decrypting the data at any point during the transfer. Here, it should be understood that forwarding encrypted data may include NIC 116 passing the encrypted data from the set of CPUs 132 to the communication network 108 without performing any additional operations on the data, such as data decryption or further data encryption.

[0075] The RDMA initialization sequence for operation 320 may include the following operations. First, RDMA coordination software (e.g., running on host device 104) is notified (e.g., by host device 104) that a VM (e.g., VMs 136 and 164) or a container or a specific process (in the case of high-performance computing (HPC)) will be launched on a specific host device (e.g., host devices 104 and 112) with enabled encrypted memory and will also perform RDMA. Subsequently, the RDMA coordination software notifies the hypervisor on each host device of the details for launching the host device application, that encrypted memory support has been activated, and that the host device will participate in a single key domain. A specific hypervisor (e.g., hypervisor 140) may be designated as the key domain master for initiating a distributed root of trust key exchange. Upon notification of the established single key domain (i.e., that the agreed-upon keys have been exchanged and are locally available on each endpoint), a host device application instance may be launched on each host device 104 and 112. Given that the keys at each endpoint are the same, the encrypted contents originating from the virtual address space of one application endpoint can be read by any remote counterpart without any decryption during network transmission. After proper startup as described above, standard RDMA methods can be used for channel setup and data exchange.

[0076] The above RDMA initialization method is not limited to any specific orchestrator or hypervisor or virtualization technology. The step of establishing a single key domain for the encrypted memory system using a NIC-assisted distributed root of trust can be accomplished through a custom boot process in any suitable application scenario. However, the NIC should not rely on packet information added by host device applications that use encrypted memory for forwarding operations (for example, DPDK applications may occur) because the packet information is not part of the key domain and this data is encrypted.

[0077] It should be understood that the example embodiments provide for using a single key to encrypt data belonging to multiple different host device applications. In this context, a single key domain refers to using a single key to encrypt data for multiple host device applications. However, the example embodiments also provide for using a separate key for each host device application that wishes to participate in the exchange of encrypted data. In this context, a single key domain refers to using a single key to encrypt data for a single host device application.

[0078] Figure 4 A method 400 according to at least one example embodiment is shown. The method 400 may be performed by referring to Figure 1-3 Reference is made to the host device 104 for description of the embodiment of the present invention. Figure 4 operation, but Figure 4The operations may be equally performed on host device 112 or any other host device of system 100 and / or 100A. Figure 4 The operation may involve creating a single key domain between endpoints to exchange encrypted data between the endpoints through RDMA operations.

[0079] Operation 404 includes generating a key and an associated key identifier by a network device connected to the host device. In this case, the network device may correspond to a NIC, such as NIC 116, and the host device may correspond to host device 104. The key and associated key identifier may be generated in the same manner as described above.

[0080] Operation 408 includes establishing, by the network device, a single key domain via the communications network by sharing the key and associated key identifier with at least one other network device. For example, NIC 116 establishes a single key domain via communications network 108 according to the operations described above and shares the key and associated key identifier with NIC 144.

[0081] Operation 412 includes performing an RDMA operation within a single key domain to send data encrypted with the key to at least one other network device via the communication network 108. For example, as described above, host device applications running on host devices 104 and 112 exchange encrypted data via RDMA transport. Thus, performing the RDMA operation may include forwarding, by the network device, data encrypted with the key from the host device's memory to the communication network. It should be understood that data encrypted with the key stored in the host device's memory remains encrypted with the key as the data travels from the memory, through the network device and the communication network, to the at least one other network device.

[0082] Although not explicitly shown, method 400 may include encrypting data with a key and storing the encrypted data in a memory of the host device (e.g., encrypted memory 128). Method 400 may also include pairing the network device and the host device to enable the network device to generate a key and an associated key identifier.

[0083] Notably, in methods 300 and 400, the keys exchanged between host devices 104 and 112 for encrypting data of applications running on the host devices are not disclosed to the applications and therefore cannot be read or modified by the applications. This functionality is enabled because the distributed root of trust that handles the key generation and exchange functions is physically isolated from access by the applications.

[0084] Figure 5 Shown Figure 1 and Figure 2 Specifically, Figure 5Shown is a virtual address space for a hypervisor 140 and a local root of trust 120 that receives a request from the hypervisor 140 to establish a single key domain through a firmware callback. The local root of trust 120 can then authenticate the request and relay the request over an isolated channel to an extended root of trust within the NIC 116. The extended root of trust within the NIC 116 can use a backend to generate keys and associated key identifier pairs and securely exchange keys (and in some cases key identifiers) with one or more remote endpoints (e.g., the host device 112).

[0085] Given that Figure 1-5 It should be understood that example embodiments relate to a NIC (e.g., NIC 116) that includes processing circuitry (e.g., CPU 118) configured to pair with a local root of trust (e.g., local root of trust 120) of a host device (e.g., host device 104) connected to the NIC. The processing circuitry is configured to provide a key to an encryption device (e.g., encryptor / decryptor 124) of the host device that enables the encryption device to encrypt data for one or more host device applications using the key. The encrypted data is stored in a host device memory (e.g., encryption memory 128). The processing circuitry is configured to share the key with a remote endpoint (e.g., NIC 144 of host device 112) and forward the encrypted data from the host device memory to the remote endpoint.

[0086] As discussed above, the processing circuit is configured to share a key and a key identifier for the key with a remote endpoint, and after sharing the key and the key identifier with the remote endpoint, the processing circuit is configured to send the key identifier to a hypervisor of the host device (e.g., hypervisor 140) through a local root of trust for use by the hypervisor when opening one or more host device applications. The NIC may include a designated channel that enables the processing circuit to share a key with the remote endpoint. In at least one embodiment, the designated channel is configured for quantum key distribution (QKD). As described above, the processing circuit is configured to pair with the local root of trust through an isolated channel between the NIC and the local root of trust. In at least one embodiment, the processing circuit is configured to pair with the local root of trust based on a root certificate associating the host device with the NIC. The processing circuit is configured to share a key in response to a request from a hypervisor of the host device (e.g., hypervisor 140) that is passed through the local root of trust (see Figure 5 In at least one embodiment, the processing circuit is configured to pair with a local root of trust of the host device when the NIC is connected to the host device. The processing circuit can be configured to provide a key to the encryption device through the local root of trust.

[0087] At least one example embodiment relates to a system (e.g., system 100 or system 100A) that includes a first host device (e.g., host device 104) and a first network device (e.g., NIC 116) coupled to the first host device. As discussed above, the first network device implements remote direct memory access (RDMA) operations to exchange encrypted data with a second host device (e.g., host device 112) over a communications network 108. The encrypted data is encrypted using a single key. The first network device can share the single key and an associated key identifier with the second network device. The encrypted data can belong to multiple applications running on the first host device and the second host device, or can belong to only one application running on the first host device and the second host device. Notably, the encrypted data remains encrypted throughout the RDMA operation.

[0088] While the example embodiments have been shown and described with respect to RDMA operations for encrypted data between endpoints with the assistance of a smart NIC, it should be understood that the example embodiments are applicable to any suitable situation where data movement between two endpoint devices is desired and both the source and destination endpoints are capable of operating on encrypted data. That is, the example embodiments are not limited to RDMA operations and NICs; other data transfer operations may be employed, and suitable peripheral devices other than NICs (e.g., GPUs, storage arrays with integrated NICs, such as network attached storage devices, etc.) may be used to perform the functions of the NICs described herein.

[0089] Specific details are given in the description to provide a thorough understanding of the embodiments. However, one of ordinary skill in the art will understand that the embodiments can be practiced without these specific details. In other cases, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail to avoid obscuring the embodiments.

[0090] While illustrative embodiments of the disclosure have been described in detail herein, it should be understood that the inventive concepts may be otherwise variously embodied and employed, and that the appended claims are intended to be construed to include such variations unless limited by prior art.

[0091] It should be understood that the inventive concepts encompass any embodiment in combination with any one or more other embodiments, any one or more features disclosed herein, any one or more features substantially disclosed herein, any one or more features as substantially disclosed herein in combination with any one or more other features as substantially disclosed herein, any one aspect / feature / embodiment in combination with any one or more other aspects / features / embodiments, using any one or more embodiments or features as disclosed herein. It should be understood that any feature described herein may be claimed in combination with any other feature described herein, regardless of whether or not such features are from the same described embodiment.

[0092] An example embodiment may be configured as follows:

[0093] (1) A network interface controller (NIC), comprising:

[0094] processing circuitry configured to:

[0095] Pairing with the local root of trust of the host device connected to the NIC;

[0096] providing a key to an encryption device of the host device, enabling the encryption device to encrypt data of one or more host device applications using the key, the encrypted data being stored in a memory of the host device;

[0097] Share a secret key with the remote endpoint; and

[0098] Forwards encrypted data from host device memory to a remote endpoint.

[0099] (2) The NIC of (1), wherein the processing circuit is configured to share the key and a key identifier of the key with the remote endpoint.

[0100] (3) The NIC of one or more of (1) to (2), wherein after sharing the key and the key identifier with the remote endpoint, the processing circuit is configured to send the key identifier to the hypervisor of the host device through the local root of trust for use by the hypervisor when opening the one or more host device applications.

[0101] (4) The NIC according to one or more of (1) to (3), further comprising:

[0102] A designated channel that enables the processing circuit to share the key with the remote endpoint

[0103] (5) The NIC of one or more of (1) to (4), wherein the designated channel is configured for quantum key distribution (QKD).

[0104] (6) The NIC of one or more of (1) to (5), wherein the processing circuit is configured to pair with the local root of trust via an isolated channel.

[0105] (7) The NIC of one or more of (1) to (6), wherein the processing circuit is configured to pair with the local trusted root based on a root certificate associating the host device with the NIC.

[0106] (8) The NIC of one or more of (1) to (7), wherein the processing circuit is configured to share the key in response to a request from a hypervisor of the host device communicated through the local root of trust.

[0107] (9) The NIC of one or more of (1) to (8), wherein the processing circuit is configured to pair with a local root of trust of the host device when the NIC is connected to the host device.

[0108] (10) The NIC of one or more of (1) to (9), wherein the processing circuit is configured to provide the key to the cryptographic device via the local root of trust without requiring the one or more host device applications to have access to the key.

[0109] (11) A method comprising:

[0110] generating, by a network device connected to the host device, a key and an associated key identifier;

[0111] establishing, by the network device over a communications network, a single key domain by sharing the key and the associated key identifier with at least one other network device; and

[0112] A remote direct memory access (RDMA) operation is performed within the single key domain to send data encrypted with the key to the at least one other network device over a communications network.

[0113] (12) The method according to one or more of (11) to (11), further comprising:

[0114] Encrypt the data using the key; and

[0115] The data encrypted with the key is stored in the memory of the host device.

[0116] (13) The method of one or more of (11) to (12), wherein performing the RDMA operation includes forwarding, by the network device, data encrypted with the key from a memory of the host device to the communication network.

[0117] (14) A method as described in one or more of (11) to (13), wherein the data encrypted with the key stored in the memory of the host device remains encrypted with the key as the data travels from the memory to the at least one other network device through the network device and the communication network.

[0118] (15) The method of one or more of (11) to (14), wherein the key is shared via quantum key distribution (QKD).

[0119] (16) The method of one or more of (11) to (15), further comprising:

[0120] Pairing the network device and the host device enables the network device to generate a key and an associated key identifier.

[0121] (17) A system comprising:

[0122] a first host device; and

[0123] A first network device is coupled to the first host device, the first network device implementing remote direct memory access (RDMA) operations to exchange encrypted data with a second host device over a communications network, wherein the encrypted data is encrypted using a single key.

[0124] (18) The system of one or more of (1) to (17), wherein the first network device shares the single key and associated key identifier with the second network device.

[0125] (19) The system of one or more of (1) to (18), wherein the encrypted data belongs to a plurality of applications running on the first host device and the second host device.

[0126] (20) The system of one or more of (1) to (19), wherein the encrypted data remains encrypted throughout the RDMA operation.

Claims

1. A network interface controller (NIC), comprising: processing circuitry configured to: pairing with a local root of trust of a host device connected to the NIC to enable the NIC to perform root-of-trust functions on behalf of the local root of trust of the host device, the local root of trust being a hardware-assisted entity that allows runtime system software to protect the identity of a platform on which the system software is running; generating a key for performing said root of trust functions as said local root of trust on behalf of said host device; providing the key to an encryption device of the host device via the local root of trust to enable the encryption device to encrypt one or more host device applications using the key, the encrypted data being stored in a host device memory; sharing the key with a remote endpoint to enable the remote endpoint to decrypt the encrypted data; as well as The encrypted data is forwarded from the host device memory to the remote endpoint.

2. The NIC of claim 1, wherein the processing circuit is configured to share the key and a key identifier of the key with the remote endpoint.

3. The NIC of claim 2 , wherein after sharing the key and the key identifier with the remote endpoint, the processing circuit is configured to send the key identifier to a hypervisor of the host device through the local root of trust for use by the hypervisor when opening the one or more host device applications.

4. The NIC of claim 1 , further comprising: A channel is designated that enables the processing circuit to share the key with the remote endpoint.

5. The NIC of claim 4, wherein the designated channel is configured for quantum key distribution (QKD).

6. The NIC of claim 1, wherein the processing circuit is configured to pair with the local root of trust through an isolated channel.

7. The NIC of claim 1, wherein the processing circuit is configured to pair with the local root of trust based on a root certificate associating the host device with the NIC.

8. The NIC of claim 1, wherein the processing circuit is configured to share the key in response to a request from a hypervisor of the host device communicated through the local root of trust.

9. The NIC of claim 1, wherein the processing circuit is configured to pair with a local root of trust of the host device when the NIC is connected to the host device.

10. The NIC of claim 1, wherein the processing circuit is configured to provide the key to the cryptographic device through the local root of trust without the key being accessible to the one or more host device applications.

11. A method comprising: pairing a network device with a host device to enable the network device to perform root-of-trust functions on behalf of the local root of trust of the host device; generating, by a network device acting as the root of trust function executing on behalf of the host device, a key and an associated key identifier; A single key domain is established by the network device and through the communication network by: providing the key to an encryption device of the host device via a secure channel passing the local root of trust to enable encryption of data of one or more host device applications using the key; as well as sharing the key and the associated key identifier with at least one other network device; as well as A remote direct access memory (RDMA) operation is performed within the single key domain to send the data of the one or more host device applications encrypted with the key to the at least one other network device over a communications network, wherein the at least one other network device decrypts the data using the key.

12. The method of claim 11, further comprising: encrypting the data using the key; as well as The data encrypted with the key is stored in a memory of the host device.

13. The method of claim 12, wherein performing the RDMA operation comprises: Data encrypted with the key is forwarded by the network device from the memory of the host device to the communication network.

14. The method of claim 12, wherein the data encrypted with the key stored in the memory of the host device remains encrypted with the key as the data travels from the memory to the at least one other network device through the network device and the communications network.

15. The method of claim 11, wherein the key is shared via quantum key distribution (QKD).

16. The method of claim 11, wherein the key is provided to the cryptographic device of the host device through the root of trust of the host device without the one or more host device applications having access to the key.

17. A system comprising: a first host device; and A first network device is paired with a local root of trust of the first host device so that the first network device performs root of trust functions on behalf of the root of trust of the first host device, the first network device implements remote direct memory (RDMA) operations to exchange encrypted data with a second host device over a communications network, wherein the encrypted data is encrypted using a single key generated by the first network device as the root of trust function performed on behalf of the local root of trust of the first host device, and the single key is provided by the first network device to the first host device and the second host device so that the first host device encrypts the encrypted data using the single key and the second host device decrypts the encrypted data using the single key, wherein the single key is provided by the first network device to an encryption device of the first host device over a secure channel passing the local root of trust of the first host device.

18. The system of claim 17, wherein the first network device shares the single key and associated key identifier with the second host device.

19. The system of claim 17, wherein the encrypted data belongs to a plurality of applications running on the first host device and the second host device.

20. The system of claim 17, wherein the encrypted data remains encrypted throughout the RDMA operation.

Images