Method, system, and program for proving logical loader code and checking completeness of service logic code

Abstract

A method for proving the code of a logical loader and checking the integrity of service logic code in a trusted execution environment (TEE) is provided. This method includes executing a proof of the code of the logical loader in the trusted execution environment (TEE), receiving a request for the logical loader to load service logic code into the TEE, performing an integrity check of the service logic code associated with the request, and permitting the logical loader to load the service logic code associated with the request into the TEE in response to the service logic code associated with the request passing the integrity check.

Description

Technical Field

[0001] The present invention relates to a trusted execution environment (TEE), and more particularly, to a confidential computing framework that operates securely within the TEE.

[0002] In response to receiving a request for logical loader code, it often depends on the logical loader to load service logic code in the enclave. The logical loader operates using the logical loader code, and the logical loader code is protected from being compromised by actors outside the secure enclave when it is included in the secure enclave. The service logic code is executed after being loaded and obtains the data required in the request.

Summary of the Invention

[0003] A computer-implemented method according to one embodiment includes performing a proof of the code of a logical loader in a trusted execution environment (TEE) and receiving a request for the logical loader to load service logic code into the TEE. A integrity check of the service logic code associated with the request is performed. In response to the service logic code associated with the request passing the integrity check, the logical loader is permitted to load the service logic code associated with the request into the TEE.

[0004] A computer program product according to another embodiment includes a computer-readable storage medium in which program instructions are embodied. These program instructions are readable and / or executable or both by a computer to cause the computer to perform the above-described method.

[0005] A system according to another embodiment includes a processor and logic integrated with the processor, logic executable by the processor, or logic integrated with and executable by the processor. This logic is configured to perform the methods described above.

[0006] Other aspects and embodiments of the invention will become apparent from the following detailed description, which illustrates the principles of the invention by way of example in conjunction with the drawings.

[0007] Next, preferred embodiments of the invention will be described by way of example only with reference to the following drawings.

Brief Description of the Drawings

[0008]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5A

Figure 5B

Figure 5C

Figure 6

Figure 7

Modes for Carrying Out the Invention

[0009] The following description is made for the purpose of explaining the general principles of the present invention and is not intended to limit the concepts of the present invention claimed herein. Further, the specific features described herein can be used in combination with other described features in each of various possible combinations and permutations.

[0010] In this specification, unless specifically defined otherwise, all terms are given the broadest possible interpretation that includes the meaning implied by this specification, the meaning understood by those skilled in the art, or the meaning defined in a dictionary, treatise, etc., or both.

[0011] It should also be noted that, as used in this specification and the appended claims, the singular forms "a", "an", and "the" include plural referents unless specifically stated otherwise. The terms "comprising", "comprises", or both, when used in this specification, indicate the presence of the described function, integer, step, operation, element, or component, or a combination thereof, but do not preclude the presence or addition of one or more other functions, integers, steps, operations, elements, components, or groups thereof, or a combination thereof.

[0012] The following description discloses multiple embodiments of the proof of the code of the logical loader within the TEE and the integrity check of the service logic code associated with the requirement for the logical loader to load the service logic code into the TEE.

[0013] In one general embodiment, a computer-implemented method includes performing a proof of the code of a logical loader in a trusted execution environment (TEE) and receiving a request for the logical loader to load service logic code into the TEE. A integrity check of the service logic code associated with the request is performed. In response to the service logic code associated with the request passing the integrity check, the logical loader is permitted to load the service logic code associated with the request into the TEE.

[0014] In another general embodiment, a computer program product includes a computer-readable storage medium having program instructions embodied therewith. These program instructions are readable by, executable by, or both readable and executable by a computer to cause the computer to perform the method described above.

[0015] In another general embodiment, a system includes a processor and logic integrated with the processor, logic executable by the processor, or logic integrated with and executable by the processor. This logic is configured to perform the method described above.

[0016] It should be understood that although this disclosure includes a detailed description of cloud computing, the implementation forms of the teachings described herein are not limited to cloud computing environments. Rather, embodiments of the invention can be implemented in conjunction with any other type of computing environment now known or developed in the future.

[0017] Cloud computing is a service delivery model that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services), which can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0018] The characteristics are as follows.

[0019] On-demand self-service: Cloud consumers can unilaterally provision computing capabilities such as server time and network storage automatically as needed, without the need for human interaction with the service provider.

[0020] Broad network access: Cloud capabilities are available over the network and can be accessed using standard mechanisms, facilitating use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0021] Resource pooling: The provider's computing resources are pooled and provided to multiple users using a multi-tenant model, and various physical and virtual resources are dynamically assigned and re-assigned according to demand. Users generally have a sense of location independence in that they are usually unaware of and do not manage the exact location of the resources provided, but at a higher level of abstraction, the location (e.g., country, state, or data center) can be specified.

[0022] Rapid adaptability: The capabilities can be provisioned quickly, flexibly, and in some cases automatically, scale out rapidly, be released quickly, and scale in rapidly. The capabilities available for provisioning often appear to the user to be purchasable in any amount, at any time, without limit.

[0023] Measurability of services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at an abstract level appropriate to the type of service (e.g., storage, processing, bandwidth, active user accounts). The amount of resource usage is monitored, controlled, and reported, providing transparency to both the provider and consumer of the utilized service.

[0024] The service model is as follows.

[0025] SaaS (Software as a Service): The capabilities provided to the user are the use of the provider's applications running on the cloud infrastructure. Those applications can be accessed from various client devices via a thin-client interface such as a web browser (e.g., web-based email). The user does not manage or control the underlying cloud infrastructure, which includes the network, servers, operating systems, storage, or individual application functions, except for limited user-specific application configuration settings.

[0026] PaaS (Platform as a Service): The capabilities provided to users are to deploy the applications created or obtained by users, which are created using the programming languages and tools supported by the provider, onto the cloud infrastructure. Users do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, or storage, but can control the deployed applications and, in some cases, the configuration of the application hosting environment.

[0027] IaaS (Infrastructure as a Service): The capabilities provided to users are the provisioning of processing, storage, network, and other basic computing resources, and users can deploy and run any software that can include the operating system and applications. Users do not manage or control the underlying cloud infrastructure, but can control the operating system, storage, deployed applications, and, in some cases, can limitedly control the selected network components (e.g., host firewall).

[0028] The deployment models are as follows.

[0029] Private cloud: The cloud infrastructure is operated only for an organization. This can be managed by the organization or a third party and can exist on-premises or off-premises.

[0030] Community cloud: The cloud infrastructure is shared by multiple organizations and supports a specific community with common concerns (e.g., mission, security requirements, policies, and compliance considerations). This can be managed by an organization or a third party and can exist on-premises or off-premises.

[0031] Public cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization that sells cloud services.

[0032] Hybrid cloud: The cloud infrastructure remains a unique entity but is a composite of two or more clouds (private, community, or public) joined by standardized or proprietary technologies (e.g., cloud bursting for load balancing between clouds) that enable data and application portability.

[0033] Cloud computing environments are service-oriented, centered around statelessness, low coupling, modularity, and semantic interoperability. At the center of cloud computing is the infrastructure, which includes a network of interconnected nodes.

[0034] Referring now to FIG. 1, an exemplary cloud computing environment 50 is shown. As illustrated, cloud computing environment 50 includes one or more cloud computing nodes 10 that are communicable with local computing devices used by cloud consumers, such as, for example, a personal digital assistant (PDA) or cellular telephone 54A, a desktop computer 54B, a laptop computer 54C, or an automotive computer system 54N, or a combination thereof. The nodes 10 may communicate with each other. The nodes 10 may be physically or virtually grouped within one or more networks, such as private, community, public, or hybrid clouds as described above, or a combination thereof (not shown). Thereby, cloud computing environment 50 can provide an infrastructure, platform, or SaaS, or a combination thereof, in which cloud consumers do not need to maintain resources on local computing devices. The types of computing devices 54A-54N shown in FIG. 1 are intended to be merely exemplary, and it is understood that cloud computing nodes 10 and cloud computing environment 50 can communicate with any type of computer control device via any type of network or network addressable connection (e.g., connection using a web browser), or both.

[0035] Referring now to FIG. 2, a set of functional abstractions provided by cloud computing environment 50 (FIG. 1) is shown. It should be understood in advance that the components, layers, and functions shown in FIG. 2 are intended to be merely exemplary, and embodiments of the present invention are not limited thereto. As illustrated, the following layers and corresponding functions are provided.

[0036] The hardware and software layer 60 includes hardware components and software components. Examples of hardware components include mainframe 61, a server 62 based on RISC (Reduced Instruction Set Computer) architecture, server 63, blade server 64, storage device 65, and network and network components 66. In some embodiments, the software components include network application server software 67 and database software 68.

[0037] The virtualization layer 70 provides an abstraction layer that provides the following examples of virtual entities: virtual server 71, virtual storage 72, virtual network 73 including a virtual private network, virtual applications and operating systems 74, and virtual clients 75.

[0038] In one example, the management layer 80 can provide the functions described below. Resource provisioning 81 dynamically procures computing resources and other resources used to execute tasks within a cloud computing environment. Metering and pricing 82 tracks the cost when resources are utilized within a cloud computing environment and bills or invoices for the usage of these resources. In one example, these resources may include application software licenses. Security authenticates cloud users and tasks and protects data and other resources. The user portal 83 provides access to the cloud computing environment to users and system administrators. Service level management 84 allocates and manages the cloud's computing resources to meet the required service levels. Service level agreement (SLA) planning and execution 85 pre-allocates and procures the cloud's computing resources for future expected demands according to the SLA.

[0039] The workload layer 90 provides examples of the functionality utilized by a cloud computing environment. Examples of workloads and functions provided by this layer include mapping and navigation 91, software development and lifecycle management 92, delivery of virtual classroom education 93, data analysis processing 94, transaction processing 95, and proof of code of the logical loader within the TEE and integrity checking of the service logic code associated with the requirement for the logical loader to load service logic code into the TEE 96.

[0040] FIG. 3 shows an architecture 300 according to one embodiment. As shown in FIG. 3, a plurality of remote networks 302 including a first remote network 304 and a second remote network 306 are provided. The gateway 301 can be coupled between the remote network 302 and the proximity network 308. In the context of this architecture 300, the networks 304, 306 can each take any form including, but not limited to, a local area network (LAN), a wide area network (WAN) such as the Internet, a public switched telephone network (PSTN), an in-house telephone network, etc.

[0041] In use, the gateway 301 functions as an entry point from the remote network 302 to the proximity network 308. In this way, the gateway 301 can function as a router that directs specific packets of data arriving at the gateway 301 to their destinations, and as a switch that provides the actual paths into and out of the gateway 301 for specific packets.

[0042] There is further included at least one data server 314 coupled to a proximity network 308 that is accessible from a remote network 302 via a gateway 301. It should be noted that the data server 314 may include any kind of computing device / groupware. A plurality of user devices 316 are coupled to each data server 314. The user device 316 may be directly connected through one of the networks 304, 306, 308. Such a user device 316 may include a desktop computer, a laptop computer, a handheld computer, a printer, or any other kind of logic. In one embodiment, it should be noted that the user device 311 may be directly coupled to any of the networks.

[0043] Peripheral devices 320 or a series of peripheral devices 320, such as facsimile devices, printers, network or local or both storage units or storage systems, etc., may be coupled to one or more of the networks 304, 306, 308. It should be noted that a database or additional components or both are utilized in or integrated into any kind of network element coupled to the networks 304, 306, 308. In the context of this description, a network element can refer to any component of a network.

[0044] According to one approach, the methods and systems described herein may be implemented with, or on, or both, one or more virtual systems or systems that emulate one or more other systems, such as a UNIX(R) system that emulates an IBM(R) z / OS(R) environment (IBM and all IBM-based trademarks and logos are trademarks or registered trademarks of International Business Machines Corporation or its affiliates or both), a UNIX(R) system that virtually hosts a known operating system environment, or an operating system that emulates an IBM(R) z / OS(R) environment. In some embodiments, this virtualization or emulation, or both, may be augmented using VMware(R) software.

[0045] In a further approach, one or more networks 304, 306, 308 may represent a cluster of systems, commonly referred to as a "cloud." In cloud computing, shared resources such as processing power, peripherals, software, data, servers, etc., are provided on demand to any system within the cloud, thereby enabling access to and distribution of services across many computing systems. Cloud computing typically includes an Internet connection between systems within the cloud, although other technologies for connecting systems may be used.

[0046] FIG. 4 shows a representative hardware environment associated with the user device 316 and / or server 314 of FIG. 3, according to one embodiment. This figure shows a standard hardware configuration of a workstation including a central processing unit 410, such as a microprocessor, and a plurality of other units interconnected via a system bus 412.

[0047] The workstation shown in FIG. 4 includes an input / output (I / O) adapter 418 for connecting peripheral devices such as a random access memory (RAM) 414, a read only memory (ROM) 416, and a disk storage unit 420 to a bus 412, a keyboard 424, a mouse 426, a speaker 428, a microphone 432, or other user interface devices such as a touch screen and a digital camera (not shown), or a user interface adapter 422 for connecting a combination thereof to the bus 412, a communication adapter 434 for connecting the workstation to a communication network 435 (e.g., a data processing network), and a display adapter 436 for connecting the bus 412 to a display device 438.

[0048] An operating system such as the Microsoft Windows(R) operating system (OS), macOS(R), or UNIX(R) OS may reside on the workstation. It will be understood that the preferred embodiments may be implemented on platforms and operating systems other than those described above. The preferred embodiments may be described using an extensible markup language (XML), the C language, or the C++ language, or a combination thereof, or other programming languages, together with object-oriented programming methods. Object-oriented programming (OOP), which has become increasingly used for developing complex applications, is used (Microsoft and Windows(R) are trademarks of Microsoft Corporation in the United States, other countries, or both, and Unix(R) is a registered trademark of The Open Group in the United States and other countries).

[0049] As described elsewhere in this specification, in response to receiving a request regarding logical loader code, in many cases, it depends on the logical loader to load service logic code in the enclave. The logical loader operates using the logical loader code, and the logical loader code is protected from being compromised by external actors outside the secure enclave if it is included in the secure enclave. The service logic code is executed after being loaded and obtains the data required in the request. However, conventional secure enclaves cannot authenticate the service logic code to be executed. Instead, these conventional enclaves rely on a framework that is prone to security violations because sensitive information remains exposed in the plain memory.

[0050] In sharp contrast to the aforementioned deficiencies of the prior art, the techniques of the various embodiments and methods described herein include a confidential computing framework that operates securely inside a trusted execution environment (TEE). The confidential computing framework provides a provable service loader application programming interface (API) that executes inside the TEE. These techniques enable custom business logic code to be loaded inside the TEE, or executed inside the TEE, or both, and at the time of loading, the integrity of the business logic code is checked. The business logic code may be confidential, for example, it may be encrypted. Further, these techniques enable the business logic code to be unloaded from the TEE, or updated, or both. As described in detail elsewhere below, for example, referring to method 500, the reliability of the code to be executed can be enforced in two steps: the proof of the business logic loader code and the integrity check of the service logic code during loading.

[0051] Referring now to FIGS. 5(A, B, C), a flowchart of a method 500 is shown in accordance with one embodiment. The method 500 may be performed in accordance with a preferred embodiment of the present invention in various embodiments, particularly in any of the environments shown in FIGS. 1-7. Of course, as will be understood by those skilled in the art when reading this description, more or fewer operations than those specifically described in FIGS. 5(A, B, C) may be included in the method 500.

[0052] Each of the steps of the method 500 may be performed by any suitable component of the operating environment. For example, in various embodiments, the method 500 may be performed, in part or in whole, by a computer or other device that includes one or more processors. A processor implemented in hardware or software or both, preferably including at least one hardware component, such as a processing circuit, chip, or module, or a combination thereof, may be utilized within any device to perform one or more steps of the method 500. Examples of processors include 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, but are not limited thereto.

[0053] Operation 502 of method 500 includes loading the code of the logical loader in the TEE. The logical loader may be included in a Trusted Execution Environment (TEE), which is a confidential computing framework configured to communicate service logic code requests via an API in some approaches. Thus, in some approaches, the logical loader code may be loaded on a physical machine such as a computer, a processor, a controller, a display, etc., or on a virtual machine (VM) of the TEE, or both. More specifically, in some approaches, the logical loader code may be business API code. For example, in one approach, the business API code may be code used in a banking API and may be configured to load service logic code in response to receiving a request to load service logic code. The physical machine or the virtual machine or both may be of a known type and may be configured to execute a proof of the logical loader code, or execute the logical loader code, or both. After the logical loader code is loaded in the TEE, the logical loader code is not accessible or visible from the perspective of a device outside the TEE.

[0054] The logic loader code is intended to be executed after the logic loader code has been proven. Thus, for example, referring to operations 504 - 506, the proof of the logic loader code is executed and it is determined whether the logic loader code passes the proof. Regarding the background, the proof can be executed as a verification process that verifies that the logic loader is configured to execute according to the parameters that the logic loader proves. Thus, in response to a decision that the verification that the logic loader is configured to execute according to the parameters that the logic loader proves is successful, it can be determined that the logic loader passes the proof. Further, in some approaches, since operational security is a priority in the TEE, the proof of the logic loader code is executed before the logic loader uses the logic loader code to ensure that the logic loader code is not malicious. For example, malicious logic loader code may cause the logic loader to operate according to a first method, e.g., an operation according to a first routine, but actually be configured to cause the logic loader to operate according to a second method, e.g., a second routine, when executed. The technique for executing the proof of the logic loader code may vary according to the approach. For example, in some approaches, the proof of the logic loader code may be a remote proof. In some other approaches, the proof of the logic loader code may be executed using known proof techniques, additionally or alternatively or both. The proof may be executed, additionally or alternatively or both, by any entity that plays the role of providing service logic to the logic loader, e.g., a service administrator.

[0055] In response to a determination that the logical loader code fails the attestation, for example, referring to the "no" logical path of decision 506, the logical loader code is not permitted to be used within the TEE. If the logical loader code is being loaded for attestation, the logical loader code can be removed from the TEE, either additionally or alternatively or both. In some approaches, in response to a determination that the logical loader code fails remote attestation, the attestation can optionally be performed against one or more other predefined samples of the logical loader code.

[0056] In response to a determination that the logical loader code passes the attestation, for example, referring to the "yes" logical path of decision 506, the logical loader code can be permitted to be used within the TEE. More specifically, after the logical loader code is attested, the logical loader has code that enables service logic code to be loaded onto the physical machine or VM, but from a business logic perspective, the logical loader is an empty shell in the sense that it has not yet loaded any of such service logic code. Regarding the background, the logical loader code can be any part of the code that is configured to be executed when loaded into the TEE. For example, the service logic code can be a stand-alone application, the service logic code can be business logic, the service logic code can be part of an application, the service logic code can be a program, the service logic code can be a query, and so on.

[0057] After the proof of the logic loader code, the logic loader is configured to load the service logic code into the machine of the TEE. In one approach, the machine of the TEE may be a physical machine. In another approach, the machine of the TEE may be a virtual machine (VM) of the TEE. Note that in some preferred systems, any TEE must be launched on a physical machine having hardware support for that particular type of TEE. In some approaches, the TEE does not include multiple physical machines, but multiple TEEs may be launched simultaneously on one physical machine.

[0058] To allow the service logic code to be loaded into the TEE machine, it is preferable to perform an integrity check on the service logic code associated with any request received to load the service logic code into the TEE machine. Note that in some approaches where the machine is a physical machine, the physical machine is extended using TEE technologies such as Software Guard Extensions (SGX), ARM SEV, TrustZone, etc. Further, the TEE may need to be launched / established on the physical machine. To configure the logical loader to perform an integrity check during loading, method 500 includes causing information to be provided to the logical loader, see, for example, operation 508. This information preferably indicates a way to enable the performance of an integrity check on the service logic code and to determine whether the service logic code should be trusted to execute within the TEE. For example, in some approaches, this information includes a kind of fingerprint of the expected service logic that the logical loader should launch or execute. In another approach, this information may include, additionally or alternatively or both, authenticated cryptographic information. Although several other types of authentication are described herein as being implemented by an asymmetric key pair or an SHA fingerprint or both, in some approaches, authenticated symmetric encryption, for example, AES-GCM or secret injection of keys into enclaves or both, may be implemented additionally or alternatively or both. In another approach, this information may include, additionally or alternatively or both, at least one cryptographic key, such as a public cryptographic key, a secret cryptographic key, etc. Information including at least one cryptographic key may enable decryption to be performed if the service logic code associated with the request to load the service logic code is encrypted. After decryption, an integrity check of the service logic code may be performed. In some approaches, this information includes, additionally or alternatively or both, instructions detailing how the service logic code is to be executed.For example, this information may include instructions for loading and executing the service logic code associated with a request only once in response to a determination that the service logic code passes a completeness check. In contrast, this information may include instructions for loading and executing the service logic code associated with a request multiple times in response to a determination that the service logic code passes a completeness check. In some other approaches, this information includes instructions, such as updating a confidential computing micro-service, e.g., the following "u-service", to keep the service logic code continuously available for execution, to execute the service logic code at a predetermined startup time, in response to a determination that a confidential computing u-service has been started and is running, since the service logic code associated with the request is immediately loaded and executed. As will be apparent to those skilled in the art when reading this disclosure, in addition to the various examples of encryption techniques described herein, known types of encryption techniques, information, parameters, values, etc. may be adapted for use in various embodiments.

[0059] It should be noted that the type of instructions included in the information may depend on the type of service logic and / or business logic, or both, that is expected to be delivered to the logic loader for loading. For purposes of illustration, assuming that the type of service logic and / or business logic, or both, that is expected to be delivered to the logic loader for loading is related to banking transactions, in some approaches, this information may include instructions for loading and executing the logic only once before re-authentication of the user profile is required. In another approach, assuming the type of service logic and / or business logic, or both, related to location services, the service information may include instructions for continuously executing the service logic code to maintain updated location results obtained from executing the service logic code.

[0060] Operation 510 includes the logical loader receiving a request to load service logic code into the TEE and, in some approaches, to execute the service logic code. In some approaches, this request is received from one or more locations external to the TEE. One or more of the requests may be queued until executed. In some approaches, the request is received via an API that exists between the TEE and a location external to the TEE, where the location external to the TEE is, for example, a cloud location using a predefined service mesh that exists between the TEE and the cloud location, a processing location communicating with one or more user devices, a user device, a service administrator device managing a request platform, and the like.

[0061] A integrity check of the service logic code associated with the request is performed, see, for example, operation 512. In one approach, performing the integrity check includes performing a simple hash comparison. In another approach, performing the integrity check may include, additionally or alternatively or both, performing measurements and attestations based on a trusted platform module (TPM). For the integrity check, any form of third-party attestation / remote attestation may be performed, additionally or alternatively or both. In yet another approach, a signature check of the loaded code may be used as the integrity check, additionally or alternatively or both.

[0062] In some approaches, the integrity check is performed by the service loader at load time, during which the service loader applies the information provided to the service loader to enable the execution of the integrity check of the service logic code associated with the request. At load time, the service logic code may be loaded into the test platform of the TEE, but note that it does not have to be loaded into the execution platform of the TEE until the service logic passes the integrity check. In some approaches, the integrity check may be performed in particular in response to receiving a request to load the service logic code. The integrity check may be performed, additionally or alternatively or both, before receiving a request to load the service logic code, for example, at least one of a default set of the required service logic code.

[0063] In some approaches, the integrity check is performed on the service logic code only after a verification has been performed to verify that the request was received from a trusted service administrator device. This verification can provide additional means of security within the TEE, provided that the service administrator device is a trusted device. This is because choosing to process requests only from trusted devices, such as a trusted service administrator device, makes it less likely that requests from untrusted sources will be processed within the TEE. Thus, in some approaches, method 500 includes performing a proof to determine whether the request was received from a trusted service administrator device. In some approaches, known techniques for performing remote proof may be used. In some other approaches, techniques for determining whether a request was received from a trusted service administrator device include, for example, local proof when the service administrator is on the same physical device as the TEE. Remote proof is generally not used to determine whether a particular request came from a certain device or dedicated device. In contrast, remote proof can be used to determine whether the service administrator device is trusted. Thus, the integrity of the device or code or business logic / service logic can be checked. In some approaches, for example, key-based authentication may be performed to ensure that a request came from a certain service administrator device.

[0064] In response to a determination that the request was received from a trusted service administrator device, execution of an integrity check of the service logic code associated with the request is permitted. In contrast, in response to a determination that the request was not received from a trusted service administrator device, execution of an integrity check of the service logic code associated with the request is not permitted.

[0065] For example, as indicated by the "No" logical path of decision 514, in response to the determination that the service logic code associated with the request fails the integrity check, the logic loader is caused not to load the service logic code associated with the request into the TEE, or not to execute it, or both, see, for example, operation 516. In response to the determination that the service logic code associated with the request fails the integrity check, a warning regarding the request is output, additionally or alternatively or both, see, for example, operation 518. For example, this warning may indicate that the request or the source of the request or both are not trustworthy. This warning may be output to one or more destination devices, such as the device used by the service administrator, the device of the requester, and may be output to a device configured to execute a predefined security protocol for the TEE along with the execution instruction to ensure that the TEE has not been compromised by a known type of malicious actor. In contrast, for example, as indicated by the "Yes" logical path of decision 514, in response to the service logic code associated with the request passing the integrity check, the logic loader is permitted to load the service logic code associated with the request into the TEE, see, for example, operation 520. According to various techniques, the logic loader may be permitted to load the service logic code associated with the request into the TEE, for example, in response to receiving a command from the controller of the TEE, in response to receiving an instruction from the administrator device, as a result of the integrity check being executed, in response to no warning being output to the administrator device, etc.

[0066] The service logic code associated with the request is permitted to be executed in response to the request being loaded into the TEE. See, for example, operation 522. The execution of the service logic code may involve accessing information stored in storage devices, such as cloud services, local storage devices, multiple storage devices that are not only local to the TEE but also not local to the TEE, in order to satisfy the request. For example, the information may include, for example, bank branch location information requested in the request, the user's bank account information associated with the request, location information, ledger information, text strings, and the like. After the execution of the service logic code, the service logic code may be unloaded, for example, deleted. In some other approaches, at least a portion of the service logic code may be stored in the physical device of the TEE for possible subsequent use. Note that in some approaches where at least a portion of the service logic code is stored in the physical device of the TEE, at least a portion of the service logic code may not be permitted to be executed until a request to execute the service logic code is received, or at least a portion of the service logic code passes the integrity check again, or both occur.

[0067] Update information regarding the service logic code associated with a request may be received, and the service logic code associated with the request may optionally be updated. For example, refer to operations 524 - 526. In some approaches, the update information regarding the service logic code associated with a request is received after a completeness check is performed. For example, if the update adds an improper segment of code to the service logic code, the updated service logic code may be subjected to a completeness check before it is loaded into the TEE, or executed by the TEE, or both, to ensure that the updated service logic code does not put the TEE in a harmful state. For example, refer to operation 528. To perform a completeness check on the updated service logic code, techniques described elsewhere in this specification for performing a completeness check may be relied upon. For example, refer to operation 512. Note that in some approaches, updating the service logic code associated with a request may include uploading the service logic code from the TEE.

[0068] It is determined whether the updated service logic code passes the completeness check. For example, refer to determination 530. For example, in response to a determination that the updated service logic code fails the completeness check, as indicated by the "no" logical path of determination 530, loading the updated service logic code into the TEE, or executing it in the TEE, or both, is not permitted. For example, refer to operation 532. In contrast, in response to a determination that the updated service logic code passes the completeness check, as indicated by the "yes" logical path of determination 530, loading the updated service logic code into the TEE, or executing it in the TEE, or both, is permitted. For example, refer to operation 534.

[0069] Maintaining a TEE by authenticating the code executed using the techniques described herein has not been considered heretofore. More specifically, the prior art cannot authenticate the code being executed by leveraging the proof of business logic loader code and the integrity check of the service logic code during loading. In stark contrast, these prior arts rely on frameworks that are prone to security violations because the sensitive information remains exposed in the plain memory. Thus, the discovery of the present invention disclosed herein, which enables a TEE by authenticating the code being executed, goes against the general perception. This is beneficial in that the techniques described herein enable a fairly large number of distinguishable use cases. For example, one possible use case involves a roaming user securely loading geography-specific service logic. Another possible use case involves securely loading and executing context-aware service logic. Further use cases include platforms such as, for example, CLOUDFLARE's Quantum-Safe Crypto (QSC) channel extension. For example, secure key caching of IBM's COS or data encryption / decryption software development kits (SDKs) or both is a further use case. Yet another possible use case involves IP-based access filtering and privacy, such as, for example, IBM's KeyProtect. It is also important to note that in some approaches, the same framework can be used both inside and outside the enclave.

[0070] FIG. 6 shows a system 600 in accordance with one embodiment. Optionally, the system 600 may be implemented with features from any other embodiments shown herein, such as features described with reference to other figures. However, of course, such a system 600 and other systems presented herein may be used in a variety of applications or permutations or both, which may or may not be specifically described in the example embodiments shown herein. Further, the system 600 presented herein may be used in any desired environment.

[0071] It may be prefaced that the system 600 functions as a dynamically extensible confidential computing environment framework using the TEE 604. The main purpose of the operations executed in the system 600 may include seamlessly protecting dynamic service logic using the TEE. As will be described in more detail below, the system 600 provides computing security in that the dynamic service logic is attested at load time and the loader is attested at startup time. The various embodiments and techniques described herein benefit from adding a provable service logic loader (which can function as an executor of service logic code, additionally or alternatively or both) to the framework. Further, the interface of the system 600 first conforms to APIs used in HTTP1.0 / 2.0, including TLS1.3 (server and client), REST (Representational State Transfer), which is an API that follows a specific software architecture style used in Internet / cloud applications, and high-performance open-source remote procedure call (RPC) frameworks such as gRPC (GOOGLE Remote Procedure Call). This framework facilitates use in that application developers can focus only on service logic rather than the cumbersome configuration of the confidential computing framework.

[0072] Continuing to refer to system 600, TEE 604 is, in one approach, a confidential computing framework, such as a u-service, configured to receive requests regarding service logic code 606. TEE 604 may be, additionally or alternatively or both, a microservice, application, database, etc. that is protected in that the code is executed inside the protected hardware enclave of TEE 604 or a secure service container or both. Request 612 may originate from a cloud service or client device 602, which is a service user that communicates with the TEE via a known type of network connection. In some approaches, the request may be received via an API. Inside the TEE 604 of system 600, a proof of the code of the logical loader may be executed. Using the code of the logical loader or the information provided to the logical loader or both, the logical loader is configured to perform a secure dynamic loading 614 of the service logic code 606, for example, in response to receiving a request for the logical loader to load the service logic code 606 into the TEE 604. It is preferable to perform a integrity check of the service logic code 606 associated with the request, and in response to the service logic code 606 associated with the request passing the integrity check, the logical loader is permitted to load the service logic code 606 associated with the request into the TEE 604. In some approaches, the execution of the service logic code includes accessing information stored in the cloud service 608. The service logic code may be unloaded after being executed.

[0073] In one exemplary approach, the service logic code 606 may be an application that is required to execute within the TEE 604. The application may include, for example, several binaries and several configuration files bundled in a package, such as an image within a Kubernetes cluster. Such an image can be measured, in one example, by obtaining the SHA-256 fingerprint of all the bits present in the image. Note that in some approaches, one or more other cryptographic hash functions, such as SHA-1, SHA-512, SHA3-512, etc., are used as additional or alternative or both. The obtaining of the SHA-256 fingerprint may be prepared offline, such that when the service logic is being prepared, it becomes possible to generate the SHA-256 fingerprint, and the TEE 604's confidential computing service can be informed that the service logic code having the SHA-256 fingerprint is allowed to execute, e.g., be launched, by the service administrator device 610. Thus, the system 600 is dynamic because loading can occur at any point in time, and in particular, loading can occur according to the current state of the application or according to a default startup configuration. This is because a request may come in and the service logic code may be requested to execute for application "A" associated with this request, and when another request is received, the service logic code associated with this second request may execute using application "B". The system 600 is also extensible in that different service logic codes may be loaded according to different SHA fingerprints.

