Enclave startup and authentication

Abstract

The present invention relates to enclave startup and authentication. A method includes: starting a pre-boot startup enclave (LE) by a pre-boot environment; creating a startup token for a pre-boot quote enclave (QE) by the pre-boot LE; authenticating the startup token by the pre-boot LE; in response to the authentication, starting the pre-boot QE with the startup token by the pre-boot environment; generating a public provision key, a private provision key, and a certification key by the pre-boot QE; verifying the authenticity of a device by the pre-boot QE using the public key; protecting a communication channel with the device by the pre-boot QE using the public provision key, the private provision key, and the public key; encrypting the public provision key, the private provision key, and the certification key by the pre-boot QE using a system-specific wrapping key; and storing the encrypted public provision key, the encrypted private provision key, and the encrypted certification key in the device by the pre-boot QE.

Description

Technical Field

[0001] The present disclosure generally relates to enclave startup and authentication. Background Art

[0002] Methods for verifying the authenticity of an enclave rely on the enclave being remotely provided. Such methods can use an internet connection. However, for security reasons, some systems may not be able to connect to the internet. Summary of the invention

[0003] According to an aspect of the present disclosure, a method for authenticating an enclave is provided, comprising: starting a pre-boot boot enclave LE by a pre-boot environment, wherein the pre-boot environment is an operating environment that can be accessed before loading an operating system; creating a boot token for pre-booting a reference enclave QE by the pre-boot LE; authenticating the boot token by the pre-boot LE; starting the pre-boot QE with the boot token in response to the authentication by the pre-boot environment; generating a public provision key, a private provision key, and a certification key by the pre-boot QE; verifying the authenticity of a device by the pre-boot QE using the public key, wherein the device is used to protect communication with the enclave and store encrypted keys; protecting a communication channel with the device by the pre-boot QE using the public provision key, the private provision key, and the public key; encrypting the public provision key, the private provision key, and the certification key by the pre-boot QE using a system-specific encapsulation key; and storing the encrypted public provision key, the encrypted private provision key, and the encrypted certification key in the device by the pre-boot QE.

[0004] According to another aspect of the present disclosure, there is provided a system for authenticating an enclave, comprising: a baseboard management controller BMC; a pre-boot environment, wherein the pre-boot environment is an operating environment accessible before loading an operating system, and wherein the pre-boot environment is used to: start a pre-boot boot enclave LE to create and authenticate a boot token; obtain a wrapping key associated with the system; start a pre-boot quote enclave QE with the boot token authenticated by the pre-boot boot enclave, the pre-boot QE is used to: generate a private provisioning key and a public provisioning key; generate a public attestation key and a private attestation key; verify the authenticity of the BMC with an embedded digital certificate; load secure communication to the BMC with the public provisioning key, the private provisioning key and the public key; encrypt the private provisioning key and the private attestation key with the wrapping key; and store the public provisioning key, the encrypted private provisioning key, the public attestation key and the encrypted private attestation key in the BMC.

[0005] According to another aspect of the present disclosure, a non-transitory machine-readable storage medium encoded with processor-executable instructions is provided, the non-transitory machine-readable storage medium including instructions for the following operations: starting a boot enclave LE to create and authenticate a boot token; starting an application enclave AE; obtaining a system-specific encapsulation key, wherein the system is used to authenticate the enclave; starting a reference enclave QE using the authenticated boot token, wherein in response to starting the QE in an offline environment, the QE is used to: generate a public provisioning key, a private provisioning key, a public attestation key, and a private attestation key; establish a secure encrypted communication channel to a baseboard management controller BMC through key exchange; verify the authenticity of the BMC; encrypt the private provisioning key and the private attestation key with the system-specific encapsulation key; and store the encrypted private provisioning key and the encrypted private attestation key in the BMC. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] In the following description, non-limiting examples of the present disclosure are described, which are to be read with reference to the attached figures and do not limit the scope of the claims. In the figures, identical and similar structures, elements or components appearing in more than one figure are generally labeled with the same or similar numbers as in the figures in which they appear. The dimensions of the components and features illustrated in the figures are selected primarily for convenience and clarity of presentation and are not necessarily to scale. With reference to the attached figures:

[0007] Figure 1 is a block diagram of a system including a baseboard management controller, a pre-boot environment, a pre-boot startup enclave, and a pre-boot reference enclave;

[0008] Figure 2 a flow chart of a method for launching a pre-boot boot enclave, launching a pre-boot reference enclave, and storing an encrypted key within a device;

[0009] Figure 3 A flowchart of a method for launching an enclave for a post-boot, referencing the enclave for a post-boot, and decrypting a stored encrypted key from a device; and

[0010] Figure 4 A block diagram of a computing device capable of launching a launch enclave, launching an application enclave, obtaining a system-specific wrapping key, and launching a reference enclave. DETAILED DESCRIPTION

[0011] In the following detailed description, reference is made to the accompanying drawings which form a part hereof, and in which is depicted by way of illustration specific examples in which the disclosure may be implemented. It is to be understood that other examples may be used and structural or logical changes may be made without departing from the scope of the disclosure.

[0012] The method of verifying the authenticity of the enclave relies on a remotely provided enclave. The remotely provided enclave may be available from a third party. In such an example, the method may connect the system including the enclave to the remotely provided enclave using an Internet connection. However, for security reasons, some systems may not be able to connect to the Internet. For example, an "air-gapped" system cannot connect to the Internet, cannot connect to any system connected to the Internet, cannot connect directly to the Internet, and / or may use a firewall.

