The present disclosure relates to a method and an apparatus for trust verification of a remote service in distributed computing environments.

BACKGROUND

In the field of distributed computing environments, cloud computing is becoming increasingly important as a way to achieve more flexible, scalable, and efficient systems. However, as users of cloud computing services lose the direct control of their data and applications hosted by cloud providers, the trustworthiness of cloud services is a main issue that hinders the deployment of cloud applications.

To overcome reservations of users towards using cloud services, cloud/service providers offer so-called trusted services that ensure their users that the data and applications they provide to the service will remain secure and protected and that the service will use these assets only as expected by the users.

One example of a trusted service is an online survey service that ensures the survey participants that their answers will remain confidential and that only aggregated results will be shared with the orderer of the survey. In addition, the survey orderer may be ensured that the survey questions and the corresponding results will remain his property and will not be shared with third parties.

Another example is a trusted cloud service that guarantees its customers that their applications will run in the cloud unmodified and protected even from the cloud provider who offers the service as infrastructure as a service, laaS.

Trusted services can be developed using a trusted execution environment, TEE, such as Intel SGX. A TEE is a secure area of a processor that establishes an isolated execution environment that provides security features such as isolated execution, integrity of applications executing with the TEE, along with confidentiality of their assets.

A trusted execution environment such as Intel SGX ensures the application running in it the following properties: code immutability, meaning that the logic of the protected application cannot be altered; data confidentiality that ensures that the application cannot be accessed without authorization; and attestation, meaning that the protected application has the ability to prove its identity to a third party, i.e. that it is indeed a specific program running in the TEE. Thus, using TEE, the service provider can ensure that the users’ assets will be protected and that the provided service will be able to attest its identity to the users.

A service identity is usually a large number, e.g. 256 bits, that may be the result of a cryptographic hash on the service executable, i.e. the binary code of the application, or the entire application deployment including the individual components of the service and the topology.

Known attestation schemes, such as Intel’s SGX Attestation, enable a user that wishes to connect to a specific service to get proof that the identity of the service is X. This is, however, of limited use to the user as he or she generally does not know whether and why a service with identity X should be trusted. The service itself may still include malicious software or otherwise compromise the assets of the user. It is therefore desirable to provide a mechanism that allows verifying whether the service X can be trusted. The mechanism should be transparent to the user to facilitate detection of fraudulent behavior. It should also be versatile and easy to implement in existing infrastructure.

SUMMARY OF INVENTION

The present disclosure provides a method and apparatus for trust verification of a remote service that allows a user or a client to establish whether a remote application of a service provider with a specific identity can be trusted. The disclosure provides a transparent mechanism to connect a user to remote services while ensuring that the services can be trusted.

According to one aspect of the present disclosure, an apparatus for trust verification of a remote service is provided wherein the apparatus comprises a processing circuitry configured to: send an attestation request for an attestation of an identity of a remote application that is at least partly executed in a trusted environment of a service provider; receive an attestation response including the requested attestation of the identity of the remote application from the service provider; and determine whether the identity of the remote application is trusted based on the attestation response and at least one trust evidence, wherein the at least one trust evidence is generated by at least one party different from the service provider. The a trusted environment is preferably a secure enclave.

The processing circuitry may be further configured to connect to the remote application upon determination that the identity of the remote application is trusted. The processing circuitry may be further configured to handle all network traffic between a client and the remote application. The trust verification may be performed in a secure enclave of the apparatus as a service, and the processing circuitry may be further configured to provide attestation of the service to the client. The network traffic between a client and the remote application is preferably via a secure channel.

According to a further aspect, the remote application may be provided by the service provider as Software as a Service, SaaS, wherein the at least one trust evidence is generated by a third party different from the service provider and the apparatus.

The at least one trust evidence may include an attestation by the third party that the identity of the remote application is trustworthy and/or a list of trustworthy application identities, wherein determining whether the identity of the remote application is trusted includes verifying the digital signature and/or comparing the identity of the remote application with the list of trustworthy application identities. The attestation is preferably a digital signature.

The at least one trust evidence may include a proof of analysis generated by the third party for the remote application wherein determining whether the identity of the remote application is trusted includes comparing the proof of analysis with at least one requirement setting which is predefined and/or received from a client application. The proof of analysis generated by the third party for the remote application is preferably a static analysis of the remote application with regard to malicious software and/or backdoors.

The at least one trust evidence may include a degree of trust related to the identity of the remote application and/or to the service provider and/or to a provider of the remote application, wherein determining whether the identity of the remote application is trusted includes comparing the degree of trust with a threshold, which is predefined or received from a client application.

According to a further aspect, the remote application may be a client/user application provided to the service provider by the client and executed by the service provider as Infrastructure as a Service, laaS, wherein the at least one trust evidence is generated by the client. The at least one trust evidence may be generated based on a configuration of the remote application, wherein determining whether the identity of the remote application is trusted includes calculating, by the processing circuitry, an identity of the remote application with the configuration in the trusted environment of the service provider.

According to another aspect of the present disclosure, a method for trust verification of a remote service is provided wherein the method comprises: sending, to a service provider, an attestation request for an attestation of an identity of a remote application that is at least partly executed in a trusted environment of the service provider; receiving an attestation response including the requested attestation of the identity of the remote application from the service provider; and determining whether the identity of the remote application is trusted based on the attestation response and at least one trust evidence, wherein the at least one trust evidence is generated by at least one party different from the service provider. The trusted environment is preferably a secure enclave.

The method may further comprise connecting to the remote application upon determination that the identity of the remote application is trusted. The method may further comprise handling all network traffic between a client and the remote application. The trust verification itself may be performed in a secure enclave as a service, attestation of this service may be provided to the client. The network traffic between a client and the remote application is preferably via a secure channel.

According to a further aspect, the remote application may be provided by the service provider as Software as a Service, SaaS, wherein the at least one trust evidence is generated by a third party different from the service provider and the apparatus, i.e. the service trust verification unit.

The at least one trust evidence may include an attestation by the third party that the identity of the remote application is trustworthy and/or a list of trustworthy application identities, wherein determining whether the identity of the remote application is trusted includes verifying the digital signature and/or comparing the identity of the remote application with the list of trustworthy application identities. The attestation is preferably a digital signature.

