WO2022257722A1

WO2022257722A1 - Method and apparatus for performing trust check on code security

Info

Publication number: WO2022257722A1
Application number: PCT/CN2022/093834
Authority: WO
Inventors: 姚经纬; 杨文玉; 肖枭; 杨孙鑫
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2021-06-10
Filing date: 2022-05-19
Publication date: 2022-12-15
Also published as: CN113343234A; CN113343234B

Abstract

Provided in one or more embodiments of the present description are a method and apparatus for performing a trust check on code security. According to one example of the method, in response to a remote verification challenge initiated by a code demander, a code provider generates a remote verification report with respect to a trusted program, and in response to a code check request initiated by the code demander, the code provider loads the trusted program, such that the trusted program scans a code to be checked, so as to generate a code check report, and generates, by using an identity private key of the trusted program itself, a digital signature for anchoring the code check report; and the code demander determines, on the basis of the remote verification report, whether a running environment of the trusted program can be trusted, and performs signature verification on the digital signature by using an identity public key of the trusted program, and then determines, according to the code check report, whether said code is secure.

Description

Method and device for credible checking of code security

technical field

One or more embodiments of this specification relate to the field of code security, and in particular, to a method and device for authenticity checking of code security.

Background technique

In the process of digital reform, enterprises will recruit a large number of software outsourcing companies to develop applications and information systems. In order to maintain the competitiveness of the company, some outsourcing software companies will keep the source code of the sold application confidential while selling the application to the purchaser. As a result, the purchaser cannot conduct quality supervision and risk management on the source code of the outsourcing company, and even the outsourcing company may use compliant code when receiving inspections, and inject illegal code when submitting the application, which has buried a huge security risk for the purchaser. risk.

Contents of the invention

In view of this, one or more embodiments of this specification provide a method and device for implementing trusted scheduling.

In order to achieve the above purpose, according to the first aspect of one or more embodiments of this specification, a method for authenticity checking of code security is proposed, including: the code requester initiates a remote verification challenge and a code inspection request; the code provider The party generates a remote verification report for the trusted program in response to the remote verification challenge, the trusted program is pre-provided by the code requester and runs in the trusted execution environment of the code provider; and, the code The provider loads the trusted program in response to the code inspection request, so that the trusted program: scans the code to be checked to generate a code inspection report, and uses the identity private key of the trusted program itself to generate an anchor The digital signature of the code inspection report; the code requester obtains the remote verification report and the code inspection report, confirms whether the operating environment of the trusted program is credible based on the remote verification report, and uses the credible The identity public key of the program verifies the digital signature, and when it is confirmed that the operating environment of the trusted program is credible and the digital signature passes the verification, the code to be inspected is confirmed according to the code inspection report Is it safe.

According to the second aspect of one or more embodiments of this specification, a method for authenticity checking of code security is proposed, which is applied to the code requester, including: initiating a remote verification challenge and a code inspection request, so that the code provider generating a remote verification report for a trusted program in response to the remote verification challenge, the trusted program being pre-provided by the code requester and running in a trusted execution environment at the code provider; and, making the code The provider loads the trusted program in response to the code inspection request, so that the trusted program: scans the code to be checked to generate a code inspection report, and uses the identity private key of the trusted program itself to generate an anchor A digital signature of the code inspection report; obtaining the remote verification report and the code inspection report, confirming whether the operating environment of the trusted program is credible based on the remote verification report, and using the identity of the trusted program The public key verifies the digital signature, and if it is confirmed that the running environment of the trusted program is credible and the digital signature passes the verification, it is confirmed whether the code to be checked is safe according to the code inspection report.

According to a third aspect of one or more embodiments of the present specification, a method for authenticity checking of code security is proposed, which is applied to a code provider, including: generating a target for authenticity in response to a remote verification challenge initiated by a code requester A remote verification report of a trusted program, the trusted program is pre-provided by the code requester and runs in the trusted execution environment of the code provider, so that the code requester obtains the remote verification report, And confirm whether the operating environment of the trusted program is credible based on the remote verification report; and load the trusted program in response to the code inspection request initiated by the code requester, so that the trusted program: scans the pending Check the code to generate a code inspection report, and use the identity private key of the trusted program itself to generate a digital signature for anchoring the code inspection report, so that the code requester can obtain the code inspection report, and use The identity public key of the trusted program verifies the digital signature, and when it is confirmed that the operating environment of the trusted program is credible and the digital signature passes the verification, the code inspection report is used to confirm that the The code to be checked is safe.

According to the fourth aspect of this specification, a device for credible checking of code security is proposed, which is applied to the code requester, including: an initiating unit, used to initiate a remote verification challenge and a code inspection request, so that the code provider responds Generating a remote verification report for a trusted program based on the remote verification challenge, the trusted program is pre-provided by the code requester and runs in the trusted execution environment of the code provider; and, making the code provider The party loads the trusted program in response to the code inspection request, so that the trusted program: scans the code to be checked to generate a code inspection report, and uses the identity private key of the trusted program itself to generate a The digital signature of the code inspection report; the confirmation unit is configured to obtain the remote verification report and the code inspection report, confirm whether the operating environment of the trusted program is credible based on the remote verification report, and use the The identity public key of the trusted program verifies the digital signature, and when it is confirmed that the running environment of the trusted program is credible and the digital signature passes the verification, the code inspection report confirms that the code to be inspected Is the code safe.

