On-demand formation of secure user domains

Abstract

The present disclosure relates to on-demand formation of secure user domains. Systems, data processing systems, and methods, among other things, are disclosed. An illustrative system includes an encryption orchestrator that analyzes a packet, obtains a tenant identifier (ID) from the packet, determines whether a tenant associated with the tenant ID currently has sufficient encryption credits available, and causes encryption resource usage to be processed using an encryption key associated with the tenant ID in response to determining that the tenant associated with the tenant ID currently has sufficient encryption credits available.

Description

On-demand formation of secure user domains

[0001] Cross-references to related applications

[0002] This application claims the benefit of Greek Patent Application No. 20220100162, filed on February 23, 2022, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] This disclosure generally relates to systems, devices, and methods for encrypting data transmission. Background Technology

[0004] Modern data centers employ a variety of devices and methods for high-speed data exchange that is vulnerable to malicious attacks, especially when the data being exchanged is not encrypted. Summary of the Invention

[0005] In an illustrative embodiment, a system includes: a cryptographic coordinator that analyzes packets, obtains a tenant identifier (ID) from the packets, determines whether a tenant associated with the tenant ID currently has sufficient cryptographic credit available, and, in response to determining that the tenant associated with the tenant ID currently has sufficient cryptographic credit available, enables cryptographic resources to process the packets using a cryptographic key associated with the tenant ID.

[0006] In an illustrative embodiment, a data processing system includes: a cryptographic coordinator that enables a tenant among a plurality of tenants to deploy a tenant-specific confidential enclave on computing resources shared among the plurality of tenants by: receiving a request to create the confidential enclave for the tenant; identifying a group of servers among a plurality of servers, the group of servers including computing resources available to the tenant; employing a root of trust (RoT) on a first server in the group of servers to exchange cryptographic keys with each of the other servers in the group of servers; updating data associated with the cryptographic keys for a tenant identifier (ID) to be assigned to the tenant; and making the updated data available for reference during encrypted transmission of data initiated by the tenant.

[0007] In an illustrative embodiment, a method is provided that enables a tenant among multiple tenants to deploy a tenant-specific confidential enclave on computing resources shared among the multiple tenants, wherein the method includes: receiving a request to create the confidential enclave for the tenant; identifying a group of servers among a plurality of servers, the group of servers including computing resources available to the tenant; accessing a root of trust (RoT) on a first server in the group of servers to exchange encryption keys with at least a second server in the group of servers; updating data associated with the encryption keys for a tenant identifier (ID) to be assigned to the tenant; and making the data referable during encrypted transmission of data initiated by the tenant.

[0008] Other features and advantages are described herein and will become apparent from the following description and accompanying drawings. Attached Figure Description

[0009] This disclosure is described in conjunction with the accompanying illustrations, which are not necessarily drawn to scale:

[0010] Figure 1 illustrates a system according to at least one exemplary embodiment;

[0011] Figure 2 illustrates additional details of the system according to at least one exemplary embodiment;

[0012] Figure 3 illustrates further details of the system according to at least one exemplary embodiment;

[0013] Figure 4 is a block diagram illustrating a data link layer encryption scheme with key provisioning according to at least one exemplary embodiment;

[0014] Figure 5 is a block diagram illustrating tenant supply capacity according to at least one exemplary embodiment; and

[0015] Figure 6 is a block diagram illustrating details of a networked device according to at least one exemplary embodiment. Detailed Implementation

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

[0017] As can be understood from the following description, and for computational efficiency reasons, the components of the system can be arranged in any appropriate location in the distributed network of components without affecting the operation of the system.

[0018] Furthermore, it should be understood that the various links connecting the elements can be wired, traced, or wireless links, or any suitable combination thereof, or any other suitable known or later-developed element capable of providing and / or communicating data with the connected element. For example, the transmission medium used as a link can be any suitable carrier of electrical signals, including coaxial cables, copper wires and optical fibers, electrical traces on a PCB, or the like.

[0019] As used in this article, the phrases “at least one,” “one or more,” “or,” and “and / or” are open-ended expressions that are both connective and disconnective in operation. 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” implies A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together.

[0020] The terms “determine,” “calculate,” and “compute,” as used herein, and their variations, are used interchangeably and include any appropriate type of method, process, operation, or technique.

[0021] This document will describe various aspects of the disclosure with reference to the accompanying drawings, which may be schematic diagrams of idealized configurations.

[0022] Unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains. It will be further understood that terms (such as those defined in common dictionaries) should be interpreted as having the same meaning as they have in the relevant technical field and in this disclosure.

[0023] As used herein, unless the context explicitly indicates otherwise, the singular forms of “a,” “an,” and “the” are intended to include the plural forms as well. It will be further understood that the terms “include,” “including,” “includes,” “comprise,” “comprises,” and / or “comprising,” when used in this specification, specify the presence of the stated feature, integer, step, operation, element, and / or component, 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.