The at least one trust evidence may include a proof of analysis generated by the third party for the remote application, wherein determining whether the identity of the remote application is trusted includes comparing the proof of analysis with at least one requirement setting which is predefined and/or received from a client application. The proof of analysis is preferably a static analysis of the remote application with regard to malicious software and/or backdoors.

The at least one trust evidence may include a degree of trust related to the identity of the remote application and/or to the service provider and/or to a provider of the remote application, wherein determining whether the identity of the remote application is trusted includes comparing the degree of trust with a threshold, which is predefined or received from a client application.

According to a further aspect, the remote application may be a client/user application provided to the service provider by the client and executed by the service provider as Infrastructure as a Service, laaS, wherein the at least one trust evidence is generated by the client. The at least one trust evidence may be generated based on a configuration of the remote application, wherein determining whether the identity of the remote application is trusted includes calculating, by the client, an identity of the remote application with the configuration in the trusted environment of the service provider.

Furthermore, a computer-readable medium storing instructions that when executed on a processor cause the processor to perform any one of the above described methods is provided.

The apparatus may include a dedicated service trust verification unit configured to perform any one of the above-described methods. The service trust verification unit or service trust verifier may be implemented as one or more software modules or as a separate unit of the processing circuitry. The service trust verifier may be implemented as a combination of software and hardware. The described processing may be performed by a chip, such as a general-purpose processor, a CPU, a GPU, or a field programmable gate array (FPGA), or the like. However, the present disclosure is not limited to implementation of the service trust verification unit on programmable hardware. The unit may also be implemented on an application-specific integrated circuit (ASIC) or by a combination of the above-mentioned hardware components.

BRIEF DESCRIPTION OF DRAWINGS

In the following, exemplary embodiments are described in more detail with reference to the attached figures and drawings, in which:

Figure 1 schematically shows a general client-server configuration for remote services such as remote computation.

Figure 2 schematically shows a configuration for trusted computing using secure containers as known in the art.

Figure 3 illustrates the concept of trust verification based on trust evidences according to the present disclosure.

Figure 4 shows a configuration for trust verification of a remote service according to a first embodiment of the present disclosure.

Figure 5 shows a configuration for trust verification of a remote service according to a second embodiment of the present disclosure. DETAILED DESCRIPTION

The present disclosure relates to the general technical field of authentication of remote services such as Cloud computing, Software as a Service (SaaS), Infrastructure as a Service (laaS), and remote computation. It offers a transparent mechanism to a user to determine whether a remote application with an attested identity can be trusted.

A general client-server architecture for remote services is schematically illustrated in Figure 1 . The configuration includes one or more clients 100 that communicate with one or more servers 200. A client may be implemented in a user device or client device as described below. A server may be implemented in a server device provided by a service provider and/or a cloud provider. The present disclosure is, however, not limited to these specific implementations but may be applied to any configuration wherein a local client (device) requests a service from a remote server (device) that is provided to the client by the server. It is understood that the service may be provided by more than a single server or server device, but may itself rely on a distributed system architecture. The server may include for instance, a web server as a front end, an application server and a data base server. For simplicity, the remote entity providing the service, whether a single server or server device, a distributed or micro service based system, or the like will be referred to in the following as a service provider. Furthermore, the client is not limited to a single client or client device but may itself include a distributed system. The client may further act as a server itself in a distributed environment, for instance as an intermediary server. The term client is used herein to include any of the above-mentioned architectures and merely indicates that entity 100, e.g. a client device, receives a service from a remote entity 200, e.g. a server device. With regard to other aspects than the provision and reception of the remote service, the client 100 and the server 200 may even switch roles.

The client 100 and the service provider 200 may be operatively connected to one or more respective client data stores and server data stores (not shown) that can be employed to store information local to the respective client 100 and server 200, such as application code, application data, input data, output data, authentication data, and the like.

The client 100 and the service provider 200 may communicate information between each other using a communication framework as indicated by the arrows. The information may include authentication information such as keys and/or signatures for establishing a secure communication channel, one or more applications, e.g. as code or binaries, input data and/or configuration data for execution of the remote application, output data of the remote application, and the like.

In an laaS architecture, the remote application may be provided by the client 100 and communicated to the service provider 200 via the communication channel before it is executed by the service provider. In this case, the remote service may include installing, e.g. compiling, the application code received from the client, executing the received application as a remote application on the side of the service provider, and communicating the results of the execution back to the client 100. In an SaaS architecture, the remote application is provided by the service provider itself and the remote service includes executing the remote application, potentially on input data received from the client 100, and communicating the results to the client.

The communications framework used for communications between the client 100 and the service provider 200 may implement any well-known communication techniques and protocols. The communications framework may be implemented as a packet-switched network (e.g., public networks such as the Internet, private networks such as an enterprise intranet, and so forth), a circuit-switched network (e.g., the public switched telephone network), or a combination of a packet-switched network and a circuit-switched network (with suitable gateways and translators). The client-server architecture may include various common communications elements, such as a transmitter, receiver, transceiver, radio, network interface, baseband processor, antenna, amplifiers, filters, power supplies, and so forth. The embodiments, however, are not limited to these implementations.

