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

Technical Field

[0001] The present disclosure relates generally to confidential computing, and more particularly to a virtual microcontroller for device authentication in a confidential computing environment. Background Art

[0002] Traditionally, devices have added functionality over time, such as adding data transformation acceleration, migrating functionality from the central processing unit (CPU) to the device, etc. This process also increases the complexity of the device in order 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 shared efficiently to enable multi-tenant use such as cloud, virtualization, containers, etc. These multi-tenant requirements are also implemented via specialized engines on the device to implement privilege separation, data paths, and security 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).

[0003] TDX (Trust Domain Extension) is an instruction in the CPU instruction set architecture (ISA) for removing a virtual machine monitor (VMM) from the trusted computing base (TCB) of a cloud computing virtual machine (VM) workload (called a trust domain or TD). In general, the TCB includes a collection of hardware, firmware, and software components implemented on a platform to provide a secure environment that includes a portion of the platform's memory address space used by the TCB.

[0004] The TDX IO model extends the TDX architecture to allow a VMM outside the TCB to manage devices that can be securely dispatched to a TD. TDX IO enables devices to be securely dispatched to a TD so that data on the link is protected from confidentiality, integrity, and replay attacks. TDX IO also implements IO memory management unit (IOMMU) attributes so that devices can directly use direct memory access (DMA) to the TD's private memory if the TD accepts an interface for the device being measured. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The embodiments described herein are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references refer to similar elements.

[0006] Figure 1 Illustrated is a computing device for providing a virtual microcontroller for device authentication in a confidential computing environment according to implementations herein.

[0007] Figure 2 Illustrated is a computing environment for providing a virtual microcontroller for device authentication in a confidential computing environment according to implementations herein.

[0008] Figure 3 A block diagram of a confidential computing environment for virtual microcontroller trust domain (VMC-TD) certificate generation according to implementations herein is illustrated.

[0009] Figure 4 FIG. 1 illustrates generation of a complete VMC certificate chain by a system-on-a-chip (SoC) secure boot service module according to implementations herein.

[0010] Figure 5 A block diagram illustrating a confidential computing environment for device authentication according to implementations herein.

[0011] Figure 6 A block diagram illustrating a confidential computing environment for virtual device measurement and management according to implementations herein.

[0012] Figure 7 is a block diagram illustrating a confidential computing environment that enables seamless updates to the entire VMC-TD according to the implementation described herein.

[0013] Figure 8is a block diagram illustrating a confidential computing environment that implements seamless updates to portions (variable portions) of a VMC-TD according to implementations herein.

[0014] Fig. 9 is a flow chart illustrating the operation of providing a virtual microcontroller for devices in a confidential computing environment according to an implementation of the present disclosure.

[0015] Fig.10 is a flow chart illustrating the operation of a virtual microcontroller providing device authentication in a confidential computing environment according to an implementation of the present disclosure.

[0016] Fig.11 is a flow chart illustrating the operation of a virtual microcontroller providing device management in a confidential computing environment according to an implementation of the present disclosure.

[0017] Fig.12 is a flow diagram illustrating operations for providing seamless updates of virtual microcontrollers for devices in a confidential computing environment, in accordance with implementations of the present disclosure.

[0018] Fig.13 is a schematic diagram of an illustrative electronic computing device that enables a virtual microcontroller for device authentication in a confidential computing environment, according to some implementations. DETAILED DESCRIPTION

[0019]

[0013] Embodiments described herein relate to a virtual microcontroller for device authentication in a confidential computing environment.

[0020] In the embodiments 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).

[0021] TDX includes instructions in the CPU instruction set architecture (ISA) for removing the virtual machine monitor (VMM) from the trusted computing base (TCB) of the cloud computing virtual machine (VM) workload (referred to as a trust domain or TD). In general, the TCB includes a collection of hardware, firmware, and software components implemented on the platform to provide a secure environment, which includes a portion of the platform's memory address space used by the TCB. The TDX-IO model extends the TDX architecture to allow VMM management outside the TCB to be securely assigned to the TD. TDX-IO enables devices to be securely assigned to the TD so that data on the link is protected from confidentiality, integrity, and replay attacks. TDX-IO also implements IOMMU (IO memory management unit) attributes so that the device can directly use direct memory access (DMA) to the private memory of the TD when the TD accepts an interface for the device being measured.

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

[0023] However, to support the SPDM / TDISP protocol, 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 reporting (RTR) for reporting SPDM measurements. The device should also include storage space for the SPDM certificate chain. In addition, the device should include logic for implementing the SPDM protocol and the TDISP protocol (which is typically written in software such as the C programming language, RUST, or ADA). Finally, the device should have a microcontroller for firmware and a corresponding secure firmware update mechanism.

[0024] However, in today's computing environment, integrated devices may be simple devices. For example, integrated devices in a system on chip (SoC) environment may only include a hardware register transfer level (RTL) written in Verilog or VHDL. Thus, it may be cumbersome and difficult for such integrated devices to support complex protocols such as the SPDM protocol or TDISP protocol described above. In addition, in the example SoC environment, there may be multiple simple integrated devices to establish a trust relationship with TD. In this case, providing storage space and complex logic to support the establishment of the trust relationship may be inefficient in terms of processing resources and space.

[0025] Embodiments herein provide a virtual microcontroller for device authentication in a confidential computing environment. A specialized service TD is implemented as a virtual microcontroller (VMC) for an integrated device. Such a specialized service TD is referred to herein as a VMC-TD. The service TD can be software that has minimal impact on existing devices in a computing environment. The service TD allows support to be added on top of existing integrated devices (such as small integrated devices on SoCs). The service TD can be updated without affecting the hardware. In the event that 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 started again. In addition, the service TD has no restrictions on memory size. For example, the service TD can declare memory usage, and then the VMM can allocate sufficient memory for it.

[0026] In the implementation of this article, VMC-TD can be regarded as part of the chain of trust (CoT) of the device. VMC-TD may include a protocol (e.g., SPDM / TDISP protocol) for establishing communication and trust relationship with TD and TSM. In some implementations, VMC-TD may not have a private key. Alternatively, VMC-TD can generate an alias key pair and certificate at runtime and require a known trusted module (such as a secure startup service module (S3M)) as an endorser to sign the certificate.

[0027] Figure 1 A computing device 100 for providing a virtual microcontroller for device authentication in a confidential computing environment according to implementations herein is illustrated. 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 data streaming accelerator (DSA), and the like.