[0024] Today's encryption is the best it has ever been. Innovative adversarial attacks occur at all levels of the computer stack, and recently even at the lowest level—the hardware resources. The consequence of such attacks is that data should not reside or traverse any hardware component without being encrypted, as attackers can even leverage performance monitoring methods to create edge channels and eavesdrop on data. Given the complexity of modern systems, data is highly susceptible to being eavesdropped on by adversaries. The sophistication of potential attacks makes it all the more crucial that data be in an encrypted, unusable state when illegally acquired.

[0025] Encrypting data in both static and dynamic states, and allowing decryption only immediately preceding its use, is a clear way to secure complex hardware systems. However, encryption at the individual resource level and key management on a per-tenant basis introduce numerous challenges that require innovative technological solutions.

[0026] One challenge in providing useful and secure hardware-level encryption is efficiency. For example, continuously encrypting and decrypting data during data movement phases (e.g., system memory to network interface controller (NIC), NIC to network, and NIC to system memory) cannot be considered efficient. It can be useful to encrypt data as soon as it is no longer needed and decrypt it immediately before reuse. Encrypted main system memory is a good example of this approach. Data is encrypted during store operations and decrypted during load operations, so the contents of main system memory are encrypted at all times. However, when memory data is moved via the PCI bus, the memory data should be decrypted because the target resource currently receiving and processing the data does not share the secret key with the memory controller.

[0027] The complexity of key sharing increases as resources belonging to the same tenant and used in the same application context cross server boundaries. Traditionally, data movement between servers is secured by network-level security methods that terminate encrypted tunneling early in the network stack. For network-level secure tunnels, encryption algorithms such as Diffie-Hellman are used to exchange keys with remote counterparts. Because software is involved in the key exchange, vulnerabilities similar to those for regular data are introduced: keys are stored unencrypted in main system memory and can therefore be hijacked, rendering all encryption useless. There are additional concerns about network security—part of the packet header should remain unencrypted because it is used by network devices for forwarding operations (such as OSI L2 switching and L3 routing). Therefore, eavesdroppers can learn the network identifier of the tunnel endpoint and attempt various network-level attacks.

[0028] Embodiments of this disclosure provide a method that allows data center orchestration software to implement on-demand, per-tenant resource enclaves that achieve confidentiality schemes across server boundaries. The proposed method is based on a secure secret key distribution scheme that utilizes an out-of-band key exchange secure channel and employs a serializer / deserializer (SERDES) data link layer to coordinate key management and pass keys between all components that a tenant will use on all servers they belong to. Encryption and decryption operations are then assigned to components that implement the transition from data in use to shelved data or data only in motion. For transport-oriented networks, the data link layer encryption scheme can be extended to work with any Media Access Control (MAC) protocol that implements frame transmission.

[0029] This disclosure pertains to encrypting some or all network headers transmitted over the wires, which will prevent or thwart an adversary from figuring out where the encrypted traffic comes from and where it goes.

[0030] Another aspect of this disclosure is to provide a confidentiality scheme that allows tenants to create resource enclaves across server boundaries. An cryptographic coordinator is described, configured to protect all data movement and transmission within and outside the server using a key owned by the same tenant. Data cannot be eavesdropped on at any stage due to lack of encryption, as it is only decrypted immediately before use and not during storage or transmission.

[0031] Furthermore, key distribution is implemented as a Root of Trust (RoT) function and isolated from the software. Tenants are unaware of the keys used to protect their deployments. A secure key-sharing scheme that coordinates key installation at the lower data link layer can then be used. Additionally, data link layer encryption is proposed for encrypting network headers in point-to-point transmissions (e.g., between NIC and switch ports). The proposed encryption method can be considered a complement to higher-level encryption schemes such as MACsec and IPsec.

[0032] Embodiments of this disclosure also provide the ability to raise secure enclaves on demand over shared resources, which coordinates the above-described functions so that tenant workloads can run in a fully encrypted setup.

[0033] It can also provide accounting functions, which makes the supply of encrypted services pay-as-you-go.

[0034] Low-level cryptographic support for protecting data is emerging when running on resources within a server. The concerns regarding introducing encryption everywhere are the additional encryption logic required for each component, latency penalties for in-band encryption of data in motion, overall power consumption penalties, and last but not least, secret key sharing.

[0035] Embodiments of this disclosure provide tenants with the ability to deploy confidential enclaves on resources that their workloads will use, regardless of whether those resources are shared with other tenants and / or span server boundaries.

[0036] A cryptographic coordinator is proposed, which receives a request to create a secure enclave and a list of resources. The selected RoT then utilizes out-of-band key exchange support to exchange keys with all remote server RoTs containing the resources involved.

[0037] In some embodiments, a tenant workload identifier is subsequently generated by a designated RoT and distributed across all entities using a key exchange mechanism. This workload identifier can then be pushed to all resources, and an association can be established between the key identifier and the data processing identifier. This approach allows each resource component to identify which data belongs to which tenant and to retrieve the correct key to perform encryption / decryption operations. For example, in system memory encryption, the workload identifier can be uniquely associated with the key identifier and the operating system (O / S) process identifier belonging to the host-side tenant in an internal table of the memory controller. Each time an access to the process memory address space occurs, the associated workload identifier can be used to retrieve the key identifier, which can then be used for encryption / decryption. In some embodiments, the workload identifier cannot overlap with the key identifier because runtime key updates are also supported, and the secret key can be updated several times throughout the workload's lifetime. As another example, a Peripheral Component Interconnect Fast (PCIe) bus root complex (RC) or host bridge receives access associated with a specific application context (e.g., ACTag) targeting a specific peripheral device. The payload is encrypted, but the PCI header, which includes information such as the payload size, physical address, and application context identifier, should be unencrypted. PCIe supports using keys provided by RoT to encrypt PCIe headers for transmissions between links, and decrypt them on the other side upon receipt (header only), thus enabling forwarding. In the same spirit, each resource stage only performs local encryption and decryption on the necessary data portions.

