CN113302893B - Method and device for trust verification - Google Patents

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 invention relates to a method and device for trust verification of remote services in a distributed computing environment.

Background technique

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 direct control over data and applications hosted by cloud providers, the trustworthiness of cloud services becomes a major issue hindering cloud application deployment.

To attract users to cloud services, cloud/service providers provide trusted services to assure users that data and applications provided to the service remain safe and protected, and that the service will only use such data and applications as intended by the user.

An example of a trusted service is an online survey service that assures survey participants that responses will be kept confidential and that aggregated results will only be shared with the survey's subscribers. Furthermore, survey subscribers are assured that the survey questions and corresponding results remain their property and will not be shared with third parties.

Another example is a trusted cloud service, which assures its customers that their applications will run in the cloud, not be modified and protected, even if the service is provided as infrastructure as a service (IaaS). Cloud providers also cannot be modified.

Trusted services can be developed using a trusted execution environment (TEE), such as Intel SGX. The TEE is a secure area 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 its assets.

Trusted execution environments such as Intel SGX ensure that applications running within them have the following properties: code immutability, which means that the logic of the protected application cannot be changed; data confidentiality, which ensures that the application cannot be accessed without authorization; and attestation , that is, the protected application is able to prove its identity to third parties that it is indeed a specific program running in the TEE. Therefore, using TEE, service providers can ensure that users' assets are protected and that the services provided can prove their identity to users.

