CN110011801A - Remote certification method and device, the electronic equipment of trusted application - Google Patents
Remote certification method and device, the electronic equipment of trusted application Download PDFInfo
- Publication number
- CN110011801A CN110011801A CN201811364461.1A CN201811364461A CN110011801A CN 110011801 A CN110011801 A CN 110011801A CN 201811364461 A CN201811364461 A CN 201811364461A CN 110011801 A CN110011801 A CN 110011801A
- Authority
- CN
- China
- Prior art keywords
- remote
- public key
- private key
- receiving object
- target container
- Prior art date
- Legal status (The legal status 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 status listed.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 33
- 230000002085 persistent effect Effects 0.000 claims abstract description 22
- 230000006870 function Effects 0.000 claims description 51
- 238000012795 verification Methods 0.000 claims description 48
- 238000005516 engineering process Methods 0.000 claims description 44
- 230000000977 initiatory effect Effects 0.000 claims description 11
- 230000008569 process Effects 0.000 description 6
- 238000010586 diagram Methods 0.000 description 5
- 230000003993 interaction Effects 0.000 description 5
- 238000012545 processing Methods 0.000 description 5
- 238000002955 isolation Methods 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 238000010276 construction Methods 0.000 description 3
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000006978 adaptation Effects 0.000 description 1
- 238000012550 audit Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000004891 communication Methods 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
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
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
A kind of remote certification method of trusted application, the protected code in trusted application are isolated load in the target container as credible performing environment；Protected code includes pending code and objective function；It include: to call the objective function to generate private key and public key in the target container, and encrypt to the private key of generation, and carry out persistent storage to encrypted private key；The private key of encryption is provided with the decryption policy being only decrypted by target container；The remote proving for being directed to public key is initiated to the long-range object that receives by third party's remote proving server-side, and when public key passes through remote proving, public key is sent to the long-range object that receives and carries out persistent storage；Obtain the implementing result of pending code；The implementing result is signed by target container based on the private key decrypted；Implementing result is sent to long-range reception object, is verified by remotely receiving object based on signature of the public key of storage to implementing result.
Description
Technical Field
One or more embodiments of the present disclosure relate to the field of block chain technologies, and in particular, to a method and an apparatus for remote attestation of a trusted application, and an electronic device.
Background
Remote Attestation (Remote Attestation) is a method for obtaining trust of a Remote provider or a Remote producer by hardware or software and hardware, and is one of key technologies of trusted computing. For example, in practical applications, protected code in a trusted application program can be isolated in a trusted execution environment, and the execution result of the protected code can be proved to be trusted data to a remote receiving object based on a remote attestation technology on the basis of not revealing the protected code.
Disclosure of Invention
The present specification proposes a remote attestation method of a trusted application, protected code in the trusted application being isolatedly loaded in a target container as a trusted execution environment; the protected code comprises a code to be executed and an objective function used for generating a private key and a public key; the method comprises the following steps:
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 is set with a decryption policy for decryption only by the target container;
initiating remote certification aiming at the public key to a remote receiving object through a third-party remote certification server, and sending the public key to the remote receiving object for persistent storage when the public key passes the remote certification;
acquiring 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;
and sending the execution result to the remote receiving object so as to verify the signature of the execution result by the remote receiving object based on the stored public key to confirm whether the execution result is credible data.
Optionally, invoking the target function to generate a private key and a public key in the target container includes:
responding to an execution instruction of the code to be executed, calling the target function to generate a private key and a public key in the target container; or,
and periodically calling the target function to generate a private key and a public key in the target container based on a preset calling period.
Optionally, initiating, by a third-party remote attestation server, remote attestation on the public key to a remote receiving object, and sending the public key to the remote receiving object for persistent storage when the public key passes the remote attestation, including:
creating a remote attestation credential based on the generated public key;
sending the remote attestation credential to the third-party remote attestation server for verification of the remote attestation credential by the remote attestation server;
obtaining a verification result returned by the remote certification server; wherein the verification result is signed by the remote attestation server based on a held private key;
and sending the verification result and the generated public key to the remote receiving object, so that the remote receiving object verifies the signature of the verification result at least based on the public key of the third-party remote certification server, and after the signature verification is passed, the generated public key is stored locally in the remote receiving object in a persistent manner.
Optionally, the trusted execution environment is a trusted execution environment built based on an SGX technology; the target container is an Enclave program in SGX technology; wherein the encrypted decryption policy of the private key is set to a keyplicoy-mrencave policy.
Optionally, the remote receiving object is an intelligent contract issued to the blockchain.
The present specification also proposes a remote attestation apparatus for a trusted application, protected code in the trusted application being isolatedly loaded in a target container as a trusted execution environment; the protected code comprises a code to be executed and an objective function used for generating a private key and a public key; the device comprises:
the generating module is used for 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 is set with a decryption policy for decryption only by the target container;
the certification module initiates a remote certification aiming at the public key to a remote receiving object through a third-party remote certification server, and sends the public key to the remote receiving object for persistent storage when the public key passes the remote certification;
the acquisition module is used for acquiring 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;
and the verification module is used for sending the execution result to the remote receiving object so as to verify the signature of the execution result by the remote receiving object based on the stored public key to confirm whether the execution result is credible data.
Optionally, the generating module:
responding to an execution instruction of the code to be executed, calling the target function to generate a private key and a public key in the target container; or,
and periodically calling the target function to generate a private key and a public key in the target container based on a preset calling period.
Optionally, the attestation module:
creating a remote attestation credential based on the generated public key;
sending the remote attestation credential to the third-party remote attestation server for verification of the remote attestation credential by the remote attestation server;
obtaining a verification result returned by the remote certification server; wherein the verification result is signed by the remote attestation server based on a held private key;
and sending the verification result and the generated public key to the remote receiving object, so that the remote receiving object verifies the signature of the verification result at least based on the public key of the third-party remote certification server, and after the signature verification is passed, the generated public key is stored locally in the remote receiving object in a persistent manner.
Optionally, the trusted execution environment is a trusted execution environment built based on an SGX technology; the target container is an Enclave program in SGX technology; wherein the encrypted decryption policy of the private key is set to a keyplicoy-mrencave policy.
Optionally, the remote receiving object is an intelligent contract issued to the blockchain.
This specification also proposes an electronic device including:
a processor;
a memory for storing machine executable instructions;
wherein protected code in a trusted application is sequestered loaded in a target container that is a trusted execution environment by reading and executing machine-executable instructions stored by the memory that correspond to control logic for remote attestation of the trusted application based on a blockchain; the protected code comprises a code to be executed and an objective function used for generating a private key and a public key; the processor is caused to:
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 is set with a decryption policy for decryption only by the target container;
initiating remote certification aiming at the public key to a remote receiving object through a third-party remote certification server, and sending the public key to the remote receiving object for persistent storage when the public key passes the remote certification;
acquiring 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;
and sending the execution result to the remote receiving object so as to verify the signature of the execution result by the remote receiving object based on the stored public key to confirm whether the execution result is credible data.
In the above technical solution, on one hand, since the public-private key pair for remote attestation is autonomously generated in the target container as a trusted execution environment, it is no longer generated by the software provider; moreover, the encrypted private key stored persistently is set with a decryption strategy for decrypting only by the target container; therefore, even a software developer cannot acquire the generated private key, so that the security level of the private key can be remarkably improved;
on the other hand, the trusted application program only needs to initiate a remote certification for the autonomously generated public key to the remote receiving object through the third-party remote certification server, and after the public key passes through the remote certification, the generated private key can be directly used to sign the execution result of the code to be executed in the protected code, and the signed execution result is sent to the remote receiving object to complete the remote certification for the execution result, so that the remote certification for the execution result is not needed to be initiated to the remote receiving object through the third-party remote certification server; therefore, frequent interaction with a third-party remote certification server is not needed, and the execution result can be conveniently and rapidly certified as trusted data to a remote receiving object based on the self-generated public and private key pair.
Drawings
FIG. 1 is a flow chart of a method for remote attestation of a trusted application provided by an exemplary embodiment.
Fig. 2 is a schematic structural diagram of an electronic device according to an exemplary embodiment.
Fig. 3 is a block diagram of a remote attestation device for a trusted application provided by an example embodiment.
Detailed Description
In practical applications, security protection of protected codes can be generally realized by building a TEE (Trusted Execution Environment) and isolating the protected codes in a Trusted application program in the TEE.
When the TEE is built, a processor at the bottom of the device can be used as a hardware support to build a container (container) which can only be accessed by the processor as a trusted execution environment, and protected codes in a trusted application program are loaded in the container in an isolated manner so as to perform isolation protection on the protected codes in the container.
For example, taking the SGX (Software Guard Extensions) technology of Intel as an example to build a TEE, based on the SGX technology, a CPU of a device is usually used as a hardware support to create a program called Enclave as a protection container, and code that needs to be protected is loaded in the Enclave program in an isolated manner to protect it from attack.
In some scenarios, if the execution result of the protected code in the trusted application needs to participate in remote trusted computing, the trusted application needs to send the execution result of the protected code to a remote receiving object, and generally needs to prove, based on a remote attestation technology, that the execution result of the protected code is trusted data to the remote receiving object on the basis of not revealing the protected code.
For example, in one scenario, assume that an intelligent contract deployed on a blockchain requires trusted computing on the blockchain with the results of execution of protected code in a trusted application as input data; in this case, the trusted application is not a linked node and is a non-trusted party for the intelligent contract; therefore, when the trusted application sends the execution results of the protected codes to the intelligent contracts deployed on the blockchain, the trusted application needs to rely on a remote attestation technology to prove the execution results of the protected codes to the intelligent contracts as trusted data (i.e., chain attestation) on the basis of not revealing the protected codes.
Based on the current remote attestation technology, when a trusted application program initiates remote attestation for specific data to a remote receiving object, the trusted application program usually needs to rely on a third-party remote attestation server to complete the remote attestation;
for example, still taking the remote attestation mechanism in SGX technology of Intel as an example, based on SGX technology, Intel will provide an IAS (international authentication service) server of a third party for remote attestation. And isolating the execution result of the protected code loaded in the Enclave, if the trusted application program needs to participate in trusted computing, interacting with the IAS server, initiating remote authentication aiming at the execution result of the protected code to a remote receiving object through the IAS server, and proving that the execution result of the protected code is trusted data to the remote receiving object.
Since the third-party remote attestation server is relied on to complete the remote attestation and needs to frequently interact with the third-party remote attestation server, a more convenient remote attestation mechanism is needed.
Based on this, the present specification proposes a remote attestation scheme that facilitates initiation of execution results of protected code to a remote recipient object based on a public-private key pair independently generated as a container of a trusted execution environment.
In implementation, a software developer of the trusted application may develop a target container (e.g., Enclave program in SGX technology) as a TEE based on a specific TEE building technology (e.g., SGX technology using Intel), and load protected code in the trusted application in the target container in isolation.
In this scheme, the protected code that is loaded in the target container in an isolated manner may include a code to be executed whose execution result needs to be remotely certified to a remote recipient, and an objective function (essentially some special codes that generate a private key and a public key) for generating a private key and a public key.
Further, the trusted application program may call a target function in the protected code that is separately loaded in the target container, and generate a pair of a public key and a private key in the target container;
on one hand, the generated private key can be encrypted in the target container; when the generated private key is encrypted in the target container, a decryption policy for decrypting only the target container can be set for the encrypted private key (that is, only the target container has a decryption right); the encrypted private key is then persisted by the processor.
On the other hand, for the generated public key, a third-party remote certification server can initiate remote certification for the public key to a remote receiving object, and when the public key passes the remote certification, the generated public key is sent to the remote receiving object, and the remote receiving object performs persistent storage.
Subsequently, when the code to be executed is executed, the target container may decrypt the encrypted private key, and perform signature processing on the execution result of the code to be executed based on the private key. The trusted application program may obtain the execution result signed by the target container, and send the execution result to the remote receiving object to initiate remote attestation of the execution result.
After receiving the execution result sent by the trusted application program, the remote receiving object may verify a signature of the execution result based on the stored public key to determine whether the execution result is trusted data.
In the above technical solution, on one hand, since the public-private key pair for remote attestation is autonomously generated in the target container as a trusted execution environment, it is no longer generated by the software provider; moreover, the encrypted private key stored persistently is set with a decryption strategy for decrypting only by the target container; therefore, even a software developer cannot acquire the generated private key, so that the security level of the private key can be remarkably improved;
on the other hand, the trusted application program only needs to initiate a remote certification for the autonomously generated public key to the remote receiving object through the third-party remote certification server, and after the public key passes through the remote certification, the generated private key can be directly used to sign the execution result of the code to be executed in the protected code, and the signed execution result is sent to the remote receiving object to complete the remote certification for the execution result, so that the remote certification for the execution result is not needed to be initiated to the remote receiving object through the third-party remote certification server; therefore, frequent interaction with a third-party remote certification server is not needed, and the execution result can be conveniently and rapidly certified as trusted data to a remote receiving object based on the self-generated public and private key pair.
The present specification is described below with reference to specific embodiments and specific application scenarios.
Referring to fig. 1, fig. 1 is a block diagram illustrating a method for remotely certifying a trusted application, applied to a trusted application, according to an embodiment of the present disclosure; protected code in the trusted application is isolated and loaded in a target container as a trusted execution environment; the protected code comprises a code to be executed and an objective function used for generating a private key and a public key; the method performs the steps of:
102, 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 is set with a decryption policy for decryption only by the target container;
104, initiating remote certification aiming at the public key to a remote receiving object through a third-party remote certification server, and sending the public key to the remote receiving object for persistent storage when the public key passes the remote certification;
step 106, obtaining 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, sending 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 trusted data.
The trusted application programs comprise application programs which are developed by software developers and can provide trusted services for third parties; in which program code in a trusted application, typically includes a protected portion, and is unprotected.
The target container is generally referred to in this specification as an isolated secure operating environment that is set up based on a specific TEE setting up technology and can provide security protection for protected codes in a trusted application;
in practical application, the target container may be an isolated software environment that is supported by a processor as underlying hardware and is only accessible by the processor; for example, taking an SGX technology of Intel as an example for building a TEE, the target container may be an Enclave program in the SGX technology, and usually, protected codes in a trusted application program are separately loaded into the Enclave program to perform security protection on the protected codes.
Of course, in practical applications, it is not excluded that the target container may be a physically isolated hardware environment; for example, the target container may be a physically isolated physical chip, and protected code in the trusted application may be isolated and loaded in the physical chip to perform security protection on the protected code.
It should be emphasized that the TEE building technology used for building the TEE is not particularly limited in this specification, and those skilled in the art can flexibly select the TEE based on actual development requirements. It will be appreciated that the particular configuration of the target container described above will also generally depend on the TEE construction technique employed by those skilled in the art; that is, whether the target container is ultimately an isolated software environment or an isolated hardware environment depends on the TEE building technique employed by those skilled in the art; for example, if one skilled in the art uses the SGX technology of Intel to build a TEE, the target container is an isolated software environment (i.e., Enclave program) that is supported by a CPU as the underlying hardware and is only accessible by the CPU.
The remote receiving object specifically refers to a remote data user of an execution result of a protected code in a trusted application program; for example, in practical applications, the remote receiving object may be an independent trusted host or a trusted system; alternatively, it may be an intelligent contract deployed on a blockchain.
In the following embodiments, the TEE will be built by using the SGX technology based on Intel as an example; it should be emphasized that the construction of TEE based on the SGX technology of Intel is only illustrative; obviously, in practical application, other TEE construction technologies can be adopted to construct TEE; for example, TrustZone technology such as ARM may also be used, which is not specifically listed in this specification.
In this specification, a software developer of a trusted application program may create an Enclave program as a TEE based on the SGX technology of Intel, and load protected code in the trusted application program in the target container in an isolated manner.
It should be noted that, the specific implementation process for creating an Enclave program based on the SGX technology and loading the protected code in the target container in isolation is not described in detail in this specification, and those skilled in the art may refer to the description in the related art when putting the technical solution in this specification into practice.
For the protected code loaded in the Enclave program in isolation, the protected code is generally called a Trusted area (Trusted Part) of the Trusted application program; and other code which is not isolated and loaded in the Enclave program is called an Untrusted (un-trusted) area of the trusted application program.
The protected code which is loaded in the Enclave program in an isolated mode at least comprises a code to be executed and a target function;
the code to be executed is a protected code of which an execution result needs to be sent to a remote receiving object for trusted computing; that is, the trusted application program needs to prove, to the remote receiving object, that the execution result of the code to be executed is trusted data by using a trusted attestation technology. The target function is specifically configured to generate a public key and a private key for the target container.
In SGX technology, a trusted application initiates remote attestation of the results of execution of protected code to a remote recipient object, typically by interacting with a deployed IAS server.
In this specification, instead of using the existing remote attestation mechanism in the SGX technology to initiate remote attestation of the execution result of the protected code to the remote receiving object by interacting with the IAS server, the existing remote attestation mechanism in the SGX technology is used to initiate a remote attestation of a public and private key pair independently generated inside an Enclave program to the remote receiving object, and then after the remote attestation of the public and private key pair passes, the remote attestation of the execution result of the protected code can be conveniently initiated to the remote receiving object based on the public and private key pair without interacting with the IAS server.
In an initial state, the untrusted area of the trusted application program may call, in an ECALL manner, an object function isolated from the protected code loaded in the Enclave program, and generate a pair of a public key and a private key inside the Enclave program.
It should be noted that, the untrusted area, by means of ECALL, may call the target function in the protected code loaded in the Enclave program in an isolated manner in real time when executing the code to be executed in the protected code, or may call the target function periodically based on a certain call period.
For example, in one implementation, when receiving an execution instruction for code to be executed in protected code, the untrusted region may respond to the execution instruction in real time, immediately call, in an ECALL manner, an object function in the protected code that is isolated and loaded in the Enclave program, and generate a pair of a public key and a private key inside the Enclave.
In another implementation, a call cycle may also be preset for the untrusted area, so that the untrusted area may periodically call, based on the call cycle, an object function in the protected code that is loaded in the Enclave program in an isolated manner, and generate a pair of a public key and a private key inside the Enclave program. In this way, the public key and the private key of the Enclave program can be updated regularly.
On one hand, for the generated private key, the processor can perform encryption processing (the key is held by the processor) in the Enclave program, the processor sets a decryption policy for the encrypted private key, and then the encrypted private key is held and stored;
based on the SGX technology, decryption strategies for encrypted information generally include a keyplicy-mrencave strategy and a keyplicy-MRSIGNER strategy.
By mrencave policy, it is meant that it can only be decrypted by the current encave; the MRSIGNER strategy means that all ENCLAVE which can be developed and signed by the same developer can be decrypted.
Because of the MRSIGNER strategy, a developer needs to be trusted; therefore, for a malicious person who obtains the private key of the developer, by developing malicious ENCLAVE and signing the malicious ENCLAVE based on the grasped private key of the developer, the encrypted private key can be decrypted by the malicious ENCLAVE, so that plaintext data of the encrypted private key is leaked.
Based on this, in this specification, when the processor sets the decryption policy for the encrypted private key, the processor may set the decryption policy to be the mrencoevepolicy; that is, only the current ENCLAVE has the right to decrypt the persistently stored encrypted private key.
By the method, even a software developer cannot acquire the private key independently generated by ENCLAVE, so that the security level of the private key can be remarkably improved.
On the other hand, for the generated public key, the trusted area of the trusted execution program may initiate remote attestation of the public key to the remote recipient through the IAS server, and when the public key passes the remote attestation, the generated public key is sent to the remote recipient, and is persistently stored by the remote recipient.
Based on the SGX technology, when a trusted area of a trusted execution program initiates remote certification aiming at a public key to a remote receiving object, firstly, a Quote serving as a remote certification certificate can be created based on the generated public key or a hash value of the public key;
for example, based on the SGX technology, the above Quote is usually created by an Enclave and a special Quote Enclave through internal interaction. The detailed implementation process of creating a Quote for remote attestation for Enclave by a Quote Enclave is not detailed in this specification, and a person skilled in the art may refer to the technology in the related art when assisting time with the technical solution in this specification.
In this specification, the finished Quote is finally created, and may include an EPID signature, a generated public key or a hash value of the public key (i.e. userdata requiring remote attestation), an MRENCLAVE identifier, an EPID identifier of the processor, and other information.
That is, the created Quote is obtained by performing an EPID signature on the generated public key or the hash value of the public key (i.e., userdata requiring remote certification), the mrencave identifier, the EPID identifier of the processor, and other information as a whole.
The mrencave identifier is a hash value of an Enclave code, and is used to uniquely identify an Enclave. The EPID tag, also known as a basename, is used to anonymously identify a processor. The EPID signature is a group signature technology that is adopted by the SGX technology of Intel and can maintain anonymity, and the signature processing procedure of the EPID signature and the signature verification procedure of the EPID signature in this specification are not described in detail, and those skilled in the art can refer to the description in the related art.
In this specification, after a Quote is generated as a remote attestation certificate, a trusted area of a trusted execution program may send the Quote to an IAS server for remote verification. After receiving the Quote, the IAS server may verify the EPID signature of the Quote, and then sign the Quote and the Verification result for the Quote as a whole based on the private key held by the IAS server, so as to generate a corresponding AVR (Attestation Verification Report).
That is, in this specification, the AVR may generally include information such as the Quote, the Quote authentication result, and the IAS signature.
In this specification, the IAS server may return the generated AVR to the trusted zone of the trusted execution program, and after receiving the AVR returned by the IAS server, the trusted zone of the trusted execution program may further send the AVR and the public key generated by calling the target function to the remote receiving object.
Alternatively, the trusted area of the trusted execution program may further send the AVR and the public key generated by calling the target function to the untrusted area of the trusted execution program, and the untrusted area may further send the AVR and the public key generated by calling the target function to the remote receiving object.
After receiving the AVR sent by the trusted zone of the trusted execution program, the remote receiving object can first verify the state of the AVR; for example, verifying whether the value of the state field in the AVR is a specific value indicating that the AVR state is normal; after the state of the AVR passes the verification, verifying the IAS signature of the AVR based on the public key corresponding to the private key held by the IAS server; if the signature passes the verification, the public key in the Quote carried in the AVR or the hash value of the public key, mrencolave identification, EPID identification of the processor and other information can be further verified.
Verifying the public key in the Quote or the hash value of the public key, namely, verifying whether the public key in the Quote or the hash value of the public key is matched with 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 the Quote, the hash value of the public key sent by the trusted region of the trusted execution program can be further calculated, and then the calculated hash value is matched with the hash value of the public key carried in the Quote; if the two match, verification can be confirmed.
The verification of the information such as mrencolave identifier in the Quote and the EPID of the processor is the process of verifying Enclave corresponding to the mrencolave identifier and verifying whether the processor corresponding to the EPID of the processor is authentic.
During implementation, an Enclave developer can prove that the Enclave code does not contain malicious codes through the open source Enclave code, and an administrator of the remote receiving object can perform security audit on the open source Enclave code and set an MRENCLAVE white list for the remote receiving object. Similarly, an EPID identification white list can be set for the remote receiving object according to actual requirements. Therefore, when the remote receiving object verifies information such as MRENCLAVE identification in the queue and EPID identification of the processor, the remote receiving object can confirm whether the processor corresponding to the MRENCLAVE identification and the EPID identification of the processor are credible by matching the MRENCLAVE identification in the queue with the MRENCLAVE white list and matching the EPID identification of the processor in the queue with the EPID white list.
Please continue to refer to fig. 2, when the IAS of AVR is signed; after the public key in the Quote carried in the AVR or the hash value of the public key, the mrencolave identifier, the EPID identifier of the processor and other information are verified, the remote receiving object can locally perform persistent storage on the public key generated by calling the target function and sent by the trusted area of the trusted execution program, and the corresponding mrencolave and EPID.
That is, MRENCLAVE corresponding to the public key generated by calling the target function is used as a trusted program identifier, and EPID corresponding to the public key is used as a trusted hardware identifier and is persistently stored together with the public key.
In this specification, after the remote receiving object persistently stores the public key generated by calling the target function locally, the subsequent trusted application program may initiate a remote attestation of the execution result of the code to be executed without interacting with an IAS server, but directly initiate a remote attestation of the execution result of the protected code to the remote receiving object by calling the public and private key pair created by the target function.
Specifically, when the execution of the to-be-executed code loaded in the Enclave in the isolated manner is completed, the Enclave may decrypt the encrypted private key that has been stored persistently (only the Enclave has a decryption authority), and perform signature processing on the to-be-executed result based on the decrypted private key.
It should be noted that, in practical applications, the execution result may include an output result of the code to be executed after the execution is completed, and may also introduce other information; according to actual service requirements, signing other information except the output result of the code to be executed as part of the execution result, and then initiating remote authentication; for example, in one example, the signature process may be performed on input data (for example, an execution parameter input when the code to be executed is executed) of the code to be executed during execution, as part of the execution result.
The untrusted area of the trusted application program may obtain the execution result signed by the envelope, directly send the execution result to the remote receiving object, and initiate a remote attestation on the execution result.
In practical applications, of course, the execution result after the signature processing may be directly sent to the remote receiving object by the trusted area of the trusted application program, and the remote attestation of the execution result may be initiated.
After receiving the execution result, the remote receiving object may verify a signature of the execution result based on the public key (i.e., the public key generated by invoking the target function) stored in a local persistent manner; if the signature passes the verification, the execution result can be directly identified as trusted data generated by trusted Enclave created on a trusted processor; at this time, the remote certification of the execution result of the code to be executed is completed.
By the method, when the remote certification is carried out on the execution result of the code to be executed to the remote receiving object, the interaction with the IAS server is not needed any more, so that the remote certification can be completed more conveniently.
In the above technical solution, on one hand, since the public-private key pair for remote attestation is autonomously generated in the target container as a trusted execution environment, it is no longer generated by the software provider; moreover, the encrypted private key stored persistently is set with a decryption strategy for decrypting only by the target container; therefore, even a software developer cannot acquire the generated private key, so that the security level of the private key can be remarkably improved;
on the other hand, the trusted application program only needs to initiate a remote certification for the autonomously generated public key to the remote receiving object through the third-party remote certification server, and after the public key passes through the remote certification, the generated private key can be directly used to sign the execution result of the code to be executed in the protected code, and the signed execution result is sent to the remote receiving object to complete the remote certification for the execution result, so that the remote certification for the execution result is not needed to be initiated to the remote receiving object through the third-party remote certification server; therefore, frequent interaction with a third-party remote certification server is not needed, and the execution result can be conveniently and rapidly certified as trusted data to a remote receiving object based on the self-generated public and private key pair.
Corresponding to the above method embodiments, the present specification also provides an embodiment of a remote attestation device for a trusted application. Embodiments of the remote attestation apparatus of trusted applications of the present specification can be applied on electronic devices. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation. From a hardware aspect, as shown in fig. 2, the hardware structure diagram of an electronic device in which a remote attestation apparatus of a trusted application program is located in this specification is shown, except for the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 2, the electronic device in which the apparatus is located in the embodiment may also include other hardware according to an actual function of the electronic device, which is not described again.
FIG. 3 is a block diagram illustrating a remote attestation device for a trusted application in an exemplary embodiment of the present description.
Referring to fig. 3, the remote attestation apparatus 30 of the trusted application can be applied to the electronic device shown in fig. 2; wherein protected code in the trusted application is sequestered loaded in a target container that is a trusted execution environment; the protected code comprises a code to be executed and a target function for generating a private key and a public key;
the device 30 comprises:
the generating 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 persistently stores the encrypted private key; wherein the encrypted private key is set with a decryption policy for decryption only by the target container;
the certification module 302 initiates a remote certification for the public key to a remote receiving object through a third-party remote certification server, and sends the public key to the remote receiving object for persistent storage when the public key passes the remote certification;
an obtaining module 303, configured 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 304 sends 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 trusted data.
In this embodiment, the generating module 301:
responding to an execution instruction of the code to be executed, calling the target function to generate a private key and a public key in the target container; or,
and periodically calling the target function to generate a private key and a public key in the target container based on a preset calling period.
In this embodiment, the attestation module 302:
creating a remote attestation credential based on the generated public key;
sending the remote attestation credential to the third-party remote attestation server for verification of the remote attestation credential by the remote attestation server;
obtaining a verification result returned by the remote certification server; wherein the verification result is signed by the remote attestation server based on a held private key;
and sending the verification result and the generated public key to the remote receiving object, so that the remote receiving object verifies the signature of the verification result at least based on the public key of the third-party remote certification server, and after the signature verification is passed, the generated public key is stored locally in the remote receiving object in a persistent manner.
In this embodiment, the trusted execution environment is a trusted execution environment built based on an SGX technology; the target container is an Enclave program in SGX technology; wherein the encrypted decryption policy of the private key is set to a keyplicoy-mrencave policy.
In this embodiment, the remote receiving object is an intelligent contract issued to a blockchain.
The implementation process of the functions and actions of each module in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, wherein the modules described as separate parts may or may not be physically separate, and the parts displayed as modules may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.
The systems, devices, modules or modules illustrated in the above embodiments may be implemented by a computer chip or an entity, or by an article of manufacture with certain functionality. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
Corresponding to the method embodiment, the present specification also provides an embodiment of an electronic device. The electronic device includes: a processor and a memory for storing machine executable instructions; wherein the processor and the memory are typically interconnected by an internal bus. In other possible implementations, the device may also include an external interface to enable communication with other devices or components.
In the embodiment, protected code in the trusted application program is loaded in a target container which is a trusted execution environment in an isolated mode; the protected code comprises a code to be executed and an objective function used for generating a private key and a public key;
by reading and executing machine-executable instructions stored by the memory that correspond to control logic for remote attestation of trusted applications, the processor is caused to:
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 is set with a decryption policy for decryption only by the target container;
initiating remote certification aiming at the public key to a remote receiving object through a third-party remote certification server, and sending the public key to the remote receiving object for persistent storage when the public key passes the remote certification;
acquiring 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;
and sending the execution result to the remote receiving object so as to verify the signature of the execution result by the remote receiving object based on the stored public key to confirm whether the execution result is credible data.
In this embodiment, the processor is caused to, by reading and executing machine-executable instructions stored by the memory that correspond to control logic for remote attestation of a trusted application:
responding to an execution instruction of the code to be executed, calling the target function to generate a private key and a public key in the target container; or,
and periodically calling the target function to generate a private key and a public key in the target container based on a preset calling period.
In this embodiment, the processor is caused to, by reading and executing machine-executable instructions stored by the memory that correspond to control logic for remote attestation of a trusted application:
creating a remote attestation credential based on the generated public key;
sending the remote attestation credential to the third-party remote attestation server for verification of the remote attestation credential by the remote attestation server;
obtaining a verification result returned by the remote certification server; wherein the verification result is signed by the remote attestation server based on a held private key;
and sending the verification result and the generated public key to the remote receiving object, so that the remote receiving object verifies the signature of the verification result at least based on the public key of the third-party remote certification server, and after the signature verification is passed, the generated public key is stored locally in the remote receiving object in a persistent manner.
Other embodiments of the present disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This specification is intended to cover any variations, uses, or adaptations of the specification following, in general, the principles of the specification and including such departures from the present disclosure as come within known or customary practice within the art to which the specification pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the specification being indicated by the following claims.
It will be understood that the present description is not limited to the precise arrangements described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present description is limited only by the appended claims.
The above description is only a preferred embodiment of the present disclosure, and should not be taken as limiting the present disclosure, and any modifications, equivalents, improvements, etc. made within the spirit and principle of the present disclosure should be included in the scope of the present disclosure.
Claims (11)
1. A remote attestation method of a trusted application, protected code in the trusted application being isolatedly loaded in a target container as a trusted execution environment; the protected code comprises a code to be executed and an objective function used for generating a private key and a public key; the method comprises the following steps:
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 is set with a decryption policy for decryption only by the target container;
initiating remote certification aiming at the public key to a remote receiving object through a third-party remote certification server, and sending the public key to the remote receiving object for persistent storage when the public key passes the remote certification;
acquiring 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;
and sending the execution result to the remote receiving object so as to verify the signature of the execution result by the remote receiving object based on the stored public key to confirm whether the execution result is credible data.
2. The method of claim 1, invoking the target function to generate a private key and a public key in the target container, comprising:
responding to an execution instruction of the code to be executed, calling the target function to generate a private key and a public key in the target container; or,
and periodically calling the target function to generate a private key and a public key in the target container based on a preset calling period.
3. The method of claim 1, initiating, by a third-party remote attestation server, remote attestation of the public key to a remote receiving object, and sending the public key to the remote receiving object for persistent storage when the public key passes the remote attestation, comprising:
creating a remote attestation credential based on the generated public key;
sending the remote attestation credential to the third-party remote attestation server for verification of the remote attestation credential by the remote attestation server;
obtaining a verification result returned by the remote certification server; wherein the verification result is signed by the remote attestation server based on a held private key;
and sending the verification result and the generated public key to the remote receiving object, so that the remote receiving object verifies the signature of the verification result at least based on the public key of the third-party remote certification server, and after the signature verification is passed, the generated public key is stored locally in the remote receiving object in a persistent manner.
4. The method of claim 1, wherein 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 encrypted decryption policy of the private key is set to a keyplicoy-mrencave policy.
5. The method of claim 1, the remote receiving object being a smart contract issued to a blockchain.
6. A remote attestation apparatus of a trusted application, protected code in the trusted application being isolatedly loaded in a target container as a trusted execution environment; the protected code comprises a code to be executed and an objective function used for generating a private key and a public key; the device comprises:
the generating module is used for 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 is set with a decryption policy for decryption only by the target container;
the certification module initiates a remote certification aiming at the public key to a remote receiving object through a third-party remote certification server, and sends the public key to the remote receiving object for persistent storage when the public key passes the remote certification;
the acquisition module is used for acquiring 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;
and the verification module is used for sending the execution result to the remote receiving object so as to verify the signature of the execution result by the remote receiving object based on the stored public key to confirm whether the execution result is credible data.
7. The apparatus of claim 6, the generation module to:
responding to an execution instruction of the code to be executed, calling the target function to generate a private key and a public key in the target container; or,
and periodically calling the target function to generate a private key and a public key in the target container based on a preset calling period.
8. The apparatus of claim 6, the attestation module to:
creating a remote attestation credential based on the generated public key;
sending the remote attestation credential to the third-party remote attestation server for verification of the remote attestation credential by the remote attestation server;
obtaining a verification result returned by the remote certification server; wherein the verification result is signed by the remote attestation server based on a held private key;
and sending the verification result and the generated public key to the remote receiving object, so that the remote receiving object verifies the signature of the verification result at least based on the public key of the third-party remote certification server, and after the signature verification is passed, the generated public key is stored locally in the remote receiving object in a persistent manner.
9. The apparatus of claim 6, the trusted execution environment being a trusted execution environment built based on SGX technology; the target container is an Enclave program in SGX technology; wherein the encrypted decryption policy of the private key is set to a keyplicoy-mrencave policy.
10. The apparatus of claim 6, the remote receiving object is a smart contract issued to a blockchain.
11. An electronic device, comprising:
a processor;
a memory for storing machine executable instructions;
wherein protected code in a trusted application is sequestered loaded in a target container that is a trusted execution environment by reading and executing machine-executable instructions stored by the memory that correspond to control logic for remote attestation of the trusted application based on a blockchain; the protected code comprises a code to be executed and an objective function used for generating a private key and a public key; the processor is caused to:
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 is set with a decryption policy for decryption only by the target container;
initiating remote certification aiming at the public key to a remote receiving object through a third-party remote certification server, and sending the public key to the remote receiving object for persistent storage when the public key passes the remote certification;
acquiring 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;
and sending the execution result to the remote receiving object so as to verify the signature of the execution result by the remote receiving object based on the stored public key to confirm whether the execution result is credible data.
Priority Applications (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011295708.6A CN112468473B (en) | 2018-11-16 | 2018-11-16 | Remote proving method and device for trusted application program and electronic equipment |
| CN201811364461.1A CN110011801B (en) | 2018-11-16 | 2018-11-16 | Remote certification method and device for trusted application program and electronic equipment |
| TW108129629A TWI716078B (en) | 2018-11-16 | 2019-08-20 | Remote certification method and device for trusted application program and electronic equipment |
| PCT/CN2019/106607 WO2020098377A1 (en) | 2018-11-16 | 2019-09-19 | Remote attestation method and apparatus for trusted application program, and electronic device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811364461.1A CN110011801B (en) | 2018-11-16 | 2018-11-16 | Remote certification method and device for trusted application program and electronic equipment |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011295708.6A Division CN112468473B (en) | 2018-11-16 | 2018-11-16 | Remote proving method and device for trusted application program and electronic equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110011801A true CN110011801A (en) | 2019-07-12 |
| CN110011801B CN110011801B (en) | 2020-10-20 |
Family
ID=67164919
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011295708.6A Active CN112468473B (en) | 2018-11-16 | 2018-11-16 | Remote proving method and device for trusted application program and electronic equipment |
| CN201811364461.1A Active CN110011801B (en) | 2018-11-16 | 2018-11-16 | Remote certification method and device for trusted application program and electronic equipment |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011295708.6A Active CN112468473B (en) | 2018-11-16 | 2018-11-16 | Remote proving method and device for trusted application program and electronic equipment |
Country Status (3)
| Country | Link |
|---|---|
| CN (2) | CN112468473B (en) |
| TW (1) | TWI716078B (en) |
| WO (1) | WO2020098377A1 (en) |
Cited By (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110430051A (en) * | 2019-08-01 | 2019-11-08 | 北京永新视博数字电视技术有限公司 | A kind of method for storing cipher key, device and server |
| CN110519260A (en) * | 2019-08-23 | 2019-11-29 | 联想(北京)有限公司 | A kind of information processing method and information processing unit |
| CN110838919A (en) * | 2019-11-01 | 2020-02-25 | 广州小鹏汽车科技有限公司 | Communication method, storage method, operation method and device |
| CN110890962A (en) * | 2019-12-20 | 2020-03-17 | 支付宝(杭州)信息技术有限公司 | Authentication key negotiation method, device, storage medium and equipment |
| CN111049825A (en) * | 2019-12-12 | 2020-04-21 | 支付宝(杭州)信息技术有限公司 | Secure multi-party computing method and system based on trusted execution environment |
| CN111092726A (en) * | 2020-03-18 | 2020-05-01 | 支付宝(杭州)信息技术有限公司 | Method and device for generating shared contract key |
| CN111090888A (en) * | 2020-03-18 | 2020-05-01 | 支付宝(杭州)信息技术有限公司 | Contract verification method and device |
| CN111382445A (en) * | 2020-03-03 | 2020-07-07 | 首都师范大学 | Method for providing trusted service by using trusted execution environment system |
| CN111541725A (en) * | 2020-07-08 | 2020-08-14 | 支付宝(杭州)信息技术有限公司 | Block chain all-in-one machine, password acceleration card thereof, and key management method and device |
| CN111988141A (en) * | 2020-03-18 | 2020-11-24 | 支付宝(杭州)信息技术有限公司 | Method and device for sharing cluster key |
| CN112507034A (en) * | 2021-02-07 | 2021-03-16 | 支付宝(杭州)信息技术有限公司 | Data storage method and system |
| CN113343234A (en) * | 2021-06-10 | 2021-09-03 | 支付宝(杭州)信息技术有限公司 | Method and device for carrying out credible check on code security |
| CN113672973A (en) * | 2021-07-20 | 2021-11-19 | 深圳大学 | Database system of embedded equipment based on RISC-V architecture of trusted execution environment |
| CN114553590A (en) * | 2022-03-17 | 2022-05-27 | 北京字节跳动网络技术有限公司 | Data transmission method and related equipment |
| CN114629639A (en) * | 2022-03-10 | 2022-06-14 | 阿里云计算有限公司 | Key management method and device based on trusted execution environment and electronic equipment |
| CN114884714A (en) * | 2022-04-26 | 2022-08-09 | 北京百度网讯科技有限公司 | Task processing method, device, equipment and storage medium |
| CN114884647A (en) * | 2021-01-22 | 2022-08-09 | 腾讯科技（深圳）有限公司 | Network access management method and related equipment |
| CN115081000A (en) * | 2022-06-17 | 2022-09-20 | 苏州浪潮智能科技有限公司 | Method, system, device and storage medium for protecting source code of remote object program |
| CN116112187A (en) * | 2023-04-10 | 2023-05-12 | 山东海量信息技术研究院 | Remote proving method, device, equipment and readable storage medium |
| CN116846682A (en) * | 2023-08-29 | 2023-10-03 | 山东海量信息技术研究院 | Communication channel establishment method, device, equipment and medium |
| CN117454437A (en) * | 2023-12-22 | 2024-01-26 | 北京天润基业科技发展股份有限公司 | Transaction processing method, storage medium and electronic device |
| WO2024198933A1 (en) * | 2023-03-29 | 2024-10-03 | 杭州阿里云飞天信息技术有限公司 | Private key protection method, server access method, system, device, and storage medium |
Families Citing this family (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113395159B (en) * | 2021-01-08 | 2024-03-12 | 腾讯科技（深圳）有限公司 | Data processing method based on trusted execution environment and related device |
| CN114090981B (en) * | 2021-11-29 | 2023-04-07 | 深圳前海微众银行股份有限公司 | Access method and device for remote host |
| CN114237637A (en) * | 2021-11-29 | 2022-03-25 | 支付宝(杭州)信息技术有限公司 | Firmware flashing method and device, storage medium and electronic equipment |
| CN113987554B (en) * | 2021-12-23 | 2022-04-08 | 支付宝(杭州)信息技术有限公司 | Method, device and system for obtaining data authorization |
| CN114422215B (en) * | 2021-12-31 | 2024-06-25 | 国网安徽省电力有限公司合肥供电公司 | Cross-platform and trusted energy data sharing system and method based on blockchain |
| CN115001744B (en) * | 2022-04-27 | 2023-08-29 | 中国科学院信息工程研究所 | Cloud platform data integrity verification method and system |
| CN114900320B (en) * | 2022-06-21 | 2024-04-26 | 杭州安恒信息安全技术有限公司 | TEE node authentication method, device, equipment and medium |
| CN115276982B (en) * | 2022-07-29 | 2024-04-16 | 武汉科技大学 | SGX-based Ethernet key management method and system |
| CN115484031B (en) * | 2022-09-13 | 2024-03-08 | 山东大学 | SGX-based trusted-free third-party cloud storage ciphertext deduplication method and system |
| FR3143244A1 (en) * | 2022-12-07 | 2024-06-14 | Electricite De France | Authorization mechanism for the use of a software process with source code security |
| CN117493344B (en) * | 2023-11-09 | 2024-07-26 | 兰州大学 | Data organization method based on confidential computing technology |
Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150264021A1 (en) * | 2014-03-13 | 2015-09-17 | Intel Corporation | Pseudonymous remote attestation utilizing a chain-of-trust |
| CN105812332A (en) * | 2014-12-31 | 2016-07-27 | 北京握奇智能科技有限公司 | Data protection method |
| CN107342858A (en) * | 2017-07-05 | 2017-11-10 | 武汉凤链科技有限公司 | A kind of intelligent contract guard method and system based on trusted context |
| CN107896150A (en) * | 2017-12-21 | 2018-04-10 | 善林（上海）金融信息服务有限公司 | Link block chain network and the system of Internet of Things |
| CN107919954A (en) * | 2017-10-20 | 2018-04-17 | 浙江大学 | A kind of block chain user key guard method and device based on SGX |
| CN108055133A (en) * | 2017-12-12 | 2018-05-18 | 江苏安凰领御科技有限公司 | A kind of key secure signing method based on block chain technology |
| CN108462689A (en) * | 2017-02-22 | 2018-08-28 | 英特尔公司 | Technology for the certification of the long-range enclaves SGX |
| US20180332011A1 (en) * | 2017-05-11 | 2018-11-15 | Microsoft Technology Licensing, Llc | Secure cryptlet tunnel |
Family Cites Families (19)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN100583768C (en) * | 2007-04-27 | 2010-01-20 | 中国科学院软件研究所 | Safety requirement based remote proving method and system thereof |
| CN101908115B (en) * | 2010-07-30 | 2013-09-11 | 中国船舶重工集团公司第七0九研究所 | Method for realizing software trusted execution based on trusted platform module |
| CN101951388B (en) * | 2010-10-14 | 2013-03-20 | 中国电子科技集团公司第三十研究所 | Remote attestation method in credible computing environment |
| WO2014141074A1 (en) * | 2013-03-15 | 2014-09-18 | Ologn Technologies Ag | Systems, methods and apparatuses for remote attestation |
| CN104077533B (en) * | 2014-07-17 | 2017-09-15 | 北京握奇智能科技有限公司 | A kind of method and apparatus for operating sensitive data |
| US9363087B2 (en) * | 2014-10-02 | 2016-06-07 | Microsoft Technology Licensing, Inc. | End-to-end security for hardware running verified software |
| 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 |
| CN104408371B (en) * | 2014-10-14 | 2017-12-19 | 中国科学院信息工程研究所 | A kind of implementation method based on credible performing environment high safety application system |
| CN104333451A (en) * | 2014-10-21 | 2015-02-04 | 广东金赋信息科技有限公司 | Trusted self-help service system |
| CN104333541A (en) * | 2014-10-21 | 2015-02-04 | 广东金赋信息科技有限公司 | Trusted self-help service system |
| 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 |
| US10397005B2 (en) * | 2017-03-31 | 2019-08-27 | Intel Corporation | Using a trusted execution environment as a trusted third party providing privacy for attestation |
| CN107395366A (en) * | 2017-08-08 | 2017-11-24 | 沈阳东青科技有限公司 | A kind of Efficient Remote method of proof towards industry control credible calculating platform |
| CN107463838B (en) * | 2017-08-14 | 2019-10-18 | 广州大学 | Method for safety monitoring, device, system and storage medium based on SGX |
| CN108390866B (en) * | 2018-02-06 | 2020-10-02 | 南京航空航天大学 | Trusted remote certification method and system based on double-agent bidirectional anonymous authentication |
-
2018
- 2018-11-16 CN CN202011295708.6A patent/CN112468473B/en active Active
- 2018-11-16 CN CN201811364461.1A patent/CN110011801B/en active Active
-
2019
- 2019-08-20 TW TW108129629A patent/TWI716078B/en active
- 2019-09-19 WO PCT/CN2019/106607 patent/WO2020098377A1/en active Application Filing
Patent Citations (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150264021A1 (en) * | 2014-03-13 | 2015-09-17 | Intel Corporation | Pseudonymous remote attestation utilizing a chain-of-trust |
| CN105812332A (en) * | 2014-12-31 | 2016-07-27 | 北京握奇智能科技有限公司 | Data protection method |
| CN108462689A (en) * | 2017-02-22 | 2018-08-28 | 英特尔公司 | Technology for the certification of the long-range enclaves SGX |
| US20180332011A1 (en) * | 2017-05-11 | 2018-11-15 | Microsoft Technology Licensing, Llc | Secure cryptlet tunnel |
| CN107342858A (en) * | 2017-07-05 | 2017-11-10 | 武汉凤链科技有限公司 | A kind of intelligent contract guard method and system based on trusted context |
| CN107919954A (en) * | 2017-10-20 | 2018-04-17 | 浙江大学 | A kind of block chain user key guard method and device based on SGX |
| CN108055133A (en) * | 2017-12-12 | 2018-05-18 | 江苏安凰领御科技有限公司 | A kind of key secure signing method based on block chain technology |
| CN107896150A (en) * | 2017-12-21 | 2018-04-10 | 善林（上海）金融信息服务有限公司 | Link block chain network and the system of Internet of Things |
Cited By (42)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110430051B (en) * | 2019-08-01 | 2022-08-05 | 北京永新视博数字电视技术有限公司 | Key storage method, device and server |
| CN110430051A (en) * | 2019-08-01 | 2019-11-08 | 北京永新视博数字电视技术有限公司 | A kind of method for storing cipher key, device and server |
| CN110519260A (en) * | 2019-08-23 | 2019-11-29 | 联想(北京)有限公司 | A kind of information processing method and information processing unit |
| CN110519260B (en) * | 2019-08-23 | 2020-09-25 | 联想(北京)有限公司 | Information processing method and information processing device |
| CN110838919B (en) * | 2019-11-01 | 2021-04-13 | 广州小鹏汽车科技有限公司 | Communication method, storage method, operation method and device |
| CN110838919A (en) * | 2019-11-01 | 2020-02-25 | 广州小鹏汽车科技有限公司 | Communication method, storage method, operation method and device |
| CN111049825A (en) * | 2019-12-12 | 2020-04-21 | 支付宝(杭州)信息技术有限公司 | Secure multi-party computing method and system based on trusted execution environment |
| CN111049825B (en) * | 2019-12-12 | 2021-11-30 | 支付宝(杭州)信息技术有限公司 | Secure multi-party computing method and system based on trusted execution environment |
| CN110890962A (en) * | 2019-12-20 | 2020-03-17 | 支付宝(杭州)信息技术有限公司 | Authentication key negotiation method, device, storage medium and equipment |
| WO2021120871A1 (en) * | 2019-12-20 | 2021-06-24 | 支付宝(杭州)信息技术有限公司 | Authentication key negotiation method and apparatus, storage medium and device |
| CN111382445A (en) * | 2020-03-03 | 2020-07-07 | 首都师范大学 | Method for providing trusted service by using trusted execution environment system |
| CN111382445B (en) * | 2020-03-03 | 2023-04-07 | 首都师范大学 | Method for providing trusted service by using trusted execution environment system |
| CN111090888A (en) * | 2020-03-18 | 2020-05-01 | 支付宝(杭州)信息技术有限公司 | Contract verification method and device |
| CN111988141A (en) * | 2020-03-18 | 2020-11-24 | 支付宝(杭州)信息技术有限公司 | Method and device for sharing cluster key |
| CN111092726A (en) * | 2020-03-18 | 2020-05-01 | 支付宝(杭州)信息技术有限公司 | Method and device for generating shared contract key |
| CN111988141B (en) * | 2020-03-18 | 2022-08-02 | 支付宝(杭州)信息技术有限公司 | Method and device for sharing cluster key |
| WO2021184882A1 (en) * | 2020-03-18 | 2021-09-23 | 支付宝(杭州)信息技术有限公司 | Method and apparatus for verifying contract |
| US11626984B2 (en) | 2020-07-08 | 2023-04-11 | Alipay (Hangzhou) Information Technology Co., Ltd. | Blockchain integrated station and cryptographic acceleration card, key management methods and apparatuses |
| CN111541725A (en) * | 2020-07-08 | 2020-08-14 | 支付宝(杭州)信息技术有限公司 | Block chain all-in-one machine, password acceleration card thereof, and key management method and device |
| CN111541725B (en) * | 2020-07-08 | 2021-04-27 | 支付宝(杭州)信息技术有限公司 | Block chain all-in-one machine, password acceleration card thereof, and key management method and device |
| CN114884647A (en) * | 2021-01-22 | 2022-08-09 | 腾讯科技（深圳）有限公司 | Network access management method and related equipment |
| CN114884647B (en) * | 2021-01-22 | 2024-02-20 | 腾讯科技（深圳）有限公司 | Network access management method and related equipment |
| CN112507034A (en) * | 2021-02-07 | 2021-03-16 | 支付宝(杭州)信息技术有限公司 | Data storage method and system |
| CN113468270A (en) * | 2021-02-07 | 2021-10-01 | 支付宝(杭州)信息技术有限公司 | Data storage method and system |
| CN113343234A (en) * | 2021-06-10 | 2021-09-03 | 支付宝(杭州)信息技术有限公司 | Method and device for carrying out credible check on code security |
| WO2022257722A1 (en) * | 2021-06-10 | 2022-12-15 | 支付宝(杭州)信息技术有限公司 | Method and apparatus for performing trust check on code security |
| CN113672973A (en) * | 2021-07-20 | 2021-11-19 | 深圳大学 | Database system of embedded equipment based on RISC-V architecture of trusted execution environment |
| CN113672973B (en) * | 2021-07-20 | 2024-04-16 | 深圳大学 | Database system of embedded device based on RISC-V architecture of trusted execution environment |
| CN114629639A (en) * | 2022-03-10 | 2022-06-14 | 阿里云计算有限公司 | Key management method and device based on trusted execution environment and electronic equipment |
| CN114553590A (en) * | 2022-03-17 | 2022-05-27 | 北京字节跳动网络技术有限公司 | Data transmission method and related equipment |
| CN114553590B (en) * | 2022-03-17 | 2023-08-22 | 抖音视界有限公司 | Data transmission method and related equipment |
| CN114884714B (en) * | 2022-04-26 | 2024-03-26 | 北京百度网讯科技有限公司 | Task processing method, device, equipment and storage medium |
| CN114884714A (en) * | 2022-04-26 | 2022-08-09 | 北京百度网讯科技有限公司 | Task processing method, device, equipment and storage medium |
| CN115081000A (en) * | 2022-06-17 | 2022-09-20 | 苏州浪潮智能科技有限公司 | Method, system, device and storage medium for protecting source code of remote object program |
| CN115081000B (en) * | 2022-06-17 | 2024-06-25 | 苏州浪潮智能科技有限公司 | Method, system, device and storage medium for protecting remote target program source code |
| WO2024198933A1 (en) * | 2023-03-29 | 2024-10-03 | 杭州阿里云飞天信息技术有限公司 | Private key protection method, server access method, system, device, and storage medium |
| CN116112187A (en) * | 2023-04-10 | 2023-05-12 | 山东海量信息技术研究院 | Remote proving method, device, equipment and readable storage medium |
| WO2024212512A1 (en) * | 2023-04-10 | 2024-10-17 | 山东海量信息技术研究院 | Remote attestation method, apparatus and device, and readable storage medium |
| CN116846682A (en) * | 2023-08-29 | 2023-10-03 | 山东海量信息技术研究院 | Communication channel establishment method, device, equipment and medium |
| CN116846682B (en) * | 2023-08-29 | 2024-01-23 | 山东海量信息技术研究院 | Communication channel establishment method, device, equipment and medium |
| CN117454437A (en) * | 2023-12-22 | 2024-01-26 | 北京天润基业科技发展股份有限公司 | Transaction processing method, storage medium and electronic device |
| CN117454437B (en) * | 2023-12-22 | 2024-03-22 | 北京天润基业科技发展股份有限公司 | Transaction processing method, storage medium and electronic device |
Also Published As
| Publication number | Publication date |
|---|---|
| TW202021306A (en) | 2020-06-01 |
| CN110011801B (en) | 2020-10-20 |
| CN112468473A (en) | 2021-03-09 |
| CN112468473B (en) | 2023-10-24 |
| WO2020098377A1 (en) | 2020-05-22 |
| TWI716078B (en) | 2021-01-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110011801B (en) | Remote certification method and device for trusted application program and electronic equipment | |
| EP3382933B1 (en) | Using a trusted execution environment as a trusted third party providing privacy for attestation | |
| Johnson et al. | Intel software guard extensions: EPID provisioning and attestation services | |
| US9867043B2 (en) | Secure device service enrollment | |
| US10491384B2 (en) | Device for secure multi-party cryptographic authorization | |
| JP5497171B2 (en) | System and method for providing a secure virtual machine | |
| WO2022073264A1 (en) | Systems and methods for secure and fast machine learning inference in trusted execution environment | |
| CN111654367B (en) | Method for cryptographic operation and creation of working key, cryptographic service platform and device | |
| US11212095B2 (en) | Allowing restricted external access to devices | |
| US20220051314A1 (en) | Information processing apparatus, information processing system, member identification method, and non-transitory computer readable medium storing program | |
| CN110580245B (en) | Private data sharing method and device | |
| TW202109320A (en) | Trusted execution environment-based application activation method and apparatus | |
| CN111542820A (en) | Method and apparatus for trusted computing | |
| CN111523110A (en) | Permission query configuration method and device based on chain codes | |
| CN112187466B (en) | Identity management method, device, equipment and storage medium | |
| WO2024139273A1 (en) | Federated learning method and apparatus, readable storage medium, and electronic device | |
| CN108449322A (en) | Identity registration, authentication method, system and relevant device | |
| CN116346341A (en) | Private key protection and server access method, system, equipment and storage medium | |
| Cooijmans et al. | Secure key storage and secure computation in Android | |
| Xia et al. | Security Access Solution of Cloud Services for Trusted Mobile Terminals Based on TrustZone. | |
| CN117453343A (en) | Virtual machine measurement and secret calculation authentication method, device, system and storage medium | |
| Hao et al. | Trusted block as a service: Towards sensitive applications on the cloud | |
| CN115270159A (en) | Intelligent contract calling method, device and equipment for block chain and storage medium | |
| US20240333513A1 (en) | Systems and Methods for Demonstrating Identity to a Trusted Platform Module | |
| JP7559841B2 (en) | Information processing device, program execution system, information processing method, and program |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20200925 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Innovative advanced technology Co.,Ltd. Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant before: Advanced innovation technology Co.,Ltd. Effective date of registration: 20200925 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Advanced innovation technology Co.,Ltd. Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands Applicant before: Alibaba Group Holding Ltd. |
|
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20240913 Address after: Guohao Times City # 20-01, 128 Meizhi Road, Singapore Patentee after: Ant Chain Technology Co.,Ltd. Country or region after: Singapore Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Patentee before: Innovative advanced technology Co.,Ltd. Country or region before: Cayman Islands |