[0038] Embodiments of this disclosure may also relate to quantum key distribution (QKD) devices and systems implementing them. QKD devices are commercially available and are used in use cases where specific peer-to-peer links need to be secured, such as in connections between data centers. The hardware nature of QKD requires changes to the entire network design and infrastructure. Typically, QKD devices are added along with existing network equipment to facilitate key exchange in specific connections that are considered untrusted.

[0039] The above-described system, method, and apparatus will now be described with reference to Figures 1 through 6.

[0040] Figure 1 illustrates a possible system 100 configuration in which a QKD device 116 is deployed alongside a networking device 104. A QKD secure link or encrypted communication channel 112 connects the two networking devices 104. Examples of networking devices 104 include, but are not limited to, edge routers, switches, NICs, top-of-rack (ToR) switches, servers, server blades, and so on. Each networking device 104 may provide encryption capabilities for a specific port (typically hardware-accelerated for high line speeds) via an encryptor / decryptor 108, or alternatively, may connect to a dedicated device acting as an encryptor for each port. Encrypted data is exchanged via the communication channel 112, which directly connects the two networking devices 104.

[0041] Each networking device 104's encryptor / decryptor 108 utilizes a QKD key already exchanged via QKD device 116. The encryptor / decryptor 108 may include appropriate hardware and / or software for encrypting data and storing the encrypted data on encrypted memory. The encryptor / decryptor 108 may further include appropriate hardware and / or software for decrypting data from the encrypted memory. The encryptor / decryptor 108 may encrypt data from one or more central processing units (CPUs) using a key received from a local RoT via an isolated (secure) channel established with QKD device 116. The encryptor / decryptor 108 may include encrypted memory in the form of volatile and / or non-volatile storage devices. Non-limiting examples of storage devices suitable for encrypted memory include flash memory, random access memory (RAM), variations thereof, combinations thereof, or the like. The encrypted memory may be the networking device 104's main system memory, peripheral device-specific memory (e.g., graphics processing unit (GPU) memory), encrypted storage (e.g., structurally NVMe (NVMe Over Fabric)), and / or storage class memory.

[0042] QKD keys are exchanged directly between QKD devices 116 via quantum channel 120. An additional service channel 124 between QKD devices 116 can be used to facilitate the implementation of the QKD protocol. Service channel 124 can be used by QKD devices 116 to exchange information about key identifiers without carrying the actual keys. Therefore, any information exchanged via service channel 124 does not necessarily compromise the system's 100% security.

[0043] Each networking device 104 can be connected to the QKD device 116 via a physical link. An illustrative but non-limiting example of a physical link that can be used to couple the QKD device 116 to the networking device 104 is a 1GbE LAN port. Communication between the QKD device 116 and the networking device 104 is intended to provide the networking device 104 with the QKD key and key ID, typically implemented according to existing standards such as ETSI014. In this standard, the QKD device 116 exposes an HTTPS server from which the networking device 104 queries the key ID. The QKD device 116 and the networking device 104 are located in the same location, which is considered a security domain; therefore, the link between them does not introduce security vulnerabilities.

[0044] Although described and illustrated as a network element, it should be understood that networking device 104 can correspond to any type of device that is part of or connected to a communication network. Other examples of suitable devices that can act or operate like networking device 104 as described herein include, but are not limited to, one or more of a personal computer (PC), laptop computer, tablet computer, smartphone, server, collection of servers, or the like.

[0045] Communication channel 112 is described as traversing a data center; however, it should be understood that communication channel 112 can traverse any type of communication network (whether trusted or untrusted). Examples of communication networks that can be used to connect networking devices 104 and support communication channel 112 include, but are not limited to, Internet Protocol (IP) networks, Ethernet networks, 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 one specific but non-limiting example, the communication network uses optical signals to enable data transmission between networking devices 104. In this case, networking devices 104 and the communication network may include waveguides (e.g., optical fibers) carrying optical signals. In one specific but non-limiting example, the communication network uses electrical signals to enable data transmission between networking devices 104. In this case, networking devices 104 and the communication network may include conductive wires (e.g., copper wires) carrying electrical signals. In one embodiment, the communication network is capable of transmitting data using both electrical and optical signals.

[0046] Referring now to Figures 2 and 3, further details of the system 200, which facilitates secure data maintenance and transmission, will be described. Various configurations of the system 200 are shown and should not be construed as limiting the embodiments of this disclosure.