The service identity is usually a large number, such as 256 bits, and can be the result of a cryptographic hash over the service executable (ie, the application's binary code) or the entire application deployment including the individual components of the service and topology.

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

Contents of the invention

The present invention provides a method and device for trust verification of remote services. The method and device enable users or clients to determine whether the remote application program of a service provider with a specific identity can be trusted. The present invention provides a transparent mechanism to connect users to remote services while ensuring that the services are trusted.

According to an aspect of the present invention, there is provided an apparatus for trust verification of a remote service, wherein the apparatus includes processing circuitry configured to: send a certificate at least in part in a service provider's trusted a request for attestation of the identity of a remote application executing in the environment; receiving an attestation response from said service provider including said requested attestation of said identity of said remote application; based on said attestation response and at least one evidence of trust, It is determined whether the identity of the remote application is trustworthy, wherein the at least one evidence of trust is generated by at least one party other than the service provider. The trusted environment is preferably a secure enclave.

The processing circuitry is further operable to connect to the remote application after determining that the identity of the remote application is authentic. The processing circuitry can also be used to handle all network traffic between the client and the remote application. Trust verification can be performed as a service in the secure enclave of the device, and processing circuitry can also be used to provide proof of service to clients. Network traffic between the client and the remote application preferably travels over a secure channel.

According to another aspect, the remote application may be provided by the service provider as Software as a Service (SaaS), wherein the at least one evidence of trust is provided by a provider other than the service provider and the Third-party generation of the device.

The at least one evidence of trust may include a certification by the third party that the identity of the remote application is trusted, and/or a list of trusted application identities, wherein the identity of the remote application is determined to be Whether the identity 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 evidence of trust may comprise a proof of analysis generated by the third party for the remote application, wherein determining whether the identity of the remote application is trusted comprises combining the proof of analysis with at least one requirement setting For comparison, the at least one requirement setting 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 respect to malware and/or backdoors.

Said at least one evidence of trust may comprise a degree of trust associated with said identity of said remote application and/or said service provider and/or a provider of said remote application, wherein determining said remote application Whether the identity is trusted includes 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 provided by the client to the service provider and executed by the service provider as Infrastructure as a Service (IaaS). An application, wherein the at least one trust evidence is generated by the client. The at least one evidence of trust 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 performing an operation in the trusted execution environment of the service provider The identity of the remote application is computed using the configuration in .

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 to a service provider an attestation that at least partly in the service provider's trusted environment requesting attestation of the identity of the executing remote application; receiving an attestation response from the service provider including the requested attestation of the identity of the remote application; based on the attestation response and at least one evidence of trust, determining the Whether the identity of the remote application is trusted, wherein the at least one evidence of trust is generated by at least one party different from the service provider. The trusted environment is preferably a secure enclave.

The method may also include connecting to the remote application after determining that the identity of the remote application is authentic. The method may also include handling all network traffic between the client and the remote application. The trust verification itself can be performed in the secure enclave as a service, proof of which can be provided to the client. Network traffic between the client and the remote application preferably travels over a secure channel.

According to another aspect, the remote application may be provided by the service provider as Software as a Service (SaaS), wherein the at least one evidence of trust is provided by a provider other than the service provider and the Generated by a third party of the device (ie, the service trust verification unit).

The at least one evidence of trust may include a certification by the third party that the identity of the remote application is trusted, and/or a list of trusted application identities, wherein the identity of the remote application is determined to be Whether the identity 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 evidence of trust may comprise a proof of analysis generated by the third party for the remote application, wherein determining whether the identity of the remote application is trusted comprises combining the proof of analysis with at least one requirement setting For comparison, the at least one requirement setting is predefined and/or received from a client application. The proof of analysis is preferably a static analysis of the remote application with respect to malware and/or backdoors.

Said at least one evidence of trust may comprise a degree of trust associated with said identity of said remote application and/or said service provider and/or a provider of said remote application, wherein determining said remote application Whether the identity is trusted includes 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 provided by the client to the service provider and executed by the service provider as Infrastructure as a Service (IaaS). An application, wherein the at least one trust evidence is generated by the client. The at least one evidence of trust may be generated based on a configuration of the remote application, wherein determining whether the identity of the remote application is trusted includes the client being in the trusted execution environment of the service provider The identity of the remote application is computed using the configuration in .

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

The device may include a dedicated service trust verification unit, configured to perform any one of the above 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 circuit. The service trust verifier can be implemented as a combination of software and hardware. The described processing may be performed by chips such as a general-purpose processor, CPU, GPU, or field programmable gate array (field programmable gate array, FPGA). However, the invention is not limited to implementing a service trust verification unit on programmable hardware. The unit may also be implemented on an application-specific integrated circuit (ASIC), or through a combination of the above hardware components.

Description of drawings

Exemplary embodiments are described in detail below with reference to the accompanying drawings, in which:

Figure 1 schematically illustrates a generic client-server configuration for remote services such as remote computing;

Figure 2 schematically illustrates a trusted computing configuration using secure containers known in the art;

Fig. 3 shows the concept of trust verification based on trust evidence provided by the present invention;

Fig. 4 shows the configuration for trust verification of remote services provided by the first embodiment of the present invention;

Fig. 5 shows the configuration for trust verification of remote services provided by the second embodiment of the present invention.

Detailed ways

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

Figure 1 schematically shows a generic client-server architecture for remote services. The configuration includes one or more clients 100 in communication with one or more servers 200 . A client may be implemented by a user device or a client device, as described below. The server can be implemented by server equipment provided by the service provider and/or cloud provider. However, the invention is not limited to these particular implementations, but can be applied to any configuration where a local client (device) requests from a remote server (device) a service provided by the server to the client. 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 server may include a Web server, an application server, and a database server as front ends. For simplicity, a remote entity providing a service, whether a single server or server device, a distributed or microservices-based system, etc., is hereinafter referred to as a service provider. Furthermore, a client is not limited to a single client or client device, but can include distributed systems. A client can also act as a server itself in a distributed environment, for example as an intermediary server. The term "client" is used herein to include any of the aforementioned architectures, and simply means that an entity 100 (eg, a client device) receives services from a remote entity 200 (eg, a server device). Regarding aspects other than providing and receiving remote services, the client 100 and the server 200 may even switch roles.

Client 100 and service provider 200 may be operatively connected to one or more corresponding client data stores and server data stores (not shown) that It can be used to store the corresponding local information of the client 100 and the server 200, such as application code, application data, input data, output data, authentication data and so on.

The client 100 and the service provider 200 can communicate information between each other using a communication framework as indicated by arrows. Said information may include authentication information such as keys and/or signatures used to establish a secure communication channel, one or more applications, e.g. as code or binaries, input data and/or configuration used to execute remote applications data, output data from remote applications, and so on.

In an IaaS architecture, remote applications can be provided by the client 100 and delivered 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 (eg, compiling) the application code received from the client, executing the received application as a remote application on the service provider side, and transmitting the execution result back to the client 100 . In a SaaS architecture, the remote application is provided by the service provider itself, and the remote service consists of possibly executing the remote application on input data received from the client 100 and delivering the result to the client.

The communication framework used for communication between the client 100 and the service provider 200 can implement any well-known communication technologies and protocols. The communication framework can be implemented as a packet-switched network (for example, a public network such as the Internet, a private network such as an intranet, etc.), a circuit-switched network (for example, a public switched telephone network), or a combination of a packet-switched network and a circuit-switched network (with suitable gateways and converters). A client-server architecture may include various common communication elements such as transmitters, receivers, transceivers, radios, network interfaces, baseband processors, antennas, amplifiers, filters, power supplies, etc. Embodiments, however, are not limited to these implementations.

The communication framework may implement various network interfaces arranged to receive, communicate and connect to a communication network. A network interface can be thought of as a specialized form of an input/output interface. The network interface may use connection protocols including, but not limited to, direct connect, 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, etc. Additionally, multiple network interfaces may be used to interface with various communication network types. For example, multiple network interfaces can be used to communicate over broadcast, multicast, and unicast networks. The distributed network controller architecture can similarly be used for pooling, load balancing, and otherwise increasing the communication bandwidth required by clients 100 and servers 200 if processing requirements demand higher speed and capacity. The communication network can be any type and combination of wired and/or wireless networks, including but not limited to direct interconnects, secure custom connections, private networks (e.g., corporate intranets), public networks (e.g., the Internet), personal area networks (personal area network, PAN), local area network (local area network, LAN), metropolitan area network (metropolitan area network, MAN), operating missions as nodes on the Internet (OMNI), wide area network (wide area network, WAN), wireless networks, cellular networks, and other communication networks.

As described above, the client 100 and the server 200 may each include a device, which may be any electronic device capable of receiving, processing, and transmitting information through a communication component or the like. Examples of electronic devices may include, but are not limited to, client devices, personal digital assistants (PDAs), mobile computing devices, smartphones, cellular phones, e-book readers, messaging devices, computers, personal computer , PC), desktop computer, laptop computer, notebook computer, netbook computer, handheld computer, tablet computer, server, server array or server farm, web server, web server, internet server, workstation, network device, web appliance, distribution Computing systems, multiprocessor systems, processor-based systems, consumer electronics devices, programmable consumer electronics devices, gaming devices, televisions, set-top boxes, wireless access points, base stations, subscriber stations, mobile subscriber centers, wireless network controllers , routers, hubs, gateways, bridges, switches, machines, or combinations thereof. In this context, the embodiments are not limited.

