CN109361668B - Trusted data transmission method - Google Patents

Abstract

The invention discloses a data trusted transmission method. The client and the server for data transmission are authenticated through SGX, the client authentication module verifies the legitimacy of the platform where it is located and the user to the corresponding server, and the client is authenticated After that, a session with the server is established, a one-time provisioning agreement is performed between the client and the server, and the confidential data of the client application is sealed on the platform where the application is located. Secure channel for communication connection, each channel corresponds to a unique client, the data sent by the server to the client is encrypted during transmission; after the protected file is encrypted in the enclave, it is sent to the client according to the file request of the client Specific files are then distributed to authenticated and authorized users of the application to view or perform other operations. The method is based on trusted hardware and effectively addresses security vulnerabilities.

Description

Trusted data transmission method

Technical Field

The invention belongs to the field of information security, and particularly relates to a novel trusted data transmission method, which is based on trusted hardware and relates to transmission of secret information in a smart grid.

Background

Since the advent of computer technology, the variety and number of applications running on computers has increased. Today's computer systems need to process more and more important, sensitive and valuable information. Such information must be tamper-resistant and theft-proof. Unfortunately, today the entire industry is more or less dedicated to stealing information [1], such as banking data or intellectual property rights of enterprises from the system. There are many applications on computer platforms that must be kept secret, such as financial projects, internet banking, and medical records applications. The secret holders or software may not trust each other, so the secrets of each software should be protected independently. Therefore, securing software and data on a computer platform has also become an important and complex task for many years.

The main functions of the current secure file transfer application are secure access to key elements and distribution of sensitive files, including ensuring confidentiality of files, access control and user usage constraints, activity logging, etc. Today, enterprises pay more and more attention to data security, and most security implementations focus on protecting enterprise data, and the need for performing authorized use and distributing personal content such as pictures, videos and the like becomes more and more obvious. The prior art solutions can also be used to achieve this.

Existing typical secure file transfer applications run on off-the-shelf client platforms and operating systems, which present a series of security issues. For example, malware, including viruses and hacking programs, threaten the ability of such applications to protect secrets and perform their processes, potentially resulting in transparent loss of digital material by the enterprise, even if such theft remains undetected for an extended period of time. Similar cases such as the network attack "Aurora" (Operation Aurora) affect many large companies. Existing schemes that attempt to protect enterprise data using encryption and access control mechanisms are vulnerable to a number of attacks. For example, malware may steal file content even while stealing keys for encryption, by reading application memory while the application is running, copying display content from video frame buffers, or violating usage policies (e.g., an attacker utilizes system time of the machine where the client is located to modify to extend the usage of expired files). In addition, given that the above mentioned threats have been resolved, more advanced attacks can still crack the application. If an attacker has access to the hardware of the platform on which the application runs, he can use hardware stealing such as "Memory Snooping" or "Cold Boot Attack" (Cold Boot Style attach) to obtain the keying material, although your application has used some encryption means to secure the file. The consequence of this is that an attacker can create malware and effectively impersonate a truly secure application client with the stolen keys. Finally, a normal enterprise data consumer, in extreme cases, maliciously copies large amounts of confidential digital information and can directly modify the application's security safeguards to avoid logging or other forms of monitoring.

Disclosure of Invention

The invention aims to provide a novel data trusted transmission method, which is based on trusted hardware, relates to the transmission of secret information in a smart grid, and is a secure file transmission system of an SGX technology, and also focuses on file distribution, access control and viewing, so that security holes are effectively solved.

In order to achieve the purpose, the invention adopts the following technical scheme: a data credible transmission method is characterized in that a client and a server which perform data transmission are authenticated through SGX, a client authentication module confirms the legality of a platform where the client is located and a user to a corresponding server, a session between the client and the server is established after the client is authenticated, the client and the server perform a one-time supply protocol, confidential data applied by the client are sealed to the platform where the application is located, wherein an independent safe channel is established between the server and the client for communication connection, each channel corresponds to a unique client, and data sent to the client by the server is encrypted in the transmission process;

