Surrounding a secure memory enclave from the context of a process container

Abstract

Memory is partitioned and isolated in container-based memory enclaves. Container-based memory enclaves have provable security guarantees. During provisioning of a container-based memory enclave from a container image, a claimed link in the container of memory addresses to the enclave is modified to verifiably link to actual memory addresses of the host, such as a partitioned memory enclave. In some instances, an enclave attestation report can be verified without sending a corresponding attestation request to a remote attestation service without end-to-end attestation between the container and a remote attestation service for each new attestation request based on prior attestation from one or more earlier container attestation reports of similar containers.

Description

Background Technology

[0001] Computer technology has evolved to the point where computers are now ubiquitous, impacting almost every industry and enabling the storage and processing of different types of data.

[0002] To securely store and process data, some operating systems and computer hardware have been configured to provide memory partitioning. Memory partitioning is a method of isolating the processing and storage of data within a single computing system and / or within a distributed network of multiple computing systems.

[0003] For example, a system can isolate "security-critical" data, such as encryption keys, user identities, user credentials, and other sensitive data, from other computational processes and less sensitive data in various isolated regions of memory, referred to herein as enclaves. The computing industry sometimes refers to these types of isolated computing environments as "trusted execution" environments and "confidential computing" environments.

[0004] Techniques for dividing memory into enclosed regions typically exist in a variety of forms. One example is hardware-based partitioning implemented by Intel's SGX, ARM Holdings TrustZone, and other companies. Another example is operating system- or hypervisor-based partitioning, such as Virtualization-Based Security (VBS).

[0005] Virtual Storage Service (VBS) uses a hypervisor or another resource management layer to create additional memory partitions within a computing system to isolate and protect security-critical data placed therein. Using VBS, multiple Virtual Trust Levels (VTLs) can be defined, which can be used to provide isolation from user mode and kernel mode. For example, a typical operating system might run in a first VTL (e.g., VTL0) to support existing user-mode and kernel-mode drivers, applications, services, etc., while the additional memory partitions could run in a second VTL (e.g., VTL1) within the same system to support isolated user mode (IUM) and a secure kernel (SK).

[0006] Security boundaries between VTLs can be enforced by the hypervisor or other management layers to prevent VTL0 from accessing VTL1, for example, by creating isolated memory regions within the process of mapping memory into VTL1, and VTL0 will not be able to access the isolated memory regions. This isolated memory region is an enclosing region. This enclosing region provides a way to perform secure, provable computation in an untrusted environment. Therefore, even if a process running from VTL1 is attacked in user mode or kernel mode, VTL1 can protect the contents of the enclosing region.

[0007] Hardware-based partitioning is another general type of memory partitioning that can be used to create isolated enclosed regions in memory. An example of hardware partitioning includes Intel's Security Guard Extensions (SGX), which incorporates processor instruction sets that allow user-mode code to allocate private memory regions, including enclosed regions, in a manner similar to VBS.

[0008] It should be understood that, whether protected by VBS or other hardware-based enclosing technologies, the enclosing zone typically exists within the context of the host process so that any interaction with the enclosing zone is subject to the existing protections of the host process.

[0009] One advantage of partitioning (especially when using virtualization based on virtual machines) is that it enables the division of data and applications in a way that allows for high-density deployment of server resources and cloud computing.

[0010] Container-based virtualization (sometimes called namespace-based virtualization) is a form of partitioning that can provide greater compatibility and increased density for scaled services. This is beneficial because greater compatibility reduces software development costs, while higher density can generate more revenue with relatively similar costs for facilities, labor, and hardware.

[0011] Containers and container-based virtualization can also be used to provide isolated, resource-controlled, and portable operating environments. For example, when a software application runs within a container, it can execute without affecting the rest of the system, and the system does not affect the application. Containers can be application-specific or can provide runtimes for multiple applications, offering additional operating system functions and services (such as I / O capabilities, security, etc.).

[0012] However, while enclosing applications and services in regular containers offers many benefits, including increased flexibility and portability, traditional container security boundaries are vulnerable to some extent. One reason for this is that existing container technologies rely on the security of the underlying operating system rather than any specific hardware security guarantees, and the intentionally flexible architecture of existing containers to facilitate application compatibility leads to gaps in how data within the container is protected. In this respect, containers cannot provide the same level of provable security guarantees as the aforementioned VBS and hardware partitioning enclosing techniques.

[0013] However, there are many emerging container scenarios in IoT and database workloads that are under development, and their containerized applications require secure storage solutions. Unfortunately, however, no system has yet been created to provide this practicality due to several challenges, particularly in providing such secure storage in an efficient and scalable manner. These shortcomings effectively limit the widespread adoption of containers in distributed systems, especially where enhanced security is required.

[0014] For example, no operating system currently provides / enforces secure memory allocation, especially in the context of robust monitoring and verification for container security scenarios. The short lifecycle of containers also makes the use of configuration, monitoring, and end-to-end secure key management and verification techniques used in other types of partitioning technologies (such as those used in VBS and hardware partitioning) somewhat prohibitive.

[0015] Therefore, there remains a need for systems and methods capable of partitioning and isolating memory in a secure and provable manner, and even more specifically, in ways that can leverage the functional advantages of containers. In some embodiments, security and isolation can be achieved by using a more heavyweight form of virtualization, such as virtual machines. In some embodiments, some hypervisor-based container implementations may require enclosing regions. In some embodiments, more heavyweight virtualization techniques are not necessary, as proofs can be used to validate lightweight container images, and container-based virtualization techniques (with less isolation) can be used to host security-intensive workloads only within memory enclosing regions.

[0016] However, it will be noted that the subject matter claimed herein is not limited to embodiments that must address any drawbacks associated with existing systems or operate only in environments such as those described above. Rather, this background is provided merely to illustrate an exemplary technical field in which some of the embodiments described herein can be practiced. Summary of the Invention