The device may be one or more applications (such as the exemplary client application 110 and remote application 210), communication components, operating systems, particularly kernels of operating systems, and other software using one or more processing components Elements perform processing operations or logic. 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, etc.), integrated circuits, application-specific Integrated circuit (application specific integrated circuit, ASIC), programmable logic device (programmable logic device, PLD), digital signal processor (digital signal processor, DSP), field programmable gate array (field programmable gate array, FPGA), storage unit , logic gates, registers, semiconductor devices, chips, microchips, chipsets, etc. Examples of software elements may include software components, programs, application programs, computer programs, application programs, system programs, software development programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions , method, procedure, software interface, application program interface (application program interface, API), instruction set, computational code, computer code, code segment, computer code segment, word, value, symbol, or any combination thereof. Depending on the needs of a given implementation, determining whether an embodiment of the service trust verification unit described below is implemented using hardware elements and/or software elements can vary according to any number of factors, such as desired calculation rates, power levels, endurance thermality, processing cycle budget, input data rate, output data rate, memory resources, data bus speed, and other design or performance constraints.

A device may use one or more communication components to perform communication operations or logic for communicating with other devices. The communication components can implement any well-known communication technologies and protocols, such as those suitable for use in packet-switched networks (e.g., public networks such as the Internet, private networks such as intranets, etc.), circuit-switched networks (e.g., public switched telephone networks), or packet-switched networks. A combination (with appropriate gateways and switches) of switched and circuit-switched networks. The communication assembly may include various types of standard communication elements, such as one or more communication interfaces, network interfaces, network interface cards (NICs), radios, wireless transmitter/receivers (transceivers), wired and/or Wireless communication media, physical connectors, and more. By way of example, and not limitation, communication media includes wired communication media and wireless communication 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, coaxial cable, fiber optics, propagated signal, and so on. Examples of wireless communication media may include acoustic, radio-frequency (radio-frequency (RF) spectrum, infrared, and other wireless media.

A device may communicate with other devices over a communication medium through one or more communication components using the communication signals shown in FIG. 1 . According to the needs of a given implementation, other devices may be inside the device as shown in FIG. 4 , or outside the device as shown in FIG. 5 .

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

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

As used in this application, the terms "apparatus", "component", "client", "server", "service provider", "software provider" and "service trust verifier" are intended to refer to computer-related entities that are 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 may be, but is not limited to, a process running on a processor, a processor, a hard drive, multiple storage drives (of optical and/or magnetic storage media), an object, an executable, a thread of execution, a program, and/or or computer. For example, an application running on a server and a server can both be components. 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. In addition, components can be communicatively coupled to each other through various types of communication media to coordinate operations. Coordination may involve one-way or two-way exchange of information as required. For example, components may communicate information in the form of signals communicated over the communications media. This information can be implemented as signals assigned to various signal lines. In this type of allocation, each message is a signal. However, other embodiments may also employ data messages. Such data messages can be sent over various connections. Exemplary connections include parallel, serial, and bus interfaces.

A computing architecture may include various common computing elements, such as one or more processors, multi-core processors, coprocessors, memory units, chipsets, controllers, peripherals, interfaces, oscillators, timing devices, graphics cards, sound cards, Multimedia input/output (I/O) components, power supplies, etc. However, the embodiments are not limited to implementation by this computing architecture.

和

处理器；

应用程序、嵌入式和安全处理器；

和

和

处理器；IBM和

Cell处理器；

Core(2)

和

处理器；以及类似处理器。双微处理器、多核处理器和其它多处理器架构也可以用作处理单元。Computing architecture may include processing units, system memory, and system buses. The processing unit can be any of a variety of commercially available processors, including but not limited to

and

processor;

application, embedded and security processors;

and

and

Processor; IBM and

Cell processor;

Core(2)

and

processors; and similar processors. Dual microprocessors, multi-core processors, and other multi-processor architectures can also be used as processing units.

The system bus provides interfaces to system components, including but not limited to system memory to processing units. The system bus can be any of several types of bus structures, which can be further interconnected 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 can be connected to the system bus through a socket architecture. Exemplary socket architectures may include, but are not limited to, accelerated graphics port (AGP), card bus, (extended) industry standard architecture ((E)ISA), micro channel architecture (micro channel architecture) , MCA), NuBus, peripheral component interconnect (extended), PCI (X)), PCI Express, personal computer memory card international association (personal computer memory card international association, PCMCIA), etc.

A computing architecture may include or implement a computer-readable storage medium to store logic. Examples of computer-readable storage media may include any tangible media capable of storing electronic data, including volatile or nonvolatile memory, removable or non-removable, erasable or non-erasable, writable or Rewrite memory, etc. 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, visualization code, and the like. Embodiments can also be implemented at least in part as instructions embodied in or on a non-transitory computer-readable medium, which can 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 storage units, such as read-only memory (ROM), random-access memory (RAM), Dynamic RAM (dynamic RAM, DRAM), double-data-rate DRAM (double-data-rate DRAM, DDRAM), synchronous DRAM (synchronous DRAM, SDRAM), static RAM (static RAM, SRAM), programmable ROM (programmable ROM, PROM ), erasable programmable ROM (erasable programmable ROM, EPROM), electrically erasable programmable ROM (electrically erasable programmable ROM, EEPROM), flash memory, polymer memory, such as ferroelectric polymer memory, Austenitic memory, phase variable or ferroelectric memory, silicon-oxide-nitride-oxide-silicon (silicon-oxide-nitride-oxide-silicon, SONOS) memory, magnetic card or optical card, device array, such as independent redundant disk array (redundant array) of independent disk (RAID) drives, solid-state storage devices (eg, USB memory, solid state drives (SSD)), and any other type of storage medium suitable for storing information. System memory may include non-volatile memory and/or volatile memory. A basic input/output system (BIOS) may be stored in non-volatile memory.

