Systems and methods to cryptographically verify an identity of an information handling system

Various embodiments of systems and methods are provided to bind a system identifier that uniquely identifies an information handling system (IHS) to the system platform, so that the identity of the IHS can be cryptographically verified. More specifically, the present disclosure provides methods to bind a unique system identifier to an IHS platform, and methods to cryptographically verify the identity of the IHS using the unique system identifier and a plurality of keys generated and stored with a Trusted Platform Module (TPM) of the IHS. Systems are provided herein to perform such methods. As such, the systems and methods disclosed herein enable system identity to be irrefutably verified, thereby preventing theft and misuse of system identity.

FIELD

This invention relates generally to information handling system security, and more particularly, to systems and methods for verifying system identity.

BACKGROUND

With increasing use and reliance on information handling system technology comes the need to secure and protect such devices from malicious use and intent. To improve system security, many information handling systems include a Trusted Platform Module (TPM) to assure platform integrity, provide secure storage of sensitive information, and perform remote attestation and other cryptographic functions. A TPM can be used to establish a strong root of trust for an IHS by ensuring that the boot process starts from a trusted combination of hardware and software, and continues until the operating system has fully booted and applications are running. In addition to assuring platform integrity, the TPM generates and uses cryptographic keys to verify or attest to the authenticity of various hardware and/or software components, and to bind and seal data/keys/applications to the platform. TPM architecture and implementation details are described in theTPM Main Specification Version1.2 (published on Mar. 3, 2011) and theTPM Library Specification2.0 (latest errata version 1.9 released Aug. 23, 2019), the entirety of which are incorporated herein by reference.

As known in the art, a TPM may generally include a microcontroller (or crypto-processor) to generate keys and perform cryptographic functions, persistent memory for storing small amounts of sensitive information (such as cryptographic keys) in a secure location, and versatile memory for storing platform metrics and additional keys. The TPM crypto-processor may generally include a hash generator and encryption-decryption engine to hash large blocks of data, and a key generation engine and random number generator to generate keys that can be used for attestation purposes.

Before a TPM leaves the manufacturing facility, the manufacturer generates an asymmetric key pair called Endorsement Keys (EK), which can be used to verify the authenticity of the TPM. The Endorsement Keys are non-migratable, stored inside the TPM and cannot be removed. Once a user takes ownership, the TPM may be used to generate additional keys, such as an Attestation Key (AK), a Storage Root Key (SRK) and additional storage and signing keys. The AK acts as an alias for the EK and can be used to attest to the validity of the platform's identity and configuration, while the SRK provides secure key storage by wrapping (encrypting) keys that may be stored outside of the TPM (e.g., within the system hard drive). The SRK forms the root of a key hierarchy including storage keys (as nodes) and signing keys (as leaves). Storage keys are generally used to encrypt/decrypt data, providing confidentiality and access control for the data itself. Signing keys are used to encrypt hash digests of data, and provide a means for a verifying party to confirm the integrity of the data (e.g., a message), and thus, confirm the origin of the hashed data.

A problem in today's information handling systems is the theft and misuse of system identity. Current system identifiers (such as service tags, product ID, and Extensible Provisioning Protocol ID, or ePPID) are mutable and prone to theft, and therefore, cannot be relied upon to verify that a system is the one it claims to be. This results in software, services and warranty items being utilized by and on fake systems. A need, therefore, exists for an improved system and method to irrefutably verify the identity of an information handling system.

SUMMARY OF THE INVENTION

The following description of various embodiments of systems and related methods is not to be construed in any way as limiting the subject matter of the appended claims.

In the present disclosure, various embodiments of systems and methods are provided herein to bind a system identifier that uniquely identifies an information handling system (IHS) to the system platform, so that the identity of the IHS can be verified. More specifically, the present disclosure provides methods to bind a unique system identifier to an IHS platform, and methods to cryptographically verify the identity of the IHS using the unique system identifier and a plurality of keys generated and stored with a Trusted Platform Module (TPM) of the IHS. Systems are provided herein to perform such methods. As such, the systems and methods disclosed herein enable system identity to be irrefutably verified, thereby preventing theft and misuse of system identity. Additional advantages and improvements provided by the systems and methods disclosed herein will become apparent upon reading this disclosure.

