Quantum secure servers

Abstract

A quantum secure server includes a processor and a memory that stores an operating system, the operating system including drivers for hardware of a quantum side channel, coprocessor, or chiplet; a quantum key generation function configured to be called by other operating system functions that utilize a secure key; and applications that make calls to the operating system for quantum keys obtained by the quantum key generation function from a remote quantum service through a quantum side channel, the coprocessor, or chiplet. In at least one embodiment, 20. The operating system receives a request to create a container and instantiates a container configured with the application in response to the request.

Description

QUANTUM SECURE SERVERSBACKGROUND

[0001] With the ubiquity of computing, people and organizations of all types, including enterprises and governments, have become reliant on computing. Much processing has been shifted to hosting enterprise functionality including database functions and storage functions on servers via heavy investment in physical servers and server farms, and increasingly in cloud subscriptions. Accordingly, this infrastructure is targeted for cyberattacks by malicious actors.

[0002] Servers are generally secured via traditional cryptographic methods including public key infrastructure (PKI) with key exchange effected via Diffie / Helman key exchange and its variants. Key generation for PKI has generally been via a number of theoretical and algebraic methods such as elliptical curves. Such methods have relied on the difficulty of factoring large numbers into their constituent primes. However, quantum computers in combination with Shor’s algorithm makes this factoring tractable and in turn makes traditional cryptographic methods vulnerable to malicious actors with access to quantum computing. Such malicious actors may include governments of nation states and state sponsored terrorist organizations.

[0003] Quantum computing is rapidly advancing by leaps and bounds. As of this writing (in 2022), IBM announced a 433-qubit quantum computer dubbed “Osprey”. This more than triples its previous world record holding quantum computer, “Eagle,” with 127-qubits. Quantum computing is already generally accessible to the public via IBM’s Watson service.

[0004] Accordingly, there is an opening to apply quantum techniques to increase the security of computing server infrastructure, to do so in a way that may be back-installed into existing server infrastructure to preserve past investment, and at the same time to minimize or eliminate man-in-the-middle vulnerabilities between the existing server infrastructure and the quantum techniques. In short, there is an opportunity for quantum secure servers.BRIEF DESCRIPTION OF THE FIGURES

[0005] The detailed description is set forth with reference to the accompanying figures. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same reference numbers in different figures indicate similar or identical items.

[0006] Figure 1 is a context diagram for quantum secure servers.

[0007] Figure 2 is a diagram of an example hardware, software, and communications environment for quantum secure servers.

[0008] Figures 3a, 3b, and 3c are block diagrams for examples of quantum secure servers.

[0009] Figure 4 is a flow chart for the operation of quantum secure servers.

[0010] Figure 5 is a flow chart for the instantiation and operation of a virtual machine and a container in concert with a hypervisor.DETAILED DESCRIPTIONContext of Quantum Secure Servers

[0011] Ready access to quantum computing enables access to quantum computing functionality to supplement traditional cryptography such as PKI and Diffie / Helman exchange. There are several quantum secure key algorithms. Examples include quantum secure key generation via software services such as Cambridge Quantum and Quantum Origin.

[0012] With traditional cryptographic key generation, a mathematical function is used to generate keys over a set of possible values, called a range, but sometimes called a field. For example, if a key generation function (x) can generate an integer key between 2.0 x 109and 2.0 x 1020, then the field for d(x) are the integers between 2.0 x 109and 2.0 x 1020. (Note that these numbers are merely exemplary. In practice, the size of the numbers and the fields are much larger.) Theoretically, the chances of guessing the key are one in 2.0 x 1020minus 2.0 x 109. However, in practice, there is a higher probability that <D(x) will generate a key in some smaller subset of the field. Compounded by the fact that D(x) may be further constrained (e.g., can only generate prime numbers) the odds againstguessing the generated key via a brute force attack become much smaller than one in the size of the smaller subset, let alone one in the size of the field. In this way, the vulnerability of keys relying on <D(x) increases and the security of keys relying on 0>(x) decreases correspondingly.

