CN113302893B

CN113302893B - Method and device for trust verification

Info

Publication number: CN113302893B
Application number: CN201980088433.8A
Authority: CN
Inventors: 丹·图伊图; 阿维盖尔·奥兰; 阿亚尔·男爵
Original assignee: Huawei Cloud Computing Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2019-01-08
Filing date: 2019-01-08
Publication date: 2022-11-18
Anticipated expiration: 2039-01-08
Also published as: WO2020143906A1; CN113302893A

Abstract

The present invention relates to an apparatus and a method for trust verification of a remote service, wherein an attestation request is sent to a service provider (300) attesting to an identity of a remote application (310) executed at least partly in a trusted execution environment (320) of the service provider (300); receiving an attestation response from the service provider (300) comprising the proof of request of the identity of the remote application (310); and wherein it is determined whether the identity of the remote application (310) is trusted based on the attestation response and at least one trust proof generated by at least one party other than the service provider (300).

Description

Method and device for trust verification

The present invention relates to a method and apparatus for trust verification of remote services in a distributed computing environment.

Background

In the field of distributed computing environments, cloud computing is becoming increasingly important as a way to implement more flexible, scalable, and more efficient systems. However, as users of cloud computing services lose direct control over data and applications hosted by cloud providers, the trustworthiness of cloud services becomes a major issue hindering cloud application deployment.

To entice users to use cloud services, cloud/service providers provide trusted services to ensure that data and applications provided to the services remain secure and protected to the users, and that the services will only use these data and applications as intended by the users.

One example of a trusted service is an online survey service that guarantees to survey participants that the answers will be kept private, and that only aggregated results will be shared with subscribers of the survey. In addition, the survey subscriber can be assured that the survey questions and corresponding results remain his or her property and are not shared with third parties.

Another example is a trusted cloud service that guarantees to its customers that their applications will run in the cloud, will not be modified and protected, even though the cloud provider offering the service as an infrastructure as a service (IaaS) cannot.

Trusted services may be developed using Trusted Execution Environment (TEE), such as Intel SGX. The TEE is a secure section of the processor that establishes an isolated execution environment that provides security features such as isolated execution, integrity of applications executing with the TEE, and confidentiality of their assets.

Trusted execution environments such as Intel SGX may ensure that applications running therein have the following properties: code is not changeable, i.e., the logic of the protected application cannot be changed; data confidentiality, which can ensure that the application program can not be accessed without authorization; and proof that the protected application is able 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 user's assets are protected and that the services provided can prove their identity to the user.

The service identity is typically a large number, e.g., 256 bits, and may be the result of a cryptographic hash over the service executable (i.e., the application's binary code) or the entire application deployment including the individual components of the service and topology.

Known attestation schemes, such as the intel SGX attestation, enable a user wishing to connect to a particular service to obtain attestation of the identity of the service X. However, users have limited use of such schemes because users typically do not know whether and why a service with identity X should be trusted. The service itself may still include malware or otherwise harm the user's assets. Therefore, it is desirable to provide a mechanism that can verify whether service X is trusted. The mechanism should be transparent to the user to facilitate detection of fraud. It should also be versatile and easy to implement in existing infrastructure.

Disclosure of Invention

The present invention provides a method and apparatus for trust verification of remote services that allows a user or client to determine whether a remote application of a service provider having a particular identity can be trusted. The present invention provides a transparent mechanism to connect the user to the remote service while ensuring that the service is trusted.

According to an aspect of the invention, there is provided an apparatus for trust verification for a remote service, wherein the apparatus comprises processing circuitry to: sending an attestation request to attest to an identity of a remote application executing at least partially in a trusted environment of a service provider; receiving an attestation response from the service provider including the requested attestation of the identity of the remote application; 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 other than the service provider. The trusted environment is preferably a secure enclave.

The processing circuit may be further operable to connect to the remote application upon determining that the identity of the remote application is trusted. The processing circuitry may also be configured to process all network traffic between a client and the remote application. Trust verification may be performed as a service in a secure enclave of a device, and the processing circuitry may also be used to provide attestation of the service to a client. Network traffic between the client and the remote application preferably passes through a secure channel.

According to another aspect, the remote application may be provided by the Service provider as a Software as a Service (SaaS), wherein the at least one proof of trust is generated by a third party different from the Service provider and the apparatus.

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

The at least one proof of trust may include an analysis proof generated by the third party for the remote application, wherein determining whether the identity of the remote application is trusted comprises comparing the analysis proof to at least one requirement setting, the at least one requirement setting being predefined and/or received from a client application. The analytical proofs generated by the third party for the remote application are preferably static analyses of the remote application with respect to malware and/or backdoors.

The at least one proof of trust may comprise a degree of trust relating to the identity of the remote application and/or the service provider and/or a provider of the remote application, wherein determining whether the identity of the remote application is trusted comprises comparing the degree of trust to a threshold, the threshold being predefined and/or received from a client application.

According to another aspect, the remote application may be a client/user application provided by the client to the Service provider and executed by the Service provider as an Infrastructure as a Service (IaaS), wherein the at least one proof of trust 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 comprises the processing circuit calculating the identity of the remote application in the trusted execution environment of the service provider using the configuration.

According to another aspect of the present invention, there is provided a method for trust verification of a remote service, wherein the method comprises: sending an attestation request to a service provider to attest to an identity of a remote application executing at least partially in a trusted environment of the service provider; receiving an attestation response from the service provider including the requested attestation of the identity of the remote application; 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 other than the service provider. The trusted environment is preferably a secure enclave.

The method may also include connecting to the remote application upon determining that the identity of the remote application is trusted. The method may also include processing all network traffic between the client and the remote application. The trust verification itself may be performed in the secure enclave as a service whose attestation may be provided to the client. Network traffic between the client and the remote application preferably passes through a secure channel.

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

The at least one proof of trust may include an analysis proof generated by the third party for the remote application, wherein determining whether the identity of the remote application is trusted comprises comparing the analysis proof to at least one requirement setting, the at least one requirement setting being predefined and/or received from a client application. The assay proof is preferably a static analysis of the remote application with respect to malware and/or backdoors.

According to another aspect, the remote application may be a client/user application provided by the client to the Service provider and executed by the Service provider as an Infrastructure as a Service (IaaS), wherein the at least one proof of trust 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 comprises the client computing the identity of the remote application in the trusted execution environment of the service provider using the configuration.

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

The apparatus may comprise a dedicated service trust verification unit for performing any of the methods described above. The service trust verifier 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). However, the invention is not limited to implementing 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 hardware components.

Drawings

Exemplary embodiments are described in detail below with reference to the attached drawing figures, wherein:

FIG. 1 schematically illustrates a general client-server configuration for a remote service (e.g., remote computing);

FIG. 2 schematically illustrates a trusted computing configuration using secure containers as known in the art;

FIG. 3 illustrates the concept of trust verification based on trust evidence provided by the present invention;

FIG. 4 illustrates a configuration for trust verification for remote services provided by a first embodiment of the present invention;

fig. 5 shows a configuration of trust verification for a remote service provided by the second embodiment of the present invention.

Detailed Description

The present invention relates to the general technical field of authentication of remote services such as cloud computing, software as a Service (SaaS), infrastructure as a Service (IaaS), and remote computing. It provides a transparent mechanism for a user to determine whether a remote application with a certified identity can be trusted.

Fig. 1 schematically shows a general client-server architecture for remote services. The configuration includes one or more clients 100 in communication with one or more servers 200. The client may be implemented by a user device or a client device, as described below. The server may be implemented by a server device provided by a service provider and/or a cloud provider. However, the present invention is not limited to these particular implementations, but may be applied to any configuration in which a local client (device) requests a service provided by a server to the client from a remote server (device). It will be appreciated that services may not only be provided by a single server or server device, but may also rely on a distributed system architecture. For example, the servers may include a Web server, an application server, and a database server as the front end. For simplicity, the remote entities providing the services, whether single servers or server devices, distributed or microservice-based systems, etc., are referred to hereinafter as service providers. Further, the client is not limited to a single client or client device, but may include a distributed system. The client may also act as a server itself in a distributed environment, e.g., as an intermediate server. The term "client" is used herein to include any of the above architectures and merely means that the entity 100 (e.g., a client device) receives a service from a remote entity 200 (e.g., a server device). Client 100 and server 200 may even switch roles with respect to other aspects besides providing and receiving remote services.

The clients 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 may be used to store information local to the respective clients 100 and servers 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 a key and/or signature used to establish a secure communication channel, one or more applications, e.g., as code or binary files, input data and/or configuration data for executing a remote application, output data of a remote application, etc.

In the IaaS architecture, remote applications may be provided by the client 100 and transmitted to the service provider 200 through a communication channel before being executed by the service provider. In this case, the remote service may include installing (e.g., compiling) application code received from the client, executing the received application as a remote application program on the service provider side, and transmitting the execution result back to the client 100. In the SaaS architecture, the remote application is provided by the service provider itself, and the remote service includes executing the remote application on input data received from the client 100, possibly, and transmitting the result to the client.

The communication framework for communication 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., a public network such as the internet, a private network such as an intranet, etc.), a circuit-switched network (e.g., a 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 communication elements such as transmitters, receivers, transceivers, radios, network interfaces, baseband processors, antennas, amplifiers, filters, power supplies, and so forth. Embodiments, however, are not limited to these implementations.

The communications framework may implement various network interfaces arranged to receive, communicate, and connect to a communications network. A network interface may be considered a specialized form of input/output interface. The network interface may use a connection protocol including, but not limited to, a direct connection, ethernet (e.g., thick, thin, twisted pair 10/100/1000Base T, etc.), token ring, wireless network interface, cellular network interface, IEEE 802.11a-x network interface, IEEE 802.16 network interface, IEEE 802.20 network interface, and the like. Further, multiple network interfaces may be used to interface with various communication network types. For example, multiple network interfaces may be used to communicate over broadcast, multicast, and unicast networks. If processing demands require higher speeds and capacities, the distributed network controller architecture may similarly be used for pooling, load balancing, and otherwise increasing the communication bandwidth required by the clients 100 and servers 200. The communication network may be any one or combination of wired and/or wireless networks including, but not limited to, direct interconnects, secure custom connections, private networks (e.g., intranets), public networks (e.g., the Internet), personal Area Networks (PANs), local Area Networks (LANs), metropolitan Area Networks (MANs), internetworks, operating tasks for nodes on the Internet (OMNI), wide Area Networks (WANs), wireless networks, cellular networks, and other communication networks.

As described above, client 100 and server 200 may each comprise a device, which may be any electronic device capable of receiving, processing, and transmitting information via a communication component or the like. Examples of an electronic device may include, but are not limited to, a client device, a Personal Digital Assistant (PDA), a mobile computing device, a smartphone, a cellular telephone, an e-book reader, a message processing 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 array or server farm, a Web server, a network server, an internet server, a workstation, a network appliance, a Web appliance, a distributed computing system, a multi-processor system, a processor-based system, a consumer electronic device, a programmable consumer electronic device, a gaming device, a television, a set-top box, a wireless access point, a base station, a subscriber station, a mobile subscriber center, a wireless network controller, a router, hub, gateway, bridge, switch, machine, or a combination thereof. The embodiments are not limited in this context.

The device may execute processing operations or logic for one or more applications (such as exemplary client application 110 and remote application 210), communications components, operating systems, and in particular the kernel of an operating system, as well as other software elements using one or more processing components. Processing components may include 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 (ASICs), programmable Logic Devices (PLDs), digital Signal Processors (DSPs), field Programmable Gate Arrays (FPGAs), memory units, logic gates, registers, semiconductor device, 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 embodiments of the service trust verification unit described below are 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.

A device may perform communication operations or logic for communicating with other devices using one or more communication components. The communication components may implement any well-known communication 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 intranets, etc.), 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 communication components may include various types of standard communication elements, such as one or more communication interfaces, network Interface Cards (NICs), 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 includes wired communications media and wireless communications media. Examples of wired communications media may include a wire, cable, metal leads, printed Circuit Board (PCB), backplane, switched fabric, semiconductor material, twisted-pair wire, co-axial cable, fiber optics, a propagated signal, and so forth. Examples of wireless communication media may include acoustic, radio-frequency (RF) spectrum, infrared and other wireless media.

A device may communicate with other devices over a communication medium using the communication signals shown in fig. 1 through one or more communication components. Other devices may be internal to the device as shown in fig. 4 or external to the device as shown in fig. 5, as desired for a given implementation.

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

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

As used in this application, the terms "device," "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, or software in execution, examples of which are provided by the exemplary computing architecture described below. For example, a component may be, but is not limited to being, a process running on 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. For example, 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 may be localized on one computer and/or distributed between two or more computers. Further, the components may be communicatively coupled to each other by various types of communications media to coordinate operations. Coordination may involve one-way or two-way information exchange as desired. For example, a component may communicate information in the form of signals communicated over the communications media. This information may be implemented as signals assigned to various signal lines. In this type of allocation, each message is a signal. However, other embodiments may employ data messages. Such data messages may be sent over 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, sound cards, multimedia input/output (I/O) components, power supplies, and so forth. However, the embodiments are not limited to implementation by this computing architecture.

The computing architecture may include a processing unit, a system memory, and a system bus. The processing unit can be any of various commercially available processors, including but not limited to

And

a processor;

application programs, embedded and secure processors;

and

and

a processor; IBM and

a Cell processor;

Core(2)

and

a processor; and the like. Dual microprocessors, multi-core processors, and other multiprocessor architectures also can 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 may 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. The interface adapter may be connected to the system bus through a socket architecture. Exemplary slot architectures may include, but are not limited to, 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 include or implement a computer-readable storage medium to store logic. Examples of a computer-readable storage medium may include any tangible medium 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 implemented, at least in part, as instructions contained in or on a non-transitory computer-readable medium, which may be read and executed by one or more processors to implement operational performance described herein.

The system memory may include various types of computer-readable storage media in the form of one or more high-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 (ROM ), 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, arrays of devices, such as arrays of individual solid-state drives (solid-state drives), and other types of storage media suitable for storing information, such as RAID, USB, flash, and other types of redundant storage devices. The system memory may include non-volatile memory and/or volatile memory. The basic input/output system (BIOS) may be stored in a non-volatile memory.

The computing architecture may include various types of computer-readable storage media in the form of one or more low-speed storage units, including internal (or external) Hard Disk Drives (HDDs), magnetic Floppy Disk Drives (FDDs) for reading from or writing to removable magnetic disks, and optical disk drives (e.g., CD-ROM, DVD, or blu-ray) for reading from or writing to removable optical disks. The HDD, FDD, and optical disk drive can be connected to the system bus by a HDD interface, an FDD interface, and an optical disk 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 their 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 may be stored in the drives and storage units, including an operating system, and in particular a kernel of the operating system, one or more application programs (also referred to herein as application programs), such as the exemplary client application program 110 and the exemplary remote application program 210, other program modules, and program data. In one embodiment, for example, one or more application programs, other program modules, and program data can include various application programs and/or components for implementing the disclosed embodiments.

A user may enter commands and information into the computing device through one or more wired/wireless input devices, e.g., a keyboard, and a pointing device, such as a mouse. Other input devices may include a microphone, an Infrared (IR) remote control, a radio-frequency (RF) remote control, a game pad, a stylus pen, card reader, dongle, fingerprint reader, gloves, drawing tablet, joystick, keyboard, retina reader, touch screen (e.g., capacitor, resistor, etc.), trackball, touch pad, sensor, stylus, and so forth. 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 may be connected by other interfaces, such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR interface, etc.

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