[0013] As used herein, an "enclave" may be at least a private area in memory that is protected from other processes or programs running or operating in the memory. In other words, an enclave may provide a space with confidentiality and integrity. Specific system software (i.e., machine-readable instructions) may provide or launch an enclave. Other processes, software, programs, operating systems (OS), hypervisors, or machine-readable instructions cannot access or change the machine-readable instructions running in the enclave, regardless of the privilege level. In another example, an enclave is a container or a protected container. Machine-readable instructions, such as Intel Software Guard Extensions (SGX) included in Intel architecture, may be used to create a private or protected area in memory (e.g., an enclave).

[0014] As used herein, a "launch enclave" may be at least a special enclave that provides services to other enclaves. A launch enclave (LE) may create and authenticate a launch token. A LE may access a launch token key that other enclaves may not access. A LE may create and authenticate a launch token using a launch token key. Although other enclaves may be launched with a launch token, an environment may not be able to launch a LE with a launch token (in other words, a LE may be launched without a launch token). A LE may also be referred to as a provisioning enclave or an infrastructure enclave.

[0015] As used herein, a "reference enclave" may be at least an enclave that performs attestation of other enclaves. A reference enclave (QE) may receive attestation requests or reports from other enclaves, such as an application enclave (AE). The QE may verify that the request or report is from an authentic source and an authentic enclave. The QE may then convert the request or report into an attestation report or reference and return the attestation report or reference to the requesting enclave. The QE may also generate keys for the reports described above, and initiate or load secure communication channels with other devices.

[0016] The examples described herein may include a system with a pre-boot environment and a post-boot environment. At the time of manufacture or later by a customer, the pre-boot environment may launch a pre-boot LE. The pre-boot launch enclave may create a launch token. The pre-boot LE may authenticate the launch token. The pre-boot LE may sign the launch token using a launch token key. The processor of the system may then verify that the launch token has been authenticated using the correct key. The pre-boot environment may use the authenticated launch token to launch or provide a pre-boot QE. The pre-boot QE may generate cryptographic keys such as a public provision key, a private provision key, a public attestation key, and / or a private attestation key. The functions described above may ensure that system security may be maintained while allowing the system to attest to an AE launched on the system. The post-boot QE may collect attestation keys from a device where the pre-boot QE may store keys. The pre-boot QE may encrypt the keys before storing them on the device. The attestation key may be used by the post-boot QE to create a reference for the AE. In other words, an AE executing on the system may receive an attestation request. The AE may request a reference from the post-boot QE. Using the attestation key, the post-boot QE may create a reference for the AE or attest to the authenticity of the AE.

[0017] Accordingly, various examples provided herein use a pre-boot environment to launch a pre-boot launch enclave (LE). The pre-boot LE can create a launch token for a pre-boot quote enclave (QE). The pre-boot LE can authenticate the launch token. The pre-boot environment with the authenticated launch token can launch the pre-boot QE. The pre-boot QE can generate a public provision key, a private provision key, and a certification key. The pre-boot QE can verify the authenticity of the device with the public key. The pre-boot QE can protect the communication channel with the device with the public provision key, the private provision key, and the public key. The pre-boot QE can encrypt the public provision key, the private provision key, and the certification key using a system-specific encapsulation key. The pre-boot QE can store the encrypted public provision key, the encrypted private provision key, and the encrypted certification key in the device.

[0018] like Figure 1As shown, system 100 includes baseboard management controller (BMC) 102, pre-boot environment 104, pre-boot LE 106, pre-boot QE 108 and processor 110. Pre-boot environment 104 can start pre-boot LE 106 and pre-boot QE 108. As the name implies, pre-boot LE 106 and pre-boot QE 108 can operate in pre-boot environment 104. Pre-boot LE 106 can create and authenticate a launch token. The launch token can be used to start or provide other enclaves, such as pre-boot QE 108. Pre-boot QE 108 can generate cryptographic keys, such as public provisioning keys, private provisioning keys, and certification keys. Pre-boot QE can use public provisioning keys and private provisioning keys to protect communication channels with other devices such as BMC 102. If other QEs access another QE, they can also use cryptographic keys. For example, a QE started in a post-boot environment can use cryptographic keys to protect a communication channel with a device such as BMC 102. One way to provide keys to other QEs in the post-boot environment is to store the keys in an accessible location. In one example, the pre-boot QE 108 can encrypt the public provision key, the private provision key, and the attestation key using a system-specific wrapping key. The pre-boot QE 108 can then store the encrypted public provision key, the encrypted private provision key, and the encrypted attestation key in a device, such as the BMC 102, either in response to the encryption or upon a prompt from a user.

[0019] As used herein, a "computing device" may be a storage array, a storage device, a storage package, a server, a desktop or laptop computer, a computer cluster, a node, a partition, a virtual machine, or any other device or apparatus including a controller, a processing resource, etc. In the examples described herein, a "processing resource" may include, for example, a processor or multiple processors contained in a single computing device or distributed across multiple computing devices. As used herein, a "processor" may be at least a central processing unit (CPU), a semiconductor-based microprocessor, a graphics processing unit (GPU), a field programmable gate array (FPGA) that retrieves and executes instructions, other electronic circuits suitable for retrieving and executing instructions stored on a machine-readable storage medium, or a combination thereof.

[0020] As used herein, a "machine-readable storage medium" may be an electronic, magnetic, optical, or other physical storage device that contains or stores information such as executable instructions, data, etc. For example, any machine-readable storage medium described herein may be any one or a combination of random access memory (RAM), volatile memory, non-volatile memory, flash memory, a storage drive (e.g., a hard drive), a solid-state drive, any type of storage disk (e.g., a compact disk, a DVD, etc.), etc. Any machine-readable storage medium described herein may be non-transitory.