[0013] A quantum key generation algorithm has the attribute that the key generation function does not statistically favor some subset of the field. In this way, if a server relies on key generation for its cybersecurity, it can rely on the size of the field as a reasonably accurate indication of the degree of security it enjoys. In contrast, for traditional cryptographic key generation, as shown above, a large field is not likely to be a true indication of the degree of security provided by the key generator.

[0014] Quantum key generators are commercially available via software as a service. However, a server that accesses a remote quantum secure key generation service is susceptible to a man-in-the-middle cyberattack. In at least one example, a man-in-the-middle cyberattack is where a third party, often malicious, compromises a communication channel. In the present example, the communication channel is between a server and a remote quantum key generator service. Where the communication channel is compromised, a malicious actor may intercept the generated key, obviating any statistical advantages of quantum key generation.

[0015] Figure 1 provides a context diagram 100 to illustrate various techniques to take advantage of quantum key generation, making use of legacy platforms, while securing key generation from man-in-the-middle attacks. In this example, a client computer 102 accesses one or more quantum secure servers 104a ... 104n. While the client computer 102 may access the physical quantum secure servers 104a ... 104n directly, it may in at least one instance access a quantum secure virtual machine 106 as served by a hypervisor 108 that is disaggregating the quantum secure servers 104a ... 104n. The quantum secure virtual machine 106 may have a quantum secure container 107 that is accessed on demand by the client computer 102.

[0016] Quantum security can be achieved in several ways. Three ways are described herein: (1 ) in at least one embodiment, the communications channel toa remote quantum key service can be eliminated by implementing a quantum key generator 110 on a chip 112 on the motherboard 114 of a quantum secure server 104, where the server CPU 116 has direct access; (2) since the motherboard 114 has a small but measurable possibility of being compromised, in an alternative embodiment a quantum key generator can be implemented as a chiplet 117 on the central processing unit 1 16; and (3) for implementations that cannot have hardware level quantum generation, a secure channel 118 (sometime called a quantum side channel) can be implemented via hardware 120 to the remote quantum key generation service 122.

[0017] Servers making use of either on-chip quantum key generation or secure quantum side channels to a quantum key generation service are called quantum secure servers herein. Examples of on-chip quantum key generation and quantum side channels are described in further detail below.

[0018] In practice, enterprises are increasingly relying on remote, often third- party, service providers to provide server-side compute capabilities (including storage, networking, and machine learning / analytic processing). This can be achieved by placing a hypervisor on top of a set of physical servers, often in a server farm, that disaggregates the physical servers and provides virtual machines with specified capacity and capabilities on demand. Since virtual machines have instantiation delays during provisioning and configuration, a service provider may provide a container service, such as Docker or Kubernetes, to provide segregated computing services in a container on demand. In this way, an organization need only use (and be billed for) the computing capacity it requests and can both outsource and right-size its computing needs.

[0019] An effect of placing a hypervisor on top of quantum secure servers is that virtual machines and containers on those virtual machines can also have the benefit of quantum key generation. In this way, quantum secure servers may provide not only quantum secure physical servers, but also quantum secure virtual machines and containers. Quantum secure virtual machines and containers are described in further detail below.

[0020] Techniques described herein enable not only quantum secure computing, but an upgrade path to enable an organization to transition fromtraditional servers, then to traditional servers using a quantum secure channel, next to servers using a quantum secure coprocessor, and finally to quantum secure central processing units. In this way, an organization can make deliberate tradeoffs and choices as to the degree of security from man-in-the-middle attacks as opposed to the cost of upgrading and / or replacing servers, all while enjoying quantum secure server-side compute services.A Hardware, Software, and Communications Environment for Quantum Secure Servers

[0021] Before describing quantum secure servers, via Figure 2, an example of a hardware, software, and communications computing environment 200 is described. In this and other examples, the functionality for quantum secure servers is generally hosted on a computing device. Example computing devices may include, without limitation, personal computers, laptops, embedded devices, tablet computers, smart phones, and virtual machines. In many cases, computing devices are to be networked.