Computing architectures 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), A magnetic floppy disk drive (FDD) for removable disks, and an optical drive for reading or writing removable optical disks (such as CD-ROM, DVD, or Blu-ray). The HDD, FDD, and optical drive can be connected to the system bus through the HDD interface, the FDD interface, and the optical drive interface, respectively. The HDD interface implemented by the external drive may include at least one or two of universal serial bus (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 the like. For example, a plurality of program modules may be stored in the drives and storage unit, including an operating system, particularly the kernel of the operating system, one or more application programs (also referred to herein as application programs), such as exemplary client application 110 and Exemplary remote applications 210, other program modules and program data. In one embodiment, for example, one or more application programs, other program modules, and program data may include various applications and/or components for implementing the disclosed embodiments.

A user can input commands and information into the computing device through one or more wired/wireless input devices, such as a keyboard and a pointing device such as a mouse. Other input devices may include microphones, infrared (infra-red (IR)) remotes, radio-frequency (radio-frequency (RF)) remotes, game pads, stylus, card readers, dongles, fingerprint readers, gloves, drawing Pads, joysticks, keyboards, retina readers, touch screens (e.g. capacitive, resistive, etc.), trackballs, trackpads, sensors, stylus, etc. These and other input devices are typically connected to the processing unit through input device interfaces coupled to the system bus, but may be connected through other interfaces such as parallel ports, IEEE 1394 serial ports, game ports, USB ports, IR interfaces, and the like.

A display can also be connected to the system bus through an interface such as a video adapter. The display can be internal or external to the computing device. In addition to displays, computing devices often include other peripheral output devices such as speakers, printers, and the like.

A computing device may operate in a networked environment using logical connections through wired and/or wireless communications to one or more remote computers (eg, remote devices). A remote device may be a workstation, server computer, router, personal computer, laptop computer, microprocessor-based entertainment device, peer device, or other public network node, and generally includes many or all of the elements described with respect to the computing architecture. Logical connections may include wired/wireless connections to a local area network (LAN) and/or a larger network (eg, a wide area network (WAN)). These types of LAN and WAN networking environments are commonplace in offices and corporations and facilitate enterprise-wide computer networks, such as intranets, all of which can connect to a global communications network, such as the Internet.

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

When used in a WAN network environment, the device may include a modem, or a communications server connected to the WAN, or have other means of establishing communications over the WAN, such as through the Internet. A modem can be an internal or external wired and/or wireless device connected to the system bus through an input device interface. In a network environment, program modules, or portions thereof, may be stored in remote memory/storage devices. It will be appreciated that a network connection is exemplary and other means of establishing a communications link between the devices may be used.

Client/server devices may be used to communicate with wired and wireless devices or entities, such as wireless devices operatively arranged in wireless communications (eg, IEEE 802.11 over-the-air modulation techniques), using the IEEE 802 series of standards. This includes at least Wi-Fi (or Wireless Fidelity), WiMax, and Bluetooth ^™ wireless technologies, among others. Therefore, the communication can be a predefined structure like a traditional network, or it can be an ad-hoc communication between at least two devices. Wi-Fi networks use radio technologies known as IEEE 802.11x (a, b, g, n, ac, etc.) to provide secure, reliable, and fast wireless connections. Wi-Fi networks can be used to connect devices to each other, to the Internet and to wired networks (using IEEE 802.3 related media and functions).

Remote services such as remote computing shown in Figure 1 are inherently insecure and are often subject to security breaches that can compromise the user's services and/or assets because the remote device is managed by a usually untrusted party (service provider) owned and maintained. Trusted services are a relatively new concept, so the number of solutions is limited.

The HTTPS protocol can establish a secure channel with an authenticated server. Server authentication may be based on an X.509 certificate provided by the server, certified and signed by a priori trusted certificate authority, in particular a root certificate authority. Even if the server can be authenticated in this way and a secure channel can be established that provides confidentiality and communication integrity, the process can still be compromised by malware on the service provider's side. Software components with a higher authority level than remote applications, especially system software components including virtual machine hypervisor (also known as virtual machine monitor (VMM)) and operating system kernel, memory access to remote applications may Can compromise remote applications, for example, when the corresponding software components include malware. In this case, even the setting of a secure channel, eg, by a transport layer security (TLS) client, may be compromised, making it impossible to guarantee confidentiality and communication integrity.

To address the issue of malware with higher privilege levels, the concept of a Trusted Execution Environment was introduced. The application code of a remote application (such as a web server or game client) running at the least privilege level is executed in an isolated execution environment (i.e., a secure container or secure enclave). Even privileged system code is forbidden from accessing the contents of the enclave, and the code and data of the enclave are so protected. Instead, a limited set of trusted functions are provided that can be used to access the contents of the enclave.

An example of a trusted execution environment is Intel's software guard extensions (SGX), as described in the review paper 'Intel SGX Explained (Intel SGX Interpretation)' described in detail. SGX is a set of extensions to Intel Architecture designed to provide integrity and confidentiality guarantees for security-sensitive computations performed on computers where all privileged software (kernel, hypervisor, etc.) could be malware. SGX-enabled processors protect the integrity and confidentiality of computing within an enclave by isolating the code and data of the enclave from the external computing environment, including the operating system and hypervisor, as well as hardware devices connected to the system bus. In SGX, an enclave (secure container) includes only the private data in the computation and the code to operate on it. Applications are often built using trusted and untrusted parts, where only the trusted part executes within the enclave. Enclaves can work together to support a distributed architecture. Enclave code and data run securely, and enclave data written to disk is encrypted and integrity checked.

Figure 2 schematically shows a modified configuration of the client-server architecture of Figure 1 for trusted computing using secure containers 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 remote applications that ultimately provide the remote services requested by the client 100 Procedure 310. For simplicity, only the trusted portion of the remote application is shown in the figure.

A typical execution could look like this. First, build the remote application with trusted and untrusted parts. The application program may be provided by the service provider 300 itself (for example, provided as SaaS), or received from the client 100 through a secure channel. Creates an enclave that resides in the processor's trusted memory when the application runs. Calls a trusted function and transfers execution to the enclave. The enclave can clearly observe all processing data, while denying external access to the enclave data. The trusted function returns the enclave data, and the application continues to execute normally.

Like its predecessors Trusted Platform Model (TPM) and Trusted Execution Technology (TXT), SGX relies on software attestation to prove to users that it is interacting with specific software running in secure containers hosted on trusted hardware. to communicate. Evidence can be a cryptographic hash, such as SHA-1, SHA-2, SHA-256, MD4, or MD5, used to attest to the hash of the contents of the secure container. A service provider can load any application in a secure container, but users/clients will refuse to load their data into a secure container whose content's hash does not match the expected value. Processor and enclave-specific sealed keys can 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 , including a cryptographic hash of enclave data. The service provider can also generate a linkable quote on the SGX report, which can be signed by a quoting enclave (QE) (not shown), which in turn can be included in the report and cryptographic hash. SGX report generates reference Q. A quoting enclave (QE) may be provided as a separate enclave on the service provider 300 side. SGX enclave 330 may request a third-party attestation service (eg, Intel's attestation service (IAS)) to attest reference Q, which may reside on a remote server. Attestation responses from attestation services MAY be signed with a public key and may include a copy of the reference. The service provider 300 may then send the reference, the IAS certification report and data on the reference as a certification response to the client 100 requesting certification in the corresponding certification request. After receiving the attestation response, the client 100 can verify the validity of the reference by checking the signature on the IAS response using the public key. Clients can further verify that 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.

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

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

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