[0021] As used herein, a "device" may be any microcontroller, BMC, circuit, CPU, microprocessor, GPU, FPGA, chassis manager, rack-level manager, server, Trusted Platform Module (TPM), other circuitry suitable for securing communications with an enclave and storing encrypted keys, or a combination thereof. For example, the device may be a BMC of a server. In another example, the device may be a TPM. In such examples, the device may store data such as encrypted keys from an enclave. In other examples, the device may assist in booting or loading a secure communication channel with an enclave.

[0022] As used herein, a "baseboard management controller" may be a dedicated service processor that uses sensors to monitor the physical state of a server or other hardware and communicates with a management system through an independent "out-of-band" connection. The BMC may also communicate with applications executed at the OS level through an input / output controller (IOCTL) interface driver, a representational state transfer (REST) ​​application program interface (API), or a specific other system software agent that facilitates communication between the BMC and the application. The BMC may access hardware devices located in the server chassis at the hardware level. The BMC may be able to directly change hardware devices. The BMC may operate independently of the OS of the system in which the BMC is located. The BMC may be located on the motherboard or main circuit board of the monitored server or other device. The fact that the BMC is installed on the motherboard of the managed server or otherwise connected to or attached to the managed server does not prevent the BMC from being considered "discrete". As used herein, the BMC has the management capabilities of the subsystems of the computing device and is separate from the processing resources of the OS that executes the computing device. The BMC is separate from a processor such as a central processing unit and executes a high-level OS or hypervisor on the system.

[0023] As used herein, a "pre-boot environment" is a machine-readable instruction that can be stored in a machine-readable storage medium and executed by a processing resource. A pre-boot environment can be an operating environment that is accessible before an operating system is loaded. A pre-boot environment can provide limited functionality. A pre-boot environment can include a user interface. A pre-boot environment can allow a user to boot and provide an enclave. A pre-boot environment can include a unified extensible firmware interface (UEFI), a basic input / output system (BIOS) interface, or other platform firmware environment.

[0024] As used herein, an "operating system" is a machine-readable instruction that can be stored in a machine-readable storage medium and executed by a processing resource. The OS may include system software that manages computer hardware and software resources and supplies common services to computer programs. The OS may assist in the communication between computing device hardware and applications. The OS may include a user interface that allows a user to interact with a computing device. The OS may include layers, such as an application layer and a core layer. High-level applications (e.g., applications that a user can interact with) may be executed in the application layer of the OS, while the core layer may include machine-readable instructions that control the computing device hardware. The OS may be installed during the setup or initialization of the computing device. The OS may be loaded into a machine-readable storage medium during the boot or startup process of the computing device. As described above, the processor or processing resource of the computing device may execute the OS from the machine-readable storage medium. The OS may be another term for a "post-boot environment". For example, after the OS is loaded into a machine-readable storage medium, the computing device may be in a post-boot environment state. In other words, once the user is able to interact with the OS, the computing device may be considered to be in a post-boot environment.

[0025] As used herein, a "cryptographic hash function" may be a function that includes machine-readable instructions. A cryptographic hash function may include machine-readable instructions that, when executed by a processor, may receive an input. The cryptographic hash function may then generate a hexadecimal string that matches the input. For example, the input may include a data string (e.g., a data structure in a memory indicated by a starting memory address and an ending memory address). In such examples, based on the data string, the cryptographic hash function outputs a string such as a hexadecimal string (e.g., a series of multiple hexadecimal values). Further, any slight change in the input may change the output string. In another example, the cryptographic hash function may be a secure hash function (SHA), any hash function approved by the Federal Information Processing Standard (FIPS), any hash function approved by the National Institute of Standards and Technology (NIST), or any other cryptographic hash function.

[0026] As used herein, a "Trusted Platform Module" or "TPM" may be an integrated circuit built into the motherboard of a computing device. A TPM may be tamper-resistant or tamper-proof. A TPM may be used for services on a computing device. Services may include device identification, authentication, encryption, measurement, determining device integrity, secure generation of cryptographic keys, remote attestation, and encapsulated storage. A TPM may include platform configuration registers (PCRs). PCRs may store security-related metrics.

[0027] As used herein, a "privilege level" may be a level at which a machine-readable instruction operates. A privilege level may be a permission level that a user of a computing device or a machine-readable instruction may have. Privilege level implementations may vary between different OSs. Different OSs may have several permission levels. For example, one user or a group of machine-readable instructions may have a full administrator privilege level (e.g., a level of full access to a computing device), while others may have limited privilege levels.

[0028] As used herein, a "system-specific wrapping key" may be a key that is unique to the system. An enclave may include a data structure that defines the enclave. The data structure may include system-specific information. This information may allow an enclave associated with the system to obtain the wrapping key. In other words, an enclave with system-unique data may access the wrapping key. For example, in response to a request for the wrapping key from the enclave, a processor or certain other hardware of the system may authenticate the enclave. Further, in response to authentication by the enclave, the processor or other hardware may send the system-specific wrapping key to an agreed-upon memory location.

[0029] Figure 2 Flowchart of a method for launching a pre-boot boot enclave, launching a pre-boot reference enclave, and storing an encrypted key within a device. Figure 1 The execution of method 200 is described with reference to system 100, but other suitable systems or modules may be used, including but not limited to computing device 400. In addition, implementation of method 200 is not limited to such examples.

