CN110011801B - Remote certification method and device for trusted application program and electronic equipment - Google Patents
Remote certification method and device for trusted application program and electronic equipment Download PDFInfo
- Publication number
- CN110011801B CN110011801B CN201811364461.1A CN201811364461A CN110011801B CN 110011801 B CN110011801 B CN 110011801B CN 201811364461 A CN201811364461 A CN 201811364461A CN 110011801 B CN110011801 B CN 110011801B
- Authority
- CN
- China
- Prior art keywords
- public key
- remote
- private key
- trusted
- 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
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 remote attestation method of a trusted application program, wherein protected codes in the trusted application program are isolated and loaded in a target container as a trusted execution environment; the protected code comprises code to be executed and an objective function; 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; 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 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 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; the remote receiving object is an intelligent contract issued to a block chain;
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; alternatively, the first and second electrodes may be,
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 third-party remote attestation server;
obtaining a verification result returned by the third-party remote certification server; the verification result is signed by the third party remote certification service terminal 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.
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 remote receiving object is an intelligent contract issued to a block chain;
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; alternatively, the first and second electrodes may be,
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 third-party remote attestation server;
obtaining a verification result returned by the third-party remote certification server; the verification result is signed by the third party remote certification service terminal 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.
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; the remote receiving object is an intelligent contract issued to a block chain;
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;
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 can also be used, and this description is not repeated.
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 putting the technical solution in this specification into practice.
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; alternatively, the first and second electrodes may be,
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; alternatively, the first and second electrodes may be,
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 (7)
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 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 protected code comprises a code to be executed and a target function 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; the decryption policy comprises a keypolar-mrencave policy;
initiating remote certification aiming at the public key to an intelligent contract issued to a block chain 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; wherein the execution result is signed by the target container based on the decrypted private key;
sending the execution result to the intelligent contract to verify a signature of the execution result by the intelligent contract based on the stored public key to confirm whether the execution result is trusted data; and when the execution result is determined to be the trusted data, executing trusted computation on the block chain by taking the execution result as input 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; alternatively, the first and second electrodes may be,
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 an intelligent contract issued to a blockchain, and sending the public key to the intelligent contract 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 third-party remote attestation server;
obtaining a verification result returned by the third-party remote certification server; the verification result is signed by the third party remote certification service terminal based on a held private key;
and sending the verification result and the generated public key to the intelligent contract, verifying the signature of the verification result by the intelligent contract at least based on the public key of the third-party remote attestation server, and after the signature verification is passed, persistently storing the generated public key in the storage space of the intelligent contract.
4. 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 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 protected code comprises a code to be executed and a target function 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 decryption policy comprises a keypolar-mrencave policy;
the certification module initiates a remote certification for the public key to the intelligent contract issued to the block chain 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 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 intelligent contract so as to verify the signature of the execution result based on the stored public key by the intelligent contract to confirm whether the execution result is credible data.
5. The apparatus of claim 4, 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; alternatively, the first and second electrodes may be,
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.
6. The apparatus of claim 4, 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 third-party remote attestation server;
obtaining a verification result returned by the third-party remote certification server; the verification result is signed by the third party remote certification service terminal based on a held private key;
and sending the verification result and the generated public key to the intelligent contract, verifying the signature of the verification result by the intelligent contract at least based on the public key of the third-party remote attestation server, and after the signature verification is passed, persistently storing the generated public key in the storage space of the intelligent contract.
7. 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 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 protected code comprises a code to be executed and a target function 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; the decryption policy comprises a keypolar-mrencave policy;
initiating remote certification aiming at the public key to an intelligent contract issued to a block chain 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 contracts are intelligent contracts issued to the blockchain;
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 intelligent contract to verify the signature of the execution result based on the stored public key by the intelligent contract to confirm whether the execution result is credible data.
Priority Applications (4)
| 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 |
| CN202011295708.6A CN112468473B (en) | 2018-11-16 | 2018-11-16 | Remote proving 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 CN110011801A (en) | 2019-07-12 |
| CN110011801B true CN110011801B (en) | 2020-10-20 |
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 After (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) | 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 |
| CN111092727B (en) * | 2020-03-18 | 2020-07-17 | 支付宝(杭州)信息技术有限公司 | Method and device for sharing cluster key |
| CN111090888B (en) * | 2020-03-18 | 2020-07-07 | 支付宝(杭州)信息技术有限公司 | Contract verification method and device |
| CN111092726B (en) * | 2020-03-18 | 2020-07-28 | 支付宝(杭州)信息技术有限公司 | Method and device for generating shared contract key |
| 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 (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| 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 |
Family Cites Families (23)
| 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 |
| CA2902285A1 (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 |
| 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 |
| US9536093B2 (en) * | 2014-10-02 | 2017-01-03 | Microsoft Technology Licensing, Llc | Automated verification of a software system |
| 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 |
| 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 |
| US10445698B2 (en) * | 2016-06-30 | 2019-10-15 | Clause, Inc. | System and method for forming, storing, managing, and executing contracts |
| US10341116B2 (en) * | 2016-12-28 | 2019-07-02 | Intel Corporation | Remote attestation with hash-based signatures |
| US20180241572A1 (en) * | 2017-02-22 | 2018-08-23 | Intel Corporation | Techniques for remote sgx enclave authentication |
| DE102018101307A1 (en) * | 2017-02-22 | 2018-08-23 | Intel Corporation | SGX enclave remote authentication techniques |
| 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 |
| 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 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 (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| 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 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110011801A (en) | 2019-07-12 |
| TW202021306A (en) | 2020-06-01 |
| TWI716078B (en) | 2021-01-11 |
| CN112468473B (en) | 2023-10-24 |
| CN112468473A (en) | 2021-03-09 |
| WO2020098377A1 (en) | 2020-05-22 |
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 | |
| JP5497171B2 (en) | System and method for providing a secure virtual machine | |
| US10491384B2 (en) | Device for secure multi-party cryptographic authorization | |
| EP3061027B1 (en) | Verifying the security of a remote server | |
| US9009463B2 (en) | Secure delivery of trust credentials | |
| KR101313480B1 (en) | Apparatus and methods for providing authorized device access | |
| CN111654367B (en) | Method for cryptographic operation and creation of working key, cryptographic service platform and device | |
| CN110580245B (en) | Private data sharing method and device | |
| CN108781210A (en) | Mobile device with credible performing environment | |
| US20130151848A1 (en) | Cryptographic certification of secure hosted execution environments | |
| WO2022073264A1 (en) | Systems and methods for secure and fast machine learning inference in trusted execution environment | |
| CN111542820A (en) | Method and apparatus for trusted computing | |
| CN111523110A (en) | Permission query configuration method and device based on chain codes | |
| CN112632573A (en) | Intelligent contract execution method, device and system, storage medium and electronic equipment | |
| Cooijmans et al. | Secure key storage and secure computation in Android | |
| CN109150811A (en) | A kind of method and device that realizing credible session calculates equipment | |
| 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 | |
| Long et al. | Using amazon managed blockchain for ePHI an analysis of hyperledger fabric and ethereum | |
| CN115270159A (en) | Intelligent contract calling method, device and equipment for block chain and storage medium | |
| Hao et al. | Trusted block as a service: Towards sensitive applications on the cloud | |
| CN115174099A (en) | Copyright asset authorization method and device based on block chain and electronic equipment |
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 |
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. |
|
| TA01 | Transfer of patent application right |