Trusted certification method and device based on distributed scene

Abstract

The invention discloses a credibility certification method and device based on a distributed scene, relates to the technical field of distributed computing, and mainly aims to realize credibility certification in the distributed scene. According to the main technical scheme, when a distributed scene is started, respective static integrity measurement reports of a sender and a receiver are generated based on system static data, and the static integrity measurement reports are utilized to apply for a trusted third party to obtain a digital certificate and a public key; when a distributed scene runs, generating respective dynamic integrity measurement reports of a sender and a receiver based on system dynamic data; carrying out identity authentication between the sender and the receiver by using a digital certificate and a public key, carrying out initial state authentication by using the signed static integrity measurement report, and carrying out running state authentication by using the signed dynamic integrity measurement report; and if the authentication result is passed, establishing a secure channel between the sender and the receiver so as to perform data transmission through the secure channel.

Description

Technical Field

[0001] The present application relates to the field of distributed computing technology, and in particular to a trusted proof method and device based on a distributed scenario. Background Art

[0002] With the rapid development of information technology, distributed computing and cloud computing have become core components of modern information systems. In these systems, multiple environment nodes (such as servers, client devices) work together to complete complex tasks. However, this distributed architecture also brings new security challenges, especially in terms of data privacy protection and ensuring the trustworthiness of the identities of both communicating parties. In order to meet these challenges, the Trusted Execution Environment (TEE) has emerged as a technology that combines hardware and software. It provides memory isolation and encryption protection, ensures the security and integrity of data processing, and guarantees the reliability of the environment itself through remote authentication technology.

[0003] Currently, most existing remote authentication methods are applicable to single-node scenarios, and they focus on measuring and authenticating programs and code segments to ensure that they have not been tampered with. However, traditional authentication methods cannot fully reflect the security status of the system at all stages from startup to operation, resulting in a lack of overall verification of the environment. They also do not consider the need for mutual collaboration between multiple environment nodes in a distributed environment, and cannot provide an effective mechanism to ensure that all participating environment nodes are in a trusted state. Summary of the invention

[0004] In view of the above problems, the present application provides a trusted proof method and device based on a distributed scenario. The main purpose is to comprehensively reflect the security status of the system at each stage from startup to operation in a distributed scenario, ensure that all participating environmental nodes are in a trusted state, and thus realize trusted proof in a distributed scenario.

[0005] In order to solve the above technical problems, this application proposes the following solutions:

[0006] In a first aspect, the present application provides a trusted proof method based on a distributed scenario, wherein the distributed scenario includes a sender and a receiver, and the method includes:

[0007] When the distributed scenario is started, a static integrity measurement report of each of the sender and the receiver is generated based on the system static data, and a digital certificate and a public key are applied for from a trusted third party using the static integrity measurement report;

[0008] When the distributed scenario is running, generating dynamic integrity measurement reports for the sender and the receiver based on system dynamic data;

[0009] Between the sender and the receiver, identity authentication is performed using the digital certificate and the public key, initial status authentication is performed using the signed static integrity measurement report, and running status authentication is performed using the signed dynamic integrity measurement report;

[0010] If the authentication result is passed, a secure channel is established between the sender and the receiver so as to perform data transmission through the secure channel.

[0011] In a second aspect, the present application provides a trusted proof device based on a distributed scenario, wherein the distributed scenario includes a sender and a receiver, and the device includes:

[0012] A first generating unit is used to generate a static integrity measurement report of each of the sender and the receiver based on system static data when the distributed scenario is started, and apply for a digital certificate and a public key from a trusted third party using the static integrity measurement report;

[0013] A second generating unit, configured to generate a dynamic integrity measurement report for each of the sender and the receiver based on system dynamic data when the distributed scenario is running;

[0014] a remote authentication unit, configured to perform identity authentication between the sender and the receiver using the digital certificate and the public key obtained by the first generation unit, perform initial status authentication using the signed static integrity measurement report obtained by the first generation unit, and perform running status authentication using the signed dynamic integrity measurement report obtained by the second generation unit;

[0015] The channel construction unit is used to establish a secure channel between the sender and the receiver if the authentication result obtained by the remote authentication unit is passed, so as to transmit data through the secure channel.

[0016] In order to achieve the above-mentioned purpose, according to the third aspect of the present application, a storage medium is provided, which includes a stored program, wherein when the program is running, the device where the storage medium is located is controlled to execute the trusted proof method based on a distributed scenario of the above-mentioned first aspect.

[0017] In order to achieve the above-mentioned purpose, according to a fourth aspect of the present application, a processor is provided, wherein the processor is used to run a program, wherein when the program is running, the trusted attestation method based on a distributed scenario of the above-mentioned first aspect is executed.

[0018] By means of the above technical scheme, the present application provides a trusted proof method and device based on a distributed scenario. When it is necessary to perform trusted proof on the distributed scenario, when the distributed scenario is started, a static integrity measurement report of the sender and the receiver is generated based on the system static data, and a digital certificate and a public key are applied to a trusted third party using the static integrity measurement report. When the distributed scenario is running, a dynamic integrity measurement report of the sender and the receiver is generated based on the system static data. Between the sender and the receiver, identity authentication is performed using the digital certificate and the public key, initial state authentication is performed using the signed static integrity measurement report, and running state authentication is performed using the signed dynamic integrity measurement report. If the authentication result is passed, a secure channel is established between the sender and the receiver to transmit data through the secure channel. The technical solution provided by the present application generates static integrity measurement reports and dynamic integrity measurement reports for multiple environmental nodes such as senders and receivers in distributed scenarios respectively through system static data at startup and system dynamic data at runtime, which can comprehensively reflect the security status of the system at each stage from startup to operation, and realize the overall verification of the environment. In addition, by starting to build a trust relationship when the entire distributed scenario is started, and continuously updating and verifying the status of multiple environmental nodes such as senders and receivers during operation, it is ensured that all participating environmental nodes can be maintained in a trusted security state. At the same time, by combining digital certificates, public keys, and signed static integrity measurement reports and signed dynamic integrity measurement reports, a more stringent identity authentication and status authentication process is achieved. Only when all authentication steps are passed, the final secure channel will be established, which solves the limitations of single-node scenario authentication and the lack of support for collaboration of multiple environmental nodes in distributed scenarios in the prior art, thereby greatly improving the security of communication and providing a more reliable mechanism for secure communication in distributed scenarios.

[0019] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present application. Also, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0021] Figure 1 A flow chart of a trusted proof method based on a distributed scenario provided in an embodiment of the present application is shown;

[0022] Figure 2 A flow chart of another trusted proof method based on a distributed scenario provided in an embodiment of the present application is shown;

[0023] Figure 3 A block diagram of a distributed scenario-based trusted proof device provided by an embodiment of the present application is shown;

[0024] Figure 4 A block diagram of another distributed scenario-based trusted certification device provided in an embodiment of the present application is shown. DETAILED DESCRIPTION

[0025] The exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0026] Currently, most existing remote authentication methods are applicable to single-node scenarios, and they focus on measuring and authenticating programs and code segments to ensure that they have not been tampered with. However, traditional authentication methods cannot fully reflect the security status of the system at all stages from startup to operation, resulting in a lack of overall verification of the environment. They also do not consider the need for mutual collaboration between multiple environment nodes in a distributed environment, and cannot provide an effective mechanism to ensure that all participating environment nodes are in a trusted state.

[0027] After research, the inventor found that by defining multiple environment nodes in a distributed scenario as senders and receivers, static integrity measurement reports and dynamic integrity measurement reports can be generated for each environment node when the system is started and running, and multi-stage authentication can be performed in combination with digital certificates and public key technology obtained by applying for a trusted third party. In this way, the identity trustworthiness and state security of all participating environment nodes can be ensured, solving the limitations of single-node scenario authentication in the prior art and the lack of support for collaboration of multiple environment nodes in distributed scenarios, providing a more reliable mechanism for secure communication in distributed scenarios.

[0028] Based on the above considerations, the embodiment of the present application provides a trusted proof method based on a distributed scenario, through which the security status of the system from startup to operation can be fully reflected in the distributed scenario, ensuring that all participating environment nodes are in a trusted state, thereby realizing trusted proof in a distributed scenario. The specific execution steps are as follows: Figure 1 As shown, including:

[0029] 101. When the distributed scenario is started, a static integrity measurement report is generated for each of the sender and the receiver, and the static integrity measurement report is used to apply for a digital certificate and a public key from a trusted third party.

[0030] In this embodiment, the distributed scenario includes multiple data interaction environment nodes, including input environment nodes, computing environment nodes, and output environment nodes, wherein data completes various initialization operations in the input environment nodes, completes specific computing and processing tasks in the computing environment nodes, and provides application services for various user entities in the output environment nodes. It should be noted that the sender can be an input environment node or a computing environment node, and correspondingly, the receiver can be a computing environment node or an output environment node.

[0031] In this step, before the system of each environment node (sender and receiver) in the distributed scenario is started, ensure that all nodes (sender and receiver) have installed and configured hardware and software components that support the trusted execution environment (TEE), such as Intel SGX, AMD SEV or ARM TrustZone. During the system startup process, all key static data, including but not limited to the operating system kernel, drivers, static code, configuration files, etc., are captured as the basis for subsequent hash operations to generate static integrity measurement reports. Specifically, a secure hash algorithm (such as SHA-256) can be used to perform a hash operation on the above static data to generate a hash value of a fixed length. Each hash value represents a specific static data object. These hash values ​​are written to the PCR register in the trusted cryptographic module (TCM) to form a static integrity measurement report. The static integrity measurement report accurately reflects the state of the system at startup, that is, the initial state.

[0032] Based on the generated static integrity measurement report, a certification request is submitted to a trusted third party (such as a certificate authority, CA). After the CA verifies the validity of the static integrity measurement report of the sender and the receiver, it issues a digital certificate and provides the corresponding public key. This process is used to ensure that only verified environment nodes can obtain legal identities.

[0033] Through the above methods, it can be ensured that each environment node is in a controlled and trusted state from the beginning of startup, preventing malicious software or tampered code from being executed. At the same time, the digital certificates and public keys issued by a trusted third party provide a solid foundation for subsequent identity authentication.

[0034] 102. When the distributed scenario is running, a dynamic integrity measurement report is generated for the sender and the receiver respectively.

[0035] In this step, when the system of each environment node (sender and receiver) in the distributed scenario is started and enters the normal operation state, the state changes of key applications and services, such as process lists, network connections, loaded library files, etc., are continuously monitored. A hash operation is performed on each detected key state change to generate a new hash value. These hash values ​​reflect the current operating status of the system, that is, the operating status. The newly generated hash value is also written into the PCR register of the TCM, and the dynamic integrity measurement report is continuously updated, which enables the security of the system to be maintained even during long-term operation. If any abnormal behavior is detected (such as unauthorized program startup), the alarm mechanism is immediately triggered and appropriate measures are taken to protect the system from potential threats.

[0036] Through the above method, real-time tracking of the security status of each environmental node system during operation is achieved, ensuring that any possible security issues can be discovered and responded to in a timely manner even during long-term operation, thereby enhancing overall security.

[0037] 103. Between the sender and the receiver, identity authentication is performed using digital certificates and public keys, initial status authentication is performed using signed static integrity measurement reports, and running status authentication is performed using signed dynamic integrity measurement reports.

[0038] In this step, the sender and the receiver each send their own digital certificate and public key to the other party, and verify whether the certificate provided by the other party is issued by a trusted third party. If the verification is successful, the two parties negotiate and exchange a temporary shared key for subsequent communication encryption. After the identity authentication is successful, the two parties use the private key to encrypt the hash value corresponding to their respective static integrity measurement reports to generate a digital signature. The two parties exchange digital signatures and static integrity measurement reports, and use the public key provided by the other party to decrypt the digital signature, and compare whether the decrypted hash value is consistent with the original hash value. If they are consistent, it is confirmed that the initial state authentication is passed. After the initial state authentication is passed, the two parties use the private key again to encrypt the hash value corresponding to the latest dynamic integrity measurement report to generate a digital signature. Similarly, the two parties exchange digital signatures and dynamic integrity measurement reports, and use the public key provided by the other party to decrypt the digital signature, and compare whether the decrypted hash value is consistent with the latest hash value. If they are consistent, it is confirmed that the running state authentication is passed. When the identity authentication, initial state authentication and running state authentication are all verified, it is considered that the verification results of the sender and the receiver are passed, which means that the sender and the receiver are in a safe state during the entire operation cycle, and step 104 is executed at this time.

[0039] Through the multi-stage authentication mechanism, not only the identities of the communicating parties are ensured to be credible, but also their security status throughout the entire operation cycle is verified, which greatly improves the security and reliability of communication.

[0040] 104. Establish a secure channel between the sender and the receiver so that data can be transmitted through the secure channel.

[0041] In this step, when all authentication steps in step 103 are passed, a TLS / SSL secure channel is formally established between the sender and the receiver. All data to be transmitted are encrypted using the previously negotiated temporary shared key to form encrypted data packets to be transmitted, ensuring the confidentiality and integrity of the data during transmission. Based on the established secure channel, these encrypted data packets to be transmitted will be securely transmitted from the sender to the receiver. After receiving the encrypted data packet, the receiver uses the same shared key to decrypt it and verify the authenticity and integrity of the data. If the verification is successful, it means that the data transmission is successful. Otherwise, an error handling mechanism will be triggered, such as re-initiating authentication or interrupting the connection.

[0042] By establishing a secure channel, the security of the entire process from authentication to data transmission is ensured, preventing man-in-the-middle attacks and other forms of data tampering, and providing a solid guarantee for secure communications in distributed scenarios.

[0043] Based on the above Figure 1It can be seen from the implementation method that the present application provides a trusted proof method based on a distributed scenario. When a trusted proof of a distributed scenario is required, when the distributed scenario is started, a static integrity measurement report of the sender and the receiver is generated based on the system static data, and the static integrity measurement report is used to apply for a digital certificate and a public key from a trusted third party. When the distributed scenario is running, a dynamic integrity measurement report of the sender and the receiver is generated based on the system dynamic data. Between the sender and the receiver, identity authentication is performed using a digital certificate and a public key, the signed static integrity measurement report is used for initial state authentication, and the signed dynamic integrity measurement report is used for running state authentication. If the authentication result is passed, a secure channel is established between the sender and the receiver to transmit data through the secure channel. The technical solution provided by the present application generates static integrity measurement reports and dynamic integrity measurement reports for multiple environmental nodes such as senders and receivers in distributed scenarios through system static data at startup and system dynamic data at runtime, which can comprehensively reflect the security status of the system at each stage from startup to operation, and realize the overall verification of the environment. In addition, by starting to build a trust relationship when the entire distributed scenario is started, and continuously updating and verifying the status of multiple environmental nodes such as senders and receivers during operation, it is ensured that all participating environmental nodes can be maintained in a trusted security state. At the same time, by combining digital certificates, public keys, and signed static integrity measurement reports and signed dynamic integrity measurement reports, a more stringent identity authentication and status authentication process is achieved. Only when all authentication steps are passed will the final secure channel be established, thereby greatly improving the security of communication, solving the limitations of single-node scenario authentication and the lack of support for collaboration among multiple environmental nodes in distributed scenarios in the prior art, and providing a more reliable mechanism for secure communication in distributed scenarios.

[0044] Further, the preferred embodiment of the present application is in the above Figure 1 Based on this, a detailed description of the trusted proof process based on distributed scenarios is given. The specific steps are as follows Figure 2 As shown, including:

[0045] 201. When the distributed scenario is started, a static integrity measurement report is generated for each sender and receiver based on the system static data, and the static integrity measurement report is used to apply for a digital certificate and a public key from a trusted third party.

[0046] This step is combined with the description of step 101 in the above method, and the same content is not repeated here. It should be noted that the specific execution process of generating the static integrity measurement report of the sender and the receiver based on the system static data is: respectively obtain the static code and configuration file of the sender and the receiver at the time of system startup; for the sender and the receiver, respectively perform hash operations on their respective static codes and configuration files, and write the obtained first hash value into the register of the trusted cryptographic module as the static integrity measurement report of the sender and the receiver, and the static integrity measurement report is used to characterize the initial state of the sender or the receiver's system.

[0047] In this step, ensure that all environment nodes (sender and receiver) have installed and configured hardware that supports the Trusted Execution Environment (TEE), such as Intel SGX, AMD SEV, or ARM TrustZone. These hardware modules provide the necessary security isolation and protection functions. Deploy a boot-time monitoring agent on each node, which is responsible for collecting static code and configuration files and working with TEE to ensure data security and integrity.

[0048] Determine which static data needs to be included in the measurement scope, including but not limited to the operating system kernel, drivers, boot loaders, system configuration files (such as files in the / etc directory), application binaries, etc. Classify static data according to importance and security requirements and set different priorities. For example, the operating system kernel and critical drivers should have the highest priority, ensuring that they are verified first.

[0049] Design an automated collection process to read all specified static data items in sequence during system startup, specifically before the operating system kernel is loaded. During the collection process, use checksums or other methods to initially verify the integrity of the static data to prevent data corruption caused by disk errors and other reasons from affecting the results of subsequent hash operations. Use a strong cryptographic hash algorithm (such as SHA-256 or SHA-3) to hash each static data item and generate a fixed-length hash value, namely the first hash value. For large files, hash values ​​can be calculated in blocks, and then the hash values ​​of each block are combined to form the final hash value. If there are multiple static data items on an environment node, their hash values ​​need to be aggregated, which can be done by simply concatenating and hashing again, or more complex methods such as Merkle tree structures to ensure overall integrity and consistency. Write the final generated hash value to the PCR register in the trusted cryptographic module (TCM). This step not only records the initial state of the system, but also prevents tampering through the hardware protection provided by the TEE.

[0050] All hash values ​​and their corresponding static data identifiers are organized into a structured static integrity measurement report. This report can be in an easy-to-parse format such as XML or JSON for subsequent processing. The entire static integrity measurement report is digitally signed using the private key held by the environment node to ensure the credibility of its source and the integrity of its content. Subsequently, a digital certificate and public key are applied to a trusted third party (such as a certificate authority CA) for subsequent identity authentication.

[0051] After the system is fully booted, immediately perform a complete static integrity verification, comparing the current state with the expected static integrity measurement report. If there are any inconsistencies, trigger an alarm and take appropriate recovery measures. Record the static data collection and hash calculation process at each boot in detail, as well as the verification results. These logs can be used for subsequent security audits and troubleshooting.

[0052] Establish a version control system for static data. Whenever there is a new firmware or software update, automatically update the static integrity measurement report and re-apply for the digital certificate. Regularly test the static integrity measurement report generation process to ensure its accuracy and reliability. In particular, when the system architecture changes or new components are introduced, timely adjust the collection scope and hash algorithm.

[0053] Through strict static data collection and hash operations, the system is ensured to be in a controlled and trusted state from the beginning of startup, preventing malware or tampered code from being executed. The hardware protection and trusted cryptographic module provided by TEE ensure the authenticity and non-tamperability of the measurement report, enhancing the reliability of the entire system. It can not only fully and accurately characterize the initial state of the sender and receiver systems, but also effectively improve the security and reliability in a distributed environment, providing a solid foundation for subsequent identity authentication and data transmission.

[0054] 202. When the distributed scenario is running, a dynamic integrity measurement report for the sender and the receiver is generated based on the system dynamic data.

[0055] This step is combined with the description of step 102 in the above method, and the same content is not repeated here. It should be noted that the specific execution process of generating the dynamic integrity measurement report of the sender and the receiver based on the system dynamic data is: respectively obtain the key program status of the sender and the receiver when the system is running; for the sender and the receiver, respectively perform hash operations on their respective key program states, and write the obtained second hash value into the register of the trusted cryptographic module as the dynamic integrity measurement report of the sender and the receiver, and the dynamic integrity measurement report is used to characterize the operating status of the sender and the receiver's system.

[0056] In this step, ensure that all nodes (sender and receiver) have installed and configured hardware that supports the Trusted Execution Environment (TEE), such as Intel SGX, AMD SEV, or ARM TrustZone. These hardware modules provide the necessary security isolation and protection functions. Deploy a monitoring agent on each node, which is responsible for collecting key program status information and working with TEE to ensure data security and integrity.

[0057] According to the application scenarios and service requirements, identify which programs and services are key programs that need to be monitored. For example, in an AI computing environment, this may include training model inference engines, data preprocessing scripts, etc. Define a set of status attributes for each key program, such as process ID, memory usage, file handles, network connections, loaded library files, etc. These attributes will serve as the basic data for hash operations.

[0058] The monitoring agent tracks the state changes of key programs in real time, capturing each startup, stop, update, or abnormal behavior. For frequently changing data (such as network connections), the sampling frequency can be set to balance performance and security. The collected state data is filtered and normalized as necessary to remove unnecessary redundant information and ensure the efficiency of hash operations. A strong cryptographic hash algorithm (such as SHA-256 or SHA-3) is used to hash the state attributes of each key program to generate a hash value of a fixed length, namely the second hash value. If there are multiple key programs on an environment node, their hash values ​​need to be aggregated, which can be done by simply concatenating and hashing again, or more complex methods such as the Merkle tree structure to ensure overall integrity and consistency. The final generated hash value is written to the PCR register in the trusted cryptographic module (TCM). This step not only records the current operating status of the system, but also prevents tampering through the hardware protection provided by TEE.

[0059] In addition, set a hash value range or pattern for each critical program during normal operation. Once a behavior that deviates from the expected is detected, an alert is triggered immediately. When an abnormality occurs, the monitoring agent should take immediate measures, such as suspending related programs, recording logs, notifying administrators, etc., to minimize potential risks.

[0060] According to the importance and security requirements of the system, set an appropriate interval to recalculate the dynamic integrity measurement report, so that the latest system status can be reflected in a timely manner. Whenever a new hash value is received, it is compared with the previously stored value to ensure that the system has not been tampered with. If inconsistencies are found, further investigate the cause and take appropriate actions.

[0061] Through continuous monitoring and hashing, the system is ensured to remain in a controlled and trusted state during operation, and any potential security threats are discovered and responded to in a timely manner. The hardware protection and trusted cryptographic module provided by TEE are used to ensure the authenticity and non-tamperability of the measurement report, enhancing the reliability of the entire system. It can not only fully and accurately characterize the operating status of the sender and receiver systems, but also effectively improve the security and reliability in a distributed environment, providing a solid foundation for subsequent identity authentication and data transmission.

[0062] 203. The sender and the receiver each send their own digital certificate and public key to the other party, and verify whether the other party's digital certificate and public key are issued by a trusted third party.

[0063] In this step, since both the sender and the receiver have obtained their respective digital certificates and public keys from a trusted third party (such as a certificate authority, CA), the digital certificate contains the public key and related information, and is signed by the CA to prove its legitimacy. The sender and the receiver send their digital certificates to each other through the first handshake, and each environment node saves a copy of the other party's certificate for subsequent verification. Both parties use the pre-configured trusted root certificate library to verify the received digital certificate chain. The verification content includes but is not limited to: checking whether the certificate is issued by a trusted CA; confirming that the certificate has not expired and is not included in the revocation list (CRL or OCSP check); verifying that the real-name information (such as domain name, organization name, etc.) is consistent with expectations; if all verification conditions are met, the identity of the other party is considered to be legal. At this time, the other party's public key is extracted from the verified digital certificate for subsequent encryption and decryption operations for initial state and running state authentication.

[0064] Identity authentication can ensure the authenticity and legitimacy of the identities of both communicating parties, and prevent man-in-the-middle attacks and other forms of identity impersonation.

[0065] 204. The sender and the receiver negotiate and exchange a temporary shared key, and confirm that the identity authentication between the sender and the receiver is passed. The shared key is used for communication encryption of the secure channel.

[0066] In this step, according to the encryption suites supported by both parties (such as RSA, ECDH), select the appropriate key exchange algorithm. If the RSA algorithm is used, the sender generates a pre-master key, encrypts it with the receiver's public key and sends it, and the receiver decrypts it to obtain the pre-master key. If the ECDH algorithm is used, both parties generate a temporary public-private key pair, exchange their public keys, and then calculate the same shared key based on these public keys. Both parties can use MAC (message authentication code) or other methods to confirm the consistency of the shared key. After completing the above steps, both parties confirm that each other's identity authentication has passed and enter the initial state authentication process of steps 205-207.

[0067] A temporary shared key is negotiated and established in a secure manner, ensuring the communication security and confidentiality of the subsequent secure channel.

[0068] 205. After the identity authentication is passed, the sender and the receiver each use a private key to encrypt the first hash value corresponding to their own static integrity measurement report to obtain a digital signature corresponding to the static integrity measurement report.

[0069] In this step, the sender and the receiver read the first hash value generated previously from the TCM register respectively, and the hash value represents the initial state of the system. The first hash value is encrypted using their respective private keys to generate a digital signature, and the original static integrity measurement report is bundled with the corresponding digital signature to form a signed static integrity measurement report.

[0070] By digitally signing the static integrity measurement report, the authenticity and integrity of the report are guaranteed, providing a basis for subsequent initial status authentication.

[0071] 206. The sender and the receiver each send their own digital signature and static integrity measurement report to the other party, and use the public key provided by the other party to decrypt the digital signature to obtain a third hash value, and compare the third hash value with the first hash value to see if they are consistent.

[0072] In this step, the two parties exchange signed static integrity measurement reports. The receiver uses the public key provided by the sender to decrypt the digital signature, restore the original first hash value (called the third hash value), and compare the third hash value with the first hash value recorded by itself to see if they are consistent. If the two hash values ​​match, it proves that the sender's static integrity measurement report has not been tampered with and is indeed from the sender holding the corresponding private key.

[0073] By verifying the signature, the authenticity and completeness of the static integrity measurement report is ensured, thus confirming that the system state at startup is trustworthy.

[0074] 207. Determine that the initial state authentication between the sender and the receiver is successful.

[0075] In this step, if the third hash value is consistent with the first hash value, both parties confirm that the initial state authentication is passed. That is to say, between the sender and the receiver, in addition to the identity authentication, the initial state authentication is also verified. The passing of the initial state authentication ensures that the environmental nodes participating in the communication are in the expected security state at startup, thereby enhancing the security of the entire system.

[0076] 208. After the initial state authentication is passed, the sender and the receiver each use a private key to encrypt the fourth hash value corresponding to their own dynamic integrity measurement report to obtain a digital signature corresponding to the dynamic integrity measurement report.

[0077] In this step, the sender and the receiver read the latest second hash value from the TCM register respectively, which reflects the operating status of the system. The second hash value is encrypted using their respective private keys to generate a digital signature. The original dynamic integrity measurement report is bundled with the corresponding digital signature to form a signed dynamic integrity measurement report.

[0078] By digitally signing the dynamic integrity measurement report, the authenticity and integrity of the report are guaranteed, providing a basis for subsequent operation status authentication.

[0079] 209. The sender and the receiver each send their own digital signature and dynamic integrity measurement report to the other party, and use the public key provided by the other party to decrypt the digital signature to obtain a fourth hash value, and compare the fourth hash value with the second hash value to see if they are consistent.

[0080] In this step, the two parties exchange signed dynamic integrity measurement reports. The receiver uses the public key provided by the sender to decrypt the digital signature and restore the original second hash value (called the fourth hash value). The receiver compares the fourth hash value with the second hash value it has recorded to see if they are consistent. If the two hash values ​​match, it proves that the sender's dynamic integrity measurement report has not been tampered with and is indeed from the sender holding the corresponding private key.

[0081] By verifying the signature, the authenticity and completeness of the dynamic integrity measurement report are ensured, thus confirming that the state of the system during operation is trustworthy.

[0082] 210. Determine that the operation status authentication between the sender and the receiver is successful.

[0083] In this step, if the fourth hash value is consistent with the second hash value, both parties confirm that the running state authentication has passed. That is to say, after the verification is consistent in this step, the identity authentication, initial state authentication and running state authentication between the sender and the receiver are all passed, that is, the overall verification result is passed, and the passing of the running state authentication ensures that the environment nodes participating in the communication maintain the expected security state throughout the operation process, greatly improving the security and reliability of the communication.

[0084] When all authentication steps are passed, a TLS / SSL secure channel is formally established to ensure the security of subsequent data transmission, and step 211 is executed at this time.

[0085] 211. Establish a secure channel between the sender and the receiver so that data can be transmitted through the secure channel.

[0086] This step is combined with the description of step 104 in the above method, and the same contents are not repeated here.

[0087] Furthermore, in order to ensure the communication security and confidentiality of the secure channel, specifically, after establishing a secure channel between the sender and the receiver, the method also includes: using a shared key to encrypt the sender's data to be transmitted to obtain the encrypted data to be transmitted, and sending the encrypted data to be transmitted to the receiver based on the secure channel; after the receiver receives the encrypted data to be transmitted, the receiver uses the shared key to decrypt it, and verifies whether the first message authentication code carried in the encrypted data to be transmitted and the second message authentication code obtained by decryption are the same; if not, triggering the error handling mechanism of the secure channel, the error handling mechanism at least includes re-initializing authentication and interrupting the connection.

[0088] In this step, the sender and receiver have established a temporary shared key through the identity authentication and key negotiation process. According to the encryption suites supported by both parties (such as AES-GCM, ChaCha20-Poly1305), select the appropriate symmetric encryption algorithm and message authentication code (MAC) algorithm. Dividing the data to be transmitted into data blocks of appropriate size (such as record layer data in the TLS protocol) helps to improve encryption efficiency and simplify error handling. Generate a random initialization vector (IV) for each data block to increase the security of encryption. IV can be a random number or a pseudo-random number and is sent to the receiver together with the data before encryption. Encrypt each data block using the shared key and the selected encryption algorithm. For encryption modes with built-in authentication functions (such as AES-GCM), an authentication tag (i.e., the first message authentication code, MAC1) is generated at the same time. Combine the encrypted data, IV (if applicable), MAC1, and other necessary metadata (such as sequence number, timestamp) into a complete data packet.

[0089] These data packets are sent one by one according to the protocol specifications through an established secure channel (such as TLS / SSL). After receiving the data packet, the receiver first parses out the IV, encrypted data and MAC1. Using the same shared key and MAC algorithm, recalculate the MAC (i.e., the second message authentication code, MAC2) based on the received encrypted data and related metadata. Compare the recalculated MAC2 with the MAC1 attached to the received data packet. If the two are consistent, continue with the subsequent processing; if they are inconsistent, the error handling mechanism is triggered. The error handling mechanism includes re-initiating authentication and interrupting the connection. Among them, re-initiating authentication specifically refers to immediately stopping the current communication and re-executing the identity authentication and key negotiation process to re-establish a trust relationship, while interrupting the connection specifically refers to directly interrupting the current secure channel connection if re-authentication fails or for security reasons to prevent further data exchange.

[0090] In addition, record the error event in detail, including the key, IV, MAC, and any abnormal conditions used. Review these logs regularly to detect potential security issues or optimize encryption strategies.

[0091] When the MAC verification is successful, the receiver uses the shared key to decrypt the encrypted data. The specific decryption method depends on the encryption algorithm used. For data blocks that need to be padded, the padded part must be removed after decryption to restore the original data length. Check the metadata in the data packet (such as serial number, timestamp) to ensure the order and timeliness of the data packet.

[0092] based on Figure 2 For example, in a financial transaction system, two banks (Bank A and Bank B) need to exchange sensitive customer information and transaction data over the network. In order to ensure the confidentiality and integrity of these data during transmission, the two parties decide to adopt a secure channel transmission scheme based on a shared key and follow the steps 201-211 discussed previously to achieve comprehensive identity authentication, status authentication, and secure communication.

[0093] Specific implementation steps:

[0094] Initialization and identity authentication (steps 203-204):

[0095] Certificate exchange: Bank A and Bank B send their digital certificates and public keys to each other and verify whether the other party's digital certificate is issued by a trusted third party (such as DigiCert).

[0096] Key negotiation: Both parties use the ECDH algorithm to negotiate and exchange a temporary shared key for subsequent communication encryption. After completing the key negotiation, both parties confirm that each other's identity authentication has passed.

[0097] Static integrity measurement report generation and initial status authentication (steps 205-207):

[0098] Static Metrics Report Generation: Bank A and Bank B each generate a first hash value containing the static code and configuration file hash values ​​at startup, and write these hash values ​​into their respective Trusted Cryptographic Module (TCM) registers.

[0099] Signing and sending: Both parties use the private key to encrypt the first hash value, obtain the digital signature corresponding to the static integrity measurement report, and send the digital signature and the static integrity measurement report to the other party.

[0100] Verification and confirmation: The recipient uses the public key provided by the other party to decrypt the digital signature, obtain the third hash value, and compare the third hash value with the first hash value to see if they are consistent. If they are consistent, it is determined that the initial state authentication has passed.

[0101] Dynamic integrity measurement report generation and operation status authentication (steps 208-210):

[0102] Dynamic measurement report generation: Bank A and Bank B obtain the key program status respectively when the system is running, and calculate the second hash value and write it into the TCM register.

[0103] Signing and sending: Both parties use the private key to encrypt the second hash value, obtain the digital signature corresponding to the dynamic integrity measurement report, and send the digital signature and the dynamic integrity measurement report to the other party.

[0104] Verification and confirmation: The receiver uses the public key provided by the other party to decrypt the digital signature, obtain the fourth hash value, and compare the fourth hash value with the second hash value to see if they are consistent. If they are consistent, it is determined that the operation status authentication is passed.

[0105] Establishing a secure channel and data transmission (step 211):

[0106] Secure channel establishment: When all authentication steps are passed, the TLS / SSL secure channel is formally established to ensure the security of subsequent data transmission.

[0107] Data preparation and encryption: Bank A divides the customer transaction records to be transmitted into multiple data blocks of appropriate size, generates a random IV for each data block, and encrypts each data block using a shared key and the AES-GCM algorithm, while generating an authentication tag (MAC1).

[0108] Constructing a data packet: Combine the encrypted data, IV, MAC1, and other necessary metadata (such as sequence number, timestamp) into a complete data packet.

[0109] Receiving and decrypting:

[0110] Data reception: After receiving the data packet, Bank B first parses out the IV, encrypted data, and MAC1.

[0111] Recalculate MAC: Use the same shared key and AES-GCM algorithm to recalculate MAC (i.e., the second message authentication code, MAC2) based on the received encrypted data and related metadata.

[0112] Compare MAC: Compare the recalculated MAC2 with the MAC1 included in the received data packet. If the two are consistent, continue with the subsequent processing; if they are inconsistent, trigger the error handling mechanism.

[0113] Error handling mechanism:

[0114] Trigger condition: When MAC1 and MAC2 do not match, it indicates that the data may have been tampered with or there are other problems.

[0115] Re-authentication: Immediately stop the current communication and re-execute the identity authentication and key negotiation process to re-establish the trust relationship.

[0116] Disconnect: If re-authentication fails or for security reasons, the current secure channel connection is directly disconnected to prevent further data exchange.

[0117] Furthermore, as a response to the above Figure 1-2 The implementation of the method embodiment shown, the embodiment of the present application provides a trusted proof device based on a distributed scenario, which is used to comprehensively reflect the security status of the system in each stage from startup to operation in a distributed scenario, and ensure that all participating environmental nodes are in a trusted state, thereby realizing trusted proof in a distributed scenario. The embodiment of the device corresponds to the aforementioned method embodiment. For ease of reading, this embodiment will no longer repeat the details of the aforementioned method embodiment one by one, but it should be clear that the device in this embodiment can correspond to all the contents of the aforementioned method embodiment. Specifically, Figure 3 As shown, the distributed scenario includes a sender and a receiver, and the device includes:

[0118] A first generating unit 31 is used to generate a static integrity measurement report of each of the sender and the receiver based on system static data when the distributed scenario is started, and apply for a digital certificate and a public key from a trusted third party using the static integrity measurement report;

[0119] A second generating unit 32 is used to generate a dynamic integrity measurement report of each of the sender and the receiver based on system dynamic data when the distributed scenario is running;

[0120] A remote authentication unit 33, configured to perform identity authentication between the sender and the receiver using the digital certificate and the public key obtained by the first generation unit 31, perform initial status authentication using the signed static integrity measurement report obtained by the first generation unit 31, and perform running status authentication using the signed dynamic integrity measurement report obtained by the second generation unit 32;

[0121] The channel building unit 34 is configured to establish a secure channel between the sender and the receiver if the authentication result obtained by the remote authentication unit 33 is passed, so as to perform data transmission through the secure channel.

[0122] Further, such as Figure 4 As shown, the first generating unit 31 includes:

[0123] The first acquisition module 311 is used to respectively acquire the static code and configuration file of the sender and the receiver when the system is started;

[0124] The first processing module 312 is used to perform hash operations on the static code and the configuration file obtained by the first acquisition module 311 for each of the sender and the receiver, and write the obtained first hash value into the register of the trusted cryptographic module as the static integrity measurement report of the sender and the receiver, respectively. The static integrity measurement report is used to characterize the initial state of the system of the sender or the receiver.

[0125] Further, such as Figure 4 As shown, the second generating unit 32 includes:

[0126] The second acquisition module 321 is used to respectively acquire the key program status of the sender and the receiver when the system is running;

[0127] The second processing module 322 is used to perform hash operations on the key program states obtained by the second acquisition module 321 of each of the sender and the receiver, and write the obtained second hash values ​​into the register of the trusted cryptographic module as the dynamic integrity measurement reports of the sender and the receiver, respectively. The dynamic integrity measurement reports are used to characterize the operating status of the systems of the sender and the receiver.

[0128] Further, such as Figure 4 As shown, the remote authentication unit 33 includes:

[0129] The first authentication module 331 is used for the sender and the receiver to send their own digital certificates and public keys to each other, and verify whether the digital certificate and public key of the other party are issued by the trusted third party;

[0130] The first confirmation module 332 is used for if the first authentication module 331 verifies that the digital certificate and the public key of the other party are issued by the trusted third party, then the sender and the receiver negotiate and exchange a temporary shared key, and determine that the identity authentication between the sender and the receiver is passed, and the shared key is used for communication encryption of the secure channel.

[0131] Further, such as Figure 4 As shown, the remote authentication unit 33 includes:

[0132] A first encryption module 333, configured to, after the identity authentication is passed, encrypt the first hash value corresponding to the static integrity measurement report of each of the sender and the receiver using a private key to obtain a digital signature corresponding to the static integrity measurement report;

[0133] The second authentication module 334 is used for the sender and the receiver to each send the digital signature and the static integrity measurement report obtained by the first encryption module 333 to the other party, and use the public key provided by the other party to decrypt the digital signature to obtain a third hash value, and compare the third hash value with the first hash value to see whether they are consistent;

[0134] The second determination module 335 is configured to determine that the initial state authentication between the sender and the receiver is successful if the second authentication module compares the third Hash value and finds that the third Hash value is consistent with the first Hash value.

[0135] Further, such as Figure 4 As shown, the remote authentication unit 33 includes:

[0136] A second encryption module 336 is configured to, after the initial state authentication is passed, encrypt the fourth hash value corresponding to the dynamic integrity measurement report of each of the sender and the receiver using a private key to obtain a digital signature corresponding to the dynamic integrity measurement report;

[0137] A third authentication module 337 is used for the sender and the receiver to each send the digital signature and the dynamic integrity measurement report obtained by the second encryption module 336 to the other party, and use the public key provided by the other party to decrypt the digital signature to obtain a fourth Hash value, and compare whether the fourth Hash value is consistent with the second Hash value;

[0138] The third determination module 338 is used for the third authentication module 337 to compare the fourth Hash value with the second Hash value, and if it is consistent, then determine that the operation status authentication between the sender and the receiver is passed.

[0139] Further, such as Figure 4 As shown, the device also includes:

[0140] An encryption and transmission unit 35 is used to encrypt the data to be transmitted of the sender by using the shared key after the channel construction unit 34 to obtain the encrypted data to be transmitted, and send the encrypted data to be transmitted to the receiver based on the secure channel;

[0141] The receiving verification unit 36, after receiving the encrypted data to be transmitted sent by the encryption sending unit 35, uses the shared key to decrypt and verify whether the first message authentication code carried in the encrypted data to be transmitted and the second message authentication code obtained by decryption are the same;

[0142] The error handling unit 37 triggers the error handling mechanism of the security channel if the receiving verification unit 36 ​​verifies that the first message authentication code carried in the encrypted data to be transmitted is different from the second message authentication code obtained by decryption. The error handling mechanism at least includes re-initiation of authentication and interruption of connection.

[0143] Furthermore, an embodiment of the present application further provides a storage medium, wherein the storage medium is used to store a computer program, wherein when the computer program is running, the device where the storage medium is located is controlled to execute the above Figure 1-2 The trusted proof method based on distributed scenarios described in.

[0144] Furthermore, the embodiment of the present application also provides a processor, the processor is used to run a program, wherein the program executes the above Figure 1-2 The trusted proof method based on distributed scenarios described in.

[0145] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0146] It is understandable that the related features in the above methods and devices can be referenced to each other. In addition, the "first", "second" and the like in the above embodiments are used to distinguish the embodiments, but do not represent the advantages and disadvantages of the embodiments.

[0147] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0148] The algorithm and display provided herein are not inherently related to any particular computer, virtual system or other device. Various general purpose systems can also be used together with the teachings based on this. According to the above description, it is obvious that the structure required for constructing such systems. In addition, the application is not directed to any specific programming language either. It should be understood that various programming languages ​​can be utilized to realize the content of the application described herein, and the description of the specific language above is for the purpose of disclosing the best mode of implementation of the application.

[0149] In addition, the memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM, and the memory includes at least one memory chip.

[0150] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0151] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0152] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0153] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0154] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0155] The memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0156] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules 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 disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0157] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0158] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0159] The above are only embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included within the scope of the claims of the present application.

Claims

1. A trusted proof method based on a distributed scenario, characterized in that: The distributed scenario includes a sender and a receiver, and the method includes: When the distributed scenario is started, a static integrity measurement report of each of the sender and the receiver is generated based on the system static data, and a digital certificate and a public key are applied for from a trusted third party using the static integrity measurement report; When the distributed scenario is running, generating dynamic integrity measurement reports for the sender and the receiver based on system dynamic data; Between the sender and the receiver, identity authentication is performed using the digital certificate and the public key, initial status authentication is performed using the signed static integrity measurement report, and running status authentication is performed using the signed dynamic integrity measurement report; If the authentication result is passed, a secure channel is established between the sender and the receiver so as to perform data transmission through the secure channel.

2. The method according to claim 1, characterized in that Generating a static integrity measurement report of each of the sender and the receiver based on the system static data, including: Respectively obtain static codes and configuration files of the sender and the receiver when the system is started; For the sender and the receiver, hash operations are performed on their respective static codes and configuration files, and the obtained first hash values ​​are written into the register of the trusted cryptographic module as the static integrity measurement reports of the sender and the receiver, respectively. The static integrity measurement reports are used to characterize the initial state of the system of the sender or the receiver.

3. The method according to claim 1, characterized in that Generating a dynamic integrity measurement report for each of the sender and the receiver based on the system dynamic data, including: Respectively obtaining key program states of the sender and the receiver when the system is running; For the sender and the receiver, hash operations are performed on their respective key program states, and the obtained second hash values ​​are written into the register of the trusted cryptographic module as the dynamic integrity measurement reports of the sender and the receiver, respectively. The dynamic integrity measurement reports are used to characterize the operating states of the systems of the sender and the receiver.

4. The method according to claim 1, characterized in that: Performing identity authentication using the digital certificate and the public key includes: The sender and the receiver each send their own digital certificate and public key to the other party, and verify whether the other party's digital certificate and public key are issued by the trusted third party; If so, the sender and the receiver negotiate and exchange a temporary shared key, and determine that the identity authentication between the sender and the receiver is successful, and the shared key is used for communication encryption of the secure channel.

5. The method according to claim 4, characterized in that Initial state authentication using signed static integrity metrics reports, including: After the identity authentication is passed, the sender and the receiver each use a private key to encrypt the first hash value corresponding to their own static integrity measurement report to obtain a digital signature corresponding to the static integrity measurement report; The sender and the receiver each send their own digital signature and the static integrity measurement report to the other party, and use the public key provided by the other party to decrypt the digital signature to obtain a third Hash value, and compare the third Hash value with the first Hash value to see whether they are consistent; If so, it is determined that the initial state authentication between the sender and the receiver is successful.

6. The method according to claim 5, characterized in that Use signed dynamic integrity measurement reports to authenticate operational status, including: After the initial state authentication is passed, the sender and the receiver each use a private key to encrypt the fourth hash value corresponding to their own dynamic integrity measurement report to obtain a digital signature corresponding to the dynamic integrity measurement report; The sender and the receiver each send their own digital signature and the dynamic integrity measurement report to the other party, and use the public key provided by the other party to decrypt the digital signature to obtain a fourth Hash value, and compare the fourth Hash value with the second Hash value to see whether they are consistent; If so, it is determined that the running status authentication between the sender and the receiver is successful.

7. The method according to any one of claims 4 to 6, characterized in that: After establishing a secure channel between the sender and the receiver, the method further includes: Encrypting the data to be transmitted of the sender by using the shared key to obtain encrypted data to be transmitted, and sending the encrypted data to be transmitted to the receiver based on the secure channel; After receiving the encrypted data to be transmitted, the receiver uses the shared key to decrypt the data and verifies whether the first message authentication code carried in the encrypted data to be transmitted and the second message authentication code obtained by decryption are the same; If not, an error handling mechanism of the secure channel is triggered, and the error handling mechanism at least includes re-initiating authentication and terminating the connection.

8. A trusted proof device based on a distributed scenario, characterized in that: The distributed scenario includes a sender and a receiver, and the device includes: A first generating unit is used to generate a static integrity measurement report of each of the sender and the receiver based on system static data when the distributed scenario is started, and apply for a digital certificate and a public key from a trusted third party using the static integrity measurement report; A second generating unit, configured to generate a dynamic integrity measurement report for each of the sender and the receiver based on system dynamic data when the distributed scenario is running; a remote authentication unit, configured to perform identity authentication between the sender and the receiver using the digital certificate and the public key obtained by the first generation unit, perform initial status authentication using the signed static integrity measurement report obtained by the first generation unit, and perform running status authentication using the signed dynamic integrity measurement report obtained by the second generation unit; The channel construction unit is used to establish a secure channel between the sender and the receiver if the authentication result obtained by the remote authentication unit is passed, so as to transmit data through the secure channel.

9. A storage medium, characterized in that: The storage medium includes a stored program, wherein when the program is running, the device where the storage medium is located is controlled to execute the trusted certification method based on a distributed scenario as described in any one of claims 1 to 7.

10. A processor, characterized in that: The processor is used to run a program, wherein the program, when running, executes the trusted attestation method based on a distributed scenario as described in any one of claims 1 to 7.

Images