Computer-implemented method, computer program, and computer system (establishing and maintaining trusted communication channels between microservices)

Abstract

To provide a distributed architecture which is more resistant to being impacted by failures.SOLUTION: A CIM, according to one approach, includes: a step of issuing, from a first microservice, a handshake request to a second microservice. In response, a verification request from the second microservice is received at the first microservice. Moreover, in response to receiving the verification request, a first secure element correlated with the first microservice produces credentials associated with the first microservice. The first secure element signs the credentials using a cryptographic key assigned to the first microservice. Furthermore, the signed credentials are sent to the second microservice.SELECTED DRAWING: Figure 3A

Description

Technical Field

[0001] The present invention relates to attestation, and more specifically, the present invention relates to a reliable communication channel between microservices.

Summary of the Invention

Problems to be Solved by the Invention

[0002] As software continues to become more complex, the deployment of monolithic architectures becomes more difficult. For example, in a monolithic architecture, the processing is tightly coupled and executed as a single service. This is relatively straightforward for deploying simple (non-complex) services, but it is significantly difficult to deploy more complex services on a monolithic architecture. For example, if a certain process of a complex service encounters a sudden increase in demand, the entire architecture is scaled to handle the increased demand. As the codebase grows, it becomes increasingly complex to add or improve features in a monolithic architecture, thereby limiting further expansion.

[0003] In an attempt to address some of these problems, microservices architectures have been introduced. In a microservices architecture, an application is built as modular components that execute each process of the application as different microservices. These microservices can be adjusted to provide specific functions according to the situation. Furthermore, microservices can be frequently updated, deployed, and scaled to meet the demand for specific functions of the application. This also results in a more resilient distributed architecture against the impact of failures.

Means for Solving the Problems

[0004] A computer-implemented method (CIM) by one approach comprises issuing a handshake request from a first microservice to a second microservice. In response thereto, in the first microservice, a verification request from the second microservice is received. Further, in response to receiving the verification request, a first secure element associated with the first microservice generates credentials associated with the first microservice. The first secure element signs the credentials using an encryption key assigned to the first microservice. Further, the signed credentials are transmitted to the second microservice.

[0005] A computer program product (CPP) by another approach comprises a set of one or more computer-readable storage media and program instructions. The program instructions are collectively stored within the set of one or more storage media. Further, the program instructions are for causing a set of processors to implement the aforementioned CIM.

[0006] A computer system (CS) by yet another approach comprises a set of processors and a set of one or more computer-readable storage media. The CS further comprises program instructions collectively stored within the set of one or more storage media, and the program instructions are for causing the set of processors to implement the aforementioned CIM.

[0007] Other aspects and approaches of the present invention will become apparent from the following detailed description, which, when interpreted in conjunction with the drawings, illustrate by way of example the principles of the present invention.

Brief Description of the Drawings

[0008]

Figure 1

[0009]

Figure 2A

[0010]

Figure 2B

[0011]

Figure 3A

[0012]

Figure 3B

[0013]

Figure 4

Mode for Carrying Out the Invention

[0014] The following description is made for the purpose of exemplifying the general principles of the present invention and does not mean to limit the concept of the invention claimed in this specification. Further, the specific features described in this specification may be used in combination with other described features in each of various possible combinations and substitutions.

[0015] Unless specifically defined otherwise in this specification, all terms shall be given their broadest possible interpretation including the meaning suggested by this specification, as well as the meaning understood by those skilled in the art and / or defined in dictionaries, treatises, etc.

[0016] As used in this specification and the appended claims, it should also be noted that the singular forms "a", "an", and "the" include plural referents unless the context clearly dictates otherwise. The terms "comprises" and / or "comprising", as used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0017] In the following description, some preferred approaches of systems, methods, and computer program products for performing attestation between microservices are disclosed by offloading operations to be performed by secure elements associated with each microservice. This process can function as a preliminary step to establish a reliable communication channel between microservices that can implement, for example, encryption and / or authentication. The approaches herein preferably enable improving the efficiency of performing attestation between microservices. It should be noted that, as used herein, "attestation", as will be described in more detail below, is intended to refer to the process of proving (e.g., authenticating) one or more properties to a third party.

[0018] In a general approach, the CIM includes issuing a handshake request from a first microservice to a second microservice. In response, a verification request from the second microservice is received at the first microservice. Further, in response to receiving the verification request, a first secure element associated with the first microservice generates credentials associated with the first microservice. The first secure element signs the credentials using an encryption key assigned to the first microservice. Further, the signed credentials are sent to the second microservice.

[0019] Therefore, the various techniques herein will be able to improve the efficiency of performing attestation among microservices. It should be noted that, with respect to this specification, "attestation" is intended to refer to the process of proving (e.g., authenticating) one or more properties of a system to a third party. For example, in confidential computing, attestation is involved in providing proof that the execution environment can be trusted before starting the execution of code or delivering any sensitive data to the execution environment. Thus, by offloading the attestation operations from the microservices themselves and having them satisfied by secure elements correlated with each microservice, the techniques herein can efficiently establish a reliable communication connection among microservices. Further, by evaluating the microservices in real time and identifying changes, the communication channel can be adjusted accordingly. This enables the techniques herein to generate and dynamically maintain a reliable communication channel without affecting the performance of the system as a whole.

[0020] In some implementations, the first microservice is in the first container of the first data center, while the second microservice is in the second container of the second data center. Thus, the stage of generating the credentials associated with the first microservice may have a stage of generating the credentials using an active Platform Configuration Register (PCR) corresponding to the first microservice in the first container. The stage of generating the credentials associated with the first microservice has a stage of generating the credentials using an active PCR corresponding to the first microservice in the first container. Further, the active PCR is updated in response to the first microservice and / or the first container being modified. The first secure element generates updated credentials using the updated PCR. The first secure element also signs the updated credentials using the cryptographic key assigned to the first microservice. Further, the signed updated credentials may be sent to the second microservice.

[0021] As mentioned above, by offloading the attestation operation from the microservice itself and utilizing the secure element associated with each microservice, it becomes possible to establish and maintain a reliable communication connection between microservices in real time without adversely affecting the performance of the entire system. This is particularly desirable in view of the drawbacks encountered by conventional products. Thus, by using PCR to generate credentials, the efficiency of performing attestation between microservices is improved.

[0022] In some implementations, the first secure element includes a certification authority and a policy checker. Further, the certification authority may be configured to generate the credentials associated with the first microservice. The certification authority may also be configured to sign the credentials using the cryptographic key assigned to the first microservice.

[0023] The policy checker preferably compares the generated credentials with the policies associated with each microservice. In some approaches, these policies are pre-assigned to their respective microservices to at least somewhat control other microservices whose connection to a given microservice is permitted (e.g., trusted). For example, a policy may be assigned to a microservice during the process of creating the microservice. Further, by generating credentials associated with a first microservice, a certification authority can maintain a communication connection between the associated microservices. Desirably, this improves the operation of the microservices and the overall comprehensive service and larger system.

[0024] In some implementations, the CIM further comprises issuing a new verification request to the third microservice in response to receiving a second handshake request from the third microservice. In response to receiving signed credentials from the third microservice, the first secure element verifies the signed credentials received from the third microservice. Further, the step of verifying the signed credentials received from the third microservice may include causing the policy checker of the first secure element to compare the signed credentials received from the third microservice with the policy assigned to the first microservice.