[0022] One computing device may be a client computing device 202. The client computing device 202 may have a processor 204 and a memory 206. The processor may be a central processing unit, a repurposed graphical processing unit, and / or a dedicated controller such as a microcontroller. The client computing device 202 may further include an input / output (I / O) interface 208, and / or a network interface 210. The I / O interface 208 may be any suitable controller card, such as a universal asynchronous receiver / transmitter (UART) used in conjunction with a standard I / O interface protocol such as RS-232 and / or Universal Serial Bus (USB). The network interface 210, may potentially work in concert with the I / O interface 208 and may be a network interface card supporting Ethernet and / or Wi-Fi and / or any number of other physical and / or datalink protocols.

[0023] Memory 206 may be any suitable computer-readable media that can store software components including an operating system 212, software libraries 214, and / or software applications 216. In general, a software component is a set of computer executable instructions stored together as a discrete whole. Examples of software components include binary executables such as static libraries, dynamically linked libraries, and executable programs. Other examples of softwarecomponents include interpreted executables that are executed on a run time such as servlets, applets, p-Code binaries, and Java binaries. Software components may run in kernel mode and / or user mode.

[0024] Computer-readable media may include computer storage media and / or communication media. Computer storage media includes volatile and nonvolatile, removable, and non-removable media implemented in any suitable method or technology for storage of information such as computer readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information for access by a computing device. In contrast, communication media may embody computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave, or other transmission mechanism. As defined herein, computer storage media does not include communication media.

[0025] A server 218 may be any suitable computing device that can participate in a network such as, without limitation, a local area network (“LAN”), a virtual private network (“VPN”), a cellular network, or the Internet. The server 218 may be a host computer and include a processor 220, a memory 222, an input / output interface 224, and / or a network interface 228. In the memory may be an operating system 228, software libraries 230, and server-side applications 232. Server-side applications may include file servers and databases, including relational databases. Accordingly, the server 218 may have a data store 234 comprising one or more hard drives or other persistent storage devices.

[0026] A service on the cloud 236 may provide the services of a server 218. In general, a server may either be a physical dedicated server or may be embodied in a virtual machine. In the latter case, the cloud 236 may represent a plurality of disaggregated servers which provide virtual application server 238 functionality and virtual storage / database 240 functionality. The disaggregated servers are physical computer servers, which may have a processor, a memory, an input / output (I / O)interface and / or a network interface. The features and variations of the processor, the memory, the I / O interface and the network interface are substantially similar to those described for the server 218. Differences may be where the disaggregated servers are optimized for throughput and / or for disaggregation.

[0027] Cloud 236 services 238 and 240 may be made accessible via an integrated cloud infrastructure 242. Cloud infrastructure 242 can not only provide access to cloud services 238 and 240 but also to billing services and other monetization services. Cloud infrastructure 242 may provide additional service abstractions such as Platform as a Service (“PAAS”), Infrastructure as a Service (“IAAS”), and Software as a Service (“SAAS”).

[0028] As previously stated, one difference between a physical server 218 or plurality of physical servers 218 arranged into a server farm is that the service provider 242 may make use of one or more hypervisors 244 to disaggregate the physical servers 218. For example, a hypervisor 244 can track which physical server 218 services (including but not limited to compute, storage, input / output / network, and analytics such as via graphical processing units) are utilized and which are free. The hypervisor 244 also may act as a scheduler for these services. For example, when a hypervisor 244 receives a request for a virtual machine with a particular configuration, the hypervisor 244 may select services from the various physical servers 218 and create a virtual machine 246 whose underlying hardware is from the selected services.

[0029] The instantiated virtual machine 246 is a software emulator that runs a selected computing instruction set architecture (ISA) such as x86, x64, or RISC- V. The hypervisor 244 may configure the virtual machine 246 with an operating system of choice, provision it with accounts of a requestor, and / or install applications. Typical applications may include but are not limited to application servers 238 and database servers 240. One effect is that a requestor only pays for requested computing services and can thereby both control (right-size) and outsource information technology (IT) services.

[0030] Because provisioning and booting an operating system on the virtual machine 246 takes time, computer requests on the virtual machine 246 are delayed by that provisioning and boot time. However, in some cases, a request desires anon-demand, near real-time response. In the past, virtual machines 246 have been pre-instantiated in a pool. However, this assumes that the pre-instantiated virtual machines have substantially the same functionality as a request. This is usually not the case.

[0031] Accordingly, containers 248, which are on-demand partitions of an already instantiated virtual machine 246, may be served to respond to a compute request. As its name implies, a container 248 is a subset of functionality of an instantiated virtual machine 246 where the container 248 is instantiated according to the compute request. Because all container 248 computing resources are already instantiated in the pre-instantiated virtual machine 246, there is no provisioning or boot time lag. Because only the requested computing resources in the container are served to the requestor, the requestor only pays for the requested computing resources, not for the entire virtual machine 246. The result is that requestors can get right-sized computing resources on demand in near real time. This is the premise of elastic computing.On-Chip, On Server, and Quantum Key Side Channel and Quantum Key Generation Facilities

[0032] As stated above, implementation of quantum security on servers can be cost prohibitive if all existing legacy servers and computing facilities were to be fully replaced with quantum secure versions. Even if cost is not a concern, a new server would necessitate the possibility of having to port applications and infrastructure from the old server to the new server. Accordingly, it is desirable to create an upgrade path with legacy servers and computing facilities from a mostly legacy server with a quantum secure interface, to a full implementation.

[0033] Figures 3a, 3b, and 3c illustrate such an upgrade path. Figure 3a is a diagram 300a of a legacy server that makes use of a remote quantum service through a secure communications channel. One issue may be that if there is physical access to the server, the interface can be interfered with by a malicious actor.

[0034] Figure 3b is a diagram 300b of a server where a coprocessor, added to a motherboard, can perform the quantum key generation facility. Here there maybe no need for a side channel, and the cost of upgrade is substantially the cost of a motherboard, a coprocessor, and the labor to upgrade the motherboard.

[0035] Finally, Figure 3c is a diagram 300c of a chiplet on the computing processor itself that is specialized to and designated for performing the quantum key generation facility. In this case, there may be no need for a motherboard upgrade, but rather a CPU upgrade, assuming pin compatibility, among other potential things. Due to the hardware change, it may be that the operating system will have to be upgraded in this scenario.

[0036] Thus, three steps in an upgrade path from a legacy server to a quantum secure server are described. Turning to Figure 300a, a quantum secure server 302a may make use of a quantum secure channel. In this example, the server 302a may correspond to the physical server 218 and has a CPU 306a and a memory 304a that may correspond to the physical server memory 222, which in turn stores an operating system 308 that may correspond to the operating system of the physical server 218.

[0037] The operating system 308 may include custom drivers specific to the hardware for the quantum side channel described below, any coprocessor, and / or modified CPU / chiplet functionality introduced.

[0038] The operating system 308 may have a key generation function 310a that that will be called by other operating system 308 functions that require a secure key. Since applications 312 on the server 302a will make calls to the operating system 308 for quantum keys, and the operating system 308 will get quantum keys via the key generation function 310, those applications 312 will have the benefit of the key generation function 310. Note that an application recompilation is not necessitated because changes for quantum key generation can be localized to the operating system 308. Rather, the key generation function 310a can be configured to obtain quantum secure keys from a quantum side channel.

[0039] In some examples, key generation may be performed off server, e.g., via a remote quantum service 314. The remote quantum service 314 may be on a secure physical server or alternatively may be implemented as a software service.

[0040] The remote quantum server 314 may be accessed through a secure communications channel 316. The secure communications channel 316 may be secured via traditional key exchange or suitable self-sovereign identity techniques. In cases where the local CPU 304a has a CPU-specific local key, self-sovereign identity techniques may make use of that CPU-specific local key, thereby obviating the need for keys centralized in a (potentially hackable) key database.

[0041] The secure communications channel 316 may be interfaced via a daughterboard 318 on the server 302a, with a secure communications chip 324 or custom hardware 120 that encodes the secure communications channel 316. Here, the secure communications chip may be an application specific integrated chip (ASIC) that contains firmware for how communications sessions are to be established and managed. In some embodiments, the actual network interface is not handled by this ASIC, but this functionality could be added, useful particularly where the network layer of communications is to be proprietary or otherwise implemented differently for better security, for example. In cases where the remote quantum server 314 is a paid service, the secure communications chip 324 can be configured for automated charging and / or payments. In embodiments where the daughterboard 318 is hardware different from the stock server 302a, the daughterboard 318 is likely to make use of custom drivers for the operating system 308.

