Certification of containers by host computing system

Abstract

Embodiments include a method for configuring a software integrity tool of a host computing system with a runtime environment arranged to execute a container containing an application. Such a method includes obtaining a container locator tag associated with a container based on an identifier of the container instantiated in a runtime environment, and performing a measurement on a file system associated with the container. Such a method includes sending a representation of the container locator tag and a result of the measurement to an attestation verification system (AVS). Other embodiments include complementary methods for the container and for the AVS, and a host computing system configured to perform such methods.

Description

Technical Field

[0001] The present application relates generally to the field of communication networks, and more particularly to techniques for virtualizing network functions (NFs) using container-based solutions executed in a host computing system (e.g., cloud, data center, etc.). Background Art

[0002] At a high level, the 5G system (5GS) consists of an access network (AN) and a core network (CN). The AN provides connectivity to the CN for UEs via base stations (such as gNB or ng-eNB described below), for example. The CN contains a variety of network functions (NFs) that provide a wide range of different functionalities, such as session management, connection management, billing, authentication, etc.

[0003] Figure 1 A high-level view of an exemplary 5G network architecture consisting of a Next Generation Radio Access Network (NG-RAN) 199 and a 5G Core (5GC) 198 is shown. The NG-RAN 199 may include one or more gNodeBs (gNBs) connected to the 5GC via one or more NG interfaces, such as gNBs 100, 150 connected via interfaces 102, 152, respectively. More specifically, the gNBs 100, 150 may be connected to one or more access and mobility management functions (AMFs) in the 5GC 198 via respective NG-C interfaces. Similarly, the gNBs 100, 150 may be connected to one or more user plane functions (UPFs) in the 5GC 198 via respective NG-U interfaces. Various other network functions (NFs) may be included in the 5GC 198, as described in more detail below.

[0004] In addition, these gNBs can be connected to each other via one or more Xn interfaces, such as Xn interface 140 between gNBs 100 and 150. The radio technology used for NG-RAN is often referred to as "new radio" (NR). With respect to the NR interface to the UE, each of the gNBs can support frequency division duplex (FDD), time division duplex (TDD), or a combination thereof. Each of the gNBs can serve a geographic coverage area including one or more cells, and in some cases, can also use various directional beams to provide coverage in the corresponding cells.

[0005] NG-RAN 199 is layered into a radio network layer (RNL) and a transport network layer (TNL). NG-RAN logical nodes and the interfaces between them are part of the RNL, while TNL provides services for user plane transport and signaling transport. TNL protocols and related functionality are specified for each NG-RAN interface (e.g., NG, Xn, F1).

[0006] Figure 1 The NG-RAN logical nodes shown in the figure include a central unit (CU or gNB-CU) and one or more distributed units (DU or gNB-DU). For example, gNB 100 includes gNB-CU 110 and gNB-DUs 120 and 130. The CU (e.g., gNB-CU 110) is a logical node that hosts higher layer protocols and performs various gNB functions (such as controlling the operation of the DU). The DU (e.g., gNB-DU 120, 130) is a decentralized logical node that hosts lower layer protocols and may include (depending on the functional split option) various subsets of gNB functions. Accordingly, each of the CU and DU may include various circuits required to perform their respective functions, including processing circuits, transceiver circuits (e.g., for communication), and power supply circuits.

[0007] gNB-CU through the corresponding F1 logical interface (such as Figure 1 The F1 interface is connected to one or more gNB-DUs (see interfaces 122 and 132 shown in FIG. 1 ). However, a gNB-DU can only be connected to a single gNB-CU. The gNB-CU and the connected gNB-DU(s) are visible only to other gNBs and the 5GC as a gNB. In other words, the F1 interface is not visible outside the gNB-CU.

[0008] Traditionally, telecommunication equipment is provided as integrated software and hardware. More recently, virtualization technology has decoupled software and hardware, making it possible to execute network functions (NFs) on commercial off-the-shelf (COTS) hardware. For example, a mobile network may include virtualized network functions (VNFs) and non-virtualized network elements (NEs) that use dedicated hardware to execute or instantiate NFs. Figure 1 In the context of the exemplary 5G network architecture shown in , various NG-RAN nodes (e.g., CU) and various NFs in 5GC can be implemented as a combination of VNFs and NEs.

[0009] In some cases, NFs may be obtained from vendors as packaged in "containers," which are software packages that can run on commercial off-the-shelf (COTS) hardware. Computing infrastructure providers (e.g., hyperscale providers, communications service providers, etc.) typically provide resources to vendors for executing their containers. These resources include computing hardware and a software environment that hosts or executes the containers, which is often referred to as a "runtime environment" or more simply a "runtime."

[0010] For example, Docker is a popular container runtime that runs on various Linux and Windows operating systems (OS). Docker creates a simple set of tools and a common packaging method that bundles all application dependencies into a container to run in the Docker engine, which enables containerized applications to run consistently on any infrastructure. Summary of the invention

[0011] Currently, when a runtime such as Docker instantiates a container that holds a software image (e.g., of NFs), there is no way to verify that the runtime actually instantiates what is expected. This can lead to various problems, issues, and / or difficulties, such as the inability to detect defects in or attacks on the software image.

[0012] Embodiments of the present disclosure address these and other issues, problems, and / or difficulties, thereby facilitating more efficient use of runtimes hosting containerized software, such as virtual NFs of communication networks.

[0013] Some embodiments include an exemplary method (eg, process) for configuring a software integrity tool of a host computing system with a runtime environment arranged to execute a container containing an application.

[0014] The exemplary methods may include obtaining a container locator tag associated with the container based on an identifier of a container instantiated in a runtime environment, and performing a measurement on a file system associated with the container. The exemplary methods may also include sending a representation of the container locator tag and a result of the measurement to an attestation verification system (AVS).

[0015] In some embodiments, these exemplary methods may further include: monitoring one or more events or patterns indicating that a container has been instantiated in the runtime environment, and in response to detecting the one or more events or patterns, obtaining an identifier of the container that has been instantiated. In some of these embodiments, the monitoring of the one or more events may be performed using an eBPF probe.

[0016] In some embodiments, performing the measurement on the file system includes calculating a digest of one or more files stored in the file system associated with the container. In such cases, the result of the measurement is a digest. In some of these embodiments, performing the measurement on the file system may also include selecting one or more files for which to calculate the digest according to a digest policy of the host computing system.

[0017] In some embodiments, the identifier associated with the container is a process identifier (PID), and the file system associated with the container has a path name that includes the PID. In some embodiments, the container locator label is a random string. In some embodiments, the container locator label is obtained from a predefined location in the file system associated with the container. In some embodiments, the representation of the container locator label is one of the following: the container locator label, or a digest of the container locator label.

[0018] In some embodiments, these exemplary methods may further include: digitally signing the representation of the container locator tag and the results of the measurement before sending the representation of the container locator tag and the results of the measurement to the AVS. In such cases, the digital signature is based on key material accessible to the host computing system but not accessible to the container configured to execute in the runtime environment. This restriction can prevent false self-certification by the container. In some of these embodiments, the digital signature is performed by a hardware mediated execution isolation zone (HMEE) associated with the software integrity tool.

[0019] Other embodiments include exemplary methods (eg, processes) for a container that contains an application and is configured to execute in a runtime environment of a host computing system.

[0020] These exemplary methods may include: in response to the container being instantiated in the runtime environment, generating a container locator tag, and storing the container locator tag in association with the container. The exemplary methods may also include: subsequently receiving an attestation result from the AVS, the attestation result indicating whether the AVS verified the file system associated with the container based on measurements made by a software integrity tool of the host computing system. These exemplary methods may also include: when the attestation result indicates that the AVS verified the file system associated with the container, preparing the application for execution in the runtime environment of the host computing system.

[0021] In some embodiments, the container further includes an attestation client that generates and stores the container locator tag and receives an attestation result.

[0022] In some embodiments, the example methods may further include, when the attestation result indicates that the AVS did not verify the file system associated with the container, performing one or more of: error handling, and refraining from preparing the application for execution in the runtime environment.

[0023] In some embodiments, the container locator tag is a random string. In some embodiments, the container locator tag is stored in a predefined location in a file system associated with the container.

[0024] In some embodiments, these exemplary methods may further include: sending a representation of the container locator tag to the AVS. In such cases, the received attestation result is based on the representation of the container locator tag. In some of these embodiments, the representation of the container locator tag is one of the following: the container locator tag, or a summary of the container locator tag.

[0025] In some embodiments, the measurement comprises a digest of one or more files stored in a file system associated with the container. In some of these embodiments, the one or more files are based on a digest policy of the host computing system.

[0026] Other embodiments include exemplary methods (eg, processes) for an AVS associated with a host computing system configured with a runtime environment arranged to execute a container containing an application.

[0027] The exemplary methods may include receiving, from a software integrity tool of a host computing system, a representation of a container locator tag of a container instantiated in a runtime environment, and results of a measurement performed by the software integrity tool on a file system associated with the container. The exemplary methods may also include, based on detecting a match between the representation of the container locator tag and a previously received representation of the container locator tag, performing verification of the file system associated with the container based on the results of the measurement. The exemplary methods may also include sending an attestation result to the container, the attestation result indicating whether the AVS verified the file system associated with the container.

[0028] In some embodiments, performing verification may include comparing the measured result to one or more known good values ​​or reference values ​​associated with the container, and verifying the file system only if there is a match or correspondence between the measured result and the one or more known good values ​​or reference values.

[0029] In some embodiments, the previously received representation is received from an attestation client contained in the container. In some embodiments, the container locator tag is a random string of characters. In some embodiments, the container locator tag is stored at a predefined location in a file system associated with the container. In some embodiments, the representation of the container locator tag is one of: the container locator tag, or a digest of the container locator tag.

[0030] In some embodiments, the representation of the container locator tag and the result of the measurement are digitally signed by the software integrity tool. In such embodiments, performing verification includes verifying the digital signature based on key material accessible to the host computing system but not accessible to the container configured to execute in the runtime environment.

[0031] Other embodiments include a software integrity tool, a container, an AVS, and / or a host computing system configured to perform operations corresponding to any of the exemplary methods described herein. Other embodiments also include a non-transitory computer-readable medium storing computer-executable instructions that, when executed by processing circuitry of a host computing system or AVS, configure the host computing system or AVS to perform operations corresponding to any of the exemplary methods described herein.

[0032] These and other disclosed embodiments can facilitate verification that a container is booted with the expected file system, for example, by verifying the integrity of binary images and library files. Because this verification operates at the host level, it is independent of the container. This verification can also be independent of the container runtime (e.g., Docker), which is advantageous if / when the attack originates from the container runtime software. At a high level, embodiments that perform verification at the host level provide better security than verification performed within the container because it prevents the container from falsely certifying itself.

[0033] These and other objects, features and advantages of the present disclosure will become apparent upon reading the following detailed description with reference to the accompanying drawings which are briefly described below. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Figure 1 An exemplary 5G network architecture is shown.

[0035] Figure 2 An exemplary Network Function Virtualization Management and Orchestration (NFV-MANO) architecture framework for 3GPP specified networks is shown.

[0036] Figure 3 An exemplary high-level architecture for a Docker engine is shown.

[0037] Figure 4 Show use Figure 3 An example compute configuration for the Docker Engine shown in .

[0038] Figure 5 An example implementation of eBPF in a Linux operating system (OS) kernel is shown.

[0039] Figure 6 A flow chart illustrating high-level operation of a software integrity tool according to some embodiments of the present disclosure.

[0040] Figure 7 An exemplary signaling diagram illustrating a verification process for a container performed by a host computing system according to some embodiments of the present disclosure.

[0041] Figure 8An exemplary method (eg, process) for a software integrity tool configured to execute in a host computing system arranged to execute containerized applications is shown in accordance with various embodiments of the present disclosure.

[0042] Fig. 9 Exemplary methods (eg, processes) for containers configured to execute in a host computing system are shown according to various embodiments of the present disclosure.

[0043] Fig.10 Exemplary methods (eg, processes) for an AVS associated with a host computing system configured to execute containerized applications are shown according to various embodiments of the present disclosure.

[0044] Fig.11 is a block diagram illustrating an exemplary container-based host computing system suitable for implementing the various embodiments described herein. DETAILED DESCRIPTION

[0045] The embodiments briefly summarized above will now be described more fully with reference to the accompanying drawings. These descriptions are provided by way of example to illustrate the subject matter to those skilled in the art and should not be construed as limiting the scope of the subject matter to only the embodiments described herein. More specifically, examples illustrating the operation of various embodiments in accordance with the advantages discussed above are provided below.

[0046] In general, all terms used in this article are to be interpreted according to their common meaning in the relevant technical field, unless the context in which the term is used clearly gives and / or implies different meanings. Unless otherwise clearly indicated, all references to one / a certain / this element, equipment, assembly, part, step, etc. are to be openly interpreted as referring to at least one instance of the element, equipment, assembly, part, step, etc. Unless a certain step is clearly described as after or before another step and / or in the case of implying that a certain step must be after or before another step, the steps of any method and / or process disclosed herein are not necessarily performed in the disclosed exact order. In any appropriate case, any feature of any embodiment in the embodiments disclosed herein can be applied to any other embodiment. Similarly, any advantage of any embodiment in the described embodiment can be applied to any other embodiment, and vice versa. Other purposes, features and advantages of the disclosed embodiments will be clear from the following description.

[0047] Note that the description given herein focuses on 3GPP telecommunication systems, and accordingly, 3GPP terminology or terminology similar to 3GPP terminology is generally used. However, the concepts disclosed herein are not limited to 3GPP systems. Other wireless systems, including but not limited to Wideband Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMax), Ultra Mobile Broadband (UMB), and Global System for Mobile Communications (GSM), may also benefit from the concepts, principles, and / or embodiments described herein.

[0048] Furthermore, functions and / or operations described herein as being performed by a telecommunication device or a network node may be distributed across multiple telecommunication devices and / or network nodes.