[0017] The disclosed embodiments are directed to embodiments for supplying containers including container-based memory enclosing regions, with provable security guarantees. The disclosed embodiments also are directed to embodiments for demonstrating security guarantees for the supplied containers including container-based memory enclosing regions.

[0018] The disclosed embodiments provide technical advantages over existing container supply technologies by providing new systems and methods for supplying containers with secure memory isolation in the form of container-based memory enclosed regions and by providing a proof infrastructure for effectively managing proofs of security assurances for containers in an efficient and scalable manner.

[0019] Some embodiments include methods and systems for creating container-based memory enclosed regions. In these embodiments, a computing system identifies a container image with a security component used to authenticate a specific security configuration used by a host system running in a first security domain, the security component being stored at a memory address of the host system. Note that in some embodiments, the virtual machine or container host implements a host system including VTL1 and VTL0 memories.

[0020] The computing system then uses the container image to instantiate a new container in a second security domain, different from the first security domain. The new container is configured to utilize the host system's enclosed memory based on a security component stored at an address on the host system. The new container includes a copy of the security component with a specific memory address, which is a claimed link from the container to the memory address of the security component stored on the host system.

[0021] Additionally, during or after the instantiation of a new container, the computing system modifies the claimed link from the container to a specific memory address of a security component stored on the host system, such that the claimed link from the container to the memory address is modified to verifiably link the container to the memory address on the host system, thereby creating a provable state for the container.

[0022] Some embodiments also include methods and systems for performing proofs against container-based memory enclosed regions. In these embodiments, the computing system identifies one or more containers residing in a security domain different from a first security domain of the host system, each of the one or more containers being configured to reference the enclosed region memory of the host system, and uses a security component to prove a specific security configuration against the enclosed region memory, the security component being stored at a memory address of the host system and linked to the memory address of the host system through one or more references to the security component at the one or more containers.

[0023] The computing system then obtains a proof report from a remote proof service regarding the security configuration of one or more containers, based on the security component. In some instances, this is a single proof report, rather than multiple proof reports. After receiving the proof report from the remote proof service, the computing system then receives a request to prove the security guarantee for a specific container within the one or more containers. The computing system then proves the security guarantee for the specific container based on the proof report received prior to receiving the proof request, without requiring new end-to-end proofs from the container and the remote proof service for the new request.

[0024] This summary is provided in a simplified form to introduce a series of concepts further described in the following detailed description. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0025] Additional features and advantages will be set forth in the following description and will be apparent in part from the description, or may be learned by practice of the teachings herein. The features and advantages of the invention may be realized and obtained by means of the means and combinations particularly pointed out in the appended claims. The features of the invention will become more apparent from the following description and the appended claims, or may be learned by practice of the invention as described below. Attached Figure Description

[0026] To describe how the above and other advantages and features can be obtained, a more specific description of the subject matter briefly described above will be presented with reference to specific embodiments illustrated in the accompanying drawings. It should be understood that these drawings depict only typical embodiments and are therefore not to be considered as limiting the scope; the embodiments will be described and explained with additional specificity and detail using the drawings, wherein:

[0027] Figure 1 The diagram illustrates a computing environment in which a key supply service and a proof service communicate with a computing system that provides operations in user mode in a first domain (e.g., VTL0) and in isolated user mode using a secure kernel, and that isolated memory enclosed regions operate in a second domain (e.g., VTL1).

[0028] Figure 2 The illustration shows an embodiment of a system design overview that utilizes containers and enclosing regions with provable states and includes container management services, proof services, and key supply services.

[0029] Figure 3 The illustration depicts a computing system configured to include and / or implement aspects of the disclosed embodiments.

[0030] Figure 4 Another computing system is illustrated, which is configured to include and / or implement aspects of the claimed invention having a key supply service and proof service infrastructure.

[0031] Figure 5 The illustration shows an embodiment of a flowchart having multiple actions associated with a method for supplying a container, according to the disclosed embodiments.

[0032] Figure 6 An embodiment is shown with a flowchart of multiple actions associated with a method for demonstrating the safety guarantee of a container, according to the disclosed embodiments. Detailed Implementation

[0033] The disclosed embodiments are directed to embodiments for supplying containers including container-based memory enclosing regions, with provable security guarantees. The disclosed embodiments also are directed to embodiments for demonstrating security guarantees for the supplied containers including container-based memory enclosing regions.

[0034] In some instances, the disclosed embodiments offer technical advantages over existing container provisioning and enclosing technologies by providing new systems and methods for supplying containers as container-based memory enclosing regions and by providing a proof infrastructure for efficiently and scalably managing proofs of security assurances for containers.

[0035] Compared to traditional VBS and traditional hardware-based enclosing regions, the creation of container-based enclosing regions provides even greater isolation for memory partitioning. For example, it's important to note that traditional enclosing regions, whether protected by VBS or other hardware-based enclosing techniques, typically exist within the context of the host process, ensuring that any interaction with the enclosing region is protected by the existing host process protection. However, while normal operating system processes do not typically possess strong isolation mechanisms, additional levels of isolation can be added to the system by encapsulating enclosing host processes within the context of a process container, as described in this paper. The use of container-based enclosing regions can also be monitored and verified to provide proven security guarantees in an effective and scalable manner.

[0036] The additional benefits and functionality of the disclosed embodiments will be described below, including the provisioning and monitoring of container-based enclosing regions, and demonstrating security guarantees for container-based enclosing regions in an efficient and scalable manner.

[0037] First, let's turn our attention to the diagram illustrating computing environment 100. Figure 1 The computing environment 100 includes a computing system 110 configured to implement aspects of the disclosed embodiments. For example, the computing system 110 includes a container management service 112 configured to provision containers 114 and container-based memory enclosing regions 116. The computing system 110 is also configured to implement the container management service 112 and containers 114 in user mode operating in a first domain (e.g., operating system VTL0) and to implement the isolated container-based memory enclosing region 116 and a corresponding secure kernel in a second domain (e.g., operating system VTL1).