[0042] The daughterboard 318 may be interfaced via a parallel or other bus, usually via a Peripheral Component Interconnect (PCI) bus 320. However, other bus ports on a motherboard may be made use of alternatively.

[0043] In cases where the daughterboard 318 delegates communications to the legacy computer 302a, it will call the communications chip 324 for the I / O and network interface. The steps for the communications from application 312 to operating system 308 to key generation function 310 to the daughterboard 318, communications chip 324, and remote quantum server 314 are described in further detail below.

[0044] Turning to Figure 3b, performance of the quantum key generation is on a coprocessor 326 on the server 302b itself, thereby obviating the need for a quantum side channel. The server 302b will have memory 304b and a CPU 306bthat may be analogous to the memory 304a and the CPU 306a, respectively, on the server 302a with the remote quantum channel.

[0045] The memory 304b shown in Figure 3b hosts operating system 308, which has an operating system key generation function 310. As with the server 302a, an application 312 in the memory 304b may call the operating system 308 when it needs a key, and in turn the operating system 308 may call the operating system key generation function 310 to obtain the key.

[0046] In the case of server 302b, instead of the operating system key generation function 310 calling a daughterboard 318 to ultimately connect to a remote quantum server for key generation as in Figure 3a, the key generation is instead performed by the coprocessor 326, which is capable of generating a quantum key algorithm to serve a key using known, suitable principles.

[0047] The coprocessor 326 may be installed on a socket on the motherboard of the server 302b or may be soldered directly to the motherboard. Regardless of how the coprocessor 326 is installed, the coprocessor 326 is to interface with the motherboard bus 328. In some embodiments access is via direct bus access. Specifically, the CPU 306b can turn over execution directly to the coprocessor 326 for the quantum key generation specific operations. If the coprocessor 326 is custom hardware, the operating system 308 may have custom drivers for the coprocessor 326.

[0048] In embodiments in which where the computer 302b has the coprocessor 326 to perform quantum key generation, the coprocessor can be called instead of calling a remote quantum server such as the remote quantum server 314. The steps for the communications from application 312 to operating system 308 to key generation function 310 to the coprocessor 326 are described in further detail below.

[0049] Turning to Figure 3c, an example is shown of a quantum secure server 302c in which the quantum key generation can be performed on a modified CPU 330 with a chiplet 332 as described below. The server 302c has memory 304c that may be analogous to the memory 304a and the memory 304b.

[0050] The chiplet 332 may be configured to perform the quantum key generation. In some embodiments, the chiplet 332 may be a set of functionalities implemented as a set of transistors, usually in silicon, and added as a module to the CPU 330. Communication between the chiplet 332 and the rest of the CPU 330 may be via an on-CPU communications channel known as a CPU crossbar 334.

[0051] As with the servers 302a and 302b, an application 312 in the memory 304c may call the operating system 308 when it needs a key, and in turn the operating system 308 may call the operating system key generation function 310. The operating system key generation function 310 in turn may call the chiplet 332 on the CPU 330, potentially via a driver. Because the chiplet 332 implements quantum key generation, the chiplet 332 will return a generated quantum key to the operating system key generation function 310, which in turn via the operating system 308 returns the key to the application 312. The chiplet approach, compared with the remote quantum server 314 example of Figure 3a and the coprocessor 326 example of Figure 3b, removes the need for the quantum side channel, and also removes the risk of a malicious party intervening in the communications channel with the coprocessor 326 at the bus or at the daughterboard 318.

[0052] Notably, any software changes were implemented in the operating system 308 by configuring the operating system key generation function 310 to call a driver to invoke key generation via the chiplet 332. Accordingly, there is no need to recompile applications.Operational Flow to Obtain and Use a Quantum Generated Key via Quantum Secure Servers

[0053] A general process for an application 312 to obtain a quantum key may include the application 312 making a request for a key from operating system 308. From the perspective of the application 312, it simply obtains a key, and has no visibility as to how the key is generated.

[0054] As described, in response to the key request, the operating system 308 makes use of the operating system key generation function 310. Again, from the perspective of the rest of the operating system 308, a key is being obtained, and whether it is quantum generated or legacy generated should be immaterial. However, in some cases, the operating system 308 may perform other operationsthat depend on whether the key is quantum generated or not. For example, for telemetry and audit, the operating system 308 may separately track what keys are quantum generated and what applications and accounts made use of quantum generated keys. In some examples, the operating system 308 may flag applications that are particularly trusted or secure for administrators. On the other hand, the operating system key generation function 310 handles key generation and accordingly will have visibility on how a key is generated.

[0055] Typically, the operating system key generation function 310 will be implemented via programmatic objects and object methods (assuming the operating system key generation function 310 is programmed using object oriented techniques) and / or programmatic functions. Some object methods and / or functions may be exposed via an application programming interface (API) of the operating system key generation function 310. Such object methods and / or functions may be implemented via invoking a device driver to the chiplet 332, the coprocessor 326, or the daughterboard 318 / communications chip 324, depending on where the key is generated.

[0056] One result is that in order to make use of and to obtain quantum generated keys, the application 312 need not be modified and recompiled. Furthermore, modifications to the operating system 308 may be isolated to the operating system key generation function 310, addition of device drivers, and any new functionality to the operating system 308 that will be dependent on whether a key is quantum generated or not. For example, a quantum key generating operating system can be created by taking the source code for an open-source operating system such as Linux, modifying the operating system key generation model, adding the quantum key dependent functionality, if there is any, and recompiling. In this way, migration of hardware can be managed, and updates and replacements scheduled independently of having access to quantum key generation functionality. Applications 312 and operating system 308 can run without modification from a remote service 314, a server with a coprocessor 326, and / or a server with a CPU with a quantum chiplet 332.

[0057] Figure 4 describes in further detail in flow chart 400 as to how obtaining a quantum key is mediated via the operating system key generation function 310.

[0058] In block 402, in the regular course of operating, the application 312 may require a key. Accordingly, the application 312 may make a request of the operating system 308. In block 404, the operating system 308 may delegate the key request to the operating system key generation function 310.

[0059] The operating system key generation function 310 may determine how to generate the quantum key in diamond block 406. The operating system key generation function may determine what key generation options are available and select an option, for example based on priority.

[0060] An example process is as follows. The operating system function may have the capability of generating a key from a quantum side channel via a daughterboard 318 with a communications chip 324 to remote service 314, via a coprocessor 326, and / or via a chiplet 332. The operating system key generation function 310 can determine what methods are available by virtue of the device drivers for the aforementioned daughterboard 318, communications chip 324, coprocessor 326, and chiplet 332 that are installed and registered with the operating system 308. If a driver is not installed and registered, the respective functionality is not available. If more than one source of a quantum key is available, the operating system key generation function may be configured to use, in priority order, the chiplet 332 first, the coprocessor 326 second, the daughterboard 318 and communications chip 324 third, and legacy key generation last. Alternatively, an administrator can modify the priority to be used. For example, if it is determined that the driver for the chiplet 332 has a bug, the administrator can move the priority to obtaining a key via the chiplet 332 to last.

[0061] In diamond block 406, if the operating system key generation function 310 selects either chiplet 332 or coprocessor 326, processing proceeds to diamond block 408. Otherwise, processing proceeds to block 422 for quantum key generation via remote service 314.

[0062] In diamond block 408, if chiplet 332 is to be used for quantum key generation, processing proceeds to block 410. Otherwise, processing is to be via coprocessor 324 and processing will proceed to block 412.

[0063] In block 410, the quantum key generation request may be forwarded to the modified CPU 330 with chiplet 332, e.g., via CPU crossbar communications channel 334. Upon key generation, processing continues by returning the generated quantum key and continuing in block 414.

[0064] In block 412, the quantum key generation request may be forwarded to the coprocessor 326, e.g., via a direct bus access communications channel 328. Upon key generation, processing continues by returning the generated quantum key and continuing in block 414.

[0065] In block 414, the operating system key generation function 310 receives the generated key and returns the generated key to operating system 308. The operating system 308 receives the generated key in block 416 and returns the generated key to the requesting application 312.