[0030] At block 202, the preboot environment 104 may launch the preboot LE 106. In another example, system software operating within the preboot environment 104 may launch the preboot LE 106. In another example, the system software and / or the preboot environment 104 may be a BIOS interface, UEFI, or other platform firmware environment. In another example, the preboot environment 104 may launch the preboot LE 106 in response to a user prompt. For example, the preboot environment 104 may include a user interface with various options. One of the options may include an option to launch a preboot enclave such as the preboot LE 106. In such an example, the user may select the option to launch the preboot LE 106.

[0031] In another example, the processor 110 of the system 100 may verify the authenticity or trustworthiness of the started pre-boot LE 106. As described above, the enclave may include a data structure. For example, the pre-boot LE 106 may include a data structure. One field of the data structure may include a private key from a private / public key pair. The processor 110 of the system 100 may include a hash value of a public key of the private / public key pair. In such an example, the processor 110 may verify the signature of the private key from the private / public key pair using the hash of the public key of the private / public key pair. If the signature is verified, the pre-boot LE 106 may be considered trusted or authentic (in other words, verified).

[0032] At block 204, preboot LE 106 may create a launch token for preboot QE 108. In one example, the launch token may be a data structure. In a further example, the data structure may contain information to launch an enclave. In one example, the launch token may contain a key cryptographic checksum (e.g., a cipher-based message authentication code (CMAC)) from preboot LE 106 that is specific to system 100. In other words, the launch token may include information that is specific to system 100. Further, the information may allow system 100 to launch an enclave without requiring a remote server.

[0033] In box 206, pre-boot LE106 can authenticate the boot token. In other words, pre-boot LE106 can sign the boot token with the boot token key. In another example, a control register or memory location of system 100 can contain the boot token key. In one example, the memory location can be a memory location determined and agreed upon by processor 110 and / or pre-boot LE106. In a further example, pre-boot LE106 can sign the boot token with a CMAC with the boot token key. In another example, the boot token can include a prompt or information to set the attribute in pre-boot QE108 that can allow pre-boot QE108 to access the system-specific encapsulation key. In another example, when the boot token is generated, pre-boot LE106 can authenticate it. In another example, pre-boot environment 104 can authenticate the boot token automatically or with user input. In another example, pre-boot environment 104 can verify the boot token generated and authenticated by pre-boot LE106. In response to verification of the boot token by pre-boot environment 104, pre-boot environment 104 may sign or authenticate the boot token with a CMAC.

[0034] At block 208, the pre-boot environment 104 may, in response to authentication of the launch token, launch the pre-boot QE 108. In one example, when the launch token is authenticated, the pre-boot environment 104 may automatically launch the pre-boot QE 108 with the launch token. In another example, after authenticating the launch token, user input may prompt the pre-boot environment 104 to launch the pre-boot QE 108.

[0035] At block 210 , the pre-boot QE 108 may generate a public provisioning key, a private provisioning key, and a certification key. In another example, the pre-boot QE 108 may generate a public certification key and a private certification key. Further, the certification key may be used to remotely certify an AE launched on the system 100 .

[0036] As described above, the pre-boot QE 108 can generate keys. The keys may include a public supply key and a private supply key. The public supply key may be considered the identity of the QE. In other words, the public supply key may be shared information from the QE to the device (e.g., BMC 102). In such examples, the QE can use the public supply key, the private supply key, and the public key of the device to initiate or load secure communications with a device that has been verified to be authentic. The private supply key may be private or secret information that the QE uses to calculate a shared secret or shared key. For example, the QE may use the public supply key and the private supply key to initiate a key exchange with a device (e.g., BMC 102).

[0037] The pre-boot QE 108 may also generate a certification key. In another example, the pre-boot QE 108 may generate a private certification key and a public provisioning key. The QE may sign a certification reference or report using the private certification key. Other applications or devices may use the public certification key to verify that the signature in the certification report or reference is authentic. In such examples, the pre-boot QE 108 may store the public certification key in the device, or in a specific other location that is readily available. When the QE signs the certification reference or report and sends the reference or report to a third party, the third party may check the signature with the public certification key to ensure that the reference or report is authentic.

[0038] At block 212, pre-boot QE 108 may verify the authenticity of the device (e.g., BMC 102) using the device's public key that is hard-coded into the pre-boot QE. In another example, pre-boot QE 108 may verify the authenticity of the device (e.g., BMC 102) using a digital certificate provided by the device.

[0039] At block 214, the pre-boot QE 108 may secure a communication channel with a device (e.g., BMC 102) using a public provisioning key and a private provisioning key. In such an example, the pre-boot QE 108 may initiate a key exchange (e.g., a Diffie-Hellman key exchange) with the device (e.g., BMC 102) to start or load a secure communication channel.

[0040] In an example of a key exchange, a QE (e.g., pre-boot QE 108 or post-boot QE) may share a public provision key with the device, and the device may share a public key with the QE. For example, x and y. The QE may perform a calculation using the private provision key and send the result to the device. The device may do the same thing, except using specific values ​​known to the device. For example, the QE may calculate and send A=xa mod y, and the device may calculate and send B=xb mod y. The QE may then perform a calculation using the device's result and the private provision key, which may be equal to the calculation performed by the device using the result from the QE and the key known to the device. The left side of the equation below may be the calculation performed by the QE, and the right side may be the calculation performed by the device:

[0041] Bamody=Abmody

[0042] The result can be considered as a shared key used to encrypt / decrypt communications between the QE and the device.