[0074] FIG. 7 shows a system 700 according to one embodiment. Optionally, the system 700 may be implemented with features from any other embodiment shown herein, such as features described with reference to other figures. However, of course, such a system 700 and other systems presented herein may be used in various applications or permutations or both, either specifically described in the example embodiments shown herein or not. Further, the system 700 presented herein may be used in any desired environment.

[0075] System 700 includes a TEE 702. A request for a logic loader to load service logic code is received by the load balancing section 704 of the TEE 702, for example, referring to the "downstream request entry point". The request can be received from a downstream web server or a downstream microservice in one approach. The u-service framework of the TEE 702 can communicate with a cloud service (not shown) or a set of service request logics, for example, referring to the "service request logic", or both. The request is delivered from the load balancing section 704 of the TEE 702 to the processing section 706 of the TEE 702 along the lock-free ring buffer 708. The processing section 706 of the TEE 702 includes a service logic loader configured to perform an integrity check via an API 710 of the service logic code associated with the received request after being properly authenticated. An integrity check of the service logic code associated with the request, for example, referring to "request path A", "request path B", "request path N", etc., can be performed by the service logic loader when loading the service logic code. In response to the service logic code associated with the request passing the integrity check, the logic loader is permitted to load the service logic code associated with the request into the TEE, or execute it, or both. In response to the service logic code associated with the request failing the integrity check, the logic loader is not permitted to load the service logic code associated with the request into the TEE, or execute it, or both.

[0076] The present invention can be a system, a method, or a computer program product, or a combination thereof, at any possible technical detail level of integration. The computer program product may include a computer-readable storage medium (or multiple computer-readable storage media) having computer-readable program instructions for causing a processor to implement aspects of the present invention.

[0077] A computer-readable storage medium can be a tangible device that can hold and store instructions for use by an instruction-executing device. The computer-readable storage medium can be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof, but is not limited thereto. A non-exhaustive listing of more specific examples of computer-readable storage media includes the following: portable computer 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), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy (R) disks, mechanically encoded devices such as punch cards or raised structures engraved in grooves in which instructions are recorded, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium shall not be construed to be a transient signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through an optical fiber cable), or an electrical signal transmitted through an electrical wire.

[0078] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to respective computing / processing devices, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, a wireless network, or a combination thereof. The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium within each computing / processing device.

[0079] Computer-readable program instructions for carrying out the operations of the present invention may be written in any combination of one or more programming languages, including assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or source code or object code written in any combination of object-oriented programming languages such as Smalltalk(R), C++, and procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer as a stand-alone software package, partly on the user's computer, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute the computer-readable program instructions to customize the electronic circuit by utilizing the state information of the computer-readable program instructions to carry out aspects of the present invention.

[0080] Aspects of the present invention will be described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0081] These computer-readable program instructions, when executed via the processor of a computer or other programmable data processing apparatus, may cause the means for implementing the functions / acts specified in one or more blocks of a flowchart, a block diagram, or both to be created, thereby making a machine that can be provided to a computer or the processor of other programmable data processing apparatus. These computer-readable program instructions may also be stored in a computer-readable storage medium that, when the instructions are stored therein, comprises a manufactured article including instructions for implementing the functions / acts in the manner specified in one or more blocks of a flowchart, a block diagram, or both, and can be used to direct a computer, programmable data processing apparatus, or other devices or combinations thereof to function in a particular manner.

[0082] The computer-readable program instructions may also be loaded onto a computer, other programmable apparatus, or other devices to create a computer-implemented process such that the instructions, when executed on the computer, other programmable apparatus, or other devices, cause a series of operational steps to be performed for implementing the functions / acts specified in one or more blocks of a flowchart, a block diagram, or both.

[0083] The flowcharts and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram can represent a module, segment, or portion of instructions that include one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions represented by the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may in fact be executed as one step, may be executed at the same time, substantially simultaneously, in a partially or wholly temporally overlapping manner, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagram or flowchart diagram, or both, and combinations of blocks of the block diagram or flowchart diagram, or both, can be implemented by a dedicated hardware-based system that performs the specified function or action, or that executes a combination of dedicated hardware and computer instructions.

[0084] Furthermore, a system according to various embodiments may include a processor and / or logic integrated with or executable by the processor, the logic being configured to perform one or more of the processing steps recited herein. The processor may be of any configuration as described herein, such as a discrete processor or processing circuit, including many components such as processing hardware, memory, I / O interfaces, etc. Being integrated means that the logic is incorporated into the processor as hardware logic, such as in an application specific integrated circuit (ASIC), an FPGA, etc. Being executable by the processor means that the logic is software logic, such as hardware logic accessible by the processor, firmware, a part of an operating system, a part of an application program, or some combination of hardware logic and software logic, and is configured to cause the processor to perform some function when executed by the processor. The software logic may be stored in any memory type known in the art, local or remote or both. Any processor known in the art may be used, such as a software processor module or a hardware processor or both, such as an ASIC, an FPGA, a central processing unit (CPU), an integrated circuit (IC), a graphics processing unit (GPU).

[0085] It will be apparent that multiple combinations can be created from the descriptions presented above, and that the various features of the aforementioned system or method or both may be combined in any manner.

[0086] It will be further understood that embodiments of the present invention are provided in the form of services deployed on behalf of customers to provide services on demand.