[0066] Finally, in block 416, the application 312 receives the generated key from operating system 308 and operates with the key. Again, from the perspective of application 312, there need be no visibility to how the key was generated and / or that a quantum secure method was used.

[0067] Block 420 is the end of the quantum key generation process.

[0068] Block 422 starts a process to generate a quantum key via a remote quantum key generation server. Because the communication is relatively long lived, the operating system key generation function 310 may implement an event handler to wait for the key to be generated by the remote service 314. For example, operating system key generation function 310 may make functions to call the communications chip either via bus 328 to communications chip 324 or via PCI 322 / 324 on daughterboard 318. Since the communications call is asynchronous, the operating system key generation function 310 may subscribe to an event published by the communications chip 324 that its request has received a response. Semaphores or other notification mechanisms also may be used.

[0069] In block 424, the communications chip 324 handshakes with remote service 314 to ensure connectivity. In some embodiments the handshake may involve a credentials exchange for authentication. If the remote service 314 is a paid service, billing may be mediated at this point as well, by producing an account and / or billing method, as part of sending credentials.

[0070] After handshaking, authentication, and establishing payment (if needed), in block 426, the communications chip 324 may send the request for the quantum key to remote service 314 by invoking a quantum key generation API exposed by remote service 314, for example.

[0071] In block 428, the communications chip 324 may receive the quantum generated key and return the generated key to the operating system key generation function 310. Processing returns to block 414,Virtual Machine and Container Operational Flow to Access a Quantum Key Side Channel for Quantum Secure Servers

[0072] Up to this point, quantum key generation and serving has been described with respect to physical servers 218. However, another scenario is where the application 312 runs on a virtual machine 246 expressed by a hypervisor 244. In this scenario, the operating system 308 which includes operating system key generation function 310 may be modified as described with respect to Figures 3 and 4. Application 312 may run normally and request a key from the operating system 308 as delegated to the operating system key generation function 310. The operating system key generation function 310 may make requests of the hardware where the hardware is exposed in a virtual machine 246 as served by the hypervisor. Because the physical servers 218 are configured with daughterboards and communications chips, coprocessors, and / or chiplets, and are configured with their respective drivers, the hypervisor need not be modified, but need only generate virtual machines that express this hardware. This is similar to a physical server being configured with a GPU that connects to the physical CPU via a PCI bus, or the physical server with a CPU with a chiplet (such as manufactured and distributed by Advanced Micro Devices), where the physical server is used in a server farm disaggregated and virtualized by a hypervisor. In this scenario, the hypervisor is configured to create virtual machines that include virtualizations of thedaughterboard 318 with communications chip 324, coprocessor 326, and / or CPU with a quantum key generation chiplet 332. Where a daughterboard 318 with a communications chip 324 is used, the operating system 308 running on the virtual machine 246, once instantiated will have to be configured to connect to the remote server 314 that performs the quantum key generation.

[0073] Turning to Figure 5, flow chart 500 describes the processing flow for an application 312 to obtain a quantum generated key when running on a virtual machine 246.

[0074] In block 502, a hypervisor 244 preconfigured as described above receives a request for a virtual machine 246. The request is in the form of a configuration file (potentially a YAM L file) specifying at least one of a daughterboard 318 with a communications chip 324, a coprocessor 326, or chiplet 332 configured to perform quantum key generation as described herein. The configuration file may also include a specification of what operating system to use (for example, the modified operating system described with respect to Figures 3 and 4 above) and provisioning information such as administrator accounts and account information to connect (including potentially authentication and payment information) to remote service 314, if remote service 314 is used for quantum key generation. The hypervisor 246, in block 504, then serves a virtual machine to the requestor.

[0075] A virtual machine 246 may be configured with container software to enable it to express a container. If operating system 308 receives a request to create a container, as determined in block 506, the operating system 308 in conjunction with container software may instantiate a container 248.

[0076] In block 508, the virtual machine or container may be configured with application software 312. Application software 312 may be server software such as an application server 238 and / or a database server 240. The application server 238 may be further configured with additional application software for software as a service. Alternatively, the virtual machine may be client software.

[0077] In block 510, the application 312 in the course of running may generate a request for a key and send the generated request to the operating system 308 running on virtual machine 246, either directly or mediated through a container 248.