[0047] Figure 2 illustrates system 200, in which an encryption coordinator 204 manages secure communication between servers and switches. Specifically, but not limited to, system 200 is shown to include encryption coordinator 204 connected to network 220, which also connects a first server 216a to a second server 216b via switch 224. Both servers 216a and 216b are shown to include processor 228, accelerator 232, memory 236, PCI 240, and NIC 244. The NIC 244 of each server 216a and 216b provides connectivity between servers 216a and 216b and network 220. Network 220 provides connectivity between servers 216a and 216b and switch 224.

[0048] Switch 224 is shown as a switching structure 248 that communicates with multiple communication ports 252. Data flowing from one server (e.g., first server 216a) to another server (e.g., second server 216b) via switch 224 can be protected in tenant security enclave 208. Tenant security enclave 208 can be managed by cryptographic coordinator 204 via on-demand security channel 212.

[0049] As will be described in further detail herein, the cryptographic coordinator 204 may reside on one or more components of system 200 to manage tenant security enclaves 208. As an example, the cryptographic coordinator 204 may be provided in the software, firmware, and / or hardware of servers 216a, 216b, and / or switch 224. The cryptographic coordinator 204 may also be provided at a central controller. In some embodiments, the cryptographic coordinator 204 is provided on one or more networked devices 104 used by tenants as part of their workflow.

[0050] The encryption coordinator 204 can be configured to maintain resource identifiers and related configuration details regarding which data will be encrypted and for which tenant. To this end, the encryption coordinator 204 can generate workload identifiers and communicate with the RoT devices of each server 216a, 216b containing resources (e.g., processor 228, accelerator 232, memory 236, PCI 240, NIC 244) that will be used for workload execution. Each resource has encryption and decryption components implementing cryptography. Each resource encryptor can be provided with isolated access to a lookup table that associates the workload identifier with a secret key tag and another resource-specific identifier (e.g., memory address, tag, IP port, etc.), which will allow for differentiation of tenant traffic. The encryptor can then perform encryption for each tenant, which only occurs if the encryption coordinator 204 has enabled encryption in the resource. Furthermore, the encryption coordinator 204 can specify partial encryption of tenant data, for example, covering annotation data (e.g., memory address, interrupt identifier, etc.) that needs to be used by a specific resource for processing / forwarding, rather than processing the entire data. In this way, each resource can flexibly encrypt a portion of the data it needs to receive (or data that needs to be appended for internal use), and this is important for local processing rather than the rest of the data that has already been encrypted.

[0051] As a non-limiting example of the above functionality, suppose an encrypted memory controller receives a memory read request from a Direct Memory Access (DMA) engine via the PCI 240 bus. The memory controller needs to be able to read the requested memory address and the requested data size; therefore, the PCI Root Complex can decrypt the read request header before passing it to the memory controller. The memory controller reads the encrypted data from memory and passes the response to the PCI Root Complex (RC), allowing the data to be returned to the remote DMA engine. The response header is passed to the PCI-RC in an unencrypted state because the PCI-RC needs to determine which component the response is addressed to, although the response data is passed to the PCI-RC in an encrypted state. The PCI-RC then encrypts the response header toward the destination endpoint; therefore, if an adversary eavesdrops on the PCI channel, the adversary will be unable to discern anything about the transaction because every bit on the wire is encrypted.

[0052] Once the above configuration is pushed to each involved resource, a secure tenant resource enclave is created, as depicted in Figure 2. Each resource facilitates the confidential processing of tenant data, which will be impossible to decrypt, thus forming a virtual shared resource enclave 208. It is worth noting that the same physical resources can be shared between different tenants, but each tenant will use a different key. In addition to protecting the resources of servers 216a and 216b, the resources of switch 224 (e.g., switch fabric 248 and / or port 252) are also protected. Therefore, the overall tenant secure enclave 208 is maintained in a secure state.

[0053] As shown in Figure 3, the supply of each tenant's secret key 308 can be performed in isolation and can be a RoT 304 component function. The secret key 308 can be delivered 316 when the cryptographic coordinator 204 requests and ultimately triggers the appropriate firmware callback. The designated RoT 304 is considered the master RoT 304 that generates the key 308 and subsequently distributes the key 308 to neighboring RoT 304s on the same and neighboring servers 216a, 216b. In the example shown, a key exchange channel 312 is established between RoT 304s on different networking devices 104 (e.g., switch 224 and servers 216a, 216b). As described above, the key exchange channel 312 may include a quantum channel 120 and / or a service channel 124.

[0054] In some embodiments, RoT 304 transmits key 308 to components via an isolated channel 312 that is not exposed to software. Key-exchange-oriented networks can utilize out-of-band mechanisms (e.g., quantum channel 120). The QKD method provides a suitable approach, but other non-quantum methods are also conceivable. For example, conventional key exchange protocols can also be used to distribute key 308 between RoT 304s of different networking devices 104. Embodiments of this disclosure envision RoT device 304 providing key 308 in a confidential manner as described above.

[0055] Referring now to FIG4, additional details relating to the operation of the cryptographic coordinator 204 will be described according to at least some embodiments of the present disclosure. Embodiments of the present disclosure provide a method for providing cryptographic support at the data link layer (e.g., over a SERDES channel).