According to one embodiment, a system in accordance with the present invention may include a plurality of information handling systems (IHSs), a first remote system configured to store an entitlement database for the plurality of IHSs, and a second remote system coupled, via a network, to the first remote system and to the plurality of IHSs. Each IHS may have a unique system identifier (e.g., a service tag, product ID, or ePPID) that uniquely identifies the IHS and a trusted platform module (TPM) configured to store a private Endorsement Key (EK), an EK certificate containing a public EK, a public signing key and a private signing key. For each IHS, the entitlement database stored within the first remote system may associate the unique system identifier specified for the IHS with the EK certificate and the public signing key stored within the TPM of the IHS. Upon receiving a verification request to verify the identity of an IHS, the second remote system may communicate with the first remote system and with the IHS to cryptographically verify the identity of the IHS.

In some embodiments, the IHS may send the verification request and the unique system identifier specified for the IHS to the second remote system. Upon receiving the verification request and the unique system identifier, the second remote system may retrieve the EK certificate and the public signing key associated with the unique system identifier from the entitlement database stored within the first remote system. After retrieving the EK certificate and the public signing key, the second remote system may generate a nonce, encrypt the nonce with a public EK obtained from the EK certificate, and transmit the encrypted nonce to the IHS.

Upon receiving the encrypted nonce from the second remote system, the IHS may decrypt the encrypted nonce using the private EK stored within the TPM, sign the nonce and the unique system identifier using the private signing key stored within the TPM, and transmit a signed message containing the nonce and the unique system identifier to the second remote system.

Upon receiving the signed message containing the nonce and the unique system identifier, the second remote system may use the public signing key retrieved from the entitlement database to verify the nonce and the unique system identifier contained within the signed message, and transmit a verification response to the IHS. The second remote system may transmit a verification response to the IHS confirming the identity of the IHS if: (a) the nonce contained within the signed message matches the nonce generated by the second remote system, and (b) the unique system identifier contained within the signed message matches the unique system identifier sent with the verification request. On the other hand, the second remote system may transmit a verification response to the IHS denying the identity of the IHS if: (a) the nonce contained within the signed message does not match the nonce generated by the second remote system, or (b) the unique system identifier contained within the signed message does not match the unique system identifier sent with the verification request.

Upon receiving the verification response from the second remote system, the IHS may perform one or more actions based on the verification response. If the identity of the IHS is confirmed, the IHS may in some embodiments be granted an elevated level of trust by the second remote system to perform trusted actions on behalf of the second remote system. Examples of trusted actions that may be performed on behalf of the second remote system may include, but are not limited to, locally collecting and transmitting telemetry data, launching a trusted application to perform action(s) on behalf of the second remote system, etc.

If the identity of the IHS cannot be confirmed (i.e., if the identity is denied), however, the IHS may be limited or restricted to a reduced level of trust by the second remote system. In addition or alternatively, the second remote system may alert a user or an administrator of a potential problem with the IHS identity and/or may trigger one or more remedial actions to be taken by the IHS, if the identity of the IHS cannot be confirmed. Example remedial actions that may be taken by the IHS if the identity of the IHS cannot be confirmed include, but are not limited to, revoking user access to the IHS, deleting data or program code, limiting functionality of the IHS until the problem with the identity is resolved, etc. Other actions may also be performed if the identity of the IHS cannot be confirmed.

According to another embodiment, a method performed by an information handling system (IHS) is provided herein to verify an identity of the IHS. In general, the method may include generating and storing a plurality of keys within a trusted platform module (TPM) of the IHS, wherein the plurality of keys include a public signing key and a private signing key; sending a verification request to verify the identity of the IHS, along with a unique system identifier specified for the IHS, to a remote system; and communicating with the remote system to cryptographically verify the identity of the IHS.

In some embodiments, said communicating may include receiving an encrypted nonce from the remote system; decrypting the encrypted nonce using a private Endorsement Key (EK) stored within the TPM; signing the nonce and the unique system identifier using the private signing key stored within the TPM; transmitting a signed message containing the nonce and the unique system identifier to the remote system; and receiving a verification response from the remote system.

In some cases, a verification response may be received from the remote system confirming the identity of the IHS if: (a) the nonce contained within the signed message matches the nonce received from the remote system, and (b) the unique system identifier contained within the signed message matches the unique system identifier sent along with the verification request. In other cases, a verification response may be received from the remote system denying the identity of the IHS if: (a) the nonce contained within the signed message does not match the nonce received from the remote system, or (b) the unique system identifier contained within the signed message does not match the unique system identifier sent along with the verification request.