[0028] The computing device 100 may be embodied as any type of device capable of performing the functions described herein. For example, the computing device 100 may be embodied as, but not limited to, a computer, a laptop computer, a tablet computer, a notebook computer, a mobile computing device, a smart phone, a wearable computing device, a multiprocessor system, a server, a workstation, and / or a consumer electronic device. Figure 1 As shown in , 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 of the 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.

[0029] The processor 120 may be embodied as any type of processor capable of performing the functions described herein. For example, the 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 circuits. As shown, the processor 120 illustratively includes secure enclave support 122, which allows the processor 120 to establish a trusted execution environment referred to as a secure enclave, in which the executed code can be measured, verified and / or otherwise determined to be authentic. Additionally, the code and data included in the secure enclave can be encrypted or otherwise protected from access by code executed outside the secure enclave. For example, the code and data included in the secure enclave can be protected by the hardware protection mechanism of the processor 120 when being executed or when stored in some protected cache memory of the processor 120. The code and data included in the secure enclave can be encrypted when stored in a shared cache or main memory 130.

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

[0031] The memory 130 may be embodied as any type of volatile or non-volatile memory or data storage device capable of performing the functions described herein. In operation, the memory 130 may store various data and software used during the operation of the computing device 100, such as operating systems, applications, programs, libraries, and drivers. As shown, the memory 130 may be communicatively coupled to the processor 120 via an I / O subsystem 124, which may be embodied as a circuit system and / or component for facilitating input / output operations with the processor 120, the memory 130, and other components of the computing device 100. For example, the 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, a firmware device, a communication link (i.e., a point-to-point link, a bus link, a line, a cable, a light guide, a printed circuit board trace, etc.) and / or other components and subsystems for facilitating input / output operations. In some embodiments, the memory 130 may be directly coupled to the 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 incorporated on a single integrated circuit chip along with the processor 120, memory 130, accelerator device 136, and / or other components of the computing device 100. Additionally or alternatively, in some embodiments, the processor 120 may include an integrated memory controller and a system agent, which may be embodied as a logic block where data traffic from the processor cores and I / O devices is aggregated before being sent to the memory 130.

[0032] As shown, the I / O subsystem 124 includes a direct memory access (DMA) engine 126 and a memory-mapped I / O (MMIO) engine 128. The processor 120 including a secure enclave established with secure enclave support 122 can communicate with the integrated device 138 using the DMA engine 126 through one or more DMA transactions and / or using the MMIO engine 128 through one or more MMIO transactions. The 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 the processor 120 and the integrated device 138. Although shown as being included in the I / O subsystem 124, it should be understood that in some embodiments, the DMA engine 126 and / or MMIO engine 128 may be included in other components of the computing device 100 (e.g., the processor 120, a memory controller, or a system agent), or may be embodied as separate components in some embodiments.

[0033] The data storage device 132 may 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 drives, solid-state drives, non-volatile flash memory, or other data storage devices. The computing device 100 may also include a communication subsystem 134, which may be embodied as any communication circuit, device, or collection thereof that enables communication between the computing device 100 and other remote devices over a computer network (not shown). The communication subsystem 134 may be configured to communicate using any one or more communication technologies (e.g., wired or wireless communications) and associated protocols (e.g., Ethernet, WiMAX, 3G, 4G LTE, etc.) to achieve such communications.

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

[0035] The integrated device 138 may further include one or more peripheral devices. The 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, the peripheral devices may include a touch screen, a graphics circuit system, a graphics processing unit (GPU) and / or processor graphics, an audio device, a microphone, a camera, a keyboard, a mouse, a network interface, and / or other input / output devices, interface devices, and / or peripheral devices.

[0036] 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 data center processing unit (DPU), which may be configured to perform different actions based on packet type, connection, or other packet characteristics.

[0037] In use, as further described below, the trusted execution environment (TEE) established by the processor 120 communicates data securely with the accelerator 136 and the integrated device 138. The data can be transferred using a memory mapped I / O (MMIO) transaction or a direct memory access (DMA) transaction. For example, the TEE can perform an MMIO write transaction including encrypted data, and the accelerator device 136 and / or the integrated device 138 decrypt the data and perform the write. As another example, the TEE can perform an MMIO read request transaction, and the accelerator device 136 and / or the integrated device 138 can read the requested data, encrypt the data, and perform an MMIO read response transaction including the encrypted data. As another example, the TEE can configure the accelerator device 136 and / or the integrated device 138 to perform a DMA operation, and the accelerator device 136 and / or the integrated device 138 performs a memory transfer, performs a cryptographic operation (ie, encryption or decryption) and forwards the result.

[0038] As further described below, the processor may provide a VMC-TD 121 for device authentication in a confidential computing environment provided in the computing device 100. The VMC-TD 121 may be implemented as a service TD. The VMC-TD 121 provides a way to minimize the actions of the firmware during the handover to the OS while allowing a secure runtime interface from the firmware to the OS to initialize the device securely and / or easily. Implementations of the present disclosure provide technical advantages of reducing the firmware trusted computing base (TCB) and allowing improved boot time (e.g., faster boot). In addition, implementations provide for minimizing the space occupied in front of the OS and implementing 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 the VMC-TD 121 are provided below with reference to Figure 2-Figure 13 To provide.

[0039] While the implementation in this article is discussed in terms of the TDX-IO architecture, the implementation is not limited to such architectures and is applicable to other confidential computing protocols and architectures (e.g., etc.) can also utilize the implementation method in this article.

[0040] Now turn to Figure 2 , depicts an example confidential computing environment for providing a virtual microcontroller for device authentication according to implementations herein.

[0041] Figure 2 FIG. 2 is a diagram illustrating a computing environment 200 for providing a virtual microcontroller for device authentication in a confidential computing environment according to implementations herein. In one implementation, the computing environment 200 may be used with reference to Figure 1 The computing device 100 described herein is the same. 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, the 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 that is isolated from VMM 250 (or hypervisor) and other non-TD software in the computing environment 200.

[0042] To help implement the security policy for TD 220, the host CPU 210 can operate the TDX module 240 controlled by the host CPU 210 in the reserved memory space of the host CPU 210 in a mode called secure-arbitration mode (SEAM), which provides a security service model. In one embodiment, the reserved memory space can be identified by a SEAM range register. The host CPU 210 can allow software executed in the SEAM memory range to access the SEAM memory range. All other software accesses from the device to the memory range are suspended. The SEAM memory range also uses a temporary memory encryption key to provide cryptographic confidentiality protection. Memory integrity can also be implemented through a cryptographic integrity protection scheme or a logical integrity protection scheme.

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