[0049] As briefly discussed above, virtualization technology decouples software and hardware so that network functions (NFs) can be executed on commercial off-the-shelf (COTS) hardware. ETSI GR NFV 001 (v1.3.1), published by the European Telecommunications Standards Institute (ETSI), describes various high-level goals and use cases for network function virtualization (NFV). High-level goals include the following:

[0050] Rapid service innovation through software-based deployment and operation of network functions and end-to-end services.

[0051] Improved operational efficiencies from common automation and operational processes.

[0052] Reduced power usage by migrating workloads and powering down unused hardware.

[0053] • Standardized and open interfaces between network functions and their management entities, so that such decoupled network elements can be provided by different entities.

[0054] Greater flexibility in assigning VNFs to hardware.

[0055] Improved capital efficiency compared to dedicated hardware implementations.

[0056] Similarly, the various NFV use cases described in ETSI GR NFV 001 can be broadly categorized into the following groups or categories:

[0057] Virtualization of telecommunications networks.

[0058] Virtualization of services in telecom networks, e.g., Internet of Things (IoT) virtualization, enhanced security, network slicing, etc.

[0059] Improved operations of virtualized networks, such as rapid service deployment, continuous integration / continuous deployment (CI / CD), testing and verification, etc.

[0060] For example, a mobile or cellular network may include virtualized NFs (VNFs) and non-virtualized network elements (NEs) that use dedicated hardware to execute or instantiate the NFs. Figure 1 In the context of the exemplary 5G network architecture shown in , various NG-RAN nodes (e.g., CU) and various NFs in 5GC can be implemented as a combination of VNFs and NEs.

[0061] In general, a (non-virtualized) NE can be considered an example of a physical network function (PNF). From a high-level perspective, a VNF is equivalent to the same NF implemented by a NE. However, the relationship between a NE and a VNF instance depends on the relationship between the corresponding NFs. If the VNF contains the entire NF of the NE, then the NE instance is 1:1 related to the VNF instance. Even so, multiple instances of the VNF can run on the same NF virtualization infrastructure (NFVI, e.g., cloud infrastructure, data center, etc.).

[0062] Both VNFs and NEs need to be managed in a consistent manner. To facilitate this, 3GPP specifies the Network Function Virtualization Management and Orchestration (NFV-MANO) architecture framework. Figure 3 An exemplary mobile network management architecture mapping relationship between the NFV-MANO architecture framework and other parts of the 3GPP specified network is shown. The 3GPP TS 28.500 (v17.0.0) section 6.1 describes in detail Figure 2 The arrangement shown in , the entire contents of which are incorporated herein by reference. For context and clarity, certain portions of this description are provided below.

[0063] Figure 2 The architecture shown in 3GPP TS 32.101 (v17.0.0) includes the following entities, some of which are further defined in 3GPP TS 32.101 (v17.0.0):

[0064] Network Management (NM), NM plays the role of one of the Operation Support System (OSS) or Business Support System (BSS) and is a consumer of the reference point Os-Ma-nfvo;

[0065] Device Management (DM) / Element Management (EM), if EM includes extended functionality, it can manage both PNFs and VNFs;

[0066] NFV Orchestrator (NFVO);

[0067] VNF Manager (VNFM);

[0068] Virtualized Infrastructure Manager (VIM);

[0069] Itf-N, the interface between NM and DM / EM;

[0070] Os-Ma-nfvo, the reference point between OSS / BSS and NFVO;

[0071] Ve-Vnfm-em, the reference point between EM and VNFM;

[0072] Ve-Vnfm-vnf, the reference point between VNF and VNFM; and

[0073] NFVI, the hardware and software components that together provide the infrastructure resources in which the VNFs are deployed.

[0074] EM / DM is responsible for FCAPS (Fault, Configuration, Accounting, Performance, Security) management functionality for VNFs at the application level and NEs at the domain and element level. This includes:

[0075] Fault management for VNFs and physical NEs.

[0076] Used for configuration management of VNFs and physical NEs.

[0077] Accounting management for VNFs and physical NEs.

[0078] For performance measurement and collection of VNFs and physical NEs.

[0079] Security management for VNFs and physical NEs.

[0080] VNF Lifecycle Management (LCM), such as requesting LCM for a VNF through the VNFM, and exchanging information about the VNF and virtualized resources associated with the VNF.

[0081] In some cases, NFs can be obtained from vendors as packaged in "containers," which are software packages that can run on COTS hardware. More specifically, a container is a standard unit of software that encapsulates application code and all its dependencies so that the application runs quickly and reliably in different computing environments. Computing infrastructure providers (e.g., hyperscale providers, communications service providers, etc.) typically provide resources to vendors for executing their containers. These resources include computing hardware and the software environment that hosts or executes the container (this is often called the "runtime").

[0082] Docker is a popular container runtime that runs on various Linux and Windows operating systems (OS). Docker creates a simple set of tools and a common packaging method that bundles all application dependencies into containers, which run on the Docker engine. Specifically, the Docker engine enables containerized applications to run consistently on any infrastructure. A Docker container image is a lightweight, independent, executable software package that has everything needed to run an application, including code, runtime, system tools, system libraries, and settings. A Docker container image becomes a container at runtime (i.e., when the container image runs on the Docker engine). Multiple Docker containers can run on the same machine and share the OS kernel with other Docker containers, and each Docker container runs as an isolated process in user space.

[0083] Figure 3 An exemplary high-level architecture of the Docker engine is shown, which has the following description Figure 3 The various blocks shown in .

[0084] Containerd implements the Kubernetes container runtime interface (CRI) and is widely adopted across public clouds and enterprises. Kubernetes is a utility platform for providing cloud-based web-services. Kubernetes can coordinate highly available clusters of connected computers (also called "processing elements" or "hosts") to work as a single unit. Kubernetes (e.g., via its runtime) deploys applications encapsulated in containers to decouple them from individual computing hosts.

[0085] Generally speaking, a Kubernetes cluster consists of two types of resources: a "supervisor" that coordinates or manages the cluster, and "nodes" or "workers" that run applications. In other words, a node is a virtual machine (VM) or physical computer that acts as a worker machine. The supervisor coordinates all activities in the cluster, such as scheduling applications, maintaining the desired state of applications, scaling applications, and rolling out new updates. Each node has a Kubelet that acts as an agent for managing nodes and communicating with the Kubernetes supervisor, as well as tools for handling container operations. The Kubernetes cluster supervisor starts application containers and schedules them to run on the nodes of the cluster. These nodes communicate with the supervisor using the Kubernetes API that the supervisor exposes. End users can also interact with the cluster directly using the Kubernetes API.

[0086] A "pod" is the basic execution unit of a Kubernetes application, i.e., the smallest and simplest unit that can be created and deployed in the Kubernetes object model. A pod represents a process running on a cluster and encapsulates an application's container(s), storage resources, a unique network IP address, and options for controlling how the container(s) should run. In other words, a Kubernetes pod represents a single instance of an application, which can consist of one or more containers that are tightly coupled and share resources.

[0087] Return to Figure 3 , BuildKit is an open source tool that takes instructions from a Dockerfile and builds (or creates) a Docker container image. This build process can take a long time, so BuildKit provides several architectural enhancements that make it much faster, more accurate, and portable. The Docker application programming interface (API) and the Docker command line interface (CLI) facilitate interfacing with the Docker engine. For example, the Docker CLI enables users to manage container instances through a clear set of commands.

[0088] like Figure 3 As shown in , the Docker engine also provides functions such as distribution, orchestration, and networking. The Docker engine also provides volume functionality, which is the preferred mechanism for persisting data generated and / or used by Docker containers. Compared to bind mounts (where files or directories on the host machine are mounted into the container), volumes are independent of the host machine's directory structure and OS and are completely managed by Docker.

[0089] Figure 4 An example computing configuration using the Docker engine is shown. At the bottom is a computing infrastructure (410, also referred to as a "host") running an OS (420, e.g., Windows, Linux, etc.). The Docker engine (430) runs on top of the OS and executes applications 1-N as Docker containers (440, also referred to as "containerized applications").

[0090] Typically, the OS is the best place to implement observability, security, and networking functionality due to its privileged ability to oversee and control the entire system. At the same time, the OS kernel is difficult to evolve due to its central role and strict requirements for stability and security. As a result, the pace of innovation at the OS level has been slower than innovation outside the OS (such as Kubernetes, Docker Engine, etc.).

[0091] eBPF is a technology that can run sandboxed programs in the Linux OS kernel. In particular, eBPF is a simple and safe way to access the kernel without affecting its behavior. eBPF can also collect execution information without changing the kernel itself or by adding kernel modules. eBPF does not require changes to the Linux kernel source code, nor does it require any specific Linux kernel modules to work. This technology is very suitable for collecting information from both user space and kernel space via carefully placed probes.

[0092] eBPF programs are event-driven and run when the kernel (or application) passes through a certain hook point. Predefined hooks include system calls, function entry / exit, kernel tracepoints, network events, etc. Figure 5 An example implementation of eBPF in the Linux OS kernel is shown, where a system call (Syscall) to the kernel scheduler is a hook that triggers the execution of the eBPF program.

[0093] Currently, when a container runtime such as the Docker engine instantiates a container, there is no way to verify that the runtime actually instantiates what is expected. There are some tools for measuring container software images. One example is federated signing, which provides container signing, verification, and storage in the Open Container Initiative (OCI) registry. In addition, there are some tools for detecting unexpected changes in the file system of a running container. One example is the Sysdig monitor, which monitors Kubernetes container groups, clusters, etc.

[0094] However, there is currently no way to verify that the original software image (e.g., of a NF) is actually running in the instantiated container. This may lead to various problems, issues, and / or difficulties. For example, a bug in the container runtime software or an attack on the software may result in changes to the usr directory of the running container, and there is currently no structured way to discover such bugs or attacks.

[0095] Therefore, embodiments of the present disclosure address these and other problems, problems, and / or difficulties through techniques for identifying that a container has been instantiated (e.g., using eBPF), where the identification is done autonomously and / or independently of the container runtime environment (e.g., Docker). These techniques then perform software attestation (e.g., compute a digest) on a set of files present within the container. For example, a compute host can detect when a new container is instantiated and then measure a selected portion of the container's file system. The host then signs the measurement results with a key accessible only to the host. The signed measurement results can be verified by a verification instance within the cluster and compared to a known good value. In some embodiments, the known good value is calculated in advance by the container's vendor during container image creation and before the container image is delivered to the intended user.

[0096] The embodiments described herein provide various benefits and / or advantages. For example, embodiments facilitate verification that a container boots with an expected file system, such as by verifying the integrity of binary images and library files. Because this verification operates at the host level, it is independent of the container. This verification can also be independent of the container runtime (e.g., Docker), which is advantageous if / when the attack originates from the container runtime software. In other words, the verification is performed on the host ("bare metal") execution of the container, independent of the container runtime and the Kubernetes cluster. A further advantage is that the verification is independent of the container vendor because it utilizes functionality inserted into each container. At a high level, embodiments operating at the host level provide better security than verification performed within the container because it prevents the container from falsely self-certifying.

[0097] Figure 6 A flow chart illustrating high-level operation of a software integrity tool according to some embodiments of the present disclosure. In particular, the software integrity tool may be run in a host computing environment that provides containerized execution of applications, such as described above. After the software integrity tool is started (block 610), it deploys a (software) probe with pattern recognition capabilities (block 620). The software probe continuously looks for patterns that indicate that a container runtime (e.g., Docker) has started a container (block 630). Once the software probe recognizes such a pattern ("yes" branch), it performs measurements (block 640) and sends the results to an attestation verification system (AVS) external to the host (block 650).

[0098] Figure 7 7 shows an exemplary signaling diagram of a verification process for a container performed by a host computing system (“host”, 710 ) according to some embodiments of the present disclosure. Figure 7 The operations shown in are given numerical labels, but this is done for ease of explanation and no sequential order is required or implied unless otherwise indicated below.

[0099] like Figure 7 As shown in , the host is arranged to execute a container (720) containing an application (722) and an attestation client (724). In addition, the host is arranged to execute a software integrity tool (730) and a container orchestrator (740). In some cases, the software integrity tool may include or be associated with a hardware mediated execution isolation zone (HMEE, 732) that provides hardware-enforced isolation of both code and data.

[0100] For example, HMEE can act as a root of trust and can be used for certification. In such scenarios, the remote verifier may request a quote from HMEE via a certification agent. HMEE will provide the remote verifier with signed measurement data ("quote"). The remote verifier can then use its own stored data to verify the signature and the quote. In this way, HMEE-based certification can provide the remote verifier with a guarantee that the correct application is executed on the correct platform. HMEE is further specified in ETSI GR NFV-SEC 009.

[0101] As a prerequisite, a software integrity tool is running on the host, such as Figure 6 As shown in . In operation 1, the orchestrator decides to instantiate a container instance derived from a container image. In operation 2, based on identifying a pattern at the system level, the software integrity tool understands that the container runtime has started a container instance. The software integrity tool also identifies a process identifier (PID) associated with the container. For example, the PID can be a Docker PID assigned by the Docker engine.

[0102] The container startup detection in operation 2 can be implemented in various ways. In some embodiments, eBPF can be used to detect the start of a new process and identify a chain of started processes that indicates the start of a new container. Even though such embodiments may require adaptation to support different container runtime solutions, such embodiments are independent of the container runtime software. By using eBPF, these embodiments can efficiently detect the start of a new container while being fail-safe and independent of the container. In other embodiments, functionality in the container runtime software can be used to detect the start of a new container and obtain the PID of the container.

[0103] After the container has been instantiated, in operation 3, the attestation client inside the container generates a random container locator tag. The length should be long enough to avoid collisions. The attestation client stores the container locator tag in the container (e.g., at a predefined path), and in operation 4, sends the container locator tag to the AVS (750). Alternatively, the attestation client may send data that enables identification of the container locator tag, such as a digest. Note that the AVS may be external to the host (as shown) or internal to the host.