[0038] The management procedure 120 or other management layer is configured to implement a security boundary between the first domain (VTL0) and the second domain (VTL1). The TPM (Trusted Platform Module) 130 is configured to prove its status to the authentication service 140. In some instances, this is achieved by providing an authentication endorsement key (EK) supplied by the TPM manufacturer, such as a key supply service 150 or another key supply service.

[0039] During use, the host running the TPM generates an Identity Authentication Key (AIK), which can be used to sign TPM claims in the AIK certificate or other reports that can later be used for integrity protection and to verify the host's startup status (e.g., to prove the security assurances of the TPM primitives). In response to a request for a verification report, the AIK certificate is initially provided to the TPM130 and / or computing system110. The AIK certificate is provided by a verification service or other certificate service in response to verifying and proving the co-existence of the authentication endorsement key (EK) provided by the TPM and AIK.

[0040] The proof service can also verify or prove security guarantees for a specific container-based enclosed region (e.g., prove its isolation security guarantees and primitives). For example, the host measures the system boot chain and the hash values ​​of the operating system binaries in the TPM Platform Configuration Register (PCR), digitally signs these using the AIK, and these can be used to confirm and prove the enclosed region binaries in a proof report verified by the proof service. During secure kernel boot, the system identity key (IDK) is generated and measured in the TPM. In some embodiments, the boot order is also measured as part of the system boot chain.

[0041] After startup, the encircling zone requests a proof report for the container from the proof service. Optionally, the encircling zone can add a key to the container proof report, which it can share with its clients. To implement this key, the encircling zone first generates a key pair and digitally signs the public key of the encircling zone key pair using the system identity key (IDK) from the encircling zone proof request sent to the proof service (e.g., proof service 140 or another proof service), along with the host TPM startup log and PCR. All of this is signed with an AIK key and AIK certificate. Once the encircling zone public key is added to the container proof report, the proof report can be considered an encircling zone proof report, and the key can be used for secure communication with the encircling zone.

[0042] The Proof Service verifies that the TPM boot log is correctly signed with the AIK key / certificate and that the boot chain measured in the PCR matches the TPM boot log. It also verifies that the IDK key in the boot log matches the IDK key used to sign the enclosed zone public key in the proof request. The Proof Service further ensures that the IDK key in the boot log matches the IDK key used to sign the enclosed zone public key in the proof request. If so, the Proof Service generates a signed proof report with the system's health status. This signed report verifies the enclosed zone proof report and includes the enclosed zone's public key and the current timestamp, thus proving the security guarantee of the container-based enclosed zone.

[0043] Figure 2 The diagram illustrates a design overview of a system utilizing containers and enclosing regions with provable states, and including container management services, proof services, and key supply services. The relationships between these components have been described above and will be further explained from the references. Figure 3 and Figure 4 This becomes more apparent in the following description.

[0044] Note that the container management service is configured to provision, start, monitor, and maintain the state of all containers running on the system, thereby providing a scalable infrastructure for creating any N containers.

[0045] Each container is also responsible for creating, initializing, and allocating its own bounding area.

[0046] Enclosures and containers are bound together via the host OS kernel, which is tracked by the container management service. While this binding is trusted and provable within the context of the host operating system, it does not maintain the security boundaries of the enclosure.

[0047] The proof service can be used to ensure that the appropriate enclosed code is running within any given enclosed region.

[0048] In some embodiments, the kernel can report a system / platform proof report to a proof service, and thus verify the integrity of the platform used to create the enclosed region (VBS, SGX, etc.). In some embodiments, the container adds the enclosed region public key to the system proof report, creating an enclosed region proof report. In some embodiments, a full proof is run on the enclosed region content, creating an enclosed region proof report.

[0049] Enclosures / containers are responsible for generating their own enclosure verification reports and providing these reports to the verification service (as described above). The verification service can coordinate with the container management service to provide verification to containers and the processes that interact with those containers.

[0050] Figure 3 and Figure 4The illustration depicts a computing system configured to include and / or implement aspects of the disclosed embodiments to supply and validate container-based enclosing regions. Figure 3 The system 300A is specifically related to the reference. Figure 5 The flowchart 500 shown and described corresponds to this, while Figure 4 System 300B specifically refers to Figure 6 The flowchart 600 shown and described corresponds to this.

[0051] As shown in the figures, the illustrated systems 300A and 300B include one or more hardware processors 310 and storage devices 320. It is worth noting that, for example, storage device 302 is generally illustrated as a bounded cylinder, which may correspond to a hard disk drive. However, it should be understood that storage device 320 is not limited to hard disk drive configurations. Instead, storage device 320 may include different types of independent and / or distributed storage devices for one or more computing systems and storage locations.

[0052] In some instances, storage device 320 includes a non-volatile storage device. In other instances, the storage device includes any combination of non-volatile and volatile storage devices. Storage device 320 may also include, for example, memory, which may include volatile memory and / or flash memory or other non-volatile memory.

[0053] In some instances, memory is used to store and implement partitioned memory, such as partitioned memory containers (e.g., new container 315) and other storage structures (e.g., container metadata 322, mapping table 324, container image 326, container image file (e.g., .dll 328 and security data 329)), as well as executable code and applications, including the OS (operating system) and kernel for computing systems 300A and 300B.

[0054] The storage may also include memory partitions, including VTL0 memory 380 and VTL1 memory 390. VTL0 memory 380 includes a first underlying memory domain used by the system OS to implement user mode and to provision containers. VTL0 memory may also store a mapping table (described in more detail below) to map the addresses of provisioned containers to corresponding container enclosing regions in the enhanced / isolated secure memory domain VTL1 memory 390, which includes isolated secure memory enclosing regions.

[0055] Storage device 320 also stores executable code and applications for instantiating or implementing other illustrated system components (e.g., mapper 330, container authentication service 340, container management service 350, memory manager 360, loader 370, key provisioning service 394), which are used to provision, monitor, load, or otherwise connect to containers or even remote systems, such as remote key provisioning service 395 and remote authentication service 396, via one or more network connections 399.

[0056] It should be understood that the illustrated separation of various system components is provided only for the purpose of facilitating the description of the disclosed embodiments, and therefore should not be construed as imposing any physical boundaries or relationships between the system components relative to the storage device or relative to each other, unless otherwise stated.

[0057] Regarding the above, it should be noted that there are imposed and enforced physical and / or virtual boundaries between the different domains VTL0 memory 380 and VTL1 memory 390, which are used accordingly to implement the system's user mode and isolated user mode.

[0058] For example, as described herein, one or more boundaries established between partitioned domains can be created and enforced during container provisioning. In some embodiments, this enforcement is maintained by a hypervisor. In other embodiments, another management layer is used to enforce and maintain partitions and memory isolation partitions created for different domains. In some instances, the container management service 340 identifies security / isolation boundaries between different containers. Security / isolation boundaries are enforced via hardware or a hypervisor (not shown).

[0059] It should be understood that, although in Figure 3 and Figure 4 Only two distinct memory partitions are shown, but by merging a single container in the first security domain (e.g., VTL0 memory 380) with the corresponding container-based enclosing partitions in the second security domain (e.g., VTL1 memory 390), any number of distinct partitions can exist. These partitions can also utilize / include any number of distinct security domains to support any number of containers established within the same and / or different security domains, such as, but not limited to, different trust levels of virtual trust levels for VBS.

[0060] Furthermore, although not shown, different partitions may also be contained in or exclusively based on hardware partitions, such as Intel’s SGX Enclosures technology, and any combination of hardware and virtual memory partitions for the containers contained therein.

[0061] Referring to different security domains, it should be understood that each security domain can be configured to adapt to different needs and preferences, and to facilitate container-based memory enclaves with different levels of security assurance for secure memory solutions with different expectations, including but not limited to existing and even yet-to-be-developed IoT, database, and enterprise workloads and storage scenarios.

[0062] In some instances not shown, the disclosed system isolates container-based memory enclosed regions within one, two, or more distinct security domains. Each distinct security domain comprises a different virtual security domain (e.g., VTL1, VTL2, etc.), has different security guarantees than the underlying host user-mode security domain (e.g., VTL0), and is implemented or distributed across one or more hardware storage devices (e.g., one or more drives, disks, racks, data centers, etc., in the same / shared set). Such a scenario can support multi-tenant implementations, where different tenants utilize the same backend container storage system and storage devices, but where each tenant has different security constraints and utilizes a different container image to supply container-based memory enclosed regions.

[0063] In some cases not shown, the disclosed system isolates the container-based memory enclosing region within one, two, or more distinct security domains, each with different security guarantees than the underlying host user-mode security domain, and each distinct security domain is physically isolated on different / physically separate and non-shared hardware storage devices (e.g., a different set of one or more drives, disks, racks, data centers, etc.). Such embodiments are particularly useful for distributed networks that utilize physical storage in different locations.

[0064] In some cases, the exposed system isolates multiple container-based memory enclosed regions within the same security domain, which is different from the underlying host user-mode security domain, where each of the multiple container-based memory enclosed regions is supplied from a common container image.

[0065] In some alternative and / or additional embodiments, at least two or more different container-based memory enclosing regions are supplied from at least two different corresponding container images.

[0066] like Figures 3 to 4 As reflected in the description and as noted above, the disclosed system includes a container management service 340. This container management service 340 is configured to provision new containers (e.g., new container 315) and monitor containers that have already been provisioned, along with their security configurations and storage regions.

[0067] Container authentication service 394 is also provided by system 300A / 300B. In some embodiments, container authentication service 394 is an interface that facilitates communication with one or more remote authentication services (e.g., remote authentication service 396).

[0068] Furthermore, since the enclosing region itself cannot easily discern the type of process it is running, because the process calling the enclosing region is controlled by another untrusted domain (e.g., VTL0), the remote certifying service 140, and sometimes the local container certifying service 394, provides an interface to the container management service 340 to coordinate with the enclosing region to certify what type of host process the given enclosing region is using. For example, if the enclosing region is running within the context of a process-isolated container, the certifying service (along with the platform certifying report and the enclosing region certifying report, as described above) can make a provable statement that the host process of the given enclosing region is isolated from the rest of the system.

[0069] In this way, the remote certification service 140, and sometimes the local container certification service 394, are configured to verify / certify certification reports provided by the system 300A / 300B and / or the enclosing container to certify the security guarantees of the system and / or the container-based memory enclosing region, as described above and in particular with reference to Figure 1 and Figure 2 As described.

[0070] In some cases, the container proof service 394 only exchanges information (e.g., proof reports, proof requests, verified proof reports, etc.) between system 300B and (multiple) remote proof services 396.

[0071] In other cases, the container proof service 394 is configured to store proof credentials and perform proofs for container-based memory enclosed area security guarantees, without interfaceing with a remote proof service for each proof request received for the enclosed area. In this way, proofs can be performed more efficiently to accommodate the ephemeral nature of containers and without requiring end-to-end proof between the enclosed area and the remote proof service for each proof request. This is particularly effective for locally verifying proof reports from multiple containers / enclosed areas all supplied from the same container image.

[0072] For example, in some cases, the container proof service 394 is configured to verify or prove security guarantees for a specific container-based enclosed region (e.g., prove its isolation security guarantees and primitives) without requiring new end-to-end verification of the enclosed region proof report for each new proof report sent for verification.

