WO2020098377A1 - 可信应用程序的远程证明方法及装置、电子设备 - Google Patents

可信应用程序的远程证明方法及装置、电子设备 Download PDF

Info

Publication number
WO2020098377A1
WO2020098377A1 PCT/CN2019/106607 CN2019106607W WO2020098377A1 WO 2020098377 A1 WO2020098377 A1 WO 2020098377A1 CN 2019106607 W CN2019106607 W CN 2019106607W WO 2020098377 A1 WO2020098377 A1 WO 2020098377A1
Authority
WO
WIPO (PCT)
Prior art keywords
remote
public key
private key
receiving object
target container
Prior art date
Application number
PCT/CN2019/106607
Other languages
English (en)
French (fr)
Inventor
陆钟豪
Original Assignee
阿里巴巴集团控股有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 阿里巴巴集团控股有限公司 filed Critical 阿里巴巴集团控股有限公司
Publication of WO2020098377A1 publication Critical patent/WO2020098377A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • One or more embodiments of this specification relate to the field of blockchain technology, and in particular, to a remote certification method and apparatus for a trusted application program, and electronic equipment.
  • Remote Attestation is a method for hardware or software to obtain the trust of remote providers or producers. It is one of the key technologies of trusted computing. For example, in practical applications, the protected code in the trusted application can be isolated in the trusted execution environment, and based on the remote certification technology, these can be proved to the remote receiving object without revealing the protected code. The execution result of the protected code is trusted data.
  • This specification proposes a method for remote attestation of a trusted application program.
  • the protected code in the trusted application program is isolated and loaded in a target container as a trusted execution environment; wherein the protected code includes code to be executed , And an objective function for generating private and public keys; the method includes:
  • the target function to generate a private key and a public key in the target container, and encrypt the generated private key and persistently store the encrypted private key; wherein, the encrypted private key is set A decryption strategy for decryption by the target container only;
  • calling the target function to generate a private key and a public key in the target container includes:
  • the target function is periodically called to generate a private key and a public key in the target container.
  • a third-party remote certification server initiates remote certification of the public key to a remote receiving object, and when the public key passes the remote certification, the public key is sent to the remote receiving object for persistence Storage, including:
  • the trusted execution environment is a trusted execution environment built based on SGX technology; the target container is an Enclave program in SGX technology; wherein, the decryption policy of the encrypted private key is set to keypolicy- MRENCLAVE strategy.
  • the remote receiving object is a smart contract issued to the blockchain.
  • This specification also proposes a remote certification device for a trusted application program.
  • the protected code in the trusted application program is isolated and loaded in a target container as a trusted execution environment; wherein the protected code includes a pending execution
  • the code, and the objective function for generating the private key and the public key; the device includes:
  • a generating module calling the target function to generate a private key and a public key in the target container, encrypting the generated private key, and persistently storing the encrypted private key; wherein, the encrypted private key A decryption strategy that is only decrypted by the target container is set;
  • the certification module initiates remote certification of the public key to the remote receiving object through a third-party remote certification server, and when the public key passes the remote certification, sends the public key to the remote receiving object for persistence storage;
  • An obtaining module to obtain an execution result of the code to be executed; wherein the execution result is signed by the target container based on the decrypted private key;
  • the verification module sends the execution result to the remote receiving object to verify the signature of the execution result based on the stored public key by the remote receiving object to confirm whether the execution result is authentic data.
  • the generation module :
  • the target function is periodically called to generate a private key and a public key in the target container.
  • the certification module :
  • the trusted execution environment is a trusted execution environment built based on SGX technology; the target container is an Enclave program in SGX technology; wherein, the decryption policy of the encrypted private key is set to keypolicy- MRENCLAVE strategy.
  • the remote receiving object is a smart contract issued to the blockchain.
  • This manual also proposes an electronic device, including:
  • Memory for storing machine executable instructions
  • the protected code in the trusted application is isolated and loaded in In a target container as a trusted execution environment; wherein the protected code includes code to be executed, and a target function for generating a private key and a public key; the processor is prompted to:
  • the target function to generate a private key and a public key in the target container, and encrypt the generated private key and persistently store the encrypted private key; wherein, the encrypted private key is set A decryption strategy for decryption by the target container only;
  • the public-private key pair for remote certification is generated autonomously in the target container as a trusted execution environment, it is no longer generated by the software provider; and, the encrypted private The key is set with a decryption strategy that only the target container decrypts; therefore, even the software developer cannot obtain the generated private key, which can significantly improve the security level of the private key;
  • the trusted application since the trusted application only needs to pass the third-party remote certification server, it initiates a remote certification of the publicly generated public key to the remote receiving object, and after the public key passes the remote certification, it can be directly used later
  • the generated private key signs the execution result of the code to be executed in the protected code, and sends the signed execution result to the remote receiving object to complete the remote certification of the execution result, without the need for a third-party remote certification service
  • the remote end initiates remote proof of the execution result to the remote receiving object; therefore, it is no longer necessary to frequently interact with the third-party remote certification server, and it can conveniently receive the object remotely based on the self-generated public and private key pair. Prove that the execution result is reliable data.
  • FIG. 1 is a flowchart of a remote certification method for a trusted application program provided by an exemplary embodiment.
  • FIG. 2 is a schematic structural diagram of an electronic device provided by an exemplary embodiment.
  • FIG. 3 is a block diagram of a remote certification device for a trusted application program provided by an exemplary embodiment.
  • TEE Trusted Execution Environment
  • TEE when building a TEE, you can usually use the processor at the bottom of the device as hardware support to build a container that can only be accessed by the processor as a trusted execution environment, and protect the trusted applications
  • the code is isolated and loaded in the container to isolate and protect the protected code in the container.
  • the CPU of the device is usually used as hardware support to create a program called Enclave as a protection container, and Isolate and load the code that needs to be protected in the Enclave program to protect it from attacks.
  • Enclave Software Guard Extensions, software protection extension
  • the trusted application needs to send the execution result of the above protected code to the remote receiving object.
  • the remote receiving object usually based on remote certification technology, on the basis of not leaking the protected code, prove to the remote receiving object that the execution result of the protected code is trusted data.
  • a smart contract deployed on the blockchain needs to use the execution result of the protected code in the trusted application as input data to perform trusted calculation on the blockchain; in this case Since the trusted application is not a node on the chain, it is an untrusted party to the smart contract; therefore, when the trusted application sends the execution result of the protected code to the smart contract deployed on the blockchain, then It is necessary to rely on remote proof technology to prove to smart contracts that the execution results of these protected codes are trusted data (ie, on-chain proof) on the basis of not revealing the protected codes.
  • Intel will provide a third-party IAS (intel attestation service) server for remote certification. Isolate the execution results of the protected code loaded in the Enclave. If you need to participate in trusted computing, the trusted application can interact with the IAS server and initiate remote execution of the protected code execution results to the remote receiving object through the IAS server. Authentication, to prove to the remote receiving object that the execution result of the protected code is trusted data.
  • IAS infrastructure attestation service
  • this specification proposes a remote certification scheme based on the public and private key pairs independently generated by the container as a trusted execution environment to conveniently initiate the execution result of the protected code to the remote receiving object.
  • TEE target containers such as the Enclave program in SGX technology
  • specific TEE construction technologies such as Intel ’s SGX technology
  • the protected code that is loaded in the target container in isolation may include the code to be executed whose execution result needs to be remotely certified by the remote receiver, and the target function for generating the private key and the public key (essential (The above are some special codes for generating private keys and public keys).
  • the trusted application program can call the target function in the protected code isolated and loaded in the target container to generate a pair of public and private keys in the target container;
  • the generated private key can also be encrypted in the target container; when the generated private key is encrypted in the target container, the encrypted private key can be set to be decrypted only by the target container Decryption strategy (that is, only the target container has decryption authority); then, the processor stores the encrypted private key persistently.
  • the target container may decrypt the encrypted private key and sign the execution result of the code to be executed based on the private key.
  • the trusted application can obtain the execution result signed by the target container and send the execution result to the remote receiving object to initiate remote certification of the execution result.
  • the remote receiving object may verify the signature of the execution result based on the stored public key to determine whether the execution result is trusted data.
  • the public-private key pair for remote certification is generated autonomously in the target container as a trusted execution environment, it is no longer generated by the software provider; and, the encrypted private The key is set with a decryption strategy that only the target container decrypts; therefore, even the software developer cannot obtain the generated private key, which can significantly improve the security level of the private key;
  • the trusted application since the trusted application only needs to pass the third-party remote certification server, it initiates a remote certification of the publicly generated public key to the remote receiving object, and after the public key passes the remote certification, it can be directly used later
  • the generated private key signs the execution result of the code to be executed in the protected code, and sends the signed execution result to the remote receiving object to complete the remote certification of the execution result, without the need for a third-party remote certification service
  • the remote end initiates remote proof of the execution result to the remote receiving object; therefore, it is no longer necessary to frequently interact with the third-party remote certification server, and it can conveniently receive the object remotely based on the publicly generated private key Prove that the execution result is reliable data.
  • FIG. 1 is a remote certification method for a trusted application provided by an embodiment of the present specification, which is applied to a trusted application; the protected code in the trusted application is isolated and loaded as a The target container of the letter execution environment; wherein, the protected code includes the code to be executed, and a target function for generating a private key and a public key; the method performs the following steps:
  • Step 102 Call the target function to generate a private key and a public key in the target container, encrypt the generated private key, and persistently store the encrypted private key; wherein, the encrypted private key A decryption strategy that is only decrypted by the target container is set;
  • Step 104 Initiate remote certification of the public key to the remote receiving object through a third-party remote certification server, and when the public key passes the remote certification, send the public key to the remote receiving object for persistence storage;
  • Step 106 Obtain the execution result of the code to be executed; wherein the execution result is signed by the target container based on the decrypted private key;
  • Step 108 Send the execution result to the remote receiving object, so that the remote receiving object verifies the signature of the execution result based on the stored public key to confirm whether the execution result is authentic data.
  • the above-mentioned trusted application program includes an application program developed by a software developer that can provide a trusted service to a third party; where the program code in the trusted application program usually includes a protected part and is not protected.
  • the above target container refers to a specific TEE construction technology based on this specification to build an isolated safe operating environment that can provide safe protection for the protected code in the trusted application;
  • the above target container may be an isolated software environment supported by the processor as the underlying hardware and can only be accessed by the processor; for example, taking TEE using Intel ’s SGX technology as an example, the above target
  • the container may specifically be an Enclave program in the SGX technology.
  • the protected code in the trusted application program is loaded into the Enclave program in isolation to protect the above-mentioned protected code.
  • the above target container can also be a physically isolated hardware environment; for example, the above target container can be a physically isolated physical chip, which can be used in trusted applications The protected code is loaded into the physical chip in isolation to protect the above protected code.
  • the TEE building technology used for building the TEE is not particularly limited in this specification, and those skilled in the art can flexibly choose based on actual development needs. It is not difficult to understand that the specific form of the above target container usually also depends on the TEE construction technology adopted by those skilled in the art; that is, whether the above target container is ultimately an isolated software environment or an isolated hardware environment depends on The TEE construction technology used by those skilled in the art; for example, if the person skilled in the art uses Intel's SGX technology to build TEE, the above target container is an isolation that is supported by the CPU as the underlying hardware and can only be accessed by the CPU Software environment (ie Enclave program).
  • the above-mentioned remote receiving object specifically refers to a remote data consumer of the execution result of the protected code in the trusted application program; for example, in practical applications, the above-mentioned remote receiving object may be an independent trusted host or a trusted system; Or, it can be a smart contract deployed on the blockchain.
  • the TEE based on Intel's SGX technology will be used as an example for illustration.
  • Intel's SGX technology to build TEE as an example is only schematic; obviously, in In practical applications, it is obvious that other TEE building technologies can also be used to build TEE; for example, TrustZone technology such as ARM can also be used, which will not be enumerated in this manual.
  • software developers of trusted application programs can create Enclave programs as TEE based on Intel's SGX technology, and load protected code in trusted application programs into the target container in isolation.
  • the protected code that is loaded in the Enclave program in isolation is usually called the Trusted Part of the trusted application; other code that is not loaded in the Enclave program in isolation is called the Untrusted Part of the letter application.
  • the protected code isolated and loaded in the above Enclave program may include at least two parts of the code to be executed and the target function;
  • the above-mentioned code to be executed is the protected code that needs to be sent to the remote receiving object for trusted calculation; that is, the trusted application program needs to prove the execution result of the above-mentioned code to be executed to the remote receiving object through trusted certification technology It is trusted data.
  • the above target function is specifically used to generate a public key and a private key for the above target container.
  • the trusted application program initiates remote proof of the execution result of the protected code to the remote receiving object, usually by interacting with the deployed IAS server.
  • the existing remote certification mechanism initiates a remote certification of the public and private key pair independently generated within the Enclave program to the remote receiving object. Then, after the remote certification of the public and private key pair is passed, based on the public and private key pair The remote receiving object initiates the remote proof of the execution result of the protected code, and no longer needs to interact with the IAS.
  • the untrusted area of the trusted application can call the target function in the protected code loaded in the Enclave program by means of ECALL to generate a pair of public and private keys inside the Enclave program .
  • the untrusted area can use ECALL to call the target function in the protected code loaded in the Enclave program in real time when the code to be executed in the protected code is executed. , Can also be called periodically based on a certain calling cycle.
  • the untrusted area when the untrusted area receives the execution instruction for the code to be executed in the protected code, it can respond to the execution instruction in real time, and immediately call the isolated load on the Enclave program by means of ECALL
  • the objective function in the protected code in is to generate a pair of public and private keys inside Enclave.
  • a call period may also be preset for the untrusted area, so that the untrusted area may periodically call the isolated and loaded in the protected code in the Enclave program based on the call period
  • the objective function generates a pair of public and private keys within the Enclave program. In this way, the public and private keys of the Enclave program can be updated regularly.
  • the generated private key can be encrypted by the processor within the Enclave program (the key is held by the processor), and the processor sets the decryption strategy for the encrypted private key, and then encrypts the encrypted private key The key is held for storage;
  • the decryption strategy for the encrypted information generally includes two strategies of keypolicy-MRENCLAVE (hereinafter referred to as MRENCLAVE strategy) and keypolicy-MRSIGNER (hereinafter referred to as MRSIGNER).
  • MRENCLAVE strategy keypolicy-MRENCLAVE
  • MRSIGNER keypolicy-MRSIGNER
  • MRENCLAVE strategy means that it can only be decrypted by the current ENCLAVE; and the so-called MRSIGNER strategy means that it can be decrypted by all ENCLAVEs developed and signed by the same developer.
  • the processor can set the decryption strategy to the MRENCLAVE strategy when setting the decryption strategy for the encrypted private key; that is, only the current ENCLAVE has the ability to decrypt the encrypted private key that is persistently stored permission.
  • the trusted area of the trusted execution program can initiate a remote certification of the public key to the remote recipient through the IAS server, and when the public key passes the remote certification, the generated The public key is sent to the remote receiving object, and the remote receiving object performs persistent storage.
  • the trusted area of the trusted execution program when initiating remote certification of the public key to the remote recipient, can first create a Quote as a remote certification credential based on the generated public key or hash value of the public key;
  • the above Quote is usually internally interacted by Enclave and a special QuoteEnclave, and created by QuoteEnclave.
  • the specific implementation process of the Quote for Enclave created by Quote Enclave is not detailed in this specification, and those skilled in the art can refer to the technology in the related technology when assisting the technical solution of this specification with time .
  • the finally created Quote can include information such as EPID signature, generated public key or hash value of public key (that is, userdata requiring remote certification), MRENCLAVE logo, and EPID logo of the processor.
  • the Quote that is finally created is the information obtained by signing the entire public key or hash value of the public key (that is, userdata that requires remote certification), the MRENCLAVE logo, and the EPID logo of the processor.
  • the MRENCLAVE logo usually the hash value of the Enclave code, is used to uniquely identify an Enclave.
  • EPID identification also known as basename, is used to anonymously identify a processor.
  • the EPID signature is a group signature technology used by Intel ’s SGX technology that can maintain anonymity. In this specification, the signature processing process of the EPID signature and the signature verification process of the EPID signature will not be described in detail. Personnel can refer to the records in related technologies.
  • the trusted area of the trusted execution program can send the Quote to the IAS server for remote verification.
  • the IAS server can verify the Quote ’s EPID signature, and then based on the private key held by the IAS server, sign the Quote and the verification result for the Quote as a whole to generate the corresponding AVR (Attestation Verification Report, to prove the verification report).
  • the AVR may generally include information such as Quote, Quote verification result, and IAS signature.
  • the IAS server can return the generated AVR to the trusted area of the trusted execution program.
  • the trusted area of the trusted execution program can use the AVR and call the above target.
  • the public key generated by the function is further sent to the remote receiving object.
  • the trusted area of the trusted execution program may also send the AVR and the public key generated by calling the above target function to the untrusted area of the trusted execution program, and the untrusted area The public key generated by calling the above target function is further sent to the remote receiving object.
  • the remote receiving object can first verify the status of the AVR; for example, verify whether the value of the status field in the AVR is a specific value indicating that the AVR status is normal; After the status verification of the AVR is passed, the IAS signature of the AVR can be verified based on the public key corresponding to the private key held by the IAS server; if the signature verification is passed, the public in the Quote carried in the AVR can be further targeted at this time Verify the hash value of the key or public key, the MRENCLAVE logo, the processor's EPID logo, and other information.
  • the verification of the public key or the hash value of the public key in Quote is the process of verifying whether the public key or the hash value of the public key in Quote matches the public key sent by the trusted area of the trusted execution program ; For example, if the hash value of the public key is carried in Quote, you can further calculate the hash value of the public key sent by the trusted area of the trusted execution program, and then the calculated hash value and the public key carried in Quote Match the hash value; if the two match, you can confirm the verification.
  • the verification of the MRENCLAVE logo in the Quote and the EPID of the processor is a process of verifying that the Enclave corresponding to the MRENCLAVE logo and the processor corresponding to the EPID of the processor are trusted.
  • Enclave developers can prove that the Enclave code does not contain malicious code through the open source Enclave code, and the administrator of the remote receiving object can conduct a security audit of the open source Enclave code and set the MRENCLAVE whitelist for the remote receiving object. In the same way, it is also possible to set up an EPID whitelist for remote receiving objects according to actual needs.
  • the remote receiving object verifies the information such as the MRENCLAVE logo in Quote and the EPID logo of the processor, it can match the MRENCLAVE logo in Quote with the MRENCLAVE white list, and the EPID logo of the processor in Quote
  • the EPID ID whitelist is matched to confirm whether the Enclave corresponding to the MRENCLAVE ID and the processor corresponding to the EPID of the processor are trusted.
  • the remote receiving object can The above-mentioned public key generated by calling the above-mentioned target function and the corresponding MRENCLAVE and EPID sent by the trusted area of the trusted execution program are stored locally locally.
  • the MRENCLAVE corresponding to the public key generated by calling the target function is used as a trusted program identifier
  • the EPID corresponding to the public key is used as a trusted hardware identifier for persistent storage together with the public key.
  • the trusted application may no longer need to interact with the IAS server to initiate
  • the remote proof of the execution result of the execution code is to directly initiate the remote proof of the execution result of the protected code to the remote receiving object by directly calling the public-private key pair created by the target function.
  • the Enclave can decrypt the encrypted private key that has been persistently stored (only the Enclave has the decryption authority), and based on the decrypted private key, Perform signature processing on the pending execution result.
  • the above execution result may include other information besides the output result of the above-mentioned to-be-executed code after the execution is completed; that is, the above-mentioned to-be-executed code may be based on actual business requirements
  • Other information besides the output result is also signed as part of the execution result, and then remote authentication is initiated; for example, in one example, the input data of the above code to be executed during execution (such as the code to be executed input during execution Execution parameters), as part of the above execution results, perform signature processing.
  • the untrusted area of the trusted application program can obtain the execution result processed by the above Enclave signature, send the execution result directly to the remote receiving object, and initiate remote certification of the execution result.
  • the trusted area of the trusted application program may directly send the above-mentioned execution result after signature processing to the remote receiving object to initiate remote certification of the execution result.
  • the remote receiving object may verify the signature of the execution result based on the public key based on the public key stored locally (that is, the public key generated by calling the target function); if the If the signature verification is passed, the execution result can be directly regarded as the trusted data generated by the trusted Enclave created on the trusted processor; at this time, the remote proof of the execution result of the code to be executed is completed.
  • the public-private key pair for remote certification is generated autonomously in the target container as a trusted execution environment, it is no longer generated by the software provider; and, the encrypted private The key is set with a decryption strategy that only the target container decrypts; therefore, even the software developer cannot obtain the generated private key, which can significantly improve the security level of the private key;
  • the trusted application since the trusted application only needs to pass the third-party remote certification server, it initiates a remote certification of the publicly generated public key to the remote receiving object, and after the public key passes the remote certification, it can be directly used later
  • the generated private key signs the execution result of the code to be executed in the protected code, and sends the signed execution result to the remote receiving object to complete the remote certification of the execution result, without the need for a third-party remote certification service
  • the remote end initiates remote proof of the execution result to the remote receiving object; therefore, it is no longer necessary to frequently interact with the third-party remote certification server, and it can conveniently receive the object remotely based on the self-generated public and private key pair. Prove that the execution result is reliable data.
  • this specification also provides an embodiment of a remote certification device for trusted applications.
  • the embodiment of the remote certification apparatus of the trusted application program of this specification can be applied to an electronic device.
  • the device embodiments may be implemented by software, or by hardware or a combination of hardware and software. Taking software implementation as an example, as a logical device, it is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory through the processor of the electronic device where it is located.
  • FIG. 2 it is a hardware structure diagram of the electronic equipment where the remote certification device of the trusted application of this specification is located, except for the processor, memory, network interface, and non-
  • the electronic device in which the apparatus is located in the embodiment generally may include other hardware according to the actual function of the electronic device, and details are not described here.
  • Fig. 3 is a block diagram of a device for remote certification of a trusted application program shown in an exemplary embodiment of the present specification.
  • the remote certification device 30 of the trusted application can be applied to the aforementioned electronic device shown in FIG. 2; wherein, the protected code in the trusted application is isolated and loaded as trusted execution In the target container of the environment; the protected code includes the code to be executed, and a target function for generating a private key and a public key;
  • the device 30 includes:
  • the generation module 301 calls the target function to generate a private key and a public key in the target container, encrypts the generated private key, and stores the encrypted private key persistently; wherein, the encrypted private key
  • the key is set with a decryption strategy that is only decrypted by the target container;
  • the certification module 302 initiates remote certification of the public key to the remote receiving object through a third-party remote certification server, and when the public key passes the remote certification, sends the public key to the remote receiving object for persistence Storage
  • the obtaining module 303 obtains the execution result of the code to be executed; wherein the execution result is signed by the target container based on the decrypted private key;
  • the verification module 304 sends the execution result to the remote receiving object to verify the signature of the execution result based on the stored public key by the remote receiving object to confirm whether the execution result is acceptable ⁇ ⁇ Letter data.
  • the generation module 301 the generation module 301:
  • the target function is periodically called to generate a private key and a public key in the target container.
  • the certification module 302 the certification module 302:
  • the trusted execution environment is a trusted execution environment built based on SGX technology; the target container is an Enclave program in SGX technology; wherein, the decryption strategy of the encrypted private key is set keypolicy-MRENCLAVE strategy.
  • the remote receiving object is a smart contract issued to the blockchain.
  • the relevant parts can be referred to the description of the method embodiments.
  • the device embodiments described above are only schematic, wherein the modules described as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules, that is, may be located in One place, or can be distributed to multiple network modules. Some or all of the modules can be selected according to actual needs to achieve the objectives of the solution in this specification. Those of ordinary skill in the art can understand and implement without paying creative labor.
  • the system, device, module or module explained in the above embodiments may be implemented by a computer chip or entity, or by a product with a certain function.
  • a typical implementation device is a computer, and the specific form of the computer may be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email sending and receiving device, and a game control Desk, tablet computer, wearable device, or any combination of these devices.
  • the electronic device includes: a processor and a memory for storing machine-executable instructions; wherein, the processor and the memory are usually connected to each other through an internal bus.
  • the device may also include an external interface to be able to communicate with other devices or components.
  • the protected code in the trusted application is isolated and loaded in the target container as a trusted execution environment; wherein, the protected code includes code to be executed, and is used to generate a private key and The objective function of the public key;
  • the target function to generate a private key and a public key in the target container, and encrypt the generated private key and persistently store the encrypted private key; wherein, the encrypted private key is set A decryption strategy for decryption by the target container only;
  • the target function is periodically called to generate a private key and a public key in the target container.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

一种可信应用程序的远程证明方法，可信应用程序中的受保护代码被隔离加载在作为可信执行环境的目标容器中；受保护代码包括待执行代码，和目标函数；包括：调用所述目标函数在所述目标容器中生成私钥以及公钥，并对生成的私钥进行加密，以及对加密后的私钥进行持久化存储；加密的私钥被设置了仅由目标容器进行解密的解密策略；通过第三方远程证明服务端向远程接收对象发起针对公钥的远程证明，并在公钥通过远程证明时，将公钥发送至远程接收对象进行持久化存储；获取待执行代码的执行结果；该执行结果由目标容器基于解密出的私钥进行了签名；将执行结果发送至远程接收对象，由远程接收对象基于存储的公钥对执行结果的签名进行验证。

Description

可信应用程序的远程证明方法及装置、电子设备 技术领域
本说明书一个或多个实施例涉及区块链技术领域，尤其涉及一种可信应用程序的远程证明方法及装置、电子设备。
背景技术
远程证明(Remote Attestation)，是一种硬件或者软硬件获得远程提供者或生产者的信任的方法，是可信计算的关键技术之一。例如，在实际应用中，可以将可信应用程序中的受保护代码在可信执行环境中进行隔离，并且可以基于远程证明技术，在不泄露受保护代码的基础上，向远程接收对象证明这些受保护代码的执行结果为可信数据。
发明内容
本说明书提出一种可信应用程序的远程证明方法，所述可信应用程序中的受保护代码被隔离加载在作为可信执行环境的目标容器中；其中，所述受保护代码包括待执行代码，和用于生成私钥以及公钥的目标函数；所述方法包括：
调用所述目标函数在所述目标容器中生成私钥以及公钥，并对生成的私钥进行加密，以及对加密后的私钥进行持久化存储；其中，加密的所述私钥被设置了仅由所述目标容器进行解密的解密策略；
通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储；
获取所述待执行代码的执行结果；其中，所述执行结果由所述目标容器基于解密出的所述私钥进行了签名处理；
将所述执行结果发送至所述远程接收对象，以由所述远程接收对象基于存储的所述公钥对所述执行结果的签名进行验证，来确认所述执行结果是否为可信数据。
可选的，调用所述目标函数在所述目标容器中生成私钥以及公钥，包括：
响应于所述待执行代码的执行指令，调用所述目标函数在所述目标容器中生成私钥以及公钥；或者，
基于预设的调用周期，周期性调用所述目标函数在所述目标容器中生成私钥以及公钥。
可选的，通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储，包括：
基于生成的所述公钥创建远程证明凭证；
将所述远程证明凭证发送至所述第三方远程证明服务端，以由所述远程证明服务端对所述远程证明凭证进行验证；
获取所述远程证明服务端返回的验证结果；其中，所述验证结果由所述远程证明服务端基于持有的私钥进行了签名处理；
将所述验证结果以及生成的所述公钥发送至所述远程接收对象，以由所述远程接收对象至少基于所述第三方远程证明服务端的公钥对所述验证结果的签名进行验证，并在所述签名验证通过后，将生成的所述公钥在所述远程接收对象本地进行持久化存储。
可选的，所述可信执行环境为基于SGX技术搭建的可信执行环境；所述目标容器为SGX技术中的Enclave程序；其中，加密后的所述私钥的解密策略被设置为keypolicy-MRENCLAVE策略。
可选的，所述远程接收对象为发布至区块链的智能合约。
本说明书还提出一种可信应用程序的远程证明装置，所述可信应用程序中的受保护代码被隔离加载在作为可信执行环境的目标容器中；其中，所述受保护代码包括待执行代码，和用于生成私钥以及公钥的目标函数；所述装置包括：
生成模块，调用所述目标函数在所述目标容器中生成私钥以及公钥，并对生成的私钥进行加密，以及对加密后的私钥进行持久化存储；其中，加密的所述私钥被设置了仅由所述目标容器进行解密的解密策略；
证明模块，通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储；
获取模块，获取所述待执行代码的执行结果；其中，所述执行结果由所述目标容器基于解密出的所述私钥进行了签名处理；
验证模块，将所述执行结果发送至所述远程接收对象，以由所述远程接收对象基于存储的所述公钥对所述执行结果的签名进行验证，来确认所述执行结果是否为可信数据。
可选的，所述生成模块：
响应于所述待执行代码的执行指令，调用所述目标函数在所述目标容器中生成私钥以及公钥；或者，
基于预设的调用周期，周期性调用所述目标函数在所述目标容器中生成私钥以及公钥。
可选的，所述证明模块：
基于生成的所述公钥创建远程证明凭证；
将所述远程证明凭证发送至所述第三方远程证明服务端，以由所述远程证明服务端对所述远程证明凭证进行验证；
获取所述远程证明服务端返回的验证结果；其中，所述验证结果由所述远程证明服务端基于持有的私钥进行了签名处理；
将所述验证结果以及生成的所述公钥发送至所述远程接收对象，以由所述远程接收对象至少基于所述第三方远程证明服务端的公钥对所述验证结果的签名进行验证，并在所述签名验证通过后，将生成的所述公钥在所述远程接收对象本地进行持久化存储。
可选的，所述可信执行环境为基于SGX技术搭建的可信执行环境；所述目标容器为SGX技术中的Enclave程序；其中，加密后的所述私钥的解密策略被设置为keypolicy-MRENCLAVE策略。
可选的，所述远程接收对象为发布至区块链的智能合约。
本说明书还提出一种电子设备，包括：
处理器；
用于存储机器可执行指令的存储器；
其中，通过读取并执行所述存储器存储的与基于区块链的可信应用程序的远程证明的控制逻辑对应的机器可执行指令，所述可信应用程序中的受保护代码被隔离加载在作为可信执行环境的目标容器中；其中，所述受保护代码包括待执行代码，和用于生成私钥以及公钥的目标函数；所述处理器被促使：
调用所述目标函数在所述目标容器中生成私钥以及公钥，并对生成的私钥进行加密，以及对加密后的私钥进行持久化存储；其中，加密的所述私钥被设置了仅由所述目标容器进行解密的解密策略；
通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储；
获取所述待执行代码的执行结果；其中，所述执行结果由所述目标容器基于解密出的所述私钥进行了签名处理；
将所述执行结果发送至所述远程接收对象，以由所述远程接收对象基于存储的所述公钥对所述执行结果的签名进行验证，来确认所述执行结果是否为可信数据。
在以上技术方案中，一方面，由于用于远程证明的公私钥对在作为可信执行环境的目标容器中自主生成，不再由软件提供商来生成；并且，持久化存储的加密后的私钥，被设置了仅由该目标容器进行解密的解密策略；因此，即便是软件开发者也无法获取到生成的私钥，从而可以显著提升私钥的安全等级；
另一方面，由于可信应用程序仅需要通过第三方远程证明服务端，向远程接收对象发起一次针对自主生成的公钥的远程证明，并在该公钥通过远程证明之后，后续就可以直接使用生成的私钥对受保护代码中的待执行代码的执行结果进行签名，并将签名后的执行结果发送给远程接收对象完成针对该执行结果的远程证明，而不再需要通过第三方远程证明服务端来向远程接收对象发起针对该执行结果的远程证明；因此，可以不再需要与第三方远程证明服务端进行频繁的交互，就可以基于自主生成的公私钥对就可以便捷的向远程接收对象证明该执行结果为可信数据。
附图说明
图1是一示例性实施例提供的一种可信应用程序的远程证明方法的流程图。
图2是一示例性实施例提供的一种电子设备的结构示意图。
图3是一示例性实施例提供的一种可信应用程序的远程证明装置的框图。
具体实施方式
在实际应用中，通常可以通过搭建TEE(Trusted Execution Environment，可信执行环境)，并将可信应用程序中的受保护代码，在TEE中进行隔离，来实现对这些受保 护代码的安全防护。
其中，在搭建TEE时，通常可以将设备底层的处理器作为硬件支撑，来搭建一个仅能由处理器来访问的容器(container)作为可信执行环境，并将可信应用程序中的受保护代码隔离加载在该容器中，以对容器中的受保护代码进行隔离保护。
例如，以利用Intel的SGX(Software Guard Extensions,软件保护扩展)技术来搭建TEE为例，基于SGX技术，通常会将设备的CPU作为硬件支撑，来创建称之为Enclave的程序作为保护容器，并将需要受到保护的代码隔离加载在Enclave程序中，保护其不受到攻击。
而在一些场景下，上述可信应用程序中的受保护代码的执行结果，如果需要参与远程的可信计算，则该可信应用程序除了需要将上述受保护代码的执行结果发送给远程接收对象以外，通常还需要基于远程证明技术，在不泄露受保护代码的基础上，向远程接收对象证明这些受保护代码的执行结果为可信数据。
例如，在一个场景下，假设部署在区块链上的智能合约需要将可信应用程序中的受保护代码的执行结果作为输入数据，在区块链上进行可信计算；在这种情况下，由于可信应用程序并不是链上节点，对于智能合约来说是非授信的一方；因此，可信应用程序在将受保护代码的执行结果发送给部署在区块链上的智能合约时，则需要依靠远程证明技术，在不泄露受保护代码的基础上，向智能合约证明这些受保护代码的执行结果为可信数据(即链上证明)。
而基于目前的远程证明技术，可信应用程序向远程接收对象发起针对特定数据的远程证明时，通常需要依赖第三方远程证明服务端来完成；
例如，仍然以Intel的SGX技术中的远程证明机制为例，基于SGX技术，Intel会提供用于远程证明的第三方的IAS(intel attestation service，因特认证服务)服务器。隔离加载在Enclave中的受保护代码的执行结果，如果需要参与可信计算，则可信应用程序可以与IAS服务器进行交互，通过IAS服务器向远程接收对象发起针对该受保护代码的执行结果的远程认证，向远程接收对象证明该受保护代码的执行结果为可信数据。
由于依赖第三方远程证明服务端来完成远程证明，需要与第三方远程证明服务端进行频繁交互，因此需要一种更加便捷的远程证明机制。
基于此，本说明书提出一种基于作为可信执行环境的容器独立生成的公私钥对，来便捷向远程接收对象发起对受保护代码的执行结果的远程证明方案。
在实现时，可信应用程序的软件开发者，可以基于特定的TEE搭建技术(比如，采用Intel的SGX技术)，来开发作为TEE的目标容器(比如，SGX技术中的Enclave程序)，并将可信应用程序中的受保护代码隔离加载在该目标容器中。
其中，在本方案中，隔离加载在上述目标容器中的受保护代码，可以包括执行结果需要向远程接收方进行远程证明的待执行代码，和用于生成私钥以及公钥的目标函数(本质上是一些生成私钥公钥的特殊代码)。
进一步的，可信应用程序可以调用隔离加载在上述目标容器中的受保护代码中的目标函数，在目标容器中生成一对公钥和私钥；
一方面，对于生成的私钥，还可以在目标容器中进行加密处理；其中，在目标容器中对生成的私钥进行加密时，可以为加密后的私钥设置仅由该目标容器进行解密的解密策略(即仅该目标容器具有解密权限)；然后，由处理器将加密后的私钥进行持久化存储。
另一方面，对于生成的公钥，可以通过第三方远程证明服务端，向远程接受对象发起针对该公钥的远程证明，并在该公钥通过远程证明时，将生成的该公钥发送至远程接收对象，由远程接收对象进行持久化存储。
后续，当上述待执行代码执行完毕，上述目标容器可以对上述加密的私钥进行解密，基于该私钥对该待执行代码的执行结果进行签名处理。而可信应用程序可以获取由上述目标容器签名处理后的执行结果，并将该执行结果发送至远程接收对象，来发起针对该执行结果的远程证明。
远程接收对象在接收到可信应用程序发送的执行结果后，可以基于已经存储的公钥，对该执行结果的签名进行验证，来确定该执行结果是否为可信数据。
在以上技术方案中，一方面，由于用于远程证明的公私钥对在作为可信执行环境的目标容器中自主生成，不再由软件提供商来生成；并且，持久化存储的加密后的私钥，被设置了仅由该目标容器进行解密的解密策略；因此，即便是软件开发者也无法获取到生成的私钥，从而可以显著提升私钥的安全等级；
另一方面，由于可信应用程序仅需要通过第三方远程证明服务端，向远程接收对象发起一次针对自主生成的公钥的远程证明，并在该公钥通过远程证明之后，后续就可以直接使用生成的私钥对受保护代码中的待执行代码的执行结果进行签名，并将签名后的执行结果发送给远程接收对象完成针对该执行结果的远程证明，而不再需要通过第三方 远程证明服务端来向远程接收对象发起针对该执行结果的远程证明；因此，可以不再需要与第三方远程证明服务端进行频繁的交互，就可以基于自主生成的公私钥对就可以便捷的向远程接收对象证明该执行结果为可信数据。
下面通过具体实施例并结合具体的应用场景对本说明书进行描述。
请参考图1，图1是本说明书一实施例提供的一种可信应用程序的远程证明方法，应用于可信应用程序；所述可信应用程序中的受保护代码被隔离加载在作为可信执行环境的目标容器中；其中，所述受保护代码包括待执行代码，和用于生成私钥以及公钥的目标函数；所述方法执行以下步骤：
步骤102，调用所述目标函数在所述目标容器中生成私钥以及公钥，并对生成的私钥进行加密，以及对加密后的私钥进行持久化存储；其中，加密的所述私钥被设置了仅由所述目标容器进行解密的解密策略；
步骤104，通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储；
步骤106，获取所述待执行代码的执行结果；其中，所述执行结果由所述目标容器基于解密出的所述私钥进行了签名处理；
步骤108，将所述执行结果发送至所述远程接收对象，以由所述远程接收对象基于存储的所述公钥对所述执行结果的签名进行验证，来确认所述执行结果是否为可信数据。
上述可信应用程序，包括由软件开发者开发的能够向第三方提供可信服务的应用程序；其中，可信应用程序中的程序代码，通常包括受保护部分，和不受保护。
上述目标容器，在本说明书泛指基于特定的TEE搭建技术，搭建出的一个能够为可信应用程序中的受保护代码提供安全保护的隔离的安全运行环境；
其中，在实际应用中，上述目标容器可以是一个以处理器作为底层硬件支撑，且仅能由处理器进行访问的隔离的软件环境；例如，以采用Intel的SGX技术搭建TEE为例，上述目标容器具体可以是SGX技术中的Enclave程序，通常将可信应用程序中的受保护代码隔离加载到Enclave程序中，来对上述受保护代码进行安全防护。
当然，在实际应用中，也不排除上述目标容器具体也可以是一个在物理上隔离的硬件环境；比如，上述目标容器具体可以是一个在物理上隔离的物理芯片，可以将可信应 用程序中的受保护代码隔离加载在该物理芯片中，来对上述受保护代码进行安全防护。
其中，需要强调的是，搭建TEE所采用的TEE搭建技术，在本说明书中不进行特别限定，本领域技术人员可以基于实际的开发需求来灵活的选择。不难理解的是，上述目标容器的具体形态，通常也取决于本领域技术人员所采用的TEE搭建技术；也即，上述目标容器最终是一个隔离的软件环境，还是一个隔离的硬件环境，取决于本领域技术人员所采用的TEE搭建技术；例如，如果本领域技术人员采用Intel的SGX技术来搭建TEE，则上述目标容器是一个以CPU作为底层硬件支撑，且仅能由CPU进行访问的隔离的软件环境(即Enclave程序)。
上述远程接收对象，具体是指可信应用程序中的受保护代码的执行结果的远程数据使用方；例如，在实际应用中，上述远程接收对象可以是一个独立的可信主机、可信系统；或者，也可以是一个在区块链上部署的智能合约。
在以下实施例中，将以基于Intel的SGX技术来搭建TEE为例进行说明；其中，需要强调的是，以基于Intel的SGX技术来搭建TEE为例，仅为示意性的；显而易见的，在实际应用中，显然也可以采用其它的TEE搭建技术，来搭建TEE；比如，还可以采用诸如ARM的TrustZone技术，在本说明书中不在进行一一列举。
在本说明书中，可信应用程序的软件开发者，可以基于Intel的SGX技术，来创建作为TEE的Enclave程序，并将可信应用程序中的受保护代码隔离加载在该目标容器中。
需要说明的是，基于SGX技术创建Enclave程序，以及将受保护代码隔离加载在该目标容器中的具体实现过程，在本说明书中不再进行详细说明，本领域技术护人员在将本说明书的技术方案付诸实现时，可以参考相关技术中的记载。
对于隔离加载在该Enclave程序中的受保护代码，通常称之为该可信应用程序的可信区(Trusted Part)；而其它未被隔离加载在Enclave程序中的代码,则称之为该可信应用程序的非可信区(Untrusted Part)。
其中，对于隔离加载在上述Enclave程序中的受保护代码，至少可以包括待执行代码和目标函数两部分；
上述待执行代码，即为执行结果需要发送给远程接收对象进行可信计算的受保护代码；也即，可信应用程序需要通过可信证明技术，向远程接收对象证明上述待执行代码的执行结果为可信数据。而上述目标函数，具体用于为上述目标容器生成公钥和私钥。
在SGX技术中，可信应用程序向远程接收对象发起对受保护代码的执行结果的远程 证明，通常是通过与部署的IAS服务器进行交互来完成的。
而本说明书中，可以不再利用SGX技术中现有的远程证明机制，通过与IAS服务器进行交互，来向远程接收对象发起对受保护代码的执行结果的远程证明，而是仅利用SGX技术中现有的远程证明机制，向远程接收对象发起一次对在Enclave程序内部独立生成的公私钥对的远程证明，而后可以在上述公私钥对的远程证明通过后，基于上述公私钥对，来便捷向远程接收对象发起对受保护代码的执行结果的远程证明，而不再需要与IAS进行交互。
在初始状态下，可信应用程序的非可信区，可以通过ECALL的方式，调用隔离加载在该Enclave程序中的受保护代码中的目标函数，在Enclave程序内部生成一对公钥以及私钥。
其中，需要说明的是，非可信区通过ECALL的方式，针对隔离加载在该Enclave程序中的受保护代码中的目标函数的调用，可以在执行受保护代码中的待执行代码时实时的调用，也可以基于一定的调用周期，来周期性的调用。
例如，在一种实现方式中，非可信区在接收到针对受保护代码中的待执行代码的执行指令时，可以实时响应该执行指令，立即通过ECALL的方式，调用隔离加载在该Enclave程序中的受保护代码中的目标函数，在Enclave内部生成一对公钥和私钥。
在另一种实现方式中，也可以为非可信区预先设定一个调用周期，使得非可信区可以基于该调用周期，来周期性调用隔离加载在该Enclave程序中的受保护代码中的目标函数，在Enclave程序内部生成一对公钥和私钥。通过这种方式，可以定时的对Enclave程序的公钥和私钥进行更新。
一方面，对于生成的私钥，可以由处理器在Enclave程序内部进行加密处理(密钥由处理器持有)，并由处理器为加密后的私钥设置解密策略，然后将加密后的私钥进行持有化存储；
其中，基于SGX技术，针对加密后的信息的解密策略，通常包括keypolicy-MRENCLAVE(以下简称MRENCLAVE策略)和keypolicy-MRSIGNER(以下简称MRSIGNER)两种策略。
所谓MRENCLAVE策略，是指仅仅可被当前的ENCLAVE解密；而所谓MRSIGNER策略，是指可以被同一开发者开发和签署的所有ENCLAVE进行解密。
由于采用MRSIGNER策略，需要信任开发者；因此，对于获取到开发者的私钥的 恶意者而言，通过开发恶意的ENCLAVE，并基于掌握的开发者的私钥对该恶意的ENCLAVE进行签署，就可以通过该恶意的ENCLAVE对加密后的私钥进行解密，从而导致加密后的私钥的明文数据泄露。
基于此，在本说明书中，处理器在为加密后的私钥设置解密策略时，可以将解密策略设置为MRENCLAVE策略；即，仅当前的ENCLAVE具有对持久化存储的加密后的私钥进行解密的权限。
通过这种方式，可以确保即便是软件开发者也无法获取到ENCLAVE独立生成的私钥，从而可以显著提升私钥的安全等级。
另一方面，对于生成的公钥，可以由可信执行程序的可信区通过IAS服务器，向远程接受对象发起针对该公钥的远程证明，并在该公钥通过远程证明时，将生成的该公钥发送至远程接收对象，由远程接收对象进行持久化存储。
基于SGX技术，可信执行程序的可信区，向远程接受对象发起针对该公钥的远程证明时，首先可以基于生成的公钥或者公钥的hash值，创建一个作为远程证明凭证的Quote；
例如，基于SGX技术，上述Quote通常是由Enclave和一个特殊的Quote Enclave进行内部交互，由Quote Enclave来创建完成的。其中，由Quote Enclave为Enclave创建用于远程证明的Quote的具体实施过程，在本说明书中不在进行详述，本领域技术人员在将本说明书的技术方案辅助时间时，可以参考相关技术中的技术。
在本说明书中，最终创建完成的Quote，通过可以包括EPID签名、生成的公钥或者公钥的hash值(即需要远程证明的userdata)、MRENCLAVE标识、处理器的EPID标识等信息。
也即，最终创建完成的Quote，是针对生成的公钥或者公钥的hash值(即需要远程证明的userdata)、MRENCLAVE标识、处理器的EPID标识等信息整体进行EPID签名后得到的信息。
其中，MRENCLAVE标识，通常为Enclave代码的hash值，用于唯一标识一个Enclave。EPID标识，也称之为basename，用于匿名标识一个处理器。而EPID签名，是Intel的SGX技术采用的一种可以保持匿名的群签名技术，在本说明书中对于EPID签名的签名处理过程，以及EPID签名的签名验证过程，不再进行详述，本领域技术人员可以参考相关技术中的记载。
在本说明书中，当生成了作为远程证明凭证的Quote之后，可信执行程序的可 信区，可以将该Quote发送给IAS服务器进行远程验证。而IAS服务器收到该Quote之后，可以对该Quote的EPID签名进行验证，然后基于IAS服务器持有的私钥，对该Quote和针对该Quote的验证结果整体进行签名处理，生成对应的AVR(Attestation Verification Report，证明验证报告)。
也即，在本说明书中，上述AVR通常可以包括上述Quote、Quote验证结果和IAS签名等信息。
在本说明书中，IAS服务器可以将生成的AVR返回给可信执行程序的可信区，可信执行程序的可信区在收到IAS服务器返回的AVR后，可以将该AVR以及通过调用上述目标函数生成的公钥，进一步发送给远程接收对象。
或者，可信执行程序的可信区也可以将该AVR以及通过调用上述目标函数生成的公钥，进一步发送给可信执行程序的非可信区，由上述非可信区将该AVR以及通过调用上述目标函数生成的公钥，进一步发送给远程接收对象。
而远程接收对象在收到可信执行程序的可信区发送的AVR之后，首先可以对AVR的状态进行验证；比如验证AVR中的状态字段的取值是否为指示该AVR状态正常的特定值；当AVR的状态验证通过之后，可以基于IAS服务器持有的私钥对应的公钥，对该AVR的IAS签名进行验证；如果签名验证通过，此时可以进一步针对该AVR中携带的Quote中的公钥或者公钥的hash值、MRENCLAVE标识、处理器的EPID标识等信息进行验证。
其中，对Quote中的公钥或者公钥的hash值进行的验证，即为验证Quote中的公钥或者公钥的hash值，与可信执行程序的可信区发送的公钥是否匹配的过程；比如，如果Quote中携带的是公钥的hash值，则可以进一步计算可信执行程序的可信区发送的公钥的hash值，然后将计算出的hash值，与Quote中携带的公钥的hash值进行匹配；如果二者匹配，则可以确认验证通过。
其中，对Quote中的MRENCLAVE标识和处理器的EPID等信息进行的验证，即为验证与MRENCLAVE标识对应Enclave，以及验证与处理器的EPID对应的处理器是否可信的过程。
在实现时，Enclave的开发者可以通过开源Enclave代码来证明Enclave代码中不包含恶意代码，而远程接收对象的管理员，可以对开源的Enclave代码进行安全审计，为远程接收对象设置MRENCLAVE白名单。同样，也可以按照实际需求，为远程接收 对象设置EPID标识白名单。从而，远程接收对象在对Quote中的MRENCLAVE标识和处理器的EPID标识等信息进行验证时，可以通过将Quote中的MRENCLAVE标识与MRENCLAVE白名单进行匹配，以及将Quote中的处理器的EPID标识与EPID标识白名单进行匹配，来确认与MRENCLAVE标识对应Enclave，以及与处理器的EPID对应的处理器是否可信。
请继续参见图2，当AVR的IAS签名；以及该AVR中携带的Quote中的公钥或者公钥的hash值、MRENCLAVE标识、处理器的EPID标识等信息均验证通过之后，远程接收对象可以将可信执行程序的可信区发送的通过调用上述目标函数生成的上述公钥，以及对应的MRENCLAVE和EPID在本地进行持久化存储。
也即，将与调用上述目标函数生成的上述公钥对应的MRENCLAVE作为可信程序标识，将与上述公钥对应的EPID作为可信硬件标识，与上述公钥一起进行持久化存储。
在本说明书，当上述远程接收对象将通过调用上述目标函数生成的上述公钥在其本地进行持久化存储之后，后续上述可信应用程序可以不再需要与IAS服务器进行交互，来发起针对上述待执行代码的执行结果的远程证明，而是直接通过调用上述目标函数创建的上述公私钥对，来便捷向远程接收对象发起对受保护代码的执行结果的远程证明。
具体地，当隔离加载在上述Enclave中的待执行代码执行完毕，上述Enclave可以对已经持久化存储的加密后的私钥进行解密(只有该Enclave具有解密权限)，并基于解密出的私钥，对该待的执行结果进行签名处理。
其中，需要说明的是，实际应用中，上述执行结果除了可以包括上述待执行代码在执行完毕后的输出结果以外，也可以引入其它的信息；即可以根据实际的业务需求，将上述待执行代码的输出结果以外的其它信息也作为执行结果的一部分进行签名处理，然后发起远程认证；例如，在一个例子中，可以将上述待执行代码在执行时的输入数据(比如待执行代码在执行时输入的执行参数)，也作为上述执行结果的一部分，进行签名处理。
而可信应用程序的非可信区，可以获取由上述Enclave签名处理后的执行结果，将该执行结果直接发送给远程接收对象，发起针对该执行结果的远程证明。
当然，在实际应用中，也可以由可信应用程序的可信区，直接将签名处理后的 上述执行结果发送给远程接收对象，发起针对该执行结果的远程证明。
而远程接收对象在收到该执行结果后，可以基于在本地持久化存储的上述公钥(即调用上述目标函数生成的公钥)，基于该公钥对该执行结果的签名进行验证；如果该签名验证通过，则可以直接认定该执行结果为，在可信的处理器上创建的可信的Enclave所生成的可信数据；此时针对上述待执行代码的执行结果的远程证明完成。
通过这种方式，在向远程接收对象对上述待执行代码的执行结果进行远程证明时，可以不再需要与IAS服务器进行交互，从而可以更加便捷的完成远程证明。
在以上技术方案中，一方面，由于用于远程证明的公私钥对在作为可信执行环境的目标容器中自主生成，不再由软件提供商来生成；并且，持久化存储的加密后的私钥，被设置了仅由该目标容器进行解密的解密策略；因此，即便是软件开发者也无法获取到生成的私钥，从而可以显著提升私钥的安全等级；
另一方面，由于可信应用程序仅需要通过第三方远程证明服务端，向远程接收对象发起一次针对自主生成的公钥的远程证明，并在该公钥通过远程证明之后，后续就可以直接使用生成的私钥对受保护代码中的待执行代码的执行结果进行签名，并将签名后的执行结果发送给远程接收对象完成针对该执行结果的远程证明，而不再需要通过第三方远程证明服务端来向远程接收对象发起针对该执行结果的远程证明；因此，可以不再需要与第三方远程证明服务端进行频繁的交互，就可以基于自主生成的公私钥对就可以便捷的向远程接收对象证明该执行结果为可信数据。
与上述方法实施例相对应，本说明书还提供了一种可信应用程序的远程证明装置的实施例。本说明书的可信应用程序的远程证明装置的实施例可以应用在电子设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在电子设备的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图2所示，为本说明书的可信应用程序的远程证明装置所在电子设备的一种硬件结构图，除了图2所示的处理器、内存、网络接口、以及非易失性存储器之外，实施例中装置所在的电子设备通常根据该电子设备的实际功能，还可以包括其他硬件，对此不再赘述。
图3是本说明书一示例性实施例示出的一种可信应用程序的远程证明装置的框图。
请参考图3，所述可信应用程序的远程证明装置30可以应用在前述图2所示的 电子设备中；其中，所述可信应用程序中的受保护代码被隔离加载在作为可信执行环境的目标容器中；所述受保护代码包括待执行代码，和用于生成私钥以及公钥的目标函数；
所述装置30包括：
生成模块301，调用所述目标函数在所述目标容器中生成私钥以及公钥，并对生成的私钥进行加密，以及对加密后的私钥进行持久化存储；其中，加密的所述私钥被设置了仅由所述目标容器进行解密的解密策略；
证明模块302，通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储；
获取模块303，获取所述待执行代码的执行结果；其中，所述执行结果由所述目标容器基于解密出的所述私钥进行了签名处理；
验证模块304，将所述执行结果发送至所述远程接收对象，以由所述远程接收对象基于存储的所述公钥对所述执行结果的签名进行验证，来确认所述执行结果是否为可信数据。
在本实施例中，所述生成模块301：
响应于所述待执行代码的执行指令，调用所述目标函数在所述目标容器中生成私钥以及公钥；或者，
基于预设的调用周期，周期性调用所述目标函数在所述目标容器中生成私钥以及公钥。
在本实施例中，所述证明模块302：
基于生成的所述公钥创建远程证明凭证；
将所述远程证明凭证发送至所述第三方远程证明服务端，以由所述远程证明服务端对所述远程证明凭证进行验证；
获取所述远程证明服务端返回的验证结果；其中，所述验证结果由所述远程证明服务端基于持有的私钥进行了签名处理；
将所述验证结果以及生成的所述公钥发送至所述远程接收对象，以由所述远程接收对象至少基于所述第三方远程证明服务端的公钥对所述验证结果的签名进行验证，并在所述签名验证通过后，将生成的所述公钥在所述远程接收对象本地进行持久化存储。
在本实施例中，所述可信执行环境为基于SGX技术搭建的可信执行环境；所述目标容器为SGX技术中的Enclave程序；其中，加密后的所述私钥的解密策略被设置为keypolicy-MRENCLAVE策略。
在本实施例中，所述远程接收对象为发布至区块链的智能合约。
上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。
对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
上述实施例阐明的系统、装置、模块或模块，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机，计算机的具体形式可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任意几种设备的组合。
与上述方法实施例相对应，本说明书还提供了一种电子设备的实施例。该电子设备包括：处理器以及用于存储机器可执行指令的存储器；其中，处理器和存储器通常通过内部总线相互连接。在其他可能的实现方式中，所述设备还可能包括外部接口，以能够与其他设备或者部件进行通信。
在本实施例中，所述可信应用程序中的受保护代码被隔离加载在作为可信执行环境的目标容器中；其中，所述受保护代码包括待执行代码，和用于生成私钥以及公钥的目标函数；
通过读取并执行所述存储器存储的与可信应用程序的远程证明的控制逻辑对应的机器可执行指令，所述处理器被促使：
调用所述目标函数在所述目标容器中生成私钥以及公钥，并对生成的私钥进行加密，以及对加密后的私钥进行持久化存储；其中，加密的所述私钥被设置了仅由所述目标容器进行解密的解密策略；
通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储；
获取所述待执行代码的执行结果；其中，所述执行结果由所述目标容器基于解密出的所述私钥进行了签名处理；
将所述执行结果发送至所述远程接收对象，以由所述远程接收对象基于存储的所述公钥对所述执行结果的签名进行验证，来确认所述执行结果是否为可信数据。
在本实施例中，通过读取并执行所述存储器存储的与可信应用程序的远程证明的控制逻辑对应的机器可执行指令，所述处理器被促使：
响应于所述待执行代码的执行指令，调用所述目标函数在所述目标容器中生成私钥以及公钥；或者，
基于预设的调用周期，周期性调用所述目标函数在所述目标容器中生成私钥以及公钥。
在本实施例中，通过读取并执行所述存储器存储的与可信应用程序的远程证明的控制逻辑对应的机器可执行指令，所述处理器被促使：
基于生成的所述公钥创建远程证明凭证；
将所述远程证明凭证发送至所述第三方远程证明服务端，以由所述远程证明服务端对所述远程证明凭证进行验证；
获取所述远程证明服务端返回的验证结果；其中，所述验证结果由所述远程证明服务端基于持有的私钥进行了签名处理；
将所述验证结果以及生成的所述公钥发送至所述远程接收对象，以由所述远程接收对象至少基于所述第三方远程证明服务端的公钥对所述验证结果的签名进行验证，并在所述签名验证通过后，将生成的所述公钥在所述远程接收对象本地进行持久化存储。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本说明书的真正范围和精神由下面的权利要求指出。
应当理解的是，本说明书并不局限于上面已经描述并在附图中示出的精确结构， 并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。
以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。

Claims (11)

  1. 一种可信应用程序的远程证明方法，所述可信应用程序中的受保护代码被隔离加载在作为可信执行环境的目标容器中；其中，所述受保护代码包括待执行代码，和用于生成私钥以及公钥的目标函数；所述方法包括：
    调用所述目标函数在所述目标容器中生成私钥以及公钥，并对生成的私钥进行加密，以及对加密后的私钥进行持久化存储；其中，加密的所述私钥被设置了仅由所述目标容器进行解密的解密策略；
    通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储；
    获取所述待执行代码的执行结果；其中，所述执行结果由所述目标容器基于解密出的所述私钥进行了签名处理；
    将所述执行结果发送至所述远程接收对象，以由所述远程接收对象基于存储的所述公钥对所述执行结果的签名进行验证，来确认所述执行结果是否为可信数据。
  2. 根据权利要求1所述的方法，调用所述目标函数在所述目标容器中生成私钥以及公钥，包括：
    响应于所述待执行代码的执行指令，调用所述目标函数在所述目标容器中生成私钥以及公钥；或者，
    基于预设的调用周期，周期性调用所述目标函数在所述目标容器中生成私钥以及公钥。
  3. 根据权利要求1所述的方法，通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储，包括：
    基于生成的所述公钥创建远程证明凭证；
    将所述远程证明凭证发送至所述第三方远程证明服务端，以由所述远程证明服务端对所述远程证明凭证进行验证；
    获取所述远程证明服务端返回的验证结果；其中，所述验证结果由所述远程证明服务端基于持有的私钥进行了签名处理；
    将所述验证结果以及生成的所述公钥发送至所述远程接收对象，以由所述远程接收对象至少基于所述第三方远程证明服务端的公钥对所述验证结果的签名进行验证，并在所述签名验证通过后，将生成的所述公钥在所述远程接收对象本地进行持久化存储。
  4. 根据权利要求1所述的方法，所述可信执行环境为基于SGX技术搭建的可信执 行环境；所述目标容器为SGX技术中的Enclave程序；其中，加密后的所述私钥的解密策略被设置为keypolicy-MRENCLAVE策略。
  5. 根据权利要求1所述的方法，所述远程接收对象为发布至区块链的智能合约。
  6. 一种可信应用程序的远程证明装置，所述可信应用程序中的受保护代码被隔离加载在作为可信执行环境的目标容器中；其中，所述受保护代码包括待执行代码，和用于生成私钥以及公钥的目标函数；所述装置包括：
    生成模块，调用所述目标函数在所述目标容器中生成私钥以及公钥，并对生成的私钥进行加密，以及对加密后的私钥进行持久化存储；其中，加密的所述私钥被设置了仅由所述目标容器进行解密的解密策略；
    证明模块，通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储；
    获取模块，获取所述待执行代码的执行结果；其中，所述执行结果由所述目标容器基于解密出的所述私钥进行了签名处理；
    验证模块，将所述执行结果发送至所述远程接收对象，以由所述远程接收对象基于存储的所述公钥对所述执行结果的签名进行验证，来确认所述执行结果是否为可信数据。
  7. 根据权利要求6所述的装置，所述生成模块：
    响应于所述待执行代码的执行指令，调用所述目标函数在所述目标容器中生成私钥以及公钥；或者，
    基于预设的调用周期，周期性调用所述目标函数在所述目标容器中生成私钥以及公钥。
  8. 根据权利要求6所述的装置，所述证明模块：
    基于生成的所述公钥创建远程证明凭证；
    将所述远程证明凭证发送至所述第三方远程证明服务端，以由所述远程证明服务端对所述远程证明凭证进行验证；
    获取所述远程证明服务端返回的验证结果；其中，所述验证结果由所述远程证明服务端基于持有的私钥进行了签名处理；
    将所述验证结果以及生成的所述公钥发送至所述远程接收对象，以由所述远程接收对象至少基于所述第三方远程证明服务端的公钥对所述验证结果的签名进行验证，并在所述签名验证通过后，将生成的所述公钥在所述远程接收对象本地进行持久化存储。
  9. 根据权利要求6所述的装置，所述可信执行环境为基于SGX技术搭建的可信执 行环境；所述目标容器为SGX技术中的Enclave程序；其中，加密后的所述私钥的解密策略被设置为keypolicy-MRENCLAVE策略。
  10. 根据权利要求6所述的装置，所述远程接收对象为发布至区块链的智能合约。
  11. 一种电子设备，包括：
    处理器；
    用于存储机器可执行指令的存储器；
    其中，通过读取并执行所述存储器存储的与基于区块链的可信应用程序的远程证明的控制逻辑对应的机器可执行指令，所述可信应用程序中的受保护代码被隔离加载在作为可信执行环境的目标容器中；其中，所述受保护代码包括待执行代码，和用于生成私钥以及公钥的目标函数；所述处理器被促使：
    调用所述目标函数在所述目标容器中生成私钥以及公钥，并对生成的私钥进行加密，以及对加密后的私钥进行持久化存储；其中，加密的所述私钥被设置了仅由所述目标容器进行解密的解密策略；
    通过第三方远程证明服务端向远程接收对象发起针对所述公钥的远程证明，并在所述公钥通过远程证明时，将所述公钥发送至所述远程接收对象进行持久化存储；
    获取所述待执行代码的执行结果；其中，所述执行结果由所述目标容器基于解密出的所述私钥进行了签名处理；
    将所述执行结果发送至所述远程接收对象，以由所述远程接收对象基于存储的所述公钥对所述执行结果的签名进行验证，来确认所述执行结果是否为可信数据。
PCT/CN2019/106607 2018-11-16 2019-09-19 可信应用程序的远程证明方法及装置、电子设备 WO2020098377A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811364461.1A CN110011801B (zh) 2018-11-16 2018-11-16 可信应用程序的远程证明方法及装置、电子设备
CN201811364461.1 2018-11-16

Publications (1)

Publication Number Publication Date
WO2020098377A1 true WO2020098377A1 (zh) 2020-05-22

Family

ID=67164919

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/106607 WO2020098377A1 (zh) 2018-11-16 2019-09-19 可信应用程序的远程证明方法及装置、电子设备

Country Status (3)

Country Link
CN (2) CN110011801B (zh)
TW (1) TWI716078B (zh)
WO (1) WO2020098377A1 (zh)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114090981A (zh) * 2021-11-29 2022-02-25 深圳前海微众银行股份有限公司 一种针对远程主机的访问方法及装置
CN114422215A (zh) * 2021-12-31 2022-04-29 国网安徽省电力有限公司合肥供电公司 一种基于区块链的跨平台和可信能源数据共享系统及方法
CN114900320A (zh) * 2022-06-21 2022-08-12 杭州安恒信息安全技术有限公司 一种tee节点认证方法、装置、设备及介质
CN115001744A (zh) * 2022-04-27 2022-09-02 中国科学院信息工程研究所 一种云平台数据完整性验证方法及系统
CN115276982A (zh) * 2022-07-29 2022-11-01 武汉科技大学 一种基于sgx的以太坊密钥管理方法及系统
CN115484031A (zh) * 2022-09-13 2022-12-16 山东大学 基于sgx的无可信第三方云存储密文去重方法及系统
CN116112187A (zh) * 2023-04-10 2023-05-12 山东海量信息技术研究院 一种远程证明方法、装置、设备及可读存储介质
WO2023116147A1 (zh) * 2021-12-23 2023-06-29 支付宝(杭州)信息技术有限公司 获取数据授权的方法、装置及系统
CN117493344A (zh) * 2023-11-09 2024-02-02 兰州大学 一种基于机密计算技术的高效数据组织方法
CN113395159B (zh) * 2021-01-08 2024-03-12 腾讯科技（深圳）有限公司 一种基于可信执行环境的数据处理方法以及相关装置
WO2024120945A1 (fr) * 2022-12-07 2024-06-13 Electricite De France Mécanisme d'autorisation pour l'utilisation d'un procédé logiciel avec sécurisation du code source

Families Citing this family (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110430051B (zh) * 2019-08-01 2022-08-05 北京永新视博数字电视技术有限公司 一种密钥存储方法、装置及服务器
CN110519260B (zh) * 2019-08-23 2020-09-25 联想(北京)有限公司 一种信息处理方法及信息处理装置
CN110838919B (zh) * 2019-11-01 2021-04-13 广州小鹏汽车科技有限公司 通信方法、存储方法、运算方法及装置
CN111049825B (zh) * 2019-12-12 2021-11-30 支付宝(杭州)信息技术有限公司 一种基于可信执行环境的安全多方计算方法和系统
CN110890962B (zh) * 2019-12-20 2021-04-13 支付宝(杭州)信息技术有限公司 认证密钥协商方法、装置、存储介质及设备
CN111382445B (zh) * 2020-03-03 2023-04-07 首都师范大学 利用可信执行环境系统提供可信服务的方法
CN111090888B (zh) * 2020-03-18 2020-07-07 支付宝(杭州)信息技术有限公司 验证合约的方法及装置
CN111092727B (zh) * 2020-03-18 2020-07-17 支付宝(杭州)信息技术有限公司 共享集群密钥的方法及装置
CN111092726B (zh) * 2020-03-18 2020-07-28 支付宝(杭州)信息技术有限公司 生成共享合约密钥的方法及装置
CN111541725B (zh) * 2020-07-08 2021-04-27 支付宝(杭州)信息技术有限公司 区块链一体机及其密码加速卡、密钥管理方法和装置
CN114884647B (zh) * 2021-01-22 2024-02-20 腾讯科技（深圳）有限公司 网络访问管理方法及相关设备
CN112507034B (zh) * 2021-02-07 2021-06-01 支付宝(杭州)信息技术有限公司 一种数据存储方法及系统
CN113343234B (zh) * 2021-06-10 2023-01-20 支付宝(杭州)信息技术有限公司 对代码安全性进行可信检查的方法及装置
CN113672973B (zh) * 2021-07-20 2024-04-16 深圳大学 基于可信执行环境的risc-v架构的嵌入式设备的数据库系统
CN114629639A (zh) * 2022-03-10 2022-06-14 阿里云计算有限公司 基于可信执行环境的密钥管理方法、装置和电子设备
CN114553590B (zh) * 2022-03-17 2023-08-22 抖音视界有限公司 数据传输方法及相关设备
CN114884714B (zh) * 2022-04-26 2024-03-26 北京百度网讯科技有限公司 任务处理方法、装置、设备及存储介质
CN115081000B (zh) * 2022-06-17 2024-06-25 苏州浪潮智能科技有限公司 保护远程目标程序源码的方法、系统、设备和存储介质
CN116846682B (zh) * 2023-08-29 2024-01-23 山东海量信息技术研究院 通信信道建立方法、装置、设备及介质
CN117454437B (zh) * 2023-12-22 2024-03-22 北京天润基业科技发展股份有限公司 交易处理方法、存储介质及电子设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101043338A (zh) * 2007-04-27 2007-09-26 中国科学院软件研究所 基于安全需求的远程证明方法及其系统
CN101908115A (zh) * 2010-07-30 2010-12-08 中国船舶重工集团公司第七○九研究所 基于可信平台模块实现软件可信执行的方法
US20140281500A1 (en) * 2013-03-15 2014-09-18 Ologn Technologies Ag Systems, methods and apparatuses for remote attestation
CN104077533A (zh) * 2014-07-17 2014-10-01 北京握奇智能科技有限公司 一种操作敏感数据的方法和设备
CN104408371A (zh) * 2014-10-14 2015-03-11 中国科学院信息工程研究所 一种基于可信执行环境高安全应用系统的实现方法

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101951388B (zh) * 2010-10-14 2013-03-20 中国电子科技集团公司第三十研究所 一种可信计算环境中的远程证明方法
US9521125B2 (en) * 2014-03-13 2016-12-13 Intel Corporation Pseudonymous remote attestation utilizing a chain-of-trust
US9536093B2 (en) * 2014-10-02 2017-01-03 Microsoft Technology Licensing, Llc Automated verification of a software system
US20160098555A1 (en) * 2014-10-02 2016-04-07 Arm Limited Program code attestation circuitry, a data processing apparatus including such program code attestation circuitry and a program attestation method
US9363087B2 (en) * 2014-10-02 2016-06-07 Microsoft Technology Licensing, Inc. End-to-end security for hardware running verified software
CN104333451A (zh) * 2014-10-21 2015-02-04 广东金赋信息科技有限公司 一种可信自助服务系统
CN104333541A (zh) * 2014-10-21 2015-02-04 广东金赋信息科技有限公司 一种可信自助服务系统
CN105812332A (zh) * 2014-12-31 2016-07-27 北京握奇智能科技有限公司 数据保护方法
US11829998B2 (en) * 2016-06-07 2023-11-28 Cornell University Authenticated data feed for blockchains
US10445698B2 (en) * 2016-06-30 2019-10-15 Clause, Inc. System and method for forming, storing, managing, and executing contracts
US10341116B2 (en) * 2016-12-28 2019-07-02 Intel Corporation Remote attestation with hash-based signatures
US20180241572A1 (en) * 2017-02-22 2018-08-23 Intel Corporation Techniques for remote sgx enclave authentication
DE102018101307A1 (de) * 2017-02-22 2018-08-23 Intel Corporation Techniken für SGX-Enklaven-Fernauthentifizierung
US10397005B2 (en) * 2017-03-31 2019-08-27 Intel Corporation Using a trusted execution environment as a trusted third party providing privacy for attestation
US10833858B2 (en) * 2017-05-11 2020-11-10 Microsoft Technology Licensing, Llc Secure cryptlet tunnel
CN107342858B (zh) * 2017-07-05 2019-09-10 武汉凤链科技有限公司 一种基于可信环境的智能合约保护方法和系统
CN107395366A (zh) * 2017-08-08 2017-11-24 沈阳东青科技有限公司 一种面向工控可信计算平台的高效远程证明方法
CN107463838B (zh) * 2017-08-14 2019-10-18 广州大学 基于sgx的安全监控方法、装置、系统及存储介质
CN107919954B (zh) * 2017-10-20 2019-05-14 浙江大学 一种基于sgx软件防护扩展指令的区块链用户密钥保护方法和装置
CN108055133B (zh) * 2017-12-12 2020-02-14 江苏安凰领御科技有限公司 一种基于区块链技术的密钥安全签名方法
CN107896150A (zh) * 2017-12-21 2018-04-10 善林（上海）金融信息服务有限公司 链接区块链网络和物联网的系统
CN108390866B (zh) * 2018-02-06 2020-10-02 南京航空航天大学 基于双代理双向匿名认证的可信远程证明方法及系统

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101043338A (zh) * 2007-04-27 2007-09-26 中国科学院软件研究所 基于安全需求的远程证明方法及其系统
CN101908115A (zh) * 2010-07-30 2010-12-08 中国船舶重工集团公司第七○九研究所 基于可信平台模块实现软件可信执行的方法
US20140281500A1 (en) * 2013-03-15 2014-09-18 Ologn Technologies Ag Systems, methods and apparatuses for remote attestation
CN104077533A (zh) * 2014-07-17 2014-10-01 北京握奇智能科技有限公司 一种操作敏感数据的方法和设备
CN104408371A (zh) * 2014-10-14 2015-03-11 中国科学院信息工程研究所 一种基于可信执行环境高安全应用系统的实现方法

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113395159B (zh) * 2021-01-08 2024-03-12 腾讯科技（深圳）有限公司 一种基于可信执行环境的数据处理方法以及相关装置
CN114090981A (zh) * 2021-11-29 2022-02-25 深圳前海微众银行股份有限公司 一种针对远程主机的访问方法及装置
WO2023116147A1 (zh) * 2021-12-23 2023-06-29 支付宝(杭州)信息技术有限公司 获取数据授权的方法、装置及系统
CN114422215A (zh) * 2021-12-31 2022-04-29 国网安徽省电力有限公司合肥供电公司 一种基于区块链的跨平台和可信能源数据共享系统及方法
CN115001744B (zh) * 2022-04-27 2023-08-29 中国科学院信息工程研究所 一种云平台数据完整性验证方法及系统
CN115001744A (zh) * 2022-04-27 2022-09-02 中国科学院信息工程研究所 一种云平台数据完整性验证方法及系统
CN114900320A (zh) * 2022-06-21 2022-08-12 杭州安恒信息安全技术有限公司 一种tee节点认证方法、装置、设备及介质
CN114900320B (zh) * 2022-06-21 2024-04-26 杭州安恒信息安全技术有限公司 一种tee节点认证方法、装置、设备及介质
CN115276982A (zh) * 2022-07-29 2022-11-01 武汉科技大学 一种基于sgx的以太坊密钥管理方法及系统
CN115276982B (zh) * 2022-07-29 2024-04-16 武汉科技大学 一种基于sgx的以太坊密钥管理方法及系统
CN115484031B (zh) * 2022-09-13 2024-03-08 山东大学 基于sgx的无可信第三方云存储密文去重方法及系统
CN115484031A (zh) * 2022-09-13 2022-12-16 山东大学 基于sgx的无可信第三方云存储密文去重方法及系统
WO2024120945A1 (fr) * 2022-12-07 2024-06-13 Electricite De France Mécanisme d'autorisation pour l'utilisation d'un procédé logiciel avec sécurisation du code source
FR3143244A1 (fr) * 2022-12-07 2024-06-14 Electricite De France Mécanisme d’autorisation pour l’utilisation d’un procédé logiciel avec sécurisation du code source
CN116112187B (zh) * 2023-04-10 2023-07-14 山东海量信息技术研究院 一种远程证明方法、装置、设备及可读存储介质
CN116112187A (zh) * 2023-04-10 2023-05-12 山东海量信息技术研究院 一种远程证明方法、装置、设备及可读存储介质
CN117493344A (zh) * 2023-11-09 2024-02-02 兰州大学 一种基于机密计算技术的高效数据组织方法

Also Published As

Publication number Publication date
TWI716078B (zh) 2021-01-11
CN112468473A (zh) 2021-03-09
CN110011801A (zh) 2019-07-12
CN112468473B (zh) 2023-10-24
CN110011801B (zh) 2020-10-20
TW202021306A (zh) 2020-06-01

Similar Documents

Publication Publication Date Title
WO2020098377A1 (zh) 可信应用程序的远程证明方法及装置、电子设备
CN111181720B (zh) 基于可信执行环境的业务处理方法及装置
JP7416775B2 (ja) 周辺デバイス
EP3458999B1 (en) Self-contained cryptographic boot policy validation
WO2022073264A1 (en) Systems and methods for secure and fast machine learning inference in trusted execution environment
Anati et al. Innovative technology for CPU based attestation and sealing
TWI701929B (zh) 密碼運算、創建工作密鑰的方法、密碼服務平台及設備
US9768951B2 (en) Symmetric keying and chain of trust
US10855465B2 (en) Audited use of a cryptographic key
US20180131677A1 (en) Balancing public and personal security needs
TW202109320A (zh) 基於可信執行環境的應用程式啟動方法及裝置
JP2010514000A (ja) 電子装置にプログラム状態データをセキュアに記憶するための方法
US20120213370A1 (en) Secure management and personalization of unique code signing keys
US11398906B2 (en) Confirming receipt of audit records for audited use of a cryptographic key
US11405201B2 (en) Secure transfer of protected application storage keys with change of trusted computing base
WO2024139273A1 (zh) 联邦学习方法、装置、可读存储介质及电子设备
WO2022162797A1 (ja) 情報処理装置、プログラム実行システム、情報処理方法、及びプログラム
CA3042984C (en) Balancing public and personal security needs
CN114556344A (zh) 在加密协同处理器中执行针对实体特定的加密代码

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19885985

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19885985

Country of ref document: EP

Kind code of ref document: A1