[0044] 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 referred to as TDX-IO. TDX-IO enables the assignment of a virtual function (VF) of an integrated device 260, such as VF-1 262A or VF-2 262B (collectively referred to as VF 262), to a specific TD 220. VF 262 may be a virtualized portion of a physical function 264 provided by an integrated device 260. VF 262 may be a lightweight function that shares one or more physical resources with a physical function 264 and with a VF 262 associated with the physical function 264. Unlike a physical function 264, a VF 262 may configure its own behavior.

[0045] More specifically, the implementation 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 host a 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 communicate with the TEE security manager (TSM) using the SPDM / TDISP protocol, thereby cooperating 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 computing between the TD 220 and the integrated device 260, the implementation herein considers the following aspects: device identity, device authentication, device measurement, virtual device management, and seamless update. Device identity

[0046] The VMC-TD 230 does not include any persistent storage and cannot hold any private keys used for device identification. Alternatively, in the implementation herein, the VMC-TD 230 may generate an alias private / public key pair at runtime, and then require a secure boot component 270 (such as a startup service module (S3M) or a 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 a device secret 274, such as a secure boot component 270 certificate signing key.

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

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

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

[0050] The TDX module 320 may receive a generate credentials call 301 (e.g., TDCALL) from the VCM-TD 310. The TDX module 320 may then request (i.e., 302) device measurements from the hardware registers of the SoC device 340. The SoC device 340 may return (i.e., 303) the device measurements to the TDX module 320 in response to the request.

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

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

[0053] The TDX module 320 may insert the TD_REPORT 322 together with the initial VMC certificate 314 to generate a complete VMC certificate 324 having a TEE report object identifier (OID). The TDX module 320 then requests (ie, 306) the SoC S3M 360 or a separate QE to sign the complete VMC certificate 324.

[0054] The SoC S3M 360 receives the request 306 to sign the full VMC certificate 324 from the TDX module 320 and signs the full VMC certificate 324 with 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). Figure 4Further details of this process are discussed. 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 generate certificate 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 communicating with the SoC device 340. In addition to the SoC S3M, a quoting enclave (QE) can also be used to perform the signing as an endorsement.

[0055] Figure 4 The diagram shows a method according to the implementation in this article. Figure 3 The SoC S3M 360 performs the generation of the complete VMC certificate chain. In one implementation, Figure 3 The SoC 330 is shown to include a SoC CPU core 350 and a SoC S3M 360. As described above with reference to Figure 3 As discussed, steps 304 and 305 involve the TDX module 320 requesting a SEAMREPORT from the CPU core 350, the CPU core 350 generating a SEAMREPORT, and the CPU core 350 returning (i.e., 305) the SEAMREPORT to the 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.

[0056] For example, the SoC S3M 360 may 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) such that the SoC S3M 360 is allowed to read the MSR. Once the SoC S3M 360 obtains the SEAMREPORT MAC key 420, the key 420 may be stored in a secure key storage 430 area of ​​the SoC S3M 360. The secure key storage 430 may store the key 420 with confidentiality protection along with other S3M keys, such as a device private key or a root MAC key. Device Authentication

[0057] Figure 5A block diagram illustrating a confidential computing environment 500 for device authentication according to implementations herein. In one implementation, the confidential computing environment 500 may be Figure 1 The computing device 100 and / or Figure 2 The confidential computing environment 500 may include a VMM 510 that hosts an 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 the VMC-TD 550 are connected to each other. Figure 2 The VMM250 is the same as the VMC-TD 550. Figure 2 The VMC-TD 230 is identical to the TSM 540 and Figure 2 The TSM 225 is the same.

[0058] As part of establishing a trusted relationship for communicating between a TD and a device in a confidential computing environment 500, the confidential computing environment 500 provides device authentication of the device. In one example, the device authentication process can utilize the SPDM protocol to authenticate the device. However, the implementations herein may also utilize other device authentication protocols, and the device authentication protocol is not limited to the SPDM protocol 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.

[0059] TSM 540 issues a SPDM GET_CERTIFICATE command for obtaining the device VMC-TD certificate chain. In one implementation, the device VMC-TD certificate chain is the same as in Figure 3 5. If the TSM 540 seeks to authenticate the device, it may generate a nonce and send the SPDM command - CHALLENGE(nonce) to the device's VMC-TD 550. The device's VMC-TD 510 then signs the transcribed message with its key and returns CHALLENGE_AUTH to the TSM 540. The TSM 540 may then verify the signature using the leaf certificate.

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

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

[0062] The device host driver 530 may return (ie, 505) the SPDM response to the SPDM agent 520 of the VMM 510. Finally, the SPDM agent 520 may return (ie, 506) the SPDM response to the TSM 540 for device authentication purposes. Equipment Measurement

[0063] Reference Figure 5 In the implementation herein, the TSM 540 may also seek to obtain device measurements of the device. As described in detail below, the TSM 540 may also utilize the SPDM protocol to perform the device measurement process. There may be various techniques for obtaining device measurements, two of which are discussed below.

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

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

[0066] 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 the device in a confidential computing environment (e.g., TDX architecture, etc.). For example, in a confidential computing environment, the virtual function 1 (VF-1) of the device can be assigned to a first TD (TD-1), the virtual function 2 (VF-2) of the device can be assigned to a second TD (TD-2), and so on.

[0067] Figure 6 A block diagram illustrating a confidential computing environment 600 for virtual device measurement and management according to implementations herein. In one implementation, the confidential computing environment 600 may be Figure 1 The computing device 100 and / or Figure 2 The confidential computing environment 600 may include a host CPU 610 and a device 640. The host CPU 610 may host one or more TDs, including TD-1 620A and TD-2 620B (collectively referred to herein as TD 620), and VMC-TD 630. The device 640 may include one or more virtual functions (VFs) and physical functions and a manager 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 function and manager 660.

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

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

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

[0071] In some implementations, the MMIO page address may accept transactions with integrity and data encryption (ide) value ide_t=1. When an MMIO request is made using a TDX key ID, a transaction with ide t=1 may be generated. Since only TD 620 can make access using the TDX key ID, this allows VMC-TD 630 to access the MMIO page. TDX module 680 may then map the MMIO page of device 640 to VMC-TD 630. Seamless updates