[0073] For example, this is possible by having the container proof service 394 store credentials including the AIK or other credentials received from the remote key supply service 395 and / or the remote proof service 396 to verify the encirclement proof report, and which can be used to verify the new encirclement proof report (from the earlier container-based encirclement or the new container-based encirclement) when it is determined that the new container-based encirclement report corresponds to or has a similar profile to the container-based encirclement report previously verified by the remote key supply service.

[0074] For example, by verifying that a new container-based enclosed zone report is signed using the same AIK or other credentials / security information received from a previous remote proof of the same or different container-based enclosed zones with the same security domain and provisioning profile (e.g., having a similar system boot chain in the TPM Platform Configuration Register (PCR), having the same IDK key, and / or being tied to the same underlying authentication endorsement key (EK)), it can be determined that the new container-based enclosed zone report corresponds to or has a profile similar to that of an earlier verified container-based enclosed zone report.

[0075] In other instances, this can be determined by identifying that a new container-based encirclement report is received from a new container supplied from the same container image that has the same security data 329 used to supply the previously supplied container and created a corresponding encirclement proof report verified by the remote proof service 140.

[0076] In some cases, the process of proving a new / guest container enclosing region supplied with the same image as the previous / host container enclosing region is performed by system 300A / B using local and / or remote container proof services 394 and local and / or remote key supply services, and includes the following: (1) the host generates a key (e.g., by using key supply service 394) or obtains a key (e.g., by using remote key supply service), which is sent to the new / guest enclosing region; (2) the new / guest enclosing region generates a proof report; (3) the new / guest enclosing region initiates a Diffie-Hellman key exchange process with the host; and (4) the new / guest enclosing region presents proof to the host enclosing region, such as by presenting the proof report to container proof service 340. The report (with key exchange data) includes information corresponding to an earlier verified proof report of the previous container enclosing zone, such as the host enclosing zone (5) the host begins the Diffie-Hellman key exchange process, (6) the host verifies the new / guest proof report, such as by using the container proof service 340, and this can be based on an earlier proof of a container supplied from the same container image, (7) the host sends key exchange information to the new / guest enclosing zone using key information provided by the key supply service 394, (8) the host and the guest enclosing zone complete the Diffie-Hellman key exchange, and (10) the host uses the key supply service 340 to encrypt the key to be sent to the guest enclosing zone using a shared key.

[0077] In such an embodiment, it is possible to utilize the local key provisioning service 394 and the container proof service 340 to verify a new / guest enclosed area enclosed area proof report supplied from the same container image previously supplied and proven by the remote authentication service.

[0078] In some embodiments, once a new container 315 is proven, it can generate reports locally for other containers or delegate the proof to other containers. For example, in some instances, these other delegating containers may have longer lifespans and thus behave like proxies. This allows, for example, the existence of numerous temporary containers on a given host system 300B, as well as proofs nested within different hierarchical structures of containers and delegating containers.

[0079] In some instances, this is based on container attributes (e.g., different container lifespans, different container types, different container locations, different container tenants, different container contents, different container risk profiles, different quality of service guarantees for different containers, container responsibilities (e.g., delegated or master container) and / or any other container attributes).

[0080] For example, a container with a longer lifespan and / or a higher risk level may need to prove one or more specific remote proof services, while a different container with a shorter lifespan and / or a lower risk level may only need to prove a different remote proof service that is closer to the system / container, or even prove a local container proof service (i.e., 394).

[0081] Therefore, in some cases, the system can access proofs from containers and deterministically route proofs to appropriate proof services based on the determined lifetime of the corresponding container (or any other attribute of the container(s)) that generated the proof. For example, upon receiving a subsequent container proof, the system can determine the attributes of the specific container associated with the subsequent container proof and then deterministically route the subsequent container proof to a remote service based on the attributes of the specific container, or alternatively, generate a proof report at least in part based on the attributes of the specific container without routing the subsequent container proof to a remote service. Since attributes can include the lifetime of the container, this can also include: the system analyzing that a first group of containers has a relatively longer lifetime than a second group of containers, wherein one or more container proofs associated with the first group of containers are routed to a remote service, while generating one or more proof reports with local proofs for each container in the second group of containers, including the subsequent container, for example, the subsequent container includes a relatively shorter lifetime than the first group of containers, and the second group of containers is not routed to a remote service.

[0082] Regarding the foregoing, it should be understood that proofs from the container can be proof requests (e.g., enclosing zone proof requests, container proof requests, proof reports, and / or other proofs). Furthermore, it will be understood that the attributes used to route proofs as described above can be container lifetime or any other container / enclosing zone attribute.

[0083] Now refer to Figure 5 The flowchart illustrates the process for supplying a container-based memory enclosing region to a container. As shown in the figure, Figure 5 The flowchart 500 includes multiple actions (actions 510, 520, and 530) that are associated with various methods for supplying containers according to the disclosed embodiments.

[0084] The illustrated first action (action 510) includes the system (e.g., system 300A) identifying a container image (e.g., container image 326) with a security component (e.g., a library file such as .dll 328) used to authenticate a specific security configuration used by a host system running on a first security domain (e.g., VTL0). In some cases, the container image is identified and loaded into memory (e.g., VTL0 memory 380) by a loader 370. The memory manager 360 identifies where containers are loaded and tracks supplied and decommissioned containers to effectively manage memory.

[0085] It is important to note that the security component of a container image can take many forms and is not necessarily a library file. Instead, the security component can include and be configured to contain any data (e.g., data blobs, data structures, unstructured data, etc.) with provable configuration information used to generate a bounding zone proof request or to contain information included in the bounding zone proof request. In some cases, the security component includes information identifying the security configuration profile of container image 326 or the isolation attributes of the bounding zone memory on which it is loaded.

[0086] For example, the security component will be loaded into a memory location on the host system, which may include a location within a bounded memory partition of the host system (e.g., within VTL1 memory 390). Although not required, container image 326 may also contain executable code or other security data 329, which, after being supplied, is decrypted using one or more keys provided by key supply service 394 and causes the executable code to be automatically instantiated within an isolated bounded memory partition (e.g., VTL1) of the host system.

