Virtual microcontroller for device authentication in confidential computing environment

Abstract

Embodiments relate to a virtual microcontroller for device authentication in a confidential computing environment. Embodiments include a processor to implement a service trust domain (TD) as a virtual microcontroller (VMC) trust domain (VM-TD) for a device, where the VM-TD supports protocols for device authentication, device measurement, and device management; and receiving a VMC certificate chain endorsed by the boot service component, the boot service component comprising at least one trusted module of the confidential computing environment, the VMC certificate chain comprising a root certificate of the boot service component, a boot service module signature certificate, and a complete VMC certificate, the complete VMC certificate comprising an initial VMC certificate and a TD report, the TD report comprising a measurement of the device.

Description

[0001] This application is a divisional application of the invention patent application entitled "Virtual Microcontroller for Device Authentication in a Confidential Computing Environment", which has PCT international application number PCT / CN2022 / 096222, international application date of May 31, 2022, and Chinese national phase application number 202280095579.7. Technical Field

[0002] This disclosure relates generally to confidential computing, and more specifically to virtual microcontrollers for device authentication in confidential computing environments. Background Technology

[0003] Traditionally, devices have added functionality over time, such as accelerating data transformation and migrating functionality from the central processing unit (CPU) to the device. This process also increases the complexity of the device to maintain performance and security. Examples of this evolution can be seen in devices such as network controllers, storage controllers, field-programmable gate arrays (FPGAs), and graphics devices. Today's devices also need to be efficiently shared to enable multi-tenant use such as cloud, virtualization, and containers. These multi-tenant requirements are also implemented via dedicated engines on the device to enforce privilege separation, data pathing, and secure arbitration. Examples of this evolution are observed in virtualized input / output (IO) from direct device assignment (DDA), single-root input-output virtualization (SR-IOV), and Scalable IO virtualization (SIOV).

[0004] TDX (Trust Domain Extension) is a set of instructions in the CPU instruction set architecture (ISA) used to remove the virtual machine monitor (VMM) from the trusted computing base (TCB) of cloud computing virtual machine (VM) workloads (referred to as trust domains or TDs). Generally, a TCB comprises a collection of hardware, firmware, and software components implemented on a platform to provide a secure environment, which includes portions of the platform's memory address space used by the TCB.

[0005] The TDX IO model extends the TDX architecture to allow VMM management outside the TCB to securely dispatch devices to the TD. TDX IO enables secure device dispatch to the TD, protecting data on the link from confidentiality, integrity, and replay attacks. TDX IO also implements an IO memory management unit (IOMMU) attribute, allowing devices to directly access the TD's private memory (DMA) if the TD accepts an interface for the device under test. Attached Figure Description

[0006] The embodiments described herein are shown as examples and not as limitations on the accompanying drawings, in which the same reference numerals refer to similar elements.

[0007] Figure 1 The illustration shows a computing device, according to the implementation described herein, for providing device authentication for confidential computing environments using a virtual microcontroller.

[0008] Figure 2 The illustration shows a computing environment for providing device authentication for a virtual microcontroller in a confidential computing environment, based on the implementation described in this paper.

[0009] Figure 3 The diagram illustrates a confidential computing environment for generating Virtual Microcontroller Trust Domain (VMC-TD) certificates, based on the implementation described in this paper.

[0010] Figure 4 The illustration shows the generation of a complete VMC certificate chain by the system-on-a-chip (SoC) secure boot service module, according to the implementation described in this article.

[0011] Figure 5 The diagram illustrates a block diagram of a confidential computing environment for device authentication, based on the implementation described in this paper.

[0012] Figure 6 The diagram illustrates a confidential computing environment for virtual device measurement and management, based on the implementation described in this paper.

[0013] Figure 7 This is a block diagram illustrating a confidential computing environment that enables seamless updates to the entire VMC-TD, based on the implementation described in this article.

[0014] Figure 8This is a block diagram illustrating a confidential computing environment that enables seamless updates to a portion (variable part) of the VMC-TD, according to the implementation described in this paper.

[0015] Figure 9 This is a flowchart illustrating the operation of a virtual microcontroller provided for a device in a confidential computing environment according to an implementation of this disclosure.

[0016] Figure 10 This is a flowchart illustrating the operation of a virtual microcontroller for device authentication in a confidential computing environment, according to an implementation of this disclosure.

[0017] Figure 11 This is a flowchart illustrating the operation of a virtual microcontroller for device management in a confidential computing environment, according to an implementation of this disclosure.

[0018] Figure 12 This is a flowchart illustrating an implementation of the present disclosure that provides seamless updates of a virtual microcontroller for a device in a confidential computing environment.

[0019] Figure 13 This is an illustrative diagram of an electronic computing device that enables device authentication for confidential computing environments, based on some implementation methods. Detailed Implementation

[0020] The embodiments described herein relate to virtual microcontrollers for device authentication in confidential computing environments.

[0021] In the embodiments described herein, the confidential computing environment may include a Trust Domain Extensions (TDX) confidential computing environment. In some embodiments, the confidential computing environment may include other confidential computing architectures, such as secure encrypted virtualization (SEV).

[0022] TDX includes instructions in the CPU instruction set architecture (ISA) for removing the Virtual Machine Monitor (VMM) from the Trusted Computing Base (TCB) of cloud computing virtual machine (VM) workloads (referred to as Trust Domains or TDs). Generally, a TCB comprises a collection of hardware, firmware, and software components implemented on a platform to provide a secure environment, including portions of the platform's memory address space used by the TCB. The TDX-IO model extends the TDX architecture to allow a VMM outside the TCB to manage devices that can be securely assigned to the TD. TDX-IO enables devices to be securely assigned to the TD, protecting data on the link from confidentiality, integrity, and replay attacks. TDX-IO also implements the IOMMU (Iono Memory Management Unit) attribute, allowing devices to directly use Direct Memory Access (DMA) to the TD's private memory if the TD accepts an interface for the device under test.

[0023] In conventional computing systems, to establish a trust relationship between a device and a TD (Trusted Execution Environment), the TDX-IO architecture instructs the TD and the Trusted Execution Environment (TEE) security manager (TSM) to use the DMTF (Secure Protocol and Data Model, SPDM) to authenticate the device and collect device measurements, and to use the PCI-SIG (Trusted Execution Environment-TEE) Device Interface Security Protocol (TDISP) to manage one or more of the device's functions. As a result, for example, if a device is to be used in a TDX-IO environment, it must implement both the SPDM and TDISP protocols.

[0024] However, to support the SPDM / TDISP protocols, the device should include a root-of-trust (RoT) for storage (RTS) for accessing device private security (such as private keys), a root-of-trust for measurement (RTM) for recording device measurements, and a root-of-trust for report (RTR) for reporting SPDM measurements. The device should also include storage space for the SPDM certificate chain. Furthermore, the device should include logic for implementing the SPDM and TDISP protocols (typically written in software such as C programming languages, Rust, or ADA). Finally, the device should have a microcontroller for firmware and corresponding secure firmware update mechanisms.

[0025] However, in today's computing environment, integrated devices may be simple devices. For example, integrated devices in a System-on-a-Chip (SoC) environment may only consist of a hardware Register Transfer Level (RTL) written in Verilog or VHDL. Therefore, supporting complex protocols such as the SPDM or TDISP protocols described above can be cumbersome and difficult for such integrated devices. Furthermore, in the example SoC environment, there may be multiple simple integrated devices that need to establish trust relationships with the TD. In this case, providing storage space and complex logic to support establishing such trust relationships may be inefficient in terms of processing resources and space.

[0026] The embodiments described herein provide a virtual microcontroller for device authentication in confidential computing environments. A dedicated service TD is implemented as a virtual microcontroller (VMC) for integrated devices. This dedicated service TD is referred to herein as VMC-TD. The service TD can be software with minimal impact on existing devices in the computing environment. The service TD allows support to be added on top of existing integrated devices, such as small integrated devices on a SoC. The service TD can be updated without affecting the hardware. If a vulnerability is discovered in the service TD, the service TD can be stopped (e.g., disassembled, removed), and a new service TD can be restarted. Furthermore, the service TD has no memory size limitation. For example, the service TD can declare memory usage, and the VMM can then allocate sufficient memory for it.

[0027] In the implementation described in this paper, VMC-TD can be considered part of the device's Chain of Trust (CoT). VMC-TD may include protocols (e.g., SPDM / TDISP protocols) for establishing communication and trust relationships with TD and TSM. In some implementations, VMC-TD may not have a private key. Alternatively, VMC-TD can generate alias key pairs and certificates at runtime and require a known trusted module (such as the secure startupservice module, S3M) to sign the certificates as an endorser.

[0028] Figure 1 The illustration shows a computing device 100 for providing a virtual microcontroller for device authentication in a confidential computing environment, according to an implementation described herein. In one implementation, the computing device 100 includes a processor 120, an accelerator device 136, and an integrated device 138. The accelerator device 136 may include, but is not limited to, a graphics processing unit (GPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), a datastreaming accelerator (DSA), and so on.