According to the fifth aspect of this specification, a device for authenticity checking of code security is proposed, which is applied to the code provider, including: a first generation unit, configured to generate a target for the remote verification challenge initiated by the code requester A remote verification report of a trusted program, the trusted program is pre-provided by the code requester and runs in the trusted execution environment of the code provider, so that the code requester can obtain the remote verification report , and confirm whether the operating environment of the trusted program is credible based on the remote verification report; the second generation unit is configured to load the trusted program in response to a code inspection request initiated by the code requester, so that the Trusted program: scan the code to be checked to generate a code check report, and use the identity private key of the trusted program itself to generate a digital signature for anchoring the code check report, so that the code requester can obtain the code inspection report, and use the identity public key of the trusted program to verify the digital signature, and if it is confirmed that the running environment of the trusted program is credible and the digital signature passes the verification, according to the The code inspection report confirms whether the code to be inspected is safe.

According to a sixth aspect of the present specification, there is provided an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein, the processor implements the above-mentioned first aspect by running the executable instructions The method described in the examples.

According to a seventh aspect of the embodiments of the present specification, there is provided a computer-readable storage medium, on which computer instructions are stored, and when the instructions are executed by a processor, the steps of the method described in the above-mentioned embodiments of the first aspect are implemented.

Description of drawings

Fig. 1 is a flowchart of a method for authentically checking code security provided by an exemplary embodiment.

Fig. 2 is a flow chart of a second method for authentically checking code security provided by an exemplary embodiment.

Fig. 3 is a flow chart of a third method for authentically checking code security provided by an exemplary embodiment.

Fig. 4 is a multi-party interaction diagram of a method for authentically checking code security provided by an exemplary embodiment.

Fig. 5 is a schematic structural diagram of a device for implementing credible checking of code security provided by an exemplary embodiment.

Fig. 6 is a block diagram of an apparatus for authentically checking code security provided by an exemplary embodiment.

Fig. 7 is a block diagram of another apparatus for authentically checking code security provided by an exemplary embodiment.

Detailed ways

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. Implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of this specification. Rather, they are merely examples of apparatuses and methods consistent with aspects of one or more embodiments of the present specification as recited in the appended claims.

It should be noted that in other embodiments, the steps of the corresponding methods may not necessarily be performed in the order shown and described in this specification. In some other embodiments, the method may include more or less steps than those described in this specification. In addition, a single step described in this specification may be decomposed into multiple steps for description in other embodiments; multiple steps described in this specification may also be combined into a single step in other embodiments describe.

Trusted Execution Environment (TEE) is a way to solve the privacy problem. TEE can function as a black box in the hardware, and the code and data operating system layer executed in the TEE cannot be peeked at, and only the predefined interface in the code can operate on it. In terms of efficiency, due to the black-box nature of TEE, plaintext data is used for operations in TEE, rather than complex cryptographic operations in homomorphic encryption, and there is no loss in the efficiency of the calculation process. Under the premise, the security and privacy of the blockchain are greatly improved. At present, the industry is very concerned about TEE solutions. Almost all mainstream chip and software alliances have their own TEE solutions, including TPM (Trusted Platform Module) in software and Intel SGX (Software Guard Extensions) in hardware. , Software Protection Extension), ARM Trustzone (Trust Zone) and AMD PSP (Platform Security Processor, Platform Security Processor).

Based on Intel SGX (hereinafter referred to as SGX) technology, the programs executed in the TEE can be called trusted programs or enclave programs. The trusted programs in the TEE can be customized and developed by relevant technical personnel, and then put into the TEE for execution. The data output by the letter program can be output to an untrusted environment outside the TEE through a specific output port. Trusted programs can be placed and run on relevant technical personnel's local electronic devices that support Intel SGX hardware, or they can be installed on non-local electronic devices for execution.

In this specification, the trusted program is provided by the code requester and runs on the electronic device of the code provider. Since the above-mentioned trusted program runs in an electronic device not local to the code requester, the code requester needs to confirm that the operating environment of the above-mentioned trusted program meets the requirements. According to SGX technology, the code requester can complete the verification of the above aspects through a complete remote verification process: in the remote verification process, the code requester is called a challenger, and the code requester initiates a remote verification challenge to the code provider. The remote verification process involves another special enclave at the code provider, that is, quoting enclave (QE for short). QE is an architectural Enclave (Architectural Enclave) provided and signed by Intel. The above-mentioned trusted program first needs to generate a REPORT (report) structure for local authentication. The above-mentioned REPORT contains at least a summary of the above-mentioned trusted program, and the QE verifies whether the trusted program is on the same platform as itself based on the REPORT structure , and then the QE encapsulates the REPORT structure into a structure, and signs it with an EPID (Enhanced Privacy Identification) private key to generate a remote verification report, that is, QUOTE (self-recommendation information). The EPID private key not only represents the code provider, but also represents the credibility of the underlying hardware of the code provider, and can also bind information such as the version of the processor firmware, and only the QE can access the EPID private key for the above-mentioned Structure is signed to generate QUOTE.