[0056] Figure 4 illustrates a transmitter 404 and a receiver 408 communicating with each other. The transmitter 404 may correspond to a first networking device 104, while the receiver 408 may correspond to a second networking device 108.

[0057] Transmitter 404 is shown as including cryptographic coordinator 204, although it should be understood that cryptographic coordinator 204 may be provided on receiver 408 or on some other device in system 200. Transmitter 404 is also shown as including data link 416, physical decoding sublayer (PCS) 420, encryptor 108, and RoT 304. PCS 420 is shown as including gearbox 424. Receiver 408 includes the corresponding RoT 304, decryptor 108, PCS 420, and data link 416.

[0058] Since SERDES supports most interconnects used for chip-to-chip data transfer, the proposed encryption scheme is suitable for data security in all motion. It is worth noting that SERDES-based communication is implemented between components on the same server, but also between NIC and switch ports; therefore, the method is also applicable to network data transfer.

[0059] Following physical layer digital signal processing, the SERDES stack is characterized by several hardware logic layers implemented in RTL, which can be further processed at the transaction layer before data is recovered at receiver 408. These lower layers are bundled below data link layer 416 and are typically named PCS 420 and Physical Medium Attachment (PMA). The PCS 420 layer is significant because it is the lowest layer; it groups data bits into well-defined entities that can be processed individually. These entities are called flits, and their bit size is defined by the SERDES logic design; they are typically groups of bits that can be processed individually by the hardware pipeline stages within a clock cycle. Therefore, a large block of data pushed from one resource to the next via SERDES is cut into flits for forwarding within the SERDES hardware pipeline. The PCS 420 layer is characterized by gearbox 428, which can specify different portions or bits contained in tenant frames 412 received at data link layer 416. Specifically, gearbox 424 can be configured to specify the data and control flits 428. The data bit block carries the payload of tenant frame 412, while the control bit block 428 is used to pass control information between SERDES endpoints and is consumed between SERDES endpoints. For example, one function of the control bit block 428 is a clock compensation message, and another is a cyclic redundancy check (CRC) check sequence message.

[0060] The embodiments of this disclosure introduce cryptographic support at the SERDES level through a cryptographic coordinator 204. Specifically, control messages can be designated to carry key tags and also determine the number of subsequent bit blocks to be encrypted with a secret key 308 corresponding to a specific tag. When tenant frame 412 arrives at the data link 416 layer of the SERDES channel, a special annotation containing a workload identifier follows the bit block as it enters the SERDES pipeline. After gearbox 424, encryptor module 108 is receiving control bit block 428. Before control bit block 428 is forwarded as part of encrypted tenant frame 432, encryptor 108 retrieves the appropriate cryptographic key 308 based on the tag and encrypts subsequent bit blocks 436 according to the instructions on control bit block 428. Subsequently, control bit block 428 is sent unencrypted to the receiver, so decryptor 108 can perform the reverse procedure, decrypting only the specified number of bit blocks 436. This design assumes the use of block ciphers that do not extend the 432 data and operates on blocks of bit block size (e.g., the bit block size is fixed). For example, AES ciphers meet these requirements, but for the sake of discussion, the details of the ciphers will not be described. At the receiver, a properly designed SERDES channel will be able to decrypt the encrypted tenant frame 432 and produce a decrypted tenant frame 436, which should substantially match tenant frame 412. Meanwhile, an attacker or adversary will have virtually no insight into the architecture established by the tenant within the tenant's secure enclave 208.

[0061] Given this support, if an eavesdropper intercepts the SERDES channel, all data bit blocks 436, except for control bit block 428, will be encrypted in the encrypted tenant frame 432. If SERDES encryption support is configured to encrypt only a portion of the data, it is assumed that the rest of the data has already been encrypted beforehand; this would happen, for example, if the user frame is an IPSec packet. The number of bit blocks 436 to be encrypted is configurable, and for performance reasons, encryption may only occur on a portion of the unencrypted data.

[0062] Returning to the IPsec example, without publicly available encryption support, eavesdropping on the SERDES channel between NIC and switch ports would allow an adversary to see the MAC and IP headers of every flow. This information allows the adversary to understand which domain and / or service the flow belongs to and decide whether it is of interest. The eavesdropped traffic packets can then be stored in persistent storage by the adversary, who can then attempt to decrypt the payload information offline using brute-force attacks. In the post-quantum era, cracking illegally acquired, idle data is a very real threat. With the proposed SERDES encryption scheme, the eavesdropper has zero insight into who the data belongs to. While flow classification for each tenant is feasible, because the IP and Ethernet headers are encrypted, one must decipher all flows to find the tenant of interest. This significantly expands the attacker's problem space.

[0063] As shown in Figure 5, the ability to distinguish which traffic belongs to which tenant further enables the introduction of accounting support, allowing data center providers to offer SERDES-level encryption as a pay-as-you-go service. The pay-as-you-go functionality can be provided as part of the encryption coordinator 204 logic, which manages the credit bucket 512. In some embodiments, the credit bucket 512 can be implemented as a counter associated with each tenant flow. Each time a block of bits is forwarded and encrypted under the control of the encryption coordinator 204, the respective counter for each tenant is decremented. If the counter reaches zero, the associated tenant flow stops encryption until additional credit is purchased. The encryption coordinator is responsible for keeping the counter updated and properly managed based on data flow, encryption, and additions to the credit bucket 512.