after the protected file is encrypted in enclave, a specific file is sent to the client according to the file request of the client, and then the specific file is distributed to an application user which is authenticated and authorized to view or execute other operations.

Further, the authenticated user receives the encrypted file, and checks the file by using a secure file reading component operated in enclave of the client platform; meanwhile, the permission checking component of the client checks whether the user has permission to check or modify the file, and once the permission checking of the file fails, the file decrypting component does not need to work.

Further, the SGX authentication is a combination of local authentication and remote authentication.

Further, the local authentication includes two enclave entities, and the two entities need to be verified mutually, the two entities are a verifier and a verifier, and the specific verification step is:

after an entity A and an entity B establish a communication path, the entity A acquires the value of MRENCLAVE of the entity B;

step two: entity A calls the encapsulated EREPORT instruction and uses the MRENCLAVE value of entity B to generate a signed REPORT for transmission back to entity B;

step three: after receiving the REPORT sent by the entity A, the entity B calls an EGETKEY instruction to acquire the REPORT Key thereof, recalculates the MAC of the REPORT, and compares the calculation result with the MAC in the REPORT;

if the two are consistent, the entity B confirms that the entity a is indeed the enclave running on the same platform as itself, and after the firmware and hardware components of the TCB are checked to be correct, the entity B can check the REPORT of the entity a to verify the software components of the TCB, including mrencolay reflecting the content of the software image running in the enclave and MRSIGNER reflecting the identity of the encryptor.

Further, the remote authentication includes: creating a quote Enclave on a platform of a client, and performing local authentication between the Quoting Enclave and the client Enclave; after the local authentication execution is finished, quote Enclave replaces the MAC in the REPORT with a signature, which is done using the device-specific asymmetric key, quote Enclave keeps the private key for the signature, which is done using RSA.

Further, the remote authentication comprises the following steps:

the method comprises the following steps: after receiving the request, the server sends a challenge statement to the client, which indicates that the client needs to provide evidence to prove that the client really runs in an environment meeting the security standard, namely enclave, and meanwhile, the client needs to prove the validity of the client.

Step two: after receiving the statement, the client hands the statement to own target Enclave for processing, and the target Enclave performs corresponding feedback operation according to the received challenge statement and performs a local authentication process with the quote Enclave of the same platform.

Step three: the target Enclave sends signature information of all self application code texts to the QUOTE Enclave, the QUOTE Enclave generates the QUOTE and the ciphertext of the signature information, the RSA public key is sent to the target Enclave, the target Enclave forwards the QUOTE, the ciphertext of the signature information and the RSA public key to the server after receiving the QUOTE, the ciphertext of the signature information and the RSA public key, the server decrypts the QUOTE according to the public key to obtain the REPORT of the target Enclave and the server, the REPORT is checked in a mode similar to local authentication result processing, and meanwhile whether the application signature information is consistent with the pre-recorded signature is checked.

Further, the encrypting the data sent by the server to the client in the transmission process includes:

the client randomly generates an RSA key pair, extracts a public key in the RSA key pair, and sends the public key to the server through the socket;

after receiving the public key, the server side encrypts a secret key which is distributed by the random password generator and used for encrypting the file, and sends the secret key to the client side;

and after receiving the encrypted data, the client decrypts the data by using a private key in the RSA key pair, thereby obtaining a key for encrypting the file.

Further, the random password generator distributing the key for encryption comprises the following steps:

a. storing fixed characters in an immutable sequence;

b. requesting NTP service and taking the acquired time as a seed of a random number;

c. generating an integer subscript each time by using an RRAND instruction according to the seeds, and reading the corresponding characters of the subscripts in the step a from a fixed sequence;

d. the characters are combined into a random password of 16 bytes.

Further, the file sent from the server side to the client side in a shunting manner must be transmitted from the corresponding secure channel, and the communication is unidirectional and is all dominated by enclave sending the request.