[0104] After the software integrity tool learns the PID, it performs operations 5-7. In operation 5, the software integrity tool performs measurements on the file system of the newly started container. For example, the software integrity tool can calculate digests of files in the file system of the container. In some embodiments, the digest policy can specify which file system folders to include in the digest calculation. The file system of the container measured in operation 5 can be obtained at different paths on the host. One place to obtain it is / proc / [PID] / root. Another place to obtain it is the driver of the container runtime.

[0105] In operation 6, the software integrity tool finds and reads the container locator tag from within the container (e.g., from a predefined path). In operation 7, the software integrity tool digitally signs the digest obtained in operation 5 and the container locator tag obtained in operation 6. If the software integrity tool includes or is associated with an HMEE, that can be used to provide additional security for the handling of key material used for signing. In such cases, only the host has access to the keys needed to verify the source of the measurement.

[0106] In operation 8, the software integrity tool sends the signed measurement results along with the signed container locator tag to AVS. In operation 9, AVS attempts to match the container locator tag received in operation 8 with a tag it has received previously (e.g., in operation 4). If there is no match or AVS understands that the container locator tag has been received recently (e.g., a replay attack), the process will typically stop or transition to error handling. Alternatively, if operation 8 occurs before operation 4, AVS may attempt to match the tag received later from the attestation client with the tag received earlier from the software integrity tool.

[0107] In operations 10-11, the AVS compares the received measurements to a list of known good values ​​and responds to the attestation client with the result (i.e., attestation success or failure). The AVS can find the correct attestation client with the aid of the container locator tag (which maps to the sender of the message in operation 4). In operations 12-13, the container receives the result from the attestation client and continues with container setup if attestation succeeds or begins error handling if attestation fails.

[0108] You can refer to Figure 8-10 To further illustrate the above described embodiment, Figure 8-10 Depicted are exemplary methods (eg, processes) for a software integrity tool, a container containing an application, and an AVS, respectively. In other words, various features of the operations described below correspond to the various embodiments described above. Figure 8-10 The exemplary methods described herein may be used in conjunction (eg, with each other and with other processes described herein) to provide benefits, advantages, and / or solutions to the problems described herein. Figure 8-10 The exemplary method is shown in a specific order by specific blocks, but the operations corresponding to these blocks can be performed in a different order than shown, and can be combined and / or divided into blocks and / or operations with different functionality than shown. Optional blocks and / or operations are indicated by dotted lines.

[0109] Specifically, Figure 8 An exemplary method (eg, process) for configuring a software integrity tool for a host computing system with a runtime environment arranged to execute a container containing an application is shown according to various embodiments of the present disclosure. Figure 8 The exemplary methods shown in may be performed by a software integrity tool (such as described elsewhere herein), or by a host computing system ("host") executing such a software integrity tool.

[0110] The exemplary method may include the operation of block 830, where, based on an identifier of a container instantiated in the runtime environment, the software integrity tool may obtain a container locator tag associated with the container and perform a measurement on a file system associated with the container. The exemplary method may also include the operation of block 850, where the software integrity tool may send a representation of the container locator tag and a result of the measurement to an attestation verification system (AVS).

[0111] In some embodiments, the exemplary method may include operations of blocks 810-820, wherein the software integrity tool may monitor one or more events or patterns indicating that a container has been instantiated in a runtime environment, and in response to detecting the one or more events or patterns, obtain an identifier of the container that has been instantiated. In some of these embodiments, the monitoring of the one or more events in block 810 is performed using an eBPF probe.

[0112] In some embodiments, performing the measurement on the file system in block 830 includes the operation of subblock 832, wherein the software integrity tool may calculate a digest of one or more files stored in the file system associated with the container. In such cases, the result of the measurement is a digest. In some of these embodiments, performing the measurement on the file system in block 830 also includes the operation of subblock 831, wherein the software integrity tool may select one or more files for which to calculate a digest based on a digest policy of the host computing system.

[0113] In some embodiments, the identifier associated with the container is a process identifier (PID), and the file system associated with the container has a path name that includes the PID. In some embodiments, the container locator label is a random string. In some embodiments, the container locator label is obtained from a predefined location in the file system associated with the container (e.g., in block 830). In some embodiments, the representation of the container locator label is one of the following: the container locator label, or a digest of the container locator label.

[0114] In some embodiments, the exemplary method may further include the operation of block 840, wherein the software integrity tool may digitally sign the representation of the container locator tag and the results of the measurement before sending the representation of the container locator tag and the results of the measurement to the AVS (e.g., in block 850). In such cases, the digital signature is based on key material accessible to the host computing system but inaccessible to the container configured to execute in the runtime environment. This restriction may prevent false self-attestation by the container. In some of these embodiments, the digital signature is performed by a hardware mediated execution isolation zone (HMEE) associated with the software integrity tool.

[0115] also, Fig. 9 An exemplary method (e.g., process) for a container according to various embodiments of the present disclosure is shown, the container containing an application and configured to execute in a runtime environment of a host computing system. For example, Fig. 9The exemplary methods shown in can be performed by a container (e.g., a Docker container, a Kubernetes container, etc.) such as described elsewhere herein, or by a host computing system (“host”) that executes such a container in a runtime environment.

[0116] The exemplary method may include the operation of block 910, wherein, in response to the container being instantiated in the runtime environment, the container may generate a container locator tag and store the container locator tag in association with the container. The exemplary method may also include the operation of block 930, wherein the container may subsequently receive an attestation result from an attestation verification system (AVS), the attestation result indicating whether the AVS verified the file system associated with the container based on measurements made by a software integrity tool of the host computing system. The exemplary method may also include the operation of block 940, wherein, when the attestation result indicates that the AVS verified the file system associated with the container, the container may prepare the application for execution in the runtime environment of the host computing system.

[0117] In some embodiments, the container also includes an attestation client that generates and stores the container locator tag (e.g., in block 910) and receives attestation results (e.g., in block 930). Figure 7 An example of such an arrangement is shown in .

[0118] In some embodiments, the exemplary method may further include the operation of block 950 , wherein when the attestation result indicates that the AVS has not verified the file system associated with the container, the container may perform one or more of: error handling, and refraining from preparing the application for execution in the runtime environment.

[0119] In some embodiments, the container locator tag is a random string. In some embodiments, the container locator tag is stored (eg, in block 910) at a predefined location in a file system associated with the container.

[0120] In some embodiments, the exemplary method may also include the operation of block 920, wherein the container may send a representation of the container locator tag to the AVS. In such cases, the attestation result (e.g., received in block 930) is based on the representation of the container locator tag. In some of these embodiments, the representation of the container locator tag is one of the following: the container locator tag, or a digest of the container locator tag.

[0121] In some embodiments, the measurement comprises a digest of one or more files stored in a file system associated with the container. In some of these embodiments, the one or more files are based on a digest policy of the host computing system.

[0122] also, Fig.10An exemplary method (e.g., process) for an AVS associated with a host computing system configured with a runtime environment arranged to execute a container containing an application is shown according to various embodiments of the present disclosure. For example, Fig.10 The exemplary methods shown in may be performed by an AVS such as described elsewhere herein, or by a host computing system ("host") executing such an AVS.