[0029] The computing device 100 can be embodied as any type of device capable of performing the functions described herein. For example, the computing device 100 can be embodied as, but not limited to, a computer, laptop computer, tablet computer, notebook computer, mobile computing device, smartphone, wearable computing device, multiprocessor system, server, workstation, and / or consumer electronic device. Figure 1 As shown, the illustrative computing device 100 includes a processor 120, an I / O subsystem 124, a memory 130, and a data storage device 132. Additionally, in some embodiments, one or more illustrative components may be incorporated into another component or otherwise form part of another component. For example, in some embodiments, the memory 130 or a portion thereof may be incorporated into the processor 120.

[0030] Processor 120 may be embodied as any type of processor capable of performing the functions described herein. For example, processor 120 may be embodied as one or more single-core processors or one or more multi-core processors, digital signal processors, microcontrollers, or other processors or processing / control circuitry. As shown, processor 120 illustratively includes secure enclave support 122, which allows processor 120 to establish a trusted execution environment, referred to as a secure enclave, in which executable code can be measured, verified, and / or otherwise determined to be authentic. Additionally, the code and data included in the secure enclave may be encrypted or otherwise protected from access by code executing outside the secure enclave. For example, the code and data included in the secure enclave may be protected by hardware protection mechanisms of processor 120 when executed or when stored in certain protected cache memories of processor 120. The code and data included in the secure enclave may be encrypted when stored in shared cache or main memory 130.

[0031] Security enclave support 122 may be embodied as a processor instruction extension set that allows processor 120 to establish one or more security enclaves in memory 130. For example, security enclave support 122 may be embodied as Intel® Software Guard Extensions (SGX) technology. In other embodiments, processor 120 may include a trusted domain (TD) embodied as Intel® Trusted Domain Extensions (TDX) 123 technology, which is implemented to isolate virtual machines from the virtual machine monitor and other virtual machines running on computing device 100.

[0032] Memory 130 can be embodied as any type of volatile or non-volatile memory or data storage device capable of performing the functions described herein. In operation, memory 130 may store various data and software used during the operation of computing device 100, such as operating systems, applications, programs, libraries, and drivers. As shown, memory 130 may be communicatively coupled to processor 120 via I / O subsystem 124, which can be embodied as a circuit system and / or components for facilitating input / output operations with processor 120, memory 130, and other components of computing device 100. For example, I / O subsystem 124 may be embodied as or otherwise include: a memory controller hub, an input / output control hub, a sensor hub, a host controller, firmware devices, communication links (i.e., point-to-point links, bus links, lines, cables, light guides, printed circuit board traces, etc.) and / or other components and subsystems for facilitating input / output operations. In some embodiments, memory 130 may be directly coupled to processor 120, for example, via an integrated memory controller hub. Additionally, in some embodiments, the I / O subsystem 124 may form part of a system-on-a-chip (SoC) and may be integrated onto a single integrated circuit chip along with processor 120, memory 130, accelerator device 136, and / or other components of computing device 100. Additionally or alternatively, in some embodiments, processor 120 may include an integrated memory controller and a system agent, which may be embodied as a logic block in which data traffic from the processor core and I / O devices converges before being sent to memory 130.

[0033] As shown, I / O subsystem 124 includes a direct memory access (DMA) engine 126 and a memory-mapped I / O (MMIO) engine 128. Processor 120, including a secure enclave established with secure enclave support 122, can communicate with integrated device 138 using DMA engine 126 through one or more DMA transactions and / or using MMIO engine 128 through one or more MMIO transactions. Computing device 100 may include multiple DMA engines 126 and / or MMIO engines 128 for handling DMA and MMIO read / write transactions based on the bandwidth between processor 120 and integrated device 138. Although shown as included in I / O subsystem 124, it should be understood that in some embodiments, DMA engine 126 and / or MMIO engine 128 may be included in other components of computing device 100 (e.g., processor 120, memory controller, or system agent), or in some embodiments may be embodied as separate components.

[0034] Data storage device 132 can be embodied as one or more devices of any type configured for short-term or long-term storage of data, such as, for example, memory devices and circuits, memory cards, hard disk drives, solid-state drives, non-volatile flash memory, or other data storage devices. Computing device 100 may also include a communication subsystem 134, which can be embodied as any communication circuitry, device, or combination thereof capable of enabling communication between computing device 100 and other remote devices via a computer network (not shown). Communication subsystem 134 can be configured to implement such communication using any one or more communication technologies (e.g., wired or wireless communication) and associated protocols (e.g., Ethernet, Bluetooth®, Wi-Fi®, WiMAX, 3G, 4G LTE, etc.).

[0035] Integrated device 138 may be embodied as a GPU, FPGA, ASIC, DSA, coprocessor (such as CPU, GPU, etc.), or other digital logic device capable of performing functions (e.g., accelerated application functions, accelerated network functions, or other accelerated functions). Integrated device 138 may be coupled to processor 120 via a high-speed interconnect or via any other suitable interconnect, such as a peripheral bus (e.g., PCI Express bus) or inter-processor interconnect (e.g., in-die interconnect (IDI) or QuickPath Interconnect (QPI)). Integrated device 138 may receive data and / or commands for processing from processor 120 via DMA, MMIO, or other data transfer transactions and return the resulting data to processor 120.

[0036] The integrated device 138 may further include one or more peripheral devices. Peripheral devices may include any number of additional input / output devices, interface devices, hardware accelerators, and / or other peripheral devices. For example, in some embodiments, peripheral devices may include a touchscreen, a graphics circuitry system, a graphics processing unit (GPU) and / or processor graphics, audio devices, a microphone, a camera, a keyboard, a mouse, a network interface, and / or other input / output devices, interface devices, and / or peripheral devices.

[0037] The computing device 100 may also include a network interface controller (NIC) 150. The NIC 150 enables the computing device 100 to communicate with another computing device 100 via a network. In embodiments, the NIC 150 may include a programmable (or intelligent) NIC, an infrastructure processing unit (IPU), or a datacenter processing unit (DPU), which may be configured to perform different actions based on packet type, connection, or other packet characteristics.

[0038] In use, as further described below, the Trusted Execution Environment (TEE) established by processor 120 securely communicates data with accelerator 136 and integrated device 138. Data can be transferred using memory-mapped I / O (MMIO) transactions or direct memory access (DMA) transactions. For example, the TEE can perform an MMIO write transaction including encrypted data, and accelerator device 136 and / or integrated device 138 decrypts the data and performs the write. As another example, the TEE can perform an MMIO read request transaction, and accelerator device 136 and / or integrated device 138 can read the requested data, encrypt the data, and perform an MMIO read response transaction including encrypted data. As yet another example, the TEE can be configured to perform DMA operations, and accelerator device 136 and / or integrated device 138 performs memory transfers, performs cryptographic operations (i.e., encryption or decryption), and forwards the results.

[0039] As further described below, the processor can provide VMC-TD 121 for device authentication in a confidential computing environment provided in computing device 100. VMC-TD 121 can be implemented as a service TD. VMC-TD 121 provides a way to minimize firmware actions during handover to the OS while allowing a secure runtime interface from firmware to the OS for secure and / or easy device initialization. The implementation of this disclosure provides the technical advantages of reducing the trusted computing base (TCB) and allowing improved boot times (e.g., faster boot). Furthermore, the implementation provides the ability to minimize the space footprint before the OS and implement a trusted runtime attached to the OS. This can minimize the impact of integrated devices and add support for the TDX-IO architecture. Further details of the implementation and operation of VMC-TD 121 are described below. Figures 2-13 To provide.

[0040] While the implementations described in this article are discussed in relation to the TDX-IO architecture, they are not limited to this type of architecture, and other confidential computing protocols and architectures (such as AMD® SEV®) can also utilize the implementations described in this article.

[0041] Turn now Figure 2 This paper describes an example confidential computing environment for providing a virtual microcontroller for device authentication, based on the implementation described herein.

[0042] Figure 2 The illustration shows a computing environment 200 for providing device authentication for a virtual microcontroller in a confidential computing environment, according to an implementation described herein. In one implementation, the computing environment 200 may be related to a reference... Figure 1 The computing device 100 described herein is identical. The computing environment 200 may include a host CPU 210, an integrated device 260, and a secure boot component 270. In the implementation herein, the host CPU 210 may implement a confidential computing environment via one or more TDs, including TD-1 220A and TD-2 220B (collectively referred to herein as TD 220). TD 220 may be a hardware-isolated VM, isolated from the VMM 250 (or hypervisor) and other non-TD software within the computing environment 200.

[0043] To aid in the implementation of security policies for the TD 220, the host CPU 210 can operate the TDX module 240, which is controlled within a reserved memory space of the host CPU 210, in a mode known as secure-arbitration mode (SEAM). SEAM mode provides a security service model. In one embodiment, the reserved memory space may be identified by a SEAM range register. The host CPU 210 may allow software executing within the SEAM memory range to access the SEAM memory range. All other software access from the device to this memory range is aborted. The SEAM memory range also utilizes a temporary memory encryption key to provide cryptographic confidentiality protection. Memory integrity can also be implemented using cryptographic integrity protection schemes or logical integrity protection schemes.

[0044] TDX module 240 helps ensure that active execution control over TD 220 does not allow VMM 250 or other untrusted entities to intercept TD access to resources assigned by the TD, such as control registers, performance monitoring counters, timestamp counters, etc. TDX module 240 can implement security policies for TD 220. An example of such a security policy could be that, when switching TD 220, TDX module 240 uses an indirect-branch-prediction barrier (IBPB) to help prevent TD indirect branch prediction from being affected by previously executed code in TD 220.