[0025] Accordingly, the implementation herein will be able to monitor and maintain multiple different connections simultaneously. Desirably, this will extend the improvements realized herein across various microservices, even in situations where microservices are updated periodically, migrated over time, and referenced by new microservices. Each of these changes affects the existing connections between microservices and is considered in determining whether each connection can still survive (e.g., be trusted). In contrast, conventional products are not able to do this efficiently and have encountered significant performance stalls.

[0026] In some implementations, CIM further comprises issuing a new verification request to a third microservice in response to receiving a second handshake request from the third microservice. In response to receiving signed credentials from the third microservice, the first secure element verifies the signed credentials received from the third microservice. The step of verifying the signed credentials received from the third microservice may include causing a policy checker of the first secure element to compare the signed credentials received from the third microservice with the policy assigned to the first microservice. Further, the step of verifying the signed credentials received from the third microservice may further include satisfying the second handshake request by establishing a communication channel between the first microservice and the third microservice in response to the policy checker determining that the signed credentials received from the third microservice satisfy the policy assigned to the first microservice.

[0027] Repeatedly, the implementation of this specification can simultaneously monitor and maintain connections between different microservices. These connections between microservices are, at least in part, based on policies assigned to each microservice and used to determine whether to establish and / or maintain a connection. Desirably, this allows the improvements realized in this specification to be extended across various microservices, even in situations where microservices are periodically updated, migrated over time, and referenced by new microservices, etc.

[0028] In some implementations, the CIM further comprises issuing a new verification request to the third microservice in response to receiving a second handshake request from the third microservice. In response to receiving signed credentials from the third microservice, the first secure element verifies the signed credentials received from the third microservice. The step of verifying the signed credentials received from the third microservice may include causing a policy checker of the first secure element to compare the signed credentials received from the third microservice with the policy assigned to the first microservice. Further, the step of verifying the signed credentials received from the third microservice may further include rejecting the second handshake request in response to the policy checker determining that the signed credentials received from the third microservice do not satisfy the policy assigned to the first microservice.

[0029] As mentioned above, the monitoring and maintenance of connections between different microservices is based, at least in part, on policies assigned to each microservice. Thus, these policies are used to determine whether a connection should be established and / or maintained. Thus, in situations where the policies are not satisfied, it follows that the communication channel should not be established and / or maintained. Desirably, this avoids situations where microservices are abused using the communication channel and protected information is disclosed.

[0030] In another exemplary approach, the CPP comprises a set of one or more computer-readable storage media and program instructions. The program instructions are collectively stored within the set of one or more storage media. Further, the program instructions are for causing a set of processors to perform any combination of the methodologies described above. Thus, the CPP is capable of realizing the improvements described above by performing combinations of the methodologies described above.

[0031] In yet another exemplary approach, the CS comprises a set of processors and a set of one or more computer-readable storage media. The CS further comprises program instructions collectively stored in the set of one or more storage media, the program instructions being for causing the set of processors to perform any combination of the methodologies described above. Thus, the CS is capable of realizing the improvements described above by performing combinations of the methodologies described above.

[0032] For certain uses of the technique, using the CIM described above, it can be determined whether two microservices located in different containers of the edge node's operating system should be connected via a communication channel. In other words, using the CIM described above, attestation can be performed between microservices at a given edge node. Each microservice can be connected to each secure element having an authentication authority element and a policy checker element. Any of the microservices can request a communication channel with another of the microservices, where the requesting microservice is evaluated to determine whether a trustworthy connection should be established there. As mentioned above, this determination is made, at least in part, by comparing the authenticated (e.g., known) information about the requesting microservice to determine whether to communicate with it. This process can function as a preliminary step in establishing a trustworthy communication channel between microservices that can implement, for example, encryption and / or authentication.

[0033] Various aspects of the present disclosure are illustrated by the description, flowcharts, block diagrams of computer systems, and / or block diagrams of the mechanical logic included in the approach of a computer program product (CPP). For any flowchart, the operations may be performed in a different order than that shown in a given flowchart, depending on the technology involved. For example, again depending on the technology involved, two operations shown in consecutive flowchart blocks may be performed in reverse order, as a single integrated step, simultaneously, or at least partially overlapping in time.

[0034] The term "computer program product approach" (the "CPP approach" or "CPP") is used in this disclosure to describe any set of one or more storage media (also referred to as "mediums") that collectively contain a set of one or more storage devices that collectively contain machine-readable code corresponding to instructions and / or data for performing the computer operations defined in a given CPP claim. A "storage device" is any tangible device capable of holding and storing instructions for use by a computer processor. By way of non-limiting example, a computer-readable storage medium may be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media are floppy disks, hard disks, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanically encoded devices (such as punch cards or pits / lands formed on the major surfaces of disks), or any suitable combination of the foregoing. A computer-readable storage medium is not to be construed as storage in the form of a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, optical pulses passing through an optical fiber cable, electrical signals transmitted through a wire, and / or other transmission media. As will be understood by those skilled in the art, data is typically moved at some irregular points during the normal operation of a storage device, such as during access, defragmentation, or garbage collection, but since the data is not transient while it is stored, the foregoing does not cause the storage device to be considered transient.

[0035] Computing environment 100 includes an example of an environment for executing at least a portion of the computer code involved in the implementation of the method of the present invention, such as improved attestation code in block 150 for performing attestation among microservices by offloading operations to be performed by secure elements associated with each microservice. This process can function as a preliminary step for establishing a reliable communication channel among microservices that can implement, for example, encryption and / or authentication.

[0036] In addition to block 150, computing environment 100 includes, for example, computer 101, wide area network (WAN) 102, end user device (EUD) 103, remote server 104, public cloud 105, and private cloud 106. In this approach, computer 101 includes a processor set 110 (including processing circuit 120 and cache 121), communication fabric 111, volatile memory 112, persistent storage 113 (including operating system 122 and block 150 identified above), a set of peripheral devices 114 (including a set of user interface (UI) devices 123, storage 124, and a set of Internet of Things (IoT) sensors 125), and network module 115. Remote server 104 includes remote database 130. Public cloud 105 includes gateway 140, cloud orchestration module 141, a set of host physical machines 142, a set of virtual machines (VMs) 143, and a set of containers 144.

[0037] Computer 101 may take the form of any other form of computer or mobile device now known or to be developed in the future that can execute a program, access a network, or query a database such as remote database 130, such as a desktop computer, laptop computer, tablet computer, smartphone, smartwatch, or other wearable computer, mainframe computer, quantum computer. As is well understood in the field of computer technology and depending on the technology, the implementation of the computer implementation method may be distributed among multiple computers and / or among multiple locations. On the other hand, in this description of computing environment 100, for the sake of simplicity as much as possible, the detailed discussion focuses on a single computer, specifically computer 101. Although computer 101 is not shown within the cloud in FIG. 1, it may be located within the cloud. On the other hand, computer 101 does not need to exist within the cloud, except within any arbitrarily shown range.

[0038] Processor set 110 includes one or more computer processors of any type now known or to be developed in the future. Processing circuit 120 may be distributed among multiple packages, such as multiple interconnected integrated circuit chips. Processing circuit 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is a memory located within the processor chip package and is typically used for data or code that should be available for fast access by threads or cores executing on processor set 110. Cache memory is typically organized into multiple levels depending on its relative proximity to the processing circuit. Alternatively, some or all of the cache for the processor set may be located "off-chip". In some computing environments, processor set 110 may be designed to operate using qubits to perform quantum computing.