In some embodiments, the method may further include performing one or more actions based upon the verification request received from the remote system. If the verification response denies the identity of the IHS, for example, said performing one or more actions may include, but are not limited to: alerting an administrator that the identity of the IHS has been modified, revoking user access to the IHS, deleting data or program code, and/or limiting functionality of the IHS. Other actions may also be performed when the verification response denies the identity of the IHS.

According to another embodiment, a method performed by a remote system to is provided herein to verify an identity of an information handling system (IHS). In general, the method may include receiving a verification request to verify the identity of the IHS, along with a unique system identifier specified for the IHS; using the unique system identifier to retrieve an Endorsement Key (EK) certificate and a public signing key associated with the unique system identifier from an entitlement database stored within another remote system; and communicating with the IHS to cryptographically verify the identity of the IHS.

In some embodiments, said communicating may include generating a nonce; encrypting the nonce with a public EK obtained from the EK certificate; and transmitting the encrypted nonce to the IHS. In some embodiments, said communicating may further include receiving a signed message containing the nonce and the unique system identifier, wherein the signed message is generated by a trusted platform module (TPM) of the IHS using a private signing key stored within the TPM; using the public signing key retrieved from the entitlement database to verify the nonce and the unique system identifier contained within the signed message; and transmitting a verification response to the IHS.

In some cases, a verification response may be transmitted to the IHS confirming the identity of the IHS if: (a) the nonce contained within the signed message matches the generated nonce, and (b) the unique system identifier contained within the signed message matches the unique system identifier received along with the verification request. In other cases, a verification response may be transmitted to the IHS denying the identity of the IHS if: (a) the nonce contained within the signed message does not match the generated nonce, or (b) the unique system identifier contained within the signed message does not match the unique system identifier received along with the verification request.

While the present disclosure is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawings and detailed description thereto are not intended to limit the disclosure to the particular form disclosed, but on the contrary, the present disclosure is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present disclosure as defined by the appended claims.

DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

Generally speaking, the present disclosure provides various embodiments of systems and methods to bind a system identifier that uniquely identifies an information handling system (IHS) to the system platform, so that the identity of the IHS can be cryptographically verified. More specifically, the present disclosure provides methods to bind a unique system identifier to an IHS platform, and methods to cryptographically verify the identity of the IHS using the unique system identifier and a plurality of keys generated and stored with a Trusted Platform Module (TPM) of the IHS. Systems are also provided herein to perform such methods. As such, the systems and methods disclosed herein enable system identity to be irrefutably verified, thereby preventing theft and misuse of system identity. Additional advantages and improvements provided by the systems and methods disclosed herein will become apparent upon reading this disclosure.

FIG.1is a block diagram of an information handling system100(e.g., a desktop computer, laptop computer, tablet computer, server, Internet of Things (IoT) device, etc.) as it may be configured according to one embodiment of the present disclosure. As shown inFIG.1, IHS100includes at least one processing device (e.g., at least one host processor)110, a system memory120, a graphics processor unit (GPU)130, a display device140, a platform controller hub (PCH)150, one or more input/output (I/O) devices152, one or more add-on devices154, a computer readable non-volatile (NV) memory160, an embedded controller (EC)170, a computer readable storage device180, a Trusted Platform Module (TPM)190and a network interface card (NIC)200.

It is expressly noted that the configuration shown inFIG.1is exemplary only, and that the various methods disclosed herein for binding and cryptographically verifying the identity of an information handling system may be implemented on any type and/or configuration of IHS having at least at least one processing device, a computer readable storage device, a TPM and a NIC. It will be further understood that while certain components of an information handling system are shown inFIG.1for illustrating embodiments of the present disclosure, the information handling system disclosed herein is not restricted to including only those components shown inFIG.1and described below.

Host processor110is configured to execute program instructions (or computer program code) for the IHS, and may include various types of programmable integrated circuits (e.g., a processor such as a controller, microcontroller, microprocessor, ASIC, etc.) and programmable logic devices (such as a field programmable gate array “FPGA”, complex programmable logic device “CPLD”, etc.). According to one embodiment, host processor110may include at least one central processing unit (CPU) having one or more processing cores. As described in more detail below, host processor110may execute program instructions (e.g., verification application186) to cryptographically verify the identity of the IHS using a system identifier that uniquely identifies the IHS and a plurality of keys generated and stored within TPM190.

System memory120is coupled to host processor110and configured to store program instructions (or computer program code), which are executable by host processor110. System memory120may be implemented using any suitable memory technology, including but not limited to, random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), synchronous dynamic RAM (SDRAM), non-volatile RAM (NVRAM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), Flash memory, or any other type of volatile memory.