[0045] As previously described, TD 220 may seek to establish a trust relationship with one or more integrated devices 260 of computing environment 200. Confidential computing architectures such as TDX architectures support TDX with device I / O, also known as TDX-IO. TDX-IO enables the assignment of virtual functions (VFs) of integrated devices 260 to specific TD 220, such as VF-1 262A or VF-2 262B (collectively referred to as VF 262). VF 262 may be a virtualized portion of physical function 264 provided by integrated device 260. VF 262 may be a lightweight function that shares one or more physical resources with physical function 264 and with VF 262 associated with that physical function 264. Unlike physical function 264, VF 262 can be configured with its own behavior.

[0046] More specifically, the implementation described herein provides a Virtual Microcontroller Trust Domain (VMC-TD) 230, which is implemented as a service TD in the host CPU 210. The VMC-TD 230 can master the device security manager 235 to support the SPDM / TDISP protocol for the integrated device 260, thereby establishing a trust relationship between the TD 220 and the integrated device 260. The VMC-TD 230 can use the SPDM / TDISP protocol to communicate with the TEE security manager (TSM), thereby collaborating with the TD 220 to establish a trusted relationship for TDX-IO. When using the VMC-TD 230 to establish a trust relationship for confidential computation between the TD 220 and the integrated device 260, the implementation described herein considers the following aspects: device identity, device authentication, device measurement, virtual device management, and seamless updates.

[0047] Device Identity

[0048] The VMC-TD 230 does not include any persistent storage and cannot retain any private keys used for device identification. Instead, in the implementation described herein, the VMC-TD 230 can generate an alias private / public key pair at runtime, subsequently requesting a Secure Boot Component 270 (such as a startup service module (S3M) or quoting enclave (QE)) to sign a public alias certificate containing the alias public key. The Secure Boot Component 270 includes a VMC-TD endorser 272 to provide endorser services. The Secure Boot Component 270 acts as an endorser to sign the VMC-TD alias certificate and return a certificate chain, where the root certificate is the certificate of the Secure Boot Component 270. The Secure Boot Component 270 may include a secure key storage area for storing device secrets 274, such as the certificate signing key of the Secure Boot Component 270.

[0049] Figure 3 The diagram illustrates a block diagram of a confidential computing environment 300 for VMC-TD certificate generation, according to the implementation described herein. In one implementation, the confidential computing environment 300 may be... Figure 1 Computing device 100 and / or Figure 2 The confidential computing environment 300 may include a SoC 330, which hosts a VMV-TD 310, a TDX module 320, an SoC device 340, an SoC CPU core 350, and an SoC S3M 360. In one embodiment, the VMV-TD 310 and... Figure 2 The VMC-TD230 is the same, and the TDX module 320 is the same as... Figure 2 The TDX module 240 is the same. The SoC device 340 can be with... Figure 2 The integrated device 260 is the same. The SoC CPU core 350 can be with... Figure 2 The host CPU is the same as the 210, and the SoC S3M 360 can be used with... Figure 2 The Secure Boot component is the same as 270.

[0050] The confidential computing environment 300 provides VMC-TD certificate chain generation. In one example, VMC-TD certificate chain generation can utilize DSA as the SoC device 340 and S3M 360 as the boot service component.

[0051] The following discussion provides an example demonstration of the VMC-TD certificate chain generation process for device identity. In one embodiment, VMC-TD 310 may generate a key pair 312 and subsequently create an initial VMC certificate 314 with the public key from that key pair 312. VMC-TD 310 can then use the initial VMC certificate 314 to invoke a certificate generation call (i.e., 301), such as TDCALL GenCertChain (TD call to generate certificate chain).

[0052] TDX module 320 can receive a certificate generation call 301 (e.g., TDCALL) from VCM-TD 310. Subsequently, TDX module 320 can request (i.e., 302) device measurements from the hardware registers of SoC device 340. SoC device 340 can respond to the request by returning (i.e., 303) device measurements to TDX module 320.

[0053] Subsequently, TDX module 320 can extract the public key from initial VMC certificate 314 and create a hash of the public key. TDX module 320 can then request (i.e., 304) SoC CPU core 350 to generate a SEAMREPORT using the VMC public key hash and device measurements. A SEAMREPORT can refer to a proof structure (e.g., a report) cryptographically bound to platform hardware using a message authentication code (MAC). The SEAMREPORT instruction is designed to take as input the verification information provided by VMC-TD 310 (e.g., the VMC public key hash), TD measurements, and additional information provided by TDX module 320, and generate a "report" structure that includes the security version number (SVN) of the TDX TCB element. This "report" structure is designed to protect integrity using a MAC (e.g., the SEAMREPORT MAC key). In some implementations, SEAMREPORT can be used to assist in generating remote verification citations.

[0054] The SoC CPU core 350 can generate a SEAMREPORT and return it (i.e., 305) to the TDX module 320. Once the SEAMREPORT is received, the TDX module 320 can generate a TD_REPORT (TD_report) 322 based on the SEAMREPORT. The TD_REPORT 322 can refer to the verification of measurements of the TD (e.g., VMC-TD 310) and can include a structure containing the TD measurements, the measurements of the TDX module 320, and values ​​provided by the TD software (e.g., VMC-TD 310). In some implementations, the TD_REPORT 322 includes VMC-TD 310 measurement registers (e.g., TD MR) and runtime measurement registers (e.g., RTMR), which can be used to verify the integrity status of the VMC-TD 310. The TD_REPORT 322 can also include device measurements of the SoC device 340, which can be used to identify the SoC device 340.

[0055] The TDX module 320 can insert TD_REPORT 322 along with the initial VMC certificate 314 to generate a complete VMC certificate 324, which has a TEE report object identifier (OID). Subsequently, the TDX module 320 requests (i.e., 306) the SoC S3M 360 or a separate QE to sign the complete VMC certificate 324.

[0056] The SoC S3M 360 receives a request 306 from the TDX module 320 to sign the complete VMC certificate 324, and signs the complete VMC certificate 324 using the S3M certificate signing key 365 maintained by the SoC S3M 360. In one implementation, the S3M certificate signing key 365 may refer to the SEAMREPORT MAC key (obtained from the SoC CPU core 350). See below for reference. Figure 4Further details of the process are discussed below. The SoC S3M 360 returns (i.e., 307) the complete VMC certificate chain to the TDX module 320. The complete VMC certificate chain includes the S3M root certificate, the S3M signing certificate, and the signed complete VMC certificate (including TD_REPORT). Finally, in response to a certificate generation call (e.g., TDCALL) issued by the VMC-TD 310, the TDX module 320 returns (i.e., 308) the complete VMC certificate chain to the VMC-TD 310. The VMC-TD 310 can then use the complete VMC certificate chain as the identity of the SoC device 340 when establishing a trusted relationship for communication with the SoC device 340. In addition to the SoC S3M, signing can also be performed using a quoting enclave (QE) as endorsement.

[0057] Figure 4 The diagram is based on the implementation method described in this article, and is composed of... Figure 3 The SoC S3M 360 generates a complete VMC certificate chain. In one implementation, Figure 3 The SoC 330 is shown as including the SoC CPU core 350 and the SoC S3M 360. (See above for reference.) Figure 3 As discussed, steps 304 and 305 involve TDX module 320 requesting a SEAMREPORT from CPU core 350, CPU core 350 generating a SEAMREPORT, and CPU core 350 returning the SEAMREPORT (i.e., 305) to TDX module 320. However, in some implementations, these steps (304 and 305) may not necessarily be performed when the SoC S3M 360 is capable of obtaining the MAC key from the SoC CPU core 350.

[0058] For example, the SoC S3M 360 can issue a hidden MSR read 410 to the SoC CPU core 350. The MSR may be controlled by a policy (e.g., a SAI policy) that allows the SoC S3M 360 to read the MSR. Once the SoC S3M 360 obtains the SEAMREPORT MAC key 420, this key 420 can be stored in the secure key storage area 430 of the SoC S3M 360. The secure key storage area 430 can use confidentiality protection to store key 420 together with other S3M keys, such as the device private key or the root MAC key.

[0059] Equipment Certification

[0060] Figure 5The diagram illustrates a block diagram of a confidential computing environment 500 for device authentication according to an implementation described herein. In one implementation, the confidential computing environment 500 may be... Figure 1 Computing device 100 and / or Figure 2 The confidential computing environment 500 is part of the computing environment 200. The confidential computing environment 500 may include a VMM 510, a master SPDM agent 520, and a device host driver 530. The confidential computing environment 500 may also include a TSM 540 and a VMC-TD 550. In one embodiment, the VMM 510 and... Figure 2 The VMM250 is the same as the VMC-TD 550. Figure 2 The VMC-TD 230 is the same, and the TSM 540 is the same. Figure 2 It is the same as the TSM 225.

[0061] As part of establishing a trusted relationship for communication between the TD and the device within the confidential computing environment 500, the confidential computing environment 500 provides device authentication. In one example, the device authentication process may utilize the SPDM protocol to authenticate the device. However, the implementation described herein may also utilize other device authentication protocols, and these protocols are not limited to the SPDM protocol used for device authentication. For ease of explanation, the following discussion of device authentication in the confidential computing environment 500 is described as utilizing the SPDM protocol.