Further, the encrypting the storage includes: the application running in the envelope requests the key by instructing the EGETKEY, reads the cached data after successfully acquiring the key, and for 1024 cached bytes which are read, the bytes are encrypted in groups according to a sliding window-like method and the encryption principle of AES (advanced encryption standard), wherein each group still has 16 bytes, and each group of bytes is encrypted by utilizing the encryption algorithm of AES.

After the technical scheme is adopted, the invention has the following advantages: the trusted transmission system based on the SGX covers the security guarantee of hardware and software, so that confidential files can be transmitted to a client from a remote server safely, and safe processing and storage access are realized. The system achieves the expected targets on the whole about the design and implementation of the security of the client, the file authority control, the file transmission process and the file storage access, and realizes the credibility of the transmission system. The integrity of the client and the safety of the system where the client is located are ensured, and the privacy of the running memories of key codes and data of the client and the server program is ensured; the confidentiality of file transmission and the security of file storage as well as the uniqueness and independence of encryption keys are ensured.

Drawings

The invention will be further described with reference to the accompanying drawings in which:

FIG. 1 is a schematic diagram of the overall system framework of the present invention;

FIG. 2 is a diagram illustrating a local authentication method according to the present invention;

FIG. 3 is a diagram illustrating a remote authentication method according to the present invention;

FIG. 4 is a schematic diagram of a secure channel in accordance with the present invention;

FIG. 5 is a schematic diagram of communication transmission according to the present invention;

FIG. 6 is a schematic diagram of encrypted storage according to the present invention.

Detailed Description

Example (b):

the invention relates to a data credible transmission method, a client and a server which carry out data transmission are authenticated through SGX, a client authentication module confirms the legality of a platform where the client is located and a user to a corresponding server, after the client is authenticated, a session between the client and the server is established, the client and the server carry out a one-time supply protocol, confidential data applied by the client are sealed on the platform where the application is located, wherein an independent safe channel is established between the server and the client for communication connection, each channel corresponds to a unique client, and data sent to the client by the server is encrypted in the transmission process; after the protected file is encrypted in enclave, a specific file is sent to the client according to the file request of the client, and then the specific file is distributed to an application user which is authenticated and authorized to view or execute other operations.

Specifically, as shown in fig. 1, which is a system framework diagram, the trusted part of the client, i.e. the part hosted in the protected enclave of the SGX, performs file operations that need to be kept secret. The architecture and how the overall system operates to meet the security requirements in various file management scenarios will be described in detail below.

Firstly, the client authentication module verifies the legality of the platform where the client authentication module is located and a user to the corresponding server. Using the SGX authentication function, this module generates a verifiable report about the client entity, i.e. the identity information bound to the platform on which the client resides, which is bound by the CPU. The server checks the report to determine that the machine with which it is communicating at the time supports SGX functionality and that the identity of the client is legitimate. The client and the server are in one-time provisioning agreement, so that the confidential data of the application is sealed on the platform where the application is located. The encrypted confidential data can only be decrypted and manipulated by the application.

In the architecture of the present system, the usage rights of the file and the encryption key are saved to the database of the server. The database administrator can modify the corresponding usage rights and group users of the client to achieve management of the rights. After the client is authenticated, a session is established with the server, and the server verifies the security of the client and the platform where the client is located. If the file is simply transmitted from the server to the client, the security of the system is greatly reduced, and meanwhile, the encrypted storage of the client is meaningless. To do this, separate secure channels need to be established between the server and the client, each channel corresponding to a unique client. After the protected file is encrypted in enclave, a specific file is sent to the client according to the file request of the client, and then the specific file is distributed to an application user which is authenticated and authorized to view or execute other operations.

Once the authenticated user receives the encrypted file, he can use the secure file reading component running in enclave of the client platform to view the file. In the process, the permission check component of the client needs to check whether the user has permission to check or modify the file, and once the permission check of the file fails, the file decryption component does not need to work.

The server includes several modules: the system comprises an authentication and session management module, a file transmission key generation module and a database for storing data related to users and files. All communication content between the server and the client is encrypted, and end-to-end integrity, replay protection and the like are guaranteed in various scenes. The system is protected from the following attacks: file content or a key used for encryption is stolen; platform and application identity spoofing, i.e., a malicious program or platform impersonating a legitimate application; usage constraints and activity logs are tampered with.

In this embodiment, in a specific authentication function design, the SGX hardware security support mainly provides a secure operating environment for upper layer application programs, and can encrypt applications so that an untrusted bottom operating system and hardware cannot steal application secrets. The traditional SGX authentication method mainly focuses on verifying the SGX running environment, that is, verifying whether an application runs safely in the SGX environment, but does not focus on the safety verification of the application itself. That is, the traditional SGX research mainly relies on the assumption that the application itself is safe, and in a real trusted transmission application scenario, the client application disguised as a user is also one of threats. For the problem, different from the traditional work, the system adopts an authentication mode combining local authentication and remote authentication.

The process of local authentication as shown in fig. 2, in the present system, the local authentication includes two enclave entities, the verifier and the verifier, and the two entities need to verify each other to prepare for the remote authentication later. For convenience of description, hereinafter, a represents a verifier and B represents a verifier. First, as step (r), entity a establishes a socket connection with entity B. After establishing the communication path, a obtains the value of MRENCLAVE of B. It should be noted that this part of the communication is not encrypted, because this step does not involve the transmission of the file, and any change or loss of the transmitted value will result in a failure of the authentication. Then a calls the encapsulated ereprt instruction and uses the MRENCLAVE value of B to generate a signed REPORT for transmission back to B, step two. A still sends a REPORT to B over this untrusted communication path. The REPORT structure here contains the identity of the two enclaves, the attributes associated with the enclaves, the trustworthiness of the hardware TCB, and a MAC (Message Authentication Code) tag, as mentioned above.

After receiving the REPORT sent by a, the entity B calls the EGETKEY instruction to obtain its REPORT Key, to recalculate the MAC of the REPORT, and compares the calculation result with the MAC in the REPORT. If the two are consistent, B can be sure that A is really enclave running on the same platform with B. When the firmware and hardware components of the TCB are checked for errors, B may check A's REPORT to verify the TCB's software components, including MRENCLAVE, which reflects the contents of the software image running in enclave, and MRSIGNER, which reflects the identity of the encryptor. This point B completes the verification of a. B then uses the value of MRENClave in the previously received REPORT to generate its REPORT in the same way, and then transmits it to A, as shown in step (c). Eventually a verifies B in the same way to ensure a is authentic.

The verification mechanism for intra-platform authentication uses a symmetric key encryption method in which only enclave checks the REPORT structure and the ereprt instruction used to generate the REPORT has access to the verification key. However, in the remote authentication, since the Enclave of the server and the Enclave of the client are distributed on two different platforms, a special Enclave, called a throttling Enclave (quote Enclave), needs to be created on the platform of the client to help the server complete the verification of the client and feed back the verification information. Since it is quoted that Enclave and the Enclave executed by the client are in the same platform, with the implementation described above, we can complete local authentication between the requesting Enclave and the client Enclave. After the local authentication execution is finished, the quote Enclave replaces the MAC in the REPORT with a signature, this signature is done using the device specific asymmetric key, the quote Enclave holds the private key used for the signature. The REPORT after replacing the MAC is called a Queue (QUOTE). The above-described signature is done using RSA.

As shown in fig. 3, the client initially wants to acquire a file of the server, and therefore, communication with the server is established. The method comprises the following steps that firstly, after receiving a request, a server sends a challenge statement to a client, and the client needs to provide evidence to prove that the client really runs in an environment which accords with a safety standard, namely enclave, and meanwhile, the client needs to prove the legality of the client. After receiving the declaration, the client hands it to its target Enclave (i.e. the Enclave executing the authentication flow) for processing. At this time, the target Enclave performs corresponding feedback operation according to the received challenge statement, and performs the above local authentication process with the quoted Enclave of the same platform, as in step two. After both enclaves have finished verification, it means that both are in the enclaves that meet the safety standards. At this time, the target Enclave sends signature information of all code texts applied by the target Enclave to the quote Enclave. QUOTE Enclave will generate quite and ciphertext of the signature information, and send RSA public key to target Enclave. After receiving the quite, the ciphertext of the signature information and the RSA public key, the target encrypt forwards them to the server, in step three. Finally, the changer on the server decrypts the queue according to the public key to obtain the REPORT of the both, and completes the check of the REPORT in a manner similar to the local authentication result processing, and meanwhile, checks whether the application signature information is consistent with the pre-filed signature. If the check passes, the entire remote authentication declares success, otherwise it fails and the server will reject other requests from the client.

In the method disclosed in patent document CN201810190643, a dynamic "two-step" authentication method is adopted, that is, an SGX module (using Intel SGX technology) is added between a user and an authentication server, the user sends the own identity information to the SGX module when performing identity authentication, the SGX module encrypts the identity information by using a key stored therein, and then transmits the encrypted information to the authentication server for the second authentication. The user terminal in this authentication method is actually in an untrusted environment, i.e. without the protection of the SGX. Therefore, the risk of man-in-the-middle attack exists, a malicious attacker can grasp the user and obtain the verification summary information sent to the SGX by the user through the means of packet capturing and the like so as to replay and obtain the authentication.

In the method disclosed in patent document CN201710621204, a traditional SGX identity authentication method is adopted, which lacks authentication on the application itself, and has a risk of pretending attacks by customers.

Specifically, in this embodiment, the design and implementation of the secure channel are as follows:

according to the invention, a secure channel is established for the communication connection between each client and the server, so that data sent by the server to the clients are encrypted in the transmission process. Thus, even if an attacker steals the transmitted data, he is left with no idea, let alone to make some attacks with the data.

The implementation of the module needs to execute two important processes, namely the generation of a random password by the server and the safe transmission process of the random password. In order to match file encryption and enhance the security of an encrypted file, the password generator adopts an RRAND instruction provided by an Intel architecture for generating a true random number.

a. Storing fixed characters in an immutable sequence;

b. requesting NTP (Network Time Protocol) service, and taking the obtained Time as a seed of a random number;

c. generating an integer subscript each time by using an RRAND instruction according to the seeds, and reading the corresponding characters of the subscripts in the step 1 from a fixed sequence;

d. the characters are combined into a random password of 16 bytes.

After the above steps are performed, the random password generator allocates a one-time file encryption key to each password request.

Although it is difficult for an attacker to know which portion is the key used to encrypt the file due to the continuity of the packets, even if the key is captured. However, the system encrypts the transmission of the key in consideration of the possibility of key leakage in extreme cases. The basic principle of this part is to encrypt and decrypt the above keys using RSA. Using RSA encryption ensures that the key can only be passed between the server and the client and that the decryptor can only be the client. The specific transmission implementation flow is shown in fig. 4:

the client randomly generates an RSA key pair, then extracts a public key in the RSA key pair, and sends the public key to the server through the socket. And after receiving the public key, the server side encrypts a key which is distributed by the random password generator and used for encrypting the file, and sends the encrypted key to the client side. And after receiving the encrypted data, the client decrypts the data by using a private key in the RSA key pair, thereby obtaining a key for encrypting the file. When data is sent from the server side, a safe channel is established, and the data transmitted by the channel is encrypted, so that the security of file transmission is ensured.

Specifically, in this embodiment, the design and implementation of the secure file transmission are as follows:

the file transmission is mainly that the server sends files from the server side to the client side in a shunting manner according to received file requests, and data in the whole process must be transmitted from a corresponding secure channel.

Since data is sent and received from enclave, an attacker can be organically multiplied by using a traditional Socket communication mode, namely, an interface of enclave can be exposed. Although enclaves may legitimately access host shared memory outside enclaves, this approach still has certain problems because a malicious host or operating system may modify non-enclave memory. Therefore, to avoid this situation, the present system provides a more stringent form of communication protocol, namely using shared code and data fields, classified as Trampoline and Stub. This area defines a strict interface with enclave interaction, making the relevant security attributes easy to control.

The communication is unidirectional and is all dominated by enclave sending the request. As shown in fig. 5, the system first needs to reserve two memory areas in the host normal memory, and register the memory addresses at both ends in enclave, so that the two memory areas become Stub and Trampoline areas. When Enclave requests a socket instance for a network, a corresponding parameter is first set in Stub (for example, fcode is assigned to fstoken), and then a predefined handler, that is, Trampoline, is called. After the enclave request and the tramroline code are processed by the host program or the operating system, the result or the return value is stored in the Stub memory area, and at the end of the tramroline code, the ERESUME instruction is re-executed to recover the operation of the enclave. After restoring control of the program to the location where enclave was previously executed, enclave may read the value in the Stub, which obtained the socket instance via in _ arg0 in the Stub. The Enclave can perform trusted transmission by using the socket channel.

At this time, according to the previous key part, after the client obtains the unique file encryption key, the server needs to encrypt the transmitted file by using the key as the channel creator. The encryption algorithm utilized here is the AES algorithm.

Specifically, in this embodiment, the design and implementation of the file sealing module are as follows:

encrypted storage is a process of reading the contents of the process buffer and outputting them in bytes to a new file on the hard disk, as shown in fig. 6. Firstly, an application running in the envelope requests a key by instructing an EGETKEY, and after the key is successfully acquired, the cached data is read. For 1024 buffer bytes read, the bytes are encrypted in groups according to a sliding window-like method and the encryption principle of AES, and each group is still 16 bytes. Then, each group of bytes is encrypted by using an encryption algorithm of AES. Since the encrypted bytes are difficult to conform to the system's encoding, certain obstacles may be brought to decryption. Therefore, we need to do some processing to the encrypted character, here, each byte is converted into 16-ary form by using loop and output to the designated file. After all data encryption is completed, the sealed storage module completes the task.

The trusted transmission system based on the SGX covers the security guarantee of hardware and software, so that confidential files can be transmitted to a client from a remote server safely, and safe processing and storage access are realized. The system achieves the expected targets on the whole about the design and implementation of the security of the client, the file authority control, the file transmission process and the file storage access, and realizes the credibility of the transmission system. The integrity of the client and the safety of the system where the client is located are ensured, and the privacy of the running memories of key codes and data of the client and the server program is ensured; the confidentiality of file transmission and the security of file storage as well as the uniqueness and independence of encryption keys are ensured.

Other embodiments of the present invention than the preferred embodiments described above will be apparent to those skilled in the art from the present invention, and various changes and modifications can be made therein without departing from the spirit of the present invention as defined in the appended claims.

Claims (6)

1. A data credible transmission method, the client and server that carry on the data transmission carry on the authentication through SGX, the client authentication module confirms its platform and user's legitimacy in place to the correspondent server, after the client is authenticated, has set up the conversation with the server, the client and server carry on the disposable provision agreement, the client uses the confidential data to seal to employ on the platform, characterized by, set up the independent safe channel to carry on the communication connection between client and the server, each channel corresponds to the only client, the server encrypts the data that the client sends to the client in the transmission;

after the protected file is encrypted in enclave, sending a specific file to the client according to a file request of the client, and then distributing the file to an application user which is authenticated and authorized to view or execute other operations;

the authenticated user receives the encrypted file and uses a secure file reading component operated in enclave of the client platform to check the file; meanwhile, the permission checking component of the client checks whether the user has permission to check or modify the file, and once the permission checking of the file fails, the file decryption component does not need to work;

the data sent by the server to the client is encrypted in the transmission process, and the encryption comprises the following steps:

the client randomly generates an RSA key pair, extracts a public key in the RSA key pair, and sends the public key to the server through the socket;

after receiving the public key, the server encrypts a secret key which is distributed by the random password generator and used for encrypting the file, and sends the secret key to the client;

after receiving the encrypted data, the client decrypts the data by using a private key in an RSA key pair, thereby obtaining a key for encrypting the file;

the random password generator distributing a key for encryption comprises the following steps:

a. storing fixed characters in an immutable sequence;

b. requesting NTP service and taking the acquired time as a seed of a random number;

c. generating an integer subscript each time by using an RRAND instruction according to the seeds, and reading the corresponding characters of the subscripts in the step a from the unchangeable sequence;

d. combining the characters into a random password of 16 bytes;

sending files from the server to the client in a shunting manner must be transmitted from a corresponding secure channel, and the communication is unidirectional and is all dominated by enclave sending a request;

using shared code and data area, divided into Trampoline and Stub; firstly, two memory areas are reserved in a host common memory, and memory addresses at two ends are registered in enclave to form Stub and Trampoline areas.

2. The method according to claim 1, wherein the SGX authentication is a combination of local authentication and remote authentication.

3. The method according to claim 2, wherein the local authentication includes two enclave entities, and the two entities need to authenticate each other, and the two entities are an authenticator and an authenticatee, and the specific authentication step includes:

after an entity A and an entity B establish a communication path, the entity A acquires the value of MRENCLAVE of the entity B;

step two: entity A calls the encapsulated EREPORT instruction and uses the MRENCLAVE value of entity B to generate a signed REPORT for transmission back to entity B;

step three: after receiving the REPORT sent by the entity A, the entity B calls an EGETKEY instruction to acquire the REPORT Key thereof, recalculates the MAC of the REPORT, and compares the calculation result with the MAC in the REPORT;

if the two are consistent, the entity B confirms that the entity a is indeed the enclave running on the same platform as itself, and after the firmware and hardware components of the TCB are checked to be correct, the entity B can check the REPORT of the entity a to verify the software components of the TCB, including mrencolay reflecting the content of the software image running in the enclave and MRSIGNER reflecting the identity of the encryptor.

4. The trusted data transfer method of claim 3, wherein the remote authentication comprises: creating a quote Enclave on a platform of a client, and performing local authentication between the Quoting Enclave and the client Enclave; after the local authentication execution is finished, the quote Enclave replaces the MAC in the REPORT with a signature, which is done using the device specific asymmetric key, and the quote Enclave holds the private key used for the signature.

5. The trusted data transmission method according to claim 4, wherein said remote authentication comprises the steps of:

the method comprises the following steps: after receiving the request, the server sends a challenge statement to the client, which indicates that the client needs to provide evidence to prove that the client really operates in an environment meeting the safety standard, namely enclave, and meanwhile, the client needs to prove the validity of the client;

step two: after receiving the statement, the client hands the statement to own target Enclave for processing, and the target Enclave performs corresponding feedback operation according to the received challenge statement and performs a local authentication process with the quote Enclave on the same platform;

step three: the target Enclave sends signature information of all self application code texts to the QUOTE Enclave, the QUOTE Enclave generates the QUOTE and the ciphertext of the signature information, the RSA public key is sent to the target Enclave, the target Enclave forwards the QUOTE, the ciphertext of the signature information and the RSA public key to the server after receiving the QUOTE, the ciphertext of the signature information and the RSA public key, the server decrypts the QUOTE according to the public key to obtain the REPORT of the target Enclave and the server, the REPORT is checked in a local authentication result processing mode, and meanwhile whether the application signature information is consistent with the pre-filed signature is checked.

6. The trusted data transfer method of claim 1, wherein the encrypted storage comprises: the application running in the envelope requests the key by instructing the EGETKEY, reads the cached data after successfully acquiring the key, and for 1024 cached bytes which are read, the bytes are encrypted in groups according to a sliding window method and the encryption principle of AES, wherein each group still has 16 bytes, and each group of bytes is encrypted by utilizing the encryption algorithm of AES.

Images