Distributed Key Management System

Abstract

A distributed key management system includes a first SCP subsystem, and the first SCP subsystem is coupled to a second SCP subsystem via a network. The first SCP subsystem establishes a secure communication channel with the second SCP subsystem, and a first key management subsystem in the first SCP subsystem retrieves an enabling key for transmission via the secure communication channel from a second key management subsystem in one of the second SCP subsystems and stores the enabling key. The first key management subsystem then receives a first enabling key request from the first SCP subsystem and determines whether the first SCP subsystem is trustworthy. If the first SCP subsystem is trustworthy, the first key management subsystem provides the first SCP subsystem with access to at least one enabling key. If the first SCP subsystem is not trustworthy, the first key management subsystem blocks the first SCP subsystem from accessing the stored at least one enabling key.

Description

BACKGROUND OF THE DISCLOSURE

[0001] The present disclosure generally relates to information handling systems, and more particularly to providing key management for information handling systems in a distributed manner.

[0002] As the value and use of information continue to grow, individuals and businesses seek additional ways to process and store information. One option available to users is an information handling system. An information handling system generally processes, compiles, stores, and / or conveys information or data for business, personal, or other purposes, thereby allowing users to leverage the value of the information. Because technology and information handling requirements and needs vary among different users or applications, information handling systems may also vary in terms of what information is processed, how the information is processed, how much information is processed, stored, or conveyed, and how quickly and efficiently the information can be processed, stored, or conveyed. The variation in information handling systems allows the information handling systems to be general-purpose or configured for a particular user or particular use, such as financial transaction processing, airline ticketing, enterprise data storage, or global communications. Additionally, an information handling system may include a variety of hardware and software components that can be configured to process, store, and convey information, and may include one or more computer systems, data storage systems, and networking systems.

[0003] Information handling systems, such as server devices and / or other computing systems known in the art, can be configured to communicate with and / or access each other via the use of keys (e.g., public / private key pairs). In conventional systems, these keys can be managed by a centralized key management system that provides a secure key repository / database that each server device must access in order to retrieve the keys required for secure communication, and such conventional key management systems typically include multiple redundant key management subsystems in order to provide high availability of the keys stored therein. However, the centralized configuration of such conventional key management systems presents a target for attack to gain unauthorized access to the keys, and requires purely redundant key management subsystems that perform no function other than taking over key management functionality when the primary key management subsystem is unavailable.

[0004] Accordingly, it is desirable to provide a key management system that addresses the problems discussed above. SUMMARY OF THE INVENTION

[0005] According to one embodiment, an information handling system (IHS) includes: a first processing subsystem; a first memory subsystem coupled to the first processing subsystem and including instructions that, when executed by the first processing subsystem, cause the first processing subsystem to provide an enable key utilization engine; a second processing subsystem coupled to the first processing subsystem; a second memory subsystem coupled to the second processing subsystem and including instructions that, when executed by the second processing subsystem, cause the second processing subsystem to provide a key management engine configured to: retrieve at least one enable key from a key management subsystem in one of a plurality of second system control processor (SCP) subsystems for communication with each of the plurality of second SCP subsystems via respective secure communication channels; store the at least one enable key in a key management database coupled to the second processing subsystem; receive a first enable key request from the enable key utilization engine; determine whether the IHS is trusted; in response to receiving the first enable key request and determining that the IHS is trusted, provide the enable key utilization engine access to the at least one enable key stored in the key management database; and in response to receiving the first enable key request and determining that the IHS is not trusted, block the enable key utilization engine from accessing the at least one enable key stored in the key management database. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 is a schematic diagram showing an embodiment of an information handling system (IHS).

[0007] Figure 2 is a schematic diagram showing an embodiment of a networking system.

[0008] Figure 3A is a schematic diagram showing an embodiment of a computing system that can be included in a Figure 2 networking system and can utilize the distributed key management system of the present disclosure.

[0009] Figure 3B is a schematic diagram showing an embodiment of a computing system that can be included in a Figure 2 networking system and can utilize the distributed key management system of the present disclosure.

[0010] Figure 4 is a schematic diagram showing an embodiment of a computing system that can be included in a Figure 3A or Figure 3B computing device and can provide an SCP subsystem of the distributed key management system of the present disclosure.

[0011] Figure 5is a flowchart showing an implementation of a method for providing distributed key management.

[0012] Figure 6A is showing Figure 2 a schematic diagram of an implementation of a networking system in which the computing system 300 of FIG. 3 has Figure 4 the SCP subsystem of Figure 5 and operates during the method of

[0013] Figure 6B is showing Figure 2 a schematic diagram of an implementation of a networking system in which the computing system 300 of FIG. 3 has Figure 4 the SCP subsystem of Figure 5 and operates during the method of

[0014] Figure 6C is showing Figure 2 a schematic diagram of an implementation of a networking system in which the computing system 300 of FIG. 3 has Figure 4 the SCP subsystem of Figure 5 and operates during the method of

[0015] Figure 6D is showing Figure 2 a schematic diagram of an implementation of a networking system in which the computing system 300 of FIG. 3 has Figure 4 the SCP subsystem of Figure 5 and operates during the method of

[0016] Figure 7 is showing Figure 2 a schematic diagram of an implementation of a networking system in which the computing system 300 of FIG. 3 has Figure 4 the SCP subsystem of Figure 5 and operates during the method of

[0017] Figure 8A is showing a schematic diagram of an implementation of a computing system that operates during the method of Figure 5 of Figure 3A

[0018] Figure 8B is showing a schematic diagram of an implementation of an SCP subsystem that operates during the method of Figure 5 of Figure 4

[0019] Figure 9 is showing a schematic diagram of an implementation of an SCP subsystem that operates during the method of Figure 5 of Figure 4

[0020] Figure 10A is showing during the method of Figure 5 ​​​operated during the method of Figure 4 Schematic diagram of an embodiment of the SCP subsystem.

[0021] Figure 10B shows Figure 2 Schematic diagram of an embodiment of the networking system, where the computing system 300 of FIG. 3 has Figure 4 the SCP subsystem and operates during the Figure 5 method.

[0022] Figure 11 shows a communication channel provided according to the Figure 5 method. DETAILED DESCRIPTION

[0023] For the purposes of this disclosure, an information handling system may include any instrumentality or aggregate of instrumentalities operable to compute, calculate, determine, classify, process, transmit, receive, retrieve, originate, switch, store, display, communicate, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an information handling system may be a personal computer (e.g., desktop or laptop computer), a tablet computer, a mobile device (e.g., personal digital assistant (PDA) or smartphone), a server (e.g., blade server or rack server), a network storage device, or any other suitable device, and may vary in size, shape, performance, functionality, and price. An information handling system may include random access memory (RAM), one or more processing resources (such as a central processing unit (CPU) or hardware or software control logic), ROM, and / or other types of non-volatile memory. Additional components of the information processing system may include one or more disk drives, one or more network ports for communicating with external devices, and various input and output (I / O) devices (such as a keyboard, mouse, touch screen, and / or video display). The information handling system may also include one or more buses operable to transfer communications between the various hardware components.