[0039] Computer-readable program instructions are typically loaded into computer 101 and cause a set of operational steps to be performed on a processor set 110 of computer 101, thereby executing a computer-implemented method, and thus the instructions so executed will instantiate the method (collectively referred to as "the method of the present invention") defined in the flowchart and / or description of the computer-implemented method included in this document. These computer-readable program instructions are stored in various types of computer-readable storage media such as cache 121 and other storage media discussed below. The program instructions and associated data are accessed by processor set 110 to control and direct the implementation of the method of the present invention. In computing environment 100, at least some of the instructions for implementing the method of the present invention may be stored in block 150 of persistent storage 113.

[0040] Communication fabric 111 is a signal conduction path that enables various components of computer 101 to communicate with each other. Typically, this fabric is created with switches and conductive paths such as buses, bridges, physical input / output ports, and switches and conductive paths that make up the like. Other types of signal communication paths such as optical fiber communication paths and / or wireless communication paths may be used.

[0041] Volatile memory 112 is any type of volatile memory known now or to be developed in the future. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory 112 is characterized by random access, although this is not required unless expressly stated. In computer 101, volatile memory 112 is located within a single package and exists inside computer 101, but alternatively or additionally, volatile memory may be distributed across multiple packages and / or located external to computer 101.

[0042] The persistent storage 113 is any form of non-volatile storage for a computer, whether currently known or to be developed in the future. The non-volatility of this storage means that the stored data is maintained regardless of whether power is being supplied to the computer 101 and / or directly to the persistent storage 113. The persistent storage 113 may be read-only memory (ROM), but typically at least a portion of the persistent storage enables writing of data, deletion of data, and rewriting of data. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. The operating system 122 may take several forms, such as various known proprietary operating systems that employ a kernel or open-source portable operating system interface type operating systems. The code included in block 150 typically includes at least some of the computer code involved in the implementation of the method of the present invention.

[0043] The peripheral device set 114 includes a set of peripheral devices of the computer 101. Data communication connections between the peripheral devices of the computer 101 and other components may be implemented in various forms such as a Bluetooth (registered trademark) connection, a Near Field Communication (NFC) connection, a connection by a cable (such as a Universal Serial Bus (USB) type cable), an insertion type connection (such as a Secure Digital (SD) card), a connection through a local area communication network, and even a connection through a wide area network such as the Internet. In various methods, the UI device set 123 may include components such as a display screen, a speaker, a microphone, wearable devices (such as Google glasses and smartwatches), a keyboard, a mouse, a printer, a touchpad, a game controller, and a haptic device. The storage 124 is an external storage such as an external hard drive or an insertable storage such as an SD card. The storage 124 may be persistent and / or volatile. In some methods, the storage 124 may take the form of a quantum computing storage device for storing data in the form of qubits. In a method where the computer 101 is required to have a large amount of storage (for example, the computer 101 locally stores and manages a large-scale database), in this case, this storage may be provided by a peripheral storage device designed to store a very large amount of data, such as a storage area network (SAN) shared by a plurality of geographically distributed computers. The IoT sensor set 125 is composed of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer, and another sensor may be a motion detector.

[0044] The network module 115 is a collection of computer software, hardware, and firmware that enables the computer 101 to communicate with other computers through the WAN 102. The network module 115 may include hardware such as a modem or a Wi-Fi (registered trademark) signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for transmitting data over the Internet. In some approaches, the network control function and the network transfer function of the network module 115 are implemented on the same physical hardware device. In other approaches (e.g., approaches that utilize software-defined networking (SDN)), the control function and the transfer function of the network module 115 are physically implemented on separate devices so that the control function manages several different network hardware devices. The computer-readable program instructions for implementing the method of the present invention can usually be downloaded to the computer 101 from an external computer or an external storage device through a network adapter card or a network interface included in the network module 115.

[0045] The WAN 102 is any wide area network (e.g., the Internet) that can transmit computer data over a non-local distance by any technology for transmitting computer data known now or to be developed in the future. In some approaches, the WAN 102 may be replaced and / or supplemented by a local area network (LAN) designed to transmit data between devices located in a local area, such as a Wi-Fi (registered trademark) network. The WAN and / or LAN usually includes computer hardware such as copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and edge servers.

[0046] The end-user device (EUD) 103 is any computer system used and controlled by an end user (e.g., a customer of the enterprise operating the computer 101), and can take any of the forms discussed above in relation to the computer 101. The EUD 103 typically receives beneficial and useful data from the operation of the computer 101. For example, in a hypothetical case where the computer 101 is designed to provide recommendations to the end user, this recommendation would typically be transmitted from the network module 115 of the computer 101 to the EUD 103 via the WAN 102. Thus, the EUD 103 can display or otherwise present the recommendation to the end user. In some approaches, the EUD 103 can be a client device such as a thin client, a thick client, a mainframe computer, a desktop computer, etc.

[0047] The remote server 104 is any computer system that provides at least some data and / or functionality to the computer 101. The remote server 104 may be controlled and used by the same entity that operates the computer 101. The remote server 104 represents a machine that collects and stores beneficial and useful data for use by other computers such as the computer 101. For example, in a hypothetical case where the computer 101 is designed and programmed to provide recommendations based on historical data, in this case, this historical data can be provided from the remote database 130 of the remote server 104 to the computer 101.

[0048] The public cloud 105 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computing capabilities, particularly data storage (cloud storage) and computing power, without direct active management by the user. Cloud computing typically exploits resource sharing to achieve economies of consistency and scale. The direct active management of the computing resources of the public cloud 105 is performed by the computer hardware and / or software of the cloud orchestration module 141. The computing resources provided by the public cloud 105 are typically implemented by a virtual computing environment that runs on various computers that make up the host physical machine set 142, which is a collection (universe) of physical computers that are within and / or available to the public cloud 105. The virtual computing environment (VCE) typically takes the form of VMs from the VM set 143 and / or containers from the container set 144. These VCEs may be stored as images and can be understood to be transferable as images or after instantiation of the VCE among and between various physical machine hosts. The cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of the VCE, and manages the active instantiation of VCE deployments. The gateway 140 is a collection of computer software, hardware, and firmware that enables the public cloud 105 to communicate via the WAN 102.

[0049] Here, some further explanation is provided about the virtualized computing environment (VCE). The VCE can be stored as an "image". A new active instance of the VCE can be instantiated from the image. Two well-known types of VCEs are VMs and containers. A container is a VCE that uses operating system-level virtualization. This refers to a feature of the operating system that enables the kernel to have multiple isolated user space instances called containers. These isolated user space instances typically behave as actual computers from the perspective of the programs running within them. A computer program running on a general operating system can utilize all the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running inside a container can only use the contents of the container and the devices assigned to that container, and this feature is known as containerization.

[0050] The private cloud 106 is similar to the public cloud 105, except that computing resources are available only for use by a single enterprise. The private cloud 106 is shown as being in communication with the WAN 102, but in other approaches, the private cloud may be completely disconnected from the Internet and accessible only via a local / private network. A hybrid cloud is a composite of multiple different types of clouds (e.g., private, community, or public cloud types), often implemented by different vendors. Each of the multiple clouds remains a separate discrete entity, but the larger hybrid cloud architecture is coupled together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the constituent clouds. In this approach, both the public cloud 105 and the private cloud 106 are part of a larger hybrid cloud.