[0087] The description of the various embodiments of the present invention is presented for purposes of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. 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 embodiments. The terms used herein are chosen in order to best explain the principles of the embodiments, the practical application, or technical improvements made to the technologies found in the marketplace, or to enable other ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. executing a proof of the code of a logical loader in a trusted execution environment (TEE); receiving a request for the logical loader to load service logic code into the TEE; performing a integrity check of the service logic code associated with the request; permitting, in response to the service logic code associated with the request passing the integrity check, the logical loader to load the service logic code associated with the request into the TEE, a computer-implemented method.

2. The computer-implemented method of claim 1, including causing information to be provided to the logical loader, the information enabling performance of the integrity check of the service logic code.

3. The computer-implemented method of claim 2, wherein the service logic code associated with the request is encrypted and the information enables decryption of the service logic code for performing the integrity check of the service logic code.

4. The computer-implemented method of claim 2 or 3, wherein the information is selected from a group including a fingerprint, a public encryption key, authenticated encrypted information, and a secret encryption key.

5. permitting, in response to the request being loaded into the TEE, execution of the service logic code associated with the request, the execution including accessing information stored in a cloud service, and unloading the service logic code after the execution, the computer-implemented method according to any one of claims 1 to 4.

6. causing, in response to the service logic code associated with the request failing the integrity check, the logical loader not to load the service logic code associated with the request into the TEE; outputting a warning regarding the request, the computer-implemented method according to any one of claims 1 to 5.

7. receiving update information regarding the service logic code associated with the request after the integrity check is performed; updating the service logic code associated with the request; The computer-implemented method according to any one of claims 1 to 6, including performing a integrity check on the updated service logic code before the updated service logic code is loaded into the TEE.

8. Performing a remote attestation to determine whether the request is received from a trusted service administrator device; In response to a determination that the request is received from the trusted service administrator device, permitting execution of the integrity check of the service logic code associated with the request; The computer-implemented method according to any one of claims 1 to 7, including not permitting execution of the integrity check of the service logic code associated with the request in response to a determination that the request is not received from the trusted service administrator device.

9. A computer program product comprising a computer-readable storage medium in which program instructions are embodied, the program instructions being readable or executable or both by a computer, and causing the computer to: Perform an attestation of the code of a logical loader in a trusted execution environment (TEE) by the computer; Receive, by the computer, a request for the logical loader to load a service logic code into the TEE; Perform an integrity check of the service logic code associated with the request by the computer; In response to the service logic code associated with the request passing the integrity check, cause the computer to permit the logical loader to load the service logic code associated with the request into the TEE.

10. The program instructions being readable or executable or both by the computer, and causing the computer to: Cause the computer to cause information to be provided to the logical loader, the information enabling execution of the integrity check of the service logic code, the computer program product according to claim 9.

11. The computer program product according to claim 10, wherein the service logic code associated with the request is encrypted, and the information enables the decryption of the service logic code in order to perform the integrity check of the service logic code.

12. The computer program product according to claim 10 or 11, wherein the information is selected from a group including a fingerprint, a public encryption key, authenticated encrypted information, and a secret encryption key.

13. The program instructions are readable and / or executable by the computer, and the computer is permitted by the computer to execute the service logic code associated with the request in response to the request being read into the TEE by the computer, wherein the execution of the service logic code includes accessing information stored in a cloud service, and the computer is caused by the computer to unload the service logic code after the execution. The computer program product according to any one of claims 9 to 12.

14. The program instructions are readable and / or executable by the computer, and the computer, in response to the service logic code associated with the request failing the integrity check, causes the logic loader by the computer not to load the service logic code associated with the request into the TEE, and causes the computer to output a warning regarding the request. The computer program product according to any one of claims 9 to 13.

15. The program instructions are readable and / or executable by the computer, and the computer, after the integrity check is performed by the computer, receives update information regarding the service logic code associated with the request, and updates the service logic code associated with the request by the computer. The computer program product according to any one of claims 9 to 14, wherein the computer is caused to perform a integrity check on the updated service logic code before the updated service logic code is loaded into the TEE.

16. The program instructions are readable and / or executable by the computer, and cause the computer to perform a remote attestation to determine whether the request has been received from a trusted service administrator device, and in response to a determination that the request has been received from the trusted service administrator device, permit the computer to perform an integrity check on the service logic code associated with the request, and in response to a determination that the request has not been received from the trusted service administrator device, cause the computer not to permit the execution of an integrity check on the service logic code associated with the request, the computer program product according to any one of claims 9 to 15.

17. A system comprising a processor and logic integrated with the processor, executable by the processor, or both integrated with and executable by the processor, the logic being configured to perform an attestation of the code of a logic loader in a trusted execution environment (TEE), receive a request for the logic loader to load service logic code into the TEE, perform an integrity check on the service logic code associated with the request, and in response to the service logic code associated with the request passing the integrity check, permit the logic loader to load the service logic code associated with the request into the TEE.

18. The logic is configured to cause information to be provided to the logic loader, the information enabling the performance of an integrity check on the service logic code, the system according to claim 17.

19. The logic is configured to permit the service logic code associated with the request to be executed in response to the request being loaded into the TEE, the execution of the service logic code including accessing information stored in a cloud service, and to unload the service logic code after the execution, the system according to claim 17 or 18.

20. The logic is configured to cause the logic loader not to load the service logic code associated with the request into the TEE in response to the service logic code associated with the request failing the integrity check, and to output a warning regarding the request, the system according to any of claims 17 to 19.

21. A computer program comprising program code means adapted to execute the method according to any of claims 1 to 8 when the program is executed on a computer. ​

Images