[0072] The VMC-TD of the implementation in this article should also support seamless update use cases. Seamless update refers to the disposal of the system during the runtime of the firmware without removing the services provided by the firmware. The motivation for such firmware updates can be, for example, bug fixes, security fixes, or performance enhancements.

[0073] For VMC-TD and seamless updates, SPDM should remain running even if the device's VMC-TD is to be updated. To support seamless updates in the implementations herein, VMC-TD should save SPDM session information (e.g., AEAD keys, AEADIV, session sequence number) as VMC-TD data (VMC-TD information).

[0074] The implementations herein provide at least two VMC-TD seamless update options. However, the implementations herein may also utilize other seamless update options, and these seamless update options are not limited to those described herein.

[0075] A first option for seamless update of the VMC-TD includes update of the entire (eg, monolithic) VMC-TD. Figure 7 7 is a block diagram illustrating a confidential computing environment 700 that implements seamless updates for the entire VMC-TD according to implementations herein. The confidential computing environment 700 includes three phases of a seamless update process for the entire VMC-TD: pre-update 710, during update 720, and post-update 730.

[0076] As part of the seamless update process for the entire VMC-TD, the VMM tears down the old (previous) VMC-TD 740 and starts up a new VMC-TD 770. Thus, the entire VMC-TD is updateable. In the pre-update 710 stage, 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 the VMC-TD data 755 to the new VMC-TD 770 after the update (i.e., 730).

[0077] In some implementations, since the VMC-TD 740 is a dedicated service TD, it can be bound to the TDX module 760. For example, the TDX module 760 can start those VMC-TDs that are "known" to be good (verified and authenticated, trusted). In order to support this in the VMC-TD 740 seamless update process, the updates to both the TDX module and the VMC-TD can be performed together. When the TDX module updates itself, it can ensure that the Secure Version Number (SVN) will not be downgraded. The TDX module can also ensure that the SVN of the new VMC-TD 770 will not be downgraded.

[0078] A second option for seamless update of the VMC-TD includes update of parts of the VMC-TD, such as the variable part. Figure 8800 is a block diagram illustrating a confidential computing environment 800 that implements seamless updates to a portion (variable portion) of a VMC-TD according to implementations herein. The confidential computing environment 800 includes three stages of a seamless update process for a portion of the entire VMC-TD: before update 810, during update 820, and after update 830.

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

[0080] Before the update (i.e., 810), the previous version 840 of the variable portion of the VMC-TD should save the VMC-TD data 855 to the VMC-TD storage area 850. During the update (i.e., 820), the previous version 840 of the variable portion of the VMC-TD is disassembled 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 update payload via a digital signature and ensure that the SVN is not downgraded. Subsequently, after the update (i.e., 830), the new version 870 of the variable portion of the VMC-TD is restored using the VMC-TD data 855.

[0081] Fig. 9 is a flow diagram illustrating operation 900 of providing a virtual microcontroller for a device in a confidential computing environment in accordance with an implementation of the present disclosure. Operation 900 (or other processes or variations and / or combinations thereof described herein) is performed 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 on a computer-readable storage medium, for example, 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) in operation 900 are performed by a processor (processing device, processor device, processor hardware circuitry, processing hardware circuitry, etc.), such as a processor. Figure 2 The host CPU 210.

[0082] Operation 900 includes: At block 910, the processor may implement a service TD as a VMC-TD for a 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 by the VMC-TD.

[0083] Then, at block 930, the processor may generate, by the VMC-TD, an initial VMC certificate including a public key in the alias key pair. At block 940, the processor may request, by the VMC-TD, a VMC certificate chain using the initial VMC certificate.

[0084] Subsequently, at box 950, the processor may receive, by the VMC-TD, a VMC certificate chain endorsed by a boot service component, which is a trusted module of a confidential computing environment. In one implementation, the VMC certificate chain includes a root certificate of the boot service component, a boot 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 a device corresponding to the VMC-TD. Finally, at box 960, the processor may 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.

[0085] Where appropriate, Fig. 9 Some of the illustrated operations may be repeated, combined, modified or deleted, and additional steps may also be added to the processes in various embodiments. Additionally, the steps may be performed in any suitable order without departing from the scope of the particular embodiments.

[0086] Fig.10 is a flow diagram illustrating operation 1000 of providing a virtual microcontroller for device authentication in a confidential computing environment in accordance with an implementation of the present disclosure. Operation 1000 (or other processes or variations and / or combinations thereof described herein) is performed 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 on a computer-readable storage medium, for example, 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) in operation 1000 are performed by a processor (processing device, processor device, processor hardware circuitry, processing hardware circuitry, etc.), such as a processor. Figure 2 The host CPU 210.

[0087] Operation 1000 includes: At block 1010, the processor may identify a 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 may send an authentication command to the VMC-TD bound to the device.

[0088] At block 1030, the processor may intercept the authentication command by the VMM that hosts one or more TDs and the VMC-TD and forward the authentication command to the host driver of the device. Subsequently, at block 1040, the processor may inject the authentication command into the VMC-TD identified as bound to the device by the host driver of the device.

[0089] Subsequently, at block 1050, the processor may return a response by the VMM 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 may then sign the response with a private key, and the TSM may verify the signature using the VMC-TD's complete VMC certificate chain. Finally, at block 1060, the processor may verify the signature of the response by the TSM using the VMC-TD's complete VMC certificate chain.

[0090] Where appropriate, Fig.10 Some of the illustrated operations may be repeated, combined, modified or deleted, and additional steps may also be added to the processes in various embodiments. Additionally, the steps may be performed in any suitable order without departing from the scope of the particular embodiments.

[0091] Fig.11 is a flow diagram illustrating operation 1100 of providing a virtual microcontroller for device management in a confidential computing environment in accordance with an implementation of the present disclosure. Operation 1100 (or other processes or variations and / or combinations thereof described herein) is performed 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 on a computer-readable storage medium, for example, 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) in operation 1100 are performed by a processor (processing device, processor device, processor hardware circuitry, processing hardware circuitry, etc.), such as a processor. Figure 2 The host CPU 210.

[0092] Operation 1100 includes: At block 1110, the processor may 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 of the device. Subsequently, at block 1120, the processor may map the MMIO page address of the device to the VMC-TD. In one implementation, the MMIO page accepts transactions with integrity and data encryption (ide_t) parameters set.

[0093] Subsequently, at block 1130, the processor may receive a request from the TD to communicate with a virtual function (VF) of the device via an MMIO page address using the TDX key ID. At block 1140, the processor may generate a transaction to access an MMIO page of the MMIO page address. In one implementation, an ide_t parameter of the transaction is set in response to the TDX key ID being part of the request. Finally, at block 1150, the processor may access the VF via the MMIO page using the generated transaction.