[0043] At block 216, the preboot QE 108 may encrypt the public provisioning key, the private provisioning key, and the attestation key with the system-specific wrapping key. In another example, the preboot QE 108 may also encrypt the private attestation key and the public attestation key. In one example, the system-specific wrapping key may be associated with any enclave provided on the system 100. In another example, the preboot LE 106 may request the system-specific wrapping key from the system 100 or the processor 110 of the system 100. In response to the request for the system-specific wrapping key, the processor 110 of the system may send the system-specific wrapping key to the address specified by the preboot LE 106. In a further example, the preboot QE 108 may collect the system-specific wrapping key from the specified address. In another example, the processor 110 of the system 100 may verify that the enclave requesting the system-specific wrapping key is a LE. In the event that the requested enclave is not a LE, then the processor 110 cannot send the system-specific wrapping key to the specified address. In another example, the pre-boot QE 108 may be signed with a private key of a private / public key pair, similar to the pre-boot LE 106. Further, the pre-boot QE 106 may request a system-specific wrapping key from the system 100. In such an example, and as described above, the system 100 or the processor 110 of the system 100 may include a hash value of a public key of the private / public key pair. In such an example, the processor 110 may verify the signature from the private key of the private / public key pair using the hash of the public key of the private / public key pair. In the event that the signature is verified, the pre-boot QE 108 may be considered trusted or authentic (in other words, verified) and may access the system-specific wrapping key.

[0044] At block 218, the pre-boot QE 108 may store the encrypted public provision key, the encrypted private provision key, and the encrypted attestation key within the device (e.g., BMC 102). In response to the establishment of the secure communication channel, the pre-boot QE 108 may continue to store the encrypted public provision key, the encrypted private provision key, and the encrypted attestation key described above within the device (e.g., BMC 102). In another example, the pre-boot QE 108 may also store the encrypted public attestation key and the encrypted private attestation key within the device (e.g., BMC 102).

[0045] In one example, the device may be BMC 102. In another example, the device may be a Trusted Platform Module (TPM). In another example, the device may be a specific combination of the components described above, specific other components, or a microcontroller.

[0046] Figure 3Flowchart of a method for launching an enclave for post-boot, launching a post-boot reference enclave, and decrypting a stored, encrypted key from a device. Although execution of method 300 is not described below with reference to a specific system, a suitable system or method may be used. A system such as system 100 or computing device 400 may be used to perform method 300. Although system 100 described above describes a system having a pre-boot environment 104, after loading the system 100 OS, system 100 may be considered to be in a post-boot environment (e.g., including a post-boot environment).

[0047] At block 302, the post-boot environment may launch a post-boot LE. As described, the post-boot environment may include an OS. In another example, the post-boot environment may include machine-readable instructions to launch an enclave. In a further example, the machine-readable instructions may include instructions to launch a post-boot enclave. In one example, a user may prompt the post-boot environment to launch the post-boot LE. In another example, in response to system 100 entering a post-boot environment state, the post-boot environment may automatically launch the post-boot LE.

[0048] At block 304, the post-boot LE may create a second boot token for the post-boot QE (in other words, different from the first boot token). In one example, the second boot token may be a data structure. In a further example, the data structure may contain information for booting the enclave. In one example, the boot token may contain information specific to system 100. Further, this information may allow system 100 to verify the authenticity of the LE without requiring a remote server.

[0049] In block 306, the post-boot LE may verify the second boot token for the post-boot QE. Similar to the process described above for the pre-boot LE 106, the post-boot LE 106 may include machine-readable instructions for authenticating the second boot token using a control register or memory location in the system. In another example, the control register or memory location of the system 100 may contain a boot token key. In one example, the memory location may be a memory location determined and agreed upon by the processor 110 and the post-boot LE. In a further example, the post-boot LE may sign the boot token using a CMAC with the boot token key. In another example, the boot token may include a prompt or information for setting an attribute in the post-boot QE that may allow the post-boot QE to access a system-specific encapsulation key. In another example, when the boot token is generated, the post-boot LE may automatically authenticate it. In another example, the post-boot environment may be automatic or utilize user input, and the user input may prompt the post-boot environment to authenticate the boot token. In another example, the post-boot environment may verify the boot token generated and authenticated by the post-boot LE. In response to verification of the boot token by the post-boot environment, the post-boot environment may authenticate or sign the boot token using the CMAC.

[0050] In another example, the processor 110 of the system 100 may verify the authenticity or trustworthiness of the launched post-boot LE. As described, the enclave may include a data structure. For example, the post-boot LE may include a data structure. One field of the data structure may include a signature of a private key from a private / public key pair. The processor 110 of the system 100 may include a hash value of a public key of the private / public key pair. In such an example, the processor 110 may verify the signature of the private key from the private / public key pair using the hash value of the public key of the private / public key pair. For example, the processor 110 may compare the hash value of the public key of the private / public key pair that may be stored within the processor with the hash value of the public key of the private / public key pair stored in the data structure of the post-boot LE. The processor 110 may then verify the signature of the post-boot LE using the public key of the private / public key pair. In the case of verifying the signature, the post-boot LE may be considered to be trusted or authentic (in other words, verified).

[0051] At block 308, the post-boot environment may launch the post-boot QE with the second launch token. In response to authentication of the second launch token. In one example, upon authentication of the second launch token, the post-boot environment may automatically launch the post-boot QE with the second launch token. In another example, after authentication of the second launch token, user input may prompt the post-boot environment to launch the post-boot QE.

[0052] At block 310, the post-boot QE may collect encrypted keys from the device. In response to the launch of the post-boot QE, the post-boot QD may collect an encrypted public provision key, an encrypted private provision key, and an encrypted attestation key. In another example, the post-boot QE may collect an encrypted private attestation key and an encrypted public attestation key.

[0053] In another example, before collecting the encrypted public provision key, the encrypted private provision key, and the encrypted attestation key (i.e., the encrypted private attestation key and the encrypted public attestation key), the post-boot QE can authenticate the authenticity of the device using the public key described above. In one example, the device can supply the public key to any other component or program (such as the post-boot QE) that attempts to authenticate the device. In another example, the post-boot QE can verify the authenticity of the post-boot QE using an embedded digital certificate.