[0024] In one embodiment, the IHS 100 ( Figure 1) includes a processor 102, which is connected to a bus 104. The bus 104 serves as a connection between the processor 102 and other components of the IHS 100. An input device 106 is coupled to the processor 102 to provide inputs to the processor 102. Examples of input devices can include a keyboard, a touch screen, pointing devices (such as a mouse, a trackball, and a touchpad), and / or various other input devices known in the art. Programs and data are stored on a mass storage device 108, which is coupled to the processor 102. Examples of mass storage devices can include a hard disk, an optical disk, a magneto-optical disk, a solid-state storage device, and / or various other mass storage devices known in the art. The IHS 100 also includes a display 110, which is coupled to the processor 102 through a video controller 112. A system memory 114 is coupled to the processor 102 to provide fast storage to the processor to facilitate the execution of computer programs by the processor 102. Examples of system memory can include random access memory (RAM) devices, such as dynamic RAM (DRAM), synchronous DRAM (SDRAM), solid-state memory devices, and / or various other memory devices known in the art. In an embodiment, a chassis 116 houses some or all of the components of the IHS 100. It should be understood that other buses and intermediate circuits can be deployed between the above components and the processor 102 to facilitate the interconnection between the components and the processor 102.

[0025] Now referring to Figure 2 , an embodiment of a networked system 200 in which the distributed key management system of the present disclosure can be utilized is shown. In the illustrated embodiment, the networked system 200 includes a plurality of computing systems 202a, 202b, up to 202c. In an embodiment, the computing systems 202a to 202c can be provided by the IHS 100 discussed above with reference to Figure 1 , and / or can include some or all of the components of the IHS 100, and in a particular example can be provided by a server device. However, although discussed as being provided by a server device, those skilled in the art who master the present disclosure will recognize that the computing systems provided in the networked system 200 can include any computing systems that can be configured to operate similarly to the computing systems 202a to 202c discussed below. In the illustrated embodiment, each of the computing systems can be coupled to a network 204, which can be provided by a local area network (LAN), the Internet, a combination thereof, and / or any other network that will be apparent to those skilled in the art who master the present disclosure.

[0026] In the illustrated embodiment, a management system 206 is also coupled to the network 204. In an embodiment, the management system 206 can be provided by the one discussed above with reference to Figure 1The discussed IHS 100 provides, and / or may include some or all components of the IHS 100, and in a particular example may be provided by one or more management server devices that may be configured to perform management functionality for the computing systems 202a - 202c (e.g., an SCP manager for an SCP subsystem included in the computing systems 202a - 202c discussed below). In the illustrated embodiment, one or more network - attached devices 208 are also coupled to the network 204. In an embodiment, the network - attached devices 208 may be provided by a variety of different network - attached devices accessible to the computing systems 202a - 202c via the network 204, and in a particular example may be provided by one or more non - volatile memory express (NVMe) storage devices that may be configured to provide network - attached storage systems to any or all of the computing systems 202a - 202c. However, while a particular networking system 200 has been shown and described, those skilled in the art having the benefit of this disclosure will recognize that the distributed key management system of this disclosure may be utilized with a variety of components and component configurations, and / or may be provided in a variety of computing system / network configurations while remaining within the scope of this disclosure.

[0027] Now referring to Figure 3A , an embodiment of a computing system 300 is shown that may provide any or all of the computing systems 202a - 202c discussed above with reference to Figure 2 . Thus, the computing system 300 may be provided by the IHS 100 discussed above with reference to Figure 1 , and / or may include some or all components of the IHS 100, and in a particular example may be provided by a server device. Additionally, while shown and discussed as being provided by a server device, those skilled in the art having the benefit of this disclosure will recognize that the functionality of the computing system 300 discussed below may be provided by other computing systems configured to operate similarly to the computing system 300 discussed below. In the illustrated embodiment, the computing system 300 includes a chassis 302 that houses the components of the computing system 300, only some of which are shown below.

[0028] For example, the chassis 302 may house a system control processor (SCP) subsystem 304 provided in accordance with the teachings of the present disclosure to perform distributed key management functionality discussed in further detail below. In some examples, the SCP subsystem 304 may be conceptualized as an “enhanced” SmartNIC device that may be configured to perform functionality not available in a conventional SmartNIC device, such as, for example, the root of trust for platform functionality described by the inventors of the present disclosure in U.S. Patent Application No. 17 / 027,835, filed on September 22, 2020 (Attorney Docket No. 16356.2212US01), and the secure communication functionality described by the inventors of the present disclosure in U.S. Patent Application No. 17 / 079,737, filed on October 26, 2020 (Attorney Docket No. 16356.2217US01), the disclosures of these patent applications being incorporated herein by reference in their entireties. However, while shown and described as an enhanced SmartNIC device provided by the SCP subsystem, those skilled in the art having the benefit of the present disclosure will understand that the SCP subsystem 304 may be replaced with various other subsystems configured to perform the functionality discussed below while remaining within the scope of the present disclosure.

[0029] In an implementation, the SCP subsystem 304 may be provided by the IHS 100 discussed above with reference to Figure 1 and / or may include some or all components of the IHS 100. In a particular example, the SCP subsystem 304 may be provided as an SCP card configured to connect to a slot on a motherboard within the chassis 302. In other examples, the SCP subsystem 304 may be integrated into the motherboard within the chassis 302. In yet other examples, the SCP subsystem 304 may be a separate / co-motherboard circuit board connected to the motherboard within the chassis 302 (e.g., a two-part motherboard having a first part that implements conventional motherboard functionality and a second part that implements the SCP functionality discussed below). However, while several specific examples are provided, those skilled in the art having the benefit of the present disclosure will understand that the SCP subsystem 304 may be provided in the computing system 300 in a variety of ways that will fall within the scope of the present disclosure.

[0030] The chassis 302 may also house a central processing subsystem 306 that is coupled (e.g., via a Compute Express Link (CxL)) to the SCP subsystem 304 and may include the above reference to Figure 1The processor 102 under discussion, a central processing unit (CPU) such as an x86 host processor, a CPU memory such as an x86 host processor memory, and / or various other processing components that will be apparent to those skilled in the art of the present disclosure. The chassis 302 may also house a graphics processing subsystem 307, which is coupled to the SCP subsystem 304 and may include the processor 102 under discussion above, a graphics processing unit (GPU), a GPU memory, and / or various other processing components that will be apparent to those skilled in the art of the present disclosure. As will be understood by those skilled in the art of the present disclosure, in the example shown below, the graphics processing subsystem 307 is connected to the central processing subsystem 306 via the SCP subsystem 304, such that the SCP subsystem 304 acts as the "host" of the graphics processing subsystem 307, but other central processing subsystem / graphics processing subsystem configurations will also fall within the scope of the present disclosure. Figure 1 The processor 102 under discussion, a graphics processing unit (GPU), a GPU memory, and / or various other processing components that will be apparent to those skilled in the art of the present disclosure. As will be understood by those skilled in the art of the present disclosure, in the example shown below, the graphics processing subsystem 307 is connected to the central processing subsystem 306 via the SCP subsystem 304, such that the SCP subsystem 304 acts as the "host" of the graphics processing subsystem 307, but other central processing subsystem / graphics processing subsystem configurations will also fall within the scope of the present disclosure.

[0031] The chassis 302 may also house a basic input / output system (BIOS) subsystem 308, which is coupled to the SCP subsystem 304 and the central processing system 306, and those skilled in the art of the present disclosure will recognize that the BIOS subsystem is provided by firmware that is configured to perform hardware initialization of the computing system 300 during a boot process (e.g., a power-on startup operation) or other initialization processes known in the art, as well as perform runtime services for the operating system and / or other application programs / programs provided by the computing system 300. Additionally, although described as a BIOS subsystem, those skilled in the art of the present disclosure will recognize that the BIOS subsystem 308 may be replaced by a Unified Extensible Firmware Interface (UEFI) subsystem, which those skilled in the art of the present disclosure will recognize defines a software interface between the operating system and the firmware in the computing system 300 and is provided to replace the BIOS subsystem (while supporting legacy BIOS services).