Graphics processor unit (GPU)130is coupled to host processor110and configured to coordinate communication between the host processor and one or more display components of the IHS. In the embodiment shown inFIG.1, GPU130is coupled to display device140and configured to provide visual images to the user. In some embodiments, IHS100may include other types of processing devices including, but not limited to, a graphics-derivative processor (such as a physics/gaming processor), a digital signal processor (DSP), a security processor, and/or a trusted execution environment (such as Intel SGX, Intel TXT, a Global Platform TEE, Intel TXE, Intel CSME, AMD PSP, etc.).

Platform controller hub (PCH)150is coupled to host processor110and configured to handle I/O operations for the IHS. As such, PCH150may include a variety of communication interfaces and ports for communicating with various IHS components, such as input/output (I/O) device(s)152, add-on device(s)154, computer readable NV memory160, EC170, computer readable storage device180, TPM190and NIC200. Examples of communication interfaces and ports that may be included within PCH150include, but are not limited to, a Peripheral Component Interconnect (PCI) interface, a PCI-Express (PCIe) interface, a Serial Peripheral Interface (SPI), an Enhanced SPI (eSPI), a Serial AT Attachment (SATA) interface, a Low Pin Count (LPC) interface, a Small Computer Serial Interface (SCSI), an Industry Standard Architecture (ISA) interface, an Inter-Integrated Circuit (I2C) interface, a Universal Serial Bus (USB) interface and a Thunderbolt™ interface.

I/O device(s)152enable the user to interact with IHS100and the software/firmware executing thereon. In some embodiments, one or more I/O devices152may be provided within IHS100. In other embodiments, I/O device(s)152may be separate from the IHS and may interact with the IHS through a wired or wireless connection. Examples of I/O devices152include, but are not limited to, keyboards, keypads, touch screens, mice, scanning devices, voice or optical recognition devices, and any other devices suitable for entering or retrieving data.

Add-on device(s)154provide additional functionality to the IHS and may be coupled to one or more of the communication interfaces and ports contained within PCH150. Examples of add-on devices154include, but are not limited to, a video card, sound card, small system computer interface (SCSI) controller, hardware RAID controller, serial/parallel port card, IEEE 1394 cards, Thunderbolt™ card, USB controller card, SATA/eSATA controller card, PS/2 controller card, non-volatile memory card, PCH storage, CPU storage, etc.

Computer readable NV memory160is configured to store boot firmware (FW)162and other system firmware (not shown), and may include any suitable type of non-volatile memory and/or Flash memory device. Boot firmware262may generally include software and/or firmware modules for specifying hardware configuration settings, system date/time, boot sequence, etc., and may be implemented as a Basic Input/Output System (BIOS) and/or a Unified Extensible Firmware Interface (UEFI).

Embedded controller (EC)170may be configured to boot the information handling system and perform other functions. EC170may generally include read only memory (ROM), random access memory (RAM) and a processing device (e.g., a controller, microcontroller, microprocessor, ASIC, etc.) for executing program instructions stored within its internal ROM and RAM. For example, EC170may be configured to execute program instructions (e.g., a boot block) stored within its internal ROM to initiate a boot process for the information handling system.

Each time IHS100is powered on or rebooted, an IHS processing device (e.g., host processor110and/or EC170) executes boot firmware162to test and initialize IHS hardware components, perform a Power-On Self-Test (POST) to ensure the hardware configuration is valid and working properly, load an operating system (OS) from computer readable storage device180, and/or perform a variety of other actions known in the art. Once the OS is loaded and running, an OS application may read component identifiers associated with various hardware components (e.g., host processor110, system memory120, GPU130, PCH150, add-on devices154, NV memory160, EC170, storage device180, NIC200etc.) of the IHS, and may store the component identifiers within system tables (e.g., SMBIOS or ACPI) or system memory locations accessible to the verification application186. Examples of component identifiers include, but are not limited to, a vendor ID (VID), a device ID (DID) and a serial number (SN).

Computer readable storage device180is configured to store software and/or data, and may include any type of persistent, non-transitory computer readable storage device, such as one or more hard disk drives (HDDs) or solid-state drives (SSDs). For example, computer readable storage device180may be configured to store an operating system (OS)182for the IHS, in addition to other software and/or firmware modules and user data. As shown inFIG.1, computer readable storage device180may also store certificates184and program instructions (e.g., a verification application)186that can be executed by host processor110to cryptographically verify the identity of IHS100.

In some embodiments, certificates184may include a Platform Attribute (PA) certificate, which is created and used in present disclosure to bind system attributes to the system platform. For example, a PA certificate may include a unique system identifier (e.g., a service tag, product ID, or ePPID) that uniquely identifies the IHS, and component identifiers (e.g., a vendor ID, device ID, serial number, etc.) that identify one or more hardware components contained within the IHS. In some embodiments, the unique system identifier and component identifiers may be communicated to a remote system204(e.g., entitlement system310). Once the unique system identifier and component identifiers are combined within a PA certificate and signed, the PA certificate may be transmitted back to the IHS100and stored within computer readable storage device180.

Verification application186contains program instructions, which may be executed by host processor110to cryptographically verify the identity of IHS100. As described in more detail below, verification application186may send a request to a remote system240(e.g., verification system320) to cryptographically verify the identity of IHS100, and may act as an intermediary between the remote system and TPM190. Additional details of verification application186are described in more detail below in reference toFIGS.3,5and8.

Trusted Platform Module (TPM)190is a tamper-resistant integrated circuit or microcontroller that can be used to assure platform integrity, provide secure storage of sensitive information, and perform remote attestation and other cryptographic functions. TPM190establishes a strong root of trust for the IHS by ensuring that the boot process starts from a trusted combination of hardware and software, and continues until the operating system has fully booted and applications are running. In the present disclosure, TPM190is also used to cryptographically verify the identity of IHS100.

As shown inFIGS.1and2, TPM190includes a secure I/O interface192for communicating with PCH150, a crypto-processor194for generating keys and performing cryptographic functions, a persistent memory196for storing small amounts of sensitive information (such as cryptographic keys) in a secure location, and a versatile memory198for storing platform metrics and additional keys. The TPM crypto-processor194includes a hash generator206to hash large blocks of data, an encryption-decryption engine208to encrypt/decrypt data, and a key generator210and random number generator212to generate a plurality of keys, which may be stored within a secure location of TPM190(e.g., within non-volatile memory) and used for attestation purposes.

For example, Endorsement Key (EK)214, Storage Root Key (SRK)216and Platform Key (PK)218may be generated and stored within persistent memory196of TPM190. The Endorsement Key (EK)214is an asymmetric key pair consisting of a public key and private key, which can be used to verify the authenticity of TPM190. The private EK is securely stored within the TPM190, and is never exposed or removed from the TPM. The public EK, on the other hand, can be read from the TPM and is typically included within an EK certificate, which is stored within the TPM and used to guarantee the validity of the EK asymmetric key pair. The Storage Root Key (SRK)216is another asymmetric key pair, which can be used to provide secure key storage by wrapping (encrypting) keys that may be stored outside of the TPM. The SRK216forms the root of a key hierarchy containing one or more storage keys220(as nodes) and signing keys222(as leaves). The Platform Key (PK)218is another asymmetric key pair, which can be used to establish a trust relationship between the platform owner and the boot firmware162by controlling access to a Key Exchange Key (KEK) database, which establishes a trust relationship between the boot firmware162and the OS182.

At each system boot, TPM190performs a cryptographic hash of hardware and software configuration settings, which are stored within the Platform Configuration Registers (PCRs)218of the TPM in versatile memory198. In addition, one or more storage keys222and/or signing keys224may also be generated and stored within versatile memory198. For example, TPM190may be used to generate a pair of System Identity (ID) signing keys224, which can be used to cryptographically verify the identity of IHS100. Like the private EK, the private key portion of the System ID signing key224is securely stored within the TPM190, and is never exposed or removed from TPM190. However, the public key portion of the System ID signing key224can be accessed and read from the TPM. In some embodiments, the public System ID signing key224can be communicated to, and stored with, a remote system204(e.g., entitlement system310) along with the EK certificate and the PA certificate.

NIC200enables IHS100to communicate with one or more remote systems204via network202. In some embodiments, IHS100may utilize NIC200and network202to communicate with one or more remote systems204(e.g., entitlement system310and/or verification system320) to bind and cryptographically verify the identity of IHS100, as shown inFIGS.3-8and described in more detail below. For purposes of this discussion, network202is indicated as a single collective component for simplicity. However, it is appreciated that network202may comprise one or more direct connections to other remote systems, as well as a more complex set of interconnections as can exist within a wide area network, such as the Internet. For example, network202may be a local area network (LAN), wide area network (WAN), personal area network (PAN), or the like, and the connection to and/or between IHS100and network202may be wired, wireless or a combination thereof.

As noted above, identifiers (such as service tags, product ID, and ePPID) currently used to identify information handling systems are prone to theft and misuse, and therefore, cannot be relied upon to irrefutably verify that a system is the one it claims to be. For example, system manufacturers often use service tags (and/or service code numbers) to identify information handling systems, and may associate software, services and/or warranty items that have been purchased for the system with a particular service tag. Unfortunately, service tags are not securely stored or cryptographically protected, and are often printed on a sticker adhered to the chassis of the information handling system. This makes it easy for malicious users to “borrow” system identity, so that software, services and warranty items purchased for valid systems can be used on fake systems.

To overcome this problem, the present disclosure provides various embodiments of systems and related methods to bind and cryptographically verify system identity. More specifically, systems and methods are provided herein to bind a system identifier that uniquely identifies an IHS to the system platform, and to use the unique system identifier and a plurality of keys generated and stored within a TPM of the IHS to cryptographically verify the identity of the IHS. In doing so, the present disclosure prevents malicious users from “borrowing” system identity and utilizing software, services and warranty items on fake systems.

FIG.3illustrates one embodiment of a system that can be used to bind a unique system identifier to an information handling system (IHS), so that the identity of the IHS may be cryptographically verified.FIG.4illustrates one embodiment of a process flow, which may be performed by components of the system shown inFIG.3to bind a unique system identifier to an IHS.FIG.5illustrates one embodiment of a process flow, which may be performed by components of the system shown inFIG.3to cryptographically verify the identity of an IHS using the unique system identifier and a plurality of keys generated and stored within a TPM of the IHS.

As shown inFIGS.3and4, a plurality of information handling systems (such as IHS100) are built at a manufacturing facility300. During manufacture at test of the system platform components by manufacture test equipment302, such as during the programming of the boot firmware162and pre-boot code, TPM190is used to generate a plurality of keys including, but not limited to, a System ID signing key224. As noted above, an Endorsement Key (EK)214may be generated and stored within TPM190during TPM manufacture. The EK214and System ID signing key224are asymmetric key pairs, each consisting of a public key and a private key. The private EK and the private System ID signing key are stored securely within TPM190(e.g., within persistent memory196and versatile memory198) and are never exposed. The public EK and the public System ID signing key, however, can be read from the TPM and used for verification purposes.

After an information handling system (such as IHS100) is built according to ordered specifications and an entitlement record is created, manufacturer test equipment302may read a unique system identifier (e.g., a service tags, product ID, or ePPID) and one or more component identifiers (e.g., a vendor ID, device ID, serial number, etc.) from system tables (e.g., SMBIOS or ACPI) or system memory locations. In some cases, component identifier(s) may be read directly from one or more system components, for example, by reading the component identifier(s) from memory mapped I/O, PCI configuration space or other memory locations within the system component(s). In addition, manufacturer test equipment302accesses TPM190to read the EK certificate (containing the public EK) and the public System ID signing key stored therein.

In some embodiments, manufacturer test equipment302may transmit the unique system identifier, component identifier(s), EK certificate and public System ID signing key to an entitlement system310via network202. In such embodiments, entitlement system310may combine the unique system identifier and component identifier(s) received from manufacturer test equipment302into a Platform Attribute (PA) certificate. After assembling and signing the PA certificate, entitlement system310may store the PA certificate, the EK certificate and the public System ID signing key within a local database (e.g., entitlement database312). In some embodiments, entitlement system310may transmit the signed PA certificate back to the manufacturer test equipment300, so that it can be stored as certificates184within computer readable storage device180of IHS100. In some embodiments, entitlement system310may provide the PA certificate, the EK certificate and the public System ID signing key to a web portal330, as shown inFIG.4and described in more detail below.

Entitlement system310is an information handling system (e.g., a server), which manages hardware and software entitlements for information handling systems (e.g., desktop computers, laptop computers, tablets, servers, etc.) manufactured and/or built by the manufacturer. Entitlement system310is a remote system, which may be coupled to manufacturing facility300, verification system320and/or IHS100via network202. In the embodiment shown inFIG.3, entitlement system310manages an entitlement database312, which associates a unique system identifier (e.g., service tags, product ID, or ePPID) specified by the manufacturer for each information handling system with a PA certificate, EK certificate, and public System ID signing key created for the IHS. By associating the unique system identifier with the PA certificate, EK certificate, and public System ID Signing Key, entitlement database312binds the unique system identifier to the IHS platform.

After IHS100leaves manufacturing facility300and a user takes ownership of the IHS, entitlement database312may be used to verify the identity of the IHS. As shown inFIGS.3and5, for example, a processing device of IHS100may execute program instructions contained within a verification application186to cryptographically verify the identity of the IHS. To begin the verification process, verification application186sends a verification request, via network202, asking a remote system (such as verification system320) to verify the identity of the IHS. A system identifier (e.g., a service tag, product ID, or ePPID) uniquely identifying the IHS may be included within the verification request, or may be sent along with the verification request to verification system320. In some embodiments, a verification request may be triggered by policy, or may be sent periodically and/or upon system start-up.

Verification system320is an information handling system (e.g., a server), which can be used to verify the identity of information handling systems (e.g., desktop computers, laptop computers, tablets, servers, etc.) manufactured and/or built by manufacturer300. As shown inFIG.3, verification system320is a remote system, which is coupled to IHS100via network202and includes verification software322and an encryption-decryption engine324. Upon receiving a verification request from verification application186, verification system320executes verification software322to retrieve information stored within the entitlement database312and to use the retrieved information to verify the identity of IHS100. For example, verification system320may use the unique system identifier (provided along with the request) to retrieve the EK certificate and public System ID signing key, which are associated with the unique system identifier and stored within entitlement database312. In some embodiments, verification system320may access the entitlement database312through a web portal330, as shown inFIG.5.

Upon receiving the EK certificate and public System ID signing key associated with the unique system identifier, verification system320generates a nonce (e.g., a random number), uses the public EK contained with the EK certificate to encrypt the nonce, and transmits the encrypted nonce to IHS100. Upon receiving the encrypted nonce, verification application186sends a request to TPM190asking the TPM to decrypt the nonce using the private EK stored within the TPM. Upon receiving a decrypted nonce from TPM190, verification application186sends another request to TPM190asking the TPM to sign the nonce and the unique system identifier using the private System ID signing key stored within the TPM. Once a signed message containing the nonce and the unique system identifier is received from TPM190, verification application186transmits the signed message to verification system320for further verification.

Upon receiving the signed message, verification system320uses the public System ID signing key obtained from entitlement database312to verify the nonce and the unique system identifier contained within the signed message. More specifically, verification system320may use the public System ID signing key to verify that: (a) the nonce contained within the signed message matches the nonce generated by the verification system320, and (b) the unique system identifier contained within the signed message matches the unique system identifier provided along with the verification request.

If a match exists for both the nonce and the unique system identifier, verification system320sends a verification response to verification application186confirming the identity of the IHS100. If the identity of the IHS is confirmed, verification system320may grant IHS100an elevated level of trust, which may enable the IHS to perform trusted actions on behalf of the verification system. Examples of trusted actions that may be performed on behalf of verification system320include, but are not limited to, locally collecting and transmitting telemetry data, and launching a trusted application to perform action(s) on behalf of the verification system.

If a match does not exist for the nonce and/or the unique system identifier, verification system320sends a verification response to verification application186denying the identity of the IHS100. If the identity of the IHS cannot be confirmed (i.e., if the identity is denied), IHS100may be limited or restricted to a reduced level of trust by the verification application186. In addition or alternatively, verification application186may alert a user or an administrator that there is a potential problem with the IHS identity, and/or may trigger one or more remedial actions to be taken, if the identity of the IHS cannot be confirmed. Example remedial actions that may be taken if the identity of the IHS cannot be confirmed include, but are not limited to, revoking user access to the IHS, deleting data or program code and/or limiting functionality of the IHS until the problem with the identity is resolved. Other actions may also be performed if the identity of the IHS cannot be confirmed.

FIGS.6-8are flow chart diagrams illustrating various embodiments of methods that may be used to bind a unique system identifier to an information handling system (IHS) platform, so that the identity of the IHS may be cryptographically verified. More specifically,FIG.6illustrates one embodiment of a method400that may be used to bind a unique system identifier to an information handling system platform during manufacturing (e.g., at manufacturing facility300). After an IHS leaves the manufacturing facility, the methods500,600shown inFIGS.7and8may be used to cryptographically verify the identity of the IHS. More specifically,FIG.7illustrates method steps performed by a remote system (e.g., verification system320), whileFIG.8illustrates method steps performed by an information handling system (e.g., IHS100) to cryptographically verify the identity of the IHS using the unique system identifier and a plurality of keys generated and stored within a Trusted Platform Module (TPM) of the IHS.

As shown inFIG.6, method400may begin (in step410) by generating a plurality of keys within a TPM of an information handling system. In the present disclosure, the TPM may be used to generate a System ID signing key asymmetric key pair, including a public System ID signing key and a private System ID signing key in step410. In step420, method400accesses the TPM to obtain the Endorsement Key (EK) certificate and the public System ID signing key stored within the TPM. In step430, method400obtains a unique system identifier (e.g., a service tag, product ID, or ePPID) from the IHS. In step440, the unique system identifier, the Endorsement Key (EK) certificate and the public System ID signing key are transmitted, via a network, to a remote system (e.g., entitlement system310and/or web portal330) for storage therein. In some embodiments, the remote system may contain a database, which associates and binds the unique system identifier to the EK certificate and public System ID signing key obtained from the IHS.

As shown inFIG.7, method500may begin (in step510) upon receiving a request from an information handling system (IHS) to verify the identity of the IHS. As noted above, the verification request may include a unique system identifier (e.g., a service tag, product ID, or ePPID) that uniquely identifies the IHS. In step520, method500uses the unique system identifier to retrieve an EK certificate and a public System ID signing key corresponding to the unique system identifier from a remote system (e.g., entitlement system310and/or web portal330). In step530, method500uses the public EK contained with the EK certificate to encrypt a nonce (e.g., a random number), and transmits the encrypted nonce to the IHS. As noted above and described in more detail below in reference toFIG.8, a Trusted Platform Module (TPM) contained within the IHS may be used to decrypt the nonce and provide a signed message containing the nonce and the unique system identifier.

In step540, method500receives the signed message containing the nonce and the unique system identifier from the IHS. In step550, method500uses the public System ID signing key obtained from the remote system to verify the nonce and the unique system identifier contained within the signed message, and provides a verification response to the IHS. In some embodiments, method step550may send a verification response to the IHS confirming the identity of the IHS if: (a) the nonce contained within the signed message matches the nonce encrypted in step530, and (b) the unique system identifier contained within the signed message matches the unique system identifier received with the verification request in step510.

As shown inFIG.8, method600may begin (in step610) by sending a request to a remote system (e.g., verification system320) to verify the identity of an information handling system (IHS). As noted above, the verification request may include a unique system identifier (e.g., a service tag, product ID, or ePPID) that uniquely identifies the IHS. In step620, method600receives a nonce encrypted with a public EK associated with the unique system identifier. In step630, method600uses a private EK stored within a Trusted Platform Module (TPM) of the IHS to decrypt the encrypted nonce. In step640, method600signs the nonce and the unique system identifier using a private System ID signing key stored within the TPM, and transmits a signed message containing the nonce and the unique system identifier to the remote system for verification. In step650, method600receives a verification response from the remote system. As noted above, the verification response may confirm or deny the identity of the IHS. In step660, method600performs one or more actions based upon the verification response received from the remote system.

In some embodiments, the IHS may perform one or more trusted actions (in step660) on behalf of the remote system if the verification response received in step650confirms the identity of the IHS. Examples of trusted actions that may be performed on behalf of the remote system include, but are not limited to, locally collecting and transmitting telemetry data, and launching a trusted application to perform action(s) on behalf of the verification system. If the verification response received in step650denies the identity of the IHS, the one or more actions performed by the IHS (in step660) may include alerting an administrator that the identity of the IHS has been modified, revoking user access to the IHS, deleting data or program code, limiting functionality of the IHS until the problem with the identity is resolved, etc. Other actions may also be performed in step660based on the verification response received in step650.

It will be understood that one or more of the tasks, functions, or methodologies described herein may be implemented, for example, as firmware or as a computer program of instructions embodied in a non-transitory tangible computer readable medium that is executed by a CPU, embedded controller, microcontroller, processor, microprocessor, FPGA, ASIC, or other suitable processing device.

While the present disclosure may be adaptable to various modifications and alternative forms, specific embodiments have been shown by way of example and described herein. However, it should be understood that the present disclosure is not intended to be limited to the particular forms disclosed. Rather, the present disclosure is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure as defined by the appended claims. Moreover, the different aspects of the disclosed systems and methods may be utilized in various combinations and/or independently. Thus, the present disclosure is not limited to only those combinations shown herein, but rather may include other combinations.