[0062] The TSM 540 issues the SPDM GET_CERTIFICATE command (SPDM GET_CERTIFICATE) to obtain the device's VMC-TD certificate chain. In one implementation, the device's VMC-TD certificate chain is associated with, for example, in... Figure 3 The generated VMC certificate chain is identical to that discussed earlier. If the TSM 540 seeks to authenticate the device, it can generate a present value and send an SPDM command – CHALLENGE (nonce) – to the device's VMC-TD 550. Subsequently, the device's VMC-TD 510 signs the transcribed message with its key and returns CHALLENGE_AUTH to the TSM 540. The TSM 540 can then use the leaf certificate to verify the signature.

[0063] In the implementation described herein, to enable the TSM 540 to communicate with the VMC-TD 550 using the SPDM protocol for device authentication purposes, the device host driver 530 is implemented in the VMM 510. Since the TSM cannot directly access the device and the VMM 510 possesses system resources, the TSM 540 can send a device SPDM request to the VMM 510 (i.e., 501). The VMM 510 can implement an SPDM agent 520, which can forward the SPDM request (i.e., 502) to the device host driver 530 because the SPDM responder is the device.

[0064] Device host driver 530 can then identify device VMC-TD 550 and inject (i.e., 503) an SPDM request into it. VMC-TD 550 can process the SPDM request, generate an SPDM response, and send the response back (i.e., 504) to device host driver 530. For example, in some implementations, VMC-TD 550 can use a virtio interface or mailbox setup between VMC-TD 550 and device host driver 530 for this communication.

[0065] Device host driver 530 can return an SPDM response (i.e., 505) to SPDM agent 520 of VMM 510. Finally, SPDM agent 520 can return an SPDM response (i.e., 506) to TSM 540 for device authentication purposes.

[0066] Equipment Measurement

[0067] Reference Figure 5 In the implementation described herein, the TSM 540 can also seek to obtain device measurements. As detailed below, the TSM 540 can also utilize the SPDM protocol for the device measurement process. Various techniques may exist for obtaining device measurements, two of which are discussed below.

[0068] Regarding the first technique, in one implementation, the TSM 540 can use the SPDM GET_MEASUREMENTS command, which is sent to the device VMC-TD 550. Once the device VMC-TD 550 receives such a request, it extracts the TDMR and RTMR from the TD report, as well as device measurements (such as ROM, firmware, hardware configuration, firmware configuration, device status, etc.), generates an SPDM measurement block, and returns the SPDM measurement block.

[0069] Regarding the second technology, in one implementation, the TSM 540 parses the VMC-TD certificate, extracts TDMR and RTMR from TD_REPORT, and directly extracts device measurements.

[0070] Virtual device measurement

[0071] After the device authentication and measurement process is completed (e.g., via establishing an SPDM connection), the TSM can use the TDISP protocol to control the virtual functions (VFs) or interfaces of devices in a confidential computing environment (e.g., a TDX architecture). For example, in a confidential computing environment, a device's virtual function 1 (VF-1) can be assigned to a first TD (TD-1), a device's virtual function 2 (VF-2) can be assigned to a second TD (TD-2), and so on.

[0072] Figure 6 The diagram illustrates a block diagram of a confidential computing environment 600 for virtual device measurement and management, according to an implementation described herein. In one implementation, the confidential computing environment 600 may be... Figure 1 Computing device 100 and / or Figure 2 This is part of the computing environment 200. The confidential computing environment 600 may include a host CPU 610 and a device 640. The host CPU 610 may control one or more TDs, and a VMC-TD 630, including TD-1 620A and TD-2 620B (collectively referred to herein as TD 620). The device 640 may include one or more virtual functions (VFs) and physical functions and managers 660, including VF-1 650A and VF-2 650B (collectively referred to herein as VF 650). VF 650 may be a virtualization of the resources of the physical functions and managers 660.

[0073] The confidential computing environment 600 may also include a TDX module 680 for communicatively coupling the VMC-TD 630 and the physical functions and manager 660. In one embodiment, the host CPU 610 and... Figure 2 The host CPU is the same as 210, and the device is 640 and... Figure 2 The integrated device 260 is the same as that of the TD 620. Figure 2 The same as the TD 220, VF 650 and Figure 2 The VF 262 is the same, with physical functions and manager 660. Figure 2 The physical functions are the same as 264, and the TDX module 680 is the same as... Figure 2 It is the same as the TDX module 240.

[0074] As part of establishing a trusted relationship for communication between TD 620 and device 640 within the confidential computing environment 600, the confidential computing environment 600 provides virtual device measurement and management. In one example, the device authentication process may utilize the TDISP protocol to manage the VF 650 of device 640 and manage device 640. However, the implementation described herein may also utilize other device authentication protocols, and this is not limited to the TDISP protocol used for the management of device(s) functions. For ease of explanation, the following discussion of virtual device management in the confidential computing environment 600 is described as utilizing the TDISP protocol.

[0075] In some implementations, the TSM (not shown) may issue TDISP commands to the TD 620 for managing (e.g., assigning, not assigning, etc.) the VF 650 of device 640. Since the VMC-TD 630 is the party receiving the TDISP commands, it should be able to communicate with the physical function and manager 660 in device 640. In some implementations, DMA or MMIO 670 may be used for communication between the TD 620 and VF 650. During platform boot-time configuration, a process initiated as part of the basic input / output system (BIOS) is performed to collect MMIO space. This process may be called MCHECK in some implementations, but may be called by other names or may be a different process in others. The MCHECK process may report the MMIO page addresses of device 640 to the TDX module 680.

[0076] In some implementations, the MMIO page address accepts transactions with an integrity and data encryption (IDE) value of ide_t = 1. A transaction with ide_t = 1 can be generated when an MMIO request is made using the TDX key ID. Since only the TD 620 can make access using the TDX key ID, this allows the VMC-TD 630 to access the MMIO page. The TDX module 680 can then map this MMIO page from the device 640 to the VMC-TD 630.

[0077] Seamless updates

[0078] The VMC-TD implementation described in this paper should also support seamless update use cases. Seamless updates refer to actions taken on the system during firmware runtime without removing the services provided by the firmware. Motivations for such firmware updates could include, for example, vulnerability fixes, security improvements, or performance enhancements.

[0079] For VMC-TD and seamless updates, SPDM should remain operational even if the device's VMC-TD is to be updated. To support seamless updates as described in this implementation, VMC-TD should store SPDM session information (e.g., AEAD key, AEADIV, session sequence number) as VMC-TD data (VMC-TD information).

[0080] The implementation described in this paper provides at least two seamless update options for VMC-TD. However, the implementation described in this paper can also utilize other seamless update options, and these options are not limited to those described in this paper.

[0081] The first option for seamless VMC-TD updates includes a complete (e.g., overall) VMC-TD update. Figure 7 This is a block diagram illustrating a confidential computing environment 700 that enables seamless updates to the entire VMC-TD according to the implementation described herein. The confidential computing environment 700 includes three phases for the seamless update process of the entire VMC-TD: before update 710, during update 720, and after update 730.

[0082] As part of a seamless update process for the entire VMC-TD, the VMM removes the old (previous) VMC-TD 740 and starts the new VMC-TD 770. Thus, the entire VMC-TD is updatable. In the pre-update phase 710, the previous VMC-TD 740 saves its VMC-TD data 755 to the TDX module storage area 750 before the update (i.e., 710), and restores this VMC-TD data 755 to the new VMC-TD 770 after the update (i.e., 730).

[0083] In some implementations, since VMC-TD 740 is a dedicated service TD, it can be bound to the TDX module 760. For example, the TDX module 760 can launch VMC-TDs that are "known" to be good (verified, certified, and trusted). To support this during seamless updates to VMC-TD 740, updates to both the TDX module and VMC-TD can be performed together. When the TDX module updates itself, it guarantees that the Secure Version Number (SVN) will not be downgraded. The TDX module can also guarantee that the SVN of the new VMC-TD 770 will not be downgraded.

[0084] The second option for seamless VMC-TD updates includes updating parts of the VMC-TD, such as variable parts. Figure 8This is a block diagram illustrating a confidential computing environment 800 that enables seamless updates to portions (variable parts) of the VMC-TD according to the implementation described herein. The confidential computing environment 800 includes three phases for the seamless update process of portions of the entire VMC-TD: before update 810, during update 820, and after update 830.

[0085] If a complete teardown and reboot of the VMC-TD is not utilized, the implementation can allow the VMC-TD to accept updated payloads. In one implementation, the VMC-TD is partitioned into an immutable portion 860, a storage area 850, and a mutable portion (previous version) 840. The immutable portion 860 of the VMC-TD is used as the root-of-trust for update (RTU). The RTU is not updatable, while the mutable portion (previous version) 840 can be updated.

[0086] Before the update (i.e., 810), the previous version 840 of the variable part of VMC-TD should save VMC-TD data 855 to VMC-TD storage area 850. During the update (i.e., 820), the previous version 840 of the variable part of VMC-TD is unpacked and updated. In some implementations, when the VMC-TD RTU performs the update (i.e., 820), the VMC-TD RTU should check the integrity of the updated payload via digital signature and ensure that SVN is not degraded. Subsequently, after the update (i.e., 830), the new version 870 of the variable part of VMC-TD is restored using the VMC-TD data 855.