[0087] It is worth noting that after the container is fully provisioned, information from the security component can be used to verify the security guarantees of the corresponding container-based memory enclosing region. It is also noted that in some instances, the security component will be loaded into the enclosing region memory partition (e.g., VTL1 memory 390) to further isolate and protect the security component from unwanted access by components / processes implemented in the underlying storage / security domain (e.g., VTL0 memory 380).

[0088] During the initial provisioning phase of a new container, the actual / verifiable memory address of the security component is not yet known because it is not specified by the container image. Therefore, the memory address used to update the mapping table and container metadata when the new container 315 is provisioned from container image 326 is merely a claimed memory address for the security component (this is an incorrect placeholder address), not the actual / verifiable address of the host system. This is why it is only referred to as the claimed memory address at this time.

[0089] During the initial provisioning phase of the container, the claimed memory address for the security component is recorded in a data structure such as mapping table 324 and / or container metadata.

[0090] It is important to note that mapping table 324 can take various forms and can be a single independent data structure or multiple distributed tables / structures. In some cases, mapping table 324 is created and maintained by mapper 330, which identifies different containers and their allocated storage locations within the system. Once created, mapping table 324 is referenced by container management service 340 and storage manager 360, enabling monitoring of new container 315 and other provisioned containers and interfacing with them.

[0091] After the container is provisioned, it accesses the security component via an address / pointer to the security component in the container metadata and / or mapping table to identify the security component information. The container uses this security component information to generate a bounding zone proof report. Therefore, if the address of the security component is not updated with the correct address, the container will not be able to access the information from the security component, nor will it be able to generate a bounding zone proof report with appropriate security guarantees for the container / bounding zone, and any / all attempts to prove these security guarantees will fail.

[0092] Furthermore, in some instances, computational processes such as paging operations may lead to changes in the memory location allocated to the container. To address this, mapping table 324 can be further updated to reflect changes in allocated memory. Additionally, the container can prove itself to proof service 394, or the container can be verified by a host memory enclosing region (e.g., VTL1) that verifies the container's integrity to match the container's code integrity (CI) policy, and, for example, causes the memory enclosing region to issue a new proof report without obtaining a remote proof from remote proof service 396. Furthermore, in this case, the host memory enclosing region acts as a delegate to remote proof service 396. Note that in some embodiments, the proof can be marked as metadata in the mapping table, and this can also be tracked by the storage manager so that the metadata may be marked as "dirty" by paging operations, and therefore the proof must be "refreshed" after each one. Therefore, in this embodiment, the memory range will be included in the proof report.

[0093] Therefore, in some embodiments, it is important that once the container is fully provisioned and the security component is finally loaded into the host system's memory (such as in the host system's enclosed memory partition), the memory address of the security component for the referenced container is updated.

[0094] As reflected in action 520, system 300A uses container image 326 to instantiate a new container 315 (which includes a new container enclosing region) in a second security domain (e.g., VTL1 memory 390) different from the first security domain (e.g., VTL0 memory 380) used to implement the host system's user-mode. Specifically, by being configured to utilize the host system's isolated enclosing region memory partition based on the configuration specified in a provably secure component (e.g., .dll 328), the new container is instantiated based on the container's enclosing region, and this results in the container being configured to reference and utilize the isolated enclosing region memory to store data and perform processes isolated from the host system's underlying user-mode memory.

[0095] Once provisioned, the new container 315 includes a copy of the security component with a specific memory address on the host system, and this copy is stored in an isolated enclosed memory partition on the host system it references. However, as mentioned above, based on the initial container image, and as reflected in mapping table 324 and / or container metadata, the current address provided or mapped by the new container 315 is merely a claimed link from the container to the memory address of the security component on the host system (because this address was unknown when the container image was first used to provision the new container).

[0096] This issue is particularly prominent and is related to the security components that use a single container image to supply multiple different containers and store / isolate these containers in the host's enclosed memory partition instead of in the VTL0 memory where the new container is first supplied.

[0097] To address this issue, the system accesses and modifies the claimed link (e.g., the security component's record / claimed physical memory address) so that the mapping link between the new container and the memory address in the enclosing memory partition will verifiably link the container to the correct memory address of the host system in the enclosing memory partition (Action 530).

[0098] This modification may also include one or more of the following: overwriting the claimed memory address of the security component at the new container with the actual memory address of the host system where the security component is actually stored; creating a link from the actual memory address of the host system where the security component is actually stored; changing the claimed address associated with the security component in mapping table 324 to the actual / verifiable address; overwriting or replacing the mapping table 324 with the claimed memory address of the security component with a new mapping table 324 having the correct address to the memory address of the security component; and creating a link or new pointer in mapping table 324 from the original claimed link / address to the actual verifiable physical address of the security component in the enclosing memory partition.

[0099] Modifications may also include, or follow, the creation of mapping tables and the use of metadata associated with the new container to add the memory addresses of security components in the enclosed memory partition to the mapping tables.

[0100] Once the memory address is changed, updated, or otherwise modified in the mapping table to point to the correct / verifiable memory location of the security component, the container can access it and generate a proof report with information based on the security component. Note that in some embodiments, the proof report is shared with the container management service 350 or a dependent party (Action 540). In some embodiments, VTL1 is able to monitor the status of the new container 315 and the status of the system 300B. In some instances, the container management service 350 is also able to monitor the container status and the system status. Monitoring the container status may include accessing and evaluating proof requests, evaluating proof reports, and / or monitoring update and write requests to the container and / or readdressing / redistribution of the container's enclosing memory.

[0101] If a given new container 315 or system 300B fails to prove or otherwise appears to be under attack, the container management service 350 may be requested to remove the new container 315, and / or such action may be taken proactively if it independently identifies such an attack (Action 550).

[0102] In some embodiments, VTL1 can monitor mapping tables 324 and prevent updates to map VTL1 memory to new containers 315 and similar entities if they fail to prove or are otherwise compromised. In some embodiments, additional notifications may be sent from VTL1 or other components to remote management entities, such as remote proof service 396.

[0103] Figure 6 The illustration shows an embodiment of a flowchart 600 having multiple actions (actions 610, 620, 630, and 640) associated with a method for demonstrating a safety guarantee for a container according to a disclosed embodiment. This flowchart 600 is related to... Figure 4 This corresponds to system 300B shown.

[0104] Initially, as reflected in the system 300B diagram and as previously described, the remote proof service 396 can be used to verify system proof reports and individual enclosing zone / container reports. The keys and other credentials used in the proof process can also be provided by the remote key supply service 395. However, as further described, end-to-end proof and key supply for temporary containers, particularly containers supplied from the same container image, represent a waste of resources.

[0105] When a new container is based on a previously used container image that was used to supply and / or prove enclosing area proof reports for previous and / or existing containers with container-based memory enclosing areas, the current system addresses some of these inefficiencies by providing a local key supply service 394 and a local container proof service 340 that contain and / or maintain credentials associated with a remote service but can be used to directly supply keys to the container during supply and / or proof and prove the security guarantees of the supplied container, without passing supply or proof requests for the new container from outside the system 300B to the remote service (such as those required for end-to-end supply and / or proof).

[0106] like Figure 6 As shown, the first action implemented by the system is the action (Action 610) to identify one or more containers residing in a security domain (e.g., VTL1 memory, including enclosing memory) different from the first security domain (VTL0) of the host system. Notably, in this action, each container is configured to reference the enclosing memory of the host system and uses a security component to validate the specific security configuration of the enclosing memory. This security component is also stored at a specific memory address on the host system, such as in the enclosing memory, and is linked to that specific memory address by one or more references to the security component at one or more containers.

[0107] The next action includes: the system obtaining a single proof report from a remote proof service, which verifies the security assurances of the security configuration of one or more containers based on information obtained by or including the security component (Action 620). For example, this can occur in response to the system submitting a container proof request to the remote proof service for a first container supplied with a specific container image and utilizing the host system's bounding zone memory and a security component used to generate the proof report.

[0108] Next, after receiving a single proof report from the remote proof service, the system receives a new request to prove a security guarantee for a specific container among one or more containers (Action 630). This can occur, for example, in response to the generation of a new / second container (which is supplied from the same container image used to supply the first container) and the submission of a new proof request. Alternatively, the specific container may be the first container that submits an additional proof request or resends an earlier submitted proof request. Note that in some embodiments, the proof request is for the container, and in some embodiments, the proof request is for both the container and the enclosing area associated with it.

[0109] In some embodiments, the local container proof service 340 intercepts new requests and prevents new proof requests from being sent to the remote proof service used to verify the first / single proof report in response to a previous proof request. In some embodiments, the network connection to the remote proof service fails, times out, or is otherwise unreliable, so new requests sent to the remote proof service used to verify the first / single proof report in response to a previous proof request do not reach their intended destination.

[0110] Instead, the system (e.g., local container proof service 340) independently (without utilizing a remote proof service for verification) verifies and / or otherwise proves the security guarantees of a particular container's security configuration (action 640). For example, this action is performed in response to determining that a particular container is supplied from the same container image used to supply a previous container for which a proof report has already been generated, that proof report is verified in a single proof report and based on that previous proof report received before a new proof request is received.

[0111] In some cases, actions 630 and 640 are repeated for different container proof requests so that the system proves security guarantees for multiple different containers, each including a reference to the same security component stored at an address on the host system, all supplied from the same container image, and based on earlier verification of the security guarantees via a proof report generated for another container supplied from the same container image.

[0112] In some embodiments, the proof service can be tiered across multiple caching levels. For example, one level may run within the container itself, another level may run on the host, and a third level may run on a remote service, such as as a remote proof service 396, and so on. In this case, verification of the container image may be reported (or propagated) to different levels and then “cached” to ensure the proof service is highly available.

[0113] Regarding the foregoing, it should be understood that the nesting of different proofs within different levels can also include structured and / or deterministic proofs at each level. For example, for each level of proof, the system can independently identify the attributes of the container that generates the proof report to be proven. Based on these attributes, the proof can be performed within the same level by the component / service responsible for performing the proof at that level (e.g., by the container, by the delegated container, by the host, by the remote service, etc.), or the request for proof can be routed to another level / proof service or component.

[0114] It should be understood that the foregoing embodiments can be used to overcome many of the drawbacks associated with conventional memory partitioning techniques, and can be used in a scalable and efficient manner to provide container-based memory enclosed areas by utilizing the hierarchical isolation of containers.

[0115] It should be understood that the methods described herein can be practiced by a computing system, such as those described above and those claimed, and include one or more processors (e.g., hardware processors) and a computer-readable medium including computer memory storing computer-executable instructions and / or one or more other hardware storage devices, the computer-executable instructions being executable by the hardware processor, and the computer-executable instructions, when executed by the hardware processor, causing the corresponding computing system to perform various functions, including performing the actions set forth in the methods described herein.

[0116] As discussed in more detail below, embodiments of the present invention may include or utilize a dedicated or general-purpose computer, including computer hardware. Embodiments within the scope of the present invention also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media may be any available medium accessible by a general-purpose or dedicated computer system. A computer-readable medium storing computer-executable instructions is a physical storage medium. A computer-readable medium carrying computer-executable instructions is a transmission medium. Therefore, by way of example and not limitation, embodiments of the present invention may include at least two distinct types of computer-readable media: physical computer-readable storage media and transmission computer-readable media.

[0117] Physical computer-readable storage media include RAM, ROM, EEPROM, CD-ROM or other optical disc storage (such as CD, DVD, etc.), magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of computer-executable instructions or data structures and that can be accessed by a general-purpose or special-purpose computer.

[0118] A “network” is defined as one or more data links that enable the transmission of data between computer systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computer via a network or other communication connection (which may be hardwired, wireless, or a combination of both), the computer appropriately considers the connection as a transmission medium. The transmission medium may include networks and / or data links, which may be used to carry or transmit desired program code components in the form of computer-executable instructions or data structures, and which may be accessible to general-purpose or special-purpose computers. Combinations of the above are also included within the scope of computer-readable media.

[0119] Furthermore, upon arrival at various computer system components, program code in the form of computer-executable instructions or data structures can be automatically transferred from a transmission computer-readable medium to a physical computer-readable storage medium (or vice versa). For example, computer-executable instructions or data structures received via a network or data link can be cached in RAM within a network interface module (e.g., a "NIC") and then ultimately transferred to the computer system RAM and / or a low-volatility computer-readable physical storage medium within the computer system. Therefore, computer-readable physical storage media can be included in computer system components that also (or even primarily) utilize the transmission medium.

[0120] Computer-executable instructions include, for example, instructions and data that cause a general-purpose computer, a special-purpose computer, or a special-purpose processing device to perform a particular function or group of functions. Computer-executable instructions can be, for example, binary, intermediate format instructions such as assembly language, or even source code. Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features or actions described above. Rather, the described features and actions are disclosed as exemplary forms for implementing the claims.

[0121] Those skilled in the art will understand that this invention can be practiced in network computing environments with a variety of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframes, mobile phones, PDAs, pagers, routers, switches, etc. This invention can also be practiced in distributed system environments, where both local and remote computer systems linked via a network (via hardwired data links, wireless data links, or a combination of hardwired and wireless data links) perform tasks. In a distributed system environment, program modules can reside on both local and remote memory storage devices.

[0122] Alternatively or additionally, the functionality described herein may be performed at least in part by one or more hardware logic components. For example, but not limited to, illustrative types of hardware logic components that may be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), etc.

[0123] The invention may be embodied in other specific forms without departing from its spirit or characteristics. The described embodiments should be considered illustrative rather than restrictive in all respects. Therefore, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All variations within the equivalent meaning and scope of the claims are included within their scope.

Claims

1. A computing system, comprising: One or more processors; as well as One or more computer-readable storage media storing computer-executable instructions executable by the one or more processors to configure the computing system to implement a method for creating a container-based memory enclosing region, and at least by configuring the computing system to perform the following operations: An image of a container that identifies a security component used to demonstrate a specific security configuration used by a host system running in a first security domain; The container image is used to instantiate a new container. When the new container is instantiated, the new container is configured to utilize the enclosed memory in the second security domain of the host system based on the security component stored in the enclosed memory at a specific memory address of the host system. The new container provides a claimed link to the claimed memory address of the security component stored in the enclosed memory of the host system. as well as During or after the instantiation of the new container, the claimed link of the new container to the claimed memory address of the security component stored in the enclosing memory is modified to the specific memory address of the security component stored at the specific memory address on the host system, and the claimed link of the new container to the claimed memory address is modified to veribly link the new container to the specific memory address of the security component stored in the enclosing memory at the specific memory address on the host system.

2. The computing system of claim 1, wherein modifying the claimed link comprises: The claimed memory address is overwritten using the specific memory address of the security component stored in the enclosed memory at the specific memory address of the host system.

3. The computing system of claim 1, wherein modifying the claimed link comprises: Create a link to the specific memory address of the security component stored in the enclosed memory at the specific memory address of the host system.

4. The computing system of claim 1, wherein modifying the claimed link comprises: Update the claimed memory address in the mapping table associated with the security component to include or reference the specific memory address of the security component stored in the enclosed memory at the specific memory address of the host system.

5. The computing system of claim 4, wherein the method further comprises creating a mapping table and adding the reference address to the mapping table using metadata associated with the new container during or after instantiation of the new container.

6. The computing system of claim 1, wherein the security component includes library files.

7. The computing system of claim 1, wherein the security component includes data used to generate a certification report on the security configuration for the new container.

8. The computing system of claim 7, wherein the computer-executable instructions are further executable by the one or more processors to configure the computing system to perform proof of security assurances associated with the security configuration for the new container.

9. A method for creating a container-based memory enclosing region, the method comprising: An image of a container that identifies a security component used to demonstrate a specific security configuration used by a host system running in a first security domain; The container image is used to instantiate a new container. When the new container is instantiated, the new container is configured to utilize the enclosed memory in the second security domain of the host system based on the security component stored in the enclosed memory at a specific memory address of the host system. The new container provides a claimed link to the claimed memory address of the security component stored in the enclosed memory of the host system. as well as During or after the instantiation of the new container, the claimed link of the new container to the claimed memory address of the security component stored in the enclosing memory is modified to the specific memory address of the security component stored at the specific memory address on the host system, and the claimed link of the new container to the claimed memory address is modified to veribly link the new container to the specific memory address of the security component stored in the enclosing memory at the specific memory address on the host system.

10. The method of claim 9, wherein modifying the claimed link comprises: The claimed memory address is overwritten using the specific memory address of the security component stored in the enclosed memory at the specific memory address of the host system.

11. The method of claim 9, wherein modifying the claimed link comprises: Create a link to the specific memory address of the security component stored in the enclosed memory at the specific memory address of the host system.

12. The method of claim 9, wherein modifying the claimed link comprises: Update the mapping table associated with the new container to include or reference the specific memory address of the security component stored in the enclosed memory at the specific memory address of the host system.

13. The method of claim 9, wherein the security component includes data used to generate a certification report on the security configuration for the new container, and wherein the method further includes performing certification of security assurances associated with the security configuration for the new container.

Images