[0064] In some embodiments, the cryptographic coordinator 204 may obtain the tenant ID from a bit block of a packet (e.g., from tenant frame 412). The cryptographic coordinator 204 may refer to a tenant lookup table 536 to identify the appropriate tenant ID annotation 532. The tenant ID annotation 532 may be appended to the received packet or frame 412 (e.g., as part of a control bit block 428) before the bit block is sent to the data link layer 504, which may include the SERDES pipeline 524 described above. The data link layer 504 may also include a RoT 520 (which may be similar to or the same as RoT 304) and a bit block encryption / decryption engine 528. The bit block encryption / decryption engine 528 may include an encryptor / decryptor 108.

[0065] In some embodiments, tenants may be provided with access to payment portal 508, which allows tenants to repopulate or define rules for repopulating their credit bucket 512. The encryption / decryption capabilities of the bit block encryption / decryption engine 528 may be enabled only if a valid tenant ID annotation is appended to bit block 532 and the encryption coordinator 204 has determined that the associated tenant has sufficient cryptographic credit in their credit bucket 512.

[0066] In some embodiments, the RoT 520 may refer to a tag / key stored in the RoT internal memory (also known as scratch memory) store 516 to determine whether a tenant ID annotation should be kept valid or whether the tenant ID should be removed. This approach enables the RoT to implement a tenant expiration scheme and also to garbage collect any entries that are no longer in use.

[0067] Miniaturized QKD systems are becoming available. Referring now to FIG6, additional details of a networking device 104, which may include a QKD device 116 for implementing a cryptographic coordinator 204, will be described according to at least some embodiments of the present disclosure. The feasibility of integrating a quantum random number generator (QRNG) 616 in a pluggable form is also considered. In some embodiments, the networking device 104 may be configured to include or interact with pluggable QKD devices 116, which may be attached to the front panel 604 of the networking device 104. In this way, the QKD devices together with the QRNG 616 may represent a QKD system integrated (partially or entirely) on the networking device 104. Exposing a portion of the QKD system (e.g., QKD device 116) at the front panel 204 of the networking device 104 for space management and other purposes may be desirable. This concept is well-suited for networking devices 104 (such as edge routers) because such devices provide available space on their front panel 604 to add additional pluggable transceiver ports 608.

[0068] As can be understood, various design considerations can be combined with different networking devices 104. In some embodiments, the cryptographic coordinator 204 may be provided within the controller 620 of the networking device 104 and / or as part of the QKD device 116 itself. In some embodiments, the networking device 108 includes a certain level of QKD functionality integrated into a co-encapsulated data center switch or the like.

[0069] Co-packaging can refer to the tight integration of different electrical and / or optoelectronic chips within the same package. The different chips constituting the co-packaging system are assembled on a single substrate, typically referred to as a multi-chip module (MCM) assembly 612. The MCM assembly 612 may include a switching circuit 624 surrounded by peripheral chips. In some embodiments, the switching circuit 624 and the surrounding chips are mounted on a common substrate, although such a configuration is not mandatory. The MCM assembly 6247 may be provided within a larger housing of the networking device 104, positioned behind the front panel 604. The switching circuit 624 may include one or more core digital application-specific integrated circuits (ASICs), CPUs, GPUs, microprocessors, FPGAs, combinations thereof, etc.

[0070] In a non-limiting example, the co-encapsulated networking device 104 may be provided as, for example, a switch enclosure as a rackmount unit. The networking device 104 may include an MCM assembly 612, an optical transceiver port 608, a QKD device 116, a QRNG 616, and a controller 620.

[0071] As described above, optical transceiver port 608 is located at front panel 604. Port 608 can transmit to front panel 604 via optical fiber. Controller 620 is shown to facilitate communication between components of QKD device 116 and MCM assembly 624. Controller 620 may include one or more of a processor, microcontroller, or dedicated, custom ASIC (e.g., a specific type of microcontroller or μC).

[0072] In some embodiments, the QRNG 616 can be provided as a chip that can communicate with the QKD device 116 and the MCM assembly 624 via a serial interface, providing true random numbers to facilitate secure encrypted communication over communication channel 112. It should be understood that the QRNG 616 can be provided in a pluggable form similar to the QKD device 116. Alternatively, as shown in Figure 6, one or both devices can be integrated into the networking device 104.

[0073] Specific details are set forth in the specification to provide a thorough understanding of the embodiments. However, those skilled in the art will understand that embodiments of the invention can be practiced without these specific details. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail to avoid obscuring the embodiments.

[0074] While exemplary embodiments of the present disclosure have been described in detail herein, it should be understood that the concepts of the invention may be embodied and employed in other ways, and the appended claims are intended to be construed as including such variations, unless limited by the prior art.

