Key management for a rack server system

A system and method for providing security key exchange and management prior to the operating system of the server and also provides for executing various security functions to prevent a virus or malicious software from propagating through the server and the network. The system and method utilize the BIOS firmware and baseboard management controller (BMC), which are more secure since they do not rely on open source code for software plug-ins from the user layer. As a result, a secure code can be created for key management with a globally unique identifier (GUID). The system and method provides for a network manager to easily and flexibly manage multiple security keys for a rack server system.

TECHNICAL FIELD

Embodiments of the system and method generally related to rack server systems. More specifically, embodiments of the system and method generally related to key management for rack server systems.

BACKGROUND

Secure data is an important characteristic for a computer network. There are many methods to provide security that can be employed to protect data stored on the computer network. Some of these methods include encryption and decryption to protect important data using hardware and software. Additional methods are employed on the computer network server which is applied to the operating system, the motherboard, basic input/output system (BIOS), security controllers, secure storage and secure processors. Typically, each of these security features may involve a security key to establish a trust relationship. For example, a trust relationship can exist between the platform owner and the platform firmware, operating system and platform firmware, client and server platform, secure data of media and platform owner, etc. Establishing the trust relationship can be accomplished using symmetric and asymmetric cryptographic keys, digital signature certificates, and new objects to enroll/delete/clear key. A secure key of each of the security features above all has its own capability, and a unique name and special location to save/retrieve, to protect the server platform from malicious software attack. Each one of these security features also has different characteristics, policy and software protocols for data, message, and owner authentication.

In order to manage these different kinds of security keys more efficiently for a rack server system, a key management server can be used to centralize security keys for multiple rack servers in a data center. The key management server can deliver the appropriate security keys to the rack servers. The server platform can communicate with the key management server using a secure protocol or secure firmware and hardware when under attack by a virus or malicious software. One communication protocol is the key management interoperability protocol (KMIP) which can be used between the key management server and an encryption server, but typically only executes under the operating system layer. Unfortunately, a malicious software application may reside behind the operating system kernel and retrieve a security key with false certification, then use the security key to enter the server and cause damage.

SUMMARY

Systems and methods in accordance with various embodiments of the present technology provide a solution to the above-mentioned problems by providing key management for a rack server system. More specifically, various embodiments of the present technology provide a system and method for providing security key exchange and management prior to the loading of the operating system (OS) of the server. By establishing security key exchange and management prior to the loading of the OS, the present technology avoids security issues that are present where the security key exchange and management occurs after the loading of the OS. In those situations, viruses and/or malicious software can enter the system using the OS and cause damage to the entire network. Since the OS is not used for security key exchange and management, components that operate prior to the OS loading are used. These components are the BIOS firmware and/or baseboard management controller (BMC), which are both more secure than the OS since they do not rely on open source code for software plug-ins from the user layer. As a result, a secure code can be created for key management with a globally unique identifier (GUID). The system and method provides for a network manager to easily and flexibly manage multiple security keys for a rack server system.

In one embodiment, a security key is delivered by enclosed firmware within the computer without exposure to viruses or malicious software. The enclosed firmware includes a unified extensible firmware interface (UEFI) BIOS and/or BMC firmware, as both of these are enclosed source code within the server motherboard that does not allow for external plug-in application loading after production or manufacture. As a result, the UEFI BIOS and/or BMC are both reliable, trustworthy, and secure programs to process security key exchange and management for various security features.

In one embodiment, a security key request is submitted through a self-encrypted drive (SED). A SED is a self-encrypting hard drive with a circuit built into the disk drive controller chip that encrypts all data to the magnetic media and decrypts all the data from the media automatically. All SEDs encrypt all the time from the factory onwards, performing like any other hard drive, with the encryption being completely transparent or invisible to the user. The SED requests, using a key management service (KMS) protocol, a security key. The KMS can be integrated with the UEFI BIOS. The UEFI BIOS is protected from malicious software and/or viruses, so only the security key request is routed through the KMS using a protocol to the intelligent platform management interface (IPMI) on the BMC. The BMC uses another protocol, the key management interoperability protocol (KMIP), to contact the key management server via a network. As with the UEFI BIOS, the BMC is also protected from malicious software and/or viruses, so only the security key request is routed through the KMIP to the key management server (KMS). The KMS provides the security key via a network through the KMIP protocol to the BMC. The BMC uses the IPMI protocol to send the security key to the UEFI BIOS. The UEFI BIOS send the security key to the SED.