[0094] Where appropriate, Fig.11 Some of the illustrated operations may be repeated, combined, modified or deleted, and additional steps may also be added to the processes in various embodiments. Additionally, the steps may be performed in any suitable order without departing from the scope of the particular embodiments.

[0095] Fig.12 is a flow diagram illustrating operation 1200 of providing seamless updates of virtual microcontrollers for devices in a confidential computing environment in accordance with an implementation of the present disclosure. Operation 1200 (or other processes or variations and / or combinations thereof described herein) is performed 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 on a computer-readable storage medium, for example, 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) in operation 1200 are performed by a processor (processing device, processor device, processor hardware circuitry, processing hardware circuitry, etc.), such as a processor. Figure 2 The host CPU 210.

[0096] Operation 1200 includes where the processor may receive an update to a virtual microcontroller trust domain (VMC-TD) bound to a device at 1210. Subsequently, the processor may save the VMC-TD data to a trusted storage area of ​​at least one of a TDX module or an immutable portion of the VMC-TD at block 1220. In one implementation, the VMC-TD data includes device authentication session information of the device.

[0097] Then, at block 1230, the processor may update the VMC-TD according to the received update. Finally, at block 1240, the processor may restore the VMC-TD using the VMC-TD data.

[0098] Where appropriate, Fig.12 Some of the illustrated operations may be repeated, combined, modified or deleted, and additional steps may also be added to the processes in various embodiments. Additionally, the steps may be performed in any suitable order without departing from the scope of the particular embodiments.

[0099] Fig.13 is a schematic diagram of an illustrative electronic computing device that enables a virtual microcontroller for device authentication in a confidential computing environment, according to some implementations. In some implementations, computing device 1300 includes one or more processors 1310 that include one or more processor dies (e.g., cores) 1318, each processor die 1318 including a VMC-TD 1364, such as described with reference to FIG. Figure 1 and Figure 2 In some embodiments, the VMC-TD 121 and / or VMC-TD 230 described herein may be used to control the VMC-TD 121 and / or VMC-TD 230. Figure 1-Figure 12 As provided in, the computing device is used to use the VMC-TD component 1364 to provide a virtual microcontroller for device authentication in a confidential computing environment.

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

[0101] In an embodiment, the processor core 1318 is capable of executing a machine-readable instruction set 1314, reading data and / or the instruction set 1314 from one or more storage devices 1360, and writing data to one or more storage devices 1360. Those skilled in the relevant art will appreciate that the illustrated embodiments, as well as other embodiments, may be implemented using other processor-based device configurations, including portable or handheld electronic devices (e.g., smart phones), portable computers, wearable computers, consumer electronics, personal computers (“PCs”), network PCs, minicomputers, server blades, mainframe computers, and the like.

[0102] 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 completely disposed in a PC, server or other computing system capable of executing processor-readable instructions.

[0103] Computing device 1300 includes a bus or similar communications link 1316 that communicatively couples and facilitates the exchange of information and / or data between various system components, including processor core 1318, cache 1362, graphics processor 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. 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 comprises any number of communicatively coupled, collocated, or remotely networked circuits or devices.

[0104] Processor core 1318 may include any number, type, or combination of currently available or future developed devices capable of executing a set of machine-readable instructions.

[0105] 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 (system on a chip, SOC); central processing unit (central processing unit, CPU); digital signal processor (digital signal processor, DSP); graphics processing unit (graphics processing unit, GPU); application-specific integrated circuit (application-specific integrated circuit, ASIC); programmable logic unit; field programmable gate array (field programmable gate array, FPGA); etc. Unless otherwise specified, Fig.13 The construction and operation of the various blocks shown in are of conventional design. Therefore, such blocks are not described in further detail herein, as they should be understood by those skilled in the relevant art. The bus 1316 interconnecting 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.

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

[0107] 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 (tactile device, video display, audio output device, hard copy output device, etc.). At least one wireless I / O interface 1320 may be communicatively coupled to one or more physical input devices 1324 (pointing device, touch screen, keyboard, tactile device, 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: Near field communication (NFC) and so on.

[0108] 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 (tactile device, video display, audio output device, hard copy output device, etc.). At least one wired I / O interface 1330 may be communicatively coupled to one or more physical input devices 1324 (pointing device, touch screen, keyboard, tactile device, etc.). 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"), and the like.

[0109] The computing device 1300 may include one or more communicatively coupled non-transitory data storage devices 1360. The data storage device 1360 may include one or more hard disk drives (HDD) and / or one or more solid-state storage devices (SSD). The one or more data storage devices 1360 may include any current or future developed storage device, network storage device, and / or system. Non-limiting examples of such data storage devices 1360 may include, but are not limited to, any current or future developed non-transitory 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, the 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 storage units, or similar devices or devices that can be communicatively coupled to and decoupled from the computing device 1300.

[0110] The 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 the bus 1316. The one or more data storage devices 1360 may store, retain, or otherwise contain machine-readable instruction sets, data structures, program modules, data stores, databases, logic structures, and / or other data useful to the processor core 1318 and / or graphics processor circuitry 1312 and / or one or more applications executed on or by the processor core 1318 and / or graphics processor circuitry 1312. In some examples, the one or more data storage devices 1360 may be stored, for example, via the bus 1316 or via one or more wired communication interfaces 1330 (e.g., a universal serial bus (i.e., USB)), one or more wireless communication interfaces 1320 (e.g., a USB), or a plurality of wireless communication interfaces 1320 (e.g., a USB). Near Field Communication (i.e., NFC)), and / or one or more network interfaces 1370 (IEEE 802.3 or Ethernet, IEEE802.11 or etc.) and are communicatively coupled to processor core 1318.

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

[0112] The computing device 1300 may include a power management circuit system 1350 that controls one or more operational aspects of an energy storage device 1352. In an embodiment, the energy storage device 1352 may include one or more primary batteries (i.e., non-rechargeable batteries) or secondary batteries (i.e., rechargeable batteries) or similar energy storage devices. In an embodiment, the energy storage device 1352 may include one or more supercapacitors or ultra-supercapacitors. In an embodiment, the power management circuit system 1350 may change, adjust, or control the flow of energy 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.