[0051] Cloud computing services and / or microservices (not shown separately in FIG. 1): Private and public clouds 106 are programmed and configured to deliver cloud computing services and / or microservices (unless otherwise indicated, the term "microservice" should be construed as being included in the larger "service" regardless of size). Cloud services are typically infrastructure, platform, or software hosted by a third-party provider and made available to users via the Internet. Cloud services facilitate the flow of user data that travels from a front-end client (e.g., a user-side server, tablet, desktop, laptop) to and from the provider's system via the Internet. In some approaches, cloud services can be configured and orchestrated according to the "as a service" technology paradigm that presents something to internal or external customers in the form of cloud computing services. In the provision of as a service, typically, endpoints are provided where various customers interface. These endpoints are typically based on a set of APIs. One category of as a service provision is Platform as a Service (PaaS), where the service provider provides, instantiates, runs, and manages a modular bundle of code that customers can use to instantiate a computing platform and one or more applications without the complexity of building and maintaining the infrastructure normally associated with these. Another category is Software as a Service (SaaS), where the software is hosted centrally and assigned on a subscription basis. SaaS is also known as on-demand software, web-based software, or software hosted on the web.The four technical sub - fields involved in cloud services are deployment, integration, on - demand, and virtual private network.

[0052] In some aspects, systems by various means may include a processor and logic integrated with and / or executable by the processor, the logic being configured to perform one or more of the processing steps listed herein. The processor may be of any configuration described herein, such as a discrete processor or processing circuit including many components such as processing hardware, memory, I / O interface, etc. "Integrated" means that the processor has logic embedded therein as hardware logic such as an application - specific integrated circuit (ASIC), FPGA, etc. "Executable by the processor" means that the logic is hardware logic; software logic such as firmware, a part of an operating system, a part of an application program, etc.; or any combination of hardware and software logic that is accessible by the processor and configured to cause the processor to perform some function when executed by the processor. As is known in the art, software logic may be stored in local and / or remote memory of any memory type. Any processor known in the art may be used, such as software processor modules, and / or hardware processors such as ASICs, FPGAs, central processing units (CPUs), integrated circuits (ICs), graphics processing units (GPUs), etc.

[0053] Of course, this logic may be implemented in various ways as a method on any device and / or system, or as a computer program product.

[0054] As previously mentioned, software has continued to become more complex, thereby making the deployment of monolithic architectures more difficult. For example, in a monolithic architecture, the processing is tightly coupled and executed as a single service. This is relatively straightforward for deploying simple (non-complex) services, but immediate problems arise when deploying more complex services on a monolithic architecture. For instance, if a certain processing of a complex service encounters a sudden increase in demand, the entire architecture has to be scaled to accommodate the increased demand. As the codebase grows, adding or improving features in a monolithic architecture also becomes increasingly complex, thereby limiting further expansion.

[0055] In an attempt to address some of these problems, microservices architectures have been introduced. In a microservices architecture, an application is built as a modular component that executes each processing of the application as a different microservice. These microservices can be adjusted to provide specific functions according to the situation. Furthermore, microservices can be updated, deployed, and scaled as needed, for example, to satisfy the demand for specific functions of an application. This also results in a more resilient distributed architecture against the impact of failures.

[0056] An architecture that supports microservices has introduced a number of desirable features, but traditional products have struggled with undesirable performance. For example, traditional products have struggled to establish and maintain reliable connections between active microservices. As mentioned above, microservices are regularly updated, migrated over time, and referenced by new microservices, etc. Each of these changes affects the existing connections between microservices, and it must be considered whether each connection is still trusted. For example, the "zero trust" principle is a high-level strategy used to build a reliable distributed system. In this strategy, an entity attempting to access a resource is assumed not to be automatically trusted even if it is inside the same network. Therefore, each entity is trusted only after being authenticated and attested, and it becomes possible to participate in the system's network, receive confidential data, perform computational tasks, etc. However, traditional products have not been able to do so efficiently and securely and have encountered significant performance bottlenecks.

[0057] In contrast to these conventional drawbacks, desirably, the techniques herein are capable of improving the efficiency and security of performing attestation between microservices. For example, by offloading the attestation operation from the microservices themselves and utilizing secure elements associated with each microservice, the techniques herein can establish and maintain a reliable communication connection between microservices in real time without affecting the performance and security of the overall system. Conventionally, credentials (e.g., cryptographic keys such as passwords, TLS private keys, etc.) have been stored in the memory of the service. Thus, if the service is compromised, an attacker can steal these credentials and impersonate the service. Instead, the secure elements store these credentials in their memory that is not directly accessible to the service. The service can simply request the secure elements to perform encryption operations using the credentials from secure element to secure element, but does not have direct access to them. The techniques herein also implement short-lived credentials that are frequently regenerated to limit the risk of leakage (e.g., disclosure). This is made possible because, as will be described in more detail below, the security element automatically re-creates these credentials, thus eliminating the central entity (e.g., administrator, key management service, etc.) from the process of re-creating the credentials and distributing them.

[0058] Referring now to FIGS. 2A-2B, a representative diagram of a distributed system 200 configured as a container orchestration platform according to one technique is shown. Specifically, FIG. 2A provides a representative diagram of the physical components included in the distributed system 200 according to one technique. FIG. 2B shows a more detailed diagram of the interaction between two microservices 236, 248 that are executed as part of the execution environments 230, 232 presented in FIG. 2A.

[0059] However, this is not intended to be limiting in any way, and one or more of the components shown in FIGS. 2A-2B may be implemented in a different form in other approaches. By way of example, a physical component may be replaced with a corresponding virtual element. For instance, one or more of the processors in FIG. 2A may be replaced with virtual processors in some approaches. In other approaches, one or more of the physical processor components may be replaced with a container or a VM.

[0060] It should also be noted that this system 200 may be implemented in conjunction with features by any other approach enumerated herein, such as those described with reference to other figures. However, this system 200 and other systems presented herein may be used in a variety of applications and / or substitutions, which may or may not be specifically described in the exemplary approaches or implementations enumerated herein. Further, the system 200 presented herein may be used in any desired environment. Thus, FIGS. 2A-2B, and other figures, may be considered to include any possible substitutions.

[0061] As shown in FIG. 2A, the distributed system 200 includes a plurality of physical components internally. For example, the system 200 is shown as including a central node 202 connected to a first node 204 and a second node 206. Specifically, the central node 202, the first node 204, and the second node 206 are each connected to a network 210. The network 210 can be of any type, depending on the desired approach. For example, in some approaches, the network 210 is a WAN such as the Internet. However, an exemplary list of other network types that the network 210 can implement includes, but is not limited to, LAN, PSTN, SAN, internal telephone network, etc. As a result, any desired information, data, commands, instructions, responses, requests, etc. can be transmitted between the nodes 204, 206, and / or 202, regardless of the amount of isolation existing between them and even if they are located in different geographical locations.

[0062] It should also be noted that two or more of the nodes 204, 206, 202 may be connected to each other in different forms depending on the approach. By way of an example not intended to limit the invention in any way, two or more edge nodes (e.g., computing nodes) may be positioned relatively close to each other and connected by a wired connection such as a cable, fiber optic link, wire, etc., or by any other type of connection that will become apparent to those skilled in the art after reading this specification.

[0063] Continuing to refer to FIG. 2A, the first and second nodes 204, 206 may have a configuration different from that of the central node 202. For example, the first and second nodes 204, 206 may be edge nodes, while the central node 202 functions as a central location that provides scalable cloud computing and / or data storage. Accordingly, the first node 204 includes a processor 216 coupled to a memory 218, the second node 206 includes a processor 220 coupled to a memory 222, while the central node 202 includes a large-scale (e.g., robust) processor 212 coupled to a cache 209 and a data storage array 214 having a relatively large storage capacity (e.g., at least larger than the cache 209). Thus, the central node 202 can process and store a relatively large amount of data, thereby enabling it to be connected to and manage a plurality of different remote nodes (e.g., edge node servers).