In one embodiment, the SED submits a security key request to the UEFI BIOS using the KMS protocol. The UEFI BIOS, protected from malicious software and/or viruses, contacts the KMS via the network. The KMS provides the security key via the network to the UEFI BIOS using the KMIP protocol. The UEFI BIOS sends the security key to the SED using the KMS protocol.

In one embodiment, a valid security key request is submitted to the UEFI BIOS using the KMS protocol. The UEFI BIOS, protected from malicious software and/or viruses, contacts the KMS via the network. The KMS determines that the security key request is valid; however the security key is not available on the KMS. The KMS creates a security key and provides the security key via the network to the UEFI BIOS using the KMIP protocol. The UEFI BIOS sends the security key to the security key requestor using the KMS protocol.

DETAILED DESCRIPTION

Various embodiments of the present technology provide a system and method for providing key management for a rack server system. More specifically, various embodiments of the present technology provide a system and method for providing robust key exchange and management prior to the operating system of the server and also provides for executing various security functions to prevent a virus or malicious software from propagating through the server and the network. The system and method utilize the BIOS firmware and baseboard management controller (BMC), which are more secure since they do not rely on open source code for software plug-ins from the user layer. As a result, a secure code can be created for key management with a globally unique identifier (GUID). The system and method provides a network manager to easily and flexibly manage multiple security keys for a rack server system.

FIG. 1illustrates a schematic block diagram of an exemplary key management for a rack server system in accordance with an implementation of the present technology. In this example, the system100includes at least one rack server102containing a UEFI BIOS104and a BMC106. The UEFI BIOS104includes a KMS protocol124for communicating with SED110. The BMC106includes a KMIP protocol116and an IPMI protocol114. The SED110submits a security key request using the KMS protocol124of the UEFI BIOS102. The BMC106includes a KMIP protocol116that contacts a KMS122via a network180. As described above, the UEFI BIOS104and the BMC106are secure from viruses and/or malicious software118. The KMS122provides the security key (not shown) electronically via the network180to the BMC102using the KMIP protocol116.

FIG. 2illustrates a schematic block diagram of an exemplary key management for a rack server system in accordance with an implementation of the present technology. In this example, the system200includes at least one rack server202containing a UEFI BIOS204. The UEFI BIOS204includes a KMIP protocol212and a KMS protocol214for receiving security key requests submitted by the SED208. The UEFI BIOS204, as described above, is secure from viruses and/or malicious software220. The security key request is sent via a network216to a KMS218. The KMS218sends the security key via the network216to the UEFI BIOS204using the KMIP protocol212. The security key is then sent to the SED208via KMS protocol214.

FIG. 3illustrates a schematic block diagram of an exemplary key management for a rack server system in accordance with an implementation of the present technology. In this example, the system300includes a variety of security requesting devices, such as a SED304. The SED304submits a security key request318through a UEFI BIOS module308. The security key request320is sent to a BMC310. A KMIP312sends the security key request320via a network314to a KMS316. The KMS316provides a security key324which is sent via the network314through the KMIP312to the BMC310. The security key324is sent to the UEFI BIOS module308. The UEFI BIOS module308sends the security key322to a variety of security requesting devices, such as the SED304.

The UEFI BIOS module308includes an EFI_KEY_MANAGEMENT_SERVICE—PROTOCOL that enables a device driver and security feature software (not shown) to access security keys associated with their operation. For example, a storage device driver may require a set of one or more security keys to access managed areas on the storage device. Implementation of the UEFI BIOS module308includes a response for the security key request from a device firmware, operating system and UEFI security feature. A variety of commands can be sent to the KMS including “UEFI driver”. A “UEFI driver” request is for a new UEFI driver to install EFI_KMS_SERVICE_PROTOCOL during power on start-test (POST). A “KMS protocol” request can apply for a variety of situations, including EFI_KMS_PROTOCOLGetServiceStatus( ), which obtains the current status of the KMS. Another situation is EFI_KMS_PROTOCOL.CreateKey( ), which requests that the KMS generate one or more new security keys and associate them with security key identifiers. The security key value is returned to the requestor. Another situation is EFI_KMS_PROTOCOL.GetKey( ), which requests an existing security key on the KMS.

The KMIP protocol312is used for communication between requestors and servers to perform a variety of management operations on objects stored and maintained by a key management system. Implementing the BMC key management interoperability (KMIP) protocol module312includes providing a web user interface for a user to configure the KMS316uniform resource locator (URL), user name, and password. Also provided is a response for the security key request from the UEFI BIOS308by using an OEM IPMI command, such as “Get KMIP Parameters/String” which is used for retrieving the configuration parameters and returned KMIP string from the “Set KMIP Parameters/String” command and KMIP server, respectively. Another OEM IPMI command can be “Set KMIP Parameters/String” which is used for setting the configuration parameters and KMIP string. Also provided is retrieving a security key via the BMC310and then translating the security key to the system firmware, operating system and the UEFI security feature (not shown).