[0032] In the illustrated embodiment, the chassis 302 may also house a boot storage device 308a, which is coupled to the SCP subsystem 304 and the BIOS subsystem 308, and those skilled in the art of the present disclosure will recognize that the boot storage device may store a boot image that the BIOS subsystem 308 may access and use during a boot operation. For example, the boot storage device 308a may be purchased from The company's Boot Optimized Storage Solution (BOSS) is provided, but other boot storage devices will also fall within the scope of the present disclosure. In the illustrated embodiment, chassis 302 may also house a Baseboard Management Controller (BMC) subsystem 310, which is coupled to SCP subsystem 304 and central processing subsystem 306 (e.g., via a Peripheral Component Interconnect Express (PCIe) link), and those skilled in the art of the present disclosure will recognize that the BMC subsystem is configured to manage the interface between system management software in computing system 300 and the hardware in computing system 300, and perform other BMC operations that will be apparent to those skilled in the art of the present disclosure.

[0033] Chassis 302 may also house (or provide coupling for) one or more input / output (I / O) devices 312, which are coupled to SCP subsystem 304. Thus, those skilled in the art of the present disclosure will recognize that I / O device 312 may be housed within chassis 302 and connected to an internal connector (e.g., on the motherboard within chassis 302), or may be provided external to chassis 302 and connected to an external connector (e.g., on the outer surface of chassis 302). As Figure 3A shown, I / O device 312 may include one or more Peripheral Component Interconnect Express (PCIe) devices 312a (either as I / O device 312 or as a supplement to other I / O devices). For example, PCIe device 312a may include an NVMe storage device, which is housed within chassis 302 (i.e., and connected to an internal connector on the motherboard within chassis 302), or external to chassis 302 (i.e., and connected to an external connector on the outer surface of chassis 302). However, while specific I / O devices and / or PCI devices have been described, those skilled in the art of the present disclosure will recognize that various other I / O devices will also fall within the scope of the present disclosure. Chassis 302 may also house one or more Field Programmable Gate Array (FPGA) devices 313, which are coupled to SCP subsystem 304, and as discussed below, may be programmed to perform any of a variety of functions for computing system 300 and / or SCP subsystem 304.

[0034] The chassis 302 can also house one or more first components 314 coupled to each of the BIOS subsystem 308 and the BMC subsystem 310, and one or more second components 316 coupled to at least one of the first components 314. In a particular example, the first components 314 and the second components 316 can include complex programmable logic devices (CPLDs), power systems, and / or various other components of various computing systems known in the art. However, while a particular computing system 300 has been shown, those skilled in the art having the benefit of this disclosure will recognize that a computing system (or other device operating in a manner similar to that described below for the computing system 300 in accordance with the teachings of this disclosure) can include a variety of components and / or component configurations for providing conventional computing system functionality as well as the functionality discussed below, while remaining within the scope of this disclosure. For example, Figure 3B An embodiment of the computing system 300 is shown, where the BMC subsystem 310 referenced above Figure 3A is omitted, and the SCP subsystem 304 is configured to provide a BMC subsystem 304a that performs the Figure 3A functionality of the BMC subsystem 310 in

[0035] Now referring to Figure 4 , an embodiment of the SCP subsystem 400 is shown, which can provide the SCP subsystem 304 discussed above with reference to Figure 3A and Figure 3B . Thus, the SCP subsystem 400 can be provided by the IHS 100 discussed above with reference to Figure 1 and / or can include some or all of the components of the IHS 100, and in a particular example can be provided as an SCP card, integrated into a motherboard, or provided as a separate / coprocessor board. However, while shown and discussed as being provided in the computing system 400 in different ways, those skilled in the art having the benefit of this disclosure will recognize that the functionality of the SCP subsystem 400 discussed below can be provided by other devices configured to operate similarly to the SCP subsystem 400 discussed below.

[0036] In the illustrated embodiment, the SCP subsystem 400 includes a chassis 402 (e.g., a circuit board) that supports the components of the SCP subsystem 400, only some of which are shown below. For example, the chassis 302 can support: an SCP processing subsystem that includes one or more SCP processors (not shown, but can include the processor 102 discussed above with reference to Figure 1 ); and an SCP memory subsystem (not shown, but can include the memory discussed above with reference to Figure 1The memory 114 discussed, the SCP memory subsystem is coupled to the SCP processing subsystem and includes instructions that, when executed by the SCP processing subsystem, cause the SCP processing subsystem to provide the SCP engine 404, which is configured to perform the functionality of the SCP engine and / or the SCP subsystem discussed below. In a particular example, the SCP processing subsystem that provides the SCP engine 404 can be provided by an ARM processor core in an ARM-based processor, but other processing systems will also fall within the scope of the present disclosure.

[0037] In addition, the chassis 302 can support: a key management subsystem 410, which can include a key management processing subsystem that includes one or more key management processors (not shown, but can include the processor 102 discussed above with reference to Figure 1 the discussion); and a key management memory subsystem (not shown, but can include the memory 114 discussed above with reference to Figure 1 the discussion), the key management memory subsystem is coupled to the key management processing subsystem and includes instructions that, when executed by the key management processing subsystem, cause the key management processing subsystem to provide a key management engine 410a, which is configured to perform the functionality of the key management engine and / or the key management subsystem discussed below.

[0038] As will be understood by those skilled in the art of the present disclosure, in some embodiments, separate and distinct processing subsystems for providing the SCP engine 404 and the key management engine 410a can be provided by different processing systems or in other embodiments by the same processing system (e.g., separate and distinct processor cores). Thus, the SCP subsystem 400 can include multiple processing subsystems (e.g., a first processing subsystem and a second processing subsystem) that respectively provide a key utilization engine and a key management engine, operating independently and / or otherwise acting in a manner discussed in further detail below. In a particular example, the key management engine 410a can provide an application programming interface (API) that can only be used by the SCP engine 404 to interact with the key management engine 410a in the manner described below, but other techniques for providing the SCP engine / key management engine communication / interaction discussed below will also fall within the scope of the present disclosure.

[0039] The chassis 302 can also support an SCP storage subsystem (not shown, but can include the one discussed above with reference to Figure 1the storage device 108 discussed above, the SCP memory system discussed above, etc.), the SCP storage subsystem (e.g., via the coupling between the SCP storage subsystem and the SCP processing subsystem) is coupled to the SCP engine 404 and may include an SCP database 406, which may store any information utilized by the SCP engine 404 as discussed below. The chassis 302 may also support a key management storage subsystem (not shown, but may include the storage device 108 discussed above with reference to Figure 1 the storage device 108 discussed above), the key management storage subsystem (e.g., via the coupling between the key management storage subsystem and the key management processing subsystem) is coupled to the key management engine 410a and may include a key management database 410b, which is included in the key management subsystem 410 and may store any information utilized by the key management engine 410a as discussed below. For example, the key management database 410b may provide a secure key repository for storing the enabling keys described in further detail below.

[0040] As understood by those skilled in the art of the present disclosure, in some embodiments, separate and distinct storage subsystems for providing the SCP database 406 and the key management database 410b may be provided by different storage systems or in other embodiments by the same storage system (e.g., separate and distinct storage areas). Thus, the SCP subsystem 400 may include multiple storage subsystems (e.g., a first storage subsystem and a second storage subsystem), which respectively provide a key utilization database and a key management database, and may be independently and securely accessed separately and / or otherwise operate in a manner discussed in further detail below.

[0041] The chassis 402 may also support: a communication system 408, which (e.g., via the coupling between the communication system 408 and the SCP processing subsystem) is coupled to the SCP engine 404 and in the illustrated embodiment, includes a network interface controller (NIC) subsystem 408a (e.g., an Ethernet subsystem), which is configured to connect the SCP subsystem 400 to the network 204 discussed above with reference to Figure 2 discussed above; a component connection subsystem 408b, which is configured to couple the SCP subsystem 400 to any one of the components included in Figure 3A and Figure 3B the computing system 300 and / or to any other communication components (e.g., a wireless communication system (e.g., near field communication (NFC) components, WiFi components, etc.)) that are obvious to those skilled in the art of the present disclosure.

[0042] Thus, communication system 408 can include any connection between SCP subsystem 400 and network 204, central processing subsystem 306, graphics processing subsystem 307, BIOS subsystem 308, boot storage device 308a, BMC subsystem 310, I / O device 312, FPGA device 313, and / or any other components utilized with computing system 202a / 300. For example, component connection subsystem 408b can include a CxL Root.mem / .cache subsystem coupled to central processing subsystem 306, an out-of-band (OOB) management subsystem coupled to BMC subsystem 310, and a CxL host subsystem coupled to components in computing system 300. However, while a particular SCP subsystem 400 has been shown and described, those skilled in the art having the benefit of this disclosure will recognize that an SCP subsystem (or other device operating in a manner similar to that described below for SCP subsystem 400 in accordance with the teachings of this disclosure) can include various components (e.g., local memory, embedded FPGA device, fast non-volatile memory (NVMe) emulation subsystem between SCP clone engine 404 and CxL Root.mem / .cache subsystem, etc.) and / or component configurations for providing the functionality discussed below while also being within the scope of this disclosure.

[0043] Now refer to Figure 5, which shows an implementation of a method 500 for providing distributed key management. As discussed below, implementations of the systems and methods of the present disclosure may utilize an SCP subsystem that provides a root of trust for its computing systems and also operates to establish distributed secure communication channels with each other to provide a secure SCP communication fabric in order to provide a distributed, immutable key management system for use by SCP subsystems when transmitting via the secure SCP communication fabric. For example, the distributed key management system of the present disclosure includes a first SCP subsystem coupled to a second SCP subsystem via a network. The first SCP subsystem establishes a secure communication channel with the second SCP subsystem, and a first key management subsystem in the first SCP subsystem retrieves an enabling key for transmission via the secure communication channel from a second key management subsystem in one of the second SCP subsystems and stores the enabling key. The first key management subsystem then receives a first enabling key request from the first SCP subsystem and determines whether the first SCP subsystem is trustworthy. If the first SCP subsystem is trustworthy, the first key management subsystem provides the first SCP subsystem access to at least one enabling key. If the first SCP subsystem is not trustworthy, the first key management subsystem blocks the first SCP subsystem from accessing the stored at least one enabling key. Thus, decentralized, distributed key management is achieved, which uses an SCP subsystem that operates to provide various other functionalities and is thus not a purely redundant subsystem as utilized in conventional key management subsystems to provide key management redundancy.

[0044] Method 500 begins at block 502, where a first SCP subsystem in a first computing system authenticates a first computing device in the first computing system that includes the first SCP subsystem. Refer to Figure 6A , in an implementation of block 502, any of the SCP subsystems 304 in computing systems 202a / 300, 202b / 300, and / or 202c / 300 may operate to authenticate a computing device in its corresponding computing system. For example, the SCP engine 404 in each of the SCP subsystems 304 / 400 in computing systems 202a through 202c / 300 may be configured at block 502 to perform the root of trust functionality described in U.S. Patent Application No. 17 / 027,835, filed on September 22, 2020 (Attorney Docket No. 16356.2212US01) by the inventors of the present disclosure, the disclosure of which is incorporated herein by reference in its entirety.

[0045] Thus, as described in the present application, each SCP subsystem can initialize and verify its SCP subsystem initialization information (e.g., SCP boot image) as part of its SCP initialization operation, use the verified SCP subsystem initialization information to complete its SCP initialization operation, verify the BIOS subsystem initialization information (e.g., BIOS boot image) of the BIOS subsystem in its computing system such that the BIOS subsystem can utilize the BIOS subsystem initialization information to complete the BIOS subsystem initialization operation, verify the BMC subsystem initialization information (e.g., BMC boot image) of the BMC subsystem in its computing system such that the BMC subsystem can utilize the BMC subsystem initialization information to complete the BMC subsystem initialization operation, and / or verify the I / O device initialization information (e.g., I / O boot image) of the I / O devices in its computing system such that the I / O devices can utilize the I / O device initialization information to complete the I / O device initialization operation. Thus, as described in the present application, the SCP subsystem in each computing system can ensure the verified operation of each of the subsystems / devices / components included in its computing system.

[0046] In addition, as also described in the present application, the "trust chain" between any SCP subsystem and the systems / devices / components directly connected to that SCP subsystem included in its computing system can be extended to the systems / devices / components indirectly coupled to that SCP subsystem included in its computing system. For example, any verified subsystem / device / component directly connected to the SCP subsystem in a computing system can operate to ensure the verified operation of each of the subsystems / devices / components in that computing system to which it is directly connected, such that the systems / devices / components indirectly connected to the SCP subsystem are also verified. Further, a verified system / device / component indirectly connected to the SCP subsystem in any computing system can operate to ensure the verified operation of each of the subsystems / devices / components in its computing system to which it is directly connected, and so on. Thus, a "trust chain" can be provided between the SCP subsystem and each subsystem / device / component in its computing system. As also discussed in the present application, the SCP subsystem in any computing system can also operate to verify the firmware updates of the subsystems / devices / components in its computing system, resulting in erasure of portions of the non-volatile storage subsystem in its computing system, and / or perform any other functionality described in the present application during method 500.

[0047] In an embodiment of block 502, authentication of any SCP subsystem and subsystem / device / component in any computing system may also allow a key management subsystem in the computing system to authenticate the SCP subsystem. For example, at block 502, a key management engine 410a included in a key management subsystem 410 in computing system 202a / 400, 202b / 400, and / or 202c / 300 may determine that an SCP subsystem in the computing system is authenticated and, in response, may generate key repository access keys (e.g., a public / private key pair and / or other keys known in the art) and provide those key repository access keys to the SCP subsystem. In certain embodiments, the key repository access keys may provide full access to any key repository with which they are associated, or may be configured to enable different access capabilities to the SCP subsystem to which they are provided. Thus, in some embodiments, one or more key repository access keys may be provided that enable key repository access to their corresponding key repository / database by each SCP subsystem in the networked system 200, or unique key repository access keys may be provided to different SCP subsystems in the networked system 200 to enable different levels of access to their corresponding key stores / databases (e.g., via different enablement keys).

[0048] The method 500 then proceeds to block 504, where the first SCP subsystem establishes a secure communication channel with the second SCP subsystem. Figure 6B , Figure 6C and Figure 6D In an embodiment of block 504, the SCP subsystems 304 in the computing systems 202a / 300, 202b / 300, and / or 202c / 300 may be operable to establish secure communication channels 600, 602, and 604 with each other. For example, the SCP engine 404 in each of the SCP subsystems 304 / 400 in the computing systems 202a-202c / 300 may be configured at block 504 to perform secure communication functionality as described in U.S. Patent Application No. 17 / 079,737 (Attorney Docket No. 16356.2217US01), filed on October 26, 2020 by the inventors of the present disclosure, the disclosure of which is incorporated herein by reference in its entirety.

[0049] Thus, as described in the present application, the SCP subsystem 304 in the computing system 202b / 300 can identify the SCP subsystem 304 in the computing system 202a / 300, sign the second SCP authentication communication with the second private key, and transmit the second signed SCP authentication communication to the SCP subsystem 304 in the computing system 202a / 300, while the SCP subsystem 304 in the computing system 202a / 300 signs the first SCP authentication communication with the first private key and transmits the first signed SCP authentication communication to the SCP subsystem 304 in the computing system 202b / 300. The SCP subsystem 304 in the computing system 202b / 300 can then use the first public key to authenticate the first SCP authentication communication, the SCP subsystem 304 in the computing system 202a / 300 can use the second public key to authenticate the second SCP authentication communication, and in response, the SCP subsystems 304 in the computing systems 202a / 300 and 202b / 300 will establish a secure communication channel 600, as Figure 6B shown.

[0050] Again, as described in the present application, the SCP subsystem 304 in the computing system 202b / 300 can then identify the SCP subsystem 304 in the computing system 202c / 300, sign the second SCP authentication communication with the second private key, and transmit the second signed SCP authentication communication to the SCP subsystem 304 in the computing system 202c / 300, while the SCP subsystem 304 in the computing system 202c / 300 signs the third SCP authentication communication with the third private key and transmits the third signed SCP authentication communication to the SCP subsystem 304 in the computing system 202b / 300. The SCP subsystem 304 in the computing system 202b / 300 can then use the third public key to authenticate the third SCP authentication communication, the SCP subsystem 304 in the computing system 202c / 300 can use the second public key to authenticate the second SCP authentication communication, and in response, the SCP subsystems 304 in the computing systems 202b / 300 and 202c / 300 will establish a secure communication channel 602, as Figure 6C shown.

[0051] Again, as described in the present application, the SCP subsystem 304 in the computing system 202b / 300 can then prove the authentication of the SCP subsystem 304 in the computing system 202c / 300 to the SCP subsystem 304 in the computing system 202a / 300, and prove the authentication of the SCP subsystem 304 in the computing system 202a / 300 to the SCP subsystem 304 in the computing system 202c / 300, which allows the SCP subsystems 304 in the computing systems 202a / 300 and 202c / 300 to establish a secure communication channel 604( Figure 6Dshown) without transmitting signed SCP authentication communications. As discussed below, after block 504, the enabling keys controlled by the distributed key management system of the present disclosure may provide for the use of the secure communication channels 600, 602, and 604 in each of the SCP subsystems 304 in the computing systems 202a / 300, 202b / 300, and 202c / 300 to securely exchange communications, and the continuous execution of the platform trust root functionality discussed above by these SCP subsystems will ensure that secure communication channels are maintained only with trusted SCP subsystems and / or computing systems.

[0052] Method 500 then proceeds to block 506, where the first key management subsystem in the first SCP subsystem retrieves one or more enabling keys and stores them in the first key management subsystem. In a specific example discussed below, at or before block 506, the key management subsystem 410 in the SCP subsystem 400 in the computing system 202b / 300 may be designated (e.g., by the management system 206) as the "global key manager" of the distributed key management system of the present disclosure, and those skilled in the art of the present disclosure will understand that multiple different key management subsystems in SCP subsystems included in different computing systems may be designated as global key managers for redundancy considerations. Thus, a subset of the SCP subsystems included in the networked system 200 may be designated as global key managers, while the remaining subset of SCP subsystems may not perform global key manager functionality.

[0053] Thus, referring to Figure 7 and at block 506, a key management engine 410a in the key management subsystem 410 in the SCP subsystem 304 / 400 included in the computing system 202b / 300 may perform an enabling key retrieval operation 700 to retrieve one or more enabling keys (e.g., a public / private key pair for implementing secure communication channel operations as discussed below and other enabling keys known in the art) from the management system 206 (e.g., the SCP manager) via the network and its communication system 408, and securely store those enabling keys in its key management database 410b. However, while the enabling keys are shown and described as being retrieved from the management system 206, those skilled in the art of the present disclosure will understand that the enabling keys of the present disclosure may be retrieved from other locations (e.g., other key management subsystems in other SCP subsystems, network-attached storage systems provided by the network-attached device 208), which is also within the scope of the present disclosure. Additionally, in some examples, the enabling keys may be generated and / or otherwise created by the key management subsystem (i.e., rather than retrieving those enabling keys from a network-accessible management system).

[0054] Thus, in some embodiments, a key management subsystem in a subset of the SCP subsystems in the networking system 200 can act as a global key manager that operates to retrieve enabling keys from a network-accessible management system, securely store those enabling keys for use by the SCP subsystem when leveraging secure communication channels 600, 602, and / or 604, and in some cases distribute those enabling keys to key management subsystems in other SCP subsystems in the networking system 200 (e.g., key management subsystems in SCP subsystems that do not act as the global key manager). As will be understood by those skilled in the art having the benefit of this disclosure, retrieving and storing the enabling keys by the SCP subsystem at block 506 can be performed at any time during method 500.

[0055] Thus, as part of establishing secure communication channels 600, 602, and 604 at block 504, a key management subsystem in an SCP subsystem designated as the global key manager can transmit an enabling key to a key management subsystem in an SCP subsystem not designated as the global key manager. For example, the key management subsystem 410 in the SCP subsystem 304 included in the computing system 202b / 300 can act as the global key manager, while the key management subsystems 410 in the SCP subsystems 304 included in the computing systems 202a / 300 and 202c / 300 do not act as the global key manager. Thus, after block 506, the key management subsystem 410 in the SCP subsystem 304 included in the computing system 202b / 300 can securely transmit the enabling key retrieved at block 506 to the key management subsystems 410 in the SCP subsystems 304 included in the computing systems 202a / 300 and 202c / 300 (i.e., for storage in their respective key management databases 410b) via the secure communication channels 600 and 602. Additionally, those skilled in the art having the benefit of this disclosure will understand how the enabling key management model can be performed by the key management subsystem acting as the global key manager and can be used to determine which SCP subsystems can receive which enabling keys, what access a particular enabling key provides, etc. Thus, after block 506, each of the key management subsystems 410 in the SCP subsystems 304 in the computing systems 202a / 300, 202b / 300, and 202c / 300 can store an enabling key configured to permit that SCP subsystem to communicate via one or more of the secure communication channels 600, 602, and / or 604.

[0056] Method 500 then proceeds to decision block 508, where it is determined whether an enable key request has been received. In one implementation, at block 508, a key management engine 410a in a key management subsystem 410 in any of the SCP subsystems 304 in computing systems 202a - 202c / 300 can operate at decision block 508 to monitor requests for an enable key from the SCP engine 404 in that SCP subsystem 304 / 400. Thus, while the following examples illustrate and describe an enable key request associated with the SCP subsystem 304 in computing system 202b / 300, those skilled in the art having the benefit of this disclosure will understand that an enable key request can be provided in an SCP subsystem in any computing system in a manner similar to that described below. If at decision block 508 it is determined that an enable key request has not been received, method 500 returns to decision block 508. Thus, method 500 can loop such that a key management subsystem 410 in any of the SCP subsystems 304 in computing systems 202a - 202c / 300 monitors requests for an enable key from the SCP engine 404 in that SCP subsystem 304 / 400, provided that an enable key request has not been received.

[0057] If at decision block 508 it is determined that an enable key request has been received, method 500 proceeds to decision block 510, where it is determined whether the first SCP subsystem is trusted. Refer to Figure 8A and Figure 8B , in the implementation of decision block 508, an application provided by the central processing subsystem 306 in computing system 202b / 300 can use the SCP engine 404 in the SCP subsystem 304 / 400 in computing system 202b / 300 to perform application operations 800, and the SCP engine 404 can determine that those application operations 800 need to be transmitted via secure communication channels 600 and / or 602 in order to, for example, implement some application functionality of the application provided by the central processing subsystem 306 in computing system 202b / 300. In response to determining that application operations 800 need to be transmitted via secure communication channels 600 and / or 602, the SCP engine 404 in the SCP subsystem 304 / 400 in computing system 202b / 300 can perform an enable key request operation 802, which includes generating an enable key request and transmitting it to a key management engine 410a in a key management subsystem 410 included in the SCP subsystem 304 / 400 in computing system 202b / 400. However, while a specific example of a scenario in which an enable key request is provided (e.g., to implement application functionality) has been illustrated and described, those skilled in the art having the benefit of this disclosure will recognize that various scenarios that result in the transmission of an enable key request will also fall within the scope of this disclosure.

[0058] Thus, at decision block 508, a key management engine 410a in a key management subsystem 410, which is included in the SCP subsystem 304 / 400 in the computing system 202b / 400, can receive an enable key request and, in response, will operate at decision block 510 to determine whether the SCP subsystem 400 is trusted. For example, at decision block 510, a key management engine 410a in a key management subsystem 410, which is included in the SCP subsystem 304 / 400 in the computing system 202b / 300, can operate to perform any of the root-of-trust-for-the-platform operations described in U.S. Patent Application No. 17 / 027,835, filed on September 22, 2020, by the inventors of the present disclosure (Attorney Docket No. 16356.2212US01) (the disclosure of this patent application is incorporated herein by reference in its entirety) to determine whether the SCP subsystem 304 / 400 in the computing system 202b / 300 is trusted and / or whether the computing system 202b / 300 is trusted.

[0059] In some embodiments, the trust determination performed on the SCP subsystem 304 / 400 and / or its computing system 202b / 300 at decision block 510 can be performed in response to receiving an enable key request at decision block 508 and thus may require performing any of the authentication, verification, and / or other trust determination operations described above. However, in other embodiments, the trust determination performed on the SCP subsystem 304 / 400 and / or its computing system 202b / 300 at decision block 510 can be performed periodically during method 500 as part of the above-described root-of-trust-for-the-platform operations, and thus the trust determination performed on the SCP subsystem 304 / 400 and / or its computing system 202b / 300 at decision block 510 may only need to determine whether the most recent root-of-trust-for-the-platform operation indicates that the SCP subsystem 304 / 400 and / or its computing system 202b / 300 is currently trusted. Additionally, those skilled in the art of the present disclosure will recognize that in the case where the periodic root-of-trust-for-the-platform operation determines that the SCP subsystem (or its computing system) is not trusted, performing the periodic root-of-trust-for-the-platform operation allows any SCP subsystem to be blocked from accessing the enable key. Thus, while specific examples have been provided, those skilled in the art of the present disclosure will understand that the determination of whether the SCP subsystem and / or its computing system is trusted can be performed in a variety of ways that will also fall within the scope of the present disclosure.

[0060] If, at decision block 510, it is determined that the first SCP subsystem is trusted, then method 500 proceeds to block 512, where the first key management subsystem provides the first SCP subsystem with access to the enable key. Refer to Figure 9, in an implementation of block 512 and in response to receiving an enable key request at decision block 508 and determining at block 510 that the enable key request was received from a trusted SCP subsystem, the key management engine 410a in the key management subsystem 410 in the SCP subsystem 304 / 400 in the computing system 202b / 400 may perform an enable key provision operation 900 to provide the SCP engine 404 in the SCP subsystem 304 / 400 in the computing system 202b / 400 access to those enable keys by, for example, retrieving an enable key from its key management database 410b and transmitting the enable key to the SCP engine 404. Additionally, in some examples, the key management subsystem in any SCP subsystem may add any trusted verified SCP subsystem to a trusted SCP matrix that may be synchronized with other key management subsystems in other SCP subsystems in order to distribute knowledge of the trusted SCP subsystems across the networked system 200.

[0061] As will be understood by those skilled in the art having the benefit of this disclosure and as Figure 10A and Figure 10B shown, the SCP engine 404 in the SCP subsystem 304 / 400 in the computing system 202b / 400 may then perform a secure communication operation 1000, which may include using the enable key received from the key management subsystem 410 to authenticate communications via the NIC subsystem 408a in its communication system 408 and over the network 204 and transmitting the communications to the computing system 202a / 300 using the secure communication channel 600. Although not shown or described in detail herein, those skilled in the art having the benefit of this disclosure will understand that the SCP engine 404 in the SCP subsystem 304 / 400 included in the computing system 202a / 300 may perform operations similar to those described above performed by the SCP engine 404 in the SCP subsystem 304 / 400 included in the computing system 202b / 300 in order to utilize the secure communication channel 600 and respond to (or otherwise communicate with) the SCP engine 404 in the SCP subsystem 304 / 400 in the computing system 202b / 400.

[0062] If, at decision block 510, it is determined that the first SCP subsystem is not trusted, then method 500 proceeds to block 514, where the first key management subsystem prevents the first SCP subsystem from accessing the enable key. In an implementation, at block 514 and in response to receiving an enable key request at decision block 508 and determining at block 510 that the enable key request was received from an untrusted SCP subsystem, the key management engine 410a in the key management subsystem 410 in the SCP subsystem 304 / 400 in the computing system 202b / 400 can operate to prevent the SCP engine 404 in the SCP subsystem 304 / 400 in the computing system 202b / 400 from accessing the enable key by, for example, erasing, deleting, and / or otherwise removing the enable key stored in the key management database 410b. Additionally, in some examples, the key management subsystem in any SCP subsystem can add any untrusted SCP subsystem to an untrusted SCP blacklist that can be synchronized with other key management subsystems in other SCP subsystems to distribute knowledge of the untrusted SCP subsystem throughout the networked system 200.

[0063] However, while enable key access blocking is described herein as including erasing, deleting, and / or otherwise removing the enable key from the key management database, those skilled in the art having the benefit of this disclosure will understand that access to the enable key can be blocked while allowing those enable keys to remain in the key management database and still remain within the scope of this disclosure. For example, the key management subsystem 410 in the SCP subsystem 304 / 400 in the computing system 202b / 400 can operate to prevent the SCP engine 404 in the SCP subsystem 304 / 400 in the computing system 202b / 400 from accessing the enable key stored in the key management database 410b by, for example, erasing, deleting, and / or otherwise removing the key access key that previously enabled that SCP subsystem to access the key management database 410b. In a particular example, when the untrusted SCP subsystem is the only SCP subsystem in the networked system 200 (e.g., a "standalone" SCP subsystem), the enable key can be allowed to remain in the key management subsystem of that SCP subsystem. Thus, any SCP subsystem or computing system that is no longer trusted is prevented from leveraging the secure communication channels 600, 602, and / or 604 due to being unable to access the enable key stored in the key management subsystem of that SCP subsystem.

[0064] Method 500 then proceeds to decision block 516, where it is determined whether the first SCP subsystem is trustworthy. Similar to that discussed above with respect to decision block 510, in an implementation of block 516 and after determining that the SCP subsystem 304 / 400 (or the computing system 202b / 300) in the computing system 202b / 300 is not trustworthy, a key management engine 410a in a key management subsystem 410 in the SCP subsystem 304 / 400 included in the computing system 202b / 300 may operate to periodically perform any of the root-of-trust operations of the platform described by the inventors of the present disclosure in U.S. Patent Application No. 17 / 027,835, filed on September 22, 2020 (Attorney Docket No. 16356.2212US01) (the disclosure of this patent application is incorporated herein by reference in its entirety) to determine whether the SCP subsystem 304 / 400 in the computing system 202b / 300 is trustworthy again and / or whether the computing system 202b / 300 is trustworthy again.

[0065] If it is determined at decision block 516 that the first SCP subsystem is not trustworthy, method 500 returns to block 514. Thus, method 500 may loop such that the key management engine 410a in the key management subsystem 410 in the SCP subsystem 304 / 400 included in the computing system 202b / 300 continues to prevent the SCP engine 404 in the SCP subsystem 304 / 400 in the computing system 202b / 300 from accessing the enabling keys in its key management database 410b, provided that the SCP subsystem (or its computing system) is not trustworthy. If at decision block 516 it is determined that the first SCP subsystem is trustworthy, method 500 proceeds to block 512. Thus, in response to determining that the SCP subsystem 304 / 400 (or the computing system 202b / 300) in the computing system 202b / 400 is trustworthy again at decision block 516, the key management engine 410a in the key management subsystem 410 in the SCP subsystem 304 / 400 in the computing system 202b / 400 may operate to provide the SCP engine 404 in the SCP subsystem 304 / 400 in the computing system 202b / 400 access to those enabling keys, such as by retrieving the enabling keys from its key management database 410b and transmitting the enabling keys to the SCP engine 404.

[0066] Thus, in embodiments where the enabling keys are erased, deleted, or otherwise removed from their key management database 410b in response to detecting an untrusted SCP subsystem, the key management engine 410a in the key management subsystem 410 in the SCP subsystem 304 / 400 in the computing system 202b / 400 may retrieve those enabling keys again similar to what was described above with respect to block 506, and then provide those enabling keys to the SCP engine 404 in the SCP subsystem 304 / 400 in the computing system 202b / 400. However, in embodiments where the enabling keys are retained in their key management database 410b at block 514, the key management engine 410a in the key management subsystem 410 in the SCP subsystem 304 / 400 in the computing system 202b / 400 may provide those enabling keys to the SCP engine 404 in the SCP subsystem 304 / 400 in the computing system 202b / 400 (e.g., by issuing a new key repository access key to the SCP subsystem 304 / 400).

[0067] Accordingly, referring again to Figure 10A and Figure 10B and after re - entering the trusted state, the SCP engine 404 in the SCP subsystem 304 / 400 in the computing system 202b / 400 may perform the secure communication operation 1000, which may include using the enabling keys received from the key management subsystem 410 to authenticate the communication and transmitting those communications that are made via the NIC subsystem 408a in its communication system 408 and over the network 204 to the computing system 202a / 300 using the secure communication channel 600. Although not shown or described in detail herein, those skilled in the art having the benefit of this disclosure will understand that the SCP engine 404 included in the SCP subsystem 304 / 400 in the computing system 202a / 300 may perform operations similar to those performed by the SCP engine 404 included in the SCP subsystem 304 / 400 in the computing system 202b / 300 described above in order to utilize the secure communication channel 600 and respond to (or otherwise communicate with) the SCP engine 404 in the SCP subsystem 304 / 400 in the computing system 202b / 400.

[0068] Referring to Figure 11 illustrates an embodiment of the communication that may be provided between the SCP subsystems in the networking system 200, where Ethernet communication allows for the transmission of data 1100a and control information 1100b. As Figure 11As shown, application / user service 1102, including data 1100a and control information 1100b, can be provided by the SCP subsystem in the networking system 200, and infrastructure / operation / telemetry service 1104, including data 1100a and control information 1100b, can also be provided by the SCP subsystem in the networking system 200 using an insecure or relatively less secure communication channel. In addition, Figure 11 Also shown is how SCP infrastructure service 1106, including data 1100a and control information 1100b, can be provided by the SCP subsystem in the networking system 200 using a secure communication channel, access to which is restricted via an enabling key provided using the distributed key management system of the present disclosure.

[0069] Accordingly, systems and methods have been described that utilize an SCP subsystem that provides a platform root of trust for their server devices and also operates to establish distributed secure communications with each other in order to provide a distributed, immutable key management system for use by the SCP subsystems when communicating via a secure SCP fabric. For example, the distributed key management system of the present disclosure includes a first SCP subsystem coupled to a second SCP subsystem via a network. The first SCP subsystem establishes a secure communication channel with the second SCP subsystem, and a first key management subsystem in the first SCP subsystem retrieves an enabling key for transmission via the secure communication channel from a second key management subsystem in one of the second SCP subsystems and stores the enabling key. The first key management subsystem then receives a first enabling key request from the first SCP subsystem and determines whether the first SCP subsystem is trusted. If the first SCP subsystem is trusted, the first key management subsystem provides the first SCP subsystem with access to at least one enabling key. If the first SCP subsystem is not trusted, the first key management subsystem blocks the first SCP subsystem from accessing the stored at least one enabling key. Thus, the SCP subsystem provides a secure (impervious to both external and internal threats), highly available (no single point of failure), and immutable key management system that issues keys and manages those keys via an infrastructure service that cannot be accessed or modified from untrusted external sources.

[0070] Although illustrative embodiments have been shown and described, numerous modifications, changes, and substitutions are encompassed in the foregoing disclosure, and in some instances, some features of the embodiments may be employed without corresponding use of other features. Accordingly, it should be understood that the appended claims will be interpreted broadly and in a manner consistent with the scope of the embodiments disclosed herein.

Claims

1. A distributed key management system, comprising: A plurality of second system control processor (SCP) subsystems, each second SCP subsystem including a corresponding second key management subsystem; A first SCP subsystem, the first SCP subsystem being included in a first computing system and coupled to the plurality of second SCP subsystems via a network; And A first key management subsystem, the first key management subsystem being included in the first SCP subsystem and configured to, in response to the first SCP subsystem establishing a corresponding secure communication channel with each of the plurality of second SCP subsystems: Retrieve at least one enabling key from one of the second key management subsystems in one of the plurality of second SCP subsystems for communicating with each of the plurality of second SCP subsystems via the corresponding secure communication channel; Store the at least one enabling key in a first key management database included in the first key management subsystem; Receive a first enabling key request from the first SCP subsystem; Determine whether the first SCP subsystem is trustworthy; In response to receiving the first enabling key request and determining that the first SCP subsystem is trustworthy, provide the first SCP subsystem with access to the at least one enabling key stored in the first key management database; In response to receiving the first enabling key request and determining that the first SCP subsystem is not trustworthy, block the first SCP subsystem from accessing the at least one enabling key stored in the first key management database, wherein the blocking includes: in response to determining that the first SCP subsystem is not trustworthy, erasing the at least one enabling key from the first key management database; After erasing the at least one enabling key from the first key management database, determine that the first SCP subsystem is trustworthy; In response to determining that the first SCP subsystem is trustworthy after erasing the at least one enabling key from the first key management database, retrieve the at least one enabling key from the second key management subsystem in one of the plurality of second SCP subsystems; In response to retrieving the at least one enabling key after determining that the first SCP subsystem is trustworthy after erasing the at least one enabling key from the first key management database, store the at least one enabling key in the first key management database.

2. The system according to claim 1, wherein the first SCP subsystem is configured to: Authenticate a plurality of first computing devices in the first computing system, and wherein determining that the first SCP subsystem is trustworthy includes determining that the first SCP subsystem has authenticated the plurality of first computing devices in the first computing system.

3. The system according to claim 1, wherein the first SCP subsystem is configured to: Identify the plurality of second SCP subsystems and, in response, establish the corresponding secure communication channel with each of the plurality of second SCP subsystems.

4. The system according to claim 1, wherein the first key management subsystem is configured to: Receive a second enable key request from at least one of the plurality of second SCP subsystems; Determine whether the at least one of the plurality of second SCP subsystems is trustworthy; In response to receiving the second enable key request and determining that the at least one of the plurality of second SCP subsystems is trustworthy, provide the at least one of the plurality of second SCP subsystems with access to the at least one enable key stored in the first key management database; And In response to receiving the second enable key request and determining that the at least one of the plurality of second SCP subsystems is untrustworthy, prevent the at least one of the plurality of second SCP subsystems from accessing the at least one enable key stored in the first key management database.

5. The system according to claim 4, wherein the first key management subsystem is configured to receive the second enable key request in response to: Receiving a global key manager designation communication that identifies the first key management subsystem as a global key manager.

6. An information handling system (IHS) corresponding to a first system control processor (SCP) subsystem, comprising: A first processing subsystem; A first memory subsystem coupled to the first processing subsystem and including instructions that, when executed by the first processing subsystem, cause the first processing subsystem to provide an enable key utilization engine; A second processing subsystem coupled to the first processing subsystem; A second memory subsystem coupled to the second processing subsystem and including instructions that, when executed by the second processing subsystem, cause the second processing subsystem to provide a key management engine, the key management engine being configured to: Retrieve at least one enable key from a key management subsystem in one of the plurality of second SCP subsystems for communicating with each of the plurality of second SCP subsystems via a respective secure communication channel; Store the at least one enable key in a key management database coupled to the second processing subsystem; Receive a first enable key request from the enable key utilization engine; Determine whether the IHS is trustworthy; In response to receiving the first enable key request and determining that the IHS is trustworthy, provide the enable key utilization engine with access to the at least one enable key stored in the key management database; And In response to receiving the first enable key request and determining that the IHS is untrustworthy, prevent the enable key utilization engine from accessing the at least one enable key stored in the key management database, wherein the prevention includes: in response to receiving the first enable key request and determining that the IHS is untrustworthy, erasing the at least one enable key from the key management database; After erasing the at least one enable key from the key management database, determine that the IHS is trustworthy; Retrieving the at least one enabling key from a key management subsystem in one of the plurality of second SCP subsystems in response to determining that the IHS is trusted after erasing the at least one enabling key from the key management database; and Storing the at least one enabling key in the key management database in response to retrieving the at least one enabling key after determining that the IHS is trusted after erasing the at least one enabling key from the key management database.

7. The IHS according to claim 6, wherein the enabling key utilization engine is configured to: Authenticate a plurality of IHS devices in the IHS, and wherein determining that the IHS is trusted includes determining that the enabling key utilization engine has authenticated the plurality of IHS devices in the IHS.

8. The IHS according to claim 6, wherein the enabling key utilization engine is configured to: Identify the plurality of second SCP subsystems and, in response, establish a respective secure communication channel with each of the plurality of second SCP subsystems.

9. The IHS according to claim 6, wherein the key management engine is configured to: Receive a second enabling key request from at least one of the plurality of second SCP subsystems; Determine whether at least one of the plurality of second SCP subsystems is trusted; In response to receiving the second enabling key request and determining that at least one of the plurality of second SCP subsystems is trusted, provide at least one of the plurality of second SCP subsystems with access to the at least one enabling key stored in the key management database; And In response to receiving the second enabling key request and determining that at least one of the plurality of second SCP subsystems is not trusted, prevent at least one of the plurality of second SCP subsystems from accessing the at least one enabling key stored in the key management database.

10. The IHS according to claim 9, wherein the key management engine is configured to receive the second enabling key request in response to: Receiving a global key manager designation communication that identifies the key management engine as a global key manager.

11. A method for providing distributed key management, comprising: Retrieving, by a first key management subsystem in a first system control processor SCP subsystem, at least one enabling key from a second key management subsystem in one of a plurality of second SCP subsystems for communicating with each of the plurality of second SCP subsystems via a respective secure communication channel; Storing, by the first key management subsystem, the at least one enabling key in the first key management subsystem; Receiving, by the first key management subsystem, a first enabling key request from the first SCP subsystem; Determining, by the first key management subsystem, whether the first SCP subsystem is trusted; The first key management subsystem provides the first SCP subsystem with access to the at least one enabling key stored in the first key management subsystem in response to receiving the first enabling key request and determining that the first SCP subsystem is trustworthy; and The first key management subsystem prevents the first SCP subsystem from accessing the at least one enabling key stored in the first key management subsystem in response to receiving the first enabling key request and determining that the first SCP subsystem is not trustworthy, wherein the prevention includes: the first key management subsystem erases the at least one enabling key from the first key management database in response to receiving the first enabling key request and determining that the first SCP subsystem is not trustworthy, After erasing the at least one enabling key from the first key management database, the first key management subsystem determines that the first SCP subsystem is trustworthy; In response to determining that the first SCP subsystem is trustworthy after erasing the at least one enabling key from the first key management database, the first key management subsystem retrieves the at least one enabling key from the second key management subsystem in one of the plurality of second SCP subsystems; In response to retrieving the at least one enabling key after determining that the first SCP subsystem is trustworthy after erasing the at least one enabling key from the first key management database, the first key management subsystem stores the at least one enabling key in the first key management database.

12. The method according to claim 11, further comprising: The first SCP subsystem authenticates a plurality of devices included in the first computing system together with the first SCP subsystem, and wherein determining that the first SCP subsystem is trustworthy includes determining that the first SCP subsystem has authenticated the plurality of devices in the first computing system.

13. The method according to claim 11, further comprising: The first SCP subsystem identifies the plurality of second SCP subsystems and, in response, establishes a respective secure communication channel with each of the plurality of second SCP subsystems.

14. The method according to claim 11, further comprising: The first key management subsystem receives a second enabling key request from at least one of the plurality of second SCP subsystems; The first key management subsystem determines whether at least one of the plurality of second SCP subsystems is trustworthy; In response to receiving the second enabling key request and determining that at least one of the plurality of second SCP subsystems is trustworthy, the first key management subsystem provides at least one of the plurality of second SCP subsystems with access to the at least one enabling key stored in the first key management subsystem; and In response to receiving the second enable key request and determining that at least one of the plurality of second SCP subsystems is untrusted, the first key management subsystem blocks access by at least one of the plurality of second SCP subsystems to the at least one enable key stored in the first key management subsystem.

15. The method according to claim 14, wherein the first key management subsystem is configured to receive the second enable key request in response to: Receiving a global key manager designated communication that identifies the key management engine as a global key manager.

Images