SYSTEMS AND METHODS FOR CLONING BMC PROFILES IN A CLUSTER ENVIRONMENT

According to embodiments of the present disclosure, a firmware cloning system and method provided using Security Protocol and Data Model (SPDM)-enabled devices. The firmware cloning system and method include program instructions that may be executed on a processing system to mutually authenticate with a source IHS to generate shared security keys, and end a request to the source IHS to generate a server profile comprising information associated with a configuration of the source HIS. A source HIS is configured to generate the server profile in response to the request, encrypt the server profile using one of the security keys, and send the encrypted server profile to the target HIS. The target HIS then is configured to receive the encrypted server profile, decrypt the encrypted server profile using a source of the shared security keys, and configure the target IHS according to the decrypted server profile.

BACKGROUND

Communication networks, and in particular the Internet, has revolutionized the manner in which software is updated on a computer system. Prior to the advent of the Internet, a software provider would package the update on computer readable media, and the computer owner had to obtain a copy of the media to complete the update in order to make the software update accessible to the user of the computer system. However, distributing software updates on computer readable media was often expensive for software providers, which tended to restrict the number of software updates that a software provider would issue. As a consequence, substantial time would pass between updates, and consumers had to manage certain known issues for these time periods, at least until an update became available. Another aspect of this older method was that many modifications were packaged into a single update to reduce the costs associated with distributing the update.

Security Protocol and Data Model (SPDM)-based attestation, which has been published by the Platform Management Components Intercommunication (PMCI) Working Group of the Distributed Management Task Force (DMTF), generally involves a security mechanism to remotely detect an adversarial presence on a device to guarantee the device's trustworthiness. Attestation runs as a two-party security scheme in which a trusted party (e.g., the requesting device) assures the integrity of the untrusted remote device (e.g., the responding device). A requesting device, using this scheme, can determine the identity of a device and/or the firmware/software that the device is running. The responding device may send proof about its current state using a cryptographic hash to the requesting device. The requesting device may then evaluate the received evidence with the expected legitimate state of the responding device, and validate whether or not the responding device is trustworthy or not. Many system-on-chip (SOC) platforms now use SPDM-based attestation due in large part, to its light weight and high levels of security provided thereby.

SUMMARY

According to embodiments of the present disclosure, a firmware cloning system and method provided using Security Protocol and Data Model (SPDM)-enabled devices. The firmware cloning system and method include program instructions that may be executed on a processing system to mutually authenticate with a source IHS to generate shared security keys, and end a request to the source IHS to generate a server profile comprising information associated with a configuration of the source HIS. A source HIS is configured to generate the server profile in response to the request, encrypt the server profile using one of the security keys, and send the encrypted server profile to the target HIS. The target HIS then is configured to receive the encrypted server profile, decrypt the encrypted server profile using a source of the shared security keys, and configure the target IHS according to the decrypted server profile.

According to another embodiment, a server profile cloning method includes the steps of mutually authenticating, by a target IHS, a source IHS to generate shared security keys, sending, by the target IHS, a request to the source IHS to generate a server profile comprising information associated with a configuration of the source HIS, and generating, by the source IHS, the server profile in response to the request, encrypting the server profile using one of the security keys, and sending the encrypted server profile to the target HIS. The method further includes the steps of receiving, by the target IHS, the encrypted server profile, decrypting, by the target IHS, the encrypted server profile using a source of the shared security keys, and configuring the target IHS according to the decrypted server profile.

According to yet another embodiment, a computer program product includes computer-executable instructions to mutually authenticate with a source IHS to generate shared security keys, and send a request to the source IHS to generate a server profile comprising information associated with a configuration of the source HIS. The source IHS is configured to generate the server profile in response to the request, and encrypt the server profile using one of the security keys, and send the encrypted server profile to the target HIS. The instructions may be further executed to receive the encrypted server profile, decrypt the encrypted server profile using a source of the shared security keys, and configure the target IHS according to the decrypted server profile.

DETAILED DESCRIPTION

