Computing device

Abstract

Embodiments related to security in a cloud environment are disclosed herein. In some embodiments, for example, a computing device (e.g., a microcloud) can include a trusted execution environment; a basic input / output system (BIOS) to request a key encryption key (KEK) from the trusted execution environment; and a self-encrypting storage (SES) associated with the KEK; wherein the trusted execution environment verifies the BIOS and provides the KEK to the BIOS after verifying the BIOS, and the BIOS provides the KEK to the SES to unlock the SES for access by the trusted execution environment.

Description

[0001] This application is a divisional application. The original application was filed with the China Patent Office on May 18, 2018 (international filing date was November 16, 2016), application number 201680067500.4, entitled "Computing Device".

[0002] Cross-reference to related applications

[0003] This application claims the benefit of priority to U.S. Provisional Patent Application No. 62 / 269,666, filed December 18, 2015, entitled “SECURITY IN CLOUDLETENVIRONMENTS”, and U.S. Non-Provisional Patent Application No. 15 / 060,844, filed March 4, 2016, entitled “COMPUTING DEVICES”, the entire contents of which are incorporated herein by reference. Background Technology

[0004] Many computing applications are delivered to end users via processing and storage resources centralized in remote data centers the size of a room or building. These data centers provide physical security for these resources, protecting them from physical tampering or theft. Attached Figure Description

[0005] The embodiments will be readily understood from the following detailed description taken in conjunction with the accompanying drawings. For ease of illustration, the same reference numerals denote the same structural elements. The embodiments are shown in the accompanying drawings by way of example rather than limitation.

[0006] Figure 1 This is a block diagram of a networked computing system including one or more microclouds, according to various embodiments.

[0007] Figure 2 This is a block diagram of a networked computing system including a microcloud lifecycle manager in one or more microclouds, according to various embodiments.

[0008] Figure 3 This is a block diagram of a networked computing system for mobile edge computing (MEC) including microclouds, according to various embodiments.

[0009] Figure 4 This is a block diagram of a networked computing system including a micro-cloud, for network function virtualization (NFV), according to various embodiments.

[0010] Figure 5 The first stage of a trusted boot process according to various embodiments is shown.

[0011] Figure 6 The second phase of a trusted boot process according to various embodiments is illustrated.

[0012] Figure 7 The first phase of a trusted bootstrapping process, including a root of trust measurement, is illustrated according to various embodiments.

[0013] Figure 8 The second phase of a trusted bootstrapping process, including a root of trust measurement, is illustrated according to various embodiments.

[0014] Figure 9 This is a block diagram of a computing device that can be used to implement the networked computing system disclosed herein, according to various embodiments. Detailed Implementation

[0015] Traditional cloud computing systems typically locate storage and processing resources in centralized data centers, far from the user devices that host these resources. This arrangement often results in high latency and high traffic across the network. However, if these storage and processing resources are moved from the centralized data center to the "edge" of the network (where the user devices are located), they are no longer physically protected and monitored by the centralized data center, and the risk of these resources suffering actual damage increases. In particular, these resources may be stolen and / or tampered with, causing them to behave in undesirable ways that are difficult to detect. For example, "remote" processing resources could download compromised cloud platform firmware, operating system (OS), software virtualization network function (VNF) updates, and / or patches from a remote site via the Internet, and this damage might go undetected. In another example, a hacker could gain physical access to a competing resource and tamper with it, rendering it in a compromised state. Conventional computing systems cannot trust that software (e.g., firmware, OS, etc.) running on remote computing resources is undamaged.

[0016] This document discloses methods and apparatus for providing tamper-resistant or tamper-proof security for cloudlets in environments where physical security cannot be guaranteed. The cloudlets disclosed herein can provide "cloud-in-a-box systems that provide cloud computing system functionality without requiring hard connections back to traditional cloud environments and meet the security requirements expected by service providers for their conventional data center-based cloud resources." Various embodiments disclosed herein may relate to the creation of boot integrity schemes and chains of trust implemented in the hardware of the entire operating platform.

[0017] In some embodiments, the microclouds disclosed herein can enable Network Functions Virtualization (NFV) and Software-Defined Networking (SDN) operators to extend their cloud service infrastructure closer to their subscribers, achieving performance and latency improvements without compromising security and reliability. The various embodiments disclosed herein may be particularly advantageous in mobile edge computing (MEC) applications (e.g., European Telecommunications Standards Institute (ETSI) MEC), fog computing, and cloud edge computing applications. For example, the microclouds disclosed herein can support secure implementations of 5G mobile network (5G) and MEC capabilities and their associated use cases.

[0018] In the following detailed description, reference is made to the accompanying drawings, which form a part of the description, wherein similar reference numerals always denote similar parts, and wherein practicable embodiments are shown by way of example. It should be understood that other embodiments may be utilized and structural or logical changes may be made without departing from the scope of this disclosure. Therefore, the following detailed description is not restrictive.

[0019] Various operations can be described sequentially as multiple discrete actions or operations in a manner most conducive to understanding the claimed subject matter. However, the order of description should not be construed as implying that these operations must depend on the order. In particular, these operations may not be performed in the presented order. The described operations may be performed in a different order than the described embodiments. Various additional operations may be performed, and / or the described operations may be omitted in additional embodiments.

[0020] For the purposes of this disclosure, the phrase "A and / or B" means (A), (B), or (A and B). For the purposes of this disclosure, the phrase "A, B, and / or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C). This description uses the phrase "in one embodiment" or "in an embodiment," which may refer to one or more of the same or different embodiments, respectively. Furthermore, the terms "comprising," "including," "having," etc., used with respect to embodiments of this disclosure are synonymous. The drawings are not necessarily drawn to scale.

[0021] Figure 1This is a block diagram of a networked computing system 100 including one or more microclouds 102 according to various embodiments. As used herein, "microcloud" can refer to computing resources (e.g., memory, processors, and networking devices) contained in a single enclosure (or a small number of enclosures) to provide data storage, processing, and / or distribution capabilities. In some embodiments, a microcloud can act as a small-scale data center. In some embodiments, as described above, the microcloud 102 can provide a substantially fully functional cloud system within a enclosure without needing to connect back to a complete cloud environment. The various microclouds 102 in system 100 can be deployed in remote environments where the physical security of the microclouds 102 cannot be guaranteed (e.g., in a public park, street corner, shopping mall). System 100 may include a single microcloud 102 or multiple microclouds 102 (e.g., dozens or hundreds of microclouds 102). References are made below. Figure 9 Discuss example implementations of Weiyun.

[0022] Typically, the microcloud 102 can run virtual functions, applications, workloads, and data storage and collection processes. In some embodiments, one or more of the microclouds 102 can run one or more Virtualized Network Functions (VNFs) 136. For example, VNF 136 may include one or more VNFs provided by a Long Term Evolution (LTE) communications operator, such as a Virtual Evolved Packet Core (vEPC) or a Virtual Customer Premises Equipment (vCPE). In some embodiments, one or more of the microclouds 102 can run one or more workload virtual machines (VMs) 138. As is known in the art, each workload VM 138 can provide an operating system (OS) and an independent instantiation of applications running on top of the operating system. Applications running in workload VMs 138 can be any suitable application, such as video caching, transcoding, etc. VNFs 136 and workload VMs 138 can utilize a set of OpenStack services 134 running on a host OS / VMM 128, and the host OS / VMM 128 may include a dock daemon 132 (e.g., for container management), as known in the art. One or more containers 117 can also run on the micro-cloud 102, providing operating system-level virtualization, as is known in the art (e.g., for high-performance computing applications). The security techniques disclosed herein can securely enable these capabilities of the micro-cloud 102 without the physical security of a centralized data center (by, for example, using keys and ciphertext).