The computing device may operate in a networked environment using logical connections via wired and/or wireless communications to one or more remote computers, such as a remote device. The remote device may 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. Logical connections may include wired/wireless connections to a Local Area Network (LAN) and/or a larger network (e.g., 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, e.g., the Internet.

When used in a LAN networking environment, the devices are connected to the LAN through a wired and/or wireless communication network interface or adapter. The adapter may facilitate wired and/or wireless communication to the LAN, which may also include a wireless access point disposed thereon for communicating with the wireless functionality of the adapter.

When used in a WAN networking environment, the device may 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 may be an internal or external wired and/or wireless device, is connected to the system bus via the input device interface. In a networked environment, program modules or portions thereof may be stored in the 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 may be used.

The client/server device may be operable to communicate with wired 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.11 over-the-air modulation techniques). This includes at least Wi-Fi (or Wireless Fidelity), wiMax, and Bluetooth ^TM Wireless technologies, etc. Thus, the communication may be a predefined structure as with a conventional network or may be a temporary communication between at least two devices. Wi-Fi networks use radio technologies called IEEE 802.11x (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 wired networks (which use IEEE 802.3-related media and functions).

Remote services such as the remote computing shown in fig. 1 are inherently insecure and are often subject to security breaches that may compromise a user's services and/or assets because the remote device is owned and maintained by a party that is not typically trusted (the service provider). Trusted services are a relatively new concept and therefore the number of solutions is limited.

The HTTPS protocol may establish a secure channel with an authenticated server. Server certification may be based on a server-provided x.509 certificate certified and signed by an a priori trusted certificate authority, in particular a root certificate authority. Even if the server can authenticate in this way and can establish a secure channel that provides confidentiality and communication integrity, the process can still be corrupted by malware on the service provider side. Software components that are more privileged than the remote application, particularly system software components that include a virtual machine hypervisor (also known as a Virtual Machine Monitor (VMM)) and an operating system kernel, memory access to the remote application may compromise the remote application, for example, when the corresponding software component includes malware. In this case, even the setting of a secure channel by, for example, a Transport Layer Security (TLS) client may be impaired, and confidentiality and communication integrity cannot be guaranteed.

To address the issue of malware at higher privilege levels, the concept of trusted execution environments was introduced. The application code of a remote application (such as a Web server or game client) running at the lowest privilege level is executed in an isolated execution environment (i.e., a secure container or secure enclave). The code and data of the enclave are thus protected even if the privileged system code also prohibits access to the contents of the enclave. But rather provides a limited set of trusted functions that may be used to access the contents of the enclave.

An example of a trusted execution environment is Intel's software protection extensions (SGX), as described in detail in the overview paper ' Intel SGX extended (Intel SGX Explanation) ' published by Victor Costan and Srinivas Deadas in the IACR Cryptographic electronic repository (IACR Cryptology spring Archive) in 2016. SGX is a set of extensions to the intel architecture intended to provide integrity and confidentiality guarantees for security-sensitive computations performed on computers where all privileged software (kernels, virtual machine hypervisors, etc.) may be malware. SGX-enabled processors protect the integrity and confidentiality of computations within an enclave by isolating the enclave's code and data from the external computing environment, including the operating system and virtual machine hypervisor and hardware devices connected to the system bus. In SGX, the enclave (secure container) includes only private data in computation and the code to operate on it. Applications are typically built using trusted and untrusted parts, with only the trusted part executing within the enclave. The enclaves may work in concert to support a distributed architecture. Enclave code and data run securely and enclave data written to disk will be encrypted and checked for integrity.

FIG. 2 schematically illustrates a modified configuration of the client-server architecture of FIG. 1 for trusted computing using a secure container as described above. In this configuration, the service provider 300 provides a trusted execution environment 320 in which one or more secure enclaves 330 are initialized to execute a remote application 310 that ultimately provides a remote service requested by the client 100. For simplicity, only the trusted portion of the remote application is shown.

A typical implementation may be as follows. First, the remote application is built using trusted and untrusted parts. The application may be provided by the service provider 300 itself (e.g., provided as SaaS) or received from the client 100 over a secure channel. When an application program is running, an enclave located in trusted memory of a processor is created. The trusted function is called and execution is translated to the enclave. The enclave may have a clear view of all process data while denying external access to the enclave data. The trusted function returns the enclave data and the application continues to execute normally.

Like their predecessor Trusted Platform Model (TPM) and trusted execution technology (TXT), SGX relies on software attestation to prove to the user that it is communicating with specific software running in a secure container hosted by trusted hardware. The evidence may be a cryptographic hash, such as SHA-1, SHA-2, SHA-256, MD4, or MD5, used to prove a hash of the secure container contents. The service provider can load any application in the secure container, but the user/client will refuse to load its data into a secure container whose hash of the content does not match the expected value. The processor and enclave-specific sealing key may be used to securely store and retrieve sensitive information that may need to be stored on disk.

SGX enclave 330 may generate an SGX report, such as remote application 310, that includes a cryptographic hash of the enclave data. The service provider may also generate a linkable reference on the SGX report, which may be signed by a referencing enclave (QE) (not shown), which in turn may generate a reference Q on the SGX report including the report and the cryptographic hash. A referring enclave (QE) may be provided as a separate enclave on the side of the service provider 300. SGX enclave 330 may request a third party attestation service (e.g., intel's Attestation Service (IAS)) attestation quote Q, which may reside on a remote server. The attestation response from the attestation service may be signed using a public key and may include a copy of the quote. Service provider 300 may then send the quote, an IAS attestation report on the quote, and data as an attestation response to client 100 requesting attestation in a corresponding attestation request. After receiving the attestation response, the client 100 can verify the validity of the quote by checking the signature on the IAS response using the public key. The client may further verify whether the cryptographic hash of the data corresponds to the hash in the reference. In this way, data can be trusted to come directly from the sending enclave.

The cryptographic hash may be generated for any data that remote application 310 may need to be securely processed by secure enclave 330 of service provider 300. For example, the data may include binary code of the application.

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

If the application is a remote application to be executed as a service (including SaaS and IaaS), then the cryptographic hash can be used as the identity of the application. In this case, the client 100 can verify the identity of the application from the attestation response.

By extending the client-server architecture of fig. 1 using the trusted execution environment and attestation of fig. 2, the client 100 can verify the identity of a remote application 310 executing in the trusted execution environment 320 of the service provider 300. However, the problem remains to determine whether an application with a verified identity can be trusted. For example, for applications provided by the service provider 300 as SaaS that itself includes malicious code or is insecure, e.g., by including insecure function calls outside of a secure enclave, a security vulnerability may arise. In this case, merely verifying the application ID cannot detect a security breach.

The present invention solves this problem by adding another entity to the secure remote computing system of fig. 2 that collects one or more pieces of evidence that the remote application can be trusted. FIG. 3 illustrates the concept of trust verification based on trust evidence provided by the present invention. Fig. 4 and 5 illustrate two alternative configurations provided by embodiments of the present invention for trust verification for remote services.

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

The service trust verifier 400 is intended to provide an intermediate entity that determines that a particular remote service or remote application 310 is trusted when a client wishes to communicate with the remote service, or the remote service wishes to communicate with the client. The determination of whether a remote application is trusted is made by, inter alia, the service trust verifier 400 when a client requests a remote service provided by the remote application. After service trust verifier 400 determines that a particular remote service is trusted, a connection may be established between client 100 and secure enclave 330. The connection may be a direct connection, i.e. bypassing the service trust verifier 400 in future communications related to a specific remote service, or may be established through 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. Since there is no direct communication between the client 100 and the remote application 310 in this case, an additional level of security is added compared to using standard network protocols (e.g., HTTPS over TLS). However, communication between client 100 and service trust verifier 400, and between service trust verifier 400 and service provider 300, may 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 according to the public key and the credentials as described above. The service trust verifier 400 may be designed as a trusted entity, for example by being located at the user's premises. If the service trust verifier is provided as a separate entity, for example as part of a remote computer 600 as shown in fig. 5, the service trust verifier itself must be booted up as trusted, for example as described below with respect to fig. 5.

The service trust verifier may be provided as a stand-alone device at the user's premises or may be integrated into the client, such as a web browser, as shown in fig. 4. Alternatively, the service trust verifier may be located outside the user's premises as the service itself, as described above, as shown in FIG. 5.

Hereinafter, a trust verification method of a remote service provided by the present invention is generally described with reference to fig. 3. The process begins with the client 100, or more specifically, the client application 110, issuing a request for a particular service provided by the remote application 310 through the service trust verifier 400. If necessary, for example, 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 a remote service can be issued.

Based on the request, the service trust verifier 400 identifies the service provider 300 that is capable of providing the requested service and sends an attestation request to the service provider 300 to attest to the identity of the corresponding remote application. For example, the attestation request may be included in a request for a remote service as is known in the art. As is known in the art, the attestation request and corresponding attestation response may be communicated over a secure channel between the service trust verifier 400 and the service provider 300. If the request for the remote service is a request for a SaaS service, the request may include a user application or a client application executed on the service provider 300 side in the form of application code or a binary file. The user application may be transmitted and built within the secure enclave 330 of the service provider 300 as a result of a service request and/or an attestation request. Thus, the service trust verifier 400 may communicate a separate service request 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 receiving the service request and the optional attestation request, the service provider 300 initializes the secure enclave 330 in the trusted execution environment 320 to execute the remote application 310. Initializing the secure enclave may include, among other things, building a remote application, such as compiling a remote application. The term "remote application" is used in the present invention to include stand-alone applications as well as distributed applications. Thus, the software attestation may be performed for stand-alone applications or distributed applications. Thus, distributed attestation may be performed for multiple cooperating secure enclaves on a single server device or distributed system.

As part of the software attestation, the trusted execution environment may sign a small piece of attestation data, thereby generating an attestation signature, as is known in the art. In addition to the attestation data, the signed message also includes a measurement that uniquely identifies the remote application. The attestation data may include, among other things, a public key that may be used to establish a secure channel between the service trust verifier 400 and the secure enclave 330. The measurement (referred to herein and hereinafter as the identity of the remote application) may comprise or consist of a cryptographic hash of the secure enclave content or contents. For example, a binary file of the remote application may be cryptographically hashed to produce a unique identity of the remote application. Other or alternative data may be cryptographically hashed to produce the identity. For example, a cryptographic hash of the enclave log may be used as the identity of the remote application as the enclave goes through each step of the build and initialization process. Further, the configuration of the remote application, particularly with respect to the distributed application, may be included in the cryptographic hash. Finally, additional data required for executing the remote application, in particular input data, may be included in the cryptographic hash.

Thus, the identity of the remote application constitutes a unique identity within the constraints of the cryptographic hash function used (e.g., SHA-1, SHA-2, SHA-256, MD4, or MD 5). Thus, the identity of the remote application may be used to convince the client or third party that particular software is running in a secure container that is hosted by trusted hardware. In addition, the attestation signature can be used to convince a client or third party that the attestation data was generated by a particular software (i.e., remote application). Since the application ID may include the configuration of the remote application with respect to the system architecture of the service provider 300, it also provides integrity with respect to the configuration of the remote application.

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

Upon receiving the attestation response, the service trust verifier 400 performs a trust verification based on the attestation response and the at least one trust proof. In accordance with the present invention, the service trust verifier uses information included in the attestation response, in particular the attestation identity and/or metadata of the remote application, in conjunction with one or more pieces of trust evidence generated by at least one party other than the service provider 300, to automatically determine whether the identity of the remote application is trusted.

At least one party other than 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. According to the present invention, trust is established based on the independence of at least one party from service provider 300. Further, the trust evidence described in detail below is selected and generated in a manner that provides additional, independent information about the trustworthiness of the remote application in proving the identity of the remote application. Depending on the sensitivity of the requesting service, and in particular the assets the user is involved in, more evidence of trust may be required to determine the trustworthiness of the remote application. For example, the service trust verifier may use requirement settings provided as a configuration file in a storage unit of the service trust verifier to determine which and how many trust evidence items are needed to determine that a particular remote service may be trusted. The sensitivity may be included as a parameter in the service request of the client 100.

As shown in FIG. 3, one or more trust proofs 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 evidence 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 particular remote service. The trusted third party may include, but is not limited to, a certification server, a certificate authority, a trusted software house server, a communication server, and the like. The service trust verifier may store a list of trusted third parties 700, similar to a list of certificate authorities, and information about the trust evidence and/or the types of remote services that may provide trust evidence from a particular third party. Communication between the service trust verifier 400 and the trusted third party 700 may be performed through a secure channel as is known in the art. Further, the trusted third party may itself implement a trusted execution environment for generating trust proofs and certifying software for generation.

For example, a list of trusted application identities may have been previously collected by the service trust verifier 400 from one or more trusted third parties 700. Upon receiving the attestation response, the service trust verifier 400 may compare the identity of the remote application received with the attestation response to the list of trusted application identities and may determine to trust the identity of the remote application, thereby trusting the remote application and the remote service itself when the received identity of the remote application is included in the list of trusted application identities. The following describes alternative and additional embodiments that may be used by the service trust verifier 400 to determine trust evidence that the remote application 310 may be trusted.

Upon determining that the identity of the remote application is trusted, the service trust verifier 400 connects to the remote application 310, and more specifically, to the secure enclave 330. As mentioned above, this connection may be established over a secure channel, in particular using the public key included in the attestation response. Thus, the connection established by the service trust verifier is bound to a particular secure enclave 330, for example, by a public key. If secure enclave 330 ceases to exist, for example because execution of remote application 310 terminates, the communication channel between service trust verifier 400 or client 100 and secure enclave 330 is also terminated. Thus, 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 invention extends only to specific remote applications, not to the entire service provider.

According to one particular embodiment, the service trust verifier 400 may handle all network traffic between the client and the remote application, i.e. all network traffic with respect to the requested remote service. This provides a further level of security since no direct communication between the client 100 and the service provider 300 takes place.

According to one embodiment, the remote application may be provided by a Service provider, for example, as part of a Software as a Service (SaaS). In this case, the service request may be a request to execute a remote application for specific user data. Here, the user may wish to obtain assurance that the user data is handled by the service provider securely and that the remote application can be trusted. As described above, a user may wish to verify that a remote application may be trusted before loading its data into a secure enclave. In this case, the trust verification by the service trust verifier may be based on at least one trust proof generated by a third party different from the service provider and the service trust verifier.

For example, the trust evidence may include an attestation made by a third party that attests to the identity of the remote application as being trusted or consisting of the attestation. For example, the proof may be provided in the form of a digital signature on the identity of the remote application. Upon receiving an attestation response from the service provider 300, the service trust verifier 400 may send a request for such attestation to a trusted third party 700 that includes the identity of the remote application. The third party 700 may verify that the identity of the remote application is included in the list of trusted application identities and, upon determining that the identity of the remote application is included in the list, return an attestation, i.e. that the identity of the remote application is trusted, to the service trust verifier 400.

In order for trusted third party 700 to include the identity of the service provider's remote applications, service provider 300 may need to prove to third party 700 that certain security criteria are maintained, e.g., that the remote applications are free of malware and backdoors. Such attestation may involve sending corresponding code and data of the remote application to third party 700, and third party 700 may build the remote application in a secure enclave having the same configuration as used by the service provider and/or perform an analysis, particularly a static program analysis, of the remote application to determine whether the remote application includes a security breach, such as a memory access to unprotected memory.

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

Upon receiving an 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 authentic. The verification of the digital signature may be performed using a public key having a certificate of a trusted third party. If the digital signature confirms the identity of the remote application, the service trust verifier 400 may determine that the remote application is trusted. However, the service trust verifier may require additional trust evidence before determining that the remote application is trusted, depending on the sensitivity of the requested service and the requirement set as described above. Likewise, if at least one qualifying trust proof is collected and verified, then the particular trust proof digitally signed for the application ID may not be needed to determine that the remote application is trusted.

The at least one trust evidence may include analytical proofs generated by a third party for the remote application, in particular a static analysis of the remote application with respect to malware and/or backdoors. The proof of analysis may be performed by a third party upon request by the service provider 300 and/or a software provider providing remote applications to the service provider 300. The analysis proof may in particular be performed each time an updated version of the remote application becomes available and/or installed on the service provider side. As described above, the analysis proof, in particular the static program analysis, may be performed by the third party 700 in the same execution environment as provided by the service provider 300, in particular with respect to a secure enclave.

The analysis proof may be a message specifying that the remote application with a particular application ID does not contain malware and/or backdoors. The message may specifically include a digital signature of the identity of the remote application. The analytical proof may additionally or alternatively include a set of parameters that reflect the results of a potential security breach of a particular test performed by a third party on the remote application. For example, parameters may quantify security risks related to interrupt handling, distributed computing and enclave collaboration, address translation and page swapping, cache coherency, thread processing, enclave Page Cache (EPC) page eviction, encryption, robustness or function calls, trusted function calls, and so forth. A third party may process these parameters to determine a single value or a set of values that reflect the robustness of the remote application against attacks. Trust verification by the service trust verifier 400 may then comprise comparing the single value or set of values with at least one requirement setting, which may be predefined or received from the client 100 together with the service request. Receiving at least one requirement setting and a service request allows a user to increase or decrease security requirements related to the sensitivity of assets involved in the remote service.

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

According to another embodiment, the at least one proof of trust may comprise a degree of trust related to the identity of the remote application and/or to the service provider and/or to the provider of the remote application (i.e. the software provider). Information about 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. However, the level of trust is collected from the trusted third party 700, not from the service provider 300 itself. For example, the degree of trust may reflect the likelihood established by an independent entity (e.g., a trusted third party) of trust for a particular remote application and/or a particular service provider and/or a particular software provider.

Thus, the degrees of trust may be collected by the service trust verifier from a trusted database storing different degrees of trust for known service providers, software providers, and/or remote applications. Alternatively or additionally, the level of trust may be collected from a chain of trust including, for example, a software developer, one or more software distributors, a service provider, and a trusted third party, wherein each entity verifies the level of trust of the next entity in the chain until the root entity. Alternatively, the confidence level may be collected using a chain of blocks, where each block includes a cryptographic hash of the previous block containing the confidence level. The original foundational blocks of such blockchains may be generated by a trusted authority that vouches for service providers, software providers, and even specific applications. Alternatively, the software provider may sign the application ID and include the signature in the founder block. Using blockchains can quickly cope with a loss of confidence in the trustworthiness of a particular service provider or software provider in case the particular service provider or software provider is found to be compromised.

Depending on the degree of trust, the service trust verifier 400 may determine whether the identity of the remote application and/or the service provider as a whole and/or the respective software provider as a whole is trusted, by comparing the degree of trust with a threshold value which may be predefined at the service trust verifier side or received from the client 100, etc. Further, the client application 110 may include such thresholds in the service request based on the sensitivity of the service requested and the assets involved.

The at least one trust proof may include a trust proof generated from a configuration of the remote application. Such configuration may include a list of components (e.g., modules) of the remote application, along with their particular relationships and/or functionality, such as Web servers, application servers, etc., the topology of the remote service, e.g., the manner in which the various components are interconnected, the configuration of the various components, etc. The configuration may be included as metadata in the attestation response and used by the service trust verifier 400 to compute the identity of the remote application if the remote application is executed in the trusted execution environment of the service provider using the configuration.

Alternatively, when the remote application is a user application or a 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 an Infrastructure as a Service (IaaS), the configuration may be included in a Service request from the client 100 to the Service trust verifier 400. In one particular embodiment, the client 100 itself may calculate the identity of the user application/client application if the user application/client application executes as a remote application with a particular configuration in the trusted execution environment of the service provider. Alternatively, the service trust verifier 400 may calculate the application ID using the configuration received from the client 100.

In any case, any details of the trusted execution environment of the service provider 300, such as the topology of the distributed system involving several secure enclaves, may be included as part of the metadata in the attestation response to the service trust verifier 400. The service trust verifier may use these details to calculate the application ID or forward these details to the client 100 if the client calculates the application ID. Thus, the corresponding trust proof may be generated by the client itself or the service trust verifier. If the trust proof is generated by the client 100, the trust proof 410 is transmitted by the client 100 to the service trust verifier 400, e.g., after transmitting details of the trusted execution environment.

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

However, the present invention is not limited to the examples of trust proofs described above, but may include other trust proofs as long as they are generated by an entity other than the service provider, and combinations of the above. Various trust proofs may be evaluated using predefined weighting factors to determine whether a particular remote application should be trusted, even if some trust proofs are missing or negative.

As described above, the service trust verifier may be provided as a separate entity, such as an application executing on a remote computer 600 as shown in FIG. 5; as a stand-alone device, provided remotely or at the client's site, i.e. within the user's control range; or as an application, module or plug-in to a client application executing on the client side, as shown in fig. 4.

Fig. 4 shows a configuration for trust verification of a remote service, wherein a service trust verifier 540 is provided at the client 500 side, 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 executing on the client device. Since the service trust verifier 540 in this particular embodiment is entirely under the control of the client 500, the service trust verifier can be implicitly 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 in detail above, one or more trust proofs 420 may be collected by the service trust verifier 540 from one or more trusted third parties 700. The trusted third party 700 may interact with the service provider 300 and a potential software provider 800, which software provider 800 provides code, binaries, etc. of the remote application 310 to the service provider 300 to generate one or more of the trust evidence items described above.

Fig. 5 illustrates a configuration of trust verification for remote services provided by an alternative embodiment of the present invention. According to this embodiment, the service trust verifier 640 is provided as a remote entity with respect to the location of the client 100. Thus, the client 100 has no control over the service trust verifier 640. To verify that the service trust verifier itself may be trusted by the client 100, the service trust verifier 640 may execute in a secure enclave 630 in the trusted execution environment 620 on the remote computer 600. The above-described attestation, possibly including third party attestation services, may be used to prove to the client 100 the identity of the service trust verifier 640. The service trust verifier 640 or remote computer 600 may be part of a chain of trust as described above. In fact, the service trust verifier 640 may be viewed in many respects as a trust verification by the client 100 of the remote application 310 of the service provider 300. However, due to the limited functionality of the service trust verifier 640, such trust verification may be significantly simplified as compared to trust verification of the remote application 310. It will be appreciated that the invention also includes a combination of the embodiments of fig. 4 and 5.

According to the invention, the trust verification of the remote service, in particular the remote application, can verify whether the remote application should be trusted in addition to proving the identity of the remote application. Since trust verification is based on separately generated trust evidence, in particular from an independent trusted third party, the risk of damage to the remote service and the involved user assets can be significantly reduced. Thus, confidence in the integrity and confidentiality of the remote service and the entire cloud computing may be increased, thereby increasing acceptance of remote computing.

Claims

1. An apparatus (400, 500, 600) for trust verification for a remote service, comprising processing circuitry to:

sending an attestation request to attest to an identity of a remote application (310) executing at least partially in a trusted execution environment (320) of a service provider (300);

receiving an attestation response from the service provider (300) including the attestation request of the identity of the remote application (310);

determining whether the identity of the remote application (310) is trusted based on the attestation response and at least one trust evidence (410, 420), wherein the at least one trust evidence (410, 420) is generated by at least one party (100, 500, 700) different from the service provider (300);

the at least one trust evidence (420) comprises an analytical proof generated by a third party (700) for the remote application (310), wherein the analytical proof is performed each time an updated version of the remote application becomes available and/or installed on a service provider side, the analytical proof specifying that the remote application with a particular application ID is free of malware and/or backdoors; wherein determining whether the identity of the remote application (310) is trusted comprises comparing the assay proof with at least one requirement setting, the at least one requirement setting being predefined and/or received from a client application (110, 510).

2. The apparatus (400, 500, 600) of claim 1 wherein the processing circuit is further configured to connect to the remote application (310) after determining that the identity of the remote application (310) is trusted.

3. The apparatus (400, 500, 600) of claim 2, wherein the processing circuit is further configured to process all network traffic between a client (100, 500) and the remote application (310), in particular the network traffic is over a secure channel.

4. The apparatus (600) of claim 2 or 3, wherein the trust verification is performed in a secure enclave (630) of the apparatus (600), and wherein the processing circuit is further configured to provide the client (100) with the attestation.

5. The apparatus (400, 500, 600) of any of the above claims 1 to 3, wherein the remote application (310) is provided by the Service provider (300) as a Software as a Service (SaaS), and wherein the at least one proof of trust (420) is generated by a third party (700) different from the Service provider and the apparatus.

6. The apparatus (400, 500, 600) of claim 5, wherein said at least one proof of trust (420) comprises an attestation made by said third party (700), said attestation including a digital signature, said attestation being for attesting that said identity of said remote application (310) is authentic;

wherein determining whether the identity of the remote application (310) is authentic comprises verifying a digital signature;

and/or, the at least one trust evidence (420) comprises a list of trusted application identities;

wherein determining whether the identity of the remote application (310) is trusted comprises comparing the identity of the remote application (310) to the list of trusted application identities.

7. The apparatus (400, 500, 600) of claim 6, wherein the at least one proof of trust (420) comprises a degree of trust associated with at least one of the identity of the remote application (310), the service provider (300), and a software provider of the remote application,

wherein determining whether the identity of the remote application (310) is trusted comprises comparing the degree of trust to a threshold, the threshold being predefined and/or received from a client application (110, 510).

8. The apparatus (400, 500, 600) according to any of claims 1 through 3 wherein the at least one trust evidence (410) is generated based on a configuration of the remote application (310),

wherein determining whether the identity of the remote application (310) is trusted comprises calculating, in the trusted execution environment (320) of the service provider (300), an identity of the remote application (310) using the configuration.

9. The apparatus (400, 500, 600) of claim 8, wherein the remote application (310) is a user application executed by the Service provider (300) as an Infrastructure as a Service (IaaS), wherein the at least one proof of trust (410) is generated by the client (100, 500).

10. A method for trust verification of a remote service, the method comprising:

receiving an attestation response from the service provider (300) including the attestation request for the identity of the remote application (310);

determining whether the identity of the remote application (310) is trusted based on the attestation response and at least one trust evidence (410, 420);

upon determining that the identity of the remote application (310) is trusted, connecting to the remote application (310), wherein the at least one trust evidence (410, 420) is generated by at least one party (100, 500, 700) different from the service provider (300);

the remote application (310) is provided by the Service provider (300) as Software as a Service (SaaS);

wherein the at least one trust evidence (420) comprises at least one of:

an attestation made by a third party (700), the attestation including a digital signature, the attestation to attest that the identity of the remote application (310) is authentic;

a list of trusted application identities;

an analytical proof generated by the third party (700) for the remote application (310); wherein the analysis proof is performed each time an updated version of a remote application becomes available and/or installed on the service provider side, the analysis proof specifying that the remote application with a particular application ID is free of malware and/or backdoors;

a degree of trust associated with at least one of the identity of the remote application (310), the service provider, and a software provider of the remote application;

wherein determining whether the identity of the remote application (310) is trusted comprises one or more of:

verifying the digital signature;

comparing the identity of the remote application (310) to the list of trusted application identities;

comparing the proof of analysis to at least one requirement setting, the at least one requirement setting being predefined and/or received from a client application (110, 510);

comparing the degree of trust to a threshold, the threshold being predefined or received from the client application (110, 510).

11. The method of claim 10, further comprising:

all network traffic between a client (100, 500) and the remote application (310) is processed.

12. The method according to claim 10 or 11,

the remote application (310) is a user application executed by the Service provider (300) as an Infrastructure as a Service (IaaS);

wherein the at least one trust evidence (410) is generated by the client (100, 500) according to a configuration of the remote application (310);

13. A computer readable medium storing instructions that, when executed in a processor, cause the processor to perform the method of any one of claims 10 to 12.