[0113] For convenience, processor core 1318, graphics processor circuit system 1312, wireless I / O interface 1320, wired I / O interface 1330, storage device 1360, and network interface 1370 are illustrated as being communicatively coupled to each other via bus 1316, thereby providing connectivity between the components described above. In alternative embodiments, the components described above may be coupled to a bus 1316. Fig.13 1316. 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 the components may be directly coupled to each other using suitable wired or wireless connections.

[0114] The following examples relate to further embodiments. Example 1 is a processing system for facilitating a virtual microcontroller for device authentication in a confidential computing environment. The processing system of Example 1 includes one or more processors, which are used 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, by the VMC-TD, a VMC certificate chain endorsed by a boot service component, the boot service component including at least one trusted module of the confidential computing environment, the VMC certificate chain including a root certificate of the boot service component, a boot service module signing certificate, and a full VMC certificate, the full VMC certificate including an initial VMC certificate and a TD report, the TD report including measurements of the device corresponding to the VMC TD.

[0115] In Example 2, the subject matter as described in Example 1 may optionally include, wherein the one or more processors are also used 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 a trusted execution environment (TEE) security manager (TSM) of a 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 the one or more processors are also used 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.

[0116] In Example 4, the subject matter as described in any 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) that hosts one or more TDs, wherein the device host driver is used to communicate with the device so that the device can 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 a private key in an alias key pair.

[0117] In Example 5, the subject matter as described in any 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), runtime measurements (RTMR) from the TD report, and extract the device's measurements from at least one of the TD report or the VMC certificate; identify the device using the device's measurements; and verify the integrity status of the VMC-TD using the TDMR and RTMR.

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

[0119] In Example 7, the subject matter of 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 a memory mapped I / O (MMIO) to communicate with a physical function of the device and a device manager to achieve control of the one or more VFs, or utilizes the MMIO to obtain device measurements from hardware registers. In Example 8, the subject matter of any one of Examples 1-7 may optionally include: wherein the MMIO is used to accept transactions with integrity and data encryption (ide) values ​​set, and wherein the transactions with the ide values ​​set are generated using a TD key identifier (ID) provisioned by one or more TDs.

[0120] In Example 9, the subject matter of any one of Examples 1-8 may optionally include: wherein, in response to the entirety of the VMC-TD being updateable, the VMC-TD is used to save the VMC-TD data to a secure storage area of ​​a 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 of a confidential computing environment, the security service module ensuring that execution control active for one or more TDs does not allow untrusted entities to intercept TD access to resources assigned by the TD. In Example 10, the subject matter of any one of Examples 1-9 may optionally include: wherein, in response to the variable portion of the VMC-TD being updateable, the VMC-TD is used to save the VMC-TD data to a secure storage area of ​​an immutable portion of the VMC-TD, and restore the VMC-TD data to the VMC-TD after a seamless update of the VMC-TD.

[0121] Example 11 is a method for facilitating a virtual microcontroller for device authentication in a confidential computing environment. The method of Example 11 may include: implementing a service trust domain (TD) by one or more servers 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 receiving, by the VMC-TD, a VMC certificate chain endorsed by a boot service component, the boot service component including at least one trusted module of the confidential computing environment, the VMC certificate chain including a root certificate of the boot service component, a boot service module signing certificate, and a full VMC certificate, the full VMC certificate including an initial VMC certificate and a TD report, the TD report including measurements of the device corresponding to the VMC TD.

[0122] In Example 12, the subject matter as described in Example 11 may optionally include, wherein the one or more processors are further used 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 a trusted execution environment (TEE) security manager (TSM) of a confidential computing environment and the VMC-TD by using the VMC certificate chain; and enable 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. 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 used to transmit a challenge to a device host driver executed in a virtual machine monitor (VMM) that hosts one or more TDs, wherein the device host driver is used to communicate with the device so that the device can 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 the private key in the alias key pair.

[0123] In Example 14, the subject matter as 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), runtime measurements (RTMR) from the TD report, and extract the device's measurements from at least one of the TD report or the VMC certificate; identify the device using the device's measurements; and verify the integrity status of the VMC-TD using the TDMR and RTMR.

[0124] In Example 15, the subject matter as described in Examples 11-14 may optionally include, wherein the TSM is used to: issue a command for obtaining measurements from the VMC-TD; and receive a measurement block including a VMC-TD measurement register (TDMR), a runtime measurement (RTMR), and measurements of a device from the VMC-TD from the VMC-TD, wherein the TDMR, the RTMR, and the 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 16, the subject matter as described in Examples 11-15 may optionally include: wherein, in response to the entirety of the VMC-TD being updateable, the VMC-TD is used to save the VMC-TD data to a secure storage area of ​​a 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, the security service module ensuring that execution controls active for one or more TDs do not allow untrusted entities to intercept TD access to resources assigned to the TD.

[0126] Example 17 is a non-transitory computer-readable storage medium for facilitating a virtual microcontroller for device authentication in a confidential computing environment. The non-transitory computer-readable storage medium of Example 17 has executable computer program instructions stored thereon, which, when executed by one or more processors, cause the one or more processors to perform operations including: implementing a service trust domain (TD) by the one or more servers 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 a confidential computing environment; and receiving, by the VMC-TD, a VMC certificate chain endorsed by a boot service component, the boot service component including a trusted module of the confidential computing environment, the VMC certificate chain including at least one of a root certificate of the boot service component, a boot service module signing certificate, and a full VMC certificate, the full VMC certificate including an initial VMC certificate and a TD report, the TD report including measurements of the device corresponding to the VMC TD.

[0127] In Example 18, the subject matter described in Example 17 may optionally include: generating, by the VMC-TD, an alias key pair including a public key and a private key; requesting, by the VMC-TD, a VMC certificate chain using an initial VMC certificate including the public key in the alias key pair; establishing a secure communication channel between a trusted execution environment (TEE) security manager (TSM) of a 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.

[0128] In Example 19, the subject matter as described in Examples 17-18 may optionally include: wherein, to authenticate the device, the TSM is used to transmit a challenge to a device host driver executed in a virtual machine monitor (VMM) that hosts one or more TDs, wherein the device host driver is used to communicate with the device so that the device can 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 a private key in an alias key pair.

[0129] In Example 20, the subject matter as 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), runtime measurement (RTMR) from the TD report, and extract the device's measurement from at least one of the TD reports of the VMC certificate; use the device's measurement to identify the device; and use the TDMR and RTMR to verify the integrity status of the VMC-TD.