The communications framework may implement various network interfaces arranged to accept, communicate, and connect to a communications network. A network interface may be regarded as a specialized form of an input/output interface. Network interfaces may employ connection protocols including without limitation direct connect, Ethernet (e.g., thick, thin, twisted pair 10/100/1000 Base T, and the like), token ring, wireless network interfaces, cellular network interfaces, IEEE 802.1 1 a-x network interfaces, IEEE 802.16 network interfaces, IEEE 802.20 network interfaces, and the like. Further, multiple network interfaces may be used to engage with various communications network types. For example, multiple network interfaces may be employed to allow for the communication over broadcast, multicast, and unicast networks. Should processing requirements dictate a greater speed and capacity, distributed network controller architectures may similarly be employed to pool, load balance, and otherwise increase the communication bandwidth required by clients 100 and servers 200. A communications network may be any one and the combination of wired and/or wireless networks including without limitation a direct interconnection, a secured custom connection, a private network (e.g., an enterprise intranet), a public network (e.g., the Internet), a Personal Area Network (PAN), a Local Area Network (LAN), a Metropolitan Area Network (MAN), an Operating Missions as Nodes on the Internet (OMNI), a Wide Area Network (WAN), a wireless network, a cellular network, and other communications networks. As mentioned above, the client 100 and the server 200 may each include a device that may be any electronic device capable of receiving, processing, and sending information, e.g. through a communication component. Examples of an electronic device may include without limitation a client device, a personal digital assistant (PDA), a mobile computing device, a smart phone, a cellular telephone, ebook readers, a messaging device, a computer, a personal computer (PC), a desktop computer, a laptop computer, a notebook computer, a netbook computer, a handheld computer, a tablet computer, a server, a server array or server farm, a web server, a network server, an Internet server, a work station, a network appliance, a web appliance, a distributed computing system, multiprocessor systems, processor-based systems, consumer electronics, programmable consumer electronics, game devices, television, set top box, wireless access point, base station, subscriber station, mobile subscriber center, radio network controller, router, hub, gateway, bridge, switch, machine, or combination thereof. The embodiments are not limited in this context.

The device may execute processing operations or logic for the one or several applications such as the exemplary client application 1 10 and the remote application 210, for a communications component, the operating system, in particular a kernel of the operating system, and for other software elements using one or more processing components. The processing components may comprise various hardware elements such as devices, logic devices, components, processors, microprocessors, circuits, processor circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, application specific integrated circuits (ASIC), programmable logic devices (PLD), digital signal processors (DSP), field programmable gate arrays (FPGA), memory units, logic gates, registers, semiconductor devices, chips, microchips, chip sets, and so forth. Examples of software elements may include software components, programs, applications, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, application program interfaces (API), instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an embodiment of the below-described service trust verification unit is implemented using hardware elements and/or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints, as desired for a given implementation.

The device may execute communications operations or logic for communications with other devices using one or more communications components. The communications components may implement any well-known communications techniques and protocols, such as techniques suitable for use with packet-switched networks (e.g., public networks such as the Internet, private networks such as an enterprise intranet, and so forth), circuit-switched networks (e.g., the public switched telephone network), or a combination of packet-switched networks and circuit-switched networks (with suitable gateways and translators). The communications component may include various types of standard communication elements, such as one or more communications interfaces, network interfaces, network interface cards (NIC), radios, wireless transmitters/receivers (transceivers), wired and/or wireless communication media, physical connectors, and so forth. By way of example, and not limitation, communication media include wired communications media and wireless communications media. Examples of wired communications media may include a wire, cable, metal leads, printed circuit boards (PCB), backplanes, switch fabrics, semiconductor material, twisted-pair wire, co-axial cable, fiber optics, a propagated signal, and so forth. Examples of wireless communications media may include acoustic, radio-frequency (RF) spectrum, infrared and other wireless media.

The device may communicate with other devices over communications media using communications signals as indicated in Figure 1 , via the one or more communications components. The other devices may be internal as in Figure 4 or external to the device as in Figure 5, as desired for a given implementation.

The device may be implemented in the form of a distributed system that may distribute portions of the above-described structure and/or operations across multiple computing entities. Examples of a distributed system may include without limitation a client-server architecture, a 3-tier architecture, an N-tier architecture, a tightly-coupled or clustered architecture, a peer-to- peer architecture, a master-slave architecture, a shared database architecture, and other types of distributed systems. The embodiments are not limited in this context.

The client 100 and/or the server 200 may include a computing architecture as described in the following. In one embodiment, the computing architecture may comprise or be implemented as part of an electronic device. Examples of an electronic device may include those described above. The embodiments are not limited in this context.

As used in this application, the terms“apparatus”,“component”,“client”,“server� ��,“service provider”,“software provider” and“service trust verifier” are intended to refer to a computer- related entity, either hardware, a combination of hardware and software, software, or software in execution, examples of which are provided by the exemplary computing architecture described below. For example, a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical and/or magnetic storage medium), an object, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. Further, components may be communicatively coupled to each other by various types of communications media to coordinate operations. The coordination may involve the uni-directional or bi-directional exchange of information as required. For instance, the components may communicate information in the form of signals communicated over the communications media. The information can be implemented as signals allocated to various signal lines. In such allocations, each message is a signal. Further embodiments, however, may alternatively employ data messages. Such data messages may be sent across various connections. Exemplary connections include parallel interfaces, serial interfaces, and bus interfaces.

The computing architecture may include various common computing elements, such as one or more processors, multi-core processors, co-processors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, video cards, audio cards, multimedia input/output (I/O) components, power supplies, and so forth. The embodiments, however, are not limited to implementation by this computing architecture.

The computing architecture may comprise a processing unit, a system memory, and a system bus. The processing unit can be any of various commercially available processors, including without limitation an AMD® Athlon®, Duron® and Opteron® processors; ARM® application, embedded and secure processors; IBM® and Motorola® Dragon Ball® and PowerPC® processors; IBM and Sony® Cell processors; Intel® Celeron®, Core (2) Duo®, Itanium®, Pentium®, Xeon®, and XScale® processors; and similar processors. Dual microprocessors, multi-core processors, and other multi-processor architectures may also be employed as the processing unit.

The system bus provides an interface for system components including, but not limited to, the system memory to the processing unit. The system bus can be any of several types of bus structure that may further interconnect to a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. Interface adapters may connect to the system bus via a slot architecture. Example slot architectures may include without limitation Accelerated Graphics Port (AGP), Card Bus, (Extended) Industry Standard Architecture ((E) ISA), Micro Channel Architecture (MCA), NuBus, Peripheral Component Interconnect (Extended) (PCI(X)), PCI Express, Personal Computer Memory Card International Association (PCMCIA), and the like. The computing architecture may comprise or implement a computer-readable storage medium to store logic. Examples of a computer-readable storage medium may include any tangible media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re writeable memory, and so forth. Examples of logic may include executable computer program instructions implemented using any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, object-oriented code, visual code, and the like. Embodiments may also be at least partly implemented as instructions contained in or on a non-transitory computer-readable medium, which may be read and executed by one or more processors to enable performance of the operations described herein.