Implementing the BMC key management interoperability (KMIP) protocol module312also includes implementing KMIP operations of create and locate between a rack server and the KMS316. These implementation commands include “Register( )”, which requests the rack server to register a managed object that was created by the user or obtained by the user through some other means, allowing the rack server to manage the object; “Locate( )”, which requests that the rack server search for one or more managed objects; or “Create( )”, which requests the rack server to generate a new symmetric security key as a managed secured object. Also implementing the BMC KMIP protocol312can include locating and creating a security key with the system GUID.

FIG. 4illustrates a schematic block diagram of an exemplary key management for a rack server system in accordance with an implementation of the present technology. In this example, the system400includes a variety of security requesting devices, such as the SED404. The SED404submits a security key request420through a UEFI BIOS module408. The security key request422is sent to a BMC410using a mail box, such as a text-based communication service. A KMIP412sends the security key request422through the KMIP412via a network416to a KMS418. The KMS418provides a security key426which is sent via the network416through the KMIP412to the BMC410. The UEFI BIOS module408sends the security key422to a variety of security requesting devices, such as the SED404.

The UEFI BIOS module408includes an EFI_KEY_MANAGEMENT_SERVICE—PROTOCOL that enables a device driver and security feature software (not shown) to access security keys associated with their operation. For example, a storage device driver may require a set of one or more security keys to access managed areas on the storage device. Implementation of the UEFI BIOS module408includes a response for the security key request from a device firmware, operating system and UEFI security feature. A variety of commands can be sent to the KMS including “UEFI driver”. A “UEFI driver” request is for a new UEFI driver to install EFI_KMS_SERVICE_PROTOCOL during power on start-test (POST). A “KMS protocol” request can apply for a variety of situations, including EFI_KMS_PROTOCOL.GetServiceStatus( ), which obtains the current status of the KMS. Another situation is EFI_KMS_PROTOCOL.CreateKey( ), which requests that the KMS generate one or more new security keys and associate them with security key identifiers. The security key value is returned to the requestor. Another situation is EFI_KMS_PROTOCOL.GetKey( ), which requests an existing security key on the KMS.

The KMIP protocol412is used for communication between requestors and servers to perform a variety of management operations on objects stored and maintained by a key management system. Implementing the BMC key management interoperability (KMIP) protocol module412includes providing a web user interface for a user to configure the KMS418uniform resource locator (URL), user name, and password. Also provided is a response for the security key request from the UEFI BIOS408by using an OEM IPMI command, such as “Get KMIP Parameters/String” which is used for retrieving the configuration parameters and returned KMIP string from the “Set KMIP Parameters/String” command and KMIP server, respectively. Another OEM IPMI command can be “Set KMIP Parameters/String” which is used for setting the configuration parameters and KMIP string. Also provided is retrieving a security key via the BMC410and then translating the security key to the system firmware, operating system and the UEFI security feature (not shown).

Implementing the BMC key management interoperability (KMIP) protocol module412also includes implementing KMIP operations of create and locate between a rack server and the KMS418. These implementation commands include “Register( )”, which requests the rack server to register a managed object that was created by the user or obtained by the user through some other means, allowing the rack server to manage the object; “Locate( )”, which requests that the rack server search for one or more managed objects; or “Create( )”, which requests the rack server to generate a new symmetric security key as a managed secured object. Also implementing the BMC KMIP protocol412can include locating and creating a security key with the system GUID.

FIG. 5illustrates a flow diagram of an exemplary key management for a rack server system500in accordance with an implementation of the present technology. The flow diagram includes a security feature504, a UEFI KMS module506, a BMC KMIP508, a KMS510. In step514, using the KMIP protocol, the BMC508configures the KMS510URL, including a user name and password, through “Register( )”. In step516, the KMS510responds to the BMC508that the connection is successful. In step518, using the KMS protocol, the security feature504determines whether system platform firmware supports UEFI KMS module506through “GetServiceStatus( )”. In step520, the UEFI KMS module506responds successfully. In step522, the security feature requests a security key from the UEFI KMS module506. Using the IPMI protocol, in step524, the UEFI KMS module506sends an OEM IPMI command to the BMC508requesting a security key. The BMC508responds successfully with an “in progress” response. In step532, the UEFI KMS module506polls until the security key is retrieved in the BMC508. In Step530, the KMS510responds to the BMC508that the security key has been created or retrieved. In step536, the BMC508responds successfully with the security key. In step534, the UEFI KMS module506responds successfully with the security key to the security feature504.