[0023] Microcloud 102 may include multiple security components. For example, microcloud 102 may include a manageability engine (ME) 108. For example, ME 108 may include a converged security and manageability engine (CSME). ME 108 may be a standalone trusted execution environment and may act as a root of trust for the manufacturer of microcloud 102 (e.g., providing a secure environment for a manufacturer-controlled boot process). For example, the trusted execution environment may provide one or more processors and memory devices that can execute code at a higher security level than that provided by the host OS / VMM 128. In some embodiments, the trusted execution environment may be isolated from the operating hardware and / or software of the host OS / VMM 128 (e.g., through encryption), and therefore can execute code in isolation from the code that executes as part of the host OS / VMM 128. In some embodiments, the trusted execution environment may be a secure area of ​​the secure processor 126 in microcloud 102, and the code executing in the trusted execution environment may be securely protected from tampering with the code executing in the host OS / VMM 128.

[0024] In some embodiments, ME 108 may be a security service processor running a manufacturer-trusted and host-independent OS. ME 108 may utilize various platform protocols and silicon functionalities such as the Intelligent Platform Management Interface (IPMI), Platform Environment Control Interface (PECI), and Host Embedded Controller Interface (HECI) to connect external management systems to the platform. In some embodiments, ME 108 may connect to various hardware components via a secure architecture (e.g., Intel System-on-Chip Architecture (IOSF)). ME 108 may include a Platform Trust Technology (PTT) component 110 and may communicate with a Trusted Platform Module (TPM) 118. As is known in the art, TPM 118 may include a chip (with processing devices) that can securely store platform data used for authenticating the microcloud 102. As is known in the art, PTT 110 may provide credential storage and key management functions and may act as a firmware TPM (fTPM) providing TPM functionality for applications on ME 108.

[0025] Microcloud 102 may include an Innovation Engine (IE) 112. IE 112 can communicate with ME 108 and can be a separate, independent trusted execution environment. Specifically, IE 112 can act as the root of trust for the operator (platform owner) of Microcloud 102 (e.g., a Telecommunication Equipment Manufacturer (TEM)). IE 112 may be supplied according to operator-specific firmware. In some embodiments, IE 112 may include a Secure Out-of-Band (OOB) service processor running a host-independent OS trusted by the operator. IE 112 may contain a boot image and authentication credentials from the operator (stored, for example, in fuses and manifests), and may store operator licensing schemes for executing specific applications or applets within IE 112. IE 112 can utilize various platform protocols and silicon functions (such as IPM I, PECI, and HECI) to connect external management systems to the platform. In some embodiments, IE 112 may connect to various hardware components via a security architecture (e.g., IOSF). IE 112 can provide an OOB manageable access point to the micro-cloud 102 platform and may optionally include an fTPM. In some embodiments, IE 112 may have networking capabilities that ME 108 may not have; for example, an Ethernet interface and associated network access. IE 112 may also access dedicated platform accelerators, such as field-programmable gate arrays (FPGAs).

[0026] IE 112 may include a Multi-Party Authorization (MPA) component 116. In use, IE 112 itself can be securely booted with a signed image and signed configuration parameters, and as described above, can act as a hardware root of trust for the carrier infrastructure (holding security credentials for the OS and applications of IE 112). MPA component 116 can run within IE 112 to implement access control and explicit authorization for security applications (e.g., NFV carrier access, telemetry, monitoring, updates, etc.). IE 112 can also be responsible for verifying any UEFI / BIOS signatures using platform credentials (stored, for example, in a fuse). IE 112 can store a key encryption key (KEK) for Self-Encrypting Storage (SES) 156; this KEK... Figure 1 This is referred to as SES-KEK 114. SES 156 is discussed in further detail below. ME 108 and IE 112 may include their own processors, cryptographic cores, static random access memory (SRAM), etc.

[0027] The MicroCloud 102 may include a boot protection component 160. The boot protection component 160 can provide hardware-based boot integrity protection to prevent unauthorized software and malware from taking over the boot block of the MicroCloud 102. In some embodiments, the boot protection component 160 may be included in an Authentication Code Module (ACM). The ACM is firmware configured to invoke appropriate CPU instructions to perform boot protection measurements and verifications. The ACM code may be privileged code signed by the manufacturer or another trusted entity. In some embodiments, the ACM may be part of the security processor 126 discussed below. The boot protection component 160 can provide measured boot, where the initial boot block is measured into the TPM 118 or PTT 110, or verified boot, where the initial boot block is cryptographically verified using a boot policy key. The boot protection component 160 can be utilized by the Central Processing Unit (CPU) of the MicroCloud 102 to boot and trigger the signing and verification process during boot. The ME108 and IE 112 can be hardware verified before CPU boot begins.

[0028] The microcloud 102 may include a security processor 126. The security processor 126 may be a security-enhanced general-purpose processor. In some embodiments, the security processor 126 may include a Software Protection Extension (SGX) component (not shown) to provide a set of instructions to the security processor 126, which can be used by an application to keep private areas of code and data within a “secure enclave.” In some embodiments, the security processor 126 may include a Trusted Measurement Service to perform proofs to ensure that all system components are authorized. For example, the security processor 126 may include a Trusted Execution Technology (TXT) component (not shown) to create a cryptographically unique identifier for each approved boot-enabled component of the microcloud 102, and then provide a hardware-based enforcement mechanism to prevent boot code that does not match the approved code. For example, the TXT component may be implemented by an ACM. In some embodiments, the security processor 126 may be an x86 processor.