[0054] At block 312, the post-boot QE may decrypt the key with the system-specific encapsulation key. In one example, in response to collecting the encrypted public provision key, the encrypted private provision key, and the encrypted attestation key (i.e., the encrypted use attestation key and the encrypted public attestation key), the post-boot QE may also collect the system-specific encapsulation key. In a further example, the post-boot QE may be system-specific. In other words, the post-boot QE is launched on the system and comes from the system. In such an example, the post-boot QE may be signed with the private key of the same private / public key pair as the pre-boot QE 106. The system 100 or the processor 110 of the system 100 may authenticate the post-boot QE, similar to the authentication of the pre-boot QE 106 described above. For example, the system 100 or the processor 110 of the system 100 may include a hash value of a public key of the private / public key pair. In such an example, the processor 110 may authenticate the signature of the private key from the private / public key pair using the hash of the public key of the private / public key pair. With the signature verified, the post-boot QE 108 can be considered trusted or authentic (in other words, verified) and can access the system-specific wrapping key (from the recognized address or location). Once the post-boot QE has the system-specific wrapping key, the post-boot QE can decrypt the encrypted public provision key, the encrypted private provision key, and the encrypted attestation key (i.e., the encrypted private attestation key and the encrypted public attestation key) using the system-specific wrapping key.

[0055] In another example, the post-boot QE can protect a communication channel with the device. The post-boot QE can use the decrypted public provision key and private provision key to start or load a secure communication channel. In such an example, the post-boot QE can initiate a key exchange (e.g., a Diffie-Hellman key exchange) with the device in the same manner as described above for the pre-boot QE 108. For example, the post-boot QE can share the decrypted public provision key with the device. The post-boot QE and the device can perform the same calculations as above to obtain a shared secret or shared key. In another example, the post-boot QE can establish a secure communication channel with other devices, remote systems, or any other system / component requesting proof of the AE on the system 100.

[0056] In another example, the post-boot LE may launch the AE. The remote system may request the QE to attest to the authenticity of the AE. In such an example, the post-boot QE may provide a report or reference to the AE regarding the authenticity of the AE (supplying the report to the AE of the remote system). The post-boot QE may create the report using the decrypted attestation key (i.e., the decrypted private attestation key and the decrypted public attestation key). In another example, the remote system may verify the attestation reference using the public attestation key.

[0057] As stated, Figure 1 1 is a block diagram of a system 100 including a BMC 102, a pre-boot environment 104, a pre-boot LE 106, a pre-boot QE 108, and a processor 110. In one example, the BMC 102 can store keys (such as a public provision key, an encrypted private provision key, a public attestation key, and an encrypted private attestation key) from the pre-boot QE 108. The BMC 102 can also provide keys (such as a public provision key, an encrypted private provision key, a public attestation key, and an encrypted private attestation key) in response to a request for a key from the post-boot QE. In another example, the BMC 102 can provide a public key associated with the BMC 102. The key associated with the BMC 102 can be used to verify the authenticity of the BMC 102.

[0058] As described above, system 100 may include pre-boot environment 104. In one example, pre-boot environment 104 may launch pre-boot LE 106 and pre-boot QE 108. In a further example, pre-boot environment 104 may launch pre-boot QE 108 in response to authentication of a launch token from pre-boot LE 106. In another example, the functions described above may occur automatically upon input from a user or execution of machine-readable instructions.

[0059] As described above, system 100 may include preboot LE 106. Preboot LE 106 may create a launch token for other enclaves. Preboot LE 106 may also authenticate a launch token or signature. For example, preboot LE 106 may create a launch token for preboot QE 108, and after creating the launch token, may authenticate the launch token automatically or through user prompting. In another example, preboot LE 106 may create and authenticate launch tokens for others. For example, other enclaves may include other preboot LEs or AEs. In another example, preboot LE 106 may also obtain a wrapping key that is unique to system 100.

[0060] As described above, system 100 may include pre-boot QE 108. In one example, pre-boot QE 108 may generate a private provisioning key, a public provisioning key, a public certification key, and a private certification key. In another example, pre-boot QE 108 may verify the authenticity of BMC 102. In such an example, pre-boot QE 108 may verify the authenticity of BMC 102 with the public key described above. In another example, pre-boot QE 108 may verify the authenticity of BMC 102 with an embedded digital certificate.

[0061] In one example, in response to verifying the authenticity of BMC102, pre-boot QE108 can protect the communication channel with BMC102. Pre-boot QE108 can protect the communication channel with a key exchange (e.g., a Diffie-Hellman exchange). For example, in a Diffie-Hellman exchange, the public provision key can be a starting or common value between pre-boot QE108 and BMC102, and the private provision key can be a value used by pre-boot QE108 to calculate a shared secret (in such an example, BMC102 can include a specific private value for calculating the shared secret). In another example, different methods of protecting the communication channel can be used. In another example, pre-boot QE108 can encrypt the private provision key and the private attestation key. In a further example, pre-boot QE108 can encrypt the private provision key and the private attestation key with a wrapping key from pre-boot LE106 that is specific to system 100. In response to protecting the communication channel and encrypting the private provision key and the private attestation key, pre-boot QE 108 may communicate and encrypt the encrypted private provision key, the public provision key, the public attestation key, and the encrypted private attestation key on a machine-readable storage medium of BMC 102 .