The system memory may include various types of computer-readable storage media in the form of one or more higher speed memory units, such as read-only memory (ROM), random- access memory (RAM), dynamic RAM (DRAM), Double-Data-Rate DRAM (DDRAM), synchronous DRAM (SDRAM), static RAM (SRAM), programmable ROM (PROM), erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, polymer memory such as ferroelectric polymer memory, ovonic memory, phase change or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (SONOS) memory, magnetic or optical cards, an array of devices such as Redundant Array of Independent Disks (RAID) drives, solid state memory devices (e.g., USB memory, solid state drives (SSD) and any other type of storage media suitable for storing information. The system memory can include non-volatile memory and/or volatile memory. A basic input/output system (BIOS) can be stored in the non-volatile memory.

The computing architecture may include various types of computer-readable storage media in the form of one or more lower speed memory units, including an internal (or external) hard disk drive (HDD), a magnetic floppy disk drive (FDD) to read from or write to a removable magnetic disk, and an optical disk drive to read from or write to a removable optical disk (e.g., a CD-ROM, DVD, or Blu-ray). The HDD, FDD and optical disk drive can be connected to the system bus by a HDD interface, an FDD interface and an optical drive interface, respectively. The HDD interface for external drive implementations can include at least one or both of Universal Serial Bus (USB) and IEEE 1394 interface technologies.

The drives and associated computer-readable media provide volatile and/or nonvolatile storage of data, data structures, computer-executable instructions, and so forth. For example, a number of program modules can be stored in the drives and memory units, including an operating system, in particular a kernel of an operating system, one or more application programs, also called applications herein, such as the exemplary client application 1 10 and the exemplary remote application 210, other program modules, and program data. In one embodiment, the one or more application programs, other program modules, and program data can include, for example, the various applications and/or components to implement the disclosed embodiments.

A user can enter commands and information into the computing device through one or more wire/wireless input devices, for example, a keyboard and a pointing device, such as a mouse. Other input devices may include microphones, infra-red (IR) remote controls, radio-frequency (RF) remote controls, game pads, stylus pens, card readers, dongles, finger print readers, gloves, graphics tablets, joysticks, keyboards, retina readers, touch screens (e.g., capacitive, resistive, etc.), trackballs, trackpads, sensors, styluses, and the like. These and other input devices are often connected to the processing unit through an input device interface that is coupled to the system bus, but can be connected by other interfaces such as a parallel port, IEEE 1394 serial port, a game port, a USB port, an IR interface, and so forth.

A display may also be connected to the system bus via an interface, such as a video adaptor. The display may be internal or external to the computing device. In addition to the display, a computing device typically includes other peripheral output devices, such as speakers, printers, and so forth.

The computing device may operate in a networked environment using logical connections via wire and/or wireless communications to one or more remote computers, such as a remote device. The remote device can be a workstation, a server computer, a router, a personal computer, portable computer, microprocessor-based entertainment appliance, a peer device or other common network node, and typically includes many or all of the elements described relative to the computing architecture. The logical connections may include wire/wireless connectivity to a local area network (LAN) and/or larger networks, for example, a wide area network (WAN). Such LAN and WAN networking environments are commonplace in offices and companies, and facilitate enterprise-wide computer networks, such as intranets, all of which may connect to a global communications network, for example, the Internet.

When used in a LAN networking environment, the device is connected to the LAN through a wire and/or wireless communication network interface or adaptor. The adaptor can facilitate wire and/or wireless communications to the LAN, which may also include a wireless access point disposed thereon for communicating with the wireless functionality of the adaptor.

When used in a WAN networking environment, the device can include a modem, or is connected to a communications server on the WAN, or has other means for establishing communications over the WAN, such as by way of the Internet. The modem, which can be internal or external and a wire and/or wireless device, connects to the system bus via the input device interface. In a networked environment, program modules, or portions thereof, can be stored in a remote memory/storage device. It will be appreciated that the network connections are exemplary and other means of establishing a communications link between the devices can be used.

The client/server device is operable to communicate with wire and wireless devices or entities using the IEEE 802 family of standards, such as wireless devices operatively disposed in wireless communication (e.g., IEEE 802.1 1 over-the-air modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth™ wireless technologies, among others. Thus, the communication can be a predefined structure as with a conventional network or simply an ad hoc communication between at least two devices. Wi-Fi networks use radio technologies called IEEE 802.1 1 x (a, b, g, n, ac etc.) to provide secure, reliable, fast wireless connectivity. A Wi-Fi network can be used to connect devices to each other, to the Internet, and to wire networks (which use IEEE 802.3-related media and functions).

Remote services such as remote computation as shown in Figure 1 are inherently insecure and often subject to security leaks that may compromise the service and/or assets of a user because the remote device is owned and maintained by a generally untrusted party, the service provider. Trusted services are a relatively new concept and consequently, the number of solutions is limited.

The HTTPS protocol allows establishing a secure channel with an authenticated server. The server authentication may be based on a X.509 certificate provided by the server which is attested and signed by an a priori trusted certificate authority, in particular a root certificate authority. Even if the server can be authenticated this way and a secure channel can be established that provides confidentiality and communication integrity, the process can still be compromised by malicious software on the side of the service provider. Memory accesses to the remote application from software components at higher privilege levels than the remote application, in particular system software components including a hypervisor, also called Virtual Machine Monitor (VMM), and the kernel of the operating system, can compromise the remote application, for instance if the respective software components include malicious software. In this case, even the setup of the secure channel, e.g. via a Transport Layer Security (TLS) client, can be compromised such that confidentiality and communication integrity cannot be guaranteed.

To resolve the issue of malicious software at higher privilege levels, the concept of a trusted execution environment was introduced. Application code for remote applications, such as a web server or a game client, running at the lowest privilege level is executed in an isolated execution environment, a so-called secure container or secure enclave. The enclave’s code and data are protected by preventing even privileged system code from accessing the content of the enclave. Instead, a limited set of trusted functions is provided that may be used to access the content of the enclave.

An example of a trusted execution environment are Intel’s Software Guard Extensions (SGX) as described in detail in the review paper‘Intel SGX Explained’ by Victor Costan and Srinivas Devadas, published in 2016, in IACR Cryptology ePrint Archive. SGX is a set of extensions to the Intel architecture that aims to provide integrity and confidentiality guarantees to security- sensitive computation performed on a computer where all the privileged software (kernel, hypervisor, etc.) is potentially malicious. An SGX-enabled processor protects the integrity and confidentiality of the computation inside an enclave by isolating the enclave’s code and data from the outside computing environment, including the operating system and hypervisor, and hardware devices attached to the system bus. In SGX, an enclave (secure container) only contains the private data in a computation and the code that operates on it. An application is generally built with trusted and untrusted parts where only the trusted parts are executed inside the enclave. Enclaves can work together to support distributed architectures. Enclave code and data run in the clear and enclave data written to disk is encrypted and checked for integrity.

Figure 2 schematically shows a modified configuration of the client-server architecture of Figure 1 for trusted computing using secure containers as described above. The service provider 300 in this configuration provides a trusted execution environment 320 in which one or more secure enclaves 330 are initialized to execute remote applications 310 that ultimately provide the remote service requested by the client 100. For simplicity, only the trusted part of the remote applications is shown in the Figures.

A typical execution may be as follows. First, the remote application is built with trusted and untrusted parts. The application may be provided by the service provider 300 itself, e.g., as SaaS, or received via a secure channel from the client 100. When the application runs, an enclave is created which is placed in the trusted memory of the processor. A trusted function is called and execution is transitioned to the enclave. The enclave sees all process data in clear while external access to enclave data is denied. The trusted function returns enclave data and the application continues normal execution.

Like its predecessors, the Trusted Platform Model (TPM) and Trusted Execution Technology (TXT), SGX relies on software attestation to prove to a user that he/she is communicating with a specific piece of software running in a secure container hosted by the trusted hardware. The proof may be a cryptographic hash, such as SHA-1 , SHA-2, SHA-256, MD4, or MD5, that certifies the hash of the secure container’s contents. The service provider can load any application in a secure container but the user/client will refuse to load his/her data into a secure container whose contents’ hash does not match the expected value. A processor and enclave- specific sealing key can be used to safely store and retrieve sensitive information that may need to be stored on disk.

An SGX enclave 330 may generate an SGX report containing a cryptographic hash of the enclave’s data, e.g., the remote application 310. The service provider may further generate a linkable quote on the SGX report which may be signed by a Quoting Enclave (QE) (not shown) which may, in turn, generate a quote Q on the SGX report that contains the report and the cryptographic hash. The Quoting Enclave (QE) may be provided as a separate enclave on the side of the service provider 300. The SGX enclave 330 may request for attestation of the quote Q from a third party attestation service, e.g., Intel’s Attestation Service (IAS), which may reside on a remote server. The attestation response from the attestation service may be signed with a public key and may contain a copy of the quote. The service provider 300 may then send the quote, the IAS attestation report on said quote and the data as an attestation response to the client 100 that requested attestation in a corresponding attestation request. After receiving the attestation response, the client 100 may verify the validity of the quote by checking the signature on the IAS response with the public key. The client may further verify that the cryptographic hash of the data corresponds to the hash within the quote. In this manner, the data may be trusted to come directly from the sending enclave.

The cryptographic hash may be generated on any data that a remote application 310 may require to be securely handled by a secure enclave 330 of the service provider 300. The data may for instance, comprise the binary code of the application.

If the application generates a public key for establishing a secure channel between the client 100 and the secure enclave 330, the cryptographic hash of the corresponding binary code may be used by the client to verify that the public key was generated by an SGX protected application whose identity is given by the hash. The public key may be used to generate a shared secret for a secure channel between the client 100 and the secure enclave 330.

If the application is a remote application to be executed as a service, both SaaS and laaS, the cryptographic hash may be used as an identity of the application. In this case, the client 100 is enabled to verify the identity of the application based on the attestation response.

By extending the client-server architecture of Figure 1 with the trusted execution environment and attestation of Figure 2, a client 100 may verify the identity of a remote application 310 executed in the trusted execution environment 320 of a service provider 300. The problem, however, remains to determine whether the application with the verified identity can be trusted. By way of example, security leaks may arise for an application provided by the service provider 300 as a SaaS that itself contains malicious code or is insecure, e.g. by including unsafe function calls outside the secure enclave. In this case, a mere verification of the application ID would not detect the security breach.

The present disclosure solves this issue by adding a further entity to the secure remote computation system of Figure 2 that collects one or more evidences that the remote application can be trusted. Figure 3 illustrates the concept of trust verification based on trust evidences according to the present disclosure. Figures 4 and 5 show two alternative configurations for trust verification of a remote service according to embodiments of the present disclosure.

According to the present disclosure, a service trust verification unit 400, called service trust verifier, is provided to manage communication between the client 100 and the remote application 310. The service trust verifier may be implemented as an apparatus or device, in particular as part of a remote computer 600 as shown in Figure 5, as an application or application module, in particular a plug-in module to a web browser, that is executed by the client 100 or the remote computer 600 or a combination thereof.

The purpose of the service trust verifier 400 is to provide an intermediate entity that determines whether a specific remote service or remote application 310 is trusted when the client wants to communicate with the remote service or vice versa. Determination of whether a remote application can be trusted is in particular, performed by the service trust verifier 400 at the time of a client request for a remote service provided through the remote application. After the service trust verifier 400 establishes that a specific remote service is trusted, a connection can be established between the client 100 and the secure enclave 330. This connection may be a direct connection, i.e. by-passing the service trust verifier 400 in future communications related to the specific remote service, or may be established via the service trust verifier 400.

In the latter case, all network traffic between the client 100 and the remote application 310, or more specifically the secure enclave 330, is handled by the service trust verifier 400. As there is no direct communication between the client 100 and the remote application 310 in this case, an additional level of security is added as compared to the use of a standard network protocol such as HTTPS over TLS. The communications between the client 100 and the service trust verifier 400 as well as between the service trust verifier 400 and the service provider 300 can, however, use standard network protocols such as HTTPS over TLS. A secure channel may be established between the service trust verifier 400 and the secure enclave 330 based on a public key and attestation as described above. The service trust verifier 400 can be designed as a trusted entity, e.g. by locating it at the premises of the user. If the service trust verifier is provided as a separate entity, for instance as part of a remote computer 600 as shown in Figure 5, the service trust verifier itself must be bootstrapped as trusted, as for instance described below with regard to Figure 5.

The service trust verifier can be provided as a standalone apparatus at the premises of a user or can be integrated into the client, for instance a web browser, as shown in Figure 4. Alternatively, the service trust verifier may be located outside the premises of the user as a service by itself, as mentioned above and as shown in Figure 5.

In the following, the method of trust verification of a remote service according to the present disclosure is described in general with reference to Figure 3. The process starts with a client 100, or more specifically a client application 1 10, issuing a request for a specific service provided by the remote application 310 through the service trust verifier 400. If necessary, for instance if the service trust verifier is provided as a separate device, in particular a remote device, a secure channel is established between the client 100 and the service trust verifier 400 before a request for the remote service can be issued.

Based on the request, the service trust verifier 400 identifies a service provider 300 capable of providing the requested service and sends an attestation request for an attestation of an identity of a corresponding remote application to the service provider 300. By way of example, the attestation request can be included in the request for the remote service as known in the art. The attestation request, and the corresponding attestation response, may be communicated over a secure channel between the service trust verifier 400 and the service provider 300 as known in the art. If the request for a remote service is a request for an SaaS service, the request may include a user application or client application in the form of application code or a binary to be executed on the side of the service provider 300. The user application may be transmitted and built inside the secure enclave 330 of the service provider 300 as a result of the service request and/or the attestation request. Thus, a separate service request may be communicated by the service trust verifier 400 to the service provider 300 before communicating the attestation request to the service provider. Alternatively, the service request and the attestation request may be transmitted together, in particular as a single request.

Upon reception of the service request, and optionally the attestation request, the service provider 300 initializes a secure enclave 330 in a trusted execution environment 320 for execution of the remote application 310. Initializing the secure enclave may in particular, include building the remote application, e.g., compiling the remote application. The term “remote application” is used in this disclosure to include standalone applications as well as distributed applications. Consequently, the software attestation may be performed with regard to a standalone application or a distributed application. Therefore, a distributed attestation with regard to multiple cooperating secure enclaves on a single server device or a distributed system may be performed.

As part of software attestation, the trusted execution environment may sign a small piece of attestation data, producing an attestation signature, as known in the art. Aside from the attestation data, the signed message includes a measurement that uniquely identifies the remote application. The attestation data may in particular include a public key that may be used for establishing a secure channel between the service trust verifier 400 and the secure enclave 330. The measurement, referred to here and in the following as the identity of the remote application, may include or consist of a cryptographic hash of the contents of the one or more secure enclaves. By way of example, a binary of the remote application may be cryptographically hashed to produce a unique identity of the remote application. Additional or alternative data may be cryptographically hashed to produce the identity. By way of example, a cryptographic hash of the enclave log as the enclave goes through every step of the build and initialization process may be used as the identity of the remote application. Furthermore, a configuration of the remote application, in particular, with regard to a distributed application, may be included in the cryptographic hash. Finally, additional data, in particular input data, required to execute the remote application may be included in the cryptographic hash.

As a result, the identity of the remote application constitutes a unique identity within the limits of the employed cryptographic hash function, such as SHA-1 , SHA-2, SHA-256, MD4, or MD5. Consequently, the identity of the remote application can be used to convince a client or a third party that a specific piece of software is running in a secure container hosted by the trusted hardware. In addition, the attestation signature can be used to convince the client or third party that the attestation data was produced by the specific piece of software, i.e. remote application. As the application ID may include the configuration of the remote application with regard to the system architecture of the service provider 300, it also provides integrity with regard to the configuration of the remote application.

After calculating the identity of the remote application, the service provider 300 according to the present disclosure sends an attestation response including the requested attestation of the identity of the remote application to the service trust verifier 400. As described above, the attestation response may include additional information such as an attestation signature, a topology or configuration of a distributed execution environment for executing the remote application, or the like as metadata.

Upon reception of the attestation response, the service trust verifier 400 performs trust verification based on the attestation response and at least one trust evidence. According to the present disclosure, the service trust verifier uses information included in the attestation response, in particular the attested identity of the remote application and/or the metadata, in combination with the one or more trust evidences generated by at least one party different from the service provider 300 to automatically determine whether the identity of the remote application is trusted.

The at least one party different from the service provider may be a third party, in particular a trusted third party (TTP), or the client 100, or the service trust verifier 400 itself. Trust is built according to this disclosure based on the independence of the at least one party from the service provider 300. Additionally, the trust evidences as described in detail below are selected and generated in a way that provides additional, independent information on the trustworthiness of the remote application with regard to the attested identity of the remote application. Depending on the sensitivity of the requested service and in particular, the involved assets of the user, a larger number of trust evidences may be required to determine the trustworthiness of a remote application. By way of example, a requirement setting provided as a configuration file in a storage unit of the service trust verifier may be used by the service trust verifier to determine which and how many trust evidence items are required to establish that a specific remote service can be trusted. The sensitivity may be included as a parameter in the service request from the client 100.

As indicated in Figure 3, one or more trust evidences 410 and 420 may be collected by the service trust verifier 400 from a trusted third party 700 and/or the client 100. The trust evidences may be collected independently of the service request and stored by the service trust verifier in a corresponding storage unit and/or may be collected when performing trust verification for a specific remote service. A trusted third party may include, but not limited to, an authentication server, a certificate authority, a trusted software house server, a communication server, and so forth. A list of trusted third parties 700 may be stored by the service trust verifier, similar to a list of certificate authorities, together with information on the type of trust evidence and/or remote service on which trust evidence can be provided available from the specific third party. Communication between the service trust verifier 400 and the trusted third party 700 can be performed via a secure channel as known in the art. In addition, the trusted third party itself may implement a trusted execution environment for generating the trust evidence and attesting the software used for the generation.

By way of example, a list of trustworthy application identities may have been collected from one or more trusted third parties 700 by the service trust verifier 400 in advance. Upon reception of the attestation response, the service trust verifier 400 may compare the identity of the remote application received together with the attestation response with the list of trustworthy application identities and may determine to trust the identity of the remote application, and thereby the remote application and remote service themselves, if the received identity of the remote application is included in the list of trustworthy application identities. Alternative and additional embodiments of trust evidences that may be used by the service trust verifier 400 to establish that a remote application 310 can be trusted will be described in the following.

Upon determination that the identity of the remote application is trusted, the service trust verifier 400 connects to the remote application 310, more specifically to the secure enclave 330. As described above, this connection can be established via a secure channel, in particular using a public key included in the attestation response. The connection established by the service trust verifier is thus bound to the specific secure enclave 330, e.g., through the public key. If the secure enclave 330 ceases to exist, for instance because execution of the remote application 310 terminates, the communication channel between the service trust verifier 400 or the client 100 and the secure enclave 330 is also terminated. As a consequence, each service request requires the establishment of a separate communication channel and therefore, a separate verification whether the requested remote service can be trusted. This provides an additional level of security against attacks, such as man-in-the-middle attacks. Furthermore, trust verification according to the present disclosure extends only to a specific remote application, not to the entire service provider.

According to a specific embodiment, the service trust verifier 400 may handle all network traffic between a client and the remote application, i.e. all network traffic with regard to the requested remote service. This provides a further level of security as no direct communication occurs between the client 100 and the service provider 300.

According to one embodiment, the remote application may be provided by the service provider, for instance as part of Software as a Service (SaaS). In this case, a service request may be a request for executing the remote application on specific user data. Here, a user may wish to receive guarantees that the user data is treated confidentially by the service provider and that the remote application can be trusted. As described above, the user may wish to verify that the remote application can be trusted before loading his or her data into the secure enclave. In this case, trust verification by the service trust verifier may be based on at least one trust evidence generated by a third party different from the service provider and the service trust verifier.

A trust evidence may for instance, include or consist of an attestation by the third party that the identity of the remote application is trustworthy. This attestation may for instance be provided in the form of a digital signature on the identity of the remote application. Upon reception of the attestation response from the service provider 300, the service trust verifier 400 may send a request for such an attestation to a trusted third party 700 including the identity of the remote application. The third party 700 may verify that the identity of the remote application is included in a list of trustworthy application identities and return an attestation, that the identity of the remote application is trustworthy, to the service trust verifier 400 upon determination that the identity of the remote application is included in the list.

To make a trusted third party 700 include the identity of a remote application of a service provider, the service provider 300 may have to demonstrate to the third party 700 that certain security standards are maintained, for instance that the remote application is free of malware and backdoors. This demonstration may involve transmitting the corresponding code and data of the remote application to the third party 700 which may build the remote application in a secure enclave with an identical configuration as the one used by the service provider and/or performing an analysis of the remote application, in particular a static program analysis, to determine whether the remote application includes security leaks such as memory accesses to unprotected memory.

If the third party 700 cannot find the identity of the remote application in the list of trustworthy application identities, it may return a negative attestation to the service trust verifier 400. Based on the negative attestation, the service trust verifier 400 may reject establishing a connection to the secure enclave 330 and communicate this rejection to the client 100 and the service provider 300.

Upon reception of the attestation from the third party 700, the service trust verifier 400 may verify the digital signature to determine whether the identity of the remote application is trusted. Verification of the digital signature may be done using a public key provided with a certificate for the trusted third party. In case the digital signature confirms the identity of the remote application, the service trust verifier 400 may determine that the remote application is trusted. The service trust verifier may, however, require additional trust evidence, depending on the sensitivity of the requested service and requirement settings as described above, before it is determined that the remote application is trusted. Equally, the specific trust evidence of a digital signature on the application ID may not be required to establish that the remote application is trusted if at least one qualifying trust evidence is collected and verified.

The at least one trust evidence may include a proof of analysis generated by the third party for the remote application, in particular a static analysis of the remote application with regards to malicious software and/or backdoors. This proof of analysis may be performed by the third party upon request by the service provider 300 and/or a software provider that provides the remote application to the service provider 300. The proof of analysis may in particular be performed every time an updated version of the remote application becomes available and/or is installed on the side of the service provider. As described above, the proof of analysis, in particular a static program analysis, may be performed by the third party 700 in an execution environment, in particular with regard to a secure enclave, identical to the execution environment provided by the service provider 300.

The proof of analysis may be a message specifying that a remote application with a specific application ID is free of malicious software and/or backdoors. The message may in particular, comprise a digital signature on the identity of the remote application. The proof of analysis may additionally or alternatively include a set of parameters that reflect the results with regard to potential security leaks of specific tests performed on the remote application by the third party. By way of example, the parameters may quantify security risks with regard to handling of interrupts, distributed computing and enclave cooperation, address translation and page swapping, cache coherence, thread handling, Enclave Page Cache (EPC) page eviction, encryption, robustness or function calls, trusted function calls, and the like. The parameters may be processed by the third party to determine a single value or set of values that reflect the robustness of the remote application against attacks. Trust verification by the service trust verifier 400 may then include comparing the single value or the set of values with at least one requirement setting that may be predefined or received together with the service request from the client 100. Receiving at least one requirement setting together with the service request enables a user to raise or lower the security requirements with regard to the sensitivity of the assets involved with the remote service.

In a specific embodiment, the single value or the set of values may be included in the attestation response from the service provider 300 as metadata, for instance in the form of a signed message that was signed by the trusted third party 700. Based on a certificate, the service trust verifier 400 may verify the integrity of the corresponding metadata and use the value or the set of values as described above to determine whether the identity of the remote application is trusted.

According to a further embodiment, the at least one trust evidence may include a degree of trust related to the identity of the remote application and/or to the service provider and/or to a provider of the remote application, i.e. a software provider. Information on the service provider and/or the provider of the remote application may be included as metadata in the attestation response from the service provider 300. The degree of trust, however, is collected from a trusted third party 700, not from the service provider 300 itself. The degree of trust may for instance reflect a probability to trust the specific remote application and/or the specific service provider and/or the specific software provider, established by an independent entity such as a trusted third party.

As such, the degree of trust may be collected by the service trust verifier from a trusted database storing various degrees of trust for known service providers, software providers, and/or remote applications. Alternatively or additionally, the degree of trust may be collected from a chain of trust, for instance including the software developer, one or more software distributors, the service provider, and a trusted third party wherein each entity validates the degree of trust of the next entity in the chain up to the root entity. Alternatively, a block chain may be employed to collect the degree of trust wherein each block contains a cryptographic hash of the previous block including the degree of trust. The original genesis block of such a block chain may be generated by a trusted authority that vouches for the service provider, the software provider or even a specific application. Alternatively, the software provider may sign the application ID and include the signature in the genesis block. Using a block chain allows quickly reacting to a loss of confidence in the trustworthiness of a specific service provider or software provider for the case that the specific service provider or software provider is found to be compromised.

Based on the degree of trust, the service trust verifier 400 may determine whether the identity of the remote application is trusted and/or whether the service provider in general is trusted and/or whether the respective software provider is generally trusted, for instance by comparing the degree of trust with a threshold that may be predefined on the side of the service trust verifier or received from a client 100. Again, a client application 1 10 may include such a threshold in the service request based on the sensitivity of the requested service and the involved assets.

The at least one trust evidence may include a trust evidence that is generated based on a configuration of the remote application. Such a configuration may include a list of the components, e.g., modules, of the remote application as well as their specific relationships and/or functions, such as web servers, application servers, etc., the topology of the remote service, e.g., how the various components are connected to each other, the configuration of the various components, and so forth. The configuration may be included as metadata in the attestation response and used by the service trust verifier 400 to calculate an identity of the remote application if it was executed with the configuration in the trusted execution environment of the service provider.

Alternatively, in the case that the remote application is a user application or client application provided by the client 100 to the service provider 300 as described above wherein the user application/client application is executed by the service provider 300 as Infrastructure as a Service (laaS), the configuration may be included in the service request from the client 100 to the service trust verifier 400. In a specific embodiment, the client 100 itself may calculate an identity of the user application/client application if it was executed as a remote application with the specific configuration in the trusted execution environment of the service provider. Alternatively, the service trust verifier 400 may use the configuration received from the client 100 to calculate the application ID.

In any case, any specifics of the trusted execution environment of the service provider 300, such as a topology of a distributed system involving several secure enclaves, may be included in the attestation response to the service trust verifier 400 as part of the metadata. The service trust verifier may use the specifics to calculate the application ID or forward the specifics to the client 100 in case the client calculates the application ID. Consequently, the corresponding trust evidence can be generated by the client itself or by the service trust verifier. If the trust evidence is generated by the client 100, the trust evidence 410 is communicated by the client 100 to the service trust verifier 400, for instance in response to transmission of the specifics of the trusted execution environment.

The service trust verifier 400 may then compare the calculated application ID with the identity of the remote application received together with the attestation response and determine to trust the remote application if the identities are identical.

The present disclosure is, however, not limited to the above examples of trust evidences but may include other trust evidences as long as they are generated by an entity different from the service provider, as well as combinations of the above described trust evidences. Various trust evidences may be evaluated with predefined weighting factors to determine whether a specific remote application should be trusted even if certain trust evidences are missing or negative.

As mentioned above, the service trust verifier may be provided as a separate entity such as an application executed on a remote computer 600 as shown in Figure 5, as a standalone apparatus, provided remotely or at the site of the client, i.e. within control of the user, or as an application, module or plug-in to a client application executed on the side of the client as shown in Figure 4.

Figure 4 shows a configuration for trust verification of a remote service wherein the service trust verifier 540 is provided on the side of the client 500, in particular as a plug-in to a web browser shown as a client application 510. Alternatively, the service trust verifier 540 may be provided as a separate application executed on the client device. Due to the fact that the service trust verifier 540 in this particular embodiment is fully under the control of the client 500, the service trust verifier can implicitly be trusted by the client application 510. In fact, the service trust verifier 540 may be used to handle all network traffic related to the requested remote service as described above.

As described above in detail, one or several trust evidences 420 can be collected by the service trust verifier 540 from one or several trusted third parties 700. The trusted third parties 700 may interact with the service provider 300 and potentially a software provider 800 that provides code, binaries, and the like to the service provider 300 for the remote application 310 to generate one or several of the above described trust evidence items.

Figure 5 shows a configuration for trust verification of a remote service according to an alternative embodiment of the present disclosure. According to this embodiment, the service trust verifier 640 is provided as a remote entity with regard to the location of the client 100. Consequently, the client 100 does not have control over the service trust verifier 640. To verify that the service trust verifier itself can be trusted by the client 100, the service trust verifier 640 may be executed in a secure enclave 630 in a trusted execution environment 620 on the remote computer 600. The above-described attestation, potentially including a third party attestation service, may be used to attest the identity of the service trust verifier 640 toward the client 100. The service trust verifier 640 or the remote computer 600 may be part of a chain of trust as described above. In fact, the service trust verifier 640 may be treated with regard to trust verification by the client 100 in many aspects as the remote application 310 of the service provider 300. Due to the limited functionality of the service trust verifier 640, such trust verification may, however, be significantly simplified as compared to trust verification for the remote application 310. It is understood that the present disclosure further includes combinations of the embodiments of Figures 4 and 5.

Trust verification of a remote service, in particular a remote application, according to the present disclosure allows verifying whether a remote application should be trusted in addition to the attestation of an identity of the remote application. As the trust verification is based on separately generated trust evidences, in particular originating from independent trusted third parties, the risk of the remote service and the involved user assets being compromised can be significantly reduced. As a result, confidence in the integrity and confidentiality of a remote service, and cloud computing as a whole, can be increased leading to a higher acceptance of remote computing.