[0078] In block 512, the operating system 308 running on the virtual machine 246 may retrieve a key as described above with respect to Figure 4. Where the operating system key function 310 makes a call to hardware, the virtual machine 246 (potentially mediated by a container 248 if the application 312 is running in a container) may forward the request to a physical server 218 as disaggregated by the hypervisor 244, where the physical server 218 may delegate the key request to daughterboard 318 with a communications chip 324, to coprocessor 326, or to chiplet 332 to perform quantum key generation as described herein. Upon key generation, the virtual machine 246 may return the generated quantum key to the operating system 308 running on the virtual machine 246 and its respective operating system key generation function 310.

[0079] In block 514, the application 312 may receive the key from the operating system 308 running on the virtual machine 246 and its respective operating system key generation function 310 and continue to run normally.

[0080] Again, note that as long as the operating system 308 on the virtual machine and its operating system key generation function 310 are modified as described with respect to Figures 3 and 4, no modifications are needed of the application 312, hypervisor 244, or container software. The hypervisor 244 need only receive a configuration file for the virtual machine 246 that specifies which hardware is to be used, and where a remote server 314 is used for quantum key generation, that the virtual machine 246 (or container) is configured to connect to the remote server 314 had has any needed authentication and / or payment information.Conclusion

[0081] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

CLAIMSWe claim:1 . A quantum secure server, comprising: a processor and a memory that stores: an operating system, the operating system including drivers for hardware of a quantum side channel and a quantum key generation function configured to be called by other operating system functions that utilize a secure key; and applications that make calls to the operating system for quantum keys obtained by the quantum key generation function from a remote quantum service through a quantum side channel.

2. The quantum secure server of claim 1 , wherein the quantum side channel is secured via traditional key exchange.

3. The quantum secure server of claim 1 , wherein the quantum side channel is secured via a self-sovereign identity technique.

4. The quantum secure server of claim 1 , further comprising: a daughterboard that interfaces with the quantum side channel, which includes a secure communications chip that encodes the quantum side channel.

5. The quantum secure server of claim 4, wherein the secure communications chip is an application specific integrated chip (ASIC) that contains firmware for how communications sessions with the remote quantum service are to be established and managed.

6. The quantum secure server of claim 4, wherein the secure communications chip is configured for automated payments.

7. The quantum secure server of claim 4, wherein the daughterboard delegates communications by calling the secure communications chip for the I / O and network interface.

8. The quantum secure server of claim 1 , wherein the operating system: receives a request to create a container; and instantiates a container configured with the application in response to the request.

9. A quantum secure server, comprising: a processor, a coprocessor, and memory that stores: an operating system having an operating system quantum key generation function; and applications that make calls to the operating system for quantum keys generated by the coprocessor to serve a quantum key.

10. The quantum secure server of claim 9, further comprising a motherboard on which the processor and coprocessor are installed.11 . The quantum secure server of claim 9, wherein the operating system: receives a request to create a container; and instantiates a container configured with the application in response to the request.

12. The quantum secure server of claim 9, wherein the operating system tracks which of the applications made use of the generated quantum keys.

13. The quantum secure server of claim 9, wherein the operating system flags applications that are trusted or secure.

14. The quantum secure server of claim 9, wherein the quantum key generation function is implemented via programmatic objects and object methods exposed via an application programming interface and implemented via invoking a device driver to the coprocessor.

15. A quantum secure server, comprising: a processor having a chiplet added as a module to the processor; andmemory that stores: an operating system having a quantum key generation function; and applications that make calls to the operating system for quantum keys generated by the chiplet.

16. The quantum secure server of claim 15, wherein the quantum key generation function is implemented via programmatic objects and object methods exposed via an application programming interface and implemented via invoking a device driver to the coprocessor.

17. The quantum secure server of claim 15, further comprising a motherboard on which the processor and chiplet are installed.

18. The quantum secure server of claim 15, wherein the operating system tracks which of the applications made use of the generated quantum keys.

19. The quantum secure server of claim 15, wherein the operating system flags applications that are trusted or secure.

20. The quantum secure server of claim 15, wherein the operating system: receives a request to create a container; and instantiates a container configured with the application in response to the request.

Images