By extending the client-server architecture of FIG. 1 with the trusted execution environment and attestation of FIG. 2 , the client 100 can verify the identity of the 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, a security breach may arise for an application provided by the service provider 300 as SaaS that itself includes malicious code or is insecure, eg, by including unsafe function calls outside the secure enclave. In this case, verifying the App ID alone cannot detect the 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 evidences that the remote application can be trusted. Fig. 3 shows the concept of trust verification based on trust evidence provided by the present invention. FIG. 4 and FIG. 5 show two optional configurations for trust verification of remote services provided by the embodiments of the present invention.

According to the present invention, a service trust verification unit 400 called a service trust verifier is provided to manage the communication between the client 100 and the remote application 310 . The service trust verifier can be implemented as a device or device, especially as a part of the remote computer 600 shown in FIG. or a combination thereof.

The service trust verifier 400 is to provide an intermediary entity that determines that a particular remote service or remote application 310 is trusted when a client wishes to communicate with a remote service, or when a remote service wishes to communicate with a client. In particular, it is determined by the service trust verifier 400 whether the remote application is trustworthy when a client requests a remote service provided by the remote application. After the service trust verifier 400 determines that a particular remote service is trustworthy, a connection can be established between the client 100 and the secure enclave 330 . This connection may be a direct connection, ie bypassing the service trust verifier 400 in future communications related to the particular remote service, or may be established through the service trust verifier 400 .

In the latter case, all network traffic between client 100 and remote application 310 , or more specifically, secure enclave 330 , is handled by 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 such as HTTPS over TLS. However, communications between the client 100 and the service trust verifier 400 and between the service trust verifier 400 and the service provider 300 may use standard network protocols, such as HTTPS over TLS. A secure channel can be established between the service trust verifier 400 and the secure enclave 330 based on the public key and certificate as described above. The service trust verifier 400 may be designed as a trusted entity, for example by locating it at the user's premises. If the service trust verifier is provided as a separate entity, eg as part of the remote computer 600 as shown in Figure 5, the service trust verifier itself must be bootstrapped as trusted, eg as described below with respect to Figure 5 .

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

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

According to the request, the service trust verifier 400 identifies a service provider 300 capable of providing the requested service, and sends an attestation request to the service provider 300 certifying the identity of the corresponding remote application. For example, a request for certification may be included in a request for remote service as is known in the art. Attestation requests and corresponding attestation responses may be communicated over a secure channel between the service trust verifier 400 and the service provider 300 as is known in the art. If the request for a remote service is a request for a SaaS service, the request may include a user application or a client application executed at the service provider 300 side in the form of application code or binary files. User applications may be transferred and built within the secure enclave 330 of the service provider 300 as a result of service requests and/or certification requests. Accordingly, the service trust verifier 400 may transmit a separate service request to the service provider 300 before transmitting the attestation request to the service provider. Alternatively, the request for service and the request for attestation may be transmitted together, in particular as a single request.

After receiving the service request and optional attestation request, the service provider 300 initializes a secure enclave 330 in the trusted execution environment 320 to execute the remote application 310 . Initializing the secure enclave may specifically include building the remote application, eg compiling the remote application. The term "remote application" is used in this invention to include stand-alone applications as well as distributed applications. Therefore, software proofs can be performed for stand-alone applications or distributed applications. Thus, distributed attestation can be performed against a single server device or across multiple cooperating secure enclaves on a distributed system.