[0087] Figure 9 This is a flowchart illustrating operation 900 of a virtual microcontroller provided for a device in a confidential computing environment according to an implementation of the present disclosure. Operation 900 (or other processes or variations and / or combinations thereof described herein) is executed under the control of one or more computer components (e.g., executable instructions, one or more computer programs, or one or more applications) configured to execute code and implemented as code. The code is stored, for example, on a computer-readable storage medium in the form of a computer program including instructions executable by one or more processors. The computer-readable storage medium is non-transitory. In some embodiments, one or more operations (or all operations) of operation 900 are executed by a processor (processing device, processor apparatus, processor hardware circuitry, processing hardware circuitry, etc.), such as... Figure 2 The host CPU is 210.

[0088] Operation 900 includes: at block 910, the processor may implement the service TD as a VMC-TD for the device. In one implementation, the VMC-TD may support protocols for device authentication, device measurement, and device management within a confidential computing environment. Such protocols may include, for example, the SPDM protocol and / or the TDISP protocol. At block 920, the processor may generate an alias key pair including a public key and a private key from the VMC-TD.

[0089] Subsequently, at box 930, the processor can generate an initial VMC certificate from the VMC-TD, including the public key from the alias key pair. At box 940, the processor can use the initial VMC certificate from the VMC-TD to request a VMC certificate chain.

[0090] Subsequently, at block 950, the processor can receive a VMC certificate chain endorsed by a bootstrap service component, which is a trusted module of the confidential computing environment, via the VMC-TD. In one implementation, the VMC certificate chain includes a root certificate of the bootstrap service component, a bootstrap service module signing certificate, and a complete VMC certificate, which includes an initial VMC certificate and a TD report containing measurements of the device corresponding to the VMC-TD. Finally, at block 960, the processor can enable one or more TDs to access one or more VFs of a device via the VMC-TD, wherein the device is authenticated using the VMC certificate chain.

[0091] Under appropriate circumstances, Figure 9 Some of the operations illustrated may be repeated, combined, modified, or deleted, and additional steps may be added to the process in various embodiments. Additionally, the steps may be performed in any suitable order without departing from the scope of a particular embodiment.

[0092] Figure 10 This is a flowchart illustrating operation 1000 of a virtual microcontroller providing device authentication in a confidential computing environment according to an implementation of this disclosure. Operation 1000 (or other processes or variations and / or combinations thereof described herein) is executed under the control of one or more computer components (e.g., executable instructions, one or more computer programs, or one or more applications) configured to execute code and implemented as code. The code is stored, for example, on a computer-readable storage medium in the form of a computer program including instructions executable by one or more processors. The computer-readable storage medium is non-transitory. In some embodiments, one or more operations (or all operations) of operation 1000 are executed by a processor (processing device, processor apparatus, processor hardware circuitry, processing hardware circuitry, etc.), such as... Figure 2 The host CPU is 210.

[0093] Operation 1000 includes: at block 1010, the processor can identify the device to be authenticated by the TSM as part of establishing a trusted communication channel between the device and one or more TDs managed by the TSM. Subsequently, at block 1020, the processor can send an authentication command to the VMC-TD bound to the device.

[0094] At box 1030, the processor can intercept authentication commands by controlling one or more TDs and the VMM of the VMC-TD and forward the authentication commands to the device's host driver. Subsequently, at box 1040, the processor can inject authentication commands into the VMC-TD identified as being bound to the device by the device's host driver.

[0095] Subsequently, at box 1050, the processor can have the VMM return a response to the authentication command generated by the VMC-TD and provided to the host driver. In one implementation, the response is returned to the TSM. The VMC-TD can then sign the response with its private key, and the TSM can verify the signature using the complete VMC certificate chain of the VMC-TD. Finally, at box 1060, the processor can have the TSM verify the signature of the response using the complete VMC certificate chain of the VMC-TD.

[0096] Under appropriate circumstances, Figure 10 Some of the operations illustrated may be repeated, combined, modified, or deleted, and additional steps may be added to the process in various embodiments. Additionally, the steps may be performed in any suitable order without departing from the scope of a particular embodiment.

[0097] Figure 11 This is a flowchart illustrating operation 1100 of a virtual microcontroller for device management in a confidential computing environment, according to an implementation of the present disclosure. Operation 1100 (or other processes or variations and / or combinations thereof described herein) is executed under the control of one or more computer components (e.g., executable instructions, one or more computer programs, or one or more applications) configured to execute code and implemented as code. The code is stored, for example, on a computer-readable storage medium in the form of a computer program including instructions executable by one or more processors. The computer-readable storage medium is non-transitory. In some embodiments, one or more operations (or all operations) of operation 1100 are executed by a processor (processing device, processor apparatus, processor hardware circuitry, processing hardware circuitry, etc.), such as... Figure 2 The host CPU is 210.

[0098] Operation 1100 includes: at block 1110, the processor can establish a trusted communication channel between the device and the TD using the VMC-TD bound to the device to enable device authentication and device measurement. Subsequently, at block 1120, the processor can map the device's MMIO page address to the VMC-TD. In one implementation, the MMIO page accepts transactions where the integrity and data encryption (ide_t) parameters are set.

[0099] Subsequently, at box 1130, the processor can receive from the TD a request to communicate with the device's Virtual Function (VF) via the MMIO page address using the TDX key ID. At box 1140, the processor can generate a transaction to access the MMIO page at the MMIO page address. In one implementation, the transaction's ide_t parameter is set in response to the TDX key ID being part of the request. Finally, at box 1150, the processor can use the generated transaction to access the VF via the MMIO page.

[0100] Under appropriate circumstances, Figure 11 Some of the operations illustrated may be repeated, combined, modified, or deleted, and additional steps may be added to the process in various embodiments. Additionally, the steps may be performed in any suitable order without departing from the scope of a particular embodiment.

[0101] Figure 12 This is a flowchart illustrating operation 1200, which provides seamless updates of a virtual microcontroller for a device in a confidential computing environment, according to an implementation of this disclosure. Operation 1200 (or other processes or variations and / or combinations thereof described herein) is executed under the control of one or more computer components (e.g., executable instructions, one or more computer programs, or one or more applications) configured to execute code and implemented as code. The code is stored, for example, on a computer-readable storage medium in the form of a computer program including instructions executable by one or more processors. The computer-readable storage medium is non-transitory. In some embodiments, one or more operations (or all operations) of operation 1200 are executed by a processor (processing device, processor apparatus, processor hardware circuitry, processing hardware circuitry, etc.), such as... Figure 2 The host CPU is 210.

[0102] Operation 1200 includes: at 1210, the processor can receive an update to the Virtual Microcontroller Trust Domain (VMC-TD) bound to the device. Subsequently, at 1220, the processor can save the VMC-TD data to a trusted storage area of ​​at least one of the TDX module or an immutable portion of the VMC-TD. In one implementation, the VMC-TD data includes the device's device authentication session information.

[0103] Subsequently, at box 1230, the processor can update the VMC-TD based on the received update. Finally, at box 1240, the processor can use the VMC-TD data to restore the VMC-TD.

[0104] Under appropriate circumstances, Figure 12 Some of the operations illustrated may be repeated, combined, modified, or deleted, and additional steps may be added to the process in various embodiments. Additionally, the steps may be performed in any suitable order without departing from the scope of a particular embodiment.

[0105] Figure 13 This is an illustrative diagram of an electronic computing device that enables device authentication for confidential computing environments, according to some implementations. In some implementations, the computing device 1300 includes one or more processors 1310, each processor 1310 including one or more processor dies (e.g., cores) 1318, each processor die 1318 including a VMC-TD 1364, such as referenced... Figure 1 and Figure 2 The described VMC-TD 121 and / or VMC-TD230. In some embodiments, such as Figures 1-12 As provided, the computing device uses the VMC-TD component 1364 to provide a virtual microcontroller for device authentication in a confidential computing environment.

[0106] Computing device 1300 may additionally include one or more of the following: cache 1362, graphics processing unit (GPU) 1312 (which may be a hardware accelerator in some implementations), wireless input / output (I / O) interface 1320, wired I / O interface 1330, system memory 1340 (e.g., memory circuitry), power management circuitry 1350, nontransitory storage device 1360, and network interface 1370 for connecting to network 1372. The following discussion provides a concise, general description of the components forming the illustrative computing device 1300. For example, non-limiting computing device 1300 may include desktop computing devices, blade server devices, workstations, or similar devices or systems.

[0107] In this embodiment, processor core 1318 is capable of executing machine-readable instruction set 1314, reading data and / or instruction set 1314 from one or more storage devices 1360, and writing data to one or more storage devices 1360. Those skilled in the art will appreciate that the illustrated embodiments and other embodiments can be implemented using other processor-based device configurations, including portable electronic devices or handheld electronic devices (e.g., smartphones), portable computers, wearable computers, consumer electronics, personal computers ("PCs"), network PCs, minicomputers, server blades, mainframe computers, and so on.

[0108] The processor core 1318 may include any number of hardwired or configurable circuits, some or all of which may include a programmable and / or configurable combination of electronic components, semiconductor devices and / or logic elements that are partially or wholly disposed in a PC, server or other computing system capable of executing processor-readable instructions.