Since the EPID public key is maintained and managed by the authentication server, and the code requester cannot obtain the EPID public key, the code requester can send the remote verification report to the authentication server after obtaining the remote verification report of the above-mentioned trusted program. In SGX technology, the above-mentioned authentication server can be an IAS (Intel Attestation Service) server provided by Intel Corporation, and send a remote verification report to the IAS server, so that the IAS server can use the EPID public key to verify the signature and return the verification result to The code requester, and the above verification result is signed by the authentication server using its identity private key. If the code requester uses the identity public key of the remote verification server to successfully verify the above-mentioned signed verification result, and the above-mentioned verification result is passed, then the program summary contained in the remote verification report can be further compared with the code requester's own maintenance. If the comparison results are consistent, it can be confirmed that the operating environment of the above-mentioned trusted program is safe and credible, and a complete remote verification process has been completed so far.

Fig. 1 is a flowchart of a method for authentically checking code security provided by an exemplary embodiment. In combination with the above detailed description of the remote verification process, the above method may include the following steps: Step 102: The code requester initiates a remote verification challenge and a code inspection request.

In one embodiment, the code provider can be understood as the party who writes the source code. When the code provider writes the source code and delivers it to the code requester, the code requester needs to check the source code to determine the security of the source code. To avoid various risks. This specification provides a solution that enables the agent provider to directly detect the source code and deliver the code inspection report to the code requester, and the code requester only needs to view the code inspection report to obtain credible code inspection results. Improve the efficiency of code providers to confirm code security. In this specification, the code provider needs to load a trusted program in its own trusted execution environment, and the above-mentioned trusted program is authenticated and confirmed by the code requester, or directly provided by the code requester to the code provider. The code requester needs to initiate a remote verification challenge and code inspection request to the code provider. The above remote verification challenge is to verify whether the running environment of the above-mentioned trusted program is safe and reliable, and the code inspection request is to make the above-mentioned trusted program check the verification code. Whether the source code written by the provider has no security risks is independent of each other and does not affect each other; there is no logical dependence on the follow-up process corresponding to the remote verification challenge and code inspection request, so this manual does not limit the The sequence in which remote verification challenges and code inspection requests are initiated. Only under the premise of confirming that the operating environment of the above-mentioned trusted program is safe and credible, can the inspection of the above-mentioned source code by the above-mentioned trusted program be credible. Therefore, in the subsequent verification process, the operation of the above-mentioned trusted program is confirmed The environment is safe and trustworthy, and it is necessary to confirm that the above source code has no security risks.

Step 104: The code provider generates a remote verification report for the trusted program in response to the remote verification challenge, and the trusted program is pre-provided by the code requester and runs in the trusted execution environment of the code provider and, the code provider loads the trusted program in response to the code inspection request, so that the trusted program: scans the code to be checked to generate a code inspection report, and uses the identity private key of the trusted program itself A digital signature anchoring the code inspection report is generated.

In one embodiment, the code provider generates a remote verification report for the above-mentioned trusted program in response to the above-mentioned remote verification challenge. Based on the detailed explanation of the remote verification process above, the remote verification report here can be understood as the above QUOTE mentioned in the article. And, the code provider loads the above-mentioned trusted program in response to the code inspection request. After the initialization of the trusted program is completed, the code to be checked written by the code provider can be scanned. Of course, if the above-mentioned trusted program has been installed on the code provider and loaded Complete, the trusted program can also directly scan the code to be checked written by the code provider without the step of loading the above trusted program. In practical applications, a time threshold can be set. When the above trusted program is used twice If the time interval exceeds the above-mentioned duration threshold, the above-mentioned trusted program needs to be reloaded, so as to ensure that the trusted program can be updated in real time and ensure its security. The trusted program can generate a code inspection report after scanning the above-mentioned code to be inspected. The above-mentioned code inspection report reflects the security of the code to be inspected. In order to ensure that the above-mentioned code inspection report is not tampered with, the above-mentioned trusted program can be generated based on an asymmetric encryption algorithm Its own public-private key pair, and use its own identity and private key to sign the above-mentioned code inspection report, so as to prove that the above-mentioned code inspection report is indeed generated by the above-mentioned trusted program, and at the same time, it can ensure that the above-mentioned code inspection report is not tampered with.

Step 106: The code requester obtains the remote verification report and the code inspection report, confirms whether the operating environment of the trusted program is credible based on the remote verification report, and uses the identity public key pair of the trusted program to The digital signature is verified, and if it is confirmed that the operating environment of the trusted program is credible and the digital signature passes the verification, it is confirmed whether the code to be checked is safe according to the code inspection report.

In one embodiment, the code requester obtains the above-mentioned remote verification report, and confirms whether the operating environment of the above-mentioned trusted program is safe according to the above-mentioned remote verification report; The identity public key of the above-mentioned trusted program can be obtained by the code demander in various ways. For example, the identity public key of the above-mentioned trusted program can be included in the remote verification report. The code requirement After obtaining the above remote verification report, the party can obtain the public key from it for the subsequent signature verification process, or the above-mentioned trusted program can directly send its own identity public key to the code requester, or the code requester is in Before providing the above-mentioned trusted program to the code provider, the identity public key of the above-mentioned trusted program is stored in advance, and this specification does not limit the way to obtain the identity public key of the trusted program. If the signature verification by the code requester is successful, it can be shown that the above-mentioned code inspection report is indeed generated by the above-mentioned trusted program and has not been tampered with. Since the operating environment of the above-mentioned trusted program can be confirmed to be safe and trusted through the remote verification report, the code inspection report generated by the trusted program placed in the safe and trusted environment should also be credible if it has not been tampered with.

In an embodiment, when the digital signature is generated by signing with the identity private key of the trusted program, the signature object includes the code inspection report and/or the hash value of the code inspection report. The above-mentioned trusted program can use its identity private key to directly sign the code inspection report. At this time, the generated digital signature contains the code inspection report and the corresponding signature data. The code inspection report is extracted from the digital signature, and the code provider does not need to provide an additional code inspection report, thereby reducing the amount of data transmission. Alternatively, the above-mentioned trusted program can perform hash calculation on the above-mentioned code inspection report to generate a standard hash value of the code inspection report, and then use its identity private key to sign the standard hash value of the code inspection report, and the generated digital signature at this time Contains the standard hash value of the code inspection report and the corresponding signature data. In this signature method, the code requester can send the code inspection report to the code requester. After obtaining the above code inspection report, the code requester needs to verify the Perform hash calculation and compare the calculated hash value with the standard hash value of the code inspection report in the digital signature. If the comparison is consistent, it means that the above code inspection report has not been tampered with, so as to further improve the code inspection report. Credibility.

Through the above method, the code provider does not need to provide the source code to be checked to the code demander, which ensures that the source code is not leaked. At the same time, the code demander can obtain the inspection results of the source code from the credible code inspection report, and This confirms whether the source code is a security risk. Since the above-mentioned code inspection report is generated by a trusted program, the code provider will not affect the credibility of the above-mentioned code inspection report.

In an embodiment, the above-mentioned remote verification process may specifically be: the remote verification report includes the program summary of the trusted program deployed at the code provider, and the code requester will not be able to automatically verify the above-mentioned remote verification report (QUOTE) after obtaining the above-mentioned remote verification report (QUOTE). To verify it, it is necessary to send the above-mentioned remote verification report to the remote verification server (IAS). sign. If the code requester uses the identity public key of the remote verification server to successfully verify the above-mentioned signed verification result, and the above-mentioned verification result is passed, then the program summary contained in the remote verification report can be further compared with the code requester's own maintenance. If the comparison results are consistent, it can be confirmed that the operating environment of the above-mentioned trusted program is credible. The specific details of the above-mentioned process can refer to the detailed description of the remote verification process above, and will not be repeated here. .

In one embodiment, if the code provider refuses to provide the source code to the code requester for various reasons such as privacy protection, but the code requester needs to detect the source code to confirm the security of the source code , the source code to be checked can be compiled by the above-mentioned trusted program to generate an executable file, and the above-mentioned executable file can be a file with a file extension of exe format. Of course, this specification does not limit the specific format of the executable file. The code demander can obtain the above-mentioned executable file, and deploy the above-mentioned executable file after confirming that the code to be checked is safe. In the above embodiment, whether the code provider directly provides the source code to the code requester will not affect the verification of the source code by the code requester. Even if the code provider only provides executable files to the code requester, the code provider can also Confirm the security of the source code written by the code provider to resolve the conflict between the code requester and the code provider.

In an embodiment, the above-mentioned digital signature can also be used to anchor the executable file.

Optionally, when the trusted program generates the digital signature by signing with its own identity private key, the signature object includes the executable file and/or the hash value of the executable file. The above-mentioned trusted program can directly sign the code inspection report and executable file by using its identity private key. At this time, the generated digital signature includes the code inspection report, executable file and corresponding signature data. Therefore, in this signature method Under this circumstance, the code requester can extract the code inspection report from the above-mentioned digital signature, and the code provider does not need to provide additional code inspection reports or executable files, thereby reducing the amount of data transmission; when the trusted program is confirmed to run on a safe and trusted In an environment where the above-mentioned digital signatures are verified, the code inspection report shows that the source code to be inspected has no security issues, and the above-mentioned three aspects are all met, the above-mentioned executable files can be deployed.

Optionally, the above-mentioned trusted program can perform hash calculation on the code inspection report and the executable file respectively to generate a standard hash value of the code inspection report and a standard hash value of the executable file, and then use its identity private key pair The standard hash value of the code inspection report and the standard hash value of the executable file are signed, and the generated digital signature contains the standard hash value of the code inspection report, the standard hash value of the executable file, and the corresponding signature data , in this signature mode, the code requester can send the code inspection report and executable file to the code requester, and the code requester needs to perform hash calculation on the two after obtaining the above code inspection report and executable file, And compare the calculated hash value with the corresponding standard hash value in the digital signature. If they are consistent, it means that the above code inspection report and the executable file have not been tampered with, so as to further improve the code inspection report and reliability. The credibility of the execution file; when the above-mentioned trusted program is confirmed to run in a safe and trusted environment, the above-mentioned digital signature is verified, and the code inspection report shows that there is no security problem in the source code to be inspected, the conditions in the above three aspects are equal. When satisfied, the above executable can be deployed.

In the above embodiment, not only can the code requester obtain credible code inspection results when the code provider only provides executable files to the code requester, but also the executable file obtained by the code requester can also pass Digital signature anchoring ensures that the above-mentioned executable file is compiled and generated by the above-mentioned trusted program and has not been tampered with.

This manual can complete the inspection and compilation of the source code to be checked provided by the code provider by installing the trusted program provided or certified by the code requester in the trusted execution environment of the code provider; and, the above remote verification report And digital signatures can form a complete evidence chain, so that the code demander can ensure the credibility of the code inspection report and executable files through the verification of the above-mentioned trusted program operating environment and the verification of the credibility of the code inspection report; based on Due to the characteristics of the trusted execution environment and the trusted program itself, the code provider does not need to submit the source code to the code requester for inspection, which avoids the leakage of the source code. At the same time, the code requester can obtain the trusted code inspection results, and When the code inspection result shows that there is no security problem in the source code to be inspected, deploy the executable file compiled from the above source code. While cleverly solving the contradiction between the code provider and the code demander, this manual enables both parties to achieve the corresponding goals, ensures the legal compliance of the source code, and avoids unnecessary risks.

FIG. 2 is a flow chart of a method for authenticity checking of code security according to an exemplary embodiment of this specification. The above method is applied to the code requester and may include the following steps: Step 202: Initiate a remote verification challenge and a code inspection request, so that the code provider generates a remote verification report for the trusted program in response to the remote verification challenge, and the trusted program is pre-provided by the code requester and runs on the trusted program at the code provider. In the execution environment; and, causing the code provider to load the trusted program in response to the code inspection request, so that the trusted program: scans the code to be checked to generate a code inspection report, and uses the trusted program itself The identity private key generates a digital signature for anchoring the code inspection report.

Step 204: Obtain the remote verification report and the code inspection report, confirm whether the operating environment of the trusted program is credible based on the remote verification report, and use the identity public key of the trusted program to verify the digital The signature is verified, and if it is confirmed that the operating environment of the trusted program is credible and the digital signature passes the verification, it is confirmed whether the code to be checked is safe according to the code inspection report.

For specific implementation manners, extended embodiments and related explanations, refer to the above, and this specification will not repeat them here.

Fig. 3 is a flow chart of a method for authenticity checking of code security according to an exemplary embodiment of this specification, which is applied to the code demander and may include the following steps: Step 302: Responding to the code request initiated by the code demander The remote verification challenge generates a remote verification report for the trusted program, the trusted program is pre-provided by the code requester and runs in the trusted execution environment of the code provider, so that the code requester can obtain The remote verification report, and confirming whether the running environment of the trusted program is credible based on the remote verification report.

Step 304: Load the trusted program in response to the code inspection request initiated by the code requester, so that the trusted program: scans the code to be checked to generate a code inspection report, and utilizes the identity privacy of the trusted program itself key to generate a digital signature for anchoring the code inspection report, so that the code requester obtains the code inspection report, and uses the identity public key of the trusted program to verify the digital signature. When it is confirmed that the operating environment of the trusted program is credible and the digital signature passes the verification, it is confirmed according to the code inspection report whether the code to be inspected is safe.

Fig. 4 is a multi-party interaction diagram showing a method for credible checking of code security according to an exemplary embodiment of this specification, which includes a software demander 41, an Enclave program 42, a QE 43, and an IAS server 44, wherein the Enclave Program (trusted program) 42 and QE (Quoting Enclave) 43 are deployed at the software provider who writes the source code to be checked, and Enclave program 42 and QE43 run in the trusted execution environment of the software provider, Enclave program 42 is provided by the software The demander 41 provides or verifies in advance, and the IAS server 44 is a remote verification server provided by the CPU provider. The above-mentioned method may include the following steps: Step 402: the software demander 41 initiates a remote verification challenge and a code inspection request; the above-mentioned remote verification challenge It is to verify whether the operating environment of the Enclave program 42 is safe and reliable, and the code inspection request is to enable the Enclave program 42 to check whether the source code written by the verification code provider has security risks. The two are independent of each other and do not affect each other.

Step 404: Enclave program 42 generates a program digest; Step 406: Enclave program 42 generates an identity public key TA_PK and an identity private key TA_SK based on an asymmetric encryption algorithm.

Step 408: Enclave program 42 generates a REPORT, which at least includes the program summary generated in step 404 and the identity public key TA_PK generated in step 406, and executes step 410 to send the REPORT to QE43.

The software provider loads the Enclave program 42 in response to the remote verification challenge, and the Enclave program 42 generates a program summary and its own public-private key pair in steps 404-406, where the public key is represented by TA_PK and the private key is represented by TA_SK. Further, as shown in steps 408-410, a REPORT is generated, which at least includes TA_PK and a program summary, and the REPORT is returned to QE43 after the generation is completed. It should be noted that the time when the Enclave program 42 in this embodiment generates a public-private key pair is only one of many possibilities. The public key TA_PK in the key pair.

Step 412: QE43 uses the EPID private key to sign REPORT to generate QUOTE, and QE43 places another special enclave for the code provider, that is, quoting enclave (QE for short). QE43 verifies whether the Enclave program 42 is on the same platform as itself based on REPORT, and then encapsulates the REPORT structure into a structure by QE43, and uses the EPID (Enhanced Privacy Identification) private key to sign to generate QUOTE. The EPID private key not only represents the code provider, but also represents the credibility of the underlying hardware of the code provider, and can also bind information such as the version of the processor firmware, and only QE43 can access the EPID private key, while the EPID public key is provided by IAS Server 44 manages maintenance.

Step 414: The Enclave program 42 can statically scan the source code to be checked written by the software provider to generate a code checking report R.

Step 416: The Enclave program 42 may perform hash calculation on the code inspection report R generated in step 414 to generate a standard hash value of the code inspection report R, represented by HR.

Step 418: The Enclave program 42 can also compile the source code to be checked written by the software provider to generate an executable file E.

Step 420: The Enclave program 42 may perform hash calculation on the executable file E generated in step 418 to generate a standard hash value of the executable file E, represented by HE.

Step 422: Enclave program 42 can use its own identity private key TA_SK to sign HR and HE to generate a digital signature S. According to related technologies, the above-mentioned signature S=HR, HE, sign(HR, HE), where HR represents a code inspection report The original file of the standard hash value of R, HE represents the original file of the executable file E, and sign(HR,HE) represents the signature data.

Step 424: Enclave program 42 returns digital signature S, REPORT, code inspection report R and executable file E to software requester 41.

Step 426: QE43 returns the QUOTE to the software demander 41.

Step 428: After obtaining the QUOTE, the code requester 41 needs to send the above QUOTE to the IAS server 44 because it cannot obtain the EPID public key and cannot verify it by itself.

Step 430: After the IAS server 44 uses the EPID public key to verify the above QUOTE, it returns the remote verification result to the code requester 41, that is, step 432. And, the above-mentioned verification result is signed by the IAS server 44 using its identity private key, if the code requester 41 uses the identity public key of the remote verification server to successfully verify the above-mentioned signed verification result, and the above-mentioned verification result is passed, then you can Further compare the program summary contained in the remote verification report with the standard program summary of the trusted program maintained by the code demander itself. If the comparison results are consistent, it can be confirmed that the operating environment of the above-mentioned trusted program is credible. The specific details of the above-mentioned process For details, refer to the detailed description of the remote verification process above, and details will not be repeated here.

Step 434: The code requester 41 extracts TA_PK from the obtained REPORT, and performs a signature verification operation on S. If the signature verification is successful, it means that HR and HE are indeed generated by the Enclave program 42 and have not been tampered with.

Step 436: The code requester 41 performs hash calculations on R and E respectively, and compares the obtained results with HE and HR extracted from the digital signature S, and if the comparison is consistent, it indicates the code inspection report R and Executable E has not been tampered with.

Step 438: If the above-mentioned remote verification is passed and the hash value check is passed, it means that the running environment of the Enclave program 42 is safe and credible, and the code inspection report R and the executable file E are indeed generated by running in a safe and credible environment and It has not been tampered with, so it can be considered that the code inspection report R credibly reflects the security situation of the source code to be inspected.

Step 440: In the case where the above-mentioned code inspection report R is considered credible, if the result in the code inspection report R considers that the source code to be inspected has no security issues, it means that the executable file E compiled by the Enclave program 42 does not have a security risk , ready to deploy.

Fig. 5 is a schematic structural diagram of a device provided by an exemplary embodiment. Please refer to FIG. 5 , at the hardware level, the device includes a processor 502 , an internal bus 504 , a network interface 506 , a memory 508 and a non-volatile memory 510 , and of course it may also include hardware required by other services. One or more embodiments of this specification may be implemented based on software, for example, the processor 502 reads a corresponding computer program from the non-volatile memory 510 into the memory 508 and executes it. Of course, in addition to software implementations, one or more embodiments of this specification do not exclude other implementations, such as logic devices or a combination of software and hardware, etc., that is to say, the execution subject of the following processing flow is not limited to each A logic unit, which can also be a hardware or logic device.

Please refer to FIG. 6 , the device for implementing trusted scheduling can be applied to the device shown in FIG. 5 to implement the technical solution of this specification.

Wherein, the device for authentically checking the code security is applied to the code requester, and includes: an initiating unit 602, configured to initiate a remote verification challenge and a code inspection request, so that the code provider responds to the remote verification challenge to generate an a remote verification report of a trusted program, the trusted program is pre-provided by the code requester and runs in the trusted execution environment of the code provider; and the code provider loads the code in response to the code inspection request The trusted program makes the trusted program: scan the code to be checked to generate a code inspection report, and use the identity private key of the trusted program itself to generate a digital signature for anchoring the code inspection report; confirm Unit 604, configured to acquire the remote verification report and the code inspection report, confirm whether the operating environment of the trusted program is credible based on the remote verification report, and use the identity public key of the trusted program to verify the Verifying the digital signature, and confirming whether the code to be inspected is safe or not according to the code inspection report when it is confirmed that the running environment of the trusted program is credible and the digital signature passes the verification.

Optionally, the above apparatus may further include: a deploying unit 606, configured to obtain an executable file generated by compiling the code to be checked by the trusted program, and deploy the executable file when it is confirmed that the code to be checked is safe. executable file.

Optionally, the digital signature is also used to anchor the executable file.

Optionally, the identity public key of the trusted program is included in the remote verification report.

Optionally, the confirming unit 604 is specifically configured to: the remote verification report includes a program summary of the trusted program deployed at the code provider; Whether the operating environment is credible, including: sending the remote verification report to the remote verification server, and receiving the verification result returned by the remote verification server, the verification result being signed by the identity private key of the remote verification server; If the signature verification is successful based on the identity public key of the remote verification server and the verification result is verified, combine the program summary contained in the remote verification report with the trusted program maintained by the code requester itself compare the summary of the standard program, and confirm that the operating environment of the trusted program is credible if the comparison result is consistent.

Please refer to FIG. 7 , the device for implementing trusted scheduling can be applied to the device shown in FIG. 5 to implement the technical solution of this specification.

Wherein, the device for authentically checking code security is applied to the code provider, including: a first generating unit 702, configured to generate a remote verification report for a trusted program in response to a remote verification challenge initiated by the code requester, so The trusted program is pre-provided by the code requester and runs in the trusted execution environment of the code provider, so that the code requester obtains the remote verification report and confirms based on the remote verification report Whether the operating environment of the trusted program is credible; the second generating unit 704 is configured to load the trusted program in response to the code inspection request initiated by the code requester, so that the trusted program: scans the code to be checked to generate a code inspection report, and use the identity private key of the trusted program itself to generate a digital signature for anchoring the code inspection report, so that the code requester can obtain the code inspection report and use the The identity public key of the trusted program verifies the digital signature, and when it is confirmed that the operating environment of the trusted program is credible and the digital signature passes the verification, the code inspection report confirms that the Check that the code is safe.

Optionally, when the digital signature is generated by signing with the identity private key of the trusted program, the signature object includes the code inspection report and/or a hash value of the code inspection report.

Optionally, the above-mentioned apparatus may further include: a compilation unit 706, used by the trusted program to compile the code to be checked to generate an executable file; Deploy when the code to be checked is safe.

Optionally, the digital signature is also used to anchor the executable file.

Optionally, when the digital signature is generated by signing with the identity private key of the trusted program, the signature object includes the executable file and/or the hash value of the executable file.

The systems, devices, modules, or units described in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer, which may take the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, e-mail device, game control device, etc. desktops, tablets, wearables, or any combination of these.

In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces and memory.

Memory may include non-permanent storage in computer-readable media, in the form of random access memory (RAM) and/or nonvolatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer readable media.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can be implemented by any method or technology for storage of information. Information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Flash memory or other memory technology, Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc (DVD) or other optical storage, Magnetic cassettes, disk storage, quantum memory, graphene-based storage media or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by computing devices. As defined herein, computer-readable media excludes transitory computer-readable media, such as modulated data signals and carrier waves.

It should also be noted that the term "comprises", "comprises" or any other variation thereof is intended to cover a non-exclusive inclusion such that a process, method, article, or apparatus comprising a set of elements includes not only those elements, but also includes Other elements not expressly listed, or elements inherent in the process, method, commodity, or apparatus are also included. Without further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article or apparatus comprising said element.

The foregoing describes specific embodiments of this specification. Other implementations are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. Multitasking and parallel processing are also possible or may be advantageous in certain embodiments.

Terms used in one or more embodiments of the present specification are for the purpose of describing specific embodiments only, and are not intended to limit the one or more embodiments of the present specification. As used in one or more embodiments of this specification and the appended claims, the singular forms "a", "the", and "the" are also intended to include the plural forms unless the context clearly dictates otherwise. It should also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present specification to describe various information, the information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of one or more embodiments of this specification, first information may also be called second information, and similarly, second information may also be called first information. Depending on the context, the word "if" as used herein may be interpreted as "at" or "when" or "in response to a determination."

The above descriptions are only preferred embodiments of one or more embodiments of this specification, and are not intended to limit one or more embodiments of this specification. Within the spirit and principles of one or more embodiments of this specification, Any modification, equivalent replacement, improvement, etc. should be included in the scope of protection of one or more embodiments of this specification.

Claims

A method of trusted checking of code security comprising:

The code requester initiates a remote verification challenge and code inspection request;

The code provider generates a remote verification report for the trusted program in response to the remote verification challenge, the trusted program is pre-provided by the code requester and runs in a trusted execution environment at the code provider; and , the code provider loads the trusted program in response to the code inspection request, so that the trusted program: scans the code to be checked to generate a code inspection report, and uses the identity private key of the trusted program itself to generate a A digital signature anchoring said code inspection report;

The code demander obtains the remote verification report and the code inspection report, confirms whether the operating environment of the trusted program is credible based on the remote verification report, and uses the identity public key of the trusted program to verify the digital The signature is verified, and if it is confirmed that the operating environment of the trusted program is credible and the digital signature passes the verification, it is confirmed whether the code to be checked is safe according to the code inspection report.
According to the method according to claim 1, when the digital signature is generated by signing with the identity private key of the trusted program, the signature object includes the code inspection report and/or the hash value of the code inspection report.
According to the method according to claim 1, the trusted program is also used to compile the code to be checked to generate an executable file; the method also includes:

The code demander obtains the executable file, and deploys the executable file after confirming that the code to be checked is safe.
The method of claim 3, said digital signature is also used to anchor said executable file.
According to the method of claim 4, when the digital signature is generated by signing with the identity private key of the trusted program, the signature object includes the executable file and/or the hash value of the executable file.
The method of claim 1, the trusted program's identity public key is included in the remote verification report.
The method according to claim 1, wherein the remote verification report includes a program summary of the trusted program deployed at the code provider; letter, including:

The code requesting party sends the remote verification report to the remote verification server, and receives the verification result returned by the remote verification server, and the verification result is signed by the identity private key of the remote verification server;

In the case that the code requesting party successfully performs signature verification according to the identity public key of the remote verification server and the verification result is verified, the code requesting party compares the program summary contained in the remote verification report with the code requesting party itself Compare the standard program summaries of the trusted programs maintained, and confirm that the operating environment of the trusted program is trusted if the comparison results are consistent.
A method for credible checking of code security, applied to the code demand side, including:

Initiate a remote verification challenge and a code inspection request, so that the code provider generates a remote verification report for the trusted program in response to the remote verification challenge. The trusted program is pre-provided by the code requester and runs on the code provider and, causing the code provider to load the trusted program in response to the code inspection request, so that the trusted program: scans the code to be checked to generate a code inspection report, and utilizes the The identity private key of the trusted program itself generates a digital signature for anchoring the code inspection report;

Obtaining the remote verification report and the code inspection report, confirming whether the operating environment of the trusted program is credible based on the remote verification report, and verifying the digital signature using the identity public key of the trusted program If it is confirmed that the operating environment of the trusted program is credible and the digital signature passes the verification, according to the code inspection report, it is confirmed whether the code to be inspected is safe.
The method of claim 8, further comprising:

Obtaining an executable file generated by compiling the code to be checked by the trusted program, and deploying the executable file when it is confirmed that the code to be checked is safe.
The method of claim 9, the digital signature is also used to anchor the executable file.
The method of claim 8, the trusted program's identity public key is included in the remote verification report.
The method according to claim 8, wherein the remote verification report includes a program summary of the trusted program deployed at the code provider; letter, including:

Sending the remote verification report to a remote verification server, and receiving a verification result returned by the remote verification server, the verification result being signed by the identity private key of the remote verification server;

If the signature verification is successful based on the identity public key of the remote verification server and the verification result is verified, combine the program summary contained in the remote verification report with the trusted program maintained by the code requester itself compare the summary of the standard program, and confirm that the running environment of the trusted program is credible if the comparison result is consistent.
A method for credible checking of code security, applied to code providers, including:

Generating a remote verification report for a trusted program in response to a remote verification challenge initiated by a code requester, the trusted program being pre-provided by the code requester and running in a trusted execution environment at the code provider, and then enabling the code requester to obtain the remote verification report, and confirm whether the operating environment of the trusted program is credible based on the remote verification report;

And, load the trusted program in response to the code inspection request initiated by the code demander, so that the trusted program: scans the code to be checked to generate a code inspection report, and uses the identity private key of the trusted program itself Generate a digital signature for anchoring the code inspection report, and then enable the code requester to obtain the code inspection report, and use the identity public key of the trusted program to verify the digital signature, and confirm If the running environment of the trusted program is credible and the digital signature passes the verification, confirm whether the code to be checked is safe according to the code checking report.
According to the method of claim 13, when the digital signature is generated by signing with the identity private key of the trusted program, the signature object includes the code inspection report and/or the hash value of the code inspection report.
According to the method according to claim 13, the trusted program is also used to compile the code to be checked to generate an executable file; the executable file is obtained by the code requester, and after confirming the code to be checked Deploy when safe.
The method of claim 15, the digital signature is also used to anchor the executable.
According to the method of claim 16, when the digital signature is generated by signing with the identity private key of the trusted program, the signature object includes the executable file and/or the hash value of the executable file.
The method of claim 13, the trusted program's identity public key is included in the remote verification report.
A device for credible checking of code security, applied to the code demand side, including:

An initiating unit, configured to initiate a remote verification challenge and a code inspection request, so that the code provider generates a remote verification report for a trusted program in response to the remote verification challenge, and the trusted program is pre-provided and run by the code requester In the trusted execution environment at the code provider; and, causing the code provider to load the trusted program in response to the code inspection request, so that the trusted program: scans the code to be checked to generate a code inspection report , and using the trusted program's own identity private key to generate a digital signature for anchoring the code inspection report;

A confirmation unit, configured to obtain the remote verification report and the code inspection report, confirm whether the operating environment of the trusted program is credible based on the remote verification report, and use the identity public key of the trusted program to verify the Verifying the digital signature, and confirming whether the code to be inspected is safe or not according to the code inspection report when it is confirmed that the running environment of the trusted program is credible and the digital signature passes the verification.
A device for credible checking of code security, applied to code providers, including:

A first generating unit, configured to generate a remote verification report for a trusted program in response to a remote verification challenge initiated by a code requester, the trusted program being pre-provided by the code requester and running on the code provider's In a trusted execution environment, further enabling the code requester to obtain the remote verification report, and confirm whether the operating environment of the trusted program is credible based on the remote verification report;

The second generation unit is configured to load the trusted program in response to the code inspection request initiated by the code requester, so that the trusted program: scans the code to be checked to generate a code inspection report, and uses the trusted program Its own identity private key generates a digital signature for anchoring the code inspection report, so that the code requester obtains the code inspection report, and uses the identity public key of the trusted program to verify the digital signature Signature verification. When it is confirmed that the operating environment of the trusted program is credible and the digital signature passes the signature verification, according to the code inspection report, it is confirmed whether the code to be inspected is safe.
An electronic device comprising:

processor;

memory for storing processor-executable instructions;

Wherein, the processor implements the method according to any one of claims 1-18 by running the executable instructions.
A computer-readable storage medium, on which computer instructions are stored, and the steps of the method according to any one of claims 1-18 are implemented when the instructions are executed by a processor.