[0062] In another example, system 100 may include a post-boot environment. The post-boot environment may perform similar functions as pre-boot environment 104 related to enclaves described above. For example, the post-boot environment may launch a post-boot LE and a post-boot QE. In a further example, the post-boot environment may launch a post-boot QE using an authenticated launch token. In another example, the post-boot environment may launch an AE. The post-boot environment may launch an AE with or without an authenticated launch token.

[0063] In another example, system 100 may include a post-boot LE. The post-boot LE may create and authenticate a launch token for other enclaves. For example, the post-boot LE may create and authenticate a launch token for a post-boot QE. In another example, the post-boot LE may create and authenticate a launch token for other enclaves. For example, other enclaves may include other post-boot LEs, QEs, or AEs. In another example, the post-boot LE may also obtain an encapsulation key that is specific to system 100.

[0064] In another example, the system 100 may include a post-boot QE. In one example, the post-boot QE may retrieve an encrypted private provision key, a public provision key, a public attestation key, and an encrypted private attestation key. In a further example, the post-boot QE may decrypt the encrypted private provision key and the encrypted private attestation key in response to obtaining a wrapping key specific to the system 100 from the post-boot LE. In another example, the post-boot QE may receive a request for a reference (or attestation reference, report, or attestation report) from the AE. In other words, the AE may request a reference (or attestation report, report, or attestation report) from the post-boot QE. In response to receiving the request for a reference or report, the post-boot QE may generate a reference or report. Once the reference or report is generated, the post-boot QE may send the reference or report to the AE. In a further example, the AE may send the reference or report to the remote system that originally requested the attestation.

[0065] Figure 4 4 is a block diagram of a computing device capable of launching a launch enclave, authenticating a launch token, launching an application enclave, obtaining a system-specific wrapping key, and launching a reference enclave, according to one example. Computing device 400 may include processing resources 402 and machine-readable storage medium 404. Processing resources 402 may execute instructions contained in machine-readable storage medium 404. The instructions may include instructions 406 to launch an LE. In one example, the LE may create and authenticate a launch token. In another example, processing resource 402 may execute instructions 406 to launch the LE in an offline or online mode (in other words, in a pre-boot or post-boot environment, respectively). In another example, processing resource 402 may use the launch token to launch other enclaves. In one example, processing resource 402 may use an authenticated launch token to launch other enclaves.

[0066] The machine-readable storage medium 404 may include instructions 408 to start the AE. In another example, the AE may be used for various purposes. The AE may communicate with a remote system. The communication may be secure, or may include secure information. To ensure that security is maintained, the remote system may request the AE to attest to authenticity. In other words, the remote system may request an attestation reference from the AE. In one example, in response to the AE receiving an attestation request from the remote system, the AE may request an attestation reference. For example, the AE may request an attestation reference from the QE.

[0067] Machine-readable storage medium 404 may include instructions 410 to obtain a system-specific wrapping key. In one example, computing device 400 may store the system-specific wrapping key in a control register of processing resource 402. In a further example, an enclave launched on computing device 400 may access or use the system-specific wrapping key.

[0068] The machine-readable storage medium 404 may include instructions 412 to start the QE. In response to the authentication of the startup token, the processing resource 402 may execute instructions 414 to start the QE. In one example, the processing resource 402 may execute instructions 414 to start the QE in a pre-boot environment. In such examples, the QE may generate a public supply key, a private supply key, a public certification key, and a private certification key. In a further example, the QE may use the public supply key to establish a secure, encrypted communication channel with the BMC. Further, the QE may verify that the BMC is authentic. In an offline or pre-boot environment, and in response to the QE being started offline, the QE may encrypt the generated public supply key, private supply key, public certification key, private certification key, or a specific combination thereof. Further, the QE may store the encrypted key in the machine-readable storage medium of the BMC.

[0069] In another example, processing resource 402 may execute instructions 412 to launch QE in a post-boot environment. In such examples, QE may obtain a public provisioning key, a private provisioning key, a public attestation key, and a private attestation key (some of which may be encrypted) from the BMC. In a further example, where the keys are encrypted (or some of the keys are encrypted), QE may decrypt the obtained keys. QE may use a system-specific encapsulation key that may be obtained by QE from computing device 400. In such examples, in response to a request for an attestation reference from an AE, QE may create an attestation reference. QE may then sign the attestation reference with the private attestation key. QE may then send the signed attestation reference to AE.

[0070] although Figures 2 to 3The flowcharts of the present invention show a specific execution order, but the execution order may be different from that depicted. For example, the execution order of two or more boxes or arrows may be disrupted relative to the order shown. Moreover, two or more consecutive boxes shown may be executed in parallel or partially in parallel. All such changes are within the scope of the present disclosure.

[0071] The present disclosure is described using the non-limiting detailed description of the examples of the present disclosure, and the present disclosure is not intended to limit the scope of the present disclosure. It should be understood that the features and / or operations described with respect to one example can be used for other examples, and not all examples of the present disclosure have the features and / or operations illustrated in a particular figure or described with respect to one of the examples. Those skilled in the art will expect variations of the described examples. Moreover, the terms "include," "comprise," "have," and their suffixes, when used in the present disclosure and / or claims, will mean "including but not necessarily limited to."

[0072] Note that some of the examples described above may include structures, actions, or details of structures and actions that may not be required by the present disclosure and are intended as examples. As is known in the art, the structures and actions described herein are interchangeable with equivalents that perform the same functions, even if the structures or actions are different. Therefore, the scope of the present disclosure is limited to the elements and limitations used in the claims.

Claims