Certain IHSs may be configured with BMCs that are used to monitor, and in some cases manage computer hardware components of their respective IHSs. A BMC is normally programmed using a firmware stack that configures the BMC for performing out-of-band (e.g., external to a computer's operating system or BIOS) hardware management tasks. The BMC firmware can support industry-standard Specifications, such as the Intelligent Platform Management Interface (IPMI) and Systems Management Architecture of Server Hardware (SMASH) for computer system administration.

Baseboard management controllers (BMCs) are particularly well suited for the features provided by the Security Protocol and Data Model (SPDM) specification. The SPDM specification has been published by the Platform Management Components Intercommunication (PMCI) Working Group of the Distributed Management Task Force (DMTF). A particular goal of the SPDM specification is to facilitate secure communication among the devices of a platform management subsystem. Examples of a platform management subsystem may include an Information Handling System (IHS), such as a desktop computer, laptop computer, a cellular telephone, a server, and the like.

The SPDM specification defines messages and procedures for secure communication among hardware devices, which includes authentication of hardware devices and session key exchange protocols to provide secure communication among those hardware devices. Management Component Transport Protocol (MCTP) Peripheral Component Interconnect Express (PCIe) vendor defined message (VDM) channels, which supports peer-to-peer messaging (e.g., route by ID), allow a SPDM-enabled hardware device to issue commands to other SPDM-enabled hardware devices within a secure communication channel.

Cyber attackers are reportedly exploiting and abusing devices, such as platform interface protocol analyzers to steal unencrypted information, spy on network traffic, and gather information to leverage in future attacks against platform components and component interfaces (e.g., I2C, PCIe, I3C, Sensewire, SPI, etc.) of an IHS. Detection of vulnerable platform components is not an easy task, and exploiting unpatched vulnerabilities could allow the attacker to take control of the IHS. Some example platform security risks may include compromised security in which hostile component insertion and/or compromised firmware updates can cause supply chain security issues. Another example platform security risk may include confidentiality and integrity risks in which data transfers that are unencrypted may be vulnerable to eavesdropping, stealing, and tampering. Additionally, non-compliant security configuration errors, certificate management, platform security trust, and the like could lead to non-compliance with industry standard security policies. The DMTF SPDM specifications have been developed to alleviate such problems and reduce management overhead in maintaining and establishing the platform security within the IHS infrastructure domain.

Within this disclosure the configuration of a server refers to a number and type of hardware devices in the IHS as well as the settings for each of those hardware devices and of the server's main components, such as motherboard settings, BIOS settings, and the like. BMCs typically provide means to export a server profile associated with the existing configuration of a server (e.g., IHS). The exported server profile can then be applied to an existing or new target server. Conventionally, the BMC generates a Server Configuration Profile (SCP) that can be used store the server profile so that it can be exported and/or imported to or from other servers. A drawback of the conventional SCP is that it stores the server profile in a plain text format (i.e., in the clear). Nevertheless, storing the server profile in plain text format presents several problems. For example, user settings including passwords (hash values) are exported in plain text format. Additionally, a low level of confidence in the integrity of the information stored in the server profile may exist because it can be easily modified. That is, the BMC on which these settings are being imported to does not know if the configuration has been tampered with or not. For another example, a user (e.g., Administrator of the server) may be required to apply these settings manually on each of the servers in a clustered environment. Embodiments of the present disclosure provide a solution to these problems, among others, by providing a system and method for cloning BMC profiles in a cluster environment that causes a target server to mutually authenticate with a source IHS, and uses security keys generated according to the mutual authentication process to encrypt the server profile at the source server, and decrypt it at the target server so that the integrity and security of information in the server profile remains intact.

FIG.1shows an example of an IHS100that may be configured to implement embodiments described herein. It should be appreciated that although certain embodiments described herein may be discussed in the context of a desktop or server computer, other embodiments may be utilized with virtually any type of IHS100. Particularly, the IHS100includes a baseboard or motherboard, to which is a printed circuit board (PCB) to which components or devices are mounted by way of a bus or other electrical communication path. For example, Central Processing Unit (CPU)102operates in conjunction with a chipset104. CPU102is a processor that performs arithmetic and logic necessary for the operation of the IHS100.

Chipset104includes northbridge106and southbridge108. Northbridge106provides an interface between CPU102and the remainder of the IHS100. Northbridge106also provides an interface to a random access memory (RAM) used as main memory114in the IHS100and, possibly, to on-board graphics adapter112. Northbridge106may also be configured to provide networking operations through Ethernet adapter110. Ethernet adapter110is capable of connecting the IHS100to another IHS100(e.g., a remotely located IHS) via a network. Connections which may be made by Ethernet adapter110may include local area network (LAN) or wide area network (WAN) connections. Northbridge106is also coupled to southbridge108.

Southbridge108is responsible for controlling many of the input/output (I/O) operations of the IHS100. In particular, southbridge108may provide one or more universal serial bus (USB) ports116, sound adapter124, Ethernet controller134, and one or more general purpose input/output (GPIO) pins118. Southbridge108may also provide a bus for interfacing peripheral card devices such as PCIe slot130. In some embodiments, the bus may include a peripheral component interconnect (PCI) bus. Southbridge108may also provide baseboard management controller (BMC)132for use in managing the various components of the IHS100. Power management circuitry126and clock generation circuitry128may also be utilized during operation of southbridge108.

Additionally, southbridge108is configured to provide one or more interfaces for connecting mass storage devices to the IHS100. For instance, in an embodiment, southbridge108may include a serial advanced technology attachment (SATA) adapter for providing one or more serial ATA ports120and/or an ATA100adapter for providing one or more ATA100ports122. Serial ATA ports120and ATA100ports122may be, in turn, connected to one or more mass storage devices storing an operating system (OS) and application programs.

An OS may comprise a set of programs that controls operations of the IHS100and allocation of resources. An application program is software that runs on top of the OS and uses computer resources made available through the OS to perform application-specific tasks desired by the user.

Mass storage devices connected to southbridge108and PCIe slot130, and their associated computer-readable media provide non-volatile storage for the IHS100. Although the description of computer-readable media contained herein refers to a mass storage device, such as a hard disk or CD-ROM drive, it should be appreciated by a person of ordinary skill in the art that computer-readable media can be any available media on any memory storage device that can be accessed by the IHS100. Examples of memory storage devices include, but are not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, DVD, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices.

A low pin count (LPC) interface may also be provided by southbridge108for connecting Super I/O device138. Super I/O device138is responsible for providing a number of I/O ports, including a keyboard port, a mouse port, a serial interface, a parallel port, and other types of input/output ports.

The LPC interface may connect a computer storage media such as a ROM or a flash memory such as a non-volatile random access memory (NVRAM) for storing BIOS/firmware136that includes BIOS program code containing the basic routines that help to start up the IHS100and to transfer information between elements within the IHS100. BIOS/firmware136comprises firmware compatible with the Extensible Firmware Interface (EFI) Specification and Framework.

The LPC interface may also be utilized to connect virtual NVRAM137(e.g., SSD/NVMe) to the IHS100. The virtual NVRAM137may be utilized by BIOS/firmware136to store configuration data for the IHS100. In other embodiments, configuration data for the IHS100may be stored on the same virtual NVRAM137as BIOS/firmware136. The IHS100may also include a SPI native NVRAM140coupled to the BIOS136.

BMC132may include non-volatile memory having program instructions stored thereon that enable remote management of the IHS100. For example, BMC132may enable a user to discover, configure, and manage the IHS100, setup configuration options, resolve and administer hardware or software problems, etc. Additionally or alternatively, BMC132may include one or more firmware volumes, each volume having one or more firmware files used by the BIOS' firmware interface to initialize and test components of the IHS100.

As a non-limiting example of BMC132, the integrated DELL Remote Access Controller (iDRAC) from DELL, INC. is embedded within DELL POWEREDGE servers and provides functionality that helps information technology (IT) administrators deploy, update, monitor, and maintain servers with no need for any additional software to be installed. The iDRAC works regardless of OS or hypervisor presence from a pre-OS or bare-metal state because iDRAC is embedded within the IHS100from the factory.

It should be appreciated that, in other embodiments, the IHS100may comprise other types of computing devices, including hand-held computers, embedded computer systems, personal digital assistants, and other types of computing devices. It is also contemplated that the IHS100may not include all of the components shown inFIG.1, may include other components that are not explicitly shown inFIG.1, or may utilize a different architecture.

According to embodiments of the present disclosure, the IHS100may support SPDM in which the BMC132manages the operation of one or more managed devices configured in the IHS100. The SPDM specification provides for secure communication between the BMC132and the managed devices in the IHS100. To meet this goal, the SPDM specification facilitates certificate chains that are stored in up to eight slots. Slot 0 is a default slot that is always used, while the other slots (e.g., slots 1-7) may be allocated for use by the administrator of the IHS100. The SPDM spec also provides a slot mask that identifies each certificate chain.

FIG.2illustrates an example server profile cloning system200according to one embodiment of the present disclosure. The server profile cloning system200includes a source server202and one or more target servers204that communicate over a network206, which may be any suitable type, such as a local area network (LAN) or a Wide Area Network (WAN) (e.g., the Internet). The source server202stores and executes a profile export tool210that may be used to generate a server profile208, encrypt the server profile208, and send it to the target servers204over the network206. Each of the target servers204stores and executes a profile import tool212that receives the encrypted profile208, decrypts the encrypted server profile to recover the server profile208in the clear, and configures its respective target server204according to the recovered server profile208.

In certain cases, the source server202may be considered to be golden in that its configuration is to be propagated to other servers in a cluster, such as a data center. For example, the source server202may be continually updated with some, most, or all of the latest software and firmware updates so that when a new group of servers are deployed into the cluster, their configuration may be made to match that of the ‘golden’ source server202, and also have some, most, or all of the latest software and/or firmware updates.

Because the server profile208is encrypted during transit, the security of sensitive information (e.g., passwords, public/private keys, proprietary configurations, etc.) in the server profile208can be maintained. Additionally, encrypting the server profile208may enhance confidence that the information in the server profile208has not been inadvertently or maliciously modified. In one embodiment, the profile export tool210and profile import tool212may encrypt and decrypt the server profile208using shared security keys that were generated according to a mutual authentication process. In another embodiment, security of the server profile208may be enhanced by performing the server profile cloning system200while the target servers204are being booted; that is, before their respective Operating Systems (Oss) are allowed to start. For example, the server profile cloning system200may be performed while the BIOS firmware136of each target server204has control of its respective target server204.

In one embodiment, execution of the profile export tool210and/or profile import tool212may be administered by the BIOS firmware136of their respective source server202or target server204. In another embodiment, execution of the profile export tool210and/or profile import tool212may be performed by a BMC132configured in each of the source server202and/or target server204. For example, the profile export tool210may communicate with the profile import tool212using a secure communication session established according to the SPDM protocol in which the secure communication session is established via a mutual authentication process where public and private security keys are generated and shared between the profile export tool210and profile import tool212. In one embodiment, the server profile208may be encrypted using a private key of the BMC132of the source server202and decrypted using a public key of the BMC132of the source server202that was previously shared with the target server204. In another embodiment, the server profile208may be stored in secure portion of the memory of the source server202to provide for data-at-rest protection. Security measures such as described above may provide for enhanced security of the server profile208and to ensure its integrity from being inadvertently or illicitly modified.

FIG.3illustrates an example flow diagram of a server profile cloning method300showing how the profile import tool212may communicate with the profile export tool210to clone the configuration of the source server202with the target server204according to one embodiment of the present disclosure. Additionally or alternatively, the server profile cloning method300may be performed at least in part, by the server profile cloning system200as described herein above with reference toFIG.2. The server profile cloning method300may be performed at any suitable time, such as whenever it is desired to clone a configuration of the target server204with the source server202. For example, the server profile cloning method300may be performed when multiple target servers204are newly deployed in a data center, and turned up for use with the existing servers in the data center.

Initially at step302, the source server202sends ongoing multicast messages to the target servers204. For example, the source server202may be configured with a multicast address to be used for sending the multicast messages at ongoing intervals (e.g., once each minute) such that, when a target server204is initially connected to the network206, it may commence the server profile cloning method300described herein. In one embodiment, the BMC132configured in the source server202may be configured with the multicast address, and used for sending the multicast messages at ongoing intervals.

At step304, the multicast address is provisioned in the target server204. In one embodiment, the cluster may be configured with multiple source servers202, each with a different configuration so that each target server204may be provisioned with a different configuration based upon which multicast address is provisioned in the target server204. For example, an administrator may desire to have a group of target servers204with a first configuration optimized for storage capabilities, and have a second group of target servers204with a second configuration optimized for enhanced compute capabilities. In such a case, the administrator may deploy a first source server202with a configuration optimized for storage capabilities, and deploy a second source server202with a configuration optimized for its compute capabilities, and provision a different multicast address in each so that selective ones a group of target servers204may be cloned with the first source server202, and other ones of the group of target servers204cloned with the second source server202.

At step306, the target server204commences a boot-up process. In one embodiment, a flag may be set in the target server204or profile import tool212to inhibit the Operating System (OS) of the target server204from being started until its configuration is cloned with that of the source server202. In one embodiment, the profile import tool212may be configured to wait for receipt of the multicast message from the profile export tool210. In a particular embodiment in which the profile import tool212is executed by a BMC132, certain steps of the server profile cloning method300described herein may be performed during a lights-out phase of the target server204in which the BMC132is running while the other devices in the target server204are powered down or powered in a limited failsafe mode of operation.

At step308, the profile import tool212discovers the profile export tool210configured in the source server202. In one embodiment, the profile import tool212discovers the profile export tool210by detecting the multicast message. In other embodiments, the profile import tool212may discover the profile export tool210using any suitable technique, such as by manually configuring the multicast address in the profile import tool212. The profile export tool210and/or profile import tool212determines whether the platforms they both are executed on (e.g., BMCs configured in the source server202and target server204) are SPDM-enabled devices at step310. If so, both the profile export tool210and profile import tool212mutually authenticate one another using SPDM at step312; otherwise both the profile export tool210and profile import tool212mutually authenticate one another using TLS at step314. As a result of either authentication process (e.g., SPDM or TLS), the profile import tool212provide its public security key to profile export tool210in the source server202.

At step316, the profile import tool212sends a request to the profile export tool210to generate a server profile208. In one embodiment, profile export tool210may perform a discovery of the configuration of the source server202, and generate a new server profile only if changes have been made to the source server's configuration since the last time that the server profile was generated. In another embodiment, the profile export tool210may generate a new server profile only if a certain amount of time (e.g., 30 minutes, 1 hour, 3 hours, etc.) has elapsed since the last time the server profile208was generated. Such behavior may be useful for cases where multiple target servers204are being cloned at or close to the same time. Thereafter at step318, the profile export tool210optionally generates the server profile208, such as based upon the aforementioned criteria. The profile export tool210then encrypts the generated server profile208using the public security key it obtained at step320, and sends the server profile208to the target server204at step322.

At step324, the profile import tool212decrypts the encrypted server profile208such as, by using the private security key of the target server204. In one embodiment, the decrypted server profile208is temporarily stored in a secure portion of the memory of the BMC132. The profile import tool212then provisions the target server204with the settings stored in the decrypted server profile208at step326, deletes the decrypted server profile208at step328, and allows the OS to start at step330.

The steps described above may be repeated for each of a group of target servers204. Nevertheless, when use of the server profile cloning method300is no longer needed or desired, the method300ends.

AlthoughFIG.3describes an example method300that may be performed to clone one or more target servers204, the features of the method300may be embodied in other specific forms without deviating from the spirit and scope of the present disclosure. For example, the method300may perform additional, fewer, or different operations than those described in the present examples, such as omitting step318if/when a group of target servers204are being clone at or about the same time. For another example, the method300may be performed in a sequence of steps different from that described above. As yet another example, certain steps of the method300may be performed by other components than those described above, such as by the BIOS configured in the IHS100.