As part of software attestation, a trusted execution environment may sign a small piece of attestation data, resulting in attestation signatures, as is known in the art. In addition to attestation data, signed messages include measurements that uniquely identify the remote application. The attestation data may include, inter alia, a public key usable to establish a secure channel between the service trust verifier 400 and the secure enclave 330 . The measurement (here and hereinafter referred to as the identity of the remote application) may comprise or consist of one or more cryptographic hashes of the content of the secure enclave. For example, a binary file of a remote application can be cryptographically hashed to produce a unique identity for the remote application. Additional or alternative data may be cryptographically hashed to produce an identity. For example, a cryptographic hash of the enclave's logs can be used as the identity of the remote application as the enclave goes through each step of the build and initialization process. Furthermore, the configuration of remote applications, especially with respect to distributed applications, can be included in the cryptographic hash. Finally, additional data required to execute the remote application, especially input data, can 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 (such as SHA-1, SHA-2, SHA-256, MD4 or MD5). Thus, the identity of a remote application can be used to convince a client or third party that a particular piece of software is running in a secure container hosted on trusted hardware. Additionally, attestation signatures can be used to convince a client or third party that attestation data was generated by specific software (ie, a 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 invention sends to the service trust verifier 400 an attestation response comprising the requested attestation of the identity of the remote application. As mentioned above, the attestation response may include additional information, such as attestation signature, topology or configuration of the distributed execution environment used to execute the remote application, etc., as metadata.

After receiving 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 invention, the service trust verifier uses the information included in the attestation response, in particular the attestation identity and/or metadata of the remote application, in combination with one or more trust attestations generated by at least one party other than 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. According to the invention, trust is established based on the independence of at least one party from the service provider 300 . Furthermore, the trust evidence described in detail below is selected and generated by providing additional, independent information about the trustworthiness of the remote application in the remote application's proven identity. Depending on the sensitivity of the requested service, particularly the assets involved by the user, more evidence of trust may be required to determine the trustworthiness of the remote application. For example, the service trust verifier may use the requirement settings provided as a configuration file in the service trust verifier's storage location to determine which and how many items of trust evidence are required to determine that a particular remote service can be trusted. Sensitivity may be included as a parameter in the client 100's service request.

As shown in FIG. 3 , one or more trust evidences 410 and 420 may be collected by the service trust verifier 400 from the trusted third party 700 and/or the client 100 . The trust evidence can be collected independently of the service request and stored in a corresponding storage unit by the service trust verifier, and/or can be collected when trust verification is performed for a particular remote service. Trusted third parties may include, but are not limited to, authentication servers, certificate authorities, trusted software house servers, communication servers, and the like. A service trust verifier may store a list of trusted third parties 700, similar to a list of certificate authorities, and information about trust proofs and/or types of remote services that can provide trust proofs from a particular third party. Communications between the service trust verifier 400 and the trusted third party 700 may be performed through secure channels known in the art. Furthermore, the trusted third party itself can implement a trusted execution environment for generating evidence of trust and attesting to the software used to generate it.

For example, a list of trusted application identities may be collected in advance by the service trust verifier 400 from one or more trusted third parties 700 . Upon receipt of the attestation response, the service trust verifier 400 may compare the identity of the remote application received with the attestation response to a list of trusted application identities, and may determine the identity of the trusted remote application, and then upon receiving The remote application's identity is included in the list of trusted application identities when trusting the remote application and the remote service itself. Alternative and additional embodiments of trust evidence that may be used by service trust verifier 400 to determine that remote application 310 may be trusted are described below.

After determining that the remote application's identity is trustworthy, service trust verifier 400 connects to remote application 310 , and more specifically, to secure enclave 330 . As mentioned above, this connection can be established over a secure channel, in particular using the public key included in the attestation response. Thus, a connection established by a service trust verifier is bound to a specific secure enclave 330, for example by a public key. If the secure enclave 330 ceases to exist, for example because execution of the remote application 310 terminates, the communication channel between the service trust verifier 400 or client 100 and the secure enclave 330 is also terminated. Therefore, each service request needs to establish a separate communication channel, and therefore, individually verify that 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 only extends to a specific remote application, not to the entire service provider.

According to a particular embodiment, the service trust verifier 400 may handle all network traffic between the client and the remote application, ie all network traffic regarding 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 Software as a Service (SaaS). In this case, the service request may be a request to execute a remote application on specific user data. Here, users may want assurance that user data is handled confidentially by the service provider and that remote applications can be trusted. As mentioned above, users may wish to verify that a remote application can be trusted before loading their data into a secure enclave. In this case, the trust verification by the service trust verifier may be based on at least one trust evidence generated by a third party other than the service provider and the service trust verifier.

For example, evidence of trust may include or consist of attestation by a third party that the identity of the remote application is trusted. 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 including 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 a proof to the service trust verifier 400, the proof being that the remote application The identity of the program is trusted.

In order for the trusted third party 700 to include the identity of the service provider's remote application, the service provider 300 may need to demonstrate to the third party 700 that certain security standards are maintained, such as that the remote application is free of malware and backdoors. Such attestation may involve sending the corresponding code and data of the remote application to the third party 700, who may build the remote application in a secure enclave with the same configuration as that used by the service provider and/or provide access to the remote application. Application analysis, specifically static program analysis, to determine whether remote applications include security vulnerabilities, such as memory accesses 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 proof, the service trust verifier 400 may refuse to establish a connection to the secure enclave 330 and communicate this rejection to the client 100 and the service provider 300 .

After receiving the attestation from the third party 700, the service trust verifier 400 may verify the digital signature to determine whether the remote application's identity is authentic. Verification of digital signatures can be performed using a public key with a certificate from a trusted third party. If the digital signature confirms the identity of the remote application, service trust verifier 400 may determine that the remote application is authentic. However, depending on the sensitivity of the requested service and the requirements set above, the service trust verifier may require additional trust evidence before determining that the remote application is trustworthy. Likewise, if at least one qualifying trust proof is collected and verified, a specific trust proof for the digital signature of the application ID may not be required to determine that the remote application is trustworthy.

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

The proof of analysis may be a message specifying that a remote application with a specific application ID is free of malware and/or backdoors. The message may include, inter alia, a digital signature of the identity of the remote application. The Proof of Analysis may additionally or alternatively include a set of parameters that reflect the results of specific testing performed by a third party on the remote application for potential security vulnerabilities. For example, parameters can be quantified related to interrupt handling, distributed computing and enclave cooperation, address translation and paging, cache coherency, threading, enclave page cache (EPC) page eviction, encryption, robustness, or Security risks related to function calls, trusted function calls, etc. Third parties can process these parameters to determine a single value or collection of values that reflect the remote application's robustness against attacks. Trust verification by the service trust verifier 400 may then include comparing a single value or set of values with at least one requirement setting, which may be predefined or received from the client 100 with the service request. Receiving at least one requirement set along with the service request enables the user to increase or decrease security requirements related to the sensitivity of the asset 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 can 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 evidence 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, ie 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 degree 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 (eg, a trusted third party) to trust a particular remote application and/or a particular service provider and/or a particular software provider.

Thus, the degree of trust may be gathered by the service trust verifier from a trust database storing different degrees of trust for known service providers, software providers, and/or remote applications. Alternatively or additionally, the degree of trust may be gleaned from a chain of trust comprising, for example, a software developer, one or more software distributors, a service provider, and a trusted third party, where each entity verifies the next in the chain Entity's trust level up to the root entity. Alternatively, trust levels can be collected using a blockchain, where each block includes a cryptographic hash of the previous block containing the trust level. The original genesis block of such a blockchain could be generated by a trusted authority vouching for service providers, software providers, or even specific applications. Alternatively, the software provider could sign the application ID and include the signature in the genesis block. The use of blockchain enables rapid response to a loss of confidence in the credibility of a particular service provider or software provider in the event that it 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 is trustworthy by comparing the degree of trust with thresholds which may be predefined at the side of the service trust verifier or received from the client 100, etc., and/or Whether the service provider is generally trustworthy, and/or whether the corresponding software provider is generally trustworthy. Furthermore, client application 110 may include such thresholds in service requests depending on the sensitivity of the service requested and the assets involved.

The at least one trust proof may include a trust proof generated according to a configuration of the remote application. Such a configuration can include a list of components (e.g. modules) of the remote application, with their specific relationships and/or functions, such as web servers, application servers, etc., the topology of the remote service, e.g., the way the various components are connected to each other , the configuration of various components, and so on. This 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 executes in the service provider's trusted execution environment using said 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 provided by the service provider 300 as an infrastructure, i.e. Service (Infrastructure as a Service, IaaS) execution, the configuration may be included in the service request from the client 100 to the service trust verifier 400 . In a particular embodiment, the client 100 itself can compute the user application/client application if it executes in the service provider's trusted execution environment as a remote application with a specific configuration. The identity of the program. Alternatively, the service trust verifier 400 may use the configuration received from the client 100 to calculate the application ID.

In any case, any details of the trusted execution environment of the service provider 300, such as the topology of a distributed system involving several secure enclaves, can be included in the attestation response to the service trust verifier 400 as part of the metadata . The service trust verifier can use these details to compute the application ID, or forward these details to the client 100 if the client computes the application ID. Accordingly, the corresponding trust evidence can be generated by the client itself or by 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, for example after transmitting details of the trusted execution environment.

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

However, the present invention is not limited to the above-mentioned examples of trust proofs, but may include other trust proofs as long as they are generated by entities other than service providers, and combinations of the above-mentioned trust proofs. Various trust proofs can 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 mentioned above, the service trust verifier can be provided as a separate entity, such as an application program executed on a remote computer 600 as shown in FIG. within the scope of control; or as an application, module or plug-in of a client application executed on the client side, as shown in FIG. 4 .

FIG. 4 shows a configuration for trust verification of remote services, where a service trust verifier 540 is provided on the client side 500 , in particular as a plug-in to a web browser shown as 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 can 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 evidences 420 may be collected by the service trust verifier 540 from one or more trusted third parties 700 . The trusted third party 700 can interact with the service provider 300 and the potential software provider 800, and the software provider 800 provides the service provider 300 with codes, binary files, etc. of the remote application program 310 to generate the above-mentioned trust evidence item one or more.

Fig. 5 shows a configuration for trust verification of 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 . Therefore, the client 100 has no 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 can execute in a secure enclave 630 in the trusted execution environment 620 on the remote computer 600 . The aforementioned attestation, possibly including a third-party attestation service, may be used to attest to the client 100 the identity of the service trust verifier 640 . 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 can be regarded as the trust verification performed by the client 100 on the remote application 310 of the service provider 300 in many respects. However, due to the limited functionality of the service trust verifier 640 , such trust verification can be significantly simplified compared to that of the remote application 310 . It can be understood that the present invention also includes a combination of the embodiments shown in FIG. 4 and FIG. 5 .

According to the present invention, the trust verification of the remote service, especially the remote application program can not only prove the identity of the remote application program, but also verify whether the remote application program should be trusted. Since trust verification is based on individually generated trust evidence, especially from an independent trusted third party, the risk of compromise of remote services and involved user assets can be significantly reduced. As a result, confidence in the integrity and confidentiality of remote services and cloud computing as a whole can be increased, thereby increasing the acceptance of remote computing.

Claims (13)

1. A device (400, 500, 600) for trust verification of remote services, characterized in that it includes a processing circuit, and the processing circuit is used for: sending an attestation request attesting to the identity of the remote application (310) executing at least in part in the trusted execution environment (320) of the service provider (300); receiving an attestation response to the attestation request including the identity of the remote application (310) from the service provider (300); Based on the attestation response and at least one evidence of trust (410, 420), it is determined whether the identity of the remote application (310) is authentic, wherein the at least one evidence of trust (410, 420) is determined by a different generated by at least one (100, 500, 700) of the aforementioned service providers (300); The at least one evidence of trust (420) includes a certificate of analysis generated by a third party (700) for the remote application (310), wherein the certificate of analysis becomes available each time an updated version of the remote application becomes available and/or or when installed at the service provider side, said analysis certifying that a remote application designated with a particular application ID is free of malware and/or backdoors; wherein determining whether said identity of said remote application (310) is available The communication includes comparing the proof of analysis 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 authentic. Remote Application (310). 3. The device (400, 500, 600) according to claim 2, characterized in that the processing circuit is further configured to process all Network traffic, specifically, the network traffic is through a secure channel. 4. The device (600) according to claim 2 or 3, wherein the trust verification is performed in a secure enclave (630) of the device (600), and the processing circuit is further configured to provide The client (100) provides proof. 5. The apparatus (400, 500, 600) according to any one of the preceding claims 1 to 3, characterized in that the remote application (310) is provided by the service provider (300) as a software-as-a-service (Software as a Service, SaaS), and said at least one trust evidence (420) is generated by a third party (700) different from said service provider and said device. 6. The apparatus (400, 500, 600) according to claim 5, characterized in that said at least one evidence of trust (420) comprises a certification by said third party (700), said certification comprising a digital signature, said attestation is used to prove that said identity of said remote application (310) is authentic; Wherein, determining whether said identity of said remote application (310) is authentic includes verifying a digital signature; And/or, the at least one trust evidence (420) includes a list of trusted application identities; Wherein, determining whether the identity of the remote application (310) is trusted includes comparing the identity of the remote application (310) with the list of trusted application identities. 7. The apparatus (400, 500, 600) of claim 6, wherein said at least one trust evidence (420) includes said identity, said service provider the degree of trust associated with at least one of the provider (300) and the software provider of the remote application, Wherein, determining whether said identity of said remote application (310) is trusted comprises comparing said degree of trust to a threshold, said threshold being predefined and/or received from a client application (110, 510) . 8. The device (400, 500, 600) according to any one of claims 1 to 3, characterized in that the at least one trust evidence (410) is generated based on the configuration of the remote application (310) of, Wherein, determining whether the identity of the remote application (310) is trusted includes computing the remote application ( 310) identity. 9. The device (400, 500, 600) according to claim 8, characterized in that the remote application (310) is provided by the service provider (300) as an Infrastructure as a Service (Infrastructure as a Service) , IaaS), wherein the at least one trust evidence (410) is generated by the client (100, 500). 10. A method for trust verification of remote services, characterized in that the method comprises: sending an attestation request attesting to the identity of the remote application (310) executing at least in part in the trusted execution environment (320) of the service provider (300); receiving an attestation response to the attestation request including the identity of the remote application (310) from the service provider (300); determining whether said identity of said remote application (310) is authentic based on said attestation response and at least one trust evidence (410, 420); After determining that said identity of said remote application (310) is trustworthy, connecting to said remote application (310), wherein said at least one evidence of trust (410, 420) is provided by a At least one of (300) (100, 500, 700) generated; The remote application program (310) is provided by the service provider (300) as Software as a Service (Software as a Service, SaaS); Wherein, the at least one trust evidence (420) includes at least one of the following: an attestation by a third party (700), said attestation including a digital signature, attesting that said identity of said remote application (310) is authentic; List of trusted application identities; Proof of analysis generated by said third party (700) for said remote application (310); wherein said proof of analysis is performed each time an updated version of the remote application becomes available and/or installed at the service provider side , said analysis proving that the remote application specified with the particular application ID is free of malware and/or backdoors; a level of trust associated with at least one of said identity of said remote application (310), said service provider, and a software provider of said remote application; Wherein, determining whether the identity of the remote application (310) is trusted includes corresponding one or more of the following: verify said digital signature; comparing said identity of said remote application (310) to said list of trusted application identities; comparing said proof of analysis with at least one requirement setting, said at least one requirement setting being predefined and/or received from a client application (110, 510); The trust level is compared to a threshold, either predefined or received from the client application (110, 510). 11. The method of claim 10, further comprising: All network traffic between the client (100, 500) and said remote application (310) is handled. 12. The method according to claim 10 or 11, characterized in that, The remote application (310) is a user application executed by the service provider (300) as Infrastructure as a Service (IaaS); Wherein, the at least one trust evidence (410) is generated by the client (100, 500) according to the configuration of the remote application (310); Wherein, determining whether the identity of the remote application (310) is trusted includes computing the remote application ( 310) identity. 13. A computer-readable medium storing instructions, characterized in that, when the instructions are executed in a processor, the processor is caused to execute the method according to any one of claims 10-12.

Images