[0029] The microcloud 102 may include a basic input / output system (BIOS) 122, which in turn may include an optional read-only memory (OROM) 124. The BIOS 122 may be a Unified Extensible Firmware Interface (UEFI) BIOS, and the OROM 124 may be a UEFI OROM. As discussed below, the OROM 124 may be implemented as firmware loaded by the BIOS 122 and may be used by the BIOS 122 to enable the ME 108 and IE 112 to read data in the SES 156. The BIOS 122 may be certified by the ME 108. In some embodiments, the BIOS 122 may implement signature verification of the OROM 124 (e.g., a UEFI OROM), as well as for the OS bootloader and OS image in the microcloud 102. For example, the UEFI secure boot process may be provided by the operator of the microcloud 102 during boot, including the OS bootloader and OS signing and verification. UEFI authentication variables (e.g., platform key (PK), KEK, signature database (DB), and prohibition database (DBX)) may be stored in a secure portion of the host storage device 154 (e.g., a rollback-resistant partition in an embedded multimedia card (eMMC) or universal flash memory device (UFS). In some embodiments, the OROM 124 may be a UEFI-loadable module controlled by the IE 112 and stored in the SPI flash memory 150. In some embodiments, the payload of the OROM 124 may be responsible for primary host storage management and / or updates.

[0030] BIOS 122 may use a key (e.g., SES-KEK 114) supplied to MicroCloud 102 by the operator as part of its authentication variables. In some embodiments, BIOS 122 may store the authenticated variables in a separate partition of SES 156. In some embodiments, BIOS 122 may store the authenticated variables in a secure storage partition of main storage device 152 (described below), accessible only through the platform root of trust (e.g., ME 108).

[0031] The host OS / VMM 128 may include a Cloud Integrity Technology (CIT) agent 130. The CIT agent 130 may interact with a trusted measurement service (e.g., TXT) of the security processor 126 to enable boot time measurements of the BIOS 122, the OS and VMM of the host OS / VMM 128, and any VNF 136, VM 138, or container 117 that is started. In some embodiments, boot protection 160, the CIT agent 130, and the trusted measurement service (e.g., TXT) of the security processor 126 may together provide trusted, verified, and measured booting all the way to applications or services running on the micro-cloud 102.

[0032] In some embodiments, as referenced below Figures 5-8 As discussed in detail, the MicroCloud 102 can perform a secure and trusted boot process. This boot process may include releasing SES-KEK 114 to SES 156 to complete the boot process. Several of the security components discussed herein can be utilized during this boot process, including the boot protection component 160, BIOS 122, and the host OS / VMM 128, as discussed in detail below.

[0033] Microcloud 102 may include one or more network interface controllers (NICs) / switches 120. The NICs / switches 120 may communicate with the host OS / VMM 128 and IE 112, and may route data to / from microcloud 102. In some embodiments, all firmware and configuration information installed to the NICs / switches 120 may be verified by a trusted measurement service (e.g., SGX) of the ME 108, IE 112, and / or security processor 126. These firmware and configuration elements may be stored in SES 156. In some embodiments, the NICs / switches 120 may be part of the main processor of microcloud 102 (e.g., in the central processing unit (CPU) north complex) or in a chipset (e.g., the platform controller hub (PCH) or south complex). In some embodiments, the NICs / switches 120 may be implemented in an FPGA programmable logic module. In some embodiments, the NICs / switches 120 may be located outside of microcloud 102 and on a Fast Peripheral Component Interconnect (PCIe), optical, or other high-speed bus. In some embodiments, the NIC / switch 120 and the micro-cloud 102 may be manufactured by different manufacturers.

[0034] Microcloud 102 may include firmware storage device 140 and main storage device 152. In some embodiments, firmware storage device 140 may include Serial Peripheral Interface (SPI) flash memory 150, but may alternatively or additionally include, for example, eMMC. SPI flash memory 150 may include BIOS firmware storage device 142 (for BIOS 122), ME firmware storage device 144 (for ME 108), IE firmware storage device 146 (for IE 112), NIC firmware storage device 162 (for NIC / switch 120), and OROM firmware storage device 148 (for OROM 124). SPI flash memory 150 may provide storage for the main platform storage device (e.g., storing UEFI platform configuration parameters).

[0035] Main storage device 152 may include storage device 158 for host OS cloud services and storage device 154 for the host. Main storage device 152 may store images of the host OS and may store all images stored in main storage device 152 in an encrypted manner. Main storage device 154 may include one or more SES 156; although mentioned in the singular, SES 156 may include one or more SES devices. SES 156 may include a memory device (e.g., a hard disk drive) and hardware circuitry for encrypting / decrypting data as it is written to or from the memory device. Encryption / decryption of data in the memory device is performed using a Media Encryption Key (MEK), which is itself encrypted by a KEK. For example, the KEK used for SES 156 is SES-KEK 114 in IE 112. SES 156 can be used for the OS. Although in Figure 1 The image is shown separately, but in some embodiments, SES 156 can be used in platform firmware. In some embodiments, the primary storage device 152 may have dual redundant partitions, such that if a partition fails, the cloud 102 can recover to its redundant partition.

[0036] In some embodiments, SES 156 can be partitioned into partitions, and IE 112 and / or ME 108 can incrementally unlock these partitions as needed (e.g., using different KEKs). A KEK (e.g., SES-KEK114) can always be protected within IE 112 and / or ME 108 (or other trusted environments) and can be programmed into SES 156 as needed. In some embodiments, each storage partition can have its own unique encrypted KEK. In some embodiments, the KEK (e.g., SES-KEK114) can be securely packaged by IE 112 and / or ME 108 and delivered to the operator's secure command center or the infrastructure owner of Micro Cloud 102. For example, the secure command center can use the packaged KEK for auditing and hosting.

[0037] The main storage device 152 and / or firmware storage device 140 may be secure storage devices, such as secure rollback-protected eMMC and / or secure flash partitions. For example, this secure storage device may be used to store platform firmware, OS bootloaders, and OS components. In some embodiments, the secure storage device of the microcloud 102 may be used to store platform firmware, OS bootloaders, and / or OS identification information that can be used to check if the correct version is in place. Examples of such OS identification information include version, security version, OS components (e.g., OpenStack image, storage, and networking services), authorized signer, and authentication variables, etc. "Version" may refer to the book value that distinguishes different versions of the software. "Security version" may refer to a value that changes when a security policy violation is detected in the software, firmware, or other related components. For example, the software may have a security version of 1 until a security issue is discovered, at which point the security version may be updated to 2 (and all security versions prior to this new security version may be considered vulnerable). "Authentication variables" may refer to secure signature database variables, such as signing keys, authorization databases, key hierarchies, update logs, etc. When the BIOS 122 is a UEFI BIOS, these authentication variables are defined by UEFI. In some embodiments, the secure storage device can be cryptographically bound to the platform hardware root of trust (e.g., the trusted measurement service (e.g., SGX) of ME 108, IE 112, and / or security processor 126). The secure storage device can be bound to the platform of Weiyun 102, and in some embodiments, any physical tampering may render the platform unbootable. In some embodiments, the platform of Weiyun 102 cannot boot without the secure storage device.

[0038] like Figure 1 As shown, micro-cloud 102 can communicate with one or more other micro-clouds 102. These other micro-clouds 102 can be configured according to any of the embodiments discussed above. In some embodiments, micro-cloud 102 may not communicate with any other micro-cloud 102. Micro-cloud 102 can also communicate with micro-cloud management center 106 (which may also be referred to as micro-cloud control center) via Internet 104. Internet 104 may consist of network devices, Internet connections, fiber optic backbones, or any other network hardware coupling micro-cloud 102 to micro-cloud management center 106. In some embodiments, one or more micro-clouds 102 can communicate with one or more network infrastructure components 119 (e.g., top-of-rack switches or routers).

[0039] The micro-cloud management center 106 can provide Infrastructure as a Service (IaaS) for managing the micro-cloud 102 within the system 100. Using the micro-cloud management center 106 to manage the micro-cloud 102 allows the system 100 to be implemented with a lower total cost of ownership (TCO) and large-scale deployment capabilities. In some embodiments, the micro-cloud management center 106 may include installed and configured management circuitry to provide appropriate software and configuration information to the micro-cloud 102. When the host OS or applications running on the micro-cloud 102 are to be updated, the remote management and telemetry circuitry in the micro-cloud management center 106 can communicate with the micro-cloud 102 using a dedicated out-of-band mechanism. For example, a port of the NIC / switch 120 can be assigned to operate as this out-of-band mechanism, providing a secure and reliable channel between the micro-cloud 102 and the micro-cloud management center 106. The updated image can be pushed down to the cloud 102 by the cloud management center 106, and the IE 112 can call OROM 124 to provide IE 112 with access to SES 156 in the main storage device 152 to store the new image. When the new image is pushed down to the cloud 102 via an out-of-band mechanism, the host OS / VMM 128 can continue operating, thereby minimizing downtime caused by the update. In other embodiments, a direct connection may exist between the IE 112 and the main storage device 152, and / or between the ME 108 and the main storage device 152 (e.g., the main storage device 152 may include multiple headers for communication with the IE 112 and the ME 108). In this way, the controller for the main storage device 152 can cause the host OS / VMM 128, the IE 112, and / or the ME 108 to act as different "agents" to connect to and use the main storage device 152 for read / write operations.

[0040] In some embodiments, the OS images on multiple microclouds 102 included in system 100 may be identical, and the identity of microcloud 102 may be determined by a configuration file hosted on a secure pseudo universal serial bus (USB) (or pseudo PCIe) device. A pseudo device can provide operation of a set of device-like devices without the hardware typically associated with such a device, to enhance the functionality of existing devices or access subsystems of microcloud 102. In some embodiments, the pseudo device may be implemented by a pseudo device driver, which may be part of a kernel that acts as a device driver but does not correspond to any “real” device hardware in microcloud 102. Specifically, a secure and trusted boot process (such as referenced below) Figures 5-8The process under discussion can be configured to expose configuration information as a pseudo-device on the USB (or PCIe) bus and allow IE112 to securely update information about the device. In some embodiments, such an implementation may include having OROM 124 mount the relevant storage device as a USB or PCIe device and having a USB or PCIe redirection controller in IE 112. The presence of an encrypted static storage device can limit the risk of physical attacks.

[0041] Figure 2 This is a block diagram of a networked computing system 100 including one or more microclouds 102 and a microcloud lifecycle manager 170, according to various embodiments. The microcloud lifecycle manager 170 may be embedded in the microcloud 102. In some embodiments, the microcloud lifecycle manager 170 of the microcloud 102 may be located in IE 112. Figure 2 As shown, each micro-cloud 102 can communicate with the micro-cloud management center 106. Specifically, the micro-cloud lifecycle manager 170 can communicate with the installation and configuration management circuitry, as well as the remote management and telemetry circuitry of the micro-cloud management center 106, as discussed above. During operation, the platform telemetry circuitry of the micro-cloud 102 can communicate with the telemetry hub included in the ME 108 (which may include firmware TPM 118 as discussed herein), and the ME 108 can communicate with the micro-cloud lifecycle manager in the IE 112. Each micro-cloud 102 can also communicate with a cloud system 174 provided by a telecommunications company or other service provider to perform NFV and SDN operations. The cloud system 174 may have its own data center 176, which may take the form of a traditional cloud computing data center. Each micro-cloud 102 can also communicate with a cloud application distribution device 172, which can provide application-specific software to the micro-cloud 102.

[0042] The MicroCloud Lifecycle Manager 170 can interact with the MicroCloud Management Center 106 to allow secure exchange between MicroCloud 102 and MicroCloud Management Center 106 without the possibility of man-in-the-middle or spoofing arrangements. For example, in some embodiments, the MicroCloud Lifecycle Manager 170 can emulate a read-only device and expose this emulated read-only device to a master server (e.g., MicroCloud Management Center 106 or MicroCloud 102 in System 100). The emulated device may include configuration parameters, which may be exposed as files or other data forms known to the operating application software on the master server. The MicroCloud Lifecycle Manager 170 can expose an Application Programming Interface (API) to the MicroCloud Management Center 106 to allow secure updates to the contents of the emulated device. The MicroCloud Lifecycle Manager 170 can therefore provide node configuration pseudo-devices.

[0043] In another example, in some embodiments, the Micro Cloud Lifecycle Manager 170 can simulate a logging device and expose this simulated read-only device to the master server. Information written to this device can be securely presented to the Micro Cloud Management Center 106 by the Micro Cloud Lifecycle Manager 170 as logger diagnostic information. The Micro Cloud Lifecycle Manager 170 can filter log information sent to the Micro Cloud Management Center 106 based on configuration or policy settings from the Micro Cloud Management Center 106.

[0044] In another example, once the Weiyun 102 platform has been fully verified, Weiyun 102 can expose its out-of-band proof level to external systems. This out-of-band proof level can represent the security of Weiyun 102's measurements. For example, a "five-star" proof level could indicate that Weiyun 102's firmware, OS bootloader, keys, and configuration are as expected. A "four-star" proof level could indicate that Weiyun 102 is mostly, but not entirely, as expected (e.g., the firmware is an outdated version). A "zero-star" proof level might indicate complete failure (e.g., the measured bootloader does not match expectations).

[0045] In some embodiments, the Weiyun Lifecycle Manager 170 can communicate with the remote management and telemetry circuitry of the Weiyun Management Center 106 via a RESTful interface. This interface can use JavaScript Object Notation (JSON) data format, and in some embodiments, it can be a Secure Hypertext Transfer Protocol (HTTPS) interface (e.g., according to the X.509 standard for client / server authentication).

[0046] As described above, in some embodiments, the micro-cloud 102 disclosed herein may be included in an MEC arrangement. Figure 3 This is a block diagram of a networked computing system 100 for mobile edge computing (MEC) including microcloud 102, according to various embodiments. Figure 3In system 100, user equipment 178 can represent any terminal device, such as a smartphone, other personal computing device, Internet of Things (IoT) device, vehicle, or sensor. A single user equipment 178 is shown for illustrative purposes, and system 100 may include multiple user equipments 178. Small cell 180 can communicate with user equipment 178 and can represent a small wireless network hub (e.g., a Wi-Fi hub, a 3GPP antenna, etc.). According to any embodiment disclosed herein, small cell 180 can be coupled to MEC platform 182, which may include microcloud 102. Termination can be performed at MEC platform 182, and microcloud 102 can provide VNF 136 for mobile termination, signaling, data plane, and applications. MEC platform 182 can communicate with mobile core 184, which may have MEC core node 186. Communication between MEC platform 182 and mobile core 184 may include backhaul links, routers, switches, and any other suitable hardware as known in the art. Mobile core 184 may include, for example, an LTE backbone network. MEC core node 186 can then communicate with the Internet 104, which in turn can be coupled to any of a variety of services (not shown), such as content delivery, content analytics, vehicle monitoring, monitoring of other sensors, emergency services, etc. This architecture contrasts with traditional mobile networks, where small cells 180 are coupled to mobile core 184 via eNBs that do not have the capability to provide cloud computing services.

[0047] Figure 4 This is a block diagram of a networked computing system 100 including a micro-cloud 102 for network function virtualization (NFV), according to various embodiments. Figure 4 In system 100, micro-cloud 102 can act as NFV infrastructure (NFV), and micro-cloud management center 106 can be included in the NFV management and orchestration (NFV MANO) component. In some embodiments, Figure 1 All components of MicroCloud 102 can be included in NFVI, except for OpenStack Services 134, VNF 136, workload VMs 138, and containers 117.

[0048] As described above, in some embodiments, the micro-cloud 102 can perform a secure and trusted boot process. This boot process may include releasing the SES-KEK 114 to the SES 156 to complete the boot process. Figure 5 and Figure 6 The first and second phases of a first embodiment of the trusted boot process are shown respectively, while Figure 7 and Figure 8The first and second phases of a second embodiment of the trusted boot process are shown respectively.

[0049] exist Figures 5-8 During the trusted boot process, the SES-KEK114 associated with SES 156 is protected by ME 108 and IE 112 and can be passed to BIOS 122 when applicable. Once successfully authenticated and authorized, SES-KEK114 can be provided to SES 156 for self-decryption and unlocking. Before receiving SES-KEK 114, BIOS 122 may have to pass signature verification checks and measurement checks originating from ME 108 and / or IE 112. BIOS 122 may include mechanisms for accessing and unlocking SES 156. In some embodiments, the above BIOS operations can be performed in System Management Mode (SMM) mode based on UEFI BIOS System Management Interrupt (SMI). In some such embodiments, the code executed in SMM can be trusted and verified as a root of trust by ME 108 and / or IE 112.

[0050] Go to Figure 5 The diagram illustrates a first phase 500 of a trusted boot process according to various embodiments. As discussed below, the first phase 500 may be a measurement and verification phase for hardware and BIOS. After system power-on, at 502, the microcode can verify and measure the Authentication Code Module (ACM) of Boot Protection (BtG) 160. The result can be written to the Platform Configuration Register (PC). At 504, the ACM of Boot Protection 160 can verify BIOS 122 and can write the result to the PCR. At 506, the ACM can verify and measure the initialization code of BIOS 122. The result can be written to the PCR; if verification fails, the process may abort. At 508, the trusted measurement service (e.g., TXT) and its memory of the Security Processor 126 can be initialized, and the SMM can be loaded. At 510, the SMM and other trusted code can be measured, and the result written to the PCR. At 512, the configuration of the trusted measurement service (e.g., TXT) and its memory can be locked by providing the ENTERACCS: LockConfig instruction. At 514, non-critical code can be executed. At 516, BIOS 122 can communicate with IE 112 to obtain SES-KEK 114 for locking SES156.

[0051] Figure 6 The second stage 600 shown can be a measurement stage for various other components (e.g., Trusted Boot (TBOOT), OS, dock engine, etc.). For example, TBOOT can be a "pre-kernel" component of the OS or VM that can invoke the TXT instruction to measure. Go to Figure 6At 602, BIOS 122 can provide SES-KEK 114 to SES 156. At 604, SES 156 can use SES-KEK 114 to decrypt SES 156's MEK, thereby unlocking SES 156. This process can be aborted if unlocking SES 156 fails. At 606, SINIT and OS code can be loaded, and a SENTER instruction can be provided (as part of a TXT process known in the art). At 608, the microcode can verify SINIT at 606 and write the result to the PCR. At 610, SINIT can measure TBOOT and write the result to the PCR. At 612, SINIT can measure the OS kernel initrd++ and write the result to the PCR. At 614, Tboot-xm can measure applications, configuration data, dock daemons, and / or other OS components and write the result to the PCR. The components measured at 614 can be configurable. In 616, the OS can be booted.

[0052] exist Figure 5 and Figure 6 The trusted boot process illustrated provides secure remote access to the Weiyun 102 platform, including authorization credentials that enable ME 108 and / or IE 112 to unlock SES 156. SES-KEK 114 is never visible to protected firmware or is extracted under normal circumstances. In some embodiments, for operator compliance, the Weiyun 102's KEK can be retrieved using highly privileged authorization. For example, IE 112 and / or ME 108 may be pre-provided with authorization credentials that can be used to securely deliver the KEK to a management entity (e.g., such as...). Figure 4 (The NFV virtualization infrastructure manager is shown).

[0053] Figure 7 and Figure 8 The first and second stages of a second embodiment of the trusted boot process are shown respectively. Figure 7 and Figure 8 The trusted boot process shown also measures the root of trust (e.g., ME 108 and IE 112). This can be used for security auditing and compliance to ensure that the Weiyun 102 platform boots with a known set of root of trust firmware / OS and a known root of trust configuration.

[0054] As described below, Phase 700 can be a measurement and verification phase for both hardware and BIOS. [Go to...] Figure 7In the first phase 700, after system power-on, at 702, ME ROM booting (e.g., ME 108) and hardware initialization can be performed, and measurements can be stored in internal SRAM (e.g., when TPM 118 is not yet ready). At 704, IEROM booting (e.g., IE 112) and multi-party authorization (e.g., multi-party authorization component 116) can be performed, and measurements can be stored in internal SRAM (e.g., when TPM 118 is not yet ready). At 706, the microcode verifies and measures the ACM of BIOS 122, and the results can be written to the PCR. At 708, the ACM verifies and measures the initialization code of BIOS 122. The results can be written to the PCR; if verification fails, the process can be aborted. At 710, the trusted measurement service (e.g., TXT) of security processor 126 and its memory can be initialized, and system management mode (SMM) can be loaded. As is known in the art, SMM can be a mode in which OS execution is suspended and trusted firmware is executed. At 712, SMM and other trusted codes can be measured, and the results written to PCR. At 714, the configuration of trusted measurement services (e.g., TXT) and their memory can be locked, and the ENTERACCS:LockConfig instruction can be provided. At 716, non-critical code can be executed. At 718, BIOS 122 can communicate with IE 112 to obtain SES-KEK 114 for locking SES 156.

[0055] Figure 8 The second phase 800 shown can be a measurement phase for various other components (e.g., TBOOT, OS, dock engine, etc.). Go to Figure 8 At 802, BIOS 122 can provide SES-KEK114 to SES 156. At 804, SES 156 can use SES-KEK114 to decrypt SES 156's MEK, thereby unlocking SES 156. This process can be aborted if unlocking SES 156 fails. At 806, SINIT and OS code can be loaded, and the SENTER instruction can be provided. At 808, the microcode can verify SINIT on 806 and write the result to the PCR. At 810, SINIT can measure TBOOT and write the result to the PCR. At 812, SINIT can measure the OS kernel initrd++ and write the result to the PCR. At 814, Tboot-xm can measure application, configuration, and dock data and write the result to the PCR. The components measured at 814 can be configurable. At 816, the OS can be booted.

[0056] Figure 9This is a block diagram of a computing device 900, according to various embodiments, of various components that can be used to implement the networked computing system disclosed herein. For example, some or all of the components of the computing device 900 may be included in a cloud application 102, a cloud application management center 106, a user device 178, or a cloud application distribution device 172. Multiple elements are... Figure 9 These elements are shown as included in the computing device 900, but any one or more of these elements may be omitted or copied when applicable to the application.

[0057] Additionally, in various embodiments, the computing device 900 may not include... Figure 9 The computing device 900 may include one or more of the elements shown, but may include interface circuitry for coupling to one or more elements. For example, the computing device 900 may not include display device 906, but may include display device interface circuitry (e.g., connector and driver circuitry) to which display device 906 may be coupled. In another set of examples, the computing device 900 may not include audio input device 924 or audio output device 908, but may include audio input or output device interface circuitry (e.g., connector and support circuitry) to which audio input device 924 or audio output device 908 may be coupled.

[0058] Computing device 900 may include processing device 902 (e.g., one or more processing devices). As used herein, the term "processing device" or "processor" may refer to any device or part of a device that processes electronic data from registers and / or memory to convert that electronic data into other electronic data that can be stored in registers and / or memory. Processing device 902 may include one or more digital signal processors (DSPs), application-specific integrated circuits (ASICs), central processing units (CPUs), graphics processing units (GPUs), cryptographic processors, server processors, or any other suitable processing device. For example, processing device 902 may include security processor 126 and separate processors included in ME 108 and IE 112 of microcloud 102. Computing device 900 may include memory 904, which itself may include one or more memory devices such as volatile memory (e.g., dynamic random access memory (DRAM)), non-volatile memory (e.g., read-only memory (ROM)), flash memory, solid-state memory, SES, and / or hard disk drives. For example, memory 904 may include firmware storage device 140 and main storage device 152 of microcloud 102.

[0059] In some embodiments, computing device 900 may include communication chip 912 (e.g., one or more communication chips). For example, communication chip 912 may be included in the NIC / switch 120 of microcloud 102. For example, communication chip 912 may be configured to manage wireless communication for transmitting data to and from computing device 900. The term "wireless" and its derivatives can be used to describe circuits, devices, systems, methods, techniques, communication channels, etc., that can transmit data using modulated electromagnetic radiation through a non-solid medium. This term does not imply that the associated devices do not contain any wiring, although in some embodiments they may not contain wiring.

[0060] The 912 communication chip can implement any of a variety of wireless standards or protocols, including but not limited to Wi-Fi (IEEE 802.11 family), IEEE 802.16 standards (e.g., IEEE 802.16-2005 amendments), Long Term Evolution (LTE) projects, and any modifications, updates, and / or revisions (e.g., Advanced LTE projects, Ultra Mobile Broadband (UMB) projects (also known as "3GPP2"), etc.). IEEE 802.16 compliant Broadband Wireless Access (BWA) networks are commonly referred to as WiMAX networks, an acronym for Global Microwave Access Interoperability, which is a certification mark for products that have passed IEEE 802.16 standard compliance and interoperability testing. The 912 communication chip can operate according to Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), High Speed ​​Packet Access (HSPA), Evolved HSPA (E-HSPA), or LTE networks. The communication chip 912 can operate according to Enhanced Data GSM Evolution (EDGE), GSM EDGE Radio Access Network (GERAN), Universal Terrestrial Radio Access Network (UTRAN), or Evolved UTRAN (E-UTRAN). The communication chip 912 can operate according to Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Digital Enhanced Cordless Communication (DECT), Evolved Data Optimization (EV-DO) and its derivatives, as well as any other wireless protocol designated as 3G, 4G, 5G, and above. In other embodiments, the communication chip 912 can operate according to other wireless protocols. The computing device 900 may include an antenna 922 to facilitate wireless communication and / or receive other wireless communications (such as AM or FM radio transmissions).

[0061] In some embodiments, the communication chip 912 can manage wired communications such as electrical, optical, or any other suitable communication protocol (e.g., Ethernet). As described above, the communication chip 912 may include multiple communication chips. For example, a first communication chip 912 may be dedicated to short-range wireless communications such as Wi-Fi or Bluetooth, and a second communication chip 912 may be dedicated to long-range wireless communications such as Global Positioning System (GPS), EDGE, GPRS, CDMA, WiMAX, LTE, EV-DO, or others. In some embodiments, the first communication chip 912 may be dedicated to wireless communications, and the second communication chip 912 may be dedicated to wired communications.

[0062] The computing device 900 may include a battery / power circuit 914. The battery / power circuit 914 may include one or more energy storage devices (e.g., batteries or capacitors) and / or circuits (e.g., AC line power) for coupling components of the computing device 900 to an energy source separate from the computing device 900.

[0063] The computing device 900 may include a display device 906 (or a corresponding interface circuit as described above). For example, the display device 906 may include any visual indicator, such as a head-up display, computer monitor, projector, touch screen display, liquid crystal display (LCD), light-emitting diode display, or flat panel display.

[0064] The computing device 900 may include an audio output device 908 (or a corresponding interface circuit as described above). For example, the audio output device 908 may include any device that generates audible indicators, such as a speaker, headphones, or earphones.

[0065] The computing device 900 may include an audio input device 924 (or a corresponding interface circuit as described above). The audio input device 924 may include any device that generates signals representing sound, such as a microphone, microphone array, or digital musical instrument (e.g., a musical instrument with a Musical Instrument Digital Interface (MIDI) output).

[0066] The computing device 900 may include a Global Positioning System (GPS) device 918 (or a corresponding interface circuit as described above). As is known in the art, the GPS device 918 can communicate with a satellite-based system and can receive the location of the computing device 900.

[0067] The computing device 900 may include other output devices 910 (or corresponding interface circuitry as described above). Examples of other output devices 910 may include audio codecs, video codecs, printers, wired or wireless transmitters for providing information to other devices, or additional storage devices.

[0068] The computing device 900 may include other input devices 920 (or corresponding interface circuitry as described above). Examples of other input devices 920 may include an accelerometer, a gyroscope, an image capture device, a keyboard, a cursor control device such as a mouse, a stylus, a touchpad, a barcode reader, a quick-response (QR) code reader, any sensor, or a radio frequency identification (RFID) reader.

[0069] Although specific examples of trusted execution environments (such as ME 108 and IE 112) are discussed herein, this is for illustrative purposes only, and the embodiments disclosed herein can be implemented using any desired trusted partition or environment (e.g., SGX or SMM mode).

[0070] In some embodiments of the MicroCloud 102, the ME 108, IE 112, security processor 126 (e.g., using SGX and / or TXT), SES 156, boot protection component 160, and CIT agent 130 can be used together to ensure that the firmware of the MicroCloud 102 platform and the OS bootloader operation for the MicroCloud 102 are protected (e.g., by ME 108 and IE 112) and that the SES-KEK 114 (and any other KEK) is stored and protected (e.g., by ME 108 and IE 112). The result is trusted and verified booting and hardware-protected, authenticated key access.

[0071] In some embodiments of the MicroCloud 102, the ME 108, IE 112, security processor 126 (e.g., using SGX), UEFI secure boot (where the firmware inspection system bootloader of the MicroCloud 102 is signed with a key authorized by a database contained in the firmware), security fuse (where the key required for booting (e.g., an initial set of public key hashes) is permanently burned into the fuse in the hardware to provide a hardware root of trust), secure encapsulation (where encapsulation techniques that do not allow the exposure of keys stored in the security fuse) and secure eMMC / storage (e.g., using a storage device with rollback protection in the eMMC, such as a replay protected memory block (RPMB)) can be used together to ensure that the MicroCloud 102 platform is booted and operable in a trusted environment, ensuring that configuration information exposed as a pseudo USB (or PCIe) device on the MicroCloud 102 can be securely accessed and updated, and that this configuration information is protected by the ME 108 and IE 112.

[0072] In some embodiments of the microcloud 102, the ME 108, IE 112, security processor 126 (e.g., using SGX and / or TXT), boot protection component 160, and CIT agent 130 may be used together to provide measured boot and trust chains to ensure that the proof of the microcloud 102 (including the ME 108, IE 112, and static and dynamic trust chains) is secure (e.g., not compromised) and to ensure that the out-of-band proof level can be exposed to external systems.

[0073] In some embodiments of the MicroCloud 102, ME 108 and IE 112 can be used together to host an embedded MicroCloud lifecycle manager. The embedded MicroCloud lifecycle manager can emulate a read-only device and expose the emulated device to the master server. Alternatively or additionally, the embedded MicroCloud lifecycle manager can emulate a logging device and expose the emulated device to the master server.

[0074] The various embodiments disclosed herein can provide one or more advantages over conventional methods. Some embodiments can provide hardware-enforced integrity and a chain of trust throughout the operating platform in environments where physical security cannot be asserted. Some embodiments can provide a secure and tamper-proof microcloud that remains secure, trusted, and proven at all stages of its platform lifecycle without requiring the physical security of a data center. Some embodiments can provide non-spoofable visibility into the operational state and proven level of trust of the microcloud. Some embodiments can allow NFV and SDN solutions based on an “open platform” to be securely deployed at remote, unmanned, and unprotected sites. This solution can enable numerous use cases for operators (e.g., MEC and 5G) that can benefit from remote, secure, distributed, and independent data processing. Some embodiments can support 5G and / or IoT.

[0075] The following paragraphs provide examples of the various embodiments disclosed herein.

[0076] Example 1 is a computing device comprising: a trusted execution environment; a basic input / output system (BIOS) for requesting a key encryption key (KEK) from the trusted execution environment; and a self-encrypting storage device (SES) associated with the KEK; wherein the trusted execution environment is configured to verify the BIOS and, after verifying the BIOS, provide the KEK to the BIOS, and the BIOS is configured to provide the KEK to the SES to unlock the SES for access by the trusted execution environment.

[0077] Example 2 can include the subject of Example 1, and can also specify that the trusted execution environment is the root of trust for the computing device.

[0078] Example 3 may include the subject matter of any of the examples in Examples 1-2, and may also specify that the trusted execution environment includes operations in a mode where the execution of the operating system on the computing device is suspended.

[0079] Example 4 can include the subject of any of Examples 1-3, and can also specify that the computing device is a micro-cloud.

[0080] Example 5 may include the subject of any of Examples 1-4, and may also specify that the trusted execution environment communicates with the remote management computing device to receive updates.

[0081] Example 6 may include the topics of Example 5, and may also specify a trusted execution environment including a lifecycle manager for communicating with remotely managed computing devices via a RESTful interface.

[0082] Example 7 can include the theme of Example 6, and can also specify a lifecycle manager to simulate a read-only device that exposes configuration parameters to another computing device.

[0083] Example 8 can include the theme of Example 6, and can also specify a lifecycle manager to simulate a read-only device that exposes logs or diagnostic information to another computing device.

[0084] Example 9 may include the subject of any of Examples 1-8, and may also include Virtualized Network Function (VNF) logic.

[0085] Example 10 may include the subject of any of Examples 1-9, and may also include virtual machine (VM) logic.

[0086] Example 11 is a networked computing system comprising: a microcloud, including a trusted execution environment, a basic input / output system (BIOS) for requesting a key encryption key (KEK) from the trusted execution environment, and a cryptographic storage device (SES) associated with the KEK, wherein the trusted execution environment provides the KEK to the BIOS, and the BIOS provides the KEK to the SES to unlock the SES for access by the trusted execution environment; and a microcloud management center that is remote from the microcloud and communicates with the trusted execution environment.

[0087] Example 12 may include the subject of Example 11, and may also specify that the networked computing system is a mobile edge computing (MEC) system.

[0088] Example 13 may include the subject of any of Examples 11-12, and may also specify that the networked computing system is a fifth-generation mobile network (5G) system.

[0089] Example 14 may include the subject of any of Examples 11-13, and may also include multiple microclouds communicating with the microcloud management center.

[0090] Example 15 may include the subject of any of Examples 11-14, and may also specify that the trusted execution environment is the operator's root of trust.

[0091] Example 16 may include the subject of any of Examples 11-15, and may also specify that the trusted execution environment is the manufacturer's root of trust.

[0092] Example 17 may include the subject of any of Examples 11-16, and may also specify that the trusted execution environment receives updated images from the Weiyun Management Center while the Weiyun operating system continues to execute.

[0093] Example 18 is a method for secure storage access, comprising: verifying the basic input / output system (BIOS) of a computing device via a trusted execution environment; in response to verifying the BIOS, providing the BIOS with a key encryption key (KEK) for a self-encrypting storage device (SES) of the computing device by the trusted execution environment; and providing the KEK to the SES via the BIOS to unlock the SES.

[0094] Example 19 may include the topic of Example 18, and may also specify that SES includes hard drives.

[0095] Example 20 may include the subject of any of Examples 18-19, where the platform firmware is stored in the SES.

[0096] Example 21 is one or more non-transitory computer-readable media having instructions stored thereon, the instructions being executed by the basic input / output system (BIOS) of a computing device to cause the computing device to perform the following actions: request a key encryption key (KEK) for a self-encrypting storage device (SES) of the computing device; receive the KEK from the trusted execution environment of the computing device in response to verification by the BIOS; and provide the KEK to unlock the SES.

[0097] Example 22 may include the subject of Example 21, and may also specify that the SES is partitioned and provide a key to unlock the SES, including providing a key to decrypt the partition of the SES associated with KEK.

[0098] Example 23 may include the subject of any of the examples 21-22, and may also specify that firmware configuration information is stored in SES.

[0099] Example 24 may include the subject of any of Examples 21-23, and may also specify that SES uses KEK to unlock the Media Encryption Key (MEK) and that MEK encrypts the data stored in SES.

[0100] Example 25 may include the subject of any of Examples 21-24, and may also specify that the computing device is an edge server in a mobile edge computing (MEC) network.

[0101] Example 26 is a computing device comprising: a trusted execution environment; a BIOS for requesting a KEK from the trusted execution environment; and a SES associated with the KEK; wherein the trusted execution environment is configured to verify the BIOS and, after verifying the BIOS, provide the KEK to the BIOS, and the BIOS provides the KEK to the SES to unlock the SES for access by the trusted execution environment.

[0102] Example 27 may include the subject of Example 26, and may also specify trusted execution environments including ME and / or IE.

[0103] Example 28 may include the subject of any of Examples 26-27, and may also specify that the trusted execution environment includes SMM.

[0104] Example 29 may include the subject of any of Examples 26-28, and may also specify that the computing device is a micro-cloud.

[0105] Example 30 may include the subject of any of Examples 26-29, and may also specify that the computing device communicates with the micro-cloud management center.

[0106] Example 31 may include the theme of any of Examples 26-30, and may also include a lifecycle manager.

[0107] Example 32 may include the subject of Example 31, and may also specify a lifecycle manager to simulate a read-only device that exposes configuration parameters to another computing device.

[0108] Example 33 may include the subject of any of Examples 31-32, and may also specify a lifecycle manager to simulate a read-only device that exposes logs or diagnostic information to another computing device.

[0109] Example 34 may include the subject of any of Examples 26-33, and may also specify that the computing device performs one or more VNFs.

[0110] Example 35 may include the subject of any of Examples 26-34, and may also specify that the computing device includes one or more workload VMs.

[0111] Example 36 is a networked computing system that includes any of the examples in Examples 26-35.

[0112] Example 37 may include the subject of Example 36, and may also specify that the networked computing system is an MEC system.

[0113] Example 38 may include the subject of Example 36, and may also specify that the networked computing system is a 5G system.

[0114] Example 39 is a method for secure storage access, comprising: verifying the BIOS of a computing device by a trusted execution environment (TEA); in response to verifying the BIOS, providing the BIOS with a keyless access key (KEK) for the storage excision device (SES) of the computing device by the TEA; and providing the SES with the KEK by the BIOS to unlock the SES.

[0115] Example 40 may include the subject of Example 39, and may also specify that the computing device is any of the computing devices in Examples 1-10 or Examples 26-35.

[0116] Example 41 is an apparatus including means for performing a method of any of the examples in Examples 18-20, any of the examples in Examples 39-40, any of the examples in Examples 43-45, or any other method disclosed herein.

[0117] Example 42 is one or more computer-readable media (e.g., non-transitory computer-readable media) having instructions stored thereon, the instructions causing the computing device to perform any of the methods of Examples 18-20, any of Examples 39-40, any of Examples 43-45, or any other method disclosed herein in response to execution by one or more processing devices of the computing device.

[0118] Example 43 is a method for operating a microcloud, including: booting a microcloud remotely from a data center, wherein the microcloud boot cannot be tampered with by software executed by the microcloud's operating system; and receiving data from a personal mobile computing device at the microcloud.

[0119] Example 44 may include the subject of Example 43, and may also include: detecting an attempt to tamper with the hardware of the cloud; and interrupting the boot process in response to detecting the attempt to tamper with the hardware of the cloud.

[0120] Example 45 may include the subject matter of any of the examples in Examples 43-44, and may also include virtualized network functions (VNFs) performed by the microcloud using data received at the microcloud.

[0121] Example 46 is a cloud computing environment, which includes: a security processor, a BIOS communicating with the security processor, an ME and an IE communicating with the BIOS, and a SES communicating with the BIOS, wherein the BIOS requests a key encryption key (KEK) from the IE, the IE is used to verify the BIOS and provides the KEK to the BIOS after verifying the BIOS, the BIOS provides the KEK to the SES to unlock the SES for access by the IE, and the security processor runs a virtual process after the IE accesses the SES.

[0122] Example 47 may include the subject of any of Examples 1-42, and may also specify that the trusted execution environment includes processing resources, which are hardware and software isolated from the execution of the operating system on the computing device.

Claims

1. A server system that can be used in conjunction with at least one remote cloud-based computer system, management-related logic, at least one processing resource, and at least one network, said server system comprising: Non-volatile storage hardware associated with at least one encryption key (EK), said at least one EK being encrypted using at least one key encryption key (KEK), said non-volatile storage hardware being used to store data, said data stored in said non-volatile storage hardware being encrypted based on said at least one EK, said data including operating system code; Hardware circuitry for decrypting / encrypting one or more corresponding portions of the data based on the at least one EK when one or more corresponding portions of the data are respectively read from and written to the non-volatile storage hardware. Computing hardware for performing at least one boot operation based on at least a portion of the operating system code read from the non-volatile storage hardware, the computing hardware also for performing at least one workload associated with at least one operating system instantiation; and Network hardware for communicating with the at least one remote cloud-based computer system via secure data exchange and with the management-related logic via the at least one network; in: The at least one KEK is obtained in at least a partial response to at least one request for the at least one processing resource in order to generate the at least one EK; The at least one processing resource is hardware and / or software that is at least partially isolated from the execution of the operating system code; The management-related logic is used in connection with patching and installing at least one software update for at least the server system and the at least one remote cloud-based computer system, at least in part. The server system and / or the at least one remote cloud-based computer system may be configured to provide diagnostic and / or log-related data to the management-related logic for use in conjunction with an application programming interface (API) for monitoring and / or managing the server system and / or the at least one remote cloud-based computer system; and The at least one remote cloud-based computer system may be configured to execute at least one virtual machine-related and / or container-related workload.

2. The server system as described in claim 1, wherein: The at least one network includes the Internet; and The at least one workload associated with the instantiation of the at least one operating system includes multiple workloads executed in association with multiple virtual machines and / or containers.

3. The server system as described in claim 1 or 2, wherein: The server system includes at least one mobile edge computing (MEC) server to perform the plurality of workloads; and The at least one MEC server at least partially implements the fifth-generation mobile network (5G) protocol functionality.

4. The server system as described in any one of claims 1-3, wherein: The management-related logic is at least partially located away from the server system.

5. The server system as described in any one of claims 1-4, wherein: The server system includes a platform trust root component for controlling access to the non-volatile storage hardware.

6. A networked computing system for use in association with at least one network, the networked computing system comprising: At least one remote cloud-based computer system; Management-related logic; At least one processing resource; as well as At least one server system, including: Non-volatile storage hardware associated with at least one encryption key (EK), said at least one EK being encrypted using at least one key encryption key (KEK), said non-volatile storage hardware being used to store data, said data stored in said non-volatile storage hardware being encrypted based on said at least one EK, said data including operating system code; Hardware circuitry for decrypting / encrypting one or more corresponding portions of the data based on the at least one EK when one or more corresponding portions of the data are respectively read from and written to the non-volatile storage hardware. Computing hardware for performing at least one boot operation based on at least a portion of the operating system code read from the non-volatile storage hardware, the computing hardware also for performing at least one workload associated with at least one operating system instantiation; and Network hardware for communicating with the at least one remote cloud-based computer system via secure data exchange and with the management-related logic via the at least one network; in: The at least one KEK is obtained in at least a partial response to at least one request for the at least one processing resource in order to generate the at least one EK; The at least one processing resource is hardware and / or software that is at least partially isolated from the execution of the operating system code; The management-related logic is used to associate with at least partially patching and installing at least one software update for the at least one server system and the at least one remote cloud-based computer system; The at least one server system and / or the at least one remote cloud-based computer system may be configured to provide diagnostic and / or log-related data to the management-related logic for use in conjunction with an application programming interface (API) for monitoring and / or managing the at least one server system and / or the at least one remote cloud-based computer system; and The at least one remote cloud-based computer system may be configured to execute at least one virtual machine-related and / or container-related workload.

7. The networked computing system as described in claim 6, wherein: The at least one network includes the Internet; and The at least one workload associated with the instantiation of the at least one operating system includes multiple workloads executed in association with multiple virtual machines and / or containers.

8. The networked computing system as described in claim 6 or 7, wherein: The at least one server system includes at least one mobile edge computing (MEC) server to perform the plurality of workloads; and The at least one MEC server at least partially implements the fifth-generation mobile network (5G) protocol functionality.

9. The networked computing system as described in any one of claims 6-8, wherein: The management-related logic is at least partially located away from the at least one server system.

10. The networked computing system as described in any one of claims 6-9, wherein: The at least one server system includes a platform trust root component for controlling access to the non-volatile storage hardware.

11. The networked computing system as described in any one of claims 6-10, wherein: The at least one server system includes multiple server systems.

12. A method implemented using a server system, said server system being used in association with at least one remote cloud-based computer system, management-related logic, at least one processing resource, and at least one network, said server system including non-volatile storage hardware, hardware circuitry, computing hardware, and network hardware, said method comprising: When one or more corresponding portions of data are read from and written to the non-volatile storage hardware respectively, the one or more corresponding portions of the data are decrypted / encrypted based on at least one encryption key (EK), the data stored in the non-volatile storage hardware is encrypted based on the at least one EK, the data includes operating system code, the at least one EK is associated with the non-volatile storage hardware and is encrypted using at least one key encryption key (KEK); At least one boot operation is performed by the computing hardware based on at least a portion of the operating system code read from the non-volatile storage hardware; The computing hardware executes at least one workload associated with at least one operating system instantiation; as well as The network hardware is used to communicate with the at least one remote cloud-based computer system via secure data exchange and to communicate with the management-related logic via the at least one network; in: The at least one KEK is obtained in at least a partial response to at least one request for the at least one processing resource in order to generate the at least one EK; The at least one processing resource is hardware and / or software that is at least partially isolated from the execution of the operating system code; The management-related logic is used to associate with at least partially patching and installing at least one software update for the server system and the at least one remote cloud-based computer system; The server system and / or the at least one remote cloud-based computer system may be configured to provide diagnostic and / or log-related data to the management-related logic for use in conjunction with an application programming interface (API) for monitoring and / or managing the server system and / or the at least one remote cloud-based computer system; and The at least one remote cloud-based computer system may be configured to execute at least one virtual machine-related and / or container-related workload.

13. The method of claim 12, wherein: The at least one network includes the Internet; and The at least one workload associated with the instantiation of the at least one operating system includes multiple workloads executed in association with multiple virtual machines and / or containers.

14. The method of claim 12 or 13, wherein: The server system includes at least one mobile edge computing (MEC) server to perform the plurality of workloads; and The at least one MEC server at least partially implements the fifth-generation mobile network (5G) protocol functionality.

15. The method according to any one of claims 12-14, wherein: The management-related logic is at least partially located away from the server system.

16. The method according to any one of claims 12-15, wherein: The server system includes a platform trust root component for controlling access to the non-volatile storage hardware.

17. One or more computer-readable media storing instructions that, when executed by one or more machines, cause to perform the method according to any one of claims 12 to 16.

18. A computer program product comprising instructions that, when executed by one or more machines, cause the one or more machines to perform the method according to any one of claims 12 to 16.

Images