1. A method for authenticating an enclave, comprising: Launching a pre-boot boot enclave LE from a pre-boot environment, wherein the pre-boot environment is an operating environment accessible before loading an operating system; A launch token for the pre-boot reference enclave QE is created by the pre-boot LE; authenticating, by the pre-boot LE, the startup token; launching, by the pre-boot environment in response to the authentication, the pre-boot QE using the launch token; generating, by the pre-boot QE, a public provisioning key, a private provisioning key and a certification key; verifying, by the pre-boot QE, the authenticity of a device using a public key, wherein the device is used to secure communications with the enclave and store encrypted keys; protecting, by the pre-boot QE, a communication channel with the device using the public provision key, the private provision key and the public key; encrypting, by the pre-boot QE, the public provision key, the private provision key, and the attestation key with a system-specific wrapping key; and An encrypted public provisioning key, an encrypted private provisioning key, and an encrypted attestation key are stored within the device by the pre-boot QE.

2. The method according to claim 1, further comprising: Starting a post-boot LE from a post-boot environment, wherein the post-boot environment is an operating environment accessible after the operating system is loaded; creating, by the post-boot LE, a second boot token for the post-boot QE; authenticating, by the post-boot LE, a second launch token for the post-boot QE; In response to the authentication, the post-boot environment initiates a post-boot QE using the second boot token; collecting, by the post-boot QE, the encrypted public provision key, the encrypted private provision key, and the encrypted attestation key from the device; and The encrypted public provision key, the encrypted private provision key, and the encrypted attestation key are decrypted by the post-boot QE using the system-specific encapsulation key.

3. The method according to claim 2, further comprising: Verifying, by the post-boot QE, the authenticity of the device using the public key; and Different communication channels with the device are protected by the post-boot QE with the decrypted public provision key, the decrypted private provision key and the public key.

4. The method according to claim 2, further comprising: The application enclave AE is started by the post-boot LE; and In response to a request to attest to the authenticity of the AE, the authenticity of the application enclave with the attestation reference is attested by the post-boot QE using the decrypted attestation key. The method of claim 4 , wherein the attestation key comprises a public attestation key and a private attestation key.

6. The method according to claim 5, further comprising: The public certification key is stored within the device by the pre-boot QE.

7. The method according to claim 6, further comprising: The attestation reference is verified by the device using the public attestation key.

8. The method according to claim 6, further comprising: collecting, by a third party, the public attestation key from the device; as well as The certification reference is verified by the third party using the public certification key.

9. The method of claim 1, wherein the device is a baseboard management controller.

10. The method of claim 1, wherein the device is a trusted platform module.

11. The method of claim 1 , wherein the system-specific wrapping key is associated with an enclave provisioned on a particular system.

12. The method of claim 1, wherein the public key is contained in a digital certificate embedded in the system.

13. A system for authenticating an enclave, comprising: Baseboard management controller BMC; A pre-boot environment, wherein the pre-boot environment is an operating environment accessible before loading an operating system, and wherein the pre-boot environment is used to: Start the pre-boot boot enclave LE to create and authenticate the boot token; obtaining a wrapping key associated with the system; Launching a preboot enclave QE with the boot token authenticated by the preboot boot enclave, the preboot QE being used to: Generate a private provisioning key and a public provisioning key; Generate a public and private proof key; Verifying the authenticity of the BMC using an embedded digital certificate; loading secure communications to the BMC with the public provision key, the private provision key, and the public key; encrypting the private provisioning key and the private attestation key with the wrapping key; and The public provisioning key, the encrypted private provisioning key, the public attestation key, and the encrypted private attestation key are stored within the BMC.

14. The system of claim 13, further comprising: A post-boot environment, wherein the post-boot environment is an operating environment accessible after loading an operating system, and wherein the post-boot environment is used to: After booting, boot LE to create and authenticate a second boot token; Launching a post-boot QE with the second boot token authenticated by the post-boot boot enclave, the post-boot QE being used to: retrieving the encrypted private provisioning key and the encrypted private attestation key from the BMC; decrypting the encrypted private provisioning key and the encrypted private attestation key using a wrapping key associated with the system; creating an attestation reference with the private attestation key in response to a request from an application enclave AE to attest the AE; and The certification reference is sent to the AE.

15. The system of claim 14, wherein the AE receives a request to certify the AE from a remote server.

16. The system of claim 13, wherein the wrapping key is available to any AE launched on the system.

17. The system of claim 13, wherein communications to the BMC are protected with the loaded encryption and message authentication via Diffie-Hellman key exchange.

18. The system of claim 13, wherein the pre-boot environment is a unified extended firmware interface.

19. A non-transitory machine-readable storage medium encoded with processor-executable instructions, the non-transitory machine-readable storage medium comprising instructions for: Launch the Launch Enclave LE to create and authenticate the launch token; Launch the application enclave AE; obtaining a wrapping key specific to a system used to authenticate the enclave; Launching a reference enclave QE using the authenticated launch token, wherein in response to launching the QE in an offline environment, the QE is used to: generating a public provisioning key, a private provisioning key, a public attestation key, and a private attestation key; Establish a secure encrypted communication channel to the baseboard management controller BMC through key exchange; Verify the authenticity of BMC; encrypting the private provisioning key and the private attestation key with a wrapping key specific to the system; and An encrypted private provisioning key and an encrypted private attestation key are stored within the BMC.

20. The non-transitory machine-readable storage medium of claim 19, wherein: In response to launching the reference enclave in an online environment, the reference enclave is used to: obtaining the encrypted private provisioning key and the encrypted private attestation key from the BMC; decrypting the encrypted private provisioning key and the encrypted private attestation key using the system-specific wrapping key; and In response to a request for a certification reference from the AE: Creating the attestation reference using the private attestation key; and The certification reference is provided to the AE.

Images