CN112468473B - Remote proving method and device for trusted application program and electronic equipment - Google Patents
Remote proving method and device for trusted application program and electronic equipment Download PDFInfo
- Publication number
- CN112468473B CN112468473B CN202011295708.6A CN202011295708A CN112468473B CN 112468473 B CN112468473 B CN 112468473B CN 202011295708 A CN202011295708 A CN 202011295708A CN 112468473 B CN112468473 B CN 112468473B
- Authority
- CN
- China
- Prior art keywords
- public key
- remote
- private key
- trusted
- execution result
- 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.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 42
- 230000002085 persistent effect Effects 0.000 claims abstract description 17
- 230000002045 lasting effect Effects 0.000 claims abstract description 16
- 230000006870 function Effects 0.000 claims description 51
- 238000012795 verification Methods 0.000 claims description 51
- 238000005516 engineering process Methods 0.000 claims description 39
- 230000008569 process Effects 0.000 claims description 12
- 230000000977 initiatory effect Effects 0.000 claims description 5
- 238000012545 processing Methods 0.000 description 11
- 238000010586 diagram Methods 0.000 description 5
- 230000003993 interaction Effects 0.000 description 5
- 238000010276 construction Methods 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 238000002955 isolation 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
- 230000002688 persistence Effects 0.000 description 1
- 238000013175 transesophageal echocardiography 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
Abstract
A remote attestation method of a trusted application, protected code in the trusted application is isolated and loaded in a target container as a trusted execution environment; the protected code includes code to be executed, and an objective function; comprising the following steps: calling the objective function to generate a private key and a public key in the objective container, encrypting the generated private key, and storing the encrypted private key in a lasting way; the encrypted private key is set with a decryption policy that is decrypted only by the target container; a third-party remote certification server initiates remote certification for 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 persistent storage; acquiring an execution result of a code to be executed; the execution result is signed by the target container based on the decrypted private key; and sending the execution result to a remote receiving object, and verifying the signature of the execution result by the remote receiving object based on the stored public key.
Description
Technical Field
One or more embodiments of the present disclosure relate to the field of blockchain technologies, and in particular, to a remote certification method and apparatus for trusted applications, and an electronic device.
Background
Remote attestation (Remote Attestation), a method by which hardware or software and hardware obtains trust of a remote provider or producer, is one of the key technologies for trusted computing. For example, in practical applications, protected code in a trusted application may be isolated in a trusted execution environment, and the execution results of these protected code may be certified to a remote receiving object as trusted data based on remote certification techniques without revealing the protected code.
Disclosure of Invention
The specification proposes a remote attestation method of a trusted application, protected code in the trusted application being isolated loaded in a target container as a trusted execution environment; wherein the protected code comprises code to be executed, and an objective function for generating a private key and a public key; the method comprises the following steps:
calling the objective function to generate a private key and a public key in the objective container, encrypting the generated private key, and storing the encrypted private key in a lasting way; wherein the encrypted private key is set with a decryption policy that is only decrypted by the target container;
a third-party remote proving server initiates remote proving for the public key to a remote receiving object, and when the public key passes the remote proving, the public key is sent to the remote receiving object for persistent storage; the remote receiving object is an intelligent contract issued to a blockchain;
Acquiring an execution result of the code to be executed; 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 based on the stored public key by the remote receiving object to confirm whether the execution result is trusted data.
Optionally, invoking the objective function generates a private key and a public key in the objective container, including:
responding to the execution instruction of the code to be executed, and calling the objective function to generate a private key and a public key in the objective container; or alternatively, the process may be performed,
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 remote attestation server initiates remote attestation for the public key to a remote receiving object through a third party remote attestation server, and when the public key passes the remote attestation, the public key is sent to the remote receiving object for persistent storage, including:
creating a remote attestation credential based on the generated public key;
the remote proof certificate is sent to the third-party remote proof server to be verified by the third-party remote proof server;
Obtaining a verification result returned by the third party remote proof server; the verification result is signed by the third-party remote proof service terminal based on the held private key;
and sending the verification result and the generated public key to the remote receiving object so that the remote receiving object can verify the signature of the verification result at least based on the public key of the third-party remote proving server, and after the signature verification is passed, storing the generated public key in a lasting mode locally to the remote receiving object.
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; the decryption strategy of the private key after encryption is set as a key policy-MRENCLAVE strategy.
The specification also proposes a remote attestation device of a trusted application, protected code in the trusted application being isolated loaded in a target container as a trusted execution environment; wherein the protected code comprises code to be executed, and an objective function for generating a private key and a public key; the device comprises:
The generation 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 storing the encrypted private key in a lasting mode; wherein the encrypted private key is set with a decryption policy that is only decrypted by the target container;
the remote authentication module initiates remote authentication for the public key to a remote receiving object through a third party remote authentication server, and sends the public key to the remote receiving object for persistent storage when the public key passes the remote authentication; the remote receiving object is an intelligent contract issued to a blockchain;
the acquisition module acquires an execution result of the code to be executed; 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 trusted data.
Optionally, the generating module:
responding to the execution instruction of the code to be executed, and calling the objective function to generate a private key and a public key in the objective container; or alternatively, the process may be performed,
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;
the remote proof certificate is sent to the third-party remote proof server to be verified by the third-party remote proof server;
obtaining a verification result returned by the third party remote proof server; the verification result is signed by the third-party remote proof service terminal based on the held private key;
and sending the verification result and the generated public key to the remote receiving object so that the remote receiving object can verify the signature of the verification result at least based on the public key of the third-party remote proving server, and after the signature verification is passed, storing the generated public key in a lasting mode locally to the remote receiving object.
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; the decryption strategy of the private key after encryption is set as a key policy-MRENCLAVE strategy.
The present specification also proposes an electronic device comprising:
a processor;
a memory for storing machine-executable instructions;
wherein protected code in the trusted application is isolated 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 of remote attestation of a blockchain-based trusted application; wherein the protected code comprises code to be executed, and an objective function for generating a private key and a public key; the processor is caused to:
calling the objective function to generate a private key and a public key in the objective container, encrypting the generated private key, and storing the encrypted private key in a lasting way; wherein the encrypted private key is set with a decryption policy that is only decrypted by the target container;
a third-party remote proving server initiates remote proving for the public key to a remote receiving object, and when the public key passes the remote proving, the public key is sent to the remote receiving object for persistent storage; the remote receiving object is an intelligent contract issued to a blockchain;
Acquiring an execution result of the code to be executed; 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 based on the stored public key by the remote receiving object to confirm whether the execution result is trusted data.
In the above technical solution, on the one hand, since the public-private key pair for remote attestation is generated autonomously in the target container as a trusted execution environment, it is no longer generated by the software provider; and, the stored encrypted private key is persisted, set with the decryption policy that is decrypted 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 one-time remote certification for the autonomously generated public key to the remote receiving object through the third-party remote certification server, after the public key passes the remote certification, the generated private key can be directly used for signing an execution result of the code to be executed in the protected code, the signed execution result is sent to the remote receiving object to complete the remote certification for the execution result, and the third-party remote certification server is not needed to initiate the remote certification for the execution result to the remote receiving object; therefore, frequent interaction with the third-party remote proving server is not needed any more, and the execution result can be conveniently proving to the remote receiving object as trusted data based on the public and private key pair generated independently.
Drawings
FIG. 1 is a flowchart of a method for remote attestation of trusted applications 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 of a trusted application provided by an exemplary embodiment.
Detailed Description
In practical applications, security protection of protected code in trusted applications can be achieved by building a TEE (Trusted Execution Environment ) and isolating the protected code in the TEE.
In building a TEE, a processor at the bottom layer of the device is usually used as a hardware support, a container (container) which can only be accessed by the processor is built as a trusted execution environment, and protected code in a trusted application program is loaded in the container in an isolated manner, so that the protected code in the container is protected in an isolated manner.
For example, taking the SGX (Software Guard Extensions, software protection extension) technology of Intel as an example to build a TEE, based on the SGX technology, a program called Enclave is usually created as a protection container by taking a CPU of a device as a hardware support, and code to be protected is isolated and loaded in the Enclave program to protect the code from attacks.
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 the execution result of the protected code to the remote receiving object as trusted data based on a remote proving technology without revealing the protected code.
For example, in one scenario, assume that a smart contract deployed on a blockchain requires trusted computations on the blockchain with the execution result of protected code in the trusted application as input data; in this case, since the trusted application is not an on-chain node, it is a non-trusted party to the smart contract; thus, trusted applications, when sending the execution results of protected code to a smart contract deployed on a blockchain, need to rely on remote attestation techniques to attest to the smart contract that the execution results of the protected code are trusted data (i.e., on-chain attestation) on the basis of not revealing the protected code.
Based on the current remote attestation technology, when a trusted application program initiates remote attestation for specific data to a remote receiving object, a third party remote attestation server is usually required to be relied on for completion;
For example, still taking the remote attestation mechanism in Intel's SGX technology as an example, intel will provide an IAS (Intel attestation service, internet authentication service) server for a third party for remote attestation based on SGX technology. Isolating the execution result of the protected code loaded in the enclaspe, if the trusted computing needs to be participated, the trusted application can interact with an IAS server, initiate remote authentication of the execution result of the protected code to a remote receiving object through the IAS server, and prove that the execution result of the protected code is trusted data to the remote receiving object.
Because the third party remote attestation server is relied on to complete remote attestation, frequent interaction with the third party remote attestation server is required, and a more convenient remote attestation mechanism is required.
Based on this, the present specification proposes a remote attestation scheme that facilitates initiating execution results of protected code to a remote receiving object based on a public-private key pair that is 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., an enclaspe program in SGX technology) as a TEE based on a particular TEE construction technology (e.g., SGX technology in Intel) and load protected code in the trusted application into the target container in isolation.
Wherein, in the present solution, the protected code loaded in the target container is isolated, which may include the code to be executed, whose execution result needs to be remotely proven to the remote receiver, and the target function (essentially, some special codes for generating the private key and the public key) for generating the private key and the public key.
Further, the trusted application may invoke an objective function that quarantines the protected code loaded in the objective container, generating a pair of public and private keys in the objective container;
on the one hand, for the generated private key, encryption processing can be performed in the target container; when the generated private key is encrypted in the target container, a decryption policy that only the target container decrypts (i.e. only the target container has decryption authority) can be set for the encrypted private key; the encrypted private key is then persisted by the processor.
On the other hand, for the generated public key, a remote certification for the public key can be initiated to a remote receiving object through a third party remote certification server, 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 execution of the code to be executed is completed, 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 may obtain the execution result after the signature processing by the target container, and send the execution result to the remote receiving object to initiate remote attestation for the execution result.
After receiving the execution result sent by the trusted application, the remote receiving object can verify the 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 the one hand, since the public-private key pair for remote attestation is generated autonomously in the target container as a trusted execution environment, it is no longer generated by the software provider; and, the stored encrypted private key is persisted, set with the decryption policy that is decrypted 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 one-time remote certification for the autonomously generated public key to the remote receiving object through the third-party remote certification server, after the public key passes the remote certification, the generated private key can be directly used for signing an execution result of the code to be executed in the protected code, the signed execution result is sent to the remote receiving object to complete the remote certification for the execution result, and the third-party remote certification server is not needed to initiate the remote certification for the execution result to the remote receiving object; therefore, frequent interaction with the third-party remote proving server is not needed any more, and the execution result can be conveniently proving to the remote receiving object as trusted data based on the public and private key pair generated independently.
The following description is made by specific embodiments and with reference to specific application scenarios.
Referring to fig. 1, fig. 1 is a schematic diagram of a remote certification method of a trusted application according to an embodiment of the present disclosure, which is applied to the trusted application; protected code in the trusted application is isolated loaded in a target container that is a trusted execution environment; wherein the protected code comprises code to be executed, and an objective function for generating a private key and a public key; the method performs the steps of:
step 102, calling the objective function to generate a private key and a public key in the objective container, encrypting the generated private key, and storing the encrypted private key in a lasting manner; wherein the encrypted private key is set with a decryption policy that is only decrypted by the target container;
step 104, initiating remote certification for 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 an execution result of the code to be executed; the execution result is signed by the target container based on the decrypted private key;
Step 108, transmitting the execution result to the remote receiving object, so that the remote receiving object can verify the signature of the execution result based on the stored public key to confirm whether the execution result is trusted data.
The trusted application includes an application developed by a software developer that is capable of providing a trusted service to a third party; where the program code in the trusted application typically includes protected portions and is unprotected.
The above target container, in this specification, refers broadly to an isolated secure operating environment that is built based on a specific TEE building technology and is capable of providing security protection for protected code in a trusted application;
in practical application, the target container may be an isolated software environment supported by the processor as the bottom hardware and only accessible by the processor; for example, taking a TEE built by adopting the SGX technology of Intel as an example, the target container may specifically be an Enclave program in the SGX technology, and the protected code in the trusted application program is usually loaded into the Enclave program in an isolated manner to perform security protection on the protected code.
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 physical chip that is physically isolated, and the protected code in the trusted application may be isolated and loaded into the physical chip to secure the protected code.
It should be emphasized that, the TEE construction technique used in constructing the TEE is not particularly limited in this specification, and those skilled in the art can flexibly select based on actual development requirements. It will be appreciated that the specific form of the target container described above will also generally depend on TEE construction techniques 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 TEE building techniques employed by those skilled in the art; for example, if one skilled in the art uses Intel's SGX technology to build TEEs, the target container is an isolated software environment (i.e., an Enclave program) that is supported by the 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; for example, in practical application, the remote receiving object may be a separate trusted host or a trusted system; alternatively, it may be a smart contract deployed on a blockchain.
In the following embodiments, a TEE will be described by taking an Intel-based SGX technology as an example; it should be emphasized that, taking Intel-based SGX technology as an example to build a TEE, it is only illustrative; obviously, in practical application, other TEE construction techniques can be obviously adopted to construct the TEE; for example, trust zone technology such as ARM may also be used, and is not further listed in this specification.
In this specification, a software developer of a trusted application may create an Enclave program as a TEE based on Intel's SGX technology and load protected code in the trusted application in isolation in the target container.
It should be noted that, the specific implementation process of creating an enclaspe program based on SGX technology and isolating protected code from loading in the target container is not described in detail in this specification, and those skilled in the art may refer to descriptions in the related art when implementing the technical solution of this specification.
For protected code loaded in the Enclave program, it is commonly referred to as the Trusted region (Trusted Part) of the Trusted application; while other code that is not sequestered from being loaded in the Enclave program is referred to as the Untrusted portion (un-trusted Part) of the trusted application.
The protected code loaded in the Enclave program in an isolated manner at least comprises two parts, namely a code to be executed and an objective function;
the code to be executed is the protected code which is needed to be sent to a remote receiving object for trusted computing as an execution result; that is, the trusted application needs to prove the execution result of the code to be executed as trusted data to the remote receiving object through a trusted proving technology. And the objective 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 execution results of protected code to a remote receiving object, typically by interacting with a deployed IAS server.
In this specification, the remote attestation of the execution result of the protected code may be initiated to the remote receiving object by interacting with the IAS server instead of using the existing remote attestation mechanism in the SGX technology, and the remote attestation of the public-private key pair independently generated in the Enclave program may be initiated to the remote receiving object only once by using the existing remote attestation mechanism, and then after the remote attestation of the public-private key pair passes, the remote attestation of the execution result of the protected code may be initiated to the remote receiving object based on the public-private key pair without interacting with the IAS.
In the initial state, the untrusted region of the trusted application program can call an objective function in protected code loaded in the Enclave program in an ECALL mode, and a pair of public keys and private keys are generated inside the Enclave program.
The non-trusted region is called for isolating the target function in the protected code loaded in the Enclave program by means of ECALL, and can be called in real time when executing the code to be executed in the protected code, or can be called periodically based on a certain calling period.
For example, in one implementation, when the untrusted region receives an execution instruction for a code to be executed in the protected code, the untrusted region may respond to the execution instruction in real time, and immediately call, by means of ECALL, an objective function in the protected code loaded in the Enclave program in isolation, and generate a pair of public key and private key inside the Enclave.
In another implementation manner, a calling period may be preset for the untrusted region, so that the untrusted region may periodically call the objective function in the protected code loaded in the Enclave program based on the calling period, and generate a pair of public key and private key inside the Enclave program. In this way, the public and private keys of the Enclave program can be updated regularly.
On the one hand, for the generated private key, the processor can carry out encryption processing (the secret key is held by the processor) in the enclaspe program, the processor sets a decryption strategy for the encrypted private key, and then the encrypted private key is stored in a holding way;
the decryption policy for the encrypted information generally includes two policies, namely a key policy-mrencycloave (hereinafter referred to as mrencycloave policy) and a key policy-mrigner (hereinafter referred to as mrigner) based on the SGX technology.
The MRENCLAVE strategy refers to that only the current ENCLAVE strategy can be decrypted; by mrstiner policy, however, is meant that all ENCLAVEs that can be developed and signed by the same developer are decrypted.
Because of adopting MRSIGNER strategy, need trust the developer; therefore, for a malicious person who obtains the private key of the developer, by developing a malicious ENCLAVE and signing the malicious ENCLAVE based on the grasped private key of the developer, the encrypted private key can be decrypted through the malicious ENCLAVE, thereby causing the leakage of plaintext data of the encrypted private key.
Based on this, in this specification, when the processor sets a decryption policy for the encrypted private key, the decryption policy may be set as an MRENCLAVE policy; 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 obtain the private key independently generated by ENCLAVE, so that the security level of the private key can be obviously improved.
On the other hand, for the generated public key, the trusted area of the trusted execution program can initiate remote certification for the public key to the remote receiving object through the IAS server, 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.
Based on SGX technology, when a trusted zone of a trusted execution program initiates remote certification for the public key to a remote receiving object, a Quote serving as a remote certification certificate can be created firstly based on the generated public key or the hash value of the public key;
for example, based on SGX technology, the above-mentioned query is usually internally interacted by enclaspe and a special query enclaspe, which is created by the query enclaspe. The specific implementation process of the Quote for remote attestation is created for Enclave by the QuoteEnclave, and is not described in detail in the present specification, and those skilled in the art can refer to the technology in the related art when putting the technical solution of the present specification into practice.
In this specification, the finished quantum is finally created by information that may include EPID signature, generated public key or hash value of public key (i.e. userdata requiring remote attestation), MRENCLAVE identification, EPID identification of processor, etc.
That is, the finally created quantum is information obtained by performing EPID signing on the generated public key or the hash value of the public key (i.e. user data needing remote attestation), the mrencleave identifier, the EPID identifier of the processor, and other information.
Wherein the MRENCLAVE identifier, typically a hash value of an Enclave code, is used to uniquely identify an Enclave. EPID identification, also known as basense, is used to anonymously identify a processor. While EPID signature is a group signature technology that can be kept anonymous and is adopted by Intel's SGX technology, the signature processing procedure for EPID signature and the signature verification procedure for EPID signature in this specification will not be 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 proof certificate, the Quote may be sent to an IAS server for remote verification by a trusted zone of a trusted execution program. After the IAS server receives the Quote, the EPID signature of the Quote can be verified, and then the Quote and the verification result aiming at the Quote are subjected to signature processing integrally based on a private key held by the IAS server to generate a corresponding AVR (Attestation Verification Report, proof verification report).
That is, in the present specification, the AVR may generally include the information of the Quote, the Quote verification result, the IAS signature, and the like.
In this specification, the IAS server may return the generated AVR to the trusted area of the trusted execution program, and after receiving the AVR returned by the IAS server, the trusted area of the trusted execution program may further send the AVR and the public key generated by calling the objective function to the remote receiving object.
Alternatively, the trusted region of the trusted execution program may further send the AVR and the public key generated by calling the objective function to the untrusted region of the trusted execution program, and the untrusted region may further send the AVR and the public key generated by calling the objective function to the remote receiving object.
After receiving the AVR sent by the trusted area of the trusted execution program, the remote receiving object can verify the state of the AVR first; for example, verifying whether the value of the status field in the AVR is a specific value indicating that the AVR is in a normal state; after the state verification of the AVR passes, the IAS signature of the AVR may 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 key or the hash value of the public key in the Quote carried in the AVR, the MRENCLAVE identifier, the EPID identifier of the processor and other information can be further verified at the moment.
The verification of the public key or the hash value of the public key in the Quote is a process of verifying whether the public key or the hash value of the public key in the Quote is matched with the public key sent by the trusted execution program in the trusted area; 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 area 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, then the verification can be confirmed to pass.
The verification of the MRENCLAVE identifier, the EPID of the processor and other information in the quantum is a process of verifying whether the processor corresponding to the MRENCLAVE identifier is credible or not.
When the method is realized, a developer of the Enclave 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 carry out security audit on the open source Enclave code, and an MRENCLAVE white list is set for the remote receiving object. Also, an EPID identification white list can be set for the remote receiving object according to actual requirements. Thus, when verifying information such as MRENCLAVE identification in the Quote and EPID identification of the processor, the remote receiving object can confirm whether the processor corresponding to the MRENCLAVE identification and the EPID of the processor are trusted or not by matching the MRENCLAVE identification in the Quote with the MRENCLAVE white list and matching the EPID identification of the processor in the Quote with the EPID identification white list.
With continued reference to FIG. 2, when the IAS of the AVR is signed; after the public key or the hash value of the public key, the MRENCLAVE identifier, the EPID identifier of the processor and other information in the quantum carried in the AVR pass verification, the remote receiving object can locally and durably store the public key, the MRENCLAVE and the EPID which are sent by the trusted area of the trusted execution program and are generated by calling the objective function.
That is, mrencleave corresponding to the public key generated by calling the objective function is used as a trusted program identifier, EPID corresponding to the public key is used as a trusted hardware identifier, and the EPID and the public key are stored in a persistent manner.
In this specification, after the remote receiving object performs persistent storage locally by using the public key generated by using the objective function, the subsequent trusted application may no longer need to interact with the IAS server to initiate remote attestation of the execution result of the code to be executed, but may directly initiate remote attestation of the execution result of the protected code to the remote receiving object by using the public-private key pair created by using the objective function.
Specifically, when the execution of the code to be executed, which is loaded in the enclaspe, is completed, the enclaspe may decrypt the encrypted private key that is already stored in a persistent manner (only the enclaspe has the decryption authority), and perform signature processing on the execution result of the code to be executed based on the decrypted private key.
In practical application, the execution result may include the output result of the code to be executed after the execution is completed, and other information may be introduced; the signature processing can be carried out on other information except the output result of the code to be executed as a part of the execution result according to the actual service requirement, and then the remote authentication is initiated; for example, in one example, the signature processing may be performed on input data of the code to be executed (for example, an execution parameter input by the code to be executed when the code to be executed is executed) as part of the execution result.
And the non-trusted area of the trusted application program can acquire the execution result after the Enclave signature processing, directly send the execution result to a remote receiving object, and initiate remote certification for the execution result.
Of course, in practical application, the trusted area of the trusted application may directly send the execution result after the signature processing to the remote receiving object, and initiate remote certification for the execution result.
And after receiving the execution result, the remote receiving object can verify the signature of the execution result based on the public key (namely, the public key generated by calling the objective function) stored in the local persistence; if the signature verification is passed, the execution result can be directly determined as trusted data generated by a 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 mode, when the remote receiving object remotely proves the execution result of the code to be executed, interaction with the IAS server is not needed, and therefore remote proving can be completed more conveniently.
In the above technical solution, on the one hand, since the public-private key pair for remote attestation is generated autonomously in the target container as a trusted execution environment, it is no longer generated by the software provider; and, the stored encrypted private key is persisted, set with the decryption policy that is decrypted 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 one-time remote certification for the autonomously generated public key to the remote receiving object through the third-party remote certification server, after the public key passes the remote certification, the generated private key can be directly used for signing an execution result of the code to be executed in the protected code, the signed execution result is sent to the remote receiving object to complete the remote certification for the execution result, and the third-party remote certification server is not needed to initiate the remote certification for the execution result to the remote receiving object; therefore, frequent interaction with the third-party remote proving server is not needed any more, and the execution result can be conveniently proving to the remote receiving object as trusted data based on the public and private key pair generated independently.
Corresponding to the above method embodiments, the present specification also provides an embodiment of a remote attestation device for trusted applications. Embodiments of the remote attestation apparatus of the trusted application of the present specification may be applied to an electronic device. The apparatus embodiments may be implemented by software, or may be implemented by hardware or a combination of hardware and software. Taking software implementation as an example, the device in a logic sense is formed by reading corresponding computer program instructions in a nonvolatile memory into a memory by a processor of an electronic device where the device is located for operation. In terms of hardware, as shown in fig. 2, a hardware structure diagram of an electronic device where a remote certification device for a trusted application in the present specification is located is shown in fig. 2, and the electronic device where the device is located in the embodiment generally includes other hardware according to the actual function of the electronic device, except for a processor, a memory, a network interface, and a nonvolatile memory shown in fig. 2, which will not be described again.
Fig. 3 is a block diagram of a remote attestation device of a trusted application as shown in an exemplary embodiment of the present description.
Referring to fig. 3, the remote attestation device 30 of the trusted application may be applied to the electronic apparatus shown in fig. 2; wherein the protected code in the trusted application is isolated loaded in a target container that is a trusted execution environment; the protected code comprises code to be executed and an objective function for generating a private key and a public key;
The device 30 comprises:
the generating module 301 calls the objective function to generate a private key and a public key in the objective container, encrypts the generated private key, and stores the encrypted private key in a lasting manner; wherein the encrypted private key is set with a decryption policy that is only decrypted by the target container;
the certification module 302 initiates 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; the execution result is signed by the target container based on the decrypted private key;
and a verification module 304, configured to 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 trusted data.
In this embodiment, the generating module 301:
responding to the execution instruction of the code to be executed, and calling the objective function to generate a private key and a public key in the objective container; or alternatively, the process may be performed,
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;
transmitting the remote proof credential to the third party remote proof server for verification of the remote proof credential by the remote proof server;
obtaining a verification result returned by the remote proving server; the verification result is signed by the remote proving server based on the held private key;
and sending the verification result and the generated public key to the remote receiving object so that the remote receiving object can verify the signature of the verification result at least based on the public key of the third-party remote proving server, and after the signature verification is passed, storing the generated public key in a lasting mode locally to the remote receiving object.
In this embodiment, the trusted execution environment is a trusted execution environment set up based on an SGX technology; the target container is an Enclave program in SGX technology; the decryption strategy of the private key after encryption is set as a key policy-MRENCLAVE strategy.
In this embodiment, the remote receiving object is a smart contract issued to a blockchain.
The implementation process of the functions and roles of each module in the above device is specifically shown in the implementation process of the corresponding steps in the above method, and will not be described herein again.
For the device embodiments, reference is made to the description of the method embodiments for the relevant points, since they essentially correspond to the method embodiments. The apparatus embodiments described above are merely illustrative, wherein the modules illustrated as separate components may or may not be physically separate, and the components shown as modules may or may not be physical, i.e., may be located in one place, or may be distributed over a plurality of network modules. Some or all of the modules may be selected according to actual needs to achieve the purposes of the present description. Those of ordinary skill in the art will understand and implement the present invention without undue burden.
The system, apparatus, module or module set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having some function. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination of any of these devices.
Corresponding to the method embodiment described above, 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 this embodiment, the protected code in the trusted application is isolated loaded in a target container that is a trusted execution environment; wherein the protected code comprises code to be executed, and an objective function for generating a private key and a public key;
by reading and executing machine-executable instructions stored in the memory corresponding to remotely proven control logic of a trusted application, the processor is caused to:
calling the objective function to generate a private key and a public key in the objective container, encrypting the generated private key, and storing the encrypted private key in a lasting way; wherein the encrypted private key is set with a decryption policy that is only decrypted by the target container;
A third-party remote proving server initiates remote proving for the public key to a remote receiving object, and when the public key passes the remote proving, the public key is sent to the remote receiving object for persistent storage;
acquiring an execution result of the code to be executed; 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 based on the stored public key by the remote receiving object to confirm whether the execution result is trusted data.
In this embodiment, the processor is caused to, by reading and executing machine-executable instructions stored in the memory corresponding to control logic for remote attestation of a trusted application:
responding to the execution instruction of the code to be executed, and calling the objective function to generate a private key and a public key in the objective container; or alternatively, the process may be performed,
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 in the memory corresponding to control logic for remote attestation of a trusted application:
Creating a remote attestation credential based on the generated public key;
transmitting the remote proof credential to the third party remote proof server for verification of the remote proof credential by the remote proof server;
obtaining a verification result returned by the remote proving server; the verification result is signed by the remote proving server based on the held private key;
and sending the verification result and the generated public key to the remote receiving object so that the remote receiving object can verify the signature of the verification result at least based on the public key of the third-party remote proving server, and after the signature verification is passed, storing the generated public key in a lasting mode locally to the remote receiving object.
Other embodiments of the present disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the invention 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 is to be understood that the present description is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, 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 foregoing description of the preferred embodiments is provided for the purpose of illustration only, and is not intended to limit the scope of the disclosure, since any modifications, equivalents, improvements, etc. that fall within the spirit and principles of the disclosure are intended to be included within the scope of the disclosure.
Claims (9)
1. A remote attestation method of a trusted application, protected code in the trusted application being isolated loaded in a target container as a trusted execution environment; the protected code comprises code to be executed and an objective function for generating a private key and a public key; the method comprises the following steps:
calling the objective function to generate a private key and a public key in the objective container, encrypting the generated private key, and storing the encrypted private key in a lasting way; wherein the encrypted private key is provided with a decryption policy that is only decrypted by the target container;
initiating remote certification for the public key to an intelligent contract issued to a blockchain through a third-party remote certification server, and sending the public key to the intelligent contract for persistent storage when the public key passes the remote certification;
Acquiring an execution result of the code to be executed; the execution result is signed by the target container based on the private key obtained by decryption;
and sending the execution result to the intelligent contract to verify the signature of the execution result based on the stored public key by the intelligent contract, and taking the execution result as input data to execute trusted computing on a blockchain when the verification is passed.
2. The method of claim 1, invoking the objective function to generate a private key and a public key in the objective container, comprising:
responding to the execution instruction of the code to be executed, and calling the objective function to generate a private key and a public key in the objective container; or alternatively, the process may be performed,
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 for the public key to a smart contract issued to a blockchain, and sending the public key to the smart contract for persistent storage when the public key passes remote attestation, comprising:
Creating a remote attestation credential based on the generated public key;
the remote proof certificate is sent to the third-party remote proof server to be verified by the third-party remote proof server;
obtaining a verification result returned by the third party remote proof server; the verification result is signed by the third-party remote proof service terminal based on the held private key;
and sending the verification result and the generated public key to the intelligent contract so that the intelligent contract can verify the signature of the verification result at least based on the public key of the third-party remote proving server, and after the signature verification is passed, the generated public key is stored in the storage space of the intelligent contract in a lasting mode.
4. A method according to claim 1 or 3, the trusted execution environment being a trusted execution environment built based on SGX technology; the target container is an Enclave program in SGX technology.
5. A remote attestation device of a trusted application, protected code in the trusted application being quarantined loaded in a target container as a trusted execution environment; the protected code comprises code to be executed and an objective function for generating a private key and a public key; the device comprises:
The generation 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 storing the encrypted private key in a lasting mode; wherein the encrypted private key is provided with a decryption policy that is only decrypted by the target container;
the certification module initiates remote certification for the public key to an intelligent contract issued to a blockchain through a third-party remote certification server, and sends the public key to the intelligent contract for persistent storage when the public key passes the remote certification;
the acquisition module acquires an execution result of the code to be executed; the execution result is signed by the target container based on the private key obtained by decryption;
and the verification module is used for sending the execution result to the intelligent contract so as to verify the signature of the execution result based on the stored public key by the intelligent contract, and when the verification is passed, the execution result is used as input data to execute trusted computation on a blockchain.
6. The apparatus of claim 5, the generation module to:
responding to the execution instruction of the code to be executed, and calling the objective function to generate a private key and a public key in the objective container; or alternatively, the process may be performed,
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.
7. The apparatus of claim 5, the attestation module to:
creating a remote attestation credential based on the generated public key;
the remote proof certificate is sent to the third-party remote proof server to be verified by the third-party remote proof server;
obtaining a verification result returned by the third party remote proof server; the verification result is signed by the third-party remote proof service terminal based on the held private key;
and sending the verification result and the generated public key to the intelligent contract so that the intelligent contract can verify the signature of the verification result at least based on the public key of the third-party remote proving server, and after the signature verification is passed, the generated public key is stored in the storage space of the intelligent contract in a lasting mode.
8. The apparatus according to claim 5 or 7, the trusted execution environment being a trusted execution environment built based on SGX technology; the target container is an Enclave program in SGX technology.
9. An electronic device, comprising:
a processor;
a memory for storing machine-executable instructions;
wherein protected code in the trusted application is isolated 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 of remote attestation of a blockchain-based trusted application; the protected code comprises code to be executed and an objective function for generating a private key and a public key; the processor is caused to:
calling the objective function to generate a private key and a public key in the objective container, encrypting the generated private key, and storing the encrypted private key in a lasting way; wherein the encrypted private key is provided with a decryption policy that is only decrypted by the target container; initiating remote certification for the public key to an intelligent contract issued to a blockchain through a third-party remote certification server, and sending the public key to the intelligent contract for persistent storage when the public key passes the remote certification; the intelligent contract is about an intelligent contract issued to a blockchain;
acquiring an execution result of the code to be executed; the execution result is signed by the target container based on the private key obtained by decryption;
And sending the execution result to the intelligent contract to verify the signature of the execution result based on the stored public key by the intelligent contract, and taking the execution result as input data to execute trusted computing on a blockchain when the verification is passed.
Priority Applications (1)
| 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 |
Applications Claiming Priority (2)
| 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 |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811364461.1A Division CN110011801B (en) | 2018-11-16 | 2018-11-16 | Remote certification method and device for trusted application program and electronic equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112468473A CN112468473A (en) | 2021-03-09 |
| CN112468473B true CN112468473B (en) | 2023-10-24 |
Family
ID=67164919
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811364461.1A Active CN110011801B (en) | 2018-11-16 | 2018-11-16 | Remote certification method and device for trusted application program and electronic equipment |
| CN202011295708.6A Active CN112468473B (en) | 2018-11-16 | 2018-11-16 | Remote proving method and device for trusted application program and electronic equipment |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811364461.1A Active CN110011801B (en) | 2018-11-16 | 2018-11-16 | Remote certification method and device for trusted application program and electronic equipment |
Country Status (3)
| Country | Link |
|---|---|
| CN (2) | CN110011801B (en) |
| TW (1) | TWI716078B (en) |
| WO (1) | WO2020098377A1 (en) |
Families Citing this family (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110430051B (en) * | 2019-08-01 | 2022-08-05 | 北京永新视博数字电视技术有限公司 | Key storage method, device and server |
| 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 |
| CN111049825B (en) * | 2019-12-12 | 2021-11-30 | 支付宝(杭州)信息技术有限公司 | Secure multi-party computing method and system based on trusted execution environment |
| CN110890962B (en) * | 2019-12-20 | 2021-04-13 | 支付宝(杭州)信息技术有限公司 | Authentication key negotiation method, device, storage medium and equipment |
| CN111382445B (en) * | 2020-03-03 | 2023-04-07 | 首都师范大学 | Method for providing trusted service by using trusted execution environment system |
| CN111988141B (en) * | 2020-03-18 | 2022-08-02 | 支付宝(杭州)信息技术有限公司 | Method and device for sharing cluster key |
| CN111092726B (en) * | 2020-03-18 | 2020-07-28 | 支付宝(杭州)信息技术有限公司 | Method and device for generating shared contract key |
| CN111090888B (en) * | 2020-03-18 | 2020-07-07 | 支付宝(杭州)信息技术有限公司 | Contract verification 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 |
| CN113395159B (en) * | 2021-01-08 | 2024-03-12 | 腾讯科技（深圳）有限公司 | Data processing method based on trusted execution environment and related device |
| CN114884647B (en) * | 2021-01-22 | 2024-02-20 | 腾讯科技（深圳）有限公司 | Network access management method and related equipment |
| CN112507034B (en) * | 2021-02-07 | 2021-06-01 | 支付宝(杭州)信息技术有限公司 | Data storage method and system |
| CN113343234B (en) * | 2021-06-10 | 2023-01-20 | 支付宝(杭州)信息技术有限公司 | Method and device for carrying out credible check on code security |
| CN113672973B (en) * | 2021-07-20 | 2024-04-16 | 深圳大学 | Database system of embedded device based on RISC-V architecture of trusted execution environment |
| CN114090981B (en) * | 2021-11-29 | 2023-04-07 | 深圳前海微众银行股份有限公司 | Access method and device for remote host |
| CN113987554B (en) * | 2021-12-23 | 2022-04-08 | 支付宝(杭州)信息技术有限公司 | Method, device and system for obtaining data authorization |
| CN114422215A (en) * | 2021-12-31 | 2022-04-29 | 国网安徽省电力有限公司合肥供电公司 | Cross-platform and trusted energy data sharing system and method based on block chain |
| 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 |
| 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 |
| CN116112187B (en) * | 2023-04-10 | 2023-07-14 | 山东海量信息技术研究院 | Remote proving method, device, equipment and readable storage medium |
| CN116846682B (en) * | 2023-08-29 | 2024-01-23 | 山东海量信息技术研究院 | Communication channel establishment method, device, equipment and medium |
| CN117454437B (en) * | 2023-12-22 | 2024-03-22 | 北京天润基业科技发展股份有限公司 | Transaction processing method, storage medium and electronic device |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101043338A (en) * | 2007-04-27 | 2007-09-26 | 中国科学院软件研究所 | Safety requirement based remote proving method and system thereof |
| CN101951388A (en) * | 2010-10-14 | 2011-01-19 | 中国电子科技集团公司第三十研究所 | Remote attestation method in credible computing environment |
| CN104333541A (en) * | 2014-10-21 | 2015-02-04 | 广东金赋信息科技有限公司 | Trusted self-help service system |
| CN104333451A (en) * | 2014-10-21 | 2015-02-04 | 广东金赋信息科技有限公司 | Trusted self-help service system |
| CN107395366A (en) * | 2017-08-08 | 2017-11-24 | 沈阳东青科技有限公司 | A kind of Efficient Remote method of proof towards industry control credible calculating platform |
| CN108390866A (en) * | 2018-02-06 | 2018-08-10 | 南京航空航天大学 | Trusted remote method of proof based on the two-way anonymous authentication of dual-proxy |
| CN108462689A (en) * | 2017-02-22 | 2018-08-28 | 英特尔公司 | Technology for the certification of the long-range enclaves SGX |
Family Cites Families (20)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101908115B (en) * | 2010-07-30 | 2013-09-11 | 中国船舶重工集团公司第七0九研究所 | Method for realizing software trusted execution based on trusted platform module |
| US20140281500A1 (en) * | 2013-03-15 | 2014-09-18 | Ologn Technologies Ag | Systems, methods and apparatuses for remote attestation |
| US9521125B2 (en) * | 2014-03-13 | 2016-12-13 | Intel Corporation | Pseudonymous remote attestation utilizing a chain-of-trust |
| 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 |
| CN105812332A (en) * | 2014-12-31 | 2016-07-27 | 北京握奇智能科技有限公司 | Data protection method |
| US11829998B2 (en) * | 2016-06-07 | 2023-11-28 | Cornell University | Authenticated data feed for blockchains |
| WO2018006072A1 (en) * | 2016-06-30 | 2018-01-04 | Clause, Inc. | Systems 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 |
| US10833858B2 (en) * | 2017-05-11 | 2020-11-10 | Microsoft Technology Licensing, Llc | Secure cryptlet tunnel |
| CN107342858B (en) * | 2017-07-05 | 2019-09-10 | 武汉凤链科技有限公司 | A kind of intelligent contract guard method and system based on trusted context |
| CN107463838B (en) * | 2017-08-14 | 2019-10-18 | 广州大学 | Method for safety monitoring, device, system and storage medium based on SGX |
| CN107919954B (en) * | 2017-10-20 | 2019-05-14 | 浙江大学 | A kind of block chain user key guard method and device based on SGX software protecting extended instruction |
| CN108055133B (en) * | 2017-12-12 | 2020-02-14 | 江苏安凰领御科技有限公司 | Key security signature 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 |
-
2018
- 2018-11-16 CN CN201811364461.1A patent/CN110011801B/en active Active
- 2018-11-16 CN CN202011295708.6A patent/CN112468473B/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 (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101043338A (en) * | 2007-04-27 | 2007-09-26 | 中国科学院软件研究所 | Safety requirement based remote proving method and system thereof |
| CN101951388A (en) * | 2010-10-14 | 2011-01-19 | 中国电子科技集团公司第三十研究所 | Remote attestation method in credible computing environment |
| CN104333541A (en) * | 2014-10-21 | 2015-02-04 | 广东金赋信息科技有限公司 | Trusted self-help service system |
| CN104333451A (en) * | 2014-10-21 | 2015-02-04 | 广东金赋信息科技有限公司 | Trusted self-help service system |
| CN108462689A (en) * | 2017-02-22 | 2018-08-28 | 英特尔公司 | Technology for the certification of the long-range enclaves SGX |
| CN107395366A (en) * | 2017-08-08 | 2017-11-24 | 沈阳东青科技有限公司 | A kind of Efficient Remote method of proof towards industry control credible calculating platform |
| CN108390866A (en) * | 2018-02-06 | 2018-08-10 | 南京航空航天大学 | Trusted remote method of proof based on the two-way anonymous authentication of dual-proxy |
Non-Patent Citations (1)
| Title |
|---|
| 《可信计算中远程自动匿名证明的研究》;刘吉强等;《计算机学报》;20090715;第32卷(第7期);正文1-7页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2020098377A1 (en) | 2020-05-22 |
| CN112468473A (en) | 2021-03-09 |
| TW202021306A (en) | 2020-06-01 |
| CN110011801A (en) | 2019-07-12 |
| TWI716078B (en) | 2021-01-11 |
| CN110011801B (en) | 2020-10-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112468473B (en) | Remote proving method and device for trusted application program and electronic equipment | |
| US11921911B2 (en) | Peripheral device | |
| US9867043B2 (en) | Secure device service enrollment | |
| JP5497171B2 (en) | System and method for providing a secure virtual machine | |
| CN107077574B (en) | Trust service for client devices | |
| WO2022073264A1 (en) | Systems and methods for secure and fast machine learning inference in trusted execution environment | |
| US9673979B1 (en) | Hierarchical, deterministic, one-time login tokens | |
| CN108781210A (en) | Mobile device with credible performing environment | |
| US20140013109A1 (en) | Secure delivery of trust credentials | |
| CN107005407B (en) | Remote password service using TPM of server | |
| US11212095B2 (en) | Allowing restricted external access to devices | |
| CN111523110A (en) | Permission query configuration method and device based on chain codes | |
| EP3674938A2 (en) | Identifying computing processes on automation servers | |
| Cooijmans et al. | Secure key storage and secure computation in Android | |
| CN117453343A (en) | Virtual machine measurement and secret calculation authentication method, device, system and storage medium | |
| Shepherd et al. | Remote credential management with mutual attestation for trusted execution environments | |
| KR20150089696A (en) | Integrity Verification System and the method based on Access Control and Priority Level | |
| WO2022162797A1 (en) | Information processing device, program execution system, information processing method, and program | |
| CN116346341A (en) | Private key protection and server access method, system, equipment and storage medium | |
| CN117579331A (en) | Remote proving method, device, electronic equipment and storage medium | |
| Uzunay et al. | Trust-in-the-middle: towards establishing trustworthiness of authentication proxies using trusted computing | |
| WO2022157501A1 (en) | A system and method for trustless key provisioning | |
| Giweli | Enhancing cloud computing security and privacy | |
| Sharma et al. | An implementation for conserving privacy based on encryption process to secured cloud computing environment | |
| DADHICH | HARDWARE ROOT OF TRUST BASED TPM: THE INHERENT OF 5IRECHAIN SECURITY |
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 | ||
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40047466 Country of ref document: HK |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |