Device rights authorization using remote attestation

Abstract

The invention discloses device rights authorization using remote attestation. Apparatuses, systems, and techniques for issuing rights tokens to a root of trust allow the root of trust to take certain actions on its protected component, such as, for example, modifications affecting the software and / or functionality available to its protected component. In certain embodiments, a rights token issuing process may involve receiving an attestation report corresponding to a root of trust of a computing system, where the attestation report is cryptographically signed using a private key unique to the root of trust, verifying the attestation report using a public key corresponding to the private key, and issuing a rights token based at least on successful verification of the attestation report. A rights token is issued for the root of trust, allowing the root of trust to take one or more actions on system components protected by the root of trust.

Description

Technical Field

[0001] The present disclosure relates generally to management of computing systems and, more particularly, to improved techniques for managing software and / or functionality available on components of a computing system. Background Art

[0002] Modern computing systems can be extremely large and complex, consisting of countless subsystems and component devices running a wide range of software stacks. For example, a high-performance computing (HPC) system may include many different servers (e.g., one or more compute, storage, and / or management nodes) that collectively process compute-intensive workloads (e.g., to support artificial intelligence (AI) or other HPC applications). In turn, each server may include many different subsystems and component devices (e.g., one or more CPU or GPU subsystems and various system controllers, interconnects, switches, interfaces, or other component devices), each of which may run its own set of software, including, for example, system and / or device firmware. The various subsystems and component devices (or components) that make up a computing system are typically placed in a secure "production" state (e.g., using secure "production" software) by the component manufacturer and then shipped to the end customer for integration into a "production" computing system. In some cases, the component manufacturer may wish to modify the software and / or functionality available on the component after it has entered production, but performing these modifications in a secure and reliable manner is a significant challenge. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The present disclosure will be more fully understood from the detailed description given below and the accompanying drawings of various embodiments of the present disclosure. However, the accompanying drawings should not be considered to limit the present disclosure to specific embodiments, but are only for explanation and understanding.

[0004] Figure 1 A block diagram of an example computing environment is shown in accordance with at least one embodiment.

[0005] Figure 2 A block diagram of an example computing environment is shown in accordance with at least one embodiment.

[0006] Figure 3 A flow chart illustrating an example method for issuing entitlement tokens in accordance with at least one embodiment is shown.

[0007] Figure 4 A flow chart illustrating an example method for installing an entitlement token in accordance with at least one embodiment is shown. DETAILED DESCRIPTION

[0008] Modern computing systems can be extremely large and complex, consisting of countless subsystems and component devices used to run a wide range of software stacks. For example, a high-performance computing (HPC) system may include multiple different servers (e.g., one or more compute, storage, and / or management nodes) that work together to process compute-intensive workloads (e.g., to support artificial intelligence (AI) or other HPC applications). Each server may include multiple different subsystems and component devices (e.g., one or more CPU or GPU subsystems and various system controllers, interconnects, switches, interfaces, or other component devices), each of which may run its own set of software, including, for example, system and / or device firmware.

[0009] The various subsystems and component devices (or components) that make up a computing system are typically developed by different manufacturers and integrated by the end customer into a "production" computing system (e.g., when deploying an HPC system in a data center environment). System components are typically in a secure "production" state (e.g., using secure "production" firmware) before being shipped to the end customer, for example, to prevent reverse engineering or other forms of exploitation or misuse. For example, system components are often protected by a root of trust (RoT), which can perform many different security functions and / or provide many different security services, including controlling the software that can be placed on the system component (e.g., in its memory) or loaded and / or executed by the system component (e.g., by its application processor). For example, the RoT may only allow the system component to load and execute trusted software code (e.g., booted from trusted firmware (e.g., production firmware)), for example, by digitally signing it using an appropriate cryptographic key (e.g., using the component manufacturer's private key, such as a production key, which is known to or verifiable by the RoT). In some cases, the RoT may also control how the system component executes software. For example, a RoT can control whether certain hardware and / or software features, tools, functions, operating modes, etc. (or features) are available for use (e.g., enabled / disabled or locked / unlocked). For example, a RoT can prevent the use of certain features (e.g., that are otherwise present in production firmware) once a system component is in a production state (e.g., where the feature could expose the component to attack, adversely affect the performance of the component, or otherwise have an undesirable effect). For example, a RoT used to protect a processor (e.g., a central processing unit (CPU), graphics processing unit (GPU), parallel processing unit (PPU), field programmable gate array (FPGA), application specific integrated circuit (ASIC), or other form of processing logic) can disable ultra-high frequency operating modes, enforce hash rate limits, or control the use of other processor features.

[0010] However, in some cases, manufacturers may wish to modify the software and / or functionality available on system components after they are in production (e.g., in an end customer's production computing system). For example, a manufacturer may wish to provide special software and / or selectively enable certain functionality for different end customers. For example, while individual system components may undergo testing and validation during their development, some end customers may perform their own testing and validation when deploying production computing systems. When different system components (perhaps developed by different manufacturers) are combined in a production computing system, issues invariably arise. To facilitate testing and validation, and to help evaluate and / or resolve any issues that may arise, component manufacturers may provide end customers with special software (e.g., custom debugging firmware, useful debugging tools, etc.) and / or enable certain restricted functionality (e.g., detailed logging, etc.). As another example, a manufacturer may restrict the use of certain functionality (e.g., disabling ultra-high frequency operation, limiting hash rate calculations, etc.) when a system component is in production, but may wish to selectively enable these functionality for certain end customers (e.g., to support certain HPC applications or workloads).

[0011] Component manufacturers can effect such modifications to computing system components by distributing software update packages (or software updates) to computing systems, containing component-specific software and / or software for enabling certain features on the component (e.g., a RoT firmware update), for installation by their RoT. In some cases, for example, component manufacturers may provide a software distribution service through which software updates for computing systems and their components can be requested (e.g., by end customers) and / or through which software updates can be distributed to target computing systems for installation by their RoT. Before installing a software update, the RoT may inspect the software update and / or its contents (e.g., the component firmware therein) to ensure that it comes from a trusted source, for example, by verifying that it is digitally signed using an appropriate cryptographic key. To ensure that the software update and / or its contents are trustworthy so that the RoT allows its installation, the software update and / or its contents may be signed using a cryptographic key known or verifiable to the RoT (e.g., the RoT already has the corresponding public key). Consequently, manufacturers are often forced to sign software updates and / or their contents using production keys (e.g., using the same production key used to sign production firmware).

[0012] However, the software and / or functionality enabled by software updates may make system components vulnerable to exploitation or abuse, and using production keys to sign software updates and / or their contents presents a significant security risk because, once distributed, component manufacturers have no effective way to control the use of the software updates and / or their contents. For example, production keys are often common to all production components, so a software update (e.g., debug firmware) signed with a production key can be installed on any such component. Signing software updates with production keys can create an unnecessarily large attack surface (e.g., putting all production components at risk), while software updates may be intended for use only in a relatively small number of components (e.g., associated with a specific end customer and / or a limited number of production systems). While production keys can be revoked (e.g., by updating the RoT firmware) when the software update is no longer needed (e.g., after testing and validation by the end customer), doing so is impractical because the revocation process would need to be performed on all production systems using the component (e.g., on every production system where the component is deployed) to ensure that the software package and / or its contents are no longer usable. Additionally, in some cases, a component manufacturer may want to re-enable the use of a software update (for example, if an end customer encounters a problem later), but may find it difficult to do so because the production key has been revoked.

[0013] Additional security concerns arise when software updates are provided via software distribution services, which may not be able to adequately authenticate or authorize software and / or feature-enabling requests under traditional distribution models. For example, existing distribution technologies may not allow the service to adequately verify which device is making the request or decide whether the request should be fulfilled and / or whether the software update should be provided (e.g., whether the request is from a specific end customer and / or production computing system, whether the component for which the software update is provided is manufactured by the manufacturer and / or provided to a specific end customer, whether the RoT on which the software update will be installed is running a known compromised firmware version, etc.).

[0014] Embodiments of the present disclosure address the aforementioned issues by employing a novel approach to deploying software to components of a computing system and / or enabling functionality on components of a computing system in a controlled manner. In some embodiments, for example, an entitlement token configuration system (or configuration system) may be used to issue an entitlement token to a RoT, which may grant or provide "privileges" or authorizations to the RoT to take certain actions on the components it protects (including the RoT itself), such as affecting changes to software and / or configuring (e.g., enabling or disabling) hardware and / or software functionality of the component (or components) it protects. In some embodiments, for example, an entitlement token may authorize the RoT to install special software (e.g., custom firmware, tools, etc.) onto a component (e.g., onto its memory), allow the component to load and execute the special software after installation (e.g., boot from custom firmware), and / or enable certain restricted functionality on system components (e.g., in production firmware or other existing firmware).

[0015] In some embodiments, the configuration system may be able to issue an entitlement token for a particular RoT of a particular computing system. In some embodiments, for example, the configuration system may issue an entitlement token after verifying an attestation report provided by the RoT, which may provide attestation about the identity and / or status of the RoT and / or the components it protects. In some embodiments, for example, the attestation report provided by the RoT may be cryptographically signed with a device-unique key of the RoT, and the configuration system may use the device-unique key to verify the attestation report. In some embodiments, after verifying the attestation report (and the identity and / or status of the RoT and / or the components it protects), the configuration system may perform one or more policy criteria checks to determine whether the RoT should be allowed to take certain actions with respect to the components it protects, based on which the configuration system may (or may not) issue an entitlement token to the RoT authorizing it to do so.

[0016] In some embodiments, for example, the configuration system may issue an entitlement token based on an end-to-end challenge-response transaction performed between the configuration system and one or more RoTs of the computing system. In some embodiments, for example, the configuration system may request an attestation report from each of the one or more RoTs of the computing system. In some embodiments, for example, the computing system may include a baseboard management controller (BMC) that can be used to monitor and / or manage the various components of the computing system and their corresponding RoTs. In some embodiments, a request for an attestation report may be issued to the computing system's BMC. In some embodiments, for example, an application engineer or other representative of a component manufacturer (e.g., to whom an end customer may report an issue or request special software and / or enable special features) may cause the configuration system to issue an attestation report request to the computing system's BMC. In some embodiments, the configuration system may include an authentication challenge (e.g., a random number generated by the configuration system) as part of the attestation report request for inclusion in any attestation report provided in response thereto. In this way, an attestation report can be associated with a specific request, allowing the configuration system to ensure that the attestation report is "up-to-date" (e.g., received in response to the current request) and prevent so-called "replay" attacks.

[0017] In some embodiments, in response to receiving an attestation report solicitation request from the configuration system, the BMC may request an attestation report from each of the different RoTs it manages. In some embodiments, for example, the BMC may issue an attestation report request (or attestation request) to each RoT, requesting attestation regarding the identity and / or status of the RoT and / or its protected components, which attestation may be provided as an attestation report. In some embodiments, the BMC may include the authentication challenge in the attestation report solicitation request it received as part of the attestation request it issues to the RoT, so that the RoT includes it as part of its returned attestation report (e.g., associating the attestation report with the attestation report solicitation request, as described above).

[0018] In some embodiments, in response to receiving an attestation request from a BMC, the RoT may generate an attestation report that includes one or more measurements, such as information about the identity and / or status of the RoT or its protected components (e.g., current hardware and / or software status). In some embodiments, for example, the attestation report may include the serial number of the RoT and / or its protected components, the current firmware version on the RoT and / or its protected components, and / or other measurements. In some embodiments, the attestation report may include one or more additional parameters. In some embodiments, for example, the RoT may include an authentication challenge from the attestation request received from the BMC (which may have originated from an attestation report request from a configuration system) as part of the attestation report (which may allow the configuration system to associate the attestation report with the attestation report request), which may serve as an authentication response. In some embodiments, the RoT may include (another) authentication challenge (e.g., a random number generated by the RoT) as part of the attestation report in any entitlement token issued in response thereto. In this way, an entitlement token can be tied to a specific attestation report, allowing the RoT to ensure that the entitlement token is "fresh" (e.g., received in response to the current attestation report) and prevent so-called "replay" attacks.

[0019] In some embodiments, the attestation report generated by the RoT can be signed with a cryptographic key unique to the RoT (e.g., a key based on a physically unclonable function (PUF)). In doing so, the attestation report (and the measurements it contains) can be cryptographically bound to a specific RoT and component. The attestation report can also serve as proof of possession of the RoT and component. In this way, the configuration system, after verifying the attestation report, can securely issue an entitlement token to a specific RoT (e.g., allowing changes to the software of the system component protected by it) and / or exercise control over its use (e.g., based on the measurements contained therein).

[0020] For example, in some embodiments, the device-unique key of the RoT may be an asymmetric key, comprising a private key and a public key (which may be individually or collectively referred to as a device-unique key). In some embodiments, the RoT may sign an attestation report using a device-unique key (e.g., a device-unique private key), and the configuration system may be able to verify the attestation report using a corresponding device-unique key (e.g., a device-unique public key), which may be known or provided to the configuration system (e.g., in a certificate (or certificate chain)). In some embodiments, for example, the RoT may calculate a message digest from the attestation report using a hash algorithm (e.g., using MD5, SHA1, SHA256, or other hash algorithm), and the RoT may encrypt the message digest using the device-unique key. In some embodiments, the RoT may append the encrypted message digest to the attestation report (or otherwise include it with the attestation report) to sign the attestation report. In some embodiments, the RoT may return the signed attestation report to the BMC (e.g., in response to an initial attestation request).

[0021] In some embodiments, the BMC may aggregate the signed attestation reports received from each RoT to generate a set of attestation reports. In some embodiments, the BMC may append a signing certificate or certificate chain (certificate) to each attestation report that contains the corresponding device-unique key (e.g., device-unique public key) of the RoT (or otherwise include it with each attestation report). In some embodiments, the certificate may have been provided by the RoT to the BMC (e.g., as part of establishing communication between the two). In some embodiments, the certificate may have been issued to the RoT by a certificate authority trusted by the BMC and / or configuration system (e.g., when first manufactured or put into production) so that they can verify the certificate and its contents (e.g., using a public key or root certificate of a certificate authority known to the BMC and / or configuration system).

[0022] In some embodiments, the BMC may return a collection of attestation reports to the configuration system (e.g., in response to an attestation report request). In some embodiments, the configuration system may process each attestation report in the collection to confirm that it has been properly signed, for example, verifying a certificate (or certificate chain) to confirm the device-unique public key of the RoT provided therein, verifying the signature on the attestation report using the device-unique public key, and / or verifying the authentication response contained in the attestation report (e.g., to ensure that it matches the authentication challenge contained in the issued attestation report request). In some embodiments, the configuration system may further process each attestation report to determine whether the identity and / or state measurements contained therein meet one or more policy criteria (e.g., whether the RoT and / or component serial number is associated with a specific end customer, whether the RoT uses the latest firmware version, etc.). In some embodiments, after verifying the attestation report and meeting the applicable policy criteria, the configuration system may generate an entitlement token for the RoT that generated the attestation report, which may allow the RoT to take certain actions with respect to the components it protects.

[0023] In some embodiments, for example, an entitlement token may allow the RoT to install special software (e.g., custom firmware, tools, etc.) onto a component (e.g., onto its memory) and allow the component to load and execute the special software after installation (e.g., boot from the custom firmware). In some embodiments, for example, an entitlement token may include a cryptographic key not previously known to the RoT (e.g., a non-production key) that the RoT may use to verify whether particular software can be trusted (e.g., so that the software can be securely installed and / or loaded and executed by the component). This may allow a component manufacturer to sign a software update and / or its contents (e.g., debug firmware) using a non-production private key, which the RoT may be able to verify using a corresponding non-production public key provided via the entitlement token (allowing the RoT to install the software update and / or its contents and allowing the component to load and execute the software after installation). In some embodiments, an entitlement token may be used to prevent the RoT from installing certain software onto a component and / or allow the component to load and execute already installed software. In some embodiments, for example, an entitlement token may identify a cryptographic key known to the RoT to be revoked (e.g., may no longer be trusted), such that software signed with the cryptographic key will no longer be verified by the RoT for installation and / or use. As another example, in some embodiments, an entitlement token may allow the RoT to configure different software and / or hardware features of the components it protects. In some embodiments, for example, an entitlement token may identify one or more restricted features and instruct the RoT to enable those features.

[0024] In some embodiments, the entitlement token may include several additional parameters that the RoT may verify before using the entitlement token. In some embodiments, these additional parameters may be used to limit the lifespan and / or scope of the entitlement token. In some embodiments, for example, the entitlement token may include one or more identity and / or state measurements from an attestation report (e.g., the serial number of the RoT and / or the component it protects, the firmware version on the RoT and / or the component it protects, and / or other identity and / or state measurements), which may be used to bind the entitlement token to a specific RoT and component and / or its specific state. In some embodiments, the entitlement token may include an authentication challenge provided in the attestation report as an authentication response, which may allow the RoT to determine whether the entitlement token is valid or expired (e.g., whether the RoT's current authentication challenge is the same or different, respectively). In some embodiments, the entitlement token may include other identity and / or state parameters that the RoT may verify before using the entitlement token, such as a software hash value (e.g., a hash value of the authorized firmware installed on the RoT and / or the component it protects), supported firmware versions (e.g., minimum or maximum firmware version numbers), a security version number, or other parameters.

[0025] In some embodiments, the configuration system may sign the entitlement token, for example, using a cryptographic key known or verifiable by the RoT, such as a production key. In some embodiments, the key may be an asymmetric key, including a private key and a public key (e.g., a private production key and a public production key). In some embodiments, the configuration system may use the private key (e.g., the private production key) to sign a certification report, and the RoT may be able to verify the certification report using a corresponding public key (e.g., the public production key) known to the RoT (e.g., when first manufactured or put into production). In some embodiments, for example, the configuration system may use a hash algorithm (e.g., using MD5, SHA1, SHA256, or other hash algorithms) to calculate a message digest from the entitlement token, and the configuration system may encrypt the message digest using the private key. In some embodiments, the configuration system may append the resulting encrypted message digest to the entitlement token (or otherwise include it with the entitlement token) to sign the entitlement token.

[0026] In some embodiments, once all attestation reports have been processed and the appropriate entitlement tokens have been generated and signed, the configuration system can aggregate the entitlement tokens and generate a set of entitlement tokens. In some embodiments, the set of entitlement tokens can be provided to the BMC of the computing system. In some embodiments, the set of entitlement tokens can be provided by the configuration system to the BMC. In other embodiments, the configuration system can provide the set of entitlement tokens to a software distribution system, which can include the set of entitlement tokens in a software update package, which can then be distributed to the BMC. In some embodiments, the software update package can include special software associated with a particular entitlement token (e.g., the entitlement token can authorize the RoT to install the software).

[0027] In some embodiments, the BMC can receive a set of entitlement tokens and extract and process each entitlement token contained therein. In some embodiments, for example, the BMC can determine its expected RoT (e.g., based on the RoT and / or component serial number provided therein) and provide it to the RoT for installation (e.g., as part of a token installation request). In some embodiments, when the set of entitlement tokens is provided in a software update, the BMC can determine that the set of entitlement tokens exists (in the software update) and extract it for further processing (as just described). In some embodiments, the BMC can extract and process the set of entitlement tokens before processing the rest of its contents (e.g., before processing any software contained therein).

[0028] In some embodiments, when the RoT receives an entitlement token from the BMC for installation (e.g., as part of a token installation request), it may inspect the entitlement token to verify that it is from a trusted source and / or is suitable for installation. In some embodiments, for example, the RoT may verify the signature on the entitlement token (e.g., using a corresponding public key known to the RoT, such as a public production key), verify that the entitlement token contains an appropriate authentication response (e.g., to ensure that it matches an authentication challenge contained in a previously sent attestation report), and / or verify one or more additional parameters contained in the entitlement token, such as identity and / or state parameters (e.g., to ensure that they match the RoT's parameters). In some embodiments, after verifying the entitlement token, the RoT may install the entitlement token. In some embodiments, for example, the RoT may store the entitlement token (e.g., in RoT memory) and / or determine the type of entitlement token (e.g., indicating what action the entitlement token authorizes the RoT to take) and process the entitlement token accordingly (e.g., extracting and storing the cryptographic key contained therein for use in attempting to verify that software is installed and / or loaded and executed by a system component, or to enable one or more functions identified therein).

[0029] In some embodiments, once the entitlement token is no longer needed (e.g., once testing and verification by the end customer is complete), the BMC may issue an entitlement token uninstall request (or token removal request) requesting the RoT to uninstall the entitlement token. In some embodiments, upon receiving the token removal request, the RoT may identify any token in memory and perform a reverse installation process for it. In some embodiments, for example, the RoT may remove the corresponding stored cryptographic keys, or disable one or more enabled functions, and remove the entitlement token from memory. In some embodiments, the BMC may be configured to, upon receiving a software update that does not include a set of entitlement tokens (e.g., software with a production signature), issue a token removal request to each RoT it manages, which may be understood to indicate that the entitlement token is no longer needed (e.g., testing and verification are complete) and that the system component will be restored to a safe state (e.g., a production state).

[0030] As described above, traditional methods for distributing software to components of a computing system and / or enabling functionality on components of a computing system (e.g., through a manufacturer's software distribution service) do not allow for adequate verification or authorization of the components before doing so. They also do not allow for effective control over the use of the software and / or functionality after distribution or enabling. Embodiments of the present disclosure overcome these limitations through the use of entitlement tokens that can authorize a RoT protecting a component and / or enable a RoT protecting a component to take certain actions on the components it protects, such as changes that affect the software and / or functionality available to the components it protects. For example, in some embodiments, entitlement tokens can be issued by a token configuration system based on an attestation report provided by the RoT, providing attestation about the identity and / or status of the RoT and / or the components it protects, and can be cryptographically signed using the device-unique key that generated their respective RoTs. This allows the token configuration system to not only verify whether the requesting device is entitled to receive certain software and / or functionality (e.g., whether the device is authorized, whether the authorized device is actually making the request, and / or whether the authorized device is in an appropriate operating state), but also to bind the entitlement token to the requesting device and its state, thereby allowing the use of the software and / or functionality to be controlled even after it is distributed and / or enabled (e.g., limiting its lifecycle and / or limiting the scope of its use).

[0031] Figure 1 is a block diagram of an example computing environment 100 according to at least one embodiment. Figure 1 As shown, computing environment 100 may include one or more computing systems 110 , a token provisioning system 140 , and (optionally, in some embodiments) a software distribution system 150 .

[0032] Computing system 110 may include any system used for computing (e.g., performing computing tasks or operations), which may vary in size and complexity. In some cases, for example, computing system 110 may be a single server, while in other cases it may be a high-performance computing (HPC) system that includes multiple different servers (e.g., one or more compute, storage, and / or management nodes). Computing systems 110 may each include several different subsystems and / or component devices ("components"), each of which may be configured to run its own set of software (e.g., including its own firmware). Each component of computing system 110 (or a subset thereof) may be protected by a corresponding root of trust (RoT), which may control the software and / or configure the hardware and / or software functionality of the component (or multiple components) it protects (including the RoT itself), in addition to other security functions and / or services.

[0033] The token configuration system 140 may be used to issue entitlement tokens to the RoT of the computing system 110 that may authorize the RoT to take certain actions with respect to the components it protects and / or enable the RoT to take certain actions with respect to the components it protects (e.g., changes that affect the software and / or functionality available on the components). For example, in some embodiments, an entitlement token may be issued to a RoT to allow the RoT to install special software (e.g., custom debug firmware, useful debugging tools, etc.) and / or enable certain restricted functionality (e.g., detailed logging, ultra-high frequency operation, unlimited hash rate computation, etc.). In some embodiments, the token configuration system 140 may issue entitlement tokens to the RoT of the computing system 110 based on an end-to-end challenge-response performed between the token configuration system 140 and each RoT. The issued entitlement token may be returned by its appropriate RoT (e.g., the RoT to which the entitlement token was issued) to the computing system 110 for installation.

[0034] In some embodiments, token configuration system 140 may return the entitlement token to computing system 110 itself. In other embodiments, token configuration system 140 may provide the entitlement token to software distribution system 150, which may include the entitlement token along with one or more software objects (e.g., firmware images) within a software update package that may be distributed to computing system 110 for installation. In some embodiments, for example, a software update package may contain special software for installation on components of a computing system (e.g., custom debug firmware, useful debugging tools, etc.) along with the entitlement token to allow the RoT protecting those components to perform such installation.

[0035] Further details regarding the structure, functionality, and / or operation of computing system 110 , token configuration system 140 , and software distribution system 150 are provided below.

[0036] Computing system 110 may include any system used for computing (e.g., performing computing tasks or operations) and may vary in size and complexity, including many different components, each of which may be configured to run its own set of software (e.g., including its own firmware). In some embodiments, for example, Figure 1 As shown, computing system 110 may include a system-level processing component or processing logic 112, and one or more peripheral components 114. For example, processing logic 112 may be or include a CPU, FPGA, ASIC, or other form of processing logic, and component 114 may be or include one or more additional processing components (e.g., one or more graphics processing units (GPUs), parallel processing units (PPUs), data processing units (DPUs), etc.), switches (e.g., Peripheral Component Interconnect Express (PCIe) switches, NVLink switches (or NVSwitches), etc.), controllers (e.g., memory controllers, etc.), communication interfaces, or other system components. In some embodiments, each component (or a subset thereof) of computing system 110 may be protected by a corresponding root of trust (RoT) component, RoT 115, which may perform a number of different security functions and / or provide a number of different security services for the component (or components) it protects (including RoT 115 itself). While RoT 115 may be shown as a discrete element separate from the components it protects, it will be appreciated that this is not the case. For example, in some embodiments, RoT 115 can be external to the components it protects, while in other embodiments, it can be integrated within or as part of the components it protects. In some embodiments, computing system 110 can also include a baseboard management controller (BMC) component, BMC 113, which can perform various management functions for computing system 110 and its components. Computing system 110 can be coupled to token configuration system 140 and / or software distribution system 150 via a communication network 160 (e.g., a local area network (LAN), a wide area network (WAN), the public Internet, and / or one or more other communication networks) and can communicate with token configuration system 140 and / or software distribution system 150, for example, using a network interface (or other communication interface thereof).

[0037] In some embodiments, components of computing system 110 (e.g., processing logic 112, BMC 113, peripheral components 114, and / or RoT 115) can be coupled to each other and can communicate with each other, for example, via communication bus 111a (e.g., using their communication interfaces). Although communication bus 111a is shown as a discrete communication bus 111a to which components can be coupled, communication bus 111a can represent multiple separate communication buses to which some or all components can be coupled and over which the components can communicate (e.g., using their respective communication interfaces). For example, in some embodiments, communication bus 111a can include a PCIe communication bus, an inter-integrated circuit (IC) bus, or a 111a bus. 2 C) a communication bus or one or more of a system management bus (SMBus), a serial peripheral interface (SPI) communication bus, and / or another communication bus to which a subset of the components (e.g., some or all) can be coupled and over which they can communicate (e.g., using a PCIe interface, I 2 C or SMBus interface, SPI interface and / or other communication interfaces thereof).

[0038] The components of computing system 110 may communicate with each other according to a communication protocol or a set of communication protocols (e.g., a protocol stack) that may control the manner in which such communication occurs (e.g., defining the signals or messages (or other data structures) to be exchanged and the order in which they are exchanged, e.g., to establish, conduct, and terminate communications). In some embodiments, for example, the components of computing system 110 may operate at least in part according to the PCIe protocol, I 2 C or SMBus protocol, SPI protocol or other communication protocols (e.g., other physical layer and / or data link layer protocols) can communicate with each other via the communication bus 111a. In some embodiments, the components of the computing system 110 can communicate with each other using one or more higher layer protocols (e.g., transport layer and / or application layer protocols), which can be implemented on top of one or more lower layer protocols (e.g., PCIe protocol, I2C protocol, etc.). 2 C or SMBus protocol, SPI protocol or other physical layer and / or data link layer protocol).

[0039] Each of the various components of computing system 110 (e.g., processing logic 112, BMC 113, peripheral components 114, and / or RoT 115) can run its own set of software, including, for example, its own firmware. In some embodiments, for example, each component of computing system 110 can be coupled to one or more memories (or other storage elements) on which the component's software (specific instances of which may be referred to as software objects, software images, or software code) can be stored. For example, in some embodiments, a component can be coupled to memory 116, which can be, for example, non-volatile memory such as flash memory, which can store the component's firmware image (or multiple firmware images). The component can be capable of loading and executing (or booting from) the firmware image stored in memory 116, for example, using its application processor (or other processing logic). While memory 116 may be shown as being external to the components to which it is coupled, it will be appreciated that this is not necessarily the case. In some embodiments, for example, memory 116 can be integrated within or part of the components to which it is coupled.

[0040] In some embodiments, the component's memory 116 may include multiple logically and / or physically separate memory elements on which the component's software may be stored. Figure 1 As shown, memory 116 may include a pair of independent memory elements, memory 116a and memory 116b, each of which may be used to store a firmware image for a component. For example, memory 116a may be used to store a first firmware image for a component (e.g., a primary firmware image), while memory 116b may be used to store a second firmware image for the component (e.g., a secondary firmware image or a backup firmware image). A component may boot from the firmware in memory 116 according to a specific boot order. In some embodiments, for example, a component may first attempt to boot from the firmware in memory 116a, and if the boot fails for some reason, then attempt to boot from the firmware in memory 116b.

[0041] In some embodiments, each component (or a subset thereof) of the computing system 110 can be protected by a corresponding root of trust (RoT) component, RoT 115, which can perform a number of different security functions and / or provide a number of different security services for the component (or components) it protects (including the RoT 115 itself). In some embodiments, the RoT 115 itself can include a number of components. In some embodiments, for example, the RoT 115 can include RoT-level processing logic (e.g., an embedded CPU, FPGA, ASIC, or other form of processing logic), one or more memories (or other storage elements) (e.g., read-only memory (ROM), one-time programmable (OTP) memory, embedded non-volatile memory such as embedded flash memory, data registers, or electronic fuses, or other secure memory or storage components), one or more communication interfaces (e.g., I 2 C or SMBus interface, SPI interface and / or other communication interface) and / or one or more other components.

[0042] In some embodiments, the RoT 115 and the component (or components) it protects may be coupled and capable of communicating with each other. In some embodiments, for example, the RoT 115 and the components it protects may communicate with each other via a communication bus 111b (e.g., I 2 C bus or SMBus) are coupled to each other and can use their respective communication interfaces (e.g., their I 2 In some embodiments, the RoT 115 and the components it protects may communicate with each other according to a communication protocol or a set of communication protocols (e.g., a protocol stack), which may control the manner in which such communication is performed. In some embodiments, for example, the RoT 115 and the components it protects may communicate with each other at least in part according to I 2 C or SMBus protocol or other communication protocols to communicate with each other.

[0043] In some embodiments, the RoT 115 may also be coupled to and able to communicate with the corresponding memory 116 of the component (or components) it protects (including the RoT 115 itself). In some embodiments, for example, the RoT 115 and memory 116 may be coupled to each other via a communication bus 111c (e.g., an SPI bus) and may communicate with each other via the communication bus 111c (e.g., an SPI bus) using their respective communication interfaces (e.g., their SPI interfaces). In some embodiments, the RoT 115 may communicate with the memory 116 according to a communication protocol or set of communication protocols (e.g., a protocol stack), which may control the manner in which such communication occurs. In some embodiments, for example, the RoT 115 may communicate with the memory 116 at least in part according to the SPI protocol or other communication protocols. In some embodiments, the RoT 115 may protect the memory 116 associated with the component. In some embodiments, for example, the memory 116 may be accessible via the RoT 115. For example, a component may load a software object (e.g., a firmware image) from the memory 116 by issuing a request or command to the RoT 115 and receiving a response therefrom. As another example, BMC 113 may install a software object (eg, a firmware image) to memory 116 by issuing a request or command to RoT 115 .

[0044] In some embodiments, the RoT 115 may allow external management of the RoT 115 itself, its protected components, and / or its memory 116 (e.g., the RoT 115 and / or its protected components). In some embodiments, for example, the RoT 115 may be externally managed by a management controller (e.g., the BMC 113) of the computing system 110. In some embodiments, for example, the BMC 113 may be externally managed via the communication bus 111a (e.g., via I 2 C bus or SMBus or SPI bus) is coupled to the RoT 115 and can use their respective communication interfaces (e.g., their I 2 C or SMBus interface or SPI interface) to communicate with RoT 115. In some embodiments, RoT 115 and BMC 113 can communicate with each other according to a communication protocol or a set of communication protocols (e.g., a protocol stack) that can control how such communication occurs.

[0045] In some embodiments, for example, RoT 115 and BMC 113 may be configured at least in part based on I 2C or SMBus protocol, SPI protocol or other communication protocols to communicate with each other. In some embodiments, RoT 115 and BMC 113 can use one or more higher layer protocols (e.g., transport and / or application layer protocols) that can be implemented on top of one or more lower layer protocols (e.g., on I 2 In some embodiments, for example, RoT 115 and BMC 113 may communicate with each other based at least in part on one or more standards developed and maintained by the Distributed Management Task Force (DMTF), which may promulgate standards for managing computing systems (e.g., computing system 110) and their components.

[0046] In some embodiments, for example, the RoT 115 and the BMC 113 can communicate with each other based on the Management Component Transport Protocol (MCTP). The MCTP protocol can be used to facilitate communication between a management controller (e.g., the BMC 113) and different components that it may be responsible for managing, for example, to support different management functions (e.g., monitoring and control functions). The MCTP protocol is an extensible protocol, for example, supporting the use of vendor-defined messages. The MCTP protocol is a transport protocol (or transport layer protocol) that can be used with different underlying communication buses. The MCTP protocol can be implemented on top of one or more other protocols, for example, on top of different physical and / or data link layer protocols (e.g., I 2 C or SMBus protocol, SPI protocol, PCIe protocol, etc.), and can support one or more higher-layer protocols.

[0047] In some embodiments, for example, the RoT 115 and the BMC 113 can communicate with each other according to the Platform Level Data Model (PLDM) standard (e.g., including the base specification and / or its extensions) and / or the Security Protocol and Data Model (SPDM) standard, which can be implemented on top of the MCTP protocol. The PLDM standard can define messages, data structures, and / or message exchange sequences for performing various management-related functions (e.g., for transferring software objects from the BMC 113 to the RoT 115 and / or updating software on the RoT 115 and / or its protected components). The SPDM standard can define messages, data structures, and / or message exchange sequences for performing various security-related functions (e.g., for establishing a secure communication session between the BMC 113 and the RoT 115, authenticating the hardware identity of the RoT 115 and / or its protected components, and / or measuring the software identity of the RoT 115 and / or its protected components).

[0048] As described above, the RoT 115 can perform a variety of different security functions and / or provide a variety of different security services for the components it protects (including the RoT 115 itself). For example, in some embodiments, the RoT 115 can perform or provide different storage, verification, update, measurement, and / or reporting functions and services for the components it protects (including the RoT 115 itself). In some embodiments, for example, the RoT 115 can control the software that can be loaded by the components (e.g., from the memory 116) and / or executed by the components (e.g., by their application processors). In some embodiments, for example, the RoT 115 can only allow components (including the RoT 115 itself) to load and / or execute trusted software code (e.g., trusted firmware images or software objects). For example, the software code can be digitally signed using a cryptographic key that can be bound to (e.g., uniquely associated with) a specific entity or organization and can be used to establish the provenance of the software code. Before allowing the software code to be loaded and / or executed, the RoT 115 can verify the digital signature to ensure that the software code can be trusted. In some embodiments, for example, RoT 115 may have one or more cryptographic keys (eg, stored in its secure memory, such as within a key storage area therein) that RoT 115 may use to verify the digital signature to determine whether it is authentic.

[0049] An entity or organization (e.g., a component manufacturer) may generate (or otherwise be uniquely associated with) a cryptographic key. For example, in some embodiments, the cryptographic key (or keys) may be an asymmetric cryptographic key, comprising a private key and a corresponding public key (which may be individually or collectively referred to as a cryptographic key). The cryptographic key (e.g., the public key) may be provided to and stored in the RoT 115 (e.g., when the RoT 115 and / or the components it protects are first manufactured or put into production). For example, in some embodiments, the cryptographic key (e.g., the public key) may be stored in its secure memory (e.g., in read-only memory (ROM), one-time programmable (OTP) memory, embedded non-volatile memory (e.g., embedded flash memory), or other secure memory or storage component thereof), such as as part of a secure key storage area therein. A software object may be signed using the cryptographic key (e.g., using the corresponding private key), wherein the digital signature is attached to (or otherwise coupled to) the software object in this process. The RoT 115 may be able to verify the digital signature of the software object using the cryptographic key stored thereon (e.g., the stored public key).

[0050] In some embodiments, RoT 115 can control the operation of the components it protects. In some embodiments, RoT 115 can control how the components it protects can execute software and / or how the components it protects can use hardware. In some embodiments, for example, RoT 115 can control whether certain hardware and / or software features, tools, functions, operating modes, etc. ("features") are available (e.g., enabled / disabled or locked / unlocked) on the components it protects. In some embodiments, for example, RoT 115 can prevent certain features of a software object (e.g., features natively present in a firmware image) from being used by a component (e.g., because such features could expose the component to attack, adversely affect the component's performance, or otherwise cause undesirable behavior). In some embodiments, for example, the component's application processor (or other processing logic) can communicate with RoT 115 to determine which features are enabled / disabled and can adjust operations accordingly, for example, by enabling / disabling appropriate features at runtime. For example, in some embodiments, RoT 115 can control whether fuse updates can be performed on the components it protects, whether cryptographic credentials can be changed on the components it protects, and / or whether pre-boot attestation can be performed on the components it protects. As additional examples, in some embodiments, RoT 115 may control whether the component's communication interfaces may be used (eg, whether a UART interface is enabled) and / or whether different network services are active (eg, whether a secure shell is enabled).

[0051] In some embodiments, the RoT 115 can control the software that can be installed (or loaded) onto the components it protects (including the RoT 115 itself), for example, onto the memory 116 associated therewith. In some embodiments, for example, the RoT 115 can only allow trusted software to be installed onto the components it protects. In some embodiments, for example, the RoT 115 can receive software objects (e.g., firmware images or other software objects) to be installed onto the components it protects. The software objects can be digitally signed using a cryptographic key that can be tied to (e.g., uniquely associated with) a specific entity or organization and can be used to establish the provenance of the software object. The RoT 115 can verify the digital signature to ensure that the software object is trustworthy and then store it in the memory 116 for use by the components. For example, in some embodiments, the RoT 115 can have one or more cryptographic keys (e.g., stored in its secure memory, such as a key store therein) that the RoT 115 can use to verify the digital signature to determine whether it is trustworthy.

[0052] In some embodiments, RoT 115 may be capable of generating an attestation report (e.g., using its processing logic) that may provide attestation regarding the identity and / or state of RoT 115 and / or the components it protects. In some embodiments, for example, RoT 115 may generate an attestation report as part of an end-to-end challenge-response process performed between token configuration system 140 and RoT 115, based on which token configuration system 140 may issue an entitlement token to RoT 115 (as discussed further herein). In some embodiments, for example, token configuration system 140 may solicit an attestation report from RoT 115, for example, by issuing an attestation report solicitation request (or solicitation request) to BMC 113, which in turn may issue an attestation report request (or attestation request) to RoT 115. In some embodiments, for example, an application engineer or other representative of component manufacturer 102 (e.g., to whom an end customer may have reported a problem or requested special software and / or enabled special features) may cause token configuration system 140 to issue an attestation report solicitation request to the BMC of a computing system. In some embodiments, the token configuration system 140 may include an authentication challenge (e.g., a random number generated by the token configuration system 140) as part of an attestation report request, which will be included in any attestation report provided by the RoT 115 in response to the request, and the BMC 113 may include it in the attestation request sent to the RoT 115.

[0053] In some embodiments, in response to receiving the attestation request, the RoT 115 may generate an attestation report that includes one or more measurements, such as, for example, an identity and / or state (e.g., current hardware and / or software state) of the RoT 115 or a component it protects. In some embodiments, for example, the attestation report may include measurements of immutable software code, mutable software code, boot phase, configuration data, and / or other state variables of the RoT 115 or a component it protects. In some embodiments, for example, the attestation report generated by the RoT 115 may include a serial number of the RoT 115 and / or a component it protects, a current firmware version on the RoT 115 and / or a component it protects, and / or other identity and / or state measurements.

[0054] In some embodiments, the attestation report generated by RoT 115 may include one or more additional parameters. In some embodiments, for example, RoT 115 may include an authentication challenge (e.g., a random number generated by token configuration system 140) for token configuration system 140, such as that which may have been included as part of a received attestation request (e.g., from BMC 113). In this manner, the attestation report may be used as an authentication response provided by RoT 115 to token configuration system 140 (e.g., as part of an end-to-end challenge-response performed therebetween).

[0055] In some embodiments, the attestation report generated by RoT 115 may include (another) authentication challenge (e.g., a random number generated by RoT 115), which will be included in any entitlement token issued by token configuration system 140 in response to the authentication challenge (e.g., as part of an end-to-end challenge-response performed therebetween). In this way, an entitlement token can be tied to a particular attestation report, allowing RoT 115 to ensure that the entitlement token is "fresh" and prevent so-called "replay" attacks. In some embodiments, for example, RoT 115 can maintain a current authentication challenge (e.g., in its memory) to include in generated attestation reports and verify received entitlement tokens (e.g., to ensure they match). In some embodiments, RoT 115 can update the authentication challenge (e.g., generate a new random number) under certain conditions (e.g., at each power cycle or boot, after successful installation of the entitlement token, and / or after a certain amount of time has passed). In this way, the authentication challenge can also be used to limit the lifespan of the entitlement token by automatically invalidating the entitlement token upon the occurrence of certain conditions.

[0056] In some embodiments, the attestation report generated by the RoT 115 can be signed using a cryptographic key unique to the RoT (e.g., a key based on a physically unclonable function (PUF)). In doing so, the attestation report (and the identity and / or state measurements contained therein) can be cryptographically bound to a specific RoT 115 and / or the components it protects. The attestation report can also serve as proof of possession of the RoT 115 and / or the components it protects. In this way, the token provisioning system 140, after verifying the attestation report, can securely issue entitlement tokens to a specific RoT 115 and / or control their use (e.g., by binding the entitlement token to the identity and / or state measurements (or a subset thereof) in the attestation report). In some embodiments, for example, the RoT 115 can calculate a message digest from the attestation report using a hashing algorithm (e.g., using MD5, SHA1, SHA256, or other hashing algorithms), and the RoT 115 can encrypt the message digest using a device-unique key. In some embodiments, the RoT 115 can append the encrypted message digest to the attestation report (or otherwise include it with the attestation report) to sign the attestation report. In some embodiments, RoT 115 may return a signed attestation report to BMC 113 (e.g., in response to the initial attestation request), and BMC 113 may, in turn, provide the signed attestation report to token configuration system 140 (e.g., in response to the initial solicitation request received by BMC 113). In some embodiments, BMC 113 and RoT 115 may establish a secure communication session before BMC 113 issues an attestation request to RoT 115 and RoT 115 provides the attestation report in response to the attestation request.

[0057] In some embodiments, the device-unique key of RoT 115 may be an asymmetric key comprising a private key and a public key. In some embodiments, RoT 115 may sign an attestation report using the device-unique private key. Token configuration system 140 may be able to verify the signed attestation report using a corresponding device-unique public key, which may be known to or provided to token configuration system 140. For example, in some embodiments, token configuration system 140 may maintain a mapping between a serial number of RoT 115 and a corresponding device-unique key (e.g., established when RoT 115 and / or the components it protects are first manufactured or put into production). In other embodiments, the device-unique public key may be provided to token configuration system 140 in a certificate (or certificate chain) issued to RoT 115 by a certificate authority (CA) trusted by token configuration system 140 (e.g., token configuration system 140 has a corresponding root certificate for the certificate (or certificate chain)). In some embodiments, for example, when the RoT 115 and / or the components it protects are first manufactured or put into production, the certificate (or certificate chain) may have been issued to the RoT 115 and may be stored by the RoT 115 (e.g., in its secure memory, such as within a key storage area therein). In some embodiments, the RoT 115 may provide the certificate (or certificate chain) and the device-unique key to the BMC 113 when establishing a secure communication session with the BMC 113 (e.g., where the BMC 113 may issue an attestation request and / or the RoT 115 may return a signed attestation report). In some embodiments, the BMC 113 may, in turn, provide the certificate (or certificate chain) to the token configuration system 140 (e.g., along with the attestation report).

[0058] In some embodiments, the RoT 115 may be capable of processing entitlement tokens issued to the RoT 115 by the token configuration system 140 (e.g., using its processing logic). In some embodiments, for example, the token configuration system 140 may issue an entitlement token to the RoT 115 that may authorize the RoT 115 and / or enable the RoT 115 to take certain actions with respect to the components it protects (including the RoT 115 itself). In some embodiments, the token configuration system 140 may issue different types of entitlement tokens that may authorize the RoT 115 and / or enable the RoT 115 to take different actions. For example, in some embodiments, an entitlement token may authorize the RoT 115 and / or enable the RoT 115 to effect changes to the software on the components it protects (including the RoT 115 itself). For convenience, such entitlement tokens may be referred to as software authorization tokens. In some embodiments, for example, a software authorization token may authorize RoT 115 and / or enable RoT 115 to install certain software (e.g., a custom firmware image, software tool, or other software object) onto the component it protects (e.g., onto its memory 116) and / or allow the component to load and execute software after installation (e.g., boot from a custom firmware image).

[0059] In some embodiments, for example, a software authorization token may include a cryptographic key not previously known to the RoT 115, which the RoT 115 may use to verify whether a particular software is trustworthy (e.g., so that a component can safely install and / or load and execute the software). This may allow a component manufacturer to sign a software object using a non-production key (e.g., a non-production private key), which the RoT 115 may verify using a cryptographic key provided by the software authorization token (e.g., a corresponding non-production public key). This may also allow the software object to be distributed separately from the software authorization token (e.g., using an existing software distribution system). In other embodiments, the software object (e.g., microcode, machine code, etc.) may be embedded or otherwise contained within the software authorization token itself. In this case, the RoT 115 may verify the software authorization token to determine whether the contained software object is trustworthy, and based on this, the RoT 115 may install the software object (e.g., on the RoT 115 itself or a component it protects).

[0060] In some embodiments, an entitlement token can be used to prevent the RoT 115 from installing certain software on a component and / or to allow a component to load and execute already installed software. For convenience, such an entitlement token can be referred to as a software revocation token. In some embodiments, for example, the software revocation token can identify a cryptographic key known to the RoT 115 to be revoked (e.g., possibly no longer trusted), such that software signed with the cryptographic key will no longer be verified by the RoT 115 for installation and / or use.

[0061] As another example, in some embodiments, an entitlement token may authorize RoT 115 and / or enable RoT 115 to configure software and / or hardware features of a component it protects. For convenience, such an entitlement token may be referred to as a feature configuration token. In some embodiments, for example, a feature configuration token may authorize RoT 115 to unlock or enable one or more features on a component it protects. In some embodiments, for example, a feature configuration token may identify one or more features of a software object that may be present on the component (e.g., features within a firmware image installed on the component and stored in memory 116), which RoT 115 may make available for use later (e.g., after the entitlement token is installed).

[0062] In some embodiments, the RoT 115 can perform a number of processing operations on the entitlement token, including, for example, receiving, verifying, installing, and / or uninstalling (or removing) the entitlement token (e.g., using its processing logic). In some embodiments, for example, the RoT 115 can receive an entitlement token issued by the token configuration system 140. In some embodiments, the entitlement token can be issued by the token configuration system 140 in response to an attestation report generated by the RoT 115. In some embodiments, the entitlement token can be provided to the BMC 113, which can determine the RoT 115 for which it is intended and forward the entitlement token to the appropriate RoT 115 for installation. In some embodiments, for example, the BMC 113 can provide the entitlement token to the appropriate RoT 115 as part of an entitlement token installation request or command (token install request) issued by the BMC 113.

[0063] In some embodiments, RoT 115 may attempt to verify a received entitlement token (e.g., as part of a token installation command issued by BMC 113) to determine whether it should be further processed (e.g., installed by RoT 115). In some embodiments, for example, RoT 115 may verify whether the entitlement token is trustworthy, intended for RoT 115, valid, and / or suitable for use by RoT 115. In some embodiments, for example, the entitlement token may have been cryptographically signed by token configuration system 140 when issued, e.g., using a cryptographic key known or verifiable by RoT 115. In some embodiments, for example, the entitlement token may have been signed using a cryptographic key of a component manufacturer (e.g., a private production key of the component manufacturer), for which a corresponding key (e.g., a public production key of the manufacturer) may have been provided and stored with RoT 115 (e.g., when RoT 115 and / or the component it protects was first manufactured or put into production). In some embodiments, RoT 115 may attempt to verify the digital signature of the entitlement token to determine its authenticity or unauthenticity, for example, using one or more cryptographic keys stored on RoT 115 (e.g., in its secure memory, such as in a key storage area therein), which may include a corresponding production key (e.g., a corresponding public production key). In some embodiments, for example, RoT 115 may calculate a message digest from the entitlement token (e.g., from the entitlement token data excluding the signature) using a hashing algorithm (e.g., using MD5, SHA1, SHA256, or other hashing algorithms). RoT 115 may decrypt the digital signature using the cryptographic key stored on RoT 115, and the result may be compared to the calculated message digest to determine whether they match. If the signature is successfully verified (e.g., if the results match), RoT 115 may further process the entitlement token (e.g., perform one or more additional verification steps and / or install the entitlement token). If the signature cannot be verified, RoT 115 may discard the entitlement token. In some embodiments, RoT 115 may notify BMC 113 of such a failure, eg, in a response sent thereto.

[0064] In some embodiments, RoT 115 may verify one or more additional parameters included in the entitlement token. In some embodiments, for example, the entitlement token may include one or more identity and / or state parameters (e.g., from the attestation report based on which it was issued) that can be used to identify RoT 115 and / or the component for which the entitlement token is intended and / or suitable for use. RoT 115 may compare the parameter values provided in the entitlement token with its identity and / or current state to determine whether they match. If the identity and / or state parameters are successfully verified (e.g., if they match the identity and / or current state of RoT 115), RoT 115 may further process the entitlement token (e.g., perform one or more additional verification steps and / or install the entitlement token). If the identity and / or state parameters are not successfully verified, RoT 115 may discard the entitlement token. In some embodiments, RoT 115 may notify BMC 113 of such failure, for example, in a response sent to BMC 113.

[0065] In some embodiments, the entitlement token may include an authentication response (e.g., an authentication challenge from the attestation report on which its issuance is based), and RoT 115 may compare the authentication response with the current authentication challenge of RoT 115 to determine whether they match. If the authentication response is successfully verified (e.g., if it matches the current authentication challenge of RoT 115), RoT 115 may further process the entitlement token (e.g., perform one or more additional verification steps and / or install the entitlement token). If the authentication response is not successfully verified, RoT 115 may discard the entitlement token. In some embodiments, RoT 115 may notify BMC 113 of such failure, for example, in a response sent to BMC 113. In some embodiments, if RoT 115 is able to successfully verify the entitlement token, it may continue to further process the entitlement token (e.g., install the entitlement token). In some embodiments, RoT 115 may notify BMC 113 that the entitlement token has been successfully verified, for example, in a response sent to BMC 113.

[0066] In some embodiments, RoT 115 may attempt to install an entitlement token after verifying the entitlement token. In some embodiments, RoT 115 may only allow installation of a single entitlement token at a time. In some embodiments, for example, RoT 115 may check whether an entitlement token is already installed before attempting to install (another) entitlement token. In some embodiments, if no existing entitlement token is detected, RoT 115 may continue to attempt to install the entitlement token.

[0067] In some embodiments, the process of installing an entitlement token may depend on the type of entitlement token. In some embodiments, RoT 115 may determine the type of entitlement token (e.g., based on a flag or field within its header) and process the entitlement token accordingly. In some embodiments, for example, when the entitlement token is a software authorization token that includes a cryptographic key, RoT 115 may parse the software authorization token and extract and store the cryptographic key contained therein (e.g., in a secure memory of RoT 115, such as a key storage area therein). RoT 115 may then be able to use the cryptographic key, for example, to verify that a software object is installed and / or allow a component to load and / or execute the software object (e.g., to boot from debug firmware or load and execute a debug tool). In some embodiments, RoT 115 may store the software authorization token (e.g., in its non-volatile memory) and may parse and extract the cryptographic key from the software authorization token at different events or under different conditions, such as each time RoT 115 attempts to verify that a software object is installed and / or allow a component to load and / or execute the software object. In some embodiments, when the entitlement token is a software authorization token that includes an embedded software object, RoT 115 may parse the software authorization token and extract and store the software object contained therein (e.g., in secure memory of RoT 115). RoT 115 may then proceed to install the software object (e.g., on RoT 115 itself or a component it protects), for example, by storing the software object in memory 116 (e.g., in a particular element thereof, such as memory 116 a or memory 116 b ) for subsequent use by a component (e.g., by RoT 115 or a component it protects).

[0068] In some embodiments, when the entitlement token is a software revocation token, the RoT 115 may parse the software revocation token and extract the cryptographic key contained therein. The RoT 115 may compare the extracted cryptographic key with a known cryptographic key stored on the RoT 115 (e.g., in a secure memory of the RoT 115, such as a key storage area therein), and if a match is found, may remove or otherwise disable use of the cryptographic key. In some embodiments, when the entitlement token is a functional configuration token, the RoT 115 may parse the functional configuration token and determine which functionalities are identified therein, and may subsequently configure (e.g., enable or disable) use of the identified functionalities (e.g., by setting or adjusting one or more software flags, register values, etc.). In some embodiments, the RoT 115 may store the functional configuration token (e.g., in its secure memory) and may parse the functional configuration token to determine which functionalities are to be configured at different events or under different conditions (e.g., at each boot or power cycle of the RoT 115 and / or its protected components). In some embodiments, RoT 115 may provide a response to BMC 113 indicating whether the installation of the entitlement token was successful or whether some error occurred during the installation.

[0069] In some embodiments, RoT 115 can uninstall (or remove) an entitlement token. In some embodiments, for example, once an entitlement token is no longer needed (e.g., once testing and verification by an end customer is complete), BMC 113 can issue an entitlement token uninstall request or command (or token removal request) instructing RoT 115 to remove the entitlement token. In some embodiments, the token removal request can identify the entitlement token to be removed, while in other embodiments, the token removal request can be interpreted as a request to remove any installed entitlement token (e.g., any entitlement token in the memory of RoT 115). In some embodiments, RoT 115 can notify BMC 113 of the success or failure of the token removal, for example, in a response sent to BMC 113.

[0070] In some embodiments, removing the entitlement token may involve reversing one or more other steps taken during installation of the entitlement token. In some embodiments, for example, uninstalling the entitlement token may involve removing or revoking cryptographic keys that may have been stored, removing software objects that may have been stored in memory, disabling one or more enabled features, and / or deleting the entitlement token from RoT 115 (e.g., from its non-volatile memory). In some embodiments, RoT 115 may attempt to revalidate the entitlement token at various events or under various conditions, and may remove the entitlement token if such revalidation is unsuccessful. In some embodiments, for example, RoT 115 may revalidate the entitlement token upon each boot or power cycle of RoT 115 and / or its protected components, after a software object (e.g., a new firmware image) is installed on RoT 115 and / or its protected components, after a specific amount of time has elapsed, and / or upon certain other events or under certain other conditions.

[0071] In some embodiments, the RoT 115 may be capable of installing software objects (e.g., firmware images or other software objects) onto the RoT 115 and / or the components it protects. In some embodiments, for example, the BMC 113 may receive a software update package (e.g., from the software distribution system 150) containing one or more software objects for installation on the corresponding RoT 115 or the components it protects. The BMC 113 may parse the software update package to identify software objects for one or more components managed by the BMC 113. In some embodiments, the BMC 113 may extract the identified software objects and provide them to the appropriate RoT 115 for installation on the RoT 115 or the components it protects. In some embodiments, for example, the BMC 113 may issue a software installation or update command (software installation command) to the RoT 115, instructing the RoT 115 to install the software object (e.g., on the RoT 115 itself or the components it protects). In some embodiments, the BMC 113 may provide the software object as part of the software installation command.

[0072] In some embodiments, in response to receiving a software object to be installed (e.g., as part of a software installation command issued by BMC 113), RoT 115 may attempt to verify the digital signature of the software object to ensure that the software object can be trusted using one or more cryptographic keys stored therein. In some cases, for example, a software object (e.g., a "secure" firmware update) may be signed using a production key, which may be provided to RoT 115 when RoT 115 or the component it protects is first manufactured or put into production. In other cases, a software object (e.g., custom debug firmware, useful debugging tools, etc.) may be signed using a non-production key (e.g., a debug key), which may be provided to RoT 115, for example, in a software authorization token installed thereon. In some embodiments, if the software object is successfully verified, RoT 115 may proceed with the installation, for example, by storing the software object in memory 116 (e.g., in a specific element thereof, such as memory 116a or memory 116b) for subsequent use by the component (e.g., by RoT 115 or the component it protects). In some embodiments, RoT 115 may notify BMC 113 of the success or failure of verification and / or installation, for example, in a response message sent to BMC 113. In some embodiments, when BMC 113 and RoT 115 communicate using the MCTP protocol and / or according to the PLDM protocol, the software object installation process (e.g., including issuing software installation commands, providing software objects, and notifying installation success or failure) may be affected by exchanging a sequence of one or more MCTP and / or PLDM messages (and / or data structures).

[0073] In some embodiments, BMC 113 may disable background copying on RoT 115 before attempting to install a software object or a specific type thereof (e.g., before installing a firmware image), for example, by issuing a background copy disable request. In some embodiments, disabling background copying on RoT 115 may prevent RoT 115 from installing the software object on a specific element of memory 116, for example, on memory 116 b. In some embodiments, for example, memory 116 b may be used to store auxiliary or fallback firmware images (e.g., production-signed firmware), and if, for some reason, installation of a firmware image (e.g., debug firmware) on memory 116 a fails, it may still be possible to fall back to (e.g., boot from) the firmware image in memory 116 b. In some embodiments, for example, when BMC 113 and RoT 115 communicate using the MCTP protocol, background copying may be disabled by sending a corresponding MCTP message (e.g., a Vendor Defined Message (VDM)). In some embodiments, in response to receiving the background replication disable request from BMC 113, RoT 115 may provide a response indicating whether background replication was successfully disabled (or unsuccessfully disabled). In some embodiments, for example, when BMC 113 and RoT 115 communicate using the MCTP protocol, RoT 115 may send a corresponding MCTP message (e.g., VDM) in response. In some embodiments, if background replication is unsuccessfully disabled, BMC 113 may not issue a software installation command to RoT 115.

[0074] In some embodiments, computing system 110 may include a management controller, such as BMC 113, which may be used to perform various management functions for computing system 110 and its components (e.g., for itself, processing logic 112, peripheral components 114, and / or RoT 115). In some embodiments, BMC 113 itself may include multiple components. In some embodiments, for example, BMC 113 may include BMC-level processing logic (e.g., an embedded CPU, FPGA, ASIC, or other form of processing logic), one or more memories (or other storage elements), including, for example, memory 116, one or more communication interfaces (e.g., PCIe interfaces, I / O interfaces), and / or a plurality of communication interfaces. 2C or SMBus interface, SPI interface, universal serial bus (USB) interface, network communication interface, and / or other communication interface) and / or one or more other components. BMC 113 can be coupled to other components of computing system 110 (e.g., processing logic 112, peripheral components 114, and / or RoT 115), for example, via communication bus 111 a (e.g., using their respective communication interfaces) and can communicate with other components of computing system 110 (e.g., processing logic 112, peripheral components 114, and / or RoT 115). In some embodiments, BMC 113 and its manageable components can communicate with each other according to a communication protocol or a set of communication protocols (e.g., a protocol stack), which can control the manner in which such communication is conducted.

[0075] For example, in some embodiments, the BMC 113 may use its respective communication interface (e.g., its I 2 C or SMBus interface or SPI interface) through I 2 C bus or SMBus or SPI bus (or other communication bus) is coupled to RoT 115 and can communicate with RoT 115. BMC 113 and RoT 115 can be based at least in part on I 2 C or SMBus protocol or SPI protocol (or some other communication protocol) to communicate with each other. In some embodiments, BMC 113 and RoT 115 can use one or more high-level protocols to communicate with each other, for example, these high-level protocols can be used in I 2 C or SMBus protocol, SPI protocol, or other low-layer protocol (e.g., over other physical layer and / or data link layer protocols). In some embodiments, for example, BMC 113 and RoT 115 can communicate with each other at least in part according to one or more standards developed and maintained by the Distributed Management Task Force (DMTF).

[0076] In some embodiments, for example, the RoT 115 and the BMC 113 can communicate with each other based on the Management Component Transport Protocol (MCTP). The MCTP protocol can be used to facilitate communication between a management controller (e.g., the BMC 113) and the different components it is responsible for managing (e.g., the RoT 115) to support different monitoring and control functions. The MCTP protocol is an extensible protocol, for example, it supports the use of vendor-defined messages. The MCTP protocol is a transport protocol (or transport layer protocol) that can be used to facilitate communication over different underlying communication buses. The MCTP protocol can be implemented on top of one or more other protocols, for example, different physical and data link layer protocols (e.g., I 2 C or SMBus protocol, PCIe protocol, etc.), and may support one or more higher-layer protocols.

[0077] In some embodiments, for example, the BMC 113 and the RoT 115 can communicate with each other according to the Platform Level Data Model (PLDM) standard (e.g., including the base specification and / or its extensions) and / or the Security Protocol and Data Model (SPDM) standard, which can be implemented on top of the MCTP protocol. For example, the PLDM standard can define messages, data structures (or data objects), and / or message exchange sequences for performing various management-related functions (e.g., for transferring software objects from the BMC 113 to the RoT 115 and / or updating software on the RoT 115 and / or its protected components). The SPDM standard can define messages, data structures (or data objects), and / or message exchange sequences for performing various security-related functions (e.g., for establishing a secure communication session between the BMC 113 and the RoT 115, authenticating the hardware identity of the RoT 115 and / or the components they protect, and / or measuring the software identity of the RoT 115 and / or the components they protect).

[0078] In some embodiments, the BMC 113 itself can be externally managed or controlled. In some embodiments, for example, the BMC 113 can provide an externally facing interface (e.g., a Web services-based interface) through which the computing system 110 and its components can be managed. In some embodiments, for example, the BMC 113 can provide an application programming interface (API) that can expose one or more services through which management operations can be performed (e.g., by exchanging messages therewith). In some embodiments, for example, the BMC 113 can provide a Redfish API (e.g., implemented according to the Redfish standard, including the base specification and / or its extensions) that exposes one or more resources (e.g., one or more services) through which management operations can be performed (e.g., by exchanging messages according to the Redfish protocol, e.g., using the Hypertext Transfer Protocol (HTTP), the Transmission Control Protocol (TCP), and / or the Internet Protocol (IP)).

[0079] In some embodiments, the BMC 113 may be able to solicit attestation reports (e.g., using its processing logic) from the RoTs 115 it manages. In some embodiments, for example, the token configuration system 140 may issue entitlement tokens based on an end-to-end challenge-response process performed between the token configuration system 140 and one or more RoTs 115 of the computing system 110. As part of the entitlement token issuance process, the token configuration system 140 may solicit attestation reports from each RoT 115 (e.g., providing attestation regarding the identity and / or state of the RoT 115 and / or the components it protects, based on which the token configuration system 140 may issue an entitlement token).

[0080] In some embodiments, the BMC 113 may provide an attestation report solicitation service to help facilitate the solicitation of attestation reports from the RoT 115 it manages. In some embodiments, for example, the token configuration system 140 may be able to issue an attestation report solicitation request to the BMC 113 through the attestation report solicitation service. In some embodiments, for example, when the BMC 113 provides an external-facing interface (e.g., a Redfish API or a Redfish service), the token configuration system 140 may invoke the attestation report solicitation service by sending a message to the interface (e.g., by sending an HTTP request message, such as an HTTP GET message, to access the attestation report solicitation service). In some embodiments, the token configuration system 140 may include an authentication challenge (e.g., a random number generated by the token configuration system 140) as part of the attestation report solicitation request to be included in any attestation report provided in response to the request. In some embodiments, in response to receiving the attestation report request from the token configuration system 140, the BMC 113 may notify the token configuration system 140 that the attestation report solicitation request has been received and / or that the attestation report solicitation process (or task) has been initiated. In some embodiments, for example, when an attestation report solicitation request is received by an attestation report solicitation service, the service may provide a notification to the token configuration system 140 in a response message (eg, in an HTTP response message).

[0081] In some embodiments, in response to receiving an attestation report solicitation request from the token configuration system 140, the BMC 113 may request an attestation report from each RoT 115 (or a subset thereof) that it manages. In some embodiments, for example, the BMC 113 may issue an attestation report request (or attestation request) to each RoT 115, requesting attestation of the identity and / or state of the RoT 115 and / or its protected components, which attestation may be provided as an attestation report. In some embodiments, the BMC 113 may include the authentication challenge from the attestation report solicitation request received by the BMC 113 (e.g., from the token configuration system 140) as part of the attestation request issued to the RoT 115, so that the RoT 115 includes it as part of its returned attestation report. In some embodiments, in response to receiving the attestation request from the BMC 113, the RoT 115 may generate a signed attestation report (as described herein), which the RoT 115 may return to the BMC 113 (e.g., in response to the issued attestation request). In some embodiments, the BMC 113 and the RoT 115 may establish a secure communication session before exchanging attestation requests and attestation reports between the BMC 113 and the RoT 115 .

[0082] As an illustrative example, in some embodiments where the BMC 113 and the RoT 115 can communicate with each other using the SPDM protocol (e.g., over the MCTP protocol and the SPI protocol), the attestation report request process can be effected by exchanging a sequence of one or more MCTP and / or SPDM messages (and / or data structures). In some embodiments, for example, the BMC 113 and the RoT 115 can exchange one or more message sequences to negotiate and establish a secure communication session. In some embodiments, for example, the BMC 113 can send a GET_VERSION message, and the RoT 115 can respond with a VERSION message to discover which SPDM version(s) are jointly supported. The BMC 113 can then send a GET_CAPABILITIES message, and the RoT 115 can respond with a CAPABILITIES message to determine which capabilities the RoT 115 supports (e.g., whether it supports measurement and / or authentication, its timeout rate, etc.). The BMC 113 may then send a NEGOTIATE_ALGORITHMS message advertising the cryptographic algorithms supported by the BMC 113, and the RoT 115 may respond with an ALGORITHMS message selecting the cryptographic algorithm to be used for the communication session.

[0083] In some embodiments, BMC 113 can also authenticate RoT 115. In some embodiments, for example, BMC 113 can send a GET_DIGESTS message, and RoT 115 can respond with a DIGEST message containing digests of different signing certificates (or certificate chains) available on RoT 115. BMC 113 can then request a specific certificate (or certificate chain) by exchanging GET_CERTIFICATE request messages and CERTIFICATE response messages (the number of which may depend on the size of the certificate or certificate chain), and RoT 115 can respond with the specific certificate (or certificate chain). In some embodiments, the certificate (or certificate chain) provided by RoT 115 may include a device-unique cryptographic key (e.g., a device-unique public key of RoT 115), which BMC 113 can use to verify the signature on subsequent messages received from RoT 115. In some embodiments, for example, the certificate may be issued to the RoT 115 by a certificate authority trusted by the BMC 113, enabling it to verify the certificate and its contents (e.g., using the public key of the certificate authority known to the BMC 113). In some embodiments, for example, the BMC 113 may already be equipped with a certificate (or a root certificate of a certificate chain) enabling it to verify the certificate and its contents. The BMC 113 may then send a CHALLENGE message (e.g., containing a random number generated by the BMC 113), and the RoT 115 may respond with a CHALLENGE_AUTH message signed by the RoT 115 using a cryptographic key corresponding to the particular certificate (e.g., a corresponding device-unique private key of the RoT 115), which the BMC 113 may verify to authenticate the RoT 115.

[0084] In some embodiments, once secure communication has been established, BMC 113 may issue an attestation report request. In some embodiments, for example, BMC 113 may send a GET_MEASUREMENTS message to RoT 115 requesting an attestation report, and RoT 115 may respond with a MEASUREMENT message containing the attestation report. In some embodiments, the GET_MEASUREMENTS message may include a measurement operation parameter requesting a measurement at a specific index value (e.g., 0x32 or 50), which RoT 115 may interpret as a request for an attestation report. In some embodiments, the GET_MEASUREMENT message may include an authentication challenge from the attestation report solicitation request received by BMC 113, which may be included in the MEASUREMENT message provided in the attestation report and / or the response. In some embodiments, the MEASUREMENT message (or attestation report response message) may be signed by RoT 115 (e.g., using a device-unique cryptographic key), for example, by appending a signature thereto. In some embodiments, a signature may be present on both the attestation request (e.g., a GET_MEASUREMENT request message) and the attestation report provided in the response sent in response (e.g., a MEASUREMENT message) (collectively, a MEASUREMENT "record").

[0085] In some embodiments, BMC 113 may determine whether an entitlement token is already installed on RoT 115 before issuing an authentication request to RoT 115. This may be used, for example, to prevent the issuance and installation of new entitlement tokens to RoT 115. In some embodiments, for example, BMC 113 may request the entitlement token status from each RoT 115 it manages. In some embodiments, for example, BMC 113 may issue an entitlement token status request to each RoT 115, requesting the RoT 115 to provide the serial number of RoT 115 and / or its protected components, indicating whether RoT 115 has any entitlement tokens installed, and / or indicating the fuse status of RoT 115 (e.g., whether it is production-fed, development-fed, debug-fed, etc.). In some embodiments, for example, when BMC 113 and RoT 115 communicate using the MCTP protocol, the entitlement token status request may be issued by sending a corresponding MCTP message (e.g., a Vendor Defined Message (VDM)). In some embodiments, RoT 115 may provide an entitlement token status response with the requested information in response to receiving the entitlement token status request from BMC 113. In some embodiments, for example, when BMC 113 and RoT 115 communicate using the MCTP protocol, RoT 115 may send an MCTP message (e.g., a VDM) in response, which may include, for example, the serial number of RoT 115 and / or the components it protects, an indication of whether RoT 115 has any entitlement tokens installed, and / or an indication of the fuse status of RoT 115 (e.g., whether it is production-flash, development-flash, debug-flash, etc.).

[0086] In some embodiments, the BMC 113 may provide a signed attestation report received from the RoT 115 to the token configuration system 140 (e.g., in response to an attestation report solicitation request). In some embodiments, the BMC 113 may append (or otherwise couple) a signing certificate (or certificate chain) to each attestation report containing the device-unique key of the RoT 115 that signed the attestation report before returning the attestation report to the token configuration system 140. In some embodiments, for example, the certificate may have been provided to the BMC 113 by the RoT 115 (e.g., as part of establishing communication between the two). In some embodiments, when the RoT 115 provides the attestation report in a signed response message signed by the attestation request message and the attestation response message (or attestation report record), the BMC 113 may return the entire record to the token configuration system 140. In such an embodiment, a signing certificate (or certificate chain) containing a device-unique key of the RoT 115 (e.g., signing the attestation report and / or attestation report response message) may be attached to the attestation report response message or record (rather than the attestation report itself contained therein) before the record is provided to the token configuration system 140. In some embodiments, the BMC 113 may aggregate the signed attestation reports (or attestation report records) received back from each RoT 115 it manages (which, in some embodiments, may include the corresponding signing certificates of the respective RoTs 115) to generate an attestation report set. In some embodiments, the BMC 113 may return the attestation report set to the token configuration system 140 (e.g., in response to the attestation report solicitation request initially received). In some embodiments, the BMC 113 may record (or cache) the identity of the RoT 115 that received the attestation report, which the BMC 113 may later use to facilitate the distribution and installation of the entitlement token received in response (e.g., from the token configuration system 140) on the appropriate RoT 115 (e.g., the RoT 115 for which the entitlement token is intended). In some embodiments, for example, BMC 113 may maintain a mapping between a globally unique device identifier of RoT 115 (e.g., a universally unique identifier (UUID) of RoT 115) obtained from RoT 115 (e.g., by exchanging MCTP control messages therewith) and serial numbers of RoT 115 and / or components it protects obtained from an attestation report provided by RoT 115. In some embodiments, an entitlement token issued in response to the attestation report may specify the serial number of RoT 115 and / or the component it is intended for, based on which BMC 113 may be able to determine a corresponding device identifier for which the entitlement token should be provided for installation (e.g., from the recorded mapping).

[0087] In some embodiments, the token configuration system 140 may process each attestation report returned by the BMC 113 (e.g., each attestation report in an attestation report set) and (e.g., after verifying the attestation report and / or satisfying one or more policy criteria) generate an entitlement token for the RoT 115 that generated the corresponding attestation report. In some embodiments, the token configuration system 140 may sign the entitlement token, for example, using a cryptographic key known or verifiable by the RoT 115 (e.g., using a production key). In some embodiments, the generated entitlement token may be returned to the BMC 113 for installation on the corresponding RoT 115 managed by it (e.g., issuing the entitlement token to it). In some embodiments, the token configuration system 140 may aggregate multiple entitlement tokens (e.g., once all attestation reports in an attestation report set have been processed and the appropriate entitlement tokens have been generated and signed) to generate an entitlement token set, which may be returned to the BMC 113 for decomposition and installation on the corresponding RoT 115 managed by it. In some embodiments, the token configuration system 140 may provide an entitlement token (or set of entitlement tokens) to the BMC 113 for installation on a corresponding RoT 115 (or multiple corresponding RoTs 115 ) managed by the BMC 113 .

[0088] In some embodiments, for example, the BMC 113 may provide an entitlement token installation service (or token installation service) to help manage the distribution and installation of entitlement tokens to the RoT 115. In some embodiments, for example, the token configuration system 140 may be able to issue an entitlement token installation request (or token installation request) to the BMC 113 via the entitlement token installation service. In some embodiments, the entitlement token (or set of entitlement tokens) may be provided as part of the token installation request. In some embodiments, for example, when the BMC 113 provides an externally facing interface (e.g., a Redfish API or Redfish service), the token configuration system 140 may invoke the entitlement token installation service by sending a message to the interface (e.g., by sending an HTTP request message, such as an HTTP Get (GET) message, to access the entitlement token installation service). In some embodiments, the token configuration system 140 may include the entitlement token (or set of entitlement tokens) as part of the message.

[0089] In some embodiments, the BMC 113 may process the received entitlement token to determine the RoT 115 for which it is intended and provide it to the identified RoT 115 for installation. In some embodiments, for example, the BMC 113 may have recorded (or cached) the identity of the RoT 115 from which the attestation report was received. In some embodiments, for example, the BMC 113 may maintain a mapping of a globally unique device identifier (e.g., a UUID) of the RoT 115 and the serial numbers of the RoT 115 and / or the components it protects. In some embodiments, the BMC 113 may parse the received entitlement token and extract the serial number specified therein (e.g., the serial number of the RoT 115 and / or the components it protects). The BMC 113 may match the extracted serial number with the corresponding device identifier (e.g., from the recorded mapping) to identify the RoT 115 for which the entitlement token should be provided for installation.

[0090] In some embodiments, the BMC 113 may issue an entitlement token installation command to the identified RoT 115 and provide the entitlement token to the RoT 115 for installation (e.g., as part of the entitlement token installation command). In some embodiments, for example, when the BMC 113 and the RoT 115 communicate using the MCTP protocol, the entitlement token installation command may be issued by sending a corresponding MCTP message (e.g., a Vendor Defined Message (VDM)), which may include the entitlement token as part of the message payload. In some embodiments, the RoT 115 may attempt to verify the entitlement token and, if successful, attempt to install the entitlement token (e.g., as described herein). In some embodiments, the RoT 115 may notify the BMC 113 of whether the RoT 115 succeeded or failed in verifying and / or installing the entitlement token. In some embodiments, for example, when the BMC 113 and the RoT 115 communicate using the MCTP protocol, the RoT 115 may send an MCTP message (e.g., a VDM) in response, which may include a status code indicating success or failure (and, in some cases, a specific error or reason for failure). In some embodiments, when BMC 113 receives a set of entitlement tokens, it may extract and process each entitlement contained therein (eg, in a manner similar to that just described).

[0091] In some embodiments, BMC 113 may determine whether an entitlement token is already installed on RoT 115 before issuing an entitlement token installation command to RoT 115. This may be used, for example, to prevent the installation of a new entitlement token on RoT 115. In some embodiments, for example, BMC 113 may request the entitlement token status from each RoT 115 it manages. In some embodiments, for example, BMC 113 may issue an entitlement token status request to each RoT 115, requesting the RoT 115 to provide the serial number of RoT 115 and / or its protected components, indicating whether RoT 115 has any entitlement tokens installed, and / or indicating the fuse status of RoT 115 (e.g., whether it is production-flash, development-flash, debug-flash, etc.). In some embodiments, for example, when BMC 113 and RoT 115 communicate using the MCTP protocol, the entitlement token status request may be issued by sending a corresponding MCTP message (e.g., a Vendor Defined Message (VDM)). In some embodiments, in response to receiving the entitlement token status request from BMC 113, RoT 115 may provide an entitlement token status response with the requested information. In some embodiments, for example, when BMC 113 and RoT 115 communicate using the MCTP protocol, RoT 115 may send an MCTP message (e.g., a VDM) in response, which may include, for example, the serial number of RoT 115 and / or the components it protects, an indication of whether RoT 115 has any entitlement tokens installed, and / or an indication of the fuse status of RoT 115 (e.g., whether it is production-flash, development-flash, debug-flash, etc.).

[0092] In some embodiments, BMC 113 may disable background copying on RoT 115 before attempting to install an entitlement token or a specific type of entitlement token (e.g., before installing a software authorization token). In some embodiments, disabling background copying on RoT 115 may prevent RoT 115 from installing software objects on memory 116, such as on memory 116b. In some embodiments, for example, memory 116b may be used to store auxiliary or fallback firmware images (e.g., production-signed firmware), and if, for some reason, installation of a firmware image (e.g., debug firmware) on memory 116a fails, it may still be possible to fall back to (e.g., boot from) the firmware image in memory 116b. In some embodiments, for example, when BMC 113 and RoT 115 communicate using the MCTP protocol, background copying may be disabled by sending a corresponding MCTP message (e.g., a Vendor Defined Message (VDM)). In some embodiments, in response to receiving a background copy disable request from BMC 113, RoT 115 may provide a response indicating whether background copying was successfully disabled (or unsuccessfully disabled). In some embodiments, for example, when BMC 113 and RoT 115 communicate using the MCTP protocol, RoT 115 may send a corresponding MCTP message (e.g., VDM) in response. In some embodiments, if background replication is not successfully disabled, BMC 113 may not issue an entitlement token installation command to RoT 115.

[0093] In some embodiments, the BMC 113 may allow external monitoring of the entitlement tokens installed on the RoTs 115 it manages, for example, as part of an entitlement token status solicitation service. In some embodiments, for example, the token configuration system 140 may issue an entitlement token status solicitation request to the BMC 113 to request the entitlement token status of the BMC 113 and / or the RoTs 115 it manages (e.g., whether any RoTs 115 managed by the BMC 113 have an entitlement token installed, which RoTs 115 have debug tokens installed, and / or the fuse status of each RoT 115). In some embodiments, for example, when the BMC 113 provides an externally facing interface (e.g., a Redfish API or Redfish service), the token configuration system 140 may invoke the entitlement token status solicitation service by sending a message to the interface (e.g., by sending an HTTP request message, such as an HTTP GET message, to access the entitlement token status solicitation service). In some embodiments, in response to receiving the entitlement token status solicitation request from token configuration system 140, BMC 113 may notify token configuration system 140 that the entitlement token status solicitation request has been received and / or that the entitlement token status solicitation process (or task) has been initiated. In some embodiments, for example, when the entitlement token status solicitation request is received by an entitlement token status solicitation service, the service may provide a notification to token configuration system 140 in a response message (e.g., in an HTTP response message).

[0094] In some embodiments, in response to receiving an entitlement token status solicitation request from the token configuration system 140, the BMC 113 may request the entitlement token status from each RoT 115 it manages. In some embodiments, for example, the BMC 113 may issue an entitlement token status request to each RoT 115, requesting the RoT 115 to provide the serial number of the RoT 115 and / or the components it protects, indicate whether the RoT 115 has any entitlement tokens installed, and / or indicate the fuse status of the RoT 115 (e.g., whether it is production-fuse, development-fuse, debug-fuse, etc.). In some embodiments, for example, when the BMC 113 and the RoT 115 communicate using the MCTP protocol, the entitlement token status request may be issued by sending a corresponding MCTP message (e.g., a Vendor Defined Message (VDM)). In some embodiments, in response to receiving the entitlement token status request from the BMC 113, the RoT 115 may provide an entitlement token status response with the requested information. In some embodiments, for example, when the BMC 113 and the RoT 115 communicate using the MCTP protocol, the RoT 115 may send an MCTP message (e.g., a VDM) in response, which may include, for example, a serial number of the RoT 115 and / or a component it protects, an indication of whether the RoT 115 has any entitlement tokens installed, and / or an indication of the fuse status of the RoT 115 (e.g., whether it is production-fuse, development-fuse, debug-fuse, etc.).

[0095] In some embodiments, BMC 113 may receive an entitlement token (or a set of entitlement tokens) for installation as part of a software update package. In some embodiments, for example, token configuration system 140 may provide the entitlement token (or set of entitlement tokens) it generates to software distribution system 150, which may include the entitlement token (or set of entitlement tokens) as part of the software update package. In some embodiments, the software update package may include one or more software objects (e.g., firmware images) for installation on BMC 113 and / or its managed components (e.g., on processing logic 112, peripheral components 114, and / or RoT 115). In some embodiments, the software objects included in the software update package may be associated with an entitlement token included in the software update package (e.g., the entitlement token may authorize RoT 115 to install). In some embodiments, software distribution system 150 may distribute the software update package with the entitlement token (or set of entitlement tokens) to BMC 113 for installation. In some embodiments, when an entitlement token (or set of entitlement tokens) is provided in a software update package, BMC 113 may determine that the entitlement token (or set of entitlement tokens) is present in the software update and extract it for further processing (e.g., in a manner similar to that described above). In some embodiments, the BMC may extract and process the set of entitlement tokens before processing the rest of its contents (e.g., before installing any software objects contained therein).

[0096] In some embodiments, BMC 113 can provide a software update service to help facilitate the distribution and installation of software on components managed by BMC 113 (e.g., on processing logic 112, peripheral components 114, and / or RoT 115). In some embodiments, for example, software distribution system 150 can provide software update packages to BMC 113 for installation on its components. In some embodiments, for example, when BMC 113 provides an externally facing interface (e.g., a Redfish API or Redfish service), software distribution system 150 can invoke the software update service by sending a message to the interface (e.g., by sending an HTTP request message, such as an HTTP GET message, to access the software update service). In some embodiments, software distribution system 150 can include the software update package as part of the message.

[0097] In some embodiments, the software update service may operate in accordance with a PLDM standard (e.g., PLDM, including the Firmware Update Specification). The PLDM standard may define, among other things, the structure of a software update package and how BMC 113 (via its PLDM handler) processes the package, e.g., extracting and installing the software objects contained therein. A PLDM software update package (or PLDM package) may, for example, include a package header and one or more software objects (e.g., firmware images). The package header may include a header information section (e.g., describing the package version, date, etc.), a component identifier record (describing the component targeted for the update, including downstream components), package content information (e.g., describing the software image contained in the package, including, for example, its classification, offset, size, and version), and a checksum. In some embodiments, an entitlement token (or set of entitlement tokens) may be included in a PLDM package as a "virtual" software object intended for a "virtual" component. In some embodiments, for example, a special component identifier (eg, a specific UUID) and / or a software object identifier (eg, 0xDEAD or 57005) may be used in the PLDM header to indicate that the software object is an entitlement token (or set of entitlement tokens).

[0098] In some embodiments, upon receiving a software update package (e.g., via a request to a software update service), BMC 113 may attempt to process the software update package (e.g., using its PLDM handler). In some embodiments, BMC 113 may inspect the software update package to determine whether it contains an entitlement token (or set of entitlement tokens). In some embodiments, for example, BMC 113 may parse the packet header to identify a virtual software object within the package containing the entitlement token (or set of entitlement tokens). In some embodiments, for example, the entitlement token (or set of entitlement tokens) may be identified by a special component identifier (e.g., a specific virtual component UUID) and / or a special software object identifier (e.g., 0xDEAD or 57005) within the packet header. In some embodiments, BMC 113 may extract the identified software object containing the entitlement token (or set of entitlement tokens) (e.g., based on relevant packet information in the header, such as the packet offset and object size), and provide it to the entitlement token installation service for processing (e.g., as described above). In some embodiments, BMC 113 may inspect the software update package to determine whether it contains an entitlement token (or set of entitlement tokens) and may extract and process the entitlement token (or set of entitlement tokens) before processing the rest of the software update package (e.g., before installing any other software objects contained therein).

[0099] In some embodiments, after extracting and processing all entitlement tokens (or sets of entitlement tokens) in the software update package, BMC 113 may process the remaining software objects in the software update package. In some embodiments, for example, BMC 113 may parse the package header to identify one or more software objects in the software update package intended for one or more components managed by BMC 113. In some embodiments, BMC 113 may extract the identified software objects and provide them to the appropriate RoT 115 for installation on the RoT 115 or the components they protect. In some embodiments, for example, BMC 113 may issue a software installation or update command (software installation command) to RoT 115, instructing the RoT to install the software objects (e.g., on the RoT 115 itself or the components it protects). In some embodiments, BMC 113 may provide the software objects as part of the software installation command. In some embodiments, in response to receiving the software objects to be installed (e.g., as part of the software installation command issued by BMC 113), RoT 115 may attempt to verify and (if successful) install the software objects (e.g., as described above). In some embodiments, RoT 115 may notify BMC 113 of the success or failure of verification and / or installation, eg, in a response message sent to BMC 113 (eg, as previously described).

[0100] In some embodiments, if BMC 113 examines the software update package and determines that it does not contain an entitlement token (or set of entitlement tokens), this can be interpreted as an indication that the RoT 115 managed by BMC 113 no longer requires the entitlement token. In some embodiments, BMC 113 can then issue a token removal request to each RoT 115 managed by BMC 113, instructing RoT 115 to remove any entitlement tokens installed thereon. In some embodiments, for example, when BMC 113 and RoT 115 communicate using the MCTP protocol, an entitlement token status request can be issued by sending a corresponding MCTP message (e.g., a Vendor Defined Message (VDM)). In some embodiments, RoT 115 can notify BMC 113 of the success or failure of the token removal, for example, in a response sent thereto. In some embodiments, for example, when BMC 113 and RoT 115 communicate using the MCTP protocol, RoT 115 can send an MCTP message (e.g., a VDM) in response, which can, for example, include a status code indicating success or failure (and, in some cases, a specific error or reason for failure).

[0101] In some embodiments, computing system 110 can be coupled to and capable of communicating with token configuration system 140. In some embodiments, token configuration system 140 can include one or more components, including, for example, a system-level processing component (e.g., a CPU, FPGA, ASIC, etc.), one or more additional processing components, switches, controllers, communication interfaces, and other system components. In some embodiments, token configuration system 140 can also be coupled to and capable of communicating with software distribution system 150 via communication network 170 (e.g., a LAN, a WAN, the public Internet, and / or one or more other communication networks). Although shown as separate communication networks, in some embodiments, communication network 160 and communication network 170 can overlap (e.g., fully or partially overlap) with each other.

[0102] In some embodiments, token configuration system 140 may be used to issue entitlement tokens to RoT 115 of computing system 110 (e.g., using its processing logic), which may authorize RoT 115 and / or enable RoT 115 to take certain actions (e.g., changes that affect software and / or functionality available on the components) with respect to the components they protect. In some cases, for example, a component manufacturer may wish to modify software and / or enable functionality on one or more components of computing system 110 (or multiple computing systems 110), which may be maintained and / or operated by the component manufacturer's end customers, for example. For example, a component manufacturer may wish to provide an end customer with special software for one or more components of computing system 110 (e.g., custom debug firmware, useful debugging tools, etc.) and / or enable certain features on one or more components of computing system 110 (e.g., detailed logging, ultra-high frequency operation, unlimited hash rate computation, etc.), for example, to allow the end customer to test, verify, and / or qualify computing system 110 and / or its components, evaluate and / or resolve any issues that may arise with the components (e.g., when integrating them into computing system 110), or support certain applications or workloads (e.g., HPC applications or workloads). In this case, the component manufacturer may use token configuration system 140 to issue an entitlement token to RoT 115 to protect the component for which the software is intended and / or the component for which the features are to be enabled.

[0103] In some embodiments, for example, token configuration system 140 can issue entitlement tokens based on an end-to-end challenge-response process performed between token configuration system 140 and one or more RoTs 115 of computing system 110. In some embodiments, for example, token configuration system 140 can request an attestation report from each RoT 115, which can provide attestation regarding the identity and / or status of RoT 115 and / or the components it protects, and token configuration system 140 can issue entitlement tokens based on the attestation report. In some embodiments, for example, token configuration system 140 can issue an attestation report request to BMC 113 of computing system 110. In some embodiments, for example, an application engineer or other representative of component manufacturer 102 (e.g., to whom an end customer may have reported an issue or requested the enablement of special software and / or special features) can cause token configuration system 140 to issue an attestation report request to the computing system's BMC. In some embodiments, for example, token configuration system 140 can issue the attestation report request via an attestation report request service provided by BMC 113.

[0104] In some embodiments, for example, the BMC 113 may provide an externally facing interface (e.g., a Redfish API or Redfish service) through which the token configuration system 140 may invoke the attestation report solicitation service, for example, by sending a message to the interface (e.g., by sending an HTTP request message, such as an HTTP GET message, to access the attestation report solicitation service). In some embodiments, the token configuration system 140 may include an authentication challenge (e.g., a random number generated by the token configuration system 140) as part of the attestation report solicitation request to be included in any attestation report provided in response thereto. In some embodiments, in response to receiving the attestation report solicitation request from the token configuration system 140, the BMC 113 may notify the token configuration system 140 that the attestation report solicitation request has been received and / or that the attestation report solicitation process (or task) has been initiated. In some embodiments, for example, when the attestation report solicitation request is sent via the attestation report solicitation service, the BMC 113 may provide a notification to the token configuration system 140 in a response message (e.g., in an HTTP response message).

[0105] In some embodiments, in response to receiving an attestation report solicitation request from the token configuration system 140, the BMC 113 may obtain a signed attestation report (or an attestation report record containing the report) from each RoT 115 that it manages (e.g., as described above). In some embodiments, the BMC 113 may return the signed attestation report to the token configuration system 140. In some embodiments, for example, when the attestation report solicitation request has been sent through the attestation report solicitation service, the BMC 113 may provide the signed attestation report to the token configuration system 140 in a response message (e.g., in an HTTP response message). In some embodiments, the BMC 113 may attach a signing certificate (or certificate chain) to each attestation report (or attestation report record) containing a device-unique key of the RoT 115 that signed the attestation report (e.g., a device-unique public key of the RoT) before returning the attestation report to the token configuration system 140. In some embodiments, the BMC 113 may aggregate signed attestation reports (or attestation report records) received back from each RoT 115 that it manages (which, in some embodiments, may include corresponding signing certificates for the respective RoTs 115) to generate an attestation report set that may be returned to the token configuration system 140 (e.g., in response to an initially received attestation report solicitation request).

[0106] In some embodiments, the token configuration system 140 can process each attestation report (or, in some embodiments, attestation report record) returned by the BMC 113 (e.g., using its processing logic). In embodiments where attestation reports (or attestation report records) are provided in an attestation report set, the token configuration system 140 can parse the attestation report set and extract and process the individual attestation reports (or attestation report records) contained therein. In some embodiments, for example, the token configuration system 140 can attempt to verify the attestation report (which, in some embodiments, can be contained in an attestation report record) to ensure that it can be trusted and / or otherwise suitable for further processing.

[0107] In some embodiments, for example, the token configuration system 140 may attempt to verify the digital signature on the attestation report (or attestation report record). In some embodiments, for example, the attestation report (or attestation report record) may have been signed by the RoT 115 that generated it, and the token configuration system 140 may attempt to verify the digital signature on the attestation report (or attestation report record). In some embodiments, for example, the RoT 115 may have signed the attestation report (or attestation report record) using its device-unique key, and the token configuration system 140 may attempt to verify the device-unique key using the corresponding key.

[0108] In some embodiments, for example, the device-unique key of RoT 115 may be an asymmetric key comprising a private key and a public key. In some embodiments, RoT 115 may have signed the attestation report (or attestation report record) using the device-unique private key, and token configuration system 140 may verify the device-unique private key using the corresponding device-unique public key. Token configuration system 140 may know the device-unique public key, or the device-unique public key may be provided to token configuration system 140. For example, in some embodiments, token configuration system 140 may maintain a mapping between the serial number of RoT 115 and the corresponding device-unique public key (e.g., established when RoT 115 and / or the components it protects are first manufactured or put into production). In such embodiments, token configuration system 140 may parse the attestation report (which, in some embodiments, may be included in the attestation report record) and extract the serial number contained therein. Based on the serial number, token configuration system 140 may determine the corresponding device-unique public key (e.g., from a mapping maintained by the token configuration system).

[0109] In other embodiments, the device-unique public key may have been provided to the token configuration system 140 in a certificate (or certificate chain) issued to the RoT 115 by a certificate authority (CA) trusted by the token configuration system 140 (e.g., the token configuration system 140 has its corresponding root certificate). In some embodiments, for example, a certificate (or certificate chain) with the device-unique public key of the RoT 115 may have been attached to (or otherwise coupled to) an attestation report (or attestation report record). In some embodiments, the token configuration system 140 may parse the attestation report (or attestation report record) and extract the certificate (or certificate chain) therefrom. The token configuration system 140 may then verify the certificate (or certificate chain) to confirm that it was issued by a trusted CA and, if successfully verified, extract the device-unique public key of the RoT 115 provided therein. In some embodiments, the token configuration system 140 may attempt to verify the digital signature on the attestation report (or attestation report record) using the extracted device-unique public key. In some embodiments, if the token configuration system 140 is able to verify the signature on the certification report (or certification report record), further processing (e.g., further verification or additional processing) may proceed, but if not, the token configuration system 140 may discard the certification report (or certification report record) and may abort further processing.

[0110] In some embodiments, the token configuration system 140 may also attempt to verify that the attestation report (which, in some embodiments, may be included in an attestation report record) includes a valid authentication response. In some embodiments, for example, the token configuration system 140 may parse the attestation report and extract the authentication response contained therein, which the token configuration system 140 may compare with the authentication challenge contained in the first issued attestation report solicitation request (e.g., in response to which the attestation report was provided) to ensure that they match. If the token configuration system 140 is able to verify that the authentication challenge and response match, further processing may continue. If they do not match, the token configuration system 140 may discard the attestation report (or attestation report record) and may suspend further processing.

[0111] In some embodiments, the token configuration system 140 may further process the attestation report (which, in some embodiments, may be included in an attestation report record) to determine whether an entitlement token and / or parameters of an entitlement token to be granted should be granted to the RoT 115 that generated the attestation report. In some embodiments, for example, the token configuration system 140 may consider whether the identity and / or state measurements contained in the attestation report meet one or more policy criteria, based on which the token configuration system 140 may be able to determine whether an entitlement token and / or parameters of an entitlement token to be granted should be granted to the RoT 115. For example, a component manufacturer may have established an entitlement token issuance policy that specifies one or more policy criteria that may need to be met in order for the RoT 115 to be authorized to receive an entitlement token, and / or establishes parameters of an entitlement token that the RoT 115 may be authorized to receive.

[0112] For example, in some embodiments, the token configuration system 140 may maintain certain information about the components it has manufactured and put into service. For example, the token configuration system 140 may maintain a list of serial numbers of the components and / or the RoT 115 that protects them, the end customers associated with the components, the identity of the computing system 110 on which the components are deployed, the identity of the BMC 113 that can manage the components, the firmware versions (of the components and / or the RoT 115 that protects them) with known security vulnerabilities, the latest firmware versions of the components and / or RoT 115, or other relevant information. In some embodiments, the token configuration system 140 may also maintain information about which end customers are authorized to receive entitlement tokens, the specific software and / or functions they are authorized to use, the cryptographic keys associated with the software, and / or other relevant information. The token configuration system 140 may use this information to determine whether the RoT 115 is authorized to receive entitlement tokens and / or the parameters of the entitlement tokens that the RoT 115 is authorized to receive.

[0113] In some embodiments, for example, the entitlement token issuance policy may specify that only certain customers are authorized to receive entitlement tokens, that devices using insecure firmware are not authorized to receive entitlement tokens, or other policy criteria. To determine whether an entitlement token should be issued, the token configuration system 140 may determine whether the serial number of the RoT 115 and / or the component it protects (e.g., identified in the attestation report) is associated with a specific end customer who is authorized to receive the entitlement token, and whether the current firmware on the RoT 115 (e.g., identified in the attestation report) is secure (e.g., does not have any known security vulnerabilities). In some embodiments, the policy criteria may also require one or more levels of approval. For example, in some embodiments, the issuance of an entitlement token may be subject to the approval of an application engineer, a customer service agent, and / or other representative of the component manufacturer 102, who may provide such approval via the token configuration system 140.

[0114] In some embodiments, upon successful verification of the proof report and satisfaction of applicable policy criteria, the token configuration system 140 may generate an entitlement token for the RoT 115, thereby allowing the RoT 115 to take certain actions with respect to the components it protects. In some embodiments, the token configuration system 140 may issue different types of entitlement tokens that may authorize and / or enable the RoT 115 to take different actions. For example, in some embodiments, the token configuration system 140 may issue a software authorization token that authorizes and / or enables the RoT 115 to affect changes to software on the components it protects. For example, in some embodiments, the token configuration system 140 may issue a software authorization token that authorizes and / or enables the RoT 115 to install certain software (e.g., a custom firmware image, a software tool, or other software object) on the components it protects (e.g., on its memory 116) and / or allows the components to load and execute software after installation (e.g., boot from a custom firmware image). For example, in some embodiments, the token configuration system 140 may include a cryptographic key in the software authorization token that was previously unknown to the RoT 115, which the RoT 115 may use to verify whether particular software can be trusted (e.g., so that a component can safely install and / or load and execute the software). For example, in some embodiments, the token configuration system 140 may include a non-production key (e.g., a non-production public key) that the RoT 115 may be able to use to verify non-production software (e.g., debug software, debug tools, etc.) signed with the non-production key (e.g., using a corresponding non-production private key). In other embodiments, the software authorization token may be embedded in or otherwise include a software object (e.g., microcode, machine code, etc.) that the RoT 115 may be able to extract and install. As another example, in some embodiments, the token configuration system 140 may issue a functional configuration token that authorizes the RoT 115 and / or enables the RoT 115 to affect changes to the software and / or hardware functionality of the component it protects (e.g., unlock or enable one or more functions on the component it protects). In some embodiments, for example, the token configuration system 140 can issue a functional configuration token that identifies one or more features of a software object that may already exist on the component (e.g., features within a production firmware image) for use by the RoT 115 (e.g., after the entitlement token is installed).

[0115] In some embodiments, the entitlement token may include a number of additional parameters that may be used to limit the lifespan and / or scope of use of the entitlement token. In some embodiments, for example, the token configuration system 140 may include one or more identity and / or state parameters (e.g., one or more identity and / or state measurements from an attestation report, such as a serial number of the RoT 115 and / or its protected components, a firmware version on the RoT 115 and / or its protected components, and / or other identity and / or state measurements) that may be used to bind the entitlement token to a specific RoT 115 and component and / or its specific state. In some embodiments, the token configuration system 140 may include an authentication challenge included in the attestation report as an authentication response that the RoT 115 may verify before installing and / or using the entitlement token (e.g., to ensure that the authentication response matches the current authentication challenge of the RoT 115). In some embodiments, the inclusion of the authentication response may also be used to control the lifespan of the entitlement token. In some embodiments, for example, RoT 115 may update its current authentication challenge (e.g., generate a new random number) under certain conditions (e.g., upon each power cycle or boot, after successful installation of an entitlement token, and / or after a particular amount of time has passed), which may be used to invalidate the entitlement token because it no longer matches the authentication response contained therein.

[0116] In some embodiments, token configuration system 140 may sign the entitlement token, for example, using a cryptographic key known or verifiable by RoT 115. In some embodiments, for example, token configuration system 140 may sign the entitlement token using a production key (e.g., a production private key), and RoT 115 may be able to verify the production key (e.g., using a production non-private key). In some embodiments, for example, token configuration system 140 may calculate a message digest on the entitlement token using a hash algorithm (e.g., using MD5, SHA1, SHA256, or other hash algorithms), and token configuration system 140 may encrypt the message digest using the production key (e.g., using a private production key). In some embodiments, token configuration system 140 may append (or otherwise couple) the resulting encrypted message digest to the entitlement token to sign the entitlement token.

[0117] In some embodiments, once the attestation report is processed and the appropriate entitlement token is generated and signed, it can be returned to the BMC 113 for installation on the corresponding RoT 115 managed by it. In some embodiments, the token configuration system 140 can aggregate multiple entitlement tokens (e.g., once all attestation reports in the attestation report set are processed and the appropriate entitlement token is generated and signed) to generate an entitlement token set, which can be returned to the BMC 113 for decomposition and installation on the corresponding RoT 115 managed by it. In some embodiments, the token configuration system 140 can provide the entitlement token (or set of entitlement tokens) directly to the BMC 113. In some embodiments, for example, the BMC 113 can provide an entitlement token installation service (or token installation service) to help manage the distribution and installation of entitlement tokens to the RoT 115. In some embodiments, the token configuration system 140 may be able to issue an entitlement token installation request (or token installation request) to the BMC 113 through the entitlement token installation service (e.g., by sending a message to an external-facing interface of the BMC 113 to invoke the entitlement token installation service). In some embodiments, the token configuration system 140 may include an entitlement token (or set of entitlement tokens) as part of the request (eg, as part of the request message).

[0118] In other embodiments, token configuration system 140 may provide an entitlement token (or set of entitlement tokens) to software distribution system 150, which may include the set of entitlement tokens in a software update package, which may then distribute the software update package to BMC 113. In some embodiments, the software update package may include one or more software objects (e.g., firmware images) for installation by BMC 113 (e.g., on BMC 113 itself and / or components it manages). In some embodiments, token configuration system 140 may identify one or more software objects for software distribution system 150 to include in the software update package (e.g., software objects that the entitlement token (or set of entitlement tokens) may authorize and / or allow for installation by RoT 115 of computing system 110).

[0119] In some embodiments, computing system 110 may be coupled to and capable of communicating with software distribution system 150. In some embodiments, software distribution system 150 may include one or more components, including, for example, a system-level processing component (e.g., a CPU, FPGA, ASIC, etc.), one or more additional processing components, switches, controllers, communication interfaces, and other system components. In some embodiments, software distribution system 150 may also be coupled to and capable of communicating with token configuration system 140.

[0120] In some embodiments, software distribution system 150 may be used to distribute software to computing system 110 for installation on one or more components thereof. In some embodiments, for example, software distribution system 150 may be capable of generating a software update package containing one or more software objects for installation on components of computing system 110. In some embodiments, for example, software distribution system 150 may generate a software update package containing specialized software (e.g., custom debugging firmware, useful debugging tools, etc.) for installation on components of computing system 110.

[0121] In some embodiments, software distribution system 150 may provide software update packages to BMC 113 of computing system 110 for installation on managed components. In some embodiments, BMC 113 may provide a software update service to facilitate software distribution and installation on managed components of computing system 110. In some embodiments, software distribution system 150 may invoke the software update service by sending a message to an interface, and may include the software update package as part of the message. In some embodiments, the software update service provided by BMC 113 may operate in accordance with the PLDM standard (e.g., including the PLDM for Firmware Update Specification). In such embodiments, software distribution system 150 may generate software update packages that comply with the PLDM standard. For example, a PLDM software update package (or PLDM package) may include a package header and one or more software objects (e.g., firmware images). The package header may include a header information section (e.g., describing the package version, date, etc.), a component identifier record (describing the components targeted for the update, including downstream components), package content information (e.g., describing the software images contained in the package, including, for example, their classification, offset, size, and version), and a checksum.

[0122] In some embodiments, token configuration system 140 may provide the entitlement token (or set of entitlement tokens) it generates to software distribution system 150 as part of a software update package provided to computing system 110. In some embodiments, software distribution system 150 may include the entitlement token (or set of entitlement tokens) received from token configuration system 140 in the software update package. In some embodiments, for example, software distribution system 150 may include the entitlement token (or set of entitlement tokens) as a "virtual" software object intended for a "virtual" component, which BMC 113 may be able to identify as such. In some embodiments, for example, a special component identifier (e.g., a specific UUID) and / or a software object identifier (e.g., 0xDEAD or 57005) may be used in the PLDM packet header to indicate that the software object is an entitlement token (or set of entitlement tokens). In some embodiments, token configuration system 140 may also provide software distribution system 150 with the identification of one or more software objects to be included in the software update package along with the entitlement token (or set of entitlement tokens) (e.g., the software objects that the entitlement token (or set of entitlement tokens) may authorize and / or allow RoT 115 of computing system 110 to install). Software distribution system 150 may generate a software update package having an entitlement token (or set of entitlement tokens) and / or one or more software objects and provide them to BMC 113 for installation on computing system 110. In some embodiments, BMC 113 may notify software distribution system 150 when processing of the software update package begins and / or when processing of the software update package is complete (e.g., once the entitlement token (or set of entitlement tokens) and / or the software objects therein have been installed).

[0123] Figure 2 is a block diagram of an example computing environment 200 according to at least one embodiment. Figure 2 As shown, computing environment 200 may include one or more computing systems 210, token configuration system 240, and, in some embodiments, software distribution system 250. Computing environment 200 is similar to Figure 1 1 and described above in connection therewith. The systems in computing environment 100 (e.g., computing system 110, token configuration system 140, software distribution system 150, and communication networks 160 and 170) are similar to the systems in computing environment 200 (e.g., computing system 210, token configuration system 240, software distribution system 250, and communication networks 260 and 270, respectively), and therefore, for the sake of brevity, their structure, functionality, and operation will not be repeated here unless necessary to explain their differences.

[0124] In particular, Figure 2 The example computing system 210 shown in FIG. Figure 1The computing system 110 shown in FIG. 1 (and the computing system 110 described above with respect thereto) is relatively more complex. In some embodiments, for example, the computing system 210 may include several computing subsystems (e.g., each computing subsystem may be similar to the computing system 110). For example, in some embodiments, the computing system 210 may be a high-performance computing system that includes multiple different server subsystems, such as a host management system 220, one or more computing subsystems 230, and / or one or more storage subsystems (not shown), which may work together to perform computationally intensive workloads (e.g., to support artificial intelligence (AI) or other HPC applications). Each subsystem of the computing system 210 may include its own system-level processing components or processing logic 212 and peripheral components 214. Each subsystem may also include its own baseboard management controller, such as BMC 213a and BMC 213b, which may perform different management functions for their respective computing subsystems, such as the host management subsystem 220 and the computing subsystem 230, respectively.

[0125] In some embodiments, the host management subsystem 220 can be used to manage and coordinate the operations of different computing subsystems 230 and / or other subsystems (e.g., storage subsystems) (not shown). In some embodiments, the BMCs 213 can be arranged and configured to operate in a hierarchical manner, e.g., a higher-level BMC can manage one or more BMCs at lower levels. In some embodiments, for example, a BMC 213a of the host management subsystem 220 can be used to manage one or more BMCs 213b of the computing subsystem 230. In some embodiments, the BMC 213a may be able to perform different management functions on the computing subsystem 230 and its components through the BMC 213b.

[0126] In some embodiments, for example, the BMC 213a of the host management subsystem 220 may be coupled to the BMC 213b of the computing subsystem 230 and may be connected to the BMC 213b via a communication bus 211d (eg, a universal serial bus (USB), I2C, or a serial bus). 2 C bus) or a communication network using its communication interface (e.g., USB interface, I 2C interface, network communication interface, or other communication interface) to communicate with the BMC 213b of the computing subsystem 230. In some embodiments, the BMCs 213 may each provide an externally-facing interface (e.g., a Redfish API or Redfish service) through which a subsystem (e.g., host management subsystem 220 or computing subsystem 230) and its components (e.g., similar to the BMC 113 described above with respect thereto) may be managed. In some embodiments, the BMC 213a may be able to perform various management functions on the computing subsystem 230 and its components through the externally-facing interface of the BMC 213b (e.g., through its Redfish API or Redfish service).

[0127] In some embodiments, the token configuration system 240 can be used to issue entitlement tokens to the RoT 215 of the computing system 210, which can authorize the RoT 215 and / or enable the RoT 215 to take certain actions with respect to the components it protects (e.g., changes that affect the software and / or functionality available on the components). In some embodiments, for example, the token configuration system 240 can issue entitlement tokens based on an end-to-end challenge-response performed between the token configuration system 240 and one or more RoTs 215 of the computing system 210. In some embodiments, for example, the token configuration system 240 can solicit an attestation report from each RoT 215, which can provide attestation regarding the identity and / or state of the RoT 215 and / or the components it protects, and the token configuration system 240 can issue entitlement tokens based on the attestation report.

[0128] In some embodiments, for example, the token configuration system 240 can issue an attestation report solicitation request to the BMC 213 a of the host management subsystem 220, for example, via an attestation report solicitation service provided thereby (e.g., in a manner similar to the token configuration system 140 and BMC 113, as described above with respect thereto). In some embodiments, for example, an application engineer or other representative of the component manufacturer 102 (e.g., to whom an end customer may have reported a problem or requested special software and / or enabled special features) can cause the token configuration system 240 to issue an attestation report solicitation request to the BMC 213 a of the host management subsystem 220.

[0129] In some embodiments, in response to receiving the attestation report solicitation request from the token configuration system 240, the BMC 213a may request an attestation report from each RoT 215 it manages (e.g., in a manner similar to the BMC 113 described above). In some embodiments, in response to receiving the attestation request from the BMC 213a, each RoT 215 managed by the BMC 213a may generate a signed attestation report (e.g., in a manner similar to the RoT 115 described above with respect thereto). In some embodiments, in response to receiving the attestation report solicitation request from the token configuration system 240, the BMC 213a may also forward (or proxy) the request to each BMC 213b it manages. In some embodiments, in response to receiving the attestation report solicitation request from the BMC 213a, the BMC 213b may request an attestation report from each RoT 215 it manages (e.g., in a manner similar to the BMC 113 described above with respect thereto). In some embodiments, in response to receiving an attestation request from BMC 213b, each RoT 215 managed by BMC 213b may generate a signed attestation report (eg, in a similar manner as RoT 115, as described above with respect thereto).

[0130] In some embodiments, BMC 213b may provide BMC 213a with signed attestation reports received from each RoT 215 it manages (e.g., in a manner similar to that in which BMC 113 provides attestation reports to token configuration system 140, as described above). In some embodiments, BMC 213b may aggregate the signed attestation reports (or attestation report records) received back from each RoT 215 it manages (which, in some embodiments, may include the respective signing certificates of the respective RoTs 215) to generate an attestation report set. In some embodiments, BMC 213b may return the attestation report set to BMC 213a (e.g., in response to an attestation report solicitation request initially forwarded by BMC 213a). In some embodiments, BMC 213b may record (or cache) the identity of the RoT 215 that received the attestation report, which BMC 213b may subsequently utilize to facilitate the distribution and installation of entitlement tokens received in response (e.g., received from token configuration system 240 by BMC 213a). In some embodiments, for example, BMC 213b may maintain a mapping between a globally unique device identifier of RoT 215 (e.g., a UUID of RoT 215) obtained from RoT 215 (e.g., by exchanging MCTP control messages therewith) and serial numbers of RoT 215 and / or components protected therein obtained from an attestation report provided by RoT 215. In some embodiments, an entitlement token issued in response to the attestation report may specify the serial numbers of RoT 215 and / or its intended components, based on which BMC 213b may be able to determine a corresponding device identifier to which the entitlement token should be provided for installation (e.g., from the recorded mapping).

[0131] In some embodiments, the BMC 213a may provide the signed attestation reports received from each RoT 215 it manages and the signed attestation reports received from each BMC 213b it manages to the token configuration system 240 (e.g., in a manner similar to that in which the BMC 113 provides attestation reports to the token configuration system 140, as described above with respect thereto). In some embodiments, the BMC 213a may aggregate the signed attestation reports (or attestation report records) received back from each RoT 215 it manages (which, in some embodiments, may include the corresponding signing certificates of the corresponding RoT 215) and the signed attestation reports received from each BMC 213b it manages to generate an attestation report set. In some embodiments, the BMC 213a may provide the attestation report set to the token configuration system 240 (e.g., in a manner similar to that in which the BMC 113 provides attestation reports to the token configuration system 140, as described above with respect thereto).

[0132] In some embodiments, BMC 213a may record (or cache) the identity of RoT 215 from which the attestation report was received, and the identity of BMC 213b from which the attestation report was received, which BMC 213a may later use to facilitate the distribution and installation of an entitlement token received in response (e.g., from token configuration system 240). In some embodiments, for example, BMC 213a may maintain a mapping of a globally unique device identifier of RoT 215 (e.g., a UUID of RoT 215) obtained from RoT 215 (e.g., by exchanging MCTP control messages therewith) and serial numbers of RoT 215 and / or its protected components obtained from the attestation report provided by RoT 215. In some embodiments, with respect to an attestation report received from BMC 213b, BMC 213a may maintain a mapping of a globally unique device identifier of BMC 213b (e.g., a UUID of BMC 213b) obtained from BMC 213b (e.g., by exchanging MCTP control messages therewith) with a serial number of each RoT 215 and / or its protected component for which the attestation report was received, obtained from the attestation report provided by BMC 213b. In some embodiments, an entitlement token issued in response to an attestation report may specify the serial number of the RoT 215 and / or its intended component, based on which BMC 213a may be able to determine (e.g., from a recorded mapping) a corresponding device identifier of BMC 213b to which the entitlement token should be forwarded (e.g., installed on a RoT managed by it).

[0133] In some embodiments, the token configuration system 240 may process each attestation report returned by the BMC 213a (e.g., each attestation report in an attestation report set) and (e.g., after verifying the attestation report and / or satisfying one or more policy criteria) generate an entitlement token for the RoT 115 that generated the corresponding attestation report (e.g., in a manner similar to the token configuration system 140, as described above with respect thereto). In some embodiments, the generated entitlement token may be returned to the BMC 213a for installation on the corresponding RoT 215 managed by it or forwarded to the BMC 213b (e.g., for installation on the corresponding RoT 215 managed by the BMC 213b). In some embodiments, the token configuration system 240 may aggregate multiple entitlement tokens to generate a set of entitlement tokens, which may be provided back to the BMC 213a for decomposition and installation on the corresponding RoT 215 or forwarded to the corresponding BMC 213b managed by it (e.g., for installation on the corresponding RoT 215 managed by the BMC 213b).

[0134] In some embodiments, the token configuration system 240 may provide an entitlement token (or a set of entitlement tokens) directly to the BMC 213a (e.g., in a manner similar to the token configuration system 140 and BMC 113 described above). In embodiments where a set of entitlement tokens is provided to the BMC 213a, the BMC 213a may extract and process the individual entitlement tokens contained therein. In some embodiments, the BMC 213a may process the received entitlement token to determine its intended RoT 215 or the BMC 213b to which it should be forwarded, and provide it to the identified RoT 215 for installation or to the BMC 213b for processing (e.g., installation on a RoT 215 managed by it). In some embodiments, for example, the BMC 213 may have recorded (or cached) the identity of the RoT 215 and / or BMC 213b that received the attestation report. In some embodiments, the BMC 213a may parse the received entitlement token and extract the serial number specified therein (e.g., the serial number of the RoT 215 and / or the component it protects). The BMC 213a may match the extracted serial number with a corresponding device identifier (eg, from a recorded mapping) to identify the RoT 215 or BMC 213b to which the entitlement token should be provided for installation.

[0135] In some embodiments, the BMC 213a may issue an entitlement token installation command to the identified RoT 215 and provide the entitlement token to the RoT 215 for installation, e.g., as part of the entitlement token installation command (e.g., in a manner similar to that described above with respect to the BMC 113 and RoT 115). In some embodiments, the BMC 213a may forward the entitlement token to the identified BMC 213b, e.g., as part of an entitlement token installation request (e.g., issued by an entitlement token installation service of the BMC 213b). In some embodiments, the BMC 213a may aggregate multiple entitlement tokens intended for the BMC 213b to generate a set of entitlement tokens that may be provided to the BMC 213b for decomposition and installation on the corresponding RoT 215 managed by it. In some embodiments, BMC 213b, upon receiving an entitlement token (or set of entitlement tokens) (e.g., as part of an entitlement token installation request received from BMC 213a), may process the entitlement token, or extract and process each entitlement token in the set of entitlement tokens (e.g., in a manner similar to that just described for BMC 213a and the RoT 215 that it manages).

[0136] In other embodiments, token configuration system 240 may provide the entitlement token (or set of entitlement tokens) to software distribution system 250, which may include the set of entitlement tokens in a software update package, which may then be distributed to BMC 213a (e.g., in a manner similar to token configuration system 140, software distribution system 150, and BMC 113, as described above with respect thereto). In some embodiments, upon receiving the software update package (e.g., via a request to a software update service), BMC 213a may attempt to process the software update package (e.g., in a manner similar to BMC 113, as described above with respect thereto). In some embodiments, BMC 213a may inspect the software update package to determine whether the entitlement token (or set of entitlement tokens) is included therein. In some embodiments, for example, BMC 213a may parse the package header to identify a virtual software object within the package that contains the entitlement token (or set of entitlement tokens). In some embodiments, for example, an entitlement token (or set of entitlement tokens) may be identified by a special component identifier (e.g., a specific virtual component UUID) and / or a special software object identifier (e.g., 0xDEAD or 57005) within a packet header. In some embodiments, BMC 213a may extract the identified software object (e.g., based on relevant packet information in the header, such as packet offset and object size), including the entitlement token (or set of entitlement tokens), for processing in the manner just described for embodiments in which the entitlement token (or set of entitlement tokens) is received directly from token configuration system 240.

[0137] In some embodiments, after processing all entitlement tokens, the BMC 213a may process the remaining software objects in the software update package (e.g., in a manner similar to that of the BMC 113, as described above with respect thereto). In some embodiments, for example, the BMC 213a may parse the software update package to identify software objects intended for one or more components managed by the BMC 213a. In some embodiments, the BMC 213a may extract the identified software objects and provide them to the appropriate RoT 215 for installation on the RoT 215 or the components they protect (e.g., as part of a software installation command). In some embodiments, the BMC 213a may parse the software update package to identify software objects for one or more components indirectly managed by the BMC 213b it manages. In some embodiments, the BMC 213a may extract the identified software objects and provide them to the appropriate BMC 213b (e.g., through its software update service) for installation by the RoT 215 it manages (e.g., in a manner similar to that just described).

[0138] Figures 3 and 4Example methods according to embodiments of the present disclosure are shown. For simplicity and clarity, these methods are depicted and described as a series of operations. However, according to the present disclosure, such operations can be performed in other orders and / or simultaneously, and together with other operations not presented or described herein. In addition, when implementing the methods according to the present disclosure, not all of the operations shown may be required. Those skilled in the art will also understand and appreciate that these methods can be represented as a series of interrelated states or events through state diagrams. In addition, it will be appreciated that the disclosed methods can be stored on an article of manufacture. The term "article of manufacture" as used herein is intended to cover a computer-readable device or storage medium equipped with a computer program and / or executable instructions that, when executed, affect one or more operations.

[0139] Figure 3 A flow chart of an example method 300 for issuing entitlement tokens according to at least one embodiment is shown. In some embodiments, the method 300 may involve a token configuration system issuing entitlement tokens to one or more RoTs of a computing system, authorizing the RoTs and / or enabling the RoTs to take certain actions with respect to one or more components they protect (e.g., changes affecting software and / or functionality available on the component). For example, in some embodiments, an entitlement token may be issued to a RoT to allow the RoT to install special software on a component (e.g., custom debug firmware, useful debugging tools, etc.) and / or enable certain restricted functionality (e.g., detailed logging, ultra-high frequency operation, unrestricted hash rate computation, etc.). In some embodiments, an entitlement token may be issued based on a communication between the token configuration system and one or more RoTs of a computing system (e.g., Figure 1 The operations of method 300 may be performed by processing logic of the token configuration system, the RoT of the computing system, and / or one or more other components thereof (e.g., by processing logic of the token configuration system 140, the computing system 110, and / or its BMC 113 or RoT 115).

[0140] In some embodiments, at operation 310, the token configuration system (e.g., using its processing logic) may request an attestation report from one or more RoTs of the computing system, which may provide attestation regarding the identity and / or state of the RoT and / or the components it protects, and the token configuration system may issue an entitlement token based on the attestation. In some embodiments, for example, the token configuration system may issue an attestation report request to a BMC of the computing system, for example, via an attestation report request service provided by the token configuration system. In some embodiments, for example, an application engineer or other representative of a component manufacturer (e.g., to whom an end customer may have reported an issue or requested special software and / or enabled special features) may cause the token configuration system to issue an attestation report request to the BMC of the computing system. In some embodiments, for example, the BMC of the computing system (e.g., using its processing logic) may provide an externally facing interface (e.g., a Redfish API or Redfish service) through which the token configuration system may invoke the attestation report request service by sending a message to the interface (e.g., by sending an HTTP request message, such as an HTTP GET message, to access the attestation report request service). In some embodiments, the token configuration system may include an authentication challenge (eg, a random number) as part of an attestation report solicitation request for inclusion in any attestation report provided in response to the request.

[0141] In some embodiments, the BMC of the computing system (e.g., using its processing logic), in response to receiving the attestation report request from the token configuration system, may notify the token configuration system that the attestation report solicitation request has been received and / or that the attestation report solicitation request process (or task) has been initiated at operation 312. In some embodiments, for example, when the attestation report solicitation request is sent via the attestation report solicitation service, the BMC may provide a notification to the token configuration system in a response message (e.g., in an HTTP response message).

[0142] In some embodiments, at operation 320, the BMC may request an attestation report from each RoT it manages (e.g., using its processing logic) in response to receiving an attestation report solicitation request from the token configuration system. In some embodiments, operation 320 may involve one or more sub-operations (e.g., Figure 3). In some embodiments, for example, at sub-operation 322, the BMC and the RoT (e.g., using their processing logic) may negotiate and establish a secure communication session. In some embodiments, for example, when the BMC and the RoT communicate with each other using the SPDM protocol, the BMC and the RoT may exchange one or more SPDM message sequences to negotiate and establish the secure communication session. In some embodiments, for example, the BMC may send a GET_VERSION message, and the RoT may respond with a VERSION message, to discover which SPDM versions the BMC and the RoT can jointly support. The BMC may then send a GET_CAPABILITES message, and the RoT may respond with a CAPABILITIES message indicating the capabilities supported by the RoT. The BMC may then send a NEGOTIATE_ALGORITHMS message to advertise the cryptographic algorithms supported by the BMC, and the RoT may respond with an ALGORITHMS message to select the cryptographic algorithm to be used for the communication session.

[0143] In some embodiments, in sub-operation 324, the BMC may authenticate the RoT (e.g., using its processing logic). In some embodiments, for example, when the BMC and the RoT communicate with each other using the SPDM protocol, the BMC and the RoT may exchange one or more SPDM message sequences to authenticate the RoT. In some embodiments, for example, the BMC may send a GET_DIGESTS message, and the RoT may respond with a DIGEST message containing digests of different signing certificates (or certificate chains) available on the RoT. The BMC may then request a specific certificate (or certificate chain) by exchanging one or more GET_CERTIFICATE request and CERTIFICATE response messages (the number of which may depend on the size of the certificate or certificate chain), and the RoT may respond with the specific certificate (or certificate chain). In some embodiments, the certificate (or certificate chain) provided by the RoT may include a device-unique cryptographic key (e.g., a device-unique public key of the RoT), which the BMC may then use to verify the signature on messages received from the RoT. In some embodiments, the BMC may then send a CHALLENGE message (e.g., containing a random number generated by the BMC), and the RoT may respond with a CHALLENGE_AUTH message signed by the RoT using a cryptographic key corresponding to a specific certificate (e.g., a device-unique private key of the RoT). In some embodiments, the BMC may verify the signature on the CHALLENGE_AUTH message to authenticate the RoT.

[0144] In some embodiments, at sub-operation 326, the BMC (e.g., using its processing logic) may issue an attestation report request (or attestation request) to each RoT it manages, requesting attestation of the identity and / or state of the RoT and / or its protected components. In some embodiments, the BMC may include the authentication challenge in the attestation report solicitation request received by the BMC from the token configuration system as part of the attestation request issued to the RoT, so that the RoT includes it as part of its returned attestation report.

[0145] In some embodiments, for example, when the BMC and the RoT communicate with each other using the SPDM protocol, the BMC may send a Get_Measurements (GET_MEASUREMENTS) measurement message to the RoT to request an attestation report from the RoT. In some embodiments, the GET_MEASUREMENTS message may include measurement operation parameters requesting a measurement at a specific index value (e.g., 0x32 or 50), which the RoT may interpret as a request for an attestation report. In some embodiments, the GET_MEASUREMENTS message may include an authentication challenge derived from the attestation report request received by the BMC from the token configuration system (e.g., in operation 310).

[0146] In some embodiments, at operation 330, the RoT (e.g., using its processing logic) may generate and return a signed attestation report in response to receiving the attestation request. In some embodiments, operation 330 may involve one or more sub-operations (e.g., Figure 3 ). In some embodiments, for example, at sub-operation 332, the RoT (e.g., using its processing logic) may generate an attestation report that includes one or more measurements regarding the identity and / or state (e.g., current hardware and / or software state) of the RoT or the components it protects. In some embodiments, for example, the attestation report may include measurements regarding immutable software code, mutable software code, boot phase, configuration data, and / or other state variables of the RoT or the components it protects. In some embodiments, for example, the attestation report generated by the RoT may include a serial number of the RoT and / or the component(s) it protects, a current firmware version on the RoT and / or the component(s) it protects, and / or other identity and / or state measurements.

[0147] In some embodiments, the attestation report generated by the RoT may include one or more additional parameters. In some embodiments, for example, the RoT may include an authentication challenge (e.g., a random number generated by the token configuration system) included as part of the received attestation request. In some embodiments, the attestation report generated by the RoT may also include (another) authentication challenge (e.g., a random number generated by the RoT) to be included in any entitlement token issued by the token configuration system in response thereto. In some embodiments, for example, the RoT may maintain a current authentication challenge (e.g., in its memory) to include it in the attestation report it generates. In some embodiments, the RoT315 may update the authentication challenge (e.g., generate a new random number) under certain conditions (e.g., each time the power is cycled or booted, after the entitlement token is successfully installed, and / or after a certain amount of time has passed).

[0148] In some embodiments, in sub-operation 334, the RoT (e.g., using its processing logic) may sign the attestation report it generated (e.g., in sub-operation 332) using a cryptographic key unique to the RoT (e.g., a key based on a physically unclonable function (PUF)). In some embodiments, for example, the RoT may calculate a message digest for the attestation report using a hash algorithm (e.g., using MD5, SHA1, SHA356, or other hash algorithms), and the RoT may encrypt the message digest using the device-unique key. In some embodiments, the RoT may append the encrypted message digest (or signature) to the attestation report to sign the attestation report.

[0149] In some embodiments, in sub-operation 336, the RoT (e.g., using its processing logic) may return a signed attestation report to the BMC (e.g., in response to the attestation request issued in sub-operation 326). In some embodiments, for example, when the BMC and the RoT are communicating with each other using the SPDM protocol, the RoT may respond with a MEASURMENT message containing the signed attestation report (e.g., in response to the GET_MEASUREMENT message issued in sub-operation 326). In some embodiments, the MEASUREMENT message itself may be signed by the RoT (e.g., using a device-unique cryptographic key) and the signature may be appended to the message. In some embodiments, the signature may be applied to both the attestation request (e.g., the GET_MEASUREMENT request message) and the attestation report sent in response and provided in response (e.g., the MEASUREMENT message) (collectively, a MEASUREMENT "record").

[0150] In some embodiments, at operation 340, the BMC (eg, using its processing logic) may process the attestation report received back from the RoT. In some embodiments, operation 340 may involve one or more sub-operations (e.g., Figure 3 In some embodiments, for example, at sub-operation 342, the BMC (e.g., using its processing logic) may append a signed certificate (or certificate chain) to each attestation report, the attestation report containing the device-unique key of the RoT that signed the attestation report. In some embodiments, for example, the certificate may have been provided by the RoT to the BMC as part of establishing communications therebetween (e.g., at sub-operation 324). In some embodiments, when the RoT provides the attestation report in a signed response message that signs the attestation request message and the attestation response message (or attestation report record), the RoT may append thereto a certificate (or certificate chain) containing the device-unique key of the RoT.

[0151] In some embodiments, at sub-operation 344, the BMC (e.g., using its processing logic) may aggregate the signed attestation reports (or attestation report records) received from each RoT it manages (which, in some embodiments, may also include the corresponding signing certificates of the corresponding RoTs, which may have been attached thereto at sub-operation 342) to generate an attestation report collection.

[0152] In some embodiments, at sub-operation 346, the BMC (e.g., using its processing logic) may record (or cache) the identity of the RoT from which the attestation report was received, which the BMC may later use to facilitate the distribution and installation of entitlement tokens received in response to the attestation report from the token configuration system. In some embodiments, for example, the BMC may maintain a mapping between a globally unique device identifier of the RoT (e.g., the RoT's UUID) and serial numbers of the RoT and / or its protected components. In some embodiments, for example, when the BMC and the RoT communicate according to the MCTP protocol, the BMC may obtain the RoT's UUID by exchanging control messages with the RoT and may obtain the serial number from the RoT's attestation report.

[0153] In some embodiments, at operation 348, the BMC (e.g., using its processing logic) may return the attestation report set to the token configuration system (e.g., in response to the attestation report solicitation request issued at operation 310). In some embodiments, for example, when the attestation report solicitation request is sent via the BMC's attestation report solicitation service, the BMC may provide the attestation report set to the token configuration system in a response message (e.g., in an HTTP response message).

[0154] In some embodiments, the token configuration system (e.g., using its processing logic) may process each attestation report (or, in some embodiments, attestation report record) returned by the BMC at operation 350. In embodiments where the attestation reports (or attestation report records) are provided in an attestation report set, the token configuration system may parse the attestation report set and extract and process the individual attestation reports (or attestation report records) contained therein (e.g., sequentially and / or in parallel).

[0155] In some embodiments, for example, at sub-operation 352, the token configuration system (e.g., using its processing logic) may attempt to verify the attestation report (which, in some embodiments, may be included in an attestation report record) to ensure that it is trustworthy and / or suitable for further processing. In some embodiments, for example, at sub-operation 352, the token configuration system (e.g., using its processing logic) may attempt to verify the digital signature of the attestation report (or attestation report record). In some embodiments, for example, the RoT may have signed the attestation report (or attestation report record) using its device-unique key, and the token configuration system may attempt to verify the key using the corresponding key. In some embodiments, for example, the device-unique key may be an asymmetric key comprising a device-unique private key (which the RoT may have used to sign the attestation report) and a device-unique public key (which the token configuration system may know or have provided to the token configuration system, which the token configuration system may use to verify the signature on the attestation report).

[0156] In some embodiments, for example, the token configuration system may maintain a mapping between a serial number of a RoT and a corresponding device-unique public key (e.g., established when the RoT and / or the component it protects is first manufactured or put into production). In such embodiments, the token configuration system may parse the attestation report (which, in some embodiments, may be included in an attestation report record) and extract the serial number contained therein, based on which the token configuration system may determine the device-unique public key corresponding thereto (e.g., from the mapping maintained thereby).

[0157] In other embodiments, the device-unique public key may have been provided to the token configuration system in a certificate (or certificate chain) issued to the RoT by a certificate authority (CA) that the token configuration system trusts (e.g., the token configuration system has its corresponding root certificate). In some embodiments, for example, a certificate (or certificate chain) with the device-unique public key of the RoT may have been attached to (or otherwise coupled to) an attestation report (or attestation report record). In some embodiments, the token configuration system may parse the attestation report (or attestation report record) and extract the certificate (or certificate chain) therefrom. The token configuration system 340 may then verify the certificate (or certificate chain) to confirm that it is issued by a trusted CA and, if successful, extract the device-unique public key of the RoT provided therein. In some embodiments, if the token configuration system is able to verify the signature on the attestation report (or attestation report record), further processing may continue (e.g., at sub-operation 352b). If not, the token configuration system may discard the attestation report (or attestation report record) and may abort processing of the attestation report (e.g., method 300 returns to sub-operation 352 to process the next attestation report).

[0158] In some embodiments, for example, at sub-operation 352, the token configuration system (e.g., using its processing logic) may also attempt to verify whether the attestation report (which, in some embodiments, may be contained in an attestation report record) includes a valid authentication response. In some embodiments, for example, the token configuration system may parse the attestation report and extract the authentication response contained therein, and the token configuration system may compare the authentication response with the authentication challenge contained in the first issued attestation report request (e.g., at operation 310) to ensure that they match. If the token configuration system is able to verify that the authentication challenge and response match, further processing may continue (e.g., at sub-operation 354). If not, the token configuration system may discard the attestation report (or attestation report record) and may abort processing of the attestation report (e.g., method 300 returns to sub-operation 352a to process the next attestation report).

[0159] In some embodiments, at sub-operation 354, the token configuration system (e.g., using its processing logic) may process the attestation report (which, in some embodiments, may be included in an attestation report record) to determine whether an entitlement token and / or parameters of an entitlement token to be granted should be granted to the RoT that generated the attestation report. In some embodiments, for example, the token configuration system may consider whether identity and / or state measurements contained in the attestation report satisfy one or more policy criteria, based on which the token configuration system may be able to determine whether an entitlement token should be granted to the RoT and / or parameters of an entitlement token to be granted. For example, a component manufacturer may have established an entitlement token issuance policy that specifies one or more policy criteria that may need to be satisfied in order for a RoT to be authorized to receive an entitlement token, and / or establishes parameters of an entitlement token that a RoT may be authorized to receive.

[0160] In some embodiments, for example, the entitlement token issuance policy may specify that only certain customers are authorized to receive entitlement tokens, that devices using insecure firmware are not authorized to receive entitlement tokens, or other policy criteria. To determine whether an entitlement token should be issued, the token configuration system may determine whether the serial number of the RoT and / or the components it protects (e.g., identified in the attestation report) is associated with a specific end customer authorized to receive the entitlement token, and whether the current firmware on the RoT (e.g., identified in the attestation report) is secure (e.g., free of any known security vulnerabilities). In some embodiments, the policy criteria may also require one or more levels of approval. In some embodiments, for example, the issuance of an entitlement token may be contingent on the approval of an application engineer, a customer service agent, and / or other representative of the component manufacturer. In some embodiments, the token configuration system may prompt the representative for approval (e.g., by sending the representative an entitlement token approval request), and the representative may provide their approval through the token configuration system. If the token configuration system is able to verify that one or more policy criteria are met, it may proceed with generating the entitlement token (e.g., at sub-operation 356). If not, the token configuration system may discard the attestation report (or attestation report record) and may abort processing of the attestation report (e.g., method 300 returns to sub-operation 352 to process the next attestation report). In some embodiments, this process may be repeated for each attestation report returned to the BMC (e.g., for each attestation report in an attestation report set).

[0161] In some embodiments, upon successful verification of the proof report and satisfaction of applicable policy criteria (e.g., at sub-operations 352 and 354), at sub-operation 356, the token configuration system (e.g., using its processing logic) may generate an entitlement token for the RoT, thereby allowing the RoT to take certain action(s) with respect to the component it protects. In some embodiments, the parameters of the generated entitlement token may be established by an entitlement token policy, e.g., the entitlement token policy may specify the software and / or functionality that may be used on the component (e.g., components for certain end customers, components in certain computing systems, components under certain conditions, etc.). In some embodiments, the token configuration system may issue different types of entitlement tokens that may authorize and / or allow the RoT to take different actions. For example, in some embodiments, the token configuration system may issue a software authorization token that authorizes the RoT to affect changes to the software on the component it protects and / or enables the RoT to affect changes to the software on the component it protects. In some embodiments, for example, the token configuration system may issue a software authorization token that authorizes the RoT and / or enables the RoT to install certain software (e.g., a custom firmware image, a software tool, or other software object) onto the component it protects (e.g., onto its memory) and / or allows the component to load and execute the software after installation (e.g., boot from a custom firmware image). In some embodiments, for example, the token configuration system may include a cryptographic key not previously known to the RoT in the software authorization token that the RoT may use to verify whether particular software can be trusted (e.g., so that the component may securely install and / or load and execute the software). In some embodiments, for example, the token configuration system may include a non-production key (e.g., a non-production public key) that the RoT may use to verify non-production software (e.g., debugging software, debugging tools, etc.) signed with the non-production key (e.g., using a corresponding non-production private key). As another example, in some embodiments, the token configuration system may issue a functional configuration token that authorizes and / or allows the RoT to affect changes to the functionality provided by the software on the component it protects (e.g., unlocking or enabling one or more functions on the component it protects). In some embodiments, for example, the token configuration system 340 can issue a functional configuration token that identifies one or more functionalities of a software object that may already exist on the component (e.g., functionalities in a production firmware image) so that the RoT is available for use (e.g., after the RoT installs the entitlement token).

[0162] In some embodiments, the entitlement token can include a number of additional parameters that can be used to limit the lifespan and / or scope of the entitlement token. In some embodiments, for example, the token configuration system can include one or more identity and / or state measurements from an attestation report that can be used to bind the entitlement token to a specific RoT and component and / or its specific state. In some embodiments, the token configuration system can include an authentication challenge, included in the attestation report as an authentication response, that the RoT can attempt to verify before installing and / or using the entitlement token.

[0163] In some embodiments, at sub-operation 358, the token configuration system (e.g., using its processing logic) may sign the entitlement token, for example, using a cryptographic key known or verifiable to the RoT issued to it. In some embodiments, for example, the token configuration system may sign the entitlement token using a production key (e.g., a production private key), which the RoT 315 may be able to verify (e.g., using a production non-private key). In some embodiments, for example, the token configuration system may calculate a message digest on the entitlement token using a hash algorithm (e.g., using MD5, SHA1, SHA356, or other hash algorithms), and the token configuration system may encrypt the message digest using the production key (e.g., using a private production key). In some embodiments, the token configuration system may append the resulting encrypted message digest to the entitlement token to sign the entitlement token. In some embodiments, the entitlement token generation and signing process (e.g., sub-operations 356 and 358) may be repeated for each attestation report that is successfully verified and / or meets applicable policy criteria (e.g., at operation 350).

[0164] In some embodiments, once all attestation reports have been processed and appropriate entitlement tokens have been generated and signed (e.g., at operation 350), the token configuration system (e.g., using its processing logic) may return the entitlement tokens to the BMC for installation on the corresponding RoT at operation 360. In some embodiments, the token configuration system (e.g., using its processing logic) may aggregate multiple entitlement tokens (e.g., once all attestation reports in an attestation report set have been processed and appropriate entitlement tokens have been generated and signed) to generate an entitlement token set, which may be returned to the BMC for decomposition and installation on the corresponding RoT.

[0165] Figure 4A flow chart of an example method 400 for installing an entitlement token is shown in accordance with at least one embodiment. In some embodiments, the method 400 may involve a token configuration system providing an entitlement token (or set of entitlement tokens) to a computing system for installation on its corresponding RoT (e.g., the one for which the entitlement token is intended). In some embodiments, the token configuration system may provide the entitlement token (or set of entitlement tokens) directly to the computing system's BMC, while in other embodiments, it may provide them to a software distribution system for inclusion in a software update package provided to the BMC for installation. The operations of the method 400 may be performed by processing logic of the token configuration system, the software distribution system, the computing system's RoT, and / or one or more other components thereof (e.g., by processing logic of the software distribution system, the RoT, and / or one or more other components thereof). Figure 1 The token configuration system 440, the software distribution system 450, the computing system 410 and / or the processing logic of the BMC 413 or the RoT 415 are executed.

[0166] In some embodiments, at operation 410, the token configuration system (e.g., using its processing logic) may provide an entitlement token (or set of entitlement tokens) to a computing system for installation on its corresponding RoT (e.g., the RoT for which the entitlement token is intended). In some embodiments, for example, the token configuration system (e.g., using its processing logic) may provide an entitlement token (or set of entitlement tokens) to a software distribution system, which may include the set of entitlement tokens in a software update package, which may then distribute the software update package to the computing system's BMC for installation. In some embodiments, the token configuration system may identify one or more software objects (e.g., firmware images) for the software distribution system to include in the software update package for installation by the BMC (e.g., on the BMC itself and / or components it manages). In some embodiments, for example, the token configuration system may identify one or more software objects that the entitlement token (or set of entitlement tokens) may authorize and / or enable installation of the computing system's RoT and / or allow use of RoT-protected components.

[0167] In some embodiments, at operation 412, the software distribution system (e.g., using its processing logic) may generate a software update package that includes an entitlement token (or set of entitlement tokens) provided by the token configuration system and one or more software objects that may have been identified by the token configuration system (e.g., at operation 410). In some embodiments, at operation 414, the software distribution system (e.g., using its processing logic) may provide the software update package to the BMC of the computing system for installation. In some embodiments, the BMC may provide a software update service to help facilitate the distribution and installation of software on components of the computing system managed by it. In some embodiments, the software distribution system may invoke the software update service by sending a message to an interface and may include the software update package as part of the message.

[0168] In some embodiments, the software update service provided by the BMC may operate in accordance with the PLDM standard (e.g., PLDM including the Firmware Update Specification). In such embodiments, the software distribution system may generate a software update package that complies with the PLDM standard (e.g., at operation 412). For example, a PLDM software update package (or PLDM package) may include a package header and one or more software objects (e.g., firmware images). The package header may include a header information portion (e.g., describing the package version, date, etc.), a component identifier record (describing the component targeted for the update, including downstream components), package content information (e.g., describing the software image contained in the package, including, for example, its classification, offset, size, and version), and a checksum. In some embodiments, the entitlement token (or set of entitlement tokens) received from the token configuration system may be included as a "virtual" software object intended for a "virtual" component, which the BMC may be able to identify as such. In some embodiments, for example, a special component identifier (e.g., a specific UUID) and / or a software object identifier (e.g., 0xDEAD or 47005) may be used in the PLDM package header to indicate that the software object is an entitlement token (or set of entitlement tokens).

[0169] In some embodiments, at operation 420, upon receiving the software update package (e.g., via a request to a software update service), the BMC (e.g., using its processing logic) may attempt to process the software update package (e.g., using its PLDM handler). In some embodiments, operation 420 may involve one or more sub-operations (e.g., Figure 4). In some embodiments, the BMC may inspect the software update package to determine whether an entitlement token (or set of entitlement tokens) is included therein. In some embodiments, for example, at sub-operation 422, the BMC (e.g., using its processing logic) may parse the packet header to identify a virtual software object within the package that contains the entitlement token (or set of entitlement tokens). In some embodiments, for example, the entitlement token (or set of entitlement tokens) may be identified using a special component identifier (e.g., a specific virtual component UUID) and / or a special software object identifier (e.g., 0xDEAD or 47005) within the packet header. In some embodiments, the BMC may extract the identified software object containing the entitlement token (or set of entitlement tokens) (e.g., based on relevant packet information in the header, such as packet offset and object size) for further processing (e.g., at operation 430). In some embodiments, the BMC may examine the software update package to determine whether an entitlement token (or set of entitlement tokens) is contained therein, and may extract and process the entitlement token (or set of entitlement tokens) (e.g., at sub-operation 422) before processing the remainder of the software update package (e.g., before installing any other software objects contained therein) (e.g., at operation 450).

[0170] In some embodiments, at operation 430, the BMC token configuration system (e.g., using its processing logic) may process each entitlement token (or set of entitlement tokens) extracted from the software update package (e.g., at operation 422). When entitlement tokens are provided in a set of entitlement tokens, the BMC may parse the set of entitlement tokens and extract and process the individual entitlement tokens contained therein (e.g., sequentially and / or in parallel).

[0171] In some embodiments, operation 430 may involve one or more sub-operations (in Figure 4 ). In some embodiments, for example, at sub-operation 432, the BMC (e.g., using its processing logic) may process the received entitlement token to determine the RoT for which it is intended and provide it to the identified RoT for installation. In some embodiments, the BMC may record (or cache) the identity of the RoT from which the attestation report was received (e.g., maintaining a mapping of the RoT's globally unique device identifier to the serial numbers of the RoT and / or the components it protects). In some embodiments, the BMC may parse the received entitlement token and extract the serial number specified therein (e.g., the serial number of the RoT and / or the components it protects). The BMC may match the extracted serial number with a corresponding device identifier (e.g., from the recorded mapping) to identify the RoT for which the entitlement token should be provided for installation.

[0172] In some embodiments, at sub-operation 434, the BMC (e.g., using its processing logic) may issue an entitlement token installation command to the identified RoT and provide the entitlement token to the RoT for installation (e.g., as part of the entitlement token installation command). In some embodiments, for example, when the BMC and the RoT communicate using the MCTP protocol, the entitlement token installation command may be issued by sending a corresponding MCTP message (e.g., a vendor-defined message (VDM)), which may include the entitlement token as part of the message payload. In some embodiments, this process (e.g., operation 430) may be repeated for each entitlement token provided to the BMC (e.g., for each entitlement token in the set of entitlement tokens).

[0173] In some embodiments, at operation 440, the RoT (e.g., using its processing logic) may attempt to verify the entitlement token and, if successful, attempt to install the entitlement token. In some embodiments, operation 440 may involve one or more sub-operations (e.g., Figure 4 In some embodiments, for example, at sub-operation 442, the RoT (e.g., using its processing logic) may attempt to verify the entitlement token received (e.g., as part of a token installation command issued by the BMC) to determine whether it should be further processed (e.g., installed by the RoT at sub-operation 444). In some embodiments, for example, the RoT (e.g., using its processing logic) may verify whether the entitlement token is trustworthy, applicable to the RoT, valid, and / or suitable for use by the RoT.

[0174] In some embodiments, for example, at the time the entitlement token was issued, the token configuration system may have cryptographically signed the entitlement token, for example, using a cryptographic key known or verifiable to the RoT (e.g., a manufacturer's production key, which may have been provided to the RoT when the RoT and / or the components it protects were first manufactured or put into production). In some embodiments, at sub-operation 442, the RoT (e.g., using its processing logic) may attempt to verify the digital signature of the entitlement token to determine its authenticity or lack thereof, for example, using one or more cryptographic keys stored on the RoT (e.g., in its secure memory, such as within a key store therein), which cryptographic keys may include corresponding production keys (e.g., corresponding public production keys). In some embodiments, for example, the RoT may calculate a message digest from the entitlement token using a hashing algorithm (e.g., using MD5, SHA1, SHA456, or other hashing algorithm) (e.g., for entitlement token data that does not include a signature). The RoT may decrypt the digital signature using a cryptographic key stored on the RoT 415, the result of which may be compared to the calculated message digest to determine whether they match. If the signature is successfully verified (e.g., if the results do match), the RoT may further process the entitlement token (e.g., at sub-operation 442). If the signature cannot be verified, the RoT may discard the entitlement token and abort processing of the entitlement token (e.g., method 400 returns to sub-operation 442 to process the next entitlement token).

[0175] In some embodiments, at sub-operation 442, the RoT (e.g., using its processing logic) may attempt to verify one or more additional parameters contained in the entitlement token. In some embodiments, for example, the entitlement token may include one or more identity and / or state parameters (e.g., from a token configuration system based on an attestation report issued thereto). The RoT may compare the parameter values provided in the entitlement token with its identity and / or current state to determine whether they match. If the identity and / or state parameters are successfully verified (e.g., if they match the identity and / or current state of the RoT), the RoT may further process the entitlement token (e.g., at sub-operation 442). If the identity and / or state parameters are not successfully verified, the RoT may discard the entitlement token and abort processing of the entitlement token (e.g., method 400 returns to sub-operation 442 to process the next entitlement token).

[0176] In some embodiments, the entitlement token may include an authentication response (e.g., an authentication challenge from the attestation report upon which it was issued), which the RoT (e.g., using its processing logic) may compare with the RoT's current authentication challenge to determine whether they match at sub-operation 442. If the authentication response is successfully verified (e.g., if it matches the RoT's current authentication challenge), the RoT may further process the entitlement token (e.g., at sub-operation 444). If the authentication response is not successfully verified, the RoT 415 may discard the entitlement token and abort processing of the entitlement token (e.g., method 400 returns to sub-operation 442 to process the next entitlement token). In some embodiments, if the RoT 415 is able to successfully verify the entitlement token, it may continue to further process the entitlement token (e.g., install the entitlement token).

[0177] In some embodiments, after successfully verifying authorization (e.g., at sub-operation 432), the RoT (e.g., using its processing logic) may attempt to install the entitlement token at sub-operation 444. In some embodiments, the RoT only allows installation of a single entitlement token at a time, and the RoT (e.g., using its processing logic) may check whether the entitlement token is already installed before attempting to install (another) entitlement token. In some embodiments, if no existing entitlement token is detected, the RoT may continue to attempt to install the entitlement token (e.g., at sub-operation 444).

[0178] In some embodiments, the process of installing an entitlement token may depend on the type of entitlement token. In some embodiments, the RoT may determine the type of entitlement token (e.g., based on a flag or field within its header) and process the entitlement token accordingly. In some embodiments, for example, when the entitlement token is a software authorization token, the RoT may parse the software authorization token and extract and store the cryptographic key contained therein (e.g., in secure memory of the RoT, such as a key storage area therein). Thereafter, the RoT may be able to use the cryptographic key, for example, to verify that a software object is installed and / or allow a component to load and / or execute the software object (e.g., to boot from debug firmware or load and execute a debug tool). In some embodiments, the RoT may store the software authorization token (e.g., in its non-volatile memory) and may parse and extract the cryptographic key from the software authorization token each time the RoT attempts to verify that a software object is installed and / or allow a component to load and / or execute the software object. In some embodiments, when the entitlement token is a functional configuration token, the RoT may parse the functional configuration token and determine which functionalities are identified therein, and may subsequently configure (e.g., enable or disable) the use of the identified functionalities. In some embodiments, the RoT may store feature enablement tokens (e.g., in its non-volatile memory) and may parse feature configuration tokens to determine which features to configure upon each boot or power cycle of the RoT and / or components it protects.

[0179] In some embodiments, at sub-operation 446, the RoT (e.g., using its processing logic) may notify the BMC of the RoT's success or failure in verifying and / or installing the entitlement token. In some embodiments, for example, when the BMC and the RoT communicate using the MCTP protocol, the RoT may send a corresponding MCTP message (e.g., a VDM) in response, which may include a status code indicating success or failure (and, in some cases, a specific error or reason for failure). In some embodiments, the entitlement token verification and installation process (e.g., operation 440) may be repeated for each entitlement token provided to the RoT for installation (e.g., as part of an entitlement token installation command, at sub-operation 434).

[0180] In some embodiments, after all entitlement tokens have been processed, at operation 450, the BMC (e.g., using its processing logic) may process the remaining software objects in the software update package. In some embodiments, for example, the BMC may parse the software update package to identify software objects intended for one or more components managed by the BMC. In some embodiments, the BMC may extract the identified software objects and provide them to the appropriate RoT for installation on the RoT or the components they protect. In some embodiments, operation 450 may involve one or more sub-operations (e.g., Figure 4In some embodiments, for example, at sub-operation 454, the BMC (e.g., using its processing logic) may issue a software installation or update command (software installation command) to the RoT, instructing the RoT to install the software object (e.g., on the RoT itself or on the components it protects). In some embodiments, the BMC may provide the software object as part of the software installation command.

[0181] In some embodiments, in response to receiving a software object to be installed (e.g., as part of a software installation command issued by a BMC), at operation 460, the RoT (e.g., using its processing logic) may attempt to verify the digital signature of the software object to ensure that the software object can be trusted using one or more cryptographic keys stored therein. In some cases, for example, a software object (e.g., a "secure" firmware update) may be signed using a production key that may be provided to the RoT when the RoT or the component it protects is first manufactured or put into production. In other cases, a software object (e.g., custom debug firmware, useful debugging tools, etc.) may be signed using a non-production key (e.g., a debug key) that may be provided to the RoT, for example, in a software authorization token installed thereon. In some embodiments, if the software object is successfully verified, the RoT may proceed with the installation, for example, by storing the software object in memory (e.g., in memory of the RoT or a component it protects) for subsequent use by a component (e.g., the RoT or a component it protects). In some embodiments, at operation 464, the RoT (e.g., using its processing logic) may notify the BMC of the success or failure of the verification and / or installation, e.g., in a response message sent to the BMC. In some embodiments, at operation 466, the BMC (e.g., using its processing logic) may notify the software distribution system and / or token configuration system of the success or failure of the installation of the software update package (including any entitlement tokens therein), e.g., in a response message sent to the token configuration system.

[0182] In some embodiments, the BMC (e.g., using its processing logic) can disable background copying on the RoT before attempting to install a software object or a particular type of software object (e.g., before installing a firmware image), for example, by issuing a background copy disable request. In some embodiments, disabling background copying on the RoT can prevent the RoT from installing the software object on a particular memory element, such as auxiliary memory storing a backup firmware image (e.g., production-signed firmware). If, for some reason, installation of a firmware image (e.g., debug firmware) to primary memory fails, it may still be possible to fall back to (e.g., boot from) a firmware image in secondary memory. In some embodiments, for example, when the BMC and the RoT communicate using the MCTP protocol, background copying may be disabled by sending a corresponding MCTP message (e.g., a vendor-defined message (VDM)). In some embodiments, in response to receiving the background copy disable request from the BMC, the RoT (e.g., using its processing logic) may provide a response indicating that background copying was (was) not successfully disabled. In some embodiments, for example, when the BMC and the RoT communicate using the MCTP protocol, the RoT may send a corresponding MCTP message (e.g., a VDM) in response. In some embodiments, if background copying is not successfully disabled, the BMC may not issue a software installation command to the RoT (e.g., at sub-operation 454).

[0183] In some embodiments, once the entitlement token is no longer needed (e.g., once testing and verification by the end customer are complete), at operation 472, the BMC (e.g., using its processing logic) may issue an entitlement token removal request, requesting the RoT to uninstall the entitlement token. In some embodiments, upon receiving the token removal request, the RoT (e.g., using its processing logic) may identify any tokens in memory and perform a reverse installation process on them. In some embodiments, for example, the RoT may remove the corresponding stored cryptographic keys or disable one or more enabled features and remove the entitlement token from memory. In some embodiments, for example, at operation 470, the BMC may be configured to issue a token removal request to each RoT it manages upon receiving a software update that does not include a set of entitlement tokens (e.g., using production-signed software). This may be interpreted as an indication that the entitlement token is no longer needed (e.g., testing and verification are complete) and that the system component will be restored to a safe state (e.g., a production state). In some embodiments, at operation 474, the RoT (e.g., using its processing logic) may notify the BMC of the success or failure of the token removal, for example, in a response sent to it. In some embodiments, at operation 476 , the BMC may notify the software distribution system and / or token configuration system about the information, for example, in a response message sent to the software distribution system and / or token configuration system.

[0184] Other variations are within the spirit of the present disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrative embodiments thereof are shown in the drawings and have been described above in detail. However, it should be understood that there is no intention to limit the disclosure to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the disclosure as defined in the appended claims.

[0185] In the context of describing the disclosed embodiments (especially in the context of the following claims), the use of the terms "a," "an," and "the," and similar referents should be interpreted to cover the singular and the plural, unless otherwise indicated herein or clearly contradicted by the context, and are not intended to define the terms. The terms "comprising," "having," "including," and "containing" should be interpreted as open-ended terms (meaning "including, but not limited to,") unless otherwise indicated. "Connected," when unmodified and referring to a physical connection, should be interpreted as partially or completely contained within, attached to, or connected together, even if there is something in between. The recitation of ranges of values herein is intended merely as a shorthand method of referring individually to each individual value falling within the range, unless otherwise indicated herein, and each individual value is incorporated into the specification as if it were individually recited herein. In at least one embodiment, the use of the term "set" (e.g., "a group of items") or "subset" should be interpreted as a non-empty set comprising one or more members, unless otherwise indicated or contradicted by the context. Furthermore, unless otherwise stated or contradicted by context, the term "subset" of a corresponding set does not necessarily mean a true subset of the corresponding set, but a subset and a corresponding set may be equal.

[0186] Unless expressly stated otherwise or clearly contradicted by context, conjunction language (e.g., phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C") should be understood, along with the context, as generally used to indicate that an item, term, or the like can be A or B or C, or any non-empty subset of the set of A, B, and C. For example, in the illustrative example of a set having three members, the conjunction phrases "at least one of A, B, and C" and "at least one of A, B, and C" refer to any one of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, such conjunction language is generally not intended to imply that certain embodiments require the presence of at least one of A, at least one of B, and at least one of C. Furthermore, unless expressly stated otherwise or contradicted by context, the term "plurality" refers to plurality (e.g., "a plurality of items" refers to a plurality of items). In at least one embodiment, the number of the plurality of items is at least two, but may be greater when expressly indicated or indicated by context. Further, unless stated otherwise or clear from context, the phrase "based on" means "based at least in part on" rather than "based solely on."

[0187] Unless otherwise specified herein or clearly contradicted by the context, the operations of the processes described herein may be performed in any suitable order. In at least one embodiment, processes such as the processes described herein (or variations and / or combinations thereof) are performed under the control of one or more computer systems configured with executable instructions and are implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is jointly executed by hardware or a combination thereof on one or more processors. In at least one embodiment, the code is stored on a computer-readable storage medium, for example, in the form of a computer program that includes multiple instructions that can be executed by one or more processors. In at least one embodiment, the computer-readable storage medium is a non-transitory computer-readable storage medium that does not include a transient signal (e.g., a propagating transient electrical or electromagnetic transmission), but includes a non-transitory data storage circuit (e.g., a buffer, a cache, and a queue) within a transient signal transceiver. In at least one embodiment, code (e.g., executable code or source code) is stored on a set of one or more non-transitory computer-readable storage media having executable instructions stored thereon (or other memory for storing executable instructions) that, when executed (e.g., as a result of execution) by one or more processors of a computer system, cause the computer system to perform the operations described herein. In at least one embodiment, the set of non-transitory computer-readable storage media includes a plurality of non-transitory computer-readable storage media, and one or more individual non-transitory storage media in the plurality of non-transitory computer-readable storage media lack all code, while the plurality of non-transitory computer-readable storage media collectively store all code. In at least one embodiment, the executable instructions are executed such that different instructions are executed by different processors—for example, a non-transitory computer-readable storage medium stores instructions, and a main central processing unit ("CPU") executes some instructions, while a graphics processing unit ("GPU") executes other instructions. In at least one embodiment, different components of the computer system have separate processors, and the different processors execute different subsets of instructions.

[0188] Thus, in at least one embodiment, a computer system is configured to implement one or more services that individually or collectively perform the operations of the processes described herein, and such computer system is configured with applicable hardware and / or software that permits the operations to be performed. Furthermore, the computer system implementing at least one embodiment of the present disclosure is a single device, and in another embodiment is a distributed computer system comprising multiple devices operating in different ways such that the distributed computer system performs the operations described herein and such that no single device performs all of the operations.

[0189] The use of any and all examples or exemplary language (e.g., "such as") provided herein is intended merely to better illuminate embodiments of the present disclosure and does not limit the scope of the present disclosure unless otherwise stated. No language in the specification should be construed as indicating any non-claimed element is essential to the practice of the disclosure.

[0190] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

[0191] In the specification and claims, the terms "coupled" and "connected" and their derivatives may be used. It should be understood that these terms may not be synonymous with each other. Rather, in specific examples, "connected" or "coupled" may be used to indicate that two or more elements are in direct or indirect physical or electrical contact with each other. "Coupled" may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0192] Unless expressly stated otherwise, it is understood that throughout this specification, terms such as "process," "compute," "calculate," "determine," etc. refer to the actions and / or processes of a computer or computing system or similar electronic computing device that manipulates and / or transforms data represented as physical (e.g., electronic) quantities in the computing system's registers and / or memories into other data similarly represented as physical quantities in the computing system's memories, registers, or other such information storage, transmission, or display devices.

[0193] Similarly, the term "processor" may refer to any device or portion of a device that processes electronic data from registers and / or memory and converts that electronic data into other electronic data that can be stored in registers and / or memory. As non-limiting examples, a "processor" may be a CPU or a GPU. A "computing platform" may include one or more processors. As used herein, a "software" process may include, for example, software and / or hardware entities that perform work over time, such as tasks, threads, and intelligent agents. In addition, each process may refer to multiple processes for executing instructions sequentially or in parallel, continuously or intermittently. In at least one embodiment, the terms "system" and "method" are used interchangeably herein, as long as a system can embody one or more methods and a method can be considered a system.

[0194] In this document, reference may be made to obtaining, acquiring, receiving, or inputting analog or digital data into a subsystem, computer system, or computer-implemented machine. In at least one embodiment, the process of obtaining, acquiring, receiving, or inputting analog or digital data can be accomplished in a variety of ways, such as by receiving data as a parameter of a function call or a call to an application programming interface. In at least one embodiment, the process of obtaining, acquiring, receiving, or inputting analog or digital data can be accomplished by transmitting data via a serial or parallel interface. In at least one embodiment, the process of obtaining, acquiring, receiving, or inputting analog or digital data can be accomplished by transmitting data from a providing entity to an acquiring entity via a computer network. In at least one embodiment, reference may also be made to providing, outputting, transmitting, sending, or presenting analog or digital data. In various examples, the process of providing, outputting, transmitting, sending, or presenting analog or digital data can be accomplished by transmitting data as input or output parameters of a function call, parameters of an application programming interface, or an interprocess communication mechanism.

[0195] Although the description herein sets forth example embodiments of the technology, other architectures may be used to implement the functionality and are intended to be within the scope of this disclosure. In addition, although specific allocations of responsibilities may be defined above for descriptive purposes, the various functions and responsibilities may be allocated and divided in different ways depending on the circumstances.

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

Claims

1. A method comprising: receiving, by at least one processing device, an attestation report corresponding to a root of trust for a computing system, wherein the attestation report is cryptographically signed using a private key unique to the root of trust; verifying, by the at least one processing device, the attestation report using a public key corresponding to the private key; as well as Based at least on successful verification of the attestation report, an entitlement token is issued by the at least one processing device for the root of trust, allowing the root of trust to take one or more actions with respect to system components protected by the root of trust.

2. The method of claim 1 , wherein the attestation report comprises a signed certificate of the root of trust, the method further comprising: The public key corresponding to the private key is determined using the signing certificate. 3 . The method of claim 1 , wherein the attestation report includes at least one state measurement, and the issued entitlement token includes the at least one state measurement.

4. The method of claim 1 , wherein the attestation report includes at least one status measurement, and wherein verifying the attestation report comprises: Determine whether the at least one state measurement result satisfies a security policy.

5. The method of claim 4, wherein the at least one state measurement comprises at least one of a device identifier or a firmware version, and wherein the security policy indicates whether at least one of the device identifier or the firmware version is authorized to receive an entitlement token.

6. The method according to claim 1, further comprising: A request for an attestation report from the root of trust is sent to the computing system, wherein the request includes an authentication challenge, and wherein the authentication challenge is included in the cryptographically signed attestation report.

7. The method according to claim 1, further comprising: transmitting the entitlement token to the computing system for installation by the root of trust; as well as A confirmation is received that the entitlement token was successfully installed by the root of trust.

8. The method according to claim 1, further comprising: issuing a request to the trusted root to remove the entitlement token; as well as A confirmation is received that the entitlement token has been successfully removed by the root of trust.

9. The method according to claim 1, further comprising: receiving another attestation report corresponding to another root of trust of the computing system, wherein the attestation report is cryptographically signed using another private key unique to the another root of trust; verifying the other attestation report using another public key corresponding to the other private key; issuing, based at least on successful verification of the another attestation report, another entitlement token to the another root of trust, allowing the another root of trust to effect changes to software of another system component protected by the another root of trust; creating a token set comprising the entitlement token and the another entitlement token; as well as The set of tokens is transmitted to the computing system for installation of the entitlement token by the root of trust and installation of the another entitlement token by the another root of trust.

10. The method of claim 1, wherein the one or more actions include at least one of: affecting a change in software of the system component, or configuring functionality provided by the software of the system component.

11. A system comprising: Memory devices; as well as a processing device coupled to the memory device, wherein the processing device is configured to perform operations comprising: receiving an attestation report corresponding to a root of trust for the computing system, wherein the attestation report is cryptographically signed using a private key unique to the root of trust; verifying the attestation report using the public key corresponding to the private key; and Based at least on successful verification of the attestation report, an entitlement token is issued for the root of trust, allowing the root of trust to take one or more actions with respect to system components protected by the root of trust.

12. The system of claim 11 , wherein the attestation report includes a signed certificate of the root of trust, and wherein the processing device is further configured to perform operations comprising: The public key corresponding to the private key is determined according to the signature certificate.

13. The system of claim 11, wherein the certification report includes at least one status measurement result, and wherein, The issued entitlement token includes the at least one state measurement.

14. The system of claim 11 , wherein the attestation report includes at least one status measurement, and wherein verifying the attestation report comprises: Determine whether the at least one state measurement result satisfies a security policy.

15. The system of claim 11, wherein the processing device is further configured to perform operations comprising: A request for an attestation report corresponding to the root of trust is sent to the computing system, wherein the request includes an authentication challenge, and wherein the authentication challenge is included in the cryptographically signed attestation report.

16. A method comprising: generating an attestation report corresponding to a root of trust for the computing system, wherein the attestation report is cryptographically signed using a private key unique to the root of trust; transmitting the attestation report from the computing system to a configuration system for verification using a public key corresponding to the private key; as well as Based at least on successful verification of the attestation report, an entitlement token is received from the configuration system, the entitlement token permitting the root of trust to take one or more actions with respect to system components protected using the root of trust.

17. The method of claim 16, wherein the entitlement token is cryptographically signed by the configuration system using another private key, the method further comprising: verifying the entitlement token by the root of trust using another public key corresponding to the another private key; as well as The entitlement token is installed by the root of trust based at least on a successful verification of the entitlement token.

18. The method according to claim 17, further comprising: generating a confirmation that the entitlement token has been successfully installed by the root of trust; as well as The confirmation is transmitted to the configuration system.

19. The method of claim 17, further comprising: An authentication challenge is transmitted with the attestation report, wherein the entitlement token is included in the cryptographically signed entitlement token.

20. The method of claim 16, further comprising: receiving, by a management controller of the computing system, a request for an attestation report from the configuration system; as well as An attestation report request is issued to the trust root in response to receiving the token solicitation request, wherein the attestation report is generated by the trust root in response to the attestation report request.

Images