FIG. 6illustrates a flow diagram of an exemplary key management for a rack server system600in accordance with an implementation of the present technology. In this example, the interaction between a UEFI BIOS KMS, a security feature, and a BMC KMIP module is detailed. In step602, a security feature determines whether a system platform firmware supports the UEFI KMS service through “GetServiceStatus( )”. In step604, a UEFI BIOS KMS module responds successfully. In step606, a security feature calls BIOS KMS protocol “CreateKey( )” or GetKey( )”. In step608, the UEFI BIOS KMS sends an OEM IPMI command to the BMC to start the security key process. In step610, the UEFI BIOS KMS interface polls the BMC and check the process status. If the status is successful in step612, the UEFI BIOS KMS interface614sends an OEM IPMI command to the BMC to retrieve the security key. In step616, the security key, security key attributes, and the security key status is returned to the security feature. In step618, if the status is not successful, an additional determination is made whether a time threshold has been exceeded, for example 1 minute. If the threshold has been exceeded, in step620, an error handling mechanism is started. If the threshold has not been exceeded, in step622, the process waits 1 second or another predetermined period, then returns to step610. As detailed previously, either a security key will be obtained through steps612,614, and616, or an error handling mechanism is started in step620.

FIG. 7illustrates a logical arrangement of a set of general components of an example computing device700. In this example, the device includes a processor702for executing instructions that can be stored in a memory device704. As would be apparent to one of ordinary skill in the art, the device can include many types of memory, data storage, or non-transitory computer-readable storage media, such as a first data storage for program instructions for execution by the processor702, a separate storage for images or data, a removable memory for sharing information with other devices, etc. The device typically will include some type of display element706, such as a touch screen or liquid crystal display (LCD), although devices such as portable media players might convey information via other means, such as through audio speakers. As discussed, the device in many embodiments will include at least one input element710able to receive conventional input from a user. This conventional input can include, for example, a push button, touch pad, touch screen, keyboard, mouse, keypad, or any other such device or element whereby a user can input a command to the device. In some embodiments, the computing device700ofFIG. 7can include one or more network interface elements708for communicating over various networks, such as a Wi-Fi, Bluetooth, RF, wired, or wireless communication systems. The device in many embodiments can communicate with a network, such as the Internet, and may be able to communicate with other such devices.

FIG. 8illustrates a flow diagram of an exemplary key management for a rack server system800in accordance with an implementation of the present technology. The process starts at step802, and in step804a key request is submitted via a BIOS of a computer system using a KMS protocol. The key request can be submitted by a variety of sources and devices, such as but not limited to a SED or a user interface. The BIOS sends the key request to the BMC in step806. Using a KMIP protocol, the BMC contacts a KMS using a network in step808. The KMS evaluates the key request in step810. At least several outcomes are a result, including but not limited to step812, where the KMS grants the security key request and sends the key back to the BMC via the network. In this step, the KMS has located an existing key and the key request has been validated. In step814, an alternative outcome, the KMS determines that the key request is valid, but there is no existing key present in the KMS. As a result, the KMS creates a new key and sends the newly-created key back to the BMC via the network. In yet another outcome, in step816, the KMS denies the key request. The key request denial by the KMS can be for a variety of reasons, such as but not limited to an unauthorized key request, an improper key request, or an invalid key request, such as due to the expiration of a time-limited security key. In step818, the BMC sends the security key to the BIOS using IPMI protocol. In step820, the BIOS responds that the security key has been successfully received from the KMS, and the process ends in step822.

Various aspects of the present technology provide methods for providing a backup power with an uninterruptible power system (UPS) that requires minimum standby power and has a high reliability. While specific examples have been cited above showing how the optional operation can be employed in different instructions, other examples can incorporate the optional operation into different instructions. For clarity of explanation, in some instances the present technology can be presented as including individual functional blocks including functional blocks comprising devices, device components, steps or routines in a method embodied in software, or combinations of hardware and software.

To the extent examples, or portions thereof, are implemented in hardware, the present system and method can be implemented with any or a combination of the following technologies: a discrete logic circuit(s) having logic gates for implementing logic functions upon data signals, an application specific integrated circuit (ASIC) having appropriate combinational logic gates, programmable hardware such as a programmable gate array(s) (PGA), a field programmable gate array (FPGA), etc.