[0123] The exemplary method may include the operation of box 1010, wherein the AVS may receive the following from a software integrity tool of the host computing system: a representation of a container locator tag of a container instantiated in a runtime environment, and a result of a measurement performed by the software integrity tool on a file system associated with the container. The exemplary method may also include the operation of box 1020, wherein, based on detecting a match between the representation of the container locator tag and a previously received representation of the container locator tag, the AVS may perform verification of the file system associated with the container based on the result of the measurement. The exemplary method may also include the operation of box 1020, wherein the AVS may send an attestation result to the container, the attestation result indicating whether the AVS verified the file system associated with the container.

[0124] In some embodiments, performing verification in block 1020 may include operations of sub-blocks 1021-1022, wherein the AVS may compare the measured result with one or more known good values ​​or reference values ​​associated with the container, and verify the file system only when there is a match or correspondence between the measured result and the one or more known good values ​​or reference values. For example, the known good values ​​or reference values ​​may be provided by the vendor of the containerized application, such as discussed above.

[0125] In some embodiments, the previously received representation is received from an attestation client contained in the container. In some embodiments, the container locator tag is a random string of characters. In some embodiments, the container locator tag is stored at a predefined location in a file system associated with the container. In some embodiments, the representation of the container locator tag is one of: the container locator tag, or a digest of the container locator tag.

[0126] In some embodiments, the representation of the container locator tag and the results of the measurement are digitally signed by the software integrity tool. In such embodiments, performing the verification in block 1020 also includes the operation of subblock 1023, wherein the AVS can verify the digital signature based on key material accessible to the host computing system but not accessible to the container configured to execute in the runtime environment.

[0127] Although Figure 8-10Methods (e.g., processes) are described, but operations corresponding to these methods (including any blocks and sub-blocks) may also be implemented in a non-transitory computer-readable medium storing computer-executable instructions. Operations corresponding to these methods (including any blocks and sub-blocks) may also be implemented in a computer program product storing computer-executable instructions. In either case, when such instructions are executed by processing circuitry associated with a host computing system, they may configure the host computing system (or components thereof) to perform operations corresponding to the corresponding methods.

[0128] Fig.11 is a schematic block diagram of a host computing system 1100 illustrating functionality implemented by some embodiments.

[0129] In some embodiments, some or all of the functionality described herein may be implemented as components executed in a runtime environment 1120 hosted by one or more of the hardware nodes 1130. Such hardware nodes may be computing machines arranged in a cluster (e.g., such as in a data center or customer premise equipment (CPE)) where many hardware nodes work together and are managed via management and orchestration (MANO) 11100, which (among other things) oversees lifecycle management of applications 1140. The runtime environment 1120 may run on top of an operating system (OS) 1125 (such as Linux or Windows), which in turn runs directly on the hardware node 1130.

[0130] The hardware node 1130 may include a processing circuit 1160 and a memory 1190. The memory 1190 contains instructions 1195 executable by the processing circuit 1160, whereby the application 1140 may be operable for various features, functions, processes, etc. of the embodiments disclosed herein. The processing circuit 1160 may include a general or special purpose hardware device, such as one or more processors (e.g., a customized processor and / or a commercial off-the-shelf processor), a specialized application specific integrated circuit (ASIC), or any other type of processing circuit (including digital or analog hardware components or special purpose processors). Each hardware node may include a memory 1190-1, which may be a non-persistent memory for temporarily storing instructions 1195 or software executed by the processing circuit 1160. For example, the instructions 1195 may include program instructions (also referred to as a computer program product), which, when executed by the processing circuit 1160, may configure the hardware node 1130 to perform operations corresponding to the method / process described herein.

[0131] Each hardware node may include one or more network interface controllers (NICs) / network interface cards 1170, which include physical network interfaces 1180. Each hardware node may also include a non-transitory, persistent, machine-readable storage medium 1190-2 having stored therein instructions and / or software 1195 executable by the processing circuitry 1160. The software 1195 may include any type of software, including an operating system 1125, a runtime environment 1120, a software integrity tool 1150, and a containerized application 1140.

[0132] Various applications 1142 (which may alternatively be referred to as software instances, virtual appliances, network functions, virtual nodes, virtual network functions, containers, containerized applications, etc.) may be executed by the host computing system 1100. Each application 1142 may be contained in a corresponding container 1141, such as Fig.11 1141a-b in the containers 1141a-b shown in FIG. Note that in some instances, the application 1142 may represent a service. Each container 1141 may also include a certification client 1143, such as Fig.11 1143a-b in the containers 1141a-b shown in FIG.

[0133] In some embodiments, runtime environment 1120 may be used to abstract applications 1142 and containers 1141 from underlying hardware nodes 1130. In such embodiments, processing circuit 1160 executes software 1195 to instantiate runtime environment 1120, which in some instances may be a Docker runtime. For example, runtime environment 1120 may appear like computing and / or networking hardware to containers and / or groups of containers hosted by host computing system 1100.

[0134] In some embodiments, multiple application containers 1141 may be arranged in a container group 1140. In such embodiments, a container group 1140 (e.g., a Kubernetes container group) may be a basic execution unit, i.e., the smallest and simplest unit that may be created and deployed in a host computing system 1100. This may be the case, for example, when multiple containers 1141 encapsulate services used as building blocks of a higher-level application represented by the container group 1140.

[0135] Each container group can include multiple resources shared by the containers within the container group. For example, a container group can represent a process running on a cluster and can encapsulate (one or more) containers (including the applications / services therein), storage resources, a unique network IP address, and options for controlling how (one or more) containers should run. In general, containers can be relatively decoupled from the underlying physical or virtual computing infrastructure.

[0136] The attestation client 1143 may include, but is not limited to, the various features, functions, structures, configurations, etc. of the various attestation client embodiments shown in the various other figures and discussed in more detail above.

[0137] In addition to application 1140, you can also Fig.11 The software integrity tool 1150 is run in the host computing system 1100 shown in FIG. The software integrity tool 1150 may include, but is not limited to, various features, functions, structures, configurations, etc. of various software integrity tool embodiments shown in various other figures and discussed in more detail above.

[0138] In some embodiments, the host computing system may include an Attestation Verification System (AVS) 1155. For example, AVS 1155 may be executed on a hardware node 1130 of the host computing system 1100. Alternatively, AVS may be executed on hardware external to the host computing system 1100, which may be similar to Fig.11 In addition, the AVS 1155 may include, but is not limited to, various features, functions, structures, configurations, etc. of various AVS embodiments shown in various other figures and discussed in more detail above.

[0139] The above merely illustrates the principles of the present disclosure. In view of the teachings herein, various modifications and variations to the described embodiments will be apparent to those skilled in the art. Therefore, it will be appreciated that those skilled in the art will be able to devise numerous systems, arrangements, and processes that, although not explicitly shown or described herein, implement the principles of the present disclosure and are therefore within the spirit and scope of the present disclosure. It will be appreciated by those of ordinary skill in the art that the various embodiments may be used together or interchangeably with one another.

[0140] The term "unit" as used herein may have a conventional meaning in the field of electronics, electrical devices and / or electronic devices, and may include, for example, electrical and / or electronic circuits, devices, modules, processors, memories, logical solid-state and / or discrete devices, computer programs or instructions for performing corresponding tasks, processes, calculations, output and / or display functions, etc., such as those described in this document.

[0141] Any appropriate steps, methods, features, functions or benefits disclosed herein may be performed by one or more functional units or modules of one or more virtual devices. Each virtual device may include a plurality of these functional units. These functional units may be implemented via processing circuits (which may include one or more microprocessors or microcontrollers) and other digital hardware (which may include digital signal processors (DSPs), dedicated digital logic, etc.). The processing circuit may be configured to execute program codes stored in a memory, which may include one or more types of memory, such as a read-only memory (ROM), a random access memory (RAM), a cache memory, a flash memory device, an optical storage device, etc. The program code stored in the memory includes program instructions for executing one or more telecommunications and / or data communication protocols and instructions for implementing one or more of the technologies described herein. In some implementations, the processing circuit may be used to cause the corresponding functional unit to perform the corresponding functions of one or more embodiments of the present disclosure.

[0142] As described herein, the device and / or equipment may be represented by a semiconductor chip, a chipset, or a (hardware) module comprising such a chip or chipset; however, this does not exclude the possibility that the functionality of the device or equipment is not implemented by hardware, but is implemented as a software module (such as a computer program or computer program product including an executable software code portion for execution or operation on a processor). In addition, the functionality of the device or equipment may be implemented by any combination of hardware and software. The device or equipment may also be viewed as an assembly of multiple devices and / or equipment, whether functionally cooperating with each other or independent of each other. In addition, as long as the functionality of the device or equipment is retained, the device and equipment may be implemented in a distributed manner throughout the system. Such and similar principles are considered to be known to technicians.

[0143] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by those of ordinary skill in the art to which the present disclosure belongs. It will be further understood that the terms used herein should be interpreted as having the same meaning as they have in the context of this specification and the related art, and will not be interpreted in an idealized or overly formal sense unless explicitly defined as such in this article.

[0144] In addition, in some cases, certain terms used in this disclosure (including the specification and the drawings) may be used synonymously (e.g., "data" and "information"). It should be understood that although these terms (and / or other terms that may be synonymous with each other) may be used synonymously herein, there may be some situations where such terms may not be intended to be used synonymously.

Claims

1. A method for configuring a software integrity tool for a host computing system having a runtime environment, the runtime environment being arranged to execute a container containing an application, the method comprising: Based on an identifier of a container instantiated in the runtime environment, obtaining (830) a container locator tag associated with the container and performing measurements on a file system associated with the container; and The representation of the container locator label and the result of the measurement are sent (850) to the attestation verification system AVS.

2. The method of claim 1, further comprising: monitoring (810) one or more events or patterns indicating that a container has been instantiated in the runtime environment; as well as In response to detecting the one or more events or patterns, the identifier of the container that has been instantiated is obtained (820).

3. The method of claim 2, wherein: Monitoring of the one or more events is performed using an eBPF probe (810).

4. The method according to any one of claims 1 to 3, wherein: Performing (830) measurements on the file system includes calculating (832) a digest of one or more files stored in the file system associated with the container, wherein the digest is the result of the measurements sent to the AVS.

5. The method of claim 4, wherein: Performing (830) measurements on the file system further includes selecting (831) the one or more files for which to compute the digest based on a digest policy of the host computing system.

6. The method according to any one of claims 1 to 5, wherein: The identifier associated with the container is a process identifier PID, and the file system associated with the container has a path name containing the PID.

7. The method according to any one of claims 1 to 6, wherein: The representation of the container locator tag is one of: the container locator tag, or a digest of the container locator tag.

8. The method according to any one of claims 1 to 7, wherein: One or more of the following applies: The container locator tag is a random string of characters; and The container locator label is obtained from a predefined location in the file system associated with the container.

9. The method of any one of claims 1 to 8, further comprising: Prior to sending the representation of the container locator tag and the result of the measurement to the AVS, digitally signing (840) the representation of the container locator tag and the result of the measurement, wherein the digital signature (840) is based on key material accessible to the host computing system but inaccessible to the container configured to execute in the runtime environment.

10. The method of claim 9, wherein: The digital signature is performed by a hardware mediator execution enclosure HMEE associated with the software integrity tool.

11. A method for a container containing an application, the container being configured to execute in a runtime environment of a host computing system, the method comprising: In response to the container being instantiated in the runtime environment, generating (910) a container locator tag and storing the container locator tag in association with the container; subsequently receiving an attestation result from an attestation verification system AVS, the attestation result indicating whether the AVS verified the file system associated with the container based on measurements performed by a software integrity tool of the host computing system; as well as When the attestation result indicates that the AVS verified the file system associated with the container, the application is prepared (940) for execution in the runtime environment.

12. The method of claim 11, wherein: The container also includes an attestation client; and The attestation client generates and stores the container locator tag, and receives the attestation result.

13. The method of any of claims 11-12, further comprising performing (950) one or more of the following when the attestation result indicates that the AVS has not verified the file system associated with the container: error handling, and refraining from preparing the application for execution in the runtime environment.

14. The method according to any one of claims 11 to 13, wherein: One or more of the following applies: The container locator tag is a random string of characters; and The container locator tag is stored at a predefined location in the file system associated with the container.

15. The method of claim 14, further comprising: A representation of the container locator tag is sent (920) to the AVS, wherein the attestation result is based on the representation of the container locator tag.

16. The method of claim 15, wherein: The representation of the container locator tag sent to the AVS is one of: the container locator tag, or a digest of the container locator tag.

17. The method according to any one of claims 11 to 16, wherein: The measurement includes a summary of one or more files stored in the file system associated with the container.

18. The method of claim 17, wherein: The one or more files upon which the digest is based are selected according to a digest policy of the host computing system.

19. A method for an attestation verification system (AVS) associated with a host computing system configured with a runtime environment, the runtime environment being arranged to execute a container containing an application, the method comprising: The following items are received (1010) from a software integrity tool of the host computing system: a representation of a container locator label of a container instantiated in the runtime environment, and results of measurements performed by the software integrity tool on a file system associated with the container; performing (1020) verification of the file system associated with the container based on the result of the measuring based on detecting a match between the representation of the container locator tag and a previously received representation of the container locator tag; An attestation result is sent (1030) to the container, the attestation result indicating whether the AVS verified the file system associated with the container.

20. The method of claim 19, wherein: Performing (1020) the verification includes: comparing the results of the measuring to one or more known good values ​​or reference values ​​associated with the container (1021); and The file system is verified (1022) only if there is a match or correspondence between the result of the measuring and the one or more known good values ​​or reference values.

21. The method of any one of claims 19-20, wherein: The previously received representation was received from an attestation client contained in the container.

22. The method of any one of claims 19 to 21, wherein: One or more of the following applies: The container locator tag is a random string of characters; and The container locator tag is stored at a predefined location in the file system associated with the container.

23. The method of any one of claims 19 to 22, wherein: The representation and the previously received representation are each one of: the container locator tag, or a digest of the container locator tag.

24. The method of any one of claims 19 to 23, wherein: said representation of said container locator tag and said result of said measuring being digitally signed by said software integrity tool; as well as Performing (1020) the verification includes verifying (1023) the digital signature based on key material accessible to the host computing system but not accessible to a container configured to execute in the runtime environment.

25. A host computing system (410, 710, 1100) configured with a runtime environment (430, 1120) arranged to execute a container (440, 720, 1141) containing an application (722, 1142), the host computing system comprising: a memory (1190) storing computer executable software code (1195) for the software integrity tool (1150) and for the runtime environment; as well as processing circuitry (1160) configured to execute the software code, wherein execution of the software code configures the host computing system to: generating, by a container, a container locator tag in response to being instantiated for execution in the runtime environment, storing the container locator tag in association with the container, and sending a representation of the container locator tag to an attestation verification system AVS (750, 1155); obtaining, by the software integrity tool, a container locator tag associated with the container based on an identifier of the container, and performing measurements on a file system associated with the container; and sending, by the software integrity tool, a representation of the vessel locator tag and a result of the measurement to the AVS; receiving, by the container, from the AVS an attestation result indicating whether the AVS verified the file system associated with the container based on the measurements performed by the software integrity tool; and By means of the container, when the attestation result indicates that the AVS has verified the file system associated with the container, the application contained in the container is prepared for execution in the runtime environment.

26. The host computing system of claim 25, wherein: Execution of the software code further configures the host computing system to perform one or more of the following: By means of the software integrity tool, operations corresponding to any of the methods described in claims 2-10; and By means of the container, the operation corresponds to any of the methods of claims 12-18.

27. The host computing system of any one of claims 25-26, wherein: The memory also includes software code for the AVS; and Execution of the software code further configures the host computing system to, through the AVS, perform operations corresponding to any of the methods of claims 19-24.

28. A host computing system (410, 710, 1100) configured with a runtime environment (430, 1120) arranged to execute a container (440, 720, 1141) containing an application (722, 1142), wherein: The host computing system is further configured to: generating, by a container, a container locator tag in response to being instantiated for execution in the runtime environment, storing the container locator tag in association with the container, and sending a representation of the container locator tag to an attestation verification system AVS (750, 1155); obtaining, by a software integrity tool (1150) of the host computing system, a container locator tag associated with the container based on an identifier of the container, and performing a measurement on a file system associated with the container; as well as sending, by the software integrity tool, a representation of the vessel locator tag and a result of the measurement to the AVS; receiving, by the container, from the AVS an attestation result indicating whether the AVS verified the file system associated with the container based on the measurements performed by the software integrity tool; as well as By means of the container, when the attestation result indicates that the AVS has verified the file system associated with the container, the application contained in the container is prepared for execution in the runtime environment.

29. The host computing system of claim 28, further configured to perform one or more of the following: By means of the software integrity tool, operations corresponding to any of the methods described in claims 2-10; and By means of the container, the operation corresponds to any of the methods of claims 12-18.

30. The host computing system of any one of claims 28-29, wherein: The host computing system is further configured to, through the AVS, perform operations corresponding to any of the methods of claims 19-24.

31. A non-transitory computer readable medium (1190) storing software code for a software integrity tool (1150) for a host computing system (410, 710, 1100) configured with a runtime environment (430, 1120), the runtime environment being arranged to execute a container (440, 720, 1141) containing an application (722, 1142), wherein: Execution of the software code by processing circuitry (1160) of the host computing system configures the software integrity tool to perform operations corresponding to any of the methods of claims 1-10.

32. A computer program product (1195) comprising software code for a software integrity tool (1150) for use with a host computing system (410, 710, 1100) configured with a runtime environment (430, 1120), the runtime environment being arranged to execute a container (440, 720, 1141) containing an application (722, 1142), wherein: Execution of the software code by processing circuitry (1160) of the host computing system configures the software integrity tool to perform operations corresponding to any of the methods of claims 1-10.

33. A non-transitory computer-readable medium (1190) storing computer-executable software code for a container (440, 720, 1141) containing an application (722, 1142), wherein: Execution of the software code by processing circuitry (1160) of a host computing system (410, 710, 1100) configures the container to perform operations corresponding to any of the methods of claims 11-18.

34. A computer program product (1195) comprising computer executable software code for a container (440, 720, 1141) containing an application (722, 1142), wherein: Execution of the software code by processing circuitry (1160) of a host computing system (410, 710, 1100) configures the container to perform operations corresponding to any of the methods of claims 11-18.

35. An attestation verification system (AVS) (750, 1155) associated with a host computing system (410, 710, 1100) configured with a runtime environment (430, 1120), the runtime environment being arranged to execute a container (440, 720, 1141) containing an application (722, 1142), the AVS comprising: a memory (1190) storing computer executable instructions; as well as Processing circuitry (1160) configured to execute the instructions, wherein execution of the instructions configures the AVS to: The following items are received from a software integrity tool (1150) of the host computing system: a representation of a container locator label of a container instantiated in the runtime environment, and results of measurements performed by the software integrity tool on a file system associated with the container; performing verification of the file system associated with the container based on the result of the measuring based on detecting a match between the representation of the container locator tag and a previously received representation of the container locator tag; An attestation result is sent to the container, the attestation result indicating whether the AVS verified the file system associated with the container.

36. The AVS of claim 35, wherein: Execution of the instructions further configures the AVS to perform operations corresponding to any of the methods of claims 20-24.

37. An attestation verification system (AVS) (750, 1155) associated with a host computing system (410, 710, 1100) configured with a runtime environment (430, 1120), the runtime environment being arranged to execute a container (440, 720, 1141) containing an application (722, 1142), the AVS being configured to: The following items are received from a software integrity tool (1150) of the host computing system: a representation of a container locator label of a container instantiated in the runtime environment, and results of measurements performed by the software integrity tool on a file system associated with the container; performing verification of the file system associated with the container based on the result of the measuring based on detecting a match between the representation of the container locator tag and a previously received representation of the container locator tag; An attestation result is sent to the container, the attestation result indicating whether the AVS verified the file system associated with the container.

38. The AVS of claim 37, further configured to perform operations corresponding to any of the methods of claims 20-24.

39. A non-transitory computer-readable medium (1190) storing computer-executable instructions that, when executed by a processing circuit (1160) of an attestation verification system (AVS) (750, 1155) associated with a host computing system (410, 710, 1100) configured with a runtime environment (430, 1120), configures the AVS to perform operations corresponding to any of the methods described in claims 19-24, wherein the runtime environment is arranged to execute a container (440, 720, 1141) containing an application (722, 1142).

40. A computer program product (1195) comprising computer executable instructions which, when executed by a processing circuit (1160) of an attestation verification system (AVS) (750, 1155) associated with a host computing system (410, 710, 1100) configured with a runtime environment (430, 1120), configures the AVS to perform operations corresponding to any of the methods described in claims 19-24, wherein the runtime environment is arranged to execute a container (440, 720, 1141) containing an application (722, 1142).

Images