[0130] Example 21 is a system for facilitating a virtual microcontroller for device authentication in a confidential computing environment. The system of Example 21 may optionally include: a memory for storing a data block; and a processor communicatively coupled to the memory, the processor for: implementing a service trust domain (TD) as a virtual microcontroller (VMC) trust domain (VMC-TD) for a device, wherein the VMC-TD supports protocols for device authentication, device measurement, and device management within the confidential computing environment; and receiving, by the VMC-TD, a VMC certificate chain endorsed by a boot service component, the boot service component including at least one trusted module of the confidential computing environment, the VMC certificate chain including a root certificate of the boot service component, a boot service module signing certificate, and a full VMC certificate, the full VMC certificate including an initial VMC certificate and a TD report, the TD report including measurements of the device corresponding to the VMC TD.

[0131] In Example 22, the subject matter as described in Example 21 may optionally include, wherein the one or more processors are also used 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 a trusted execution environment (TEE) security manager (TSM) of a 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 the one or more processors are also used 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.

[0132] In Example 24, the subject matter as described in any 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) that hosts one or more TDs, wherein the device host driver is used to communicate with the device so that the device can 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 a private key in an alias key pair.

[0133] In Example 25, the subject matter as described in any 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), runtime measurements (RTMR) from the TD report, and extract the device's measurements from at least one of the TD report or the VMC certificate; identify the device using the device's measurements; and verify the integrity status of the VMC-TD using the TDMR and RTMR.

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

[0135] In Example 27, the subject matter of any one of Examples 21-26 may optionally include: wherein, after 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 a memory mapped I / O (MMIO) to communicate with a physical function of the device and a device manager to achieve control of the one or more VFs, or utilizes MMIO to obtain device measurements from hardware registers. In Example 28, the subject matter of any one of Examples 21-27 may optionally include: wherein MMIO is used to accept transactions with integrity and data encryption (ide) values ​​set, and wherein the transactions with ide values ​​set are generated using a TD key identifier (ID) provisioned with one or more TDs.

[0136] In Example 29, the subject matter of any one of Examples 21-28 may optionally include: wherein, in response to the entirety of the VMC-TD being updateable, the VMC-TD is used to save the VMC-TD data to a secure storage area of ​​a 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 of a confidential computing environment, the security service module ensuring that execution control active for one or more TDs does not allow untrusted entities to intercept TD access to resources assigned by the TD. In Example 30, the subject matter of any one of Examples 21-29 may optionally include: wherein, in response to the variable portion of the VMC-TD being updateable, the VMC-TD is used to save the VMC-TD data to a secure storage area of ​​an immutable portion of the VMC-TD, and restore the VMC-TD data to the VMC-TD after a seamless update of the VMC-TD.

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

[0138] Example 33 is at least one machine-readable medium, the 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 a method as described in any of Examples 11-16. Example 34 is an apparatus for facilitating a virtual microcontroller for device authentication in a confidential computing environment, the apparatus being configured to perform a method as described in any of Examples 11-16. Example 35 is an apparatus for facilitating a virtual microcontroller for device authentication in a confidential computing environment, the apparatus comprising an apparatus for performing a method as described in any of Examples 11-16. The details in the examples may be used anywhere in one or more embodiments.

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

[0140] Various embodiments may include various processes. These processes may be performed by hardware components, or may be embodied in computer programs or machine executable instructions, which may be used to cause a general or special purpose processor or logic circuit programmed with the instructions to perform these processes. Alternatively, these processes may be performed by a combination of hardware and software.

[0141] Portions of the various embodiments may be provided as a computer program product, which may include a computer-readable medium (e.g., a non-transitory computer-readable storage medium) having computer program instructions stored thereon, which may be used to program a computer (or other electronic device) for execution by one or more processors to perform processes according to certain embodiments. Computer-readable media may include, but are not limited to, a 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 or optical card, a flash memory, or other types of computer-readable media suitable for storing electronic instructions. In addition, the embodiments may also be downloaded as a computer program product, wherein the program may be transmitted from a remote computer to a requesting computer.

[0142] Many of the methods are described in their basic form, but processes may be added to or deleted 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 the present embodiment. It will be apparent to those skilled in the art that many further modifications and adaptations may be made. The specific embodiments are not provided to limit the concepts but to illustrate the concepts. The scope of the embodiments is not to be determined by the specific examples provided above, but only by the claims below.

[0143] If element "A" is said to be coupled to or coupled to element "B", 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 the cause of "B", but there may also be at least one other component, feature, structure, process or characteristic that assists in causing "B". If the specification indicates that a component, feature, structure, process or characteristic "may", "could" or "might" be included, it is not necessary that the particular component, feature, structure, process or characteristic be included. If the specification or claims mention "a or an" element, this does not mean that there is only one described element.

[0144] An embodiment is an implementation or example. References to "an embodiment," "an embodiment," "some embodiments," or "other embodiments" in the specification mean that a particular feature, structure, or characteristic described in conjunction with the embodiment is included in at least some embodiments. The various appearances of "an embodiment," "an embodiment," or "some embodiments" do not all refer to the same embodiment. It should be appreciated that in the foregoing description of the example embodiments, for the purpose of making the disclosure fluent and assisting in understanding one or more aspects of the various novel aspects, the various features are sometimes grouped together in a single embodiment, a drawing, or a description thereof. However, this method of disclosure should not be interpreted as reflecting the intention that the claimed embodiments utilize more features than those explicitly stated in each claim. On the contrary, as reflected in the appended claims, the novel aspects exist in fewer features than all the features of a single aforementioned disclosed embodiment. Thus, the claims are expressly incorporated into the specification, with each claim itself as a separate embodiment.

Claims

1. A processing system comprising: One or more processors configured to: 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 a confidential computing environment; as well as The VMC-TD receives a VMC certificate chain endorsed by a boot service component, wherein the boot service component includes a trusted module of the confidential computing environment, the VMC certificate chain includes a root certificate of the boot service component, a boot service module signing certificate, and at least one of a complete VMC certificate, wherein the complete VMC certificate includes an initial VMC certificate and a TD report, wherein the TD report includes measurements of the device corresponding to the VMC TD.

2. The processing system of claim 1, wherein: The one or more processors are further configured to: The VMC-TD generates an alias key pair including a public key and a private key; The VMC-TD requests the VMC certificate chain using an initial VMC certificate, wherein the initial VMC certificate includes the public key in the alias key pair; as well as A secure communication channel is established between a trusted execution environment (TEE) security manager (TSM) of the confidential computing environment and the VMC-TD by utilizing the VMC certificate chain.