[0064] Each of the processors 212, 216, 220 may be capable of managing one or more operating systems (OS) at each node location 202, 204, 206. For example, a processor that supports virtualization can include a host OS and a guest OS. Accordingly, the processors 212, 216, 220 are shown as supporting a host OS 230 in addition to a guest OS 232. The OSs 230, 232 are numbered and illustrated in the same way in each of the processors 212, 216, 220, but this is not intended to be limiting in any way. In other words, each of the processors 212, 216, 220 may implement an OS of any desired type and / or configuration internally. By way of non-limiting example, the processor 212 may implement a first type of host OS and a first type of guest OS, while the processor 216 implements a second type of host OS and a second type of guest OS. In another non-limiting example, a processor that does not support virtualization may implement only a host OS.

[0065] Each of processors 212, 216, and 220 may also include a plurality of containers within operating systems 230, 232. In this approach, guest operating system 232 may include a plurality of different containers. Each of the containers can be used to execute small-scale microservices, software processes, larger-scale applications, and the like. Thus, each container may include executable files, binary code, libraries, and configuration files associated with the implementation of microservices, software processes, large-scale applications, and the like. However, as will be understood by those skilled in the art, for example, after reading this specification, in other approaches, microservices may be executed directly within a virtual machine or within a container of a virtual machine. For the purposes of this specification, it should be noted that "microservice" is intended to refer to a modular service that each supports a specific task within a larger collective application. In other words, a large-scale application may be divided into specific tasks, each of which may be realized by different microservices.

[0066] Referring now to FIG. 2B, a more detailed diagram of containers and corresponding microservices according to one approach is shown. First, referring to central node 202, host operating system 230 and guest operating system 232 are executed on processor 212. Further, container 234 includes microservice 236. Microservice 236 may be configured to provide a specific function according to a desired approach. Further, microservice 236 may be updated, deployed, and scaled as needed, for example, to satisfy the demand for a specific function of an application. Similarly, processor 216 of node 204 includes host operating system 230 and guest operating system 232, which include container 246 and microservice 248.

[0067] Also, microservice 236 is shown as sharing a connection with secure element 238, while microservice 248 is connected to secure element 250. Thus, microservice 236 and secure element 238 can communicate with each other by sending data, requests, responses, etc. between them. Similarly, microservice 248 and secure element 250 can communicate with each other by sending data, requests, responses, etc. between them. In some approaches, secure elements 238, 250 may be assigned to respective microservices 236, 248 as part of establishing the microservices. Thus, it is preferred that each microservice be connected to (or "correlated" with) each secure element. This enables offloading at least some operations to the secure element. For example, as will be described in more detail below, an attestation can be performed in response to receiving a communication request, using a secure element for example.

[0068] Depending on the approach, communication (e.g., information exchange) between a microservice and a corresponding secure element may be realized using different types of connections according to a specific approach. For example, in some approaches, the microservice is software executed by a physical computer, while the secure element is a chip connected to the motherboard of the physical computer. Thus, the microservice can have access to and communicate with the secure element via a direct physical connection to the chip within the hardware. In other approaches, the microservice may be implemented within a virtual environment (e.g., a cloud environment). Thus, the microservice may be executed within a VM, while the secure element is a physical component that can be exposed to the VM. In other approaches, the processing may actually implement a secure element that is executed on the host operating system and can be exposed to the VM. The VM and the processor may further have access to shared memory through a hypervisor, via a network connection, etc. In yet other approaches, the microservice may be software executed within a confidential computing environment. Thus, as a result of satisfying some attestation procedure, the microservice may be able to establish access to another process (e.g., a secure element) implemented within the confidential computing environment.

[0069] Continuing to refer to FIG. 2B, the secure elements 238, 250 each include a respective policy checker element 240, 252 and a respective certification authority element 242, 254. The secure elements 238, 250 each also include a respective PCR 244, 256. Thus, each of the PCRs 244, 256 may internally include a plurality of different values (e.g., hash values) corresponding to the actively executing software. In some approaches, one or both of the secure elements 238, 250 is a physical Trusted Platform Module (TPM), or a physical device implementing all or a subset of the TPM specification. By way of non-limiting example, a hardware security module may implement at least a subset of the TPM specification. Further, as will be understood by one of ordinary skill in the art after reading this specification, this enables a hardware security module to virtualize a desired number of TPMs. However, in other approaches, one or both of the secure elements 238, 250 is a virtual TPM.

[0070] Preferably, the policy checker elements 240, 252 are each configured to complete at least a portion of the handshake request. This can be achieved by comparing information associated with the source of the handshake request (e.g., credentials received therefrom) with one or more policies that outline specific criteria used to determine whether the handshake request should be approved. Each of the different policy checker elements 240, 252 may include the same, similar, and / or different policies from one another. Thus, the policy checker elements 240, 252 may be adjusted to apply a desired set of policies while evaluating the handshake request information.

[0071] For example, in some approaches, the policy may be defined such that only handshake requests received from other microservices running within the same data center are approved. In other approaches, the policy may outline that handshake requests received from other microservices running within a specific OS and firmware may be approved. This can be determined using the Unified Extensible Firmware Interface (UEFI) and OS boot measurements on the host machine. In another approach, the policy may outline that handshake requests received from other microservices running within a specific OS within a VM may be approved. In another approach, the policy may outline that handshake requests received from other microservices running within a specific OS within a container may be approved. In another approach, the policy may outline that handshake requests received from a host machine associated with a specific entity (e.g., organization, user, application, etc.) may be approved. This can be determined using the hash of the specific entity within the host machine's PCR. In another approach, the policy may outline that handshake requests received from a VM associated with a specific entity (e.g., organization, user, application, etc.) may be approved. In another approach, the policy may outline that in a first microservice, handshake requests received from other microservices that approve handshake requests from the first microservice may be approved. In another approach, the policy may outline that handshake requests received from a predefined physical location may be approved. For example, in a first microservice, the policy may outline that handshake requests received from microservices running within the same data center as the first microservice may be approved.

[0072] Preferably, the certificate authority elements 242, 254 are each configured to generate information used to verify identification information during a handshake request. In some approaches, the certificate authority elements 242, 254 can each be configured to generate credentials corresponding to a desired encryption protocol. For example, the certificate authority elements 242, 254 can each be configured to generate Transport Layer Security (TLS) credentials that include the current PCR. However, in other approaches, the TLS credentials can include a hash from multiple PCRs. Thus, the TLS credentials can be generated to include a subset of the PCRs. Preferably, the certificate authority elements 242, 254 are also each configured to automatically generate updated credentials in response to the current PCR being modified (e.g., updated). Thus, the certificate authority elements 242, 254 can maintain communication connections between correlated microservices despite updates being made to the microservices themselves and / or the containers in which they are running internally. Desirably, this improves the operation of the microservices, as well as the overall service and larger system.

[0073] PCRs 244 and 256 store information correlated with each microservice 236, 248. In some approaches, PCRs 244 and 256 each accumulate a plurality of hash values corresponding to (e.g., defining) the software currently running within each container 234, 246. For example, PCRs 244 and 256 may each internally aggregate fingerprints corresponding to the microservices 236, 248 (and other software) running within each container 234, 246. In other words, the aggregated fingerprints within the PCRs describe the software currently running in the correlated parts of the system, the configuration of the running software, the version of the running software, the data center in which the software is running, the owner of the running software, etc. Thus, credentials can be created using the information contained in the fingerprints. By way of one non-limiting example, as would be understood by one of ordinary skill in the art after reading this specification, the information within the current PCRs may be included in the generated TLS credentials.

[0074] Again, while the architecture supporting microservices has introduced a number of desirable features, conventional products have struggled with performance degradation. For example, conventional products have struggled to establish and maintain reliable connections between active microservices. For example, conventional products perform integrity attestation in a separate step that can only be performed if the system or platform implements such features that use a TPM, vTPM, or other element. As mentioned above, microservices are periodically updated, migrated over time, and referenced by new microservices, etc. Each of these changes affects the existing connections between microservices, and it must be considered whether each connection remains viable (e.g., trusted). However, conventional products have not been able to do so efficiently and have encountered significant performance stalls.

[0075] In sharp contrast to these conventional drawbacks, the approach of the present specification can desirably improve the efficiency of performing attestation among microservices. For the present specification, it should be noted that "attestation" is intended to refer to the process of proving (e.g., authenticating) one or more properties of a system to a third party. For example, in confidential computing, attestation is involved in providing proof that the execution environment can be trusted before starting the execution of code or before delivering any sensitive data to the execution environment. Thus, by offloading the attestation operation from the microservices themselves and having them satisfied by secure elements associated with each microservice, the approach of the present specification can efficiently establish a reliable communication connection among microservices. Further, by evaluating microservices in real time and identifying changes, the communication channel can be adjusted accordingly. This enables the approach of the present specification to generate and dynamically maintain a reliable communication channel without affecting the performance of the system as a whole, as will be described in more detail below, for example.

[0076] Referring now to FIG. 3A, a computer-implemented method 300 for performing attestation among microservices is shown according to one approach by offloading the operations to be performed by secure elements associated with each microservice. This process can function as a preliminary step for establishing a reliable communication channel among microservices that can implement, for example, encryption and / or authentication. Method 300 may be implemented according to any of a variety of approaches, particularly those of the environments illustrated in FIGS. 1-2B. Of course, as will be understood by those skilled in the art upon reading the present specification, method 300 may include more or fewer operations than those specifically described in FIG. 3A.

[0077] Each stage of method 300 may be performed by any suitable component of the operating environment. Each of the nodes 301a, 301b, 302a, 302b shown in the flowchart of method 300 may correspond to one or more processors, controllers, computers, etc. located at different locations in the distributed system. For example, node 301a may include one or more virtual processors of a container at a node of the distributed system (see, for example, container 234 in FIG. 2B), while node 301b may include one or more virtual processors of a secure element (see, for example, secure element 238 in FIG. 2B). Further, node 302a may include one or more virtual processors of another container at a different node of the distributed system (see, for example, container 246 in FIG. 2B), while node 302b may include one or more virtual processors of another secure element (see, for example, secure element 250 in FIG. 2B). Thus, commands, data, requests, etc. may be transmitted between each of nodes 301a, 301b, 302a, 302b depending on the technique. However, in some techniques, communication may not be realized between the secure element of node 301b and the secure element of node 302b. Further, it should be noted that, as will be understood by those skilled in the art after reading this specification, for example, the various processes included in method 300 are not intended to be limiting in any way. For example, in some techniques, the data transmitted from node 302a to node 301a may originate from a request transmitted from node 301a to node 302a.

[0078] In various implementations, method 300 may be performed partially or wholly by a controller, a processor, etc., or by some other device having one or more processors internally. It may be implemented in hardware and / or software, and a processor having at least one hardware component, such as a processing circuit, a chip, and / or a module, may be utilized in any device to perform one or more stages of method 300. Exemplary processors include, but are not limited to, a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), combinations thereof, or any other suitable computing device known in the art.

[0079] Referring specifically to the flowchart here, the microservice executed at node 302a may desire to initiate a communication channel with another microservice executed at node 301a. For example, the microservice at node 302a may evaluate and / or apply the information output by the microservice executed at node 301a. In other words, the microservices at nodes 302a and 301a may be configured to interact in some way. Thus, operation 304 includes issuing a handshake request to the microservice executed at node 301a. As will be understood by those skilled in the art after reading this specification, the handshake request may function as an initial stage to establish a communication channel between two locations. In some approaches, the handshake request transmitted in operation 304 is a TLS handshake request. However, in different approaches, other types of operational handshake requests may be utilized.

[0080] In response to receiving a handshake request, node 301a evaluates the request to determine the details associated with the proposed handshake. See operation 306. This enables node 301a to identify the type of communication channel requested, the type of information expected to be transmitted along the communication channel, the source of the request, and so on.

[0081] Operation 308 further includes sending a verification request to the microservice of node 302a. The initial handshake request may include some information associated with the request, but additional details are used to determine whether a reliable communication channel should be established between the two microservices. For example, an encryption key can be used to verify the authenticity of the received request, thereby avoiding communication channels with undesired locations.

[0082] In response to receiving a verification request at node 301a, one or more instructions are sent to the secure element of node 302b. See operation 310. The one or more instructions sent in operation 310 ultimately instruct the secure element to generate credentials associated with the first microservice. For example, the one or more instructions may be directed to the certificate authority element of the secure element of node 302b (see, for example, certificate authority elements 242, 254 of FIG. 2B). In other words, as a result of sending one or more instructions in operation 310, node 302a causes credentials representing the microservice being executed at node 302a to be formed. Thus, operation 312 will include generating the requested credentials at node 302b in response to receiving the one or more instructions sent in operation 310.

[0083] In some approaches, credentials are generated using information stored in the PCR of node 302b and correlated with the microservices of node 302a. For example, the PCR can internally aggregate fingerprints corresponding to microservices (and other software) running, for example, within the same container at node 302a. In other words, the aggregated fingerprint in the PCR describes the software currently running in the system, the configuration of the running software, the version of the running software, the data center where the software is running, the owner of the running software, etc. Thus, credentials can be created using the information contained in the fingerprint. It should also be noted that, for the purposes of this specification, "credentials" is intended to refer to a data structure that provides proof of an identity - based claim. However, the type and / or number of credentials used to provide this proof may vary depending on the desired approach. By way of non - limiting example, operation 310 includes generating TLS credentials using the current PCR.

[0084] Now, referring temporarily to FIG. 3B, an exemplary sub - operation for generating and maintaining credentials in response to a received verification request according to one approach is shown. Thus, one or more of these sub - operations can be used to implement operation 312 of FIG. 3A. However, note that the sub - operations of FIG. 3B are shown according to one approach and are not intended to be limiting in any way.

[0085] As shown, sub-operation 350 includes generating credentials corresponding to the details of each microservice using the fingerprint aggregated within the active (e.g., current) PCR. Thus, for example, as would be understood by those skilled in the art, the generated PCR is up-to-date (e.g., current) and represents an accurate representation of each microservice. This may be achieved using any one or more of the techniques described above with respect to FIG. 3A.

[0086] These credentials can provide an accurate representation of each microservice at the time the credentials are created, but the microservices and the containers in which they are running can change substantially over time. For example, the microservices and / or the containers in which they are running may be updated periodically, migrated, referenced by new microservices, etc. Each of these changes affects the existing connections between microservices and must be considered in determining whether each connection remains trustworthy.

[0087] To account for these changes and ensure that the credentials continue to provide an accurate representation over time, sub-operation 352 includes determining whether each microservice and / or corresponding container has been modified since the credentials were formed in sub-operation 350. The flowchart is shown to repeat sub-operation 352 in response to determining that the microservices and corresponding containers have not been modified since the credentials were formed in sub-operation 350. In other words, the microservices and containers may preferably be continuously monitored, preferably in real-time. The microservices and containers may be monitored in the background so as not to affect ongoing performance while also maintaining efficient performance of the system as a whole.

[0088] The flowchart proceeds to sub-operation 354 in response to determining that the micro-service and / or corresponding container has been modified after the credentials are formed in sub-operation 350. There, sub-operation 354 includes updating the active PCR. In other words, the information representing the micro-service and / or corresponding container stored in the PCR is preferably updated so that the PCR maintains an accurate (e.g., updated) representation. In some approaches, a new PCR may be formed using the modifications applied to the micro-service and / or container. Further, the newly formed PCR may be promoted to the "current" version of the PCR, while the previous version of the PCR is demoted and stored in memory.

[0089] Sub-operation 356 includes generating updated credentials using the updated PCR. As mentioned above, the updated credentials may be generated by the secure element. For example, in some approaches, the updated credentials are generated by a certification authority within the secure element (see, e.g., the certification authority elements 242, 254 of FIG. 2B). Additionally, sub-operation 358 includes cryptographically authenticating the updated credentials generated in sub-operation 356. In other words, sub-operation 358 may include signing the updated credentials using the cryptographic key assigned to the micro-service represented by the updated credentials. For example, the updated credentials may be cryptographically authenticated by a certification authority within the secure element (see, e.g., the certification authority elements 242, 254 of FIG. 2B).

[0090] By cryptographically authenticating the updated credentials, an additional security layer can be added to the credentials themselves. This additional security measure may be implemented in situations where strict protection is required. For example, microservices that use and / or generate sensitive data may be subject to a higher level of consideration. For the purposes of this specification, "sensitive data" as used herein may refer to any type of data that will be restricted and / or controlled in access in some way. For example, sensitive data may include confidential data, data that should remain within the organization and not be shared outside the organization, data that should not be made publicly available, data that a user wishes to keep private, data that receives a higher level of consideration as a result of applicable laws and / or corporate policies (e.g., data associated with children under the age of 13 as defined by the Children's Online Privacy Protection Act), data provided confidentially to another user or entity, and the like.

[0091] Continuing to refer to FIG. 3B, the cryptographically signed updated credentials are preferably sent back to the originator of the verification request that was initially received. As a result, updates to the microservice and / or container can be reflected in any existing and new communication channels. Thus, the sub-operations of FIG. 3B will be able to automatically identify and respond to any changes that occur during runtime.

[0092] Returning now to FIG. 3A, the credentials generated by the secure element of node 302b in operation 312 are returned to the corresponding microservice of node 302a. Refer to operation 314. In some approaches, the credentials may be evaluated to determine authenticity. This enables changes (e.g., corrections) to be made to the credentials before sending them to the originator of the verification request. Desirably, this avoids unintentionally blocking communication between microservices that should otherwise be authorized to communicate with each other.

[0093] Upon proceeding to operation 316, the generated credentials are sent from the microservice of node 302a to the microservice of node 301a. In response to receiving the credentials, preferably, node 301a transfers the credentials to the secure element of node 301b along with one or more instructions for verifying the credentials. Refer to operation 318. In other words, one or more instructions sent to node 301b cause each secure element to verify the received signed credentials. Accordingly, operation 320 includes evaluating the received credentials and determining whether they comply with one or more predefined policies.

[0094] In some approaches, a policy checker element (see, e.g., policy checker elements 240, 252 of FIG. 2B) within the secure element of node 301b can compare the information authenticated in the credentials received from the microservice of node 302a with the policies associated with the microservice of node 301a. In some approaches, these policies are pre - assigned to their respective microservices to at least somewhat control other microservices whose connection to a given microservice is permitted (e.g., trusted). For example, a policy may be assigned to a microservice during the process of creating the microservice. In some approaches, the policies may be modified over time as a result of user input, evaluation of past performance, changing security levels, network bandwidth, etc.

[0095] For example, in some approaches, the policy may be defined such that only handshake requests received from other microservices running within the same data center are approved. In other approaches, the policy may state that handshake requests received from other microservices running within a specific OS and firmware may be approved. This can be determined using the Unified Extensible Firmware Interface (UEFI) and the boot measurements of the OS on the host machine. In another approach, the policy may state that handshake requests received from other microservices running within a specific OS within a VM may be approved. In another approach, the policy may state that handshake requests received from other microservices running within a specific OS within a container may be approved. In another approach, the policy may state that handshake requests received from a host machine associated with a specific entity (e.g., organization, user, application, etc.) may be approved. This can be determined using the hash of the specific entity within the Platform Configuration Register (PCR) of the host machine. In another approach, the policy may state that handshake requests received from a VM associated with a specific entity (e.g., organization, user, application, etc.) may be approved. In another approach, the policy may state that in a first microservice, handshake requests received from other microservices that approve handshake requests from the first microservice may be approved. In another approach, the policy may state that handshake requests received from a predetermined physical location may be approved. For example, in a first microservice, the policy may state that handshake requests received from microservices running within the same data center as the first microservice may be approved.

[0096] Continuing to refer to FIG. 3A, method 300 proceeds from operation 320 to operation 322 in response to determining that the received credentials comply with one or more of the predefined policies. Here, operation 322 includes returning an indication that the verification request has been satisfied. In response to receiving the indication, the microservice of node 301a may approve the initial handshake request received in operation 304. Refer to operation 324. As a result of approving the initial handshake request, a trusted communication channel is created between the microservice of node 301a and the microservice of node 302a. Refer to 326. This enables the two microservices to exchange information as needed between them, thereby enabling the microservices to achieve the desired results. Since changes occur over time, a preferred approach is to also monitor changes such as microservices, containers running the microservices, etc. By identifying these changes in real time, the techniques herein can dynamically update the credentials, thereby making the communication channel more secure and trustworthy. The techniques herein can also support runtime integrity attestation using asynchronous attestation. Thus, microservices can communicate more effectively than was previously achievable.

[0097] Returning to operation 320, method 300 proceeds to operation 328 in response to determining that the received credentials do not comply with one or more of the predefined policies. Here, operation 328 includes returning an indication that the verification request has not been satisfied. In response to receiving the indication, the microservice of node 301a can reject the initial handshake request received in operation 304 and send back a corresponding notification to the requesting-side microservice of node 302a. Refer to operation 330. As a result of rejecting (e.g., denying) the received handshake request, the microservice of node 302a may be prevented from issuing subsequent handshake requests for a predefined amount of time if the predefined conditions are not satisfied, etc.

[0098] Therefore, method 300 would be capable of improving the efficiency of performing attestation among microservices. For example, by offloading the attestation operations from the microservices themselves and having them satisfied by secure elements correlated to each microservice, the techniques herein can efficiently establish a reliable communication connection among microservices. Further, by evaluating the microservices in real time and identifying changes, the communication channel can be adjusted accordingly. This enables the techniques herein to generate and dynamically maintain a reliable communication channel without affecting the performance of the system as a whole. This also results in a distributed architecture in which each microservice is connected to each secure element, and each secure element is configured to automatically generate and update credentials over time. Thus, the credentials support integrity measurements during use. The secure elements are also configured to verify policies.

[0099] It should also be noted that the configuration, number, type, etc. of the nodes illustrated in FIG. 3A are not intended to be limiting in any way. As shown above, each microservice can communicate with any desired number of other microservices. For example, an operating system implemented on an edge node may include a plurality of containers, and each container may support a different microservice. Each microservice may be further connected to each secure element having an authentication authority element and a policy checker element. Each of the microservices may request a communication channel with any other microservice, and furthermore, this any other microservice evaluates the requesting microservice to determine whether a trustworthy connection should be established. As mentioned above, for example, as will be understood by those skilled in the art after reading this specification, this determination is made, at least in part, by comparing the authenticated (e.g., known) information about the requesting microservice to determine whether to communicate with it.

[0100] Referring now to FIG. 4, a logic system 400 is shown that is configured to perform attestation between microservices by offloading operations to secure elements associated with each microservice, by way of an example in use that is not intended to be limiting in any way.

[0101] As shown, the logical system 400 includes a root certificate authority (CA), which is connected to a communicating sequential processes (CSP) CA, which in turn is connected to a cloud CA, which in turn is connected to a host CA. Under the host CA, a first tenant, Tenant 1, and a second tenant, Tenant 2, are connected to VM CA1 and VM CA2, and VM1 and VM2, respectively. VM1 is shown as executing microservice 1, while VM2 is shown as executing microservice 2. VM1 is also connected to a secure element 1, while VM2 is connected to a secure element 2. Preferably, each secure element can compare a policy with a received request, dynamically generate credentials in response to a modification of a microservice and / or VM, store PCR information, etc., according to any of the techniques herein.

[0102] It will be apparent that various features of the foregoing systems and / or methodologies may be combined in any manner to create a plurality of combinations from the description presented above.

[0103] It will be further understood that the techniques of the present invention may be provided in the form of services deployed on behalf of a customer to provide services on demand.

[0104] Although the descriptions of the various techniques of the present invention have been presented for purposes of illustration, it is not intended to be exhaustive or limited to the disclosed techniques. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described techniques. The terms used herein were chosen to best describe the principles of the techniques, practical applications, or technical improvements over technologies found in the marketplace, or to enable other practitioners of ordinary skill in the art to understand the techniques disclosed herein.

Claims

1. Issuing a handshake request from the first microservice to the second microservice; receiving, at the first microservice, a validation request from the second microservice; in response to receiving the validation request, causing a first secure element associated with the first microservice to generate a credential associated with the first microservice; having the first secure element sign the credential using a cryptographic key assigned to the first microservice; and Sending the signed credential to the second microservice. A computer implemented method (CIM) comprising:

2. 2. The CIM of claim 1, wherein the first microservice is in a first container in a first data center and the second microservice is in a second container in a second data center.

3. The step of generating the credentials associated with the first microservice comprises:

3. The CIM of claim 2, further comprising generating the credential using an active platform configuration register (PCR) corresponding to the first microservice in the first container.

4. updating the active PCRs in response to the first microservice and / or the first container being modified; causing the first secure element to generate an updated credential using the updated PCR; having the first secure element sign the updated credential using the cryptographic key assigned to the first microservice; and Sending the signed updated credentials to the second microservice. The CIM of claim 3 further comprising:

5. The first secure element includes a certificate authority and a policy checker, the certificate authority: Creating the credential associated with the first microservice; Signing the credential using the cryptographic key assigned to the first microservice. The CIM of claim 1 , configured as follows:

6. in response to receiving a second handshake request from a third microservice, issuing a new validation request to the third microservice; and In response to receiving a signed credential from the third microservice, causing the first secure element to validate the signed credential received from the third microservice. The CIM of claim 1 , further comprising:

7. The step of verifying the signed credential received from the third microservice includes:

7. The CIM of claim 6, further comprising causing a policy checker of the first secure element to compare the signed credential received from the third microservice with a policy assigned to the first microservice.

8. The step of verifying the signed credential received from the third microservice includes:

8. The CIM of claim 7, further comprising, in response to the policy checker determining that the signed credential received from the third microservice satisfies the policy assigned to the first microservice, satisfying the second handshake request by establishing a communication channel between the first microservice and the third microservice.

9. The step of verifying the signed credential received from the third microservice includes:

8. The CIM of claim 7, further comprising: rejecting the second handshake request in response to the policy checker determining that the signed credential received from the third microservice does not satisfy the policy assigned to the first microservice.

10. Program Instructions Equipped with The program instructions cause the processor set to perform the following computer operations: issuing a handshake request from the first microservice to the second microservice; receiving, in the first microservice, a validation request from the second microservice; In response to receiving the validation request, causing a first secure element associated with the first microservice to generate a credential associated with the first microservice; having the first secure element sign the credential using a cryptographic key assigned to the first microservice; and Sending the signed credential to the second microservice. A computer program for causing the computer to carry out the steps described above.

11. 11. The computer program product of claim 10, wherein the first microservice is in a first container in a first data center and the second microservice is in a second container in a second data center.

12. The step of generating the credentials associated with the first microservice includes:

12. The computer program product of claim 11, comprising generating the credential using an active platform configuration register (PCR) corresponding to the first microservice in the first container.

13. and further comprising program instructions that cause the processor set to perform the following computer operations: updating the active PCRs in response to the first microservice and / or the first container being modified; causing the first secure element to generate an updated credential using the updated PCR; having the first secure element sign the updated credential using the cryptographic key assigned to the first microservice; and Sending the signed updated credentials to the second microservice.

13. A computer program product as claimed in claim 12, for carrying out the steps of:

14. The first secure element includes a certificate authority and a policy checker, the certificate authority: Creating the credential associated with the first microservice; Signing the credential using the cryptographic key assigned to the first microservice.

11. A computer program as claimed in claim 10, configured to:

15. and further comprising program instructions that cause the processor set to perform the following computer operations: in response to receiving a second handshake request from a third microservice, issuing a new validation request to the third microservice; and In response to receiving a signed credential from the third microservice, causing the first secure element to validate the signed credential received from the third microservice. A computer program according to any one of claims 10 to 14 for carrying out the steps of:

16. The step of verifying the signed credential received from the third microservice includes: having a policy checker of the first secure element compare the signed credential received from the third microservice with a policy assigned to the first microservice.

16. The computer program of claim 15, comprising:

17. The step of verifying the signed credential received from the third microservice includes: In response to the policy checker determining that the signed credential received from the third microservice satisfies the policy assigned to the first microservice, satisfying the second handshake request by establishing a communication channel between the first microservice and the third microservice.

17. The computer program of claim 16, further comprising:

18. The step of verifying the signed credential received from the third microservice includes: rejecting the second handshake request in response to the policy checker determining that the signed credential received from the third microservice does not satisfy the policy assigned to the first microservice.

17. The computer program of claim 16, further comprising:

19. Processor set; a set of one or more computer readable storage media; program instructions collectively stored within said set of one or more storage media Equipped with The program instructions cause the processor set to perform the following computer operations: issuing a handshake request from the first microservice to the second microservice; receiving, in the first microservice, a validation request from the second microservice; In response to receiving the validation request, causing a first secure element associated with the first microservice to generate a credential associated with the first microservice; having the first secure element sign the credential using a cryptographic key assigned to the first microservice; and Sending the signed credential to the second microservice. A computer system (CS) for implementing the above.

20. and further comprising program instructions collectively stored within said set of one or more storage media, said program instructions causing said set of processors to perform the following computer operations: in response to receiving a second handshake request from a third microservice, issuing a new validation request to the third microservice; and In response to receiving a signed credential from the third microservice, causing the first secure element to validate the signed credential received from the third microservice. The purpose is to carry out the following: The step of verifying the signed credential received from the third microservice includes: having a policy checker of the first secure element compare the signed credential received from the third microservice with a policy assigned to the first microservice; and In response to the policy checker determining that the signed credential received from the third microservice satisfies the policy assigned to the first microservice, satisfying the second handshake request by establishing a communication channel between the first microservice and the third microservice.

20. The CS of claim 19, comprising:

Images