[0075] It should be understood that the inventive concept encompasses any embodiment combined with any or more other embodiments, any or more features disclosed herein, any or more features substantially disclosed herein, any or more features substantially disclosed herein combined with any or more other features substantially disclosed herein, any aspect / feature / embodiment disclosed herein combined with any or more other aspects / features / embodiments, and the use of any or more embodiments or features disclosed herein. It should be understood that any feature described herein may be combined with any other feature described herein to make a claim, regardless of whether such features are derived from the same described embodiment.

[0076] An exemplary embodiment can be configured as follows:

[0077] (1) A system comprising:

[0078] A cryptographic coordinator analyzes packets, obtains tenant identifiers (IDs) from the packets, determines whether a tenant associated with the tenant ID currently has sufficient cryptographic credits available, and, in response to determining that the tenant associated with the tenant ID currently has sufficient cryptographic credits available, enables cryptographic resources to process the packets using the cryptographic key associated with the tenant ID.

[0079] (2) The system according to (1), wherein the encryption key includes a quantum key, and wherein the quantum key is individually associated with the tenant.

[0080] (3) The system according to (1) or (2), wherein the cryptographic coordinator obtains the tenant ID from the bit block of the packet.

[0081] (4) The system according to (3), wherein the bit block includes a first bit block of a group.

[0082] (5) The system according to (1)-(4), wherein the encryption resources include physical decoding sublayer (PCS) hardware resources.

[0083] (6) The system according to (5), wherein the PCS hardware resources include at least one of a transmitting circuit, a scrambling circuit, a gearbox and an encoding circuit.

[0084] (7) The system according to (5), wherein the PCS hardware resources provide an encrypted version of the packet to the serializer / deserializer (Serdes).

[0085] (8) The system according to (1)-(7), wherein the packets are received from circuitry operating at the data link layer.

[0086] (9) The system according to (1)-(8), wherein the cryptographic coordinator updates the cryptographic credits available to the tenant after encrypting the packet with the cryptographic key using the cryptographic resource.

[0087] (10) The system according to (1)-(9), wherein the cryptographic coordinator determines, by referring to a resource list, whether the tenant associated with the tenant ID currently has sufficient cryptographic credits available.

[0088] (11) A data processing system, comprising:

[0089] A cryptographic coordinator enables tenants among multiple tenants to deploy tenant-specific confidential enclaves on computing resources shared among the multiple tenants in the following manner:

[0090] Receive a request to create the confidential enclave for the tenant;

[0091] Identify a group of servers from a plurality of servers, the group of servers including computing resources available to the tenant;

[0092] A root of trust (RoT) is used on the first server in the group of servers to exchange encryption keys with each other server in the group of servers;

[0093] The update will associate the tenant identifier (ID) assigned to the tenant with the encryption key; and

[0094] During the encrypted transmission of data initiated by the tenant, the updated data becomes available for reference.

[0095] (12) The data processing system according to (11), wherein each of the set of servers includes a RoT, and wherein the RoT on the first server exchanges the encryption key with the RoT on each of the other servers in the set of servers.

[0096] (13) The data processing system according to (12), wherein the encryption key is exchanged using an out-of-band key exchange process.

[0097] (14) The data processing system according to (13), wherein the encryption key includes a quantum key, and wherein the out-of-band key exchange process employs a quantum key distribution (QKD) device.

[0098] (15) The data processing system according to (11)-(14), wherein the cryptographic coordinator further enables a second tenant among the plurality of tenants to deploy a second confidentiality enclave specific to the second tenant on one or more computing resources on which the confidentiality enclave of the tenant is deployed.

[0099] (16) The data processing system according to (11)-(15), wherein the computing resources include cloud computing resources, and wherein the encryption key is used to encrypt or decrypt one or more data packets exchanged during memory access within the computing resources.

[0100] (17) A method for enabling a tenant among multiple tenants to deploy a tenant-specific confidential enclave on computing resources shared among the multiple tenants, the method comprising:

[0101] Receive a request to create the confidential enclave for the tenant;

[0102] Identify a group of servers from a plurality of servers, the group of servers including computing resources available to the tenant;

[0103] Access the root of trust (RoT) on the first server in the group of servers to exchange encryption keys with at least the second server in the group of servers;

[0104] The update will associate the tenant identifier (ID) assigned to the tenant with the encryption key; and

[0105] During the encrypted transmission of data initiated by the tenant, the data becomes available for reference.

[0106] (18) The method according to (17), wherein the data includes a resource list, the method further comprising:

[0107] Analyze packets received at the Physical Decoding Sublayer (PCS) hardware resources of the servers in the group of servers;

[0108] Refer to the resource list to determine whether the tenant associated with the tenant ID currently has sufficient cryptographic credits available; and

[0109] In response to determining that the tenant associated with the tenant ID currently has sufficient cryptographic credits available, the PCS hardware resources are enabled to process the packet using the cryptographic key.

[0110] (19) The method according to (17) or (18), wherein each of the set of servers includes a RoT, wherein the RoT on the first server exchanges the encryption key with the RoT on each of the other servers in the set of servers, wherein the encryption key includes a quantum key, and wherein a quantum key distribution (QKD) device is used to exchange the quantum key.

[0111] (20) The method according to (17)-(19), wherein the computing resources include cloud computing resources, and wherein the encryption key is used to encrypt or decrypt one or more data packets exchanged during memory access within the computing resources.

[0112] (21) The method according to (17)-(20) further includes:

[0113] After encrypting the packet with the encryption key, update the encrypted credits available to the tenant.

Claims

1. A system comprising: An encryption coordinator analyzes packets, obtains a tenant identifier ID from the packets, determines whether a tenant associated with the tenant ID currently has sufficient encryption credits available, and in response to determining that the tenant associated with the tenant ID currently has sufficient encryption credits available, enables an encryption resource to process the packets using an encryption key associated with the tenant ID, wherein the encryption key is passed to the encryption resource by a designated root of trust (RoT) device through an isolated channel not exposed to software, and the tenant is unaware of the encryption key.

2. The system of claim 1, wherein the encryption key comprises a quantum key, and wherein, The quantum key is associated with a single tenant.

3. The system of claim 1, wherein the cryptographic coordinator obtains the tenant ID from the bit block of the packet.

4. The system of claim 3, wherein the bit block comprises a first bit block of a group.

5. The system according to claim 1, wherein the encryption resources include physical decoding sublayer (PCS) hardware resources.

6. The system of claim 5, wherein the PCS hardware resources include at least one of a transmitting circuit, a scrambling circuit, a gearbox, and an encoding circuit.

7. The system of claim 5, wherein the PCS hardware resources provide an encrypted version of the packet to the serializer / deserializer Serdes.

8. The system of claim 1, wherein the packet is received from circuitry operating at the data link layer.

9. The system of claim 1, wherein the cryptographic coordinator updates the cryptographic credits available to the tenant after encrypting the packet with the cryptographic key using the cryptographic resource.

10. The system of claim 1, wherein the cryptographic coordinator determines, by referring to a resource list, whether the tenant associated with the tenant ID currently has sufficient cryptographic credits available.

11. A data processing system, comprising: A cryptographic coordinator enables a tenant among multiple tenants to deploy a tenant-specific confidential enclave on computing resources shared among the multiple tenants by receiving a request to create the confidential enclave for the tenant. Identify a group of servers that include computing resources available to the tenant; using a root of trust (RoT) device on a first server in the group of servers, exchange encryption keys with each other server in the group of servers through an isolated channel not exposed to software, wherein the tenant is unaware of the encryption keys; The update will associate the tenant identifier ID assigned to the tenant with the encryption key; And to make the updated data available for reference during encrypted transmission of data initiated by the tenant.

12. The data processing system of claim 11, wherein each server in the group of servers includes a RoT device, and wherein, The RoT device on the first server exchanges the encryption key with the RoT device on each of the other servers in the group of servers.

13. The data processing system of claim 12, wherein the encryption key is exchanged using an out-of-band key exchange process.

14. The data processing system of claim 13, wherein the encryption key comprises a quantum key, and wherein, The out-of-band key exchange process uses a quantum key distribution (QKD) device.

15. The data processing system of claim 11, wherein the cryptographic coordinator further enables a second tenant among the plurality of tenants to deploy a second confidentiality enclave specific to the second tenant on one or more computing resources shared among the plurality of tenants.

16. The data processing system of claim 11, wherein the computing resources shared among the plurality of tenants include cloud computing resources, and wherein, The encryption key is used to encrypt or decrypt one or more data packets exchanged during memory access within the computing resources.

17. A method for enabling a tenant among multiple tenants to deploy a tenant-specific confidential enclave on computing resources shared among the multiple tenants, the method comprising: Receive a request to create the confidential enclave for the tenant; Identify a group of servers that include the computing resources available to the tenant among a plurality of servers; Access the root of trust (RoT) device on the first server in the group of servers to exchange encryption keys with at least a second server in the group of servers via an isolated channel not exposed to software, wherein the tenant is unaware of the encryption keys; The update associates the tenant identifier ID assigned to the tenant with the encryption key; and makes the data available for reference during encrypted transmission of data initiated by the tenant.

18. The method of claim 17, wherein the data includes a resource list, the method further comprising: Analyze the packets received at the Physical Decoding Sublayer (PCS) hardware resources of the servers in the group of servers; Refer to the resource list to determine whether the tenant associated with the tenant ID currently has sufficient cryptographic credits available; And in response to determining that the tenant associated with the tenant ID currently has sufficient cryptographic credit available, the PCS hardware resources are able to process the packet using the cryptographic key.

19. The method of claim 17, wherein each server in the group of servers includes a RoT device, wherein the RoT device on the first server exchanges the encryption key with the RoT device on each of the other servers in the group of servers, wherein the encryption key includes a quantum key, and wherein, The quantum keys are exchanged using a quantum key distribution (QKD) device.

20. The method of claim 17, wherein the computing resources shared among the plurality of tenants include cloud computing resources, and wherein, The encryption key is used to encrypt or decrypt one or more data packets exchanged during memory access.

21. The method of claim 17, further comprising: After encrypting the packet with the encryption key, update the encrypted credits available to the tenant.

Images