3. The processing system of claim 2, wherein: The one or more processors are further configured to enable one or more TDs to access one or more virtual functions (VFs) of the device via the VMC-TD, and wherein the device is authenticated using the VMC certificate chain.

4. The processing system of claim 3, wherein: To authenticate the device, the TSM is used to transmit a challenge to a device host driver executed in a virtual machine monitor (VMM) that hosts the one or more TDs, wherein the device host driver is used to communicate with the device so that the device can 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 the private key in the alias key pair.

5. The processing system of claim 3, wherein: The TSM is used to: Parsing the complete VMC certificate to obtain the TD report; extracting a VMC-TD measurement register (TDMR), a runtime measurement (RTMR) from the TD report, and extracting measurements of the device from at least one of the TD report or the VMC certificate; identifying the device using the measurements of the device; as well as The integrity status of the VMC-TD is verified using the TDMR and the RTMR.

6. The processing system of claim 3, wherein: The TSM is used to: issuing a command for obtaining measurements from the VMC-TD; and A measurement block including a VMC-TD measurement register (TDMR), a runtime measurement (RTMR), and a measurement of the device from the VMC-TD is received from the VMC-TD, wherein the TDMR, the RTMR, and the measurement of the device are extracted by the VMC-TD from at least one of the TD report or the VMC certificate.

7. The processing system of claim 3, wherein: After establishment of the secure communication channel, the TSM is used to control the 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 a physical function of the device and a device manager to achieve control of the one or more VFs, or utilizes MMIO to obtain the device measurements from hardware registers.

8. The processing system of claim 7, wherein: The MMIO is used to accept transactions with integrity and data encryption (ide) values ​​set, and wherein the transactions with the ide value set are generated using TD key identifiers (IDs) provisioned by the one or more TDs.

9. The processing system of claim 1, wherein: In response to the entirety of the VMC-TD being updateable, the VMC-TD is used to save VMC-TD data to a secure storage area of ​​a 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 of the confidential computing environment, the security service module ensuring that execution controls active for the one or more TDs do not allow untrusted entities to intercept TD access to resources assigned by the TD.

10. The processing system of claim 1, wherein: In response to the variable portion of the VMC-TD being updateable, the VMC-TD is operable to save VMC-TD data to a secure storage area of ​​an immutable portion of the VMC-TD and restore the VMC-TD data to the VMC-TD after a seamless update of the VMC-TD.

11. A method comprising: Implementing a service trust domain (TD) by one or more servers 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 a confidential computing environment; as well as The VMC-TD receives a VMC certificate chain endorsed by a boot service component, wherein the boot service component includes at least one trusted module of the confidential computing environment, the VMC certificate chain includes a root certificate of the boot service component, a boot service module signing certificate, and a complete VMC certificate, wherein the complete VMC certificate includes an initial VMC certificate and a TD report, wherein the TD report includes measurements of the device corresponding to the VMC TD.

12. The method of claim 11, wherein: The one or more processors are further configured to: The VMC-TD generates an alias key pair including a public key and a private key; The VMC-TD requests the VMC certificate chain using an initial VMC certificate, wherein the initial VMC certificate includes the public key in the alias key pair; Establishing a secure communication channel between a trusted execution environment (TEE) security manager (TSM) of the confidential computing environment and the VMC-TD by utilizing the VMC certificate chain; as well as enabling 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.

13. The method of claim 12, wherein: To authenticate the device, the TSM is used to transmit a challenge to a device host driver executed in a virtual machine monitor (VMM) that hosts the one or more TDs, wherein the device host driver is used to communicate with the device so that the device can 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 the private key in the alias key pair.

14. The method of claim 12, wherein: The TSM is used to: Parsing the complete VMC certificate to obtain the TD report; extracting a VMC-TD measurement register (TDMR), a runtime measurement (RTMR) from the TD report, and extracting measurements of the device from at least one of the TD report or the VMC certificate; identifying the device using the measurements of the device; as well as The integrity status of the VMC-TD is verified using the TDMR and the RTMR.

15. The method of claim 12, wherein: The TSM is used to: issuing a command for obtaining measurements from the VMC-TD; and A measurement block including a VMC-TD measurement register (TDMR), a runtime measurement (RTMR), and a measurement of the device from the VMC-TD is received from the VMC-TD, wherein the TDMR, the RTMR, and the measurement of the device are extracted by the VMC-TD from at least one of the TD report or the VMC certificate.

16. The method of claim 11, wherein: In response to the entirety of the VMC-TD being updateable, the VMC-TD is used to save VMC-TD data to a secure storage area of ​​a 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 of the confidential computing environment, the security service module ensuring that execution controls active for the one or more TDs do not allow untrusted entities to intercept TD access to resources assigned by the TD.

17. A non-transitory computer readable storage medium having executable computer program instructions stored thereon, the executable computer program instructions, when executed by one or more processors, causing the one or more processors to perform operations comprising: implementing, by the one or more servers, 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 a confidential computing environment; and The VMC-TD receives a VMC certificate chain endorsed by a boot service component, wherein the boot service component includes a trusted module of the confidential computing environment, the VMC certificate chain includes a root certificate of the boot service component, a boot service module signing certificate, and at least one of a complete VMC certificate, wherein the complete VMC certificate includes an initial VMC certificate and a TD report, wherein the TD report includes measurements of the device corresponding to the VMC TD.

18. The non-transitory computer readable storage medium of claim 17, wherein: The one operation also includes: The VMC-TD generates an alias key pair including a public key and a private key; The VMC-TD requests the VMC certificate chain using an initial VMC certificate, wherein the initial VMC certificate includes the public key in the alias key pair; establishing a secure communication channel between a 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 the device via the VMC-TD; Wherein, the device is authenticated using the VMC certificate chain.

19. The non-transitory computer readable storage medium of claim 18, wherein:To authenticate the device, the TSM is used to transmit a challenge to a device host driver executed in a virtual machine monitor (VMM) that hosts the one or more TDs, wherein the device host driver is used to communicate with the device so that the device can 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 the private key in the alias key pair.

20. The non-transitory computer readable storage medium of claim 18, wherein: The TSM is used to: Parsing the complete VMC certificate to obtain the TD report; extracting from the TD report a VMC-TD measurement register (TDMR), a runtime measurement (RTMR), and extracting measurements of the device from at least one of the TD report of the VMC certificate; identifying the device using the measurements of the device; as well as The integrity status of the VMC-TD is verified using the TDMR and the RTMR.

Images