[0109] Computing device 1300 includes a bus or similar communication link 1316 communicatively coupled between various system components and facilitating the exchange of information and / or data between these components, including a processor core 1318, a cache 1362, a graphics processing unit circuitry 1312, one or more wireless I / O interfaces 1320, one or more wired I / O interfaces 1330, one or more storage devices 1360, and / or one or more network interfaces 1370. The term "computing device 1300" may be referenced herein in the singular, but this is not intended to limit embodiments to a single computing device 1300, as in some embodiments, there may be more than one computing device 1300 that incorporates, includes, or contains any number of communicatively coupled, juxtaposed, or remotely networked circuits or devices.

[0110] The processor core 1318 may include any number and type of currently available or future-developed devices or any combination of such devices capable of executing machine-readable instruction sets.

[0111] Processor core 1318 may include (or be coupled to) but is not limited to any current or future-developed single-core or multi-core processor or microprocessor, such as: one or more system-on-a-chip (SoC); central processing unit (CPU); digital signal processor (DSP); graphics processing unit (GPU); application-specific integrated circuit (ASIC); programmable logic unit; field-programmable gate array (FPGA); etc. Unless otherwise stated, Figure 13 The construction and operation of the various boxes shown are of conventional design. Therefore, such boxes are not described in further detail herein, as those skilled in the art should understand them. The bus 1316 that interconnects at least some of the components of the computing device 1300 may employ any currently available or future-developed serial or parallel bus structure or architecture.

[0112] System memory 1340 may include read-only memory (ROM) 1342 and random access memory (RAM) 1346. A portion of ROM 1342 may be used to store or otherwise reserve a basic input / output system (BIOS) 1344. BIOS 1344 provides basic functionality to computing device 1300, for example, by causing processor core 1318 to load and / or execute one or more machine-readable instruction sets 1314. In embodiments, at least some of the one or more machine-readable instruction sets 1314 cause at least a portion of processor core 1318 to provide, create, generate, transform, and / or act as a dedicated, designated, and specific machine, such as a word processor, digital image acquisition device, media player, gaming system, communication device, smartphone, etc. The computing device may also include System Management RAM (SMRAM) 1366, which is used as memory by processor 1310 to store code used in System Management Mode (SMM).

[0113] The computing device 1300 may include at least one wireless input / output (I / O) interface 1320. At least one wireless I / O interface 1320 may be communicatively coupled to one or more physical output devices 1322 (haptic devices, video displays, audio output devices, hard copy output devices, etc.). At least one wireless I / O interface 1320 may also be communicatively coupled to one or more physical input devices 1324 (pointing devices, touchscreens, keyboards, haptic devices, etc.). At least one wireless I / O interface 1320 may include any currently available or future-developed wireless I / O interface. Example wireless I / O interfaces include, but are not limited to: Bluetooth®, near field communication (NFC), etc.

[0114] The computing device 1300 may include one or more wired input / output (I / O) interfaces 1330. At least one wired I / O interface 1330 may be communicatively coupled to one or more physical output devices 1322 (haptic devices, video displays, audio output devices, hard copy output devices, etc.). At least one wired I / O interface 1330 may be communicatively coupled to one or more physical input devices 1324 (pointing devices, touchscreens, keyboards, haptic devices, etc.). The wired I / O interface 1330 may include any currently available or future-developed I / O interface. Example wired I / O interfaces include, but are not limited to, Universal Serial Bus (USB), IEEE 1394 (“FireWire”), etc.

[0115] Computing device 1300 may include one or more communicatively coupled nontransitory data storage devices 1360. Data storage devices 1360 may include one or more hard disk drives (HDDs) and / or one or more solid-state storage devices (SSDs). One or more data storage devices 1360 may include any currently or future-developed storage devices, network storage devices, and / or systems. Non-limiting examples of such data storage devices 1360 may include, but are not limited to, any currently or future-developed nontransitory storage device or device, such as one or more magnetic storage devices, one or more optical storage devices, one or more resistive storage devices, one or more molecular storage devices, one or more quantum storage devices, or various combinations thereof. In some implementations, one or more data storage devices 1360 may include one or more removable storage devices, such as one or more flash drives, flash memories, flash memory cells, or similar devices or devices communicatively coupled to and decoupled from computing device 1300.

[0116] One or more data storage devices 1360 may include an interface or controller (not shown) that communicatively couples a corresponding storage device or system to bus 1316. One or more data storage devices 1360 may store, retain, or otherwise contain one or more application-useful machine-readable instruction sets, data structures, program modules, data stores, databases, logical structures, and / or other data that are executable on or by processor core 1318 and / or graphics processor circuitry 1312 and / or on or by processor core 1318 and / or graphics processor circuitry 1312. In some instances, one or more data storage devices 1360 may be communicatively coupled to the processor core 1318, for example via bus 1316 or via one or more wired communication interfaces 1330 (e.g., Universal Serial Bus (i.e., USB)), one or more wireless communication interfaces 1320 (e.g., Bluetooth®, Near Field Communication (i.e., NFC)), and / or one or more network interfaces 1370 (IEEE 802.3 or Ethernet, IEEE 802.11 or WiFi®, etc.).

[0117] Processor-readable instruction set 1314 and other programs, applications, logic sets and / or modules may be stored wholly or partially in system memory 1340. Such instruction set 1314 may be transferred wholly or partially from one or more data storage devices 1360. Instruction set 1314 may be loaded, stored, or otherwise retained in system memory 1340, wholly or partially, during execution by processor core 1318 and / or graphics processor circuitry 1312.

[0118] The computing device 1300 may include a power management circuitry 1350 that controls one or more operational aspects of an energy storage device 1352. In embodiments, the energy storage device 1352 may include one or more primary batteries (i.e., non-rechargeable batteries) or rechargeable batteries (i.e., rechargeable batteries) or similar energy storage devices. In embodiments, the energy storage device 1352 may include one or more supercapacitors or ultra-supercapacitors. In embodiments, the power management circuitry 1350 may alter, adjust, or control the energy flow from an external power source 1354 to the energy storage device 1352 and / or to the computing device 1300. The power source 1354 may include, but is not limited to, a solar power system, a commercial power grid, a portable generator, an external energy storage device, or any combination thereof.

[0119] For simplicity, the processor core 1318, graphics processor circuitry 1312, wireless I / O interface 1320, wired I / O interface 1330, storage device 1360, and network interface 1370 are illustrated as communicatively coupled to each other via bus 1316, thereby providing connectivity between the components described above. In alternative embodiments, the components described above can be coupled with… Figure 13 The different communication coupling methods illustrated herein. For example, one or more of the components described above may be directly coupled to other components, or may be coupled to each other via one or more intermediate components (not shown). In another example, one or more of the components described above may be integrated into processor core 1318 and / or graphics processor circuitry 1312. In some embodiments, all or part of bus 1316 may be omitted, and components may be directly coupled to each other using suitable wired or wireless connections.

[0120] The following examples relate to further embodiments. Example 1 is a processing system for facilitating virtual microcontroller authentication for devices in a confidential computing environment. The processing system of Example 1 includes one or more processors configured to: implement a service trust domain (TD) as a virtual microcontroller (VMC) trust domain (VMC-TD) for devices, wherein the VMC-TD supports protocols for device authentication, device measurement, and device management within the confidential computing environment; and receive a VMC certificate chain endorsed by a startup service component, the startup service component including at least one trusted module of the confidential computing environment, the VMC certificate chain including a root certificate of the startup service component, a startup service module signing certificate, and a complete VMC certificate, the complete VMC certificate including an initial VMC certificate and a TD report, the TD report including measurements of the device corresponding to the VMC TD.

[0121] In Example 2, the subject matter as described in Example 1 may optionally include, wherein one or more processors are further configured to: generate an alias key pair including a public key and a private key by the VMC-TD; request a VMC certificate chain by the VMC-TD using an initial VMC certificate, the initial VMC certificate including the public key in the alias key pair; and establish a secure communication channel between the Trusted Execution Environment (TEE) Security Manager (TSM) of the confidential computing environment and the VMC-TD by utilizing the VMC certificate chain. In Example 3, the subject matter as described in any one of Examples 1-2 may optionally include, wherein one or more processors are further configured to enable one or more TDs to access one or more virtual functions (VFs) of a device via the VMC-TD, and wherein the device is authenticated using the VMC certificate chain.

[0122] In Example 4, the subject matter as described in any one of Examples 1-3 may optionally include: wherein, in order to authenticate a device, the TSM is used to transmit a challenge to a device host driver executed in a virtual machine monitor (VMM) of one or more master TDs, wherein the device host driver is used to communicate with the device so that the device is able to send a response to the challenge back to the TSM, and wherein the response to the challenge to authenticate the device is generated by the VMC-TD using a private key in an alias key pair.

[0123] In Example 5, the subject matter as described in any one of Examples 1-4 may optionally include, wherein the TSM is used to: parse the complete VMC certificate to obtain a TD report; extract the VMC-TD Measurement Register (TDMR) and Runtime Measurement (RTMR) from the TD report, and extract the device measurement from at least one of the TD report or the VMC certificate; identify the device using the device measurement; and verify the integrity status of the VMC-TD using the TDMR and RTMR.

[0124] In Example 6, the subject matter as described in any one of Examples 1-5 may optionally include, wherein the TSM is configured to: issue a command for obtaining measurements from the VMC-TD; and receive from the VMC-TD a measurement block including the VMC-TD Measurement Register (TDMR), Runtime Measurement (RTMR), and measurements of the device from the VMC-TD, wherein the TDMR, RTMR, and measurements of the device are extracted by the VMC-TD from at least one of a TD report or a VMC certificate.

[0125] In Example 7, the subject matter as described in any one of Examples 1-6 may optionally include: wherein, after the establishment of the secure communication channel, the TSM is used to control one or more VFs via communication with the VMC-TD using a protocol for device management, and wherein the VMC-TD utilizes memory-mapped I / O (MMIO) to communicate with the physical functions of the device and the device manager to implement control of the one or more VFs, or utilizes MMIO to obtain device measurements from hardware registers. In Example 8, the subject matter as described in any one of Examples 1-7 may optionally include: wherein the MMIO is used to accept transactions where the integrity and data encryption (ide) values ​​are set, and wherein the transactions where the ide values ​​are set are generated using TD key identifiers (IDs) supplied by one or more TDs.

[0126] In Example 9, the subject matter as described in any one of Examples 1-8 may optionally include: wherein, in response to the overall updability of the VMC-TD, the VMC-TD is used to save VMC-TD data to a secure storage area of ​​the TD Extension (TDX) module and restore the VMC-TD data to the VMC-TD after a seamless update of the VMC-TD, the TDX module including a security service module for a confidential computing environment that ensures that active execution control for one or more TDs does not allow untrusted entities to intercept TD access to resources allocated by the TD. In Example 10, the subject matter as described in any one of Examples 1-9 may optionally include: wherein, in response to the updability of the variable portion of the VMC-TD, the VMC-TD is used to save VMC-TD data to a secure storage area of ​​the immutable portion of the VMC-TD and restore the VMC-TD data to the VMC-TD after a seamless update of the VMC-TD.

[0127] Example 11 is a method for facilitating virtual microcontroller authentication for devices in a confidential computing environment. The method of Example 11 may include: one or more servers implementing a Service Trust Domain (TD) as a Virtual Microcontroller (VMC) Trust Domain (VMC-TD) for devices, wherein the VMC-TD supports protocols for device authentication, device measurement, and device management within the confidential computing environment; and the VMC-TD receiving a VMC certificate chain endorsed by a startup service component, the startup service component comprising at least one trusted module of the confidential computing environment, the VMC certificate chain comprising a root certificate of the startup service component, a startup service module signing certificate, and a complete VMC certificate, the complete VMC certificate comprising an initial VMC certificate and a TD report, the TD report comprising measurements of the device corresponding to the VMC TD.

[0128] In Example 12, the subject matter as described in Example 11 may optionally include, wherein one or more processors are further configured to: generate an alias key pair including a public key and a private key by the VMC-TD; request a VMC certificate chain by the VMC-TD using an initial VMC certificate, the initial VMC certificate including the public key in the alias key pair; establish a secure communication channel between the Trusted Execution Environment (TEE) Security Manager (TSM) of the confidential computing environment and the VMC-TD by utilizing the VMC certificate chain; and enable one or more TDs to access one or more virtual functions (VFs) of the device via the VMC-TD; wherein the device is authenticated using the VMC certificate chain. In Example 13, the subject matter as described in Examples 11-12 may optionally include, wherein, in order to authenticate the device, the TSM is configured to transmit a challenge to a device host driver executing in a Virtual Machine Monitor (VMM) controlling one or more TDs, wherein the device host driver is configured to communicate with the device such that the device is able to send a response to the challenge back to the TSM, and wherein the response to the challenge for authenticating the device is generated by the VMC-TD using the private key in the alias key pair.

[0129] In Example 14, the subject matter described in Examples 11-13 may optionally include, wherein the TSM is used to: parse the complete VMC certificate to obtain a TD report; extract the VMC-TD Measurement Register (TDMR) and Runtime Measurement (RTMR) from the TD report, and extract the device measurement from at least one of the TD report or the VMC certificate; identify the device using the device measurement; and verify the integrity status of the VMC-TD using the TDMR and RTMR.

[0130] In Example 15, the subject matter as described in Examples 11-14 may optionally include, wherein the TSM is configured to: issue a command for obtaining measurements from the VMC-TD; and receive from the VMC-TD a measurement block including the VMC-TD Measurement Register (TDMR), Runtime Measurement (RTMR), and measurements of the device from the VMC-TD, wherein the TDMR, RTMR, and device measurements are extracted by the VMC-TD from at least one of a TD report or a VMC certificate.

[0131] In Example 16, the subject matter as described in Examples 11-15 may optionally include: wherein, in response to the overall updatable nature of the VMC-TD, the VMC-TD is used to save VMC-TD data to a secure storage area of ​​the TD Extension (TDX) module and restore the VMC-TD data to the VMC-TD after a seamless update of the VMC-TD, the TDX module including a security service module for a confidential computing environment that ensures that active execution control for one or more TDs does not allow untrusted entities to intercept TD access to resources assigned by the TD.

[0132] Example 17 is a non-transitory computer-readable storage medium used to facilitate virtual microcontroller authentication for a confidential computing environment. The non-transitory computer-readable storage medium of Example 17 has executable computer program instructions stored thereon that, when executed by one or more processors, cause the one or more processors to perform operations including: implementing a service trust domain (TD) as a virtual microcontroller (VMC) trust domain (VMC-TD) for a device by the one or more servers, wherein the VMC-TD supports protocols for device authentication, device measurement, and device management within the confidential computing environment; and receiving a VMC certificate chain endorsed by a startup service component, the startup service component comprising a trusted module of the confidential computing environment, the VMC certificate chain comprising at least one of a root certificate of the startup service component, a startup service module signing certificate, and a complete VMC certificate, the complete VMC certificate comprising an initial VMC certificate and a TD report, the TD report comprising measurements of the device corresponding to the VMC TD.

[0133] In Example 18, the subject matter as described in Example 17 may optionally include: generating an alias key pair including a public key and a private key by the VMC-TD; requesting a VMC certificate chain by the VMC-TD using an initial VMC certificate including the public key in the alias key pair; establishing a secure communication channel between the Trusted Execution Environment (TEE) Security Manager (TSM) of the confidential computing environment and the VMC-TD by utilizing the VMC certificate chain; and enabling one or more TDs to access one or more virtual functions (VFs) of a device via the VMC-TD; wherein the device is authenticated using the VMC certificate chain.

[0134] In Example 19, the subject matter described in Examples 17-18 may optionally include: wherein, in order to authenticate a device, the TSM is used to transmit a challenge to a device host driver executed in a virtual machine monitor (VMM) of one or more TDs, wherein the device host driver is used to communicate with the device so that the device is able to send a response to the challenge back to the TSM, and wherein the response to the challenge to authenticate the device is generated by the VMC-TD using a private key in an alias key pair.

[0135] In Example 20, the subject matter described in Examples 17-19 may optionally include, wherein the TSM is used to: parse the complete VMC certificate to obtain a TD report; extract the VMC-TD Measurement Register (TDMR) and Runtime Measurement Register (RTMR) from the TD report, and extract the device measurement from at least one of the TD reports of the VMC certificate; identify the device using the device measurement; and verify the integrity status of the VMC-TD using the TDMR and RTMR.

[0136] Example 21 is a system for facilitating virtual microcontroller authentication for devices in a confidential computing environment. The system of Example 21 may optionally include: a memory for storing data blocks; and a processor communicatively coupled to the memory, the processor being configured to: implement a service trust domain (TD) as a virtual microcontroller (VMC) trust domain (VMC-TD) for devices, wherein the VMC-TD supports protocols for device authentication, device measurement, and device management within the confidential computing environment; and receive a VMC certificate chain endorsed by a startup service component, the startup service component comprising at least one trusted module of the confidential computing environment, the VMC certificate chain comprising a root certificate of the startup service component, a startup service module signing certificate, and a complete VMC certificate, the complete VMC certificate comprising an initial VMC certificate and a TD report, the TD report comprising measurements of the device corresponding to the VMC TD.

[0137] In Example 22, the subject matter as described in Example 21 may optionally include, wherein one or more processors are further configured to: generate an alias key pair including a public key and a private key by the VMC-TD; request a VMC certificate chain by the VMC-TD using an initial VMC certificate, the initial VMC certificate including the public key in the alias key pair; and establish a secure communication channel between the Trusted Execution Environment (TEE) Security Manager (TSM) of the confidential computing environment and the VMC-TD by utilizing the VMC certificate chain. In Example 23, the subject matter as described in any one of Examples 21-22 may optionally include, wherein one or more processors are further configured to enable one or more TDs to access one or more virtual functions (VFs) of a device via the VMC-TD, and wherein the device is authenticated using the VMC certificate chain.

[0138] In Example 24, the subject matter as described in any one of Examples 21-23 may optionally include: wherein, in order to authenticate a device, the TSM is used to transmit a challenge to a device host driver executed in a virtual machine monitor (VMM) of one or more TDs, wherein the device host driver is used to communicate with the device so that the device is able to send a response to the challenge back to the TSM, and wherein the response to the challenge to authenticate the device is generated by the VMC-TD using a private key in an alias key pair.

[0139] In Example 25, the subject matter as described in any one of Examples 21-24 may optionally include, wherein the TSM is used to: parse the complete VMC certificate to obtain a TD report; extract the VMC-TD Measurement Register (TDMR) and Runtime Measurement (RTMR) from the TD report, and extract the device measurement from at least one of the TD report or the VMC certificate; identify the device using the device measurement; and verify the integrity status of the VMC-TD using the TDMR and RTMR.

[0140] In Example 26, the subject matter as described in any one of Examples 21-25 may optionally include, wherein the TSM is configured to: issue a command for obtaining measurements from the VMC-TD; and receive from the VMC-TD a measurement block including the VMC-TD Measurement Register (TDMR), Runtime Measurement (RTMR), and measurements of the device from the VMC-TD, wherein the TDMR, RTMR, and measurements of the device are extracted by the VMC-TD from at least one of a TD report or a VMC certificate.

[0141] In Example 27, the subject matter as described in any one of Examples 21-26 may optionally include: wherein, after the establishment of the secure communication channel, the TSM is used to control one or more VFs via communication with the VMC-TD using a protocol for device management, and wherein the VMC-TD utilizes memory-mapped I / O (MMIO) to communicate with the physical functions of the device and the device manager to implement control of the one or more VFs, or utilizes MMIO to obtain device measurements from hardware registers. In Example 28, the subject matter as described in any one of Examples 21-27 may optionally include: wherein the MMIO is used to accept transactions where the integrity and data encryption (ide) values ​​are set, and wherein the transactions where the ide values ​​are set are generated using TD key identifiers (IDs) supplied by one or more TDs.

[0142] In Example 29, the subject matter as described in any one of Examples 21-28 may optionally include: wherein, in response to the overall updability of the VMC-TD, the VMC-TD is used to save VMC-TD data to a secure storage area of ​​the TD Extension (TDX) module and restore the VMC-TD data to the VMC-TD after a seamless update of the VMC-TD, the TDX module including a security service module for a confidential computing environment that ensures that active execution control for one or more TDs does not allow untrusted entities to intercept TD access to resources allocated by the TD. In Example 30, the subject matter as described in any one of Examples 21-29 may optionally include: wherein, in response to the updability of the variable portion of the VMC-TD, the VMC-TD is used to save VMC-TD data to a secure storage area of ​​the immutable portion of the VMC-TD and restore the VMC-TD data to the VMC-TD after a seamless update of the VMC-TD.

[0143] Example 31 is an apparatus for facilitating device authentication for a virtual microcontroller in a confidential computing environment. The apparatus includes: means for implementing a service trust domain (TD) as a virtual microcontroller (VMC) trust domain (VMC-TD) for the device, wherein the VMC-TD supports protocols for device authentication, device measurement, and device management within the confidential computing environment; and means for using the VMC-TD to receive a VMC certificate chain endorsed by a startup service component, the startup service component comprising a trusted module of the confidential computing environment, the VMC certificate chain comprising at least one of a root certificate of the startup service component, a startup service module signing certificate, and a complete VMC certificate, the complete VMC certificate comprising an initial VMC certificate and a TD report, the TD report comprising measurements of the device corresponding to the VMC TD. In Example 32, the subject matter of Example 31 may optionally include an apparatus further configured to perform the methods of any of Examples 12 to 16.

[0144] Example 33 is at least one machine-readable medium comprising a plurality of instructions that, in response to being executed on a computing device, cause the computing device to perform the method as described in any one of Examples 11-16. Example 34 is an apparatus for facilitating device authentication for a confidential computing environment, the apparatus being configured to perform the method as described in any one of Examples 11-16. Example 35 is an apparatus for facilitating device authentication for a confidential computing environment, the apparatus including means for performing the method as described in any one of Examples 11-16. Details in these examples may be used anywhere in one or more embodiments.

[0145] In the above description, numerous specific details have been set forth for purposes of explanation to provide a full understanding of the described embodiments. However, it will be apparent to those skilled in the art that embodiments may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form. Intermediate structures may exist between the illustrated components. Components described or illustrated herein may have additional inputs or outputs not illustrated or described.

[0146] Various embodiments may include a variety of processes. These processes may be executed by hardware components or may be embodied in a computer program or machine-executable instructions that can be used to cause a general-purpose or special-purpose processor or logic circuit programmed with those instructions to perform these processes. Alternatively, these processes may be executed by a combination of hardware and software.

[0147] Various portions of the embodiments can be provided as a computer program product, which may include a computer-readable medium (e.g., a non-transitory computer-readable storage medium) having stored thereon computer program instructions that can be used to program a computer (or other electronic device) for execution by one or more processors to perform processes according to certain embodiments. The computer-readable medium may include, but is not limited to, a magnetic disk, an optical disk, a read-only memory (ROM), a random access memory (RAM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic card or optical card, a flash memory, or other types of computer-readable media suitable for storing electronic instructions. Additionally, the embodiments may also be downloaded as a computer program product, wherein the program can be transferred from a remote computer to a requesting computer.

[0148] Many methods in this method are described in their basic form, but procedures may be added to or removed from any of the methods, and information may be added to or subtracted from any of the described messages without departing from the basic scope of this embodiment. It will be apparent to those skilled in the art that many further modifications and adaptations can be made. Specific embodiments are not provided to limit the concepts but are intended to illustrate them. The scope of the embodiments is not determined by the specific examples provided above, but only by the claims below.

[0149] If element "A" is coupled to or coupled to element "B", then element A may be directly coupled to element B or indirectly coupled, for example, through element C. When the specification or claims state that component, feature, structure, process, or characteristic A "causes" component, feature, structure, process, or characteristic B, this means that "A" is at least partially caused by "B", but there may also be at least one other component, feature, structure, process, or characteristic that contributes to causing "B". If the specification indicates that a component, feature, structure, process, or characteristic "may", "can", or "may" be included, then the inclusion of that particular component, feature, structure, process, or characteristic is not necessary. If the specification or claims refer to an element "a" or "an", this does not mean that only one described element exists.

[0150] An embodiment is an implementation or example. References to “embodiment,” “one embodiment,” “some embodiments,” or “other embodiments” in the specification mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least some embodiments. The various appearances of “embodiment,” “one embodiment,” or “some embodiments” do not all refer to the same embodiment. It should be understood that in the foregoing description of exemplary embodiments, features are sometimes grouped together in a single embodiment, drawing, or description thereof for the purpose of making this disclosure fluent and aiding in understanding one or more aspects of novelty. However, this method of disclosure should not be construed as reflecting an intention to utilize more features than expressly recited in each claim. Rather, as reflected in the appended claims, novelty exists in fewer features than all the features of a single foregoing disclosed embodiment. Thus, the claims are thereby expressly incorporated into this specification, with each claim itself serving as a separate embodiment.

Claims

1. An apparatus for device authentication in a confidential computing environment, the apparatus comprising: Graphics processing unit (GPU), coupled to memory, the GPU is used for: Establish a trust relationship between the host central processing unit (CPU) and the GUP; A service trust domain (TD) is established using the host CPU, wherein the service TD is used to support a security protocol and a data model SPDM protocol for at least one of GPU authentication, GPU measurement, or GPU management. The association is a certificate chain endorsed by a trusted module, wherein the certificate chain is associated with a certificate including a TD report with the GPU measurement, and wherein the trust relationship between the host CPU and the GPU is used to facilitate secure encrypted communication, such that data between the host CPU and the GPU is transferred based on direct memory access (DMA).

2. The apparatus of claim 1, wherein, The host CPU includes a secure enclave.

3. The apparatus of claim 1, wherein, The confidential computing environment includes a secure encrypted virtualization (SEV).

4. A method for device authentication in a confidential computing environment, the method comprising: Establish a trust relationship between the host central processing unit (CPU) and the graphics processing unit (GPU); A service trust domain (TD) is established using the host CPU, wherein the service TD is used to support a security protocol and a data model SPDM protocol for at least one of GPU authentication, GPU measurement, or GPU management. The GPU is associated with a certificate chain endorsed by a trusted module, wherein the certificate chain is associated with a certificate including a TD report with measurements from the GPU, and wherein the trust relationship between the host CPU and the GPU is used to facilitate secure encrypted communication, such that data between the host CPU and the GPU is transferred based on direct memory access (DMA).

5. The method of claim 4, wherein, The host CPU includes a secure enclave.

6. The method of claim 4, wherein, The confidential computing environment includes a secure encrypted virtualization (SEV).

7. At least one computer-readable medium having instructions stored thereon, the instructions, when executed, causing a computing device to perform operations, the operations including: Establish a trust relationship between the host central processing unit (CPU) and the graphics processing unit (GPU); A service trust domain (TD) is established using the host CPU, wherein the service TD is used to support a security protocol and a data model SPDM protocol for at least one of GPU authentication, GPU measurement, or GPU management. The GPU is associated with a certificate chain endorsed by a trusted module, wherein the certificate chain is associated with a certificate including a TD report with measurements from the GPU, and wherein the trust relationship between the host CPU and the GPU is used to facilitate secure encrypted communication, such that data between the host CPU and the GPU is transferred based on direct memory access (DMA).

8. The computer-readable medium of claim 7, wherein, The host CPU includes a secure enclave.

9. The computer-readable medium of claim 7, wherein, The confidential computing environment includes a secure encrypted virtualization (SEV).

Images