Clock Environment Trustworthiness Verification Method, Device, Equipment and Storage Medium

Abstract

The present application discloses a method, apparatus, device and storage medium for verifying the credibility of a clock environment, belonging to the field of computer technology, and is used to verify whether the clock environments of various node devices are credible. The method includes: receiving clock environment proof information sent by a node device, where the clock environment proof information includes a historical time proof sequence composed of time proofs generated by the node device within a historical time period, and each time proof is obtained by using the corresponding previous time proof as an input; verifying each time proof based on the previous time proof of the first time proof in the historical time proof sequence and each time proof in the historical time proof sequence; determining whether the actual duration of the historical time period matches the true duration based on the number of time proofs included in the historical time proof sequence; if the verification result indicates that all time proofs pass the verification and the actual duration matches the true duration, then determining that the clock environment of the node device is credible.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and provides a method, device, equipment and storage medium for verifying the credibility of a clock environment. Background Art

[0002] Time-sensitive products, such as web anti-tampering products, often need to configure the effective or invalid time periods of the protection directory protection rules in node devices. Therefore, the accuracy of time is very important for this type of product. If the system time of the node device is used as the standard, others may directly adjust the system time to keep the protection directory protection rules in the invalid time period all the time; but if the time of the management device is used as the standard, the problem of the reliability of the time of the management device itself still needs to be considered. If there is a problem with the time of the management device itself, it will cause problems with the node protection rules in all node devices at the same time. In addition, since the effective time of the node protection ability needs to be verified and proved, any failure of the management device, such as downtime or communication anomaly, may affect the file protection and prevention ability of the node device in real time. Moreover, in addition to the core file protection service being troubled by time problems, event summary programs such as web anti-tampering will also be affected. For example, if the time of the management device and the node device is inconsistent, and the management device summarizes node events according to its own time, there may be a situation of missing events.

[0003] Similarly, such time-sensitive products usually have the above problems. Therefore, there is an urgent need for a solution to verify the time reported by the node device. Summary of the Invention

[0004] Embodiments of the present application provide a method, device, equipment and storage medium for verifying the credibility of a clock environment, which are used to verify whether the clock environments of various node devices are credible.

[0005] On the one hand, a method for verifying the credibility of a clock environment is provided, which is applied to a management device included in a distributed service system. The method includes:

[0006] Receiving clock environment proof information sent by a node device, where the clock environment proof information includes a historical time proof sequence composed of time proofs generated by the node device in a historical time period, and each time proof is obtained by using the corresponding previous time proof as an input;

[0007] Based on the previous time proof of the first time proof in the historical time proof sequence, and each time proof in the historical time proof sequence, verifying each time proof to obtain a verification result; and,

[0008] Determine whether the actual duration of the historical time period recorded by the node terminal device is consistent with the true duration based on the number of time proofs included in the historical time proof sequence;

[0009] If the verification result indicates that all the time proofs pass the verification and the actual duration is consistent with the true duration, determine that the clock environment of the node terminal device is trustworthy.

[0010] Optionally, the method further includes:

[0011] If at least one of the following conditions is satisfied, generate an initial time proof for the node terminal device and send the initial time proof and the time stamp of the current moment to the node terminal device;

[0012] Among them, the conditions include:

[0013] The verification result indicates that the time proofs do not pass the verification;

[0014] The actual duration is not consistent with the true duration;

[0015] The node terminal device is restarted;

[0016] An exception occurs in the node terminal device.

[0017] On the one hand, a method for verifying the trustworthiness of a clock environment is provided, which is applied to a node terminal device included in a distributed service system. The method includes:

[0018] Adopt a cyclic iterative method to call a set encryption method to generate a historical time proof sequence corresponding to a historical time period; where each iteration process includes the following steps:

[0019] Obtain the latest generated historical time proof in the historical time proof sequence of the local node;

[0020] Use the historical time proof as input, call the encryption method to generate the current time proof corresponding to the current time, and link the current time proof to the historical time proof sequence; when the reporting opportunity arrives, send the clock environment proof information carrying the historical time proof sequence within the historical time period to the management terminal device, so that the management terminal device verifies the clock environment of the node terminal device based on the clock environment proof information.

[0021] Optionally, the method further includes:

[0022] Receive the initial time proof and the time stamp sent by the management terminal device;

[0023] Using the initial time proof and the time stamp as inputs, call the encryption method to generate the next time proof of the initial time proof, and link the next time proof to the initial time proof to form a historical time proof sequence.

[0024] Optionally, using the historical time proof as an input, call the encryption method to generate the current time proof corresponding to the current time, including:

[0025] If a business event is triggered at the current time, digitally sign the business event and perform a hash operation on the digital signature result to obtain the business event time proof corresponding to the business event;

[0026] Using the historical time proof and the business event time proof as inputs, call the encryption method to generate the current time proof corresponding to the current time.

[0027] On the one hand, a clock environment credibility verification device is provided, which is applied to the management end device included in the distributed business system. The device includes:

[0028] A receiving unit, configured to receive clock environment proof information sent by a node end device. The clock environment proof information includes a historical time proof sequence composed of time proofs generated by the node end device within a historical time period, and each time proof is obtained by using the corresponding previous time proof as an input;

[0029] A historical proof verification unit, configured to perform verification on each time proof based on the previous time proof of the first time proof in the historical time proof sequence and each time proof in the historical time proof sequence, and obtain a verification result;

[0030] A historical proof time estimation verification unit, configured to determine whether the actual duration of the historical time period recorded by the node end device is consistent with the true duration based on the number of time proofs included in the historical time proof sequence;

[0031] An output unit, configured to determine that the clock environment of the node end device is credible if the verification result indicates that each time proof passes the verification and the actual duration is consistent with the true duration.

[0032] Optionally, the historical proof verification unit is specifically configured to:

[0033] Perform sharding processing on the historical time proof sequence to obtain each time proof;

[0034] Construct a plurality of time proof combinations based on the previous time proof proven by the first time and the respective time proofs. Each time proof combination includes a first time proof and a second time proof generated by using the first time proof as an input.

[0035] For the plurality of time proof combinations, perform the following operations respectively:

[0036] For a time proof combination, based on the first time proof included in the time proof combination, obtain a third time proof by using the same encryption method as that of the node end device.

[0037] Determine whether the third time proof is consistent with the second time proof included in the time proof combination, and obtain a determination result.

[0038] Based on the determination results corresponding to the plurality of time proof combinations respectively, obtain the verification result.

[0039] Optionally, the historical proof time estimation verification unit is specifically configured to:

[0040] Based on the number of time proofs included in the historical time proof sequence and the hash generation capability corresponding to the node end device, determine the actual duration of the historical time period; wherein, the hash generation capability is used to represent the number of time proofs that the node end device can generate per unit time.

[0041] Determine whether the difference between the actual duration and the true duration is not greater than a set difference threshold; wherein, if the difference is not greater than the set difference threshold, the actual duration is consistent with the true duration, and if the difference is greater than the set difference threshold, the actual duration is not consistent with the true duration.

[0042] Optionally, the historical proof time estimation verification unit is specifically configured to:

[0043] Based on the actual duration, and the upper limit value and the lower limit value of the preset hash generation capability, determine the range of the number of time proofs that can be generated within the historical time period.

[0044] Determine whether the number is within the range of the number; wherein, if the number is within the range of the number, it is determined that the actual duration is consistent with the true duration, and if the number is not within the range of the number, it is determined that the actual duration is not consistent with the true duration.

[0045] Optionally, each of the time proofs includes an event time proof, and the event time proof is obtained by using the service event content and the latest time proof at the time when the service event occurs as inputs; then the historical proof time estimation verification unit is further configured to:

[0046] Determine an estimated time range for the occurrence of the service event based on the number of time proofs included in the historical time proof sequence and the position of the event time proof in the historical time proof sequence;

[0047] If it is determined that the estimated time range is consistent with the timestamp of the service event, determine that the occurrence time of the service event is true.

[0048] Optionally, the device further includes a reset unit for:

[0049] If at least one of the following conditions is met, generate an initial time proof for the node-end device, and send the initial time proof and the timestamp of the current moment to the node-end device;

[0050] Wherein, the conditions include:

[0051] The verification result indicates that each time proof fails the verification;

[0052] The actual duration does not match the true duration;

[0053] The node-end device restarts;

[0054] The node-end device has an abnormality.

[0055] On the one hand, a clock environment credibility verification device is provided, which is applied to a node-end device included in a distributed service system. The device includes:

[0056] A historical proof generation unit for generating a historical time proof sequence corresponding to a historical time period by calling a set encryption method in a cyclic iteration manner; wherein, each iteration process includes the following steps:

[0057] Obtain the latest generated historical time proof in the historical time proof sequence of the local node;

[0058] Use the historical time proof as an input, call the encryption method to generate a current time proof corresponding to the current time, and link the current time proof to the historical time proof sequence;

[0059] A historical proof reporting unit for sending clock environment proof information carrying the historical time proof sequence within a historical time period to a management-end device when the reporting opportunity arrives, so that the management-end device verifies the clock environment of the node-end device based on the clock environment proof information.

[0060] Optionally, the historical proof generation unit is further used for:

[0061] Receive the initial time proof and timestamp sent by the receiving management device;

[0062] Using the initial time proof and timestamp as inputs, call the encryption method to generate the next time proof of the initial time proof, and link the next time proof to the initial time proof to form a historical time proof sequence.

[0063] Optionally, the historical proof generation unit is specifically configured to:

[0064] If a service event is triggered at the current time, digitally sign the service event and perform a hash operation on the digital signature result to obtain the service event time proof corresponding to the service event;

[0065] Using the historical time proof and the service event time proof as inputs, call the encryption method to generate the current time proof corresponding to the current time.

[0066] On the one hand, a computer device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the steps of any of the above methods are implemented.

[0067] On the one hand, a computer storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the steps of any of the above methods are implemented.

[0068] On the one hand, a computer program product or computer program is provided. The computer program product or computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the steps of any of the above methods.

[0069] In the embodiments of the present application, the node-end device generates time proofs using an encryption method, and these generated time proofs constitute a historical time proof sequence. Since the generation time of each time proof is generally fixed, multiple calculations of time proofs consume a certain amount of time, so that the historical time proof sequence can represent the passage of time in the node-end device. In addition, the node-end device reports its own historical time proof sequence to the management-end device. Correspondingly, the management-end device verifies each time proof in the historical time proof sequence and verifies the actual duration represented by the historical time proof sequence. When both verifications pass, it indicates that the clock environment of the node-end device is trustworthy and can safely perform corresponding services. Since the calculation process of the historical time proof sequence must use the previous time proof as input to obtain a new time proof, that is, the calculation process is serial, it is impossible to predict what the specific subsequent time proof will be, and once a certain time proof is modified, the historical time proof sequence cannot pass the verification. Therefore, using the historical time proof sequence for time verification improves the credibility of the clock environment credibility verification. BRIEF DESCRIPTION OF THE DRAWINGS

[0070] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following will briefly introduce the drawings required for use in the description of the embodiments or related technologies. Obviously, the drawings in the following description are only the embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can also be obtained according to the provided drawings.

[0071] Figure 1 Schematic diagram of the application scenario provided by the embodiments of the present application;

[0072] Figure 2 Schematic diagram of the architecture of the distributed service system provided by the embodiments of the present application;

[0073] Figure 3 Schematic diagram of the relationship between tick and slot provided by the embodiments of the present application;

[0074] Figure 4 Schematic flowchart of a method for verifying the credibility of the clock environment provided by the embodiments of the present application;

[0075] Figure 5 Schematic flowchart of another method for verifying the credibility of the clock environment provided by the embodiments of the present application;

[0076] Figure 6 Schematic flowchart of still another method for verifying the credibility of the clock environment provided by the embodiments of the present application;

[0077] Figure 7A schematic structural diagram of the clock environment credibility verification device provided by an embodiment of the present application;

[0078] Figure 8 Another schematic structural diagram of the clock environment credibility verification device provided by an embodiment of the present application;

[0079] Figure 9 A schematic structural diagram of the computer device provided by an embodiment of the present application. Detailed implementation manners

[0080] To make the objectives, technical solutions, and advantages of the present application clearer and more understandable, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without making creative efforts shall fall within the protection scope of the present application. Without conflict, the embodiments in the present application and the features in the embodiments may be arbitrarily combined with each other. And although the logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than here.

[0081] To facilitate the understanding of the technical solutions provided by the embodiments of the present application, some key terms used in the embodiments of the present application are explained here first:

[0082] Historical time proof sequence: The historical time proof sequence belongs to the Proof of History (POH). POH is a computational sequence that can provide a cryptographic method to verify the passage of time between two events. It uses a secure encryption function, so that the output cannot be predicted from the input and must be fully executed to generate the output. The secure encryption function can be, for example, the SHA256 function or the RACE Integrity Primitives Evaluation Message Digest (RIPEMD) function, etc. When performing the calculation, the result of the previous hash operation is used as the input for the next hash operation, and each hash operation result is used as a time proof. Since the operation result cannot be predicted, it can only be performed on a single core, and it is impossible to create an entry that will generate the required hash in the future, nor can an alternative history with the same hash be created. Therefore, the passage of time is encoded in a verifiable data structure. When performing verification, it can be verified in parallel in segments, so the verification time is very short.

[0083] In the embodiments of the present application, the security encryption function adopted can be a hash operation function, so the time proof generated can be understood as a hash array, which is called an entry array. The historical time proof sequence (PoH stream) composed of these hash arrays, and the PoH stream is a hash chain inserted with time stamps.

[0084] Verifiable Delay Function (VDF): VDF has these characteristics. First, the verification of the result of VDF should be very efficient, and the time proof generated by VDF can be quickly verified. Second, the result of VDF has uniqueness. For any input of VDF, there should be a unique output result that can pass the test. That is to say, there do not exist two different outputs with the same input. Third, VDF is a serial operation algorithm, the execution time is predictable, and it cannot be accelerated through parallelism. Functions that meet these characteristics can all be used as the encryption function in the embodiments of the present application to generate corresponding time proofs. For example, the SHA256 function can be adopted.

[0085] In a distributed network architecture, for time-sensitive products, it is extremely important to ensure the credibility of time. Traditional time synchronization can use the time server mode based on the Network Time Protocol (NTP). However, others can completely interfere with the security of system services by modifying the system time. And when the node device is not connected to the NTP server network or attacks the NTP server, the trust problem of the node device still exists.

[0086] In view of this, the embodiments of the present application provide a method for verifying the credibility of the clock environment. In this method, the node device uses an encryption method to generate time proofs, and these generated time proofs constitute a historical time proof sequence. Since the generation time of each time proof is generally fixed, the calculation of multiple time proofs consumes a certain amount of time, so that the historical time proof sequence can represent the passage of time in the node device. In addition, the node device reports its own historical time proof sequence to the management device. Correspondingly, the management device verifies each time proof in the historical time proof sequence and the actual duration represented by the historical time proof sequence. When both verifications pass, it indicates that the clock environment of the node device is credible and can safely perform corresponding services. Since the calculation process of the historical time proof sequence must use the previous time proof as input to obtain a new time proof, that is, the calculation process is serial, it is impossible to predict what the subsequent time proof will be specifically, and once a certain time proof is modified, the historical time proof sequence cannot pass the verification. Therefore, using the historical time proof sequence for time verification improves the credibility of the clock environment credibility verification.

[0087] In addition, since the node device can maintain its own historical time proof sequence by itself, even if the network connection between the node device and the management device is disconnected, the node device can still continue to maintain the historical time proof sequence. When the connection between the node device and the management device is restored, the management device only needs to perform verification, thus solving the problem of time credibility caused by network differences.

[0088] In the embodiments of the present application, when generating a time proof, if a service event is triggered currently, the service time will also be used as input and recorded in the time proof. Thus, the service event is equivalent to being engraved with a historical record, occurring in a certain slot, which further increases the credibility of the time proof.

[0089] After introducing the design concept of the embodiments of the present application, the following briefly introduces the application scenarios applicable to the technical solutions of the embodiments of the present application. It should be noted that the following introduced application scenarios are only used to illustrate the embodiments of the present application rather than to limit them. In the specific implementation process, the technical solutions provided by the embodiments of the present application can be flexibly applied according to actual needs.

[0090] The solution provided by the embodiments of the present application can be applied to most distributed service scenarios, especially time-sensitive product scenarios such as web anti-tampering product scenarios. As Figure 1 shown, it is a schematic diagram of an application scenario provided by the embodiments of the present application. In this scenario, it may include multiple node devices 101 and a management device 102.

[0091] The node end device 101 can be, for example, devices such as mobile phones, tablet computers (PADs), laptop computers, desktop computers, smart TVs, in-vehicle terminals, smart wearable devices, and servers. The node end device 101 can be installed with business applications, such as web page anti-tampering applications or device security management applications, etc. These business applications can implement corresponding services when running on the node end device. The applications involved in the embodiments of this application can be software clients, or web pages, applets, etc. clients, or can also be service plugins integrated into other applications, without limiting the specific type of the application.

[0092] The management end device 102 can be the background server corresponding to the business application installed on the node end device 101. For example, it can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or can also be a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, i.e., Content Delivery Network (CDN), and big data and artificial intelligence platforms, etc., but is not limited thereto.

[0093] Both the management end device 102 and the node end device 101 can include one or more processors, memories, and I / O interfaces for interacting with the terminal, etc. In addition, both the management end device 102 and the node end device 101 can also be configured with databases, which can be used to store data involved in the embodiments of this application, etc. For example, the memory of the management end device 102 can store the program instructions of the clock environment credibility verification method executed by the management end device provided in the embodiments of this application. When these program instructions are executed by the processor, they can be used to implement the steps of the clock environment credibility verification method provided in the embodiments of this application to verify the clock environments of each node end device. Similarly, the memory of the node end device 101 can store the program instructions of the clock environment credibility verification method executed by the node end device provided in the embodiments of this application. When these program instructions are executed by the processor, they can be used to implement the steps of the clock environment credibility verification method provided in the embodiments of this application to generate a time proof of the node end device for the management end device to perform clock environment credibility verification.

[0094] Taking the web page anti-tampering scenario as an example, the management end device 102 and the node end device 101 can use the method of this application embodiment for time synchronization. The management end device 102 can set the effective time period of the protected directory of the node end device 101 according to the verified time. And since once the historical time proof sequence is tampered with, it cannot pass the verification, thus making the clock environment of the node end device credible. Then, combined with the effective time period configured by the management end device, web page anti-tampering protection can be executed within the credible effective time period.

[0095] A direct or indirect communication connection can be established between the node terminal device 101 and the management terminal device 102 through one or more networks 103. The network 103 can be a wired network or a wireless network. For example, the wireless network can be a mobile cellular network or a Wireless-Fidelity (WIFI) network. Of course, it can also be other possible networks, and the embodiments of the present invention do not limit this.

[0096] It should be noted that in the embodiments of the present application, the number of node terminal devices 101 can be one or more. Similarly, the number of management terminal devices 102 can also be one or more. That is to say, the number of node terminal devices 101 or management terminal devices 102 is not limited.

[0097] Of course, the method provided by the embodiments of the present application is not limited to Figure 1 the application scenarios shown, and can also be used in other possible application scenarios, which are not limited by the embodiments of the present application. The functions that can be achieved by each device in Figure 1 the application scenarios shown will be described together in the subsequent method embodiments, and will not be elaborated here too much.

[0098] See Figure 2 shown, which is a schematic diagram of the network architecture of the distributed service system provided by the embodiments of the present application. Among them, the network architecture includes a management end and a node end.

[0099] Specifically, the management end provides a POH management (poh_manage) service for managing and recording the POH information of each node end. The POH information includes the above-mentioned historical time proof sequence. As Figure 2 shown, the management end can specifically include three modules: a historical proof timing verification (check_poh_speed) module, a historical proof verification (poh_validator) module, and a historical proof storage (poh_recorder) module.

[0100] (1) Historical proof timing verification module

[0101] This module is used to verify the current slot. When performing time estimation verification, specifically based on a central processing unit (CPU) core, calculate the number of hashes (i.e., proof of time) that can be generated per second. Then, divide the number of generated hashes by the number of hashes that can be generated per second to calculate the number of seconds required for the generated hashes. Thus, after the node side submits the POH information, the specific approximate time range when the business event on the node side occurs can be estimated, and it can be determined whether the business event reported by the node is within a reasonable time range to ensure the authenticity of the business event occurrence time.

[0102] (2) Historical Proof Verification Module

[0103] This module is used to verify the POH information submitted by the node side, including the historical proof of time sequence. The historical proof verification module can verify the correctness of each proof of time in the historical proof of time sequence through a verification method verify.

[0104] Among them, the verify method can include two input parameters. For example, the first input parameter is the start hash, and the second input parameter is the entry array, which is the specific expression of the above historical proof of time sequence. In practical applications, the start hash can refer to the previous proof of time of the first event proof of the current historical proof of time sequence, or it can refer to the genesis hash, that is, the first proof of time issued by the management side. Since the management side also records the start hash of each node side, the node side can not carry the start hash when sending POH information.

[0105] (3) Historical Proof Storage Module

[0106] This module is used to store the currently verified slot of each node side for synchronizing historical proofs, that is, if the current ticks are within a specific range and pass the verification, they are recorded in the corresponding database (DB).

[0107] The node side provides a POH service (poh_service), which is specifically used to implement the generation and reporting of POH information. It can include a historical proof generation (poh_generator) module, a historical proof reporting (poh_send) module, and a historical proof storage module.

[0108] (1) Historical Proof Generation Module

[0109] This module is used to perform hash chain calculation, that is, generate proof of time.

[0110] See Figure 2As shown, the node terminal device also includes a service agent (agent) that implements services. When it triggers a service event message, the historical proof generation module will also perform a hash calculation based on the service event message and the previous time proof to generate the corresponding time proof. When no service event message is triggered, the historical proof generation module performs a hash calculation based on the previous time proof to generate the time proof at the current moment.

[0111] (2) Historical proof reporting module

[0112] This module is used to send ticks or entries to the poh_manage module on the server side if the current tick range is within the specified range. The POH management service module will record the slot and tick values of each node, as well as the hash of the current tick.

[0113] (3) Historical proof storage module

[0114] This module is used to store POH-related information generated by the node terminal.

[0115] For ease of understanding, before introducing the method of this application, the time environment involved in the embodiments of this application is introduced. In the embodiments of this application, in order to perform time proof more accurately, a custom network clock clock is adopted. The clock is used to express the information of the network clock of the node terminal device. The clock represents the network time, and the members of the clock start from 0. The clock is composed of ticks and slots to express time. The definition of the clock is as follows:

[0116]

[0117] Among them, tick is the smallest time measurement unit of the PoH stream. Tick divides 1 second. For example, it is defined as 160 ticks per second (ticks / s), that is, each tick occupies 6.25 milliseconds. Of course, the value of each tick can also be defined according to actual needs. A slot is a time unit. A slot contains multiple ticks. The specific number of ticks it contains can be defined by itself. For example, if each slot is defined to have 64 ticks, then each slot occupies 6.25 * 64 = 400 milliseconds.

[0118] See Figure 3 As shown, it is a schematic diagram of the relationship between tick and slot. Among them, Figure 3 Specifically, taking 160 ticks per second and each slot containing 64 ticks as an example, as Figure 3As shown, slot_index 0 contains 64 ticks from tick 0 to tick 63, slot_index 1 contains 64 ticks from tick 64 to tick 127, and so on.

[0119] Next, the method flow provided by each embodiment of the present application will be introduced. The method flow includes parts executed by the node device 101 and the management device 102 respectively.

[0120] Please refer to Figure 4 , which is a schematic flow diagram of a method for verifying the credibility of the clock environment provided by an embodiment of the present application. This method can be executed by the management device.

[0121] Step 401: Receive the historical time proof sequence sent by the node device. The historical time proof sequence includes the time proofs generated by the node device during the historical time period. Each time proof is obtained by using the corresponding previous time proof as input.

[0122] Step 402: Based on the previous time proof of the first time proof in the historical time proof sequence and each time proof in the historical time proof sequence, verify each time proof to obtain a verification result.

[0123] Step 403: Based on the number of time proofs included in the historical time proof sequence, determine whether the actual duration of the historical time period recorded by the node device matches the true duration.

[0124] It should be noted that there is no substantial order between step 402 and step 403. In practical applications, step 402 can be executed first, step 403 can be executed first, or step 402 and step 403 can be executed simultaneously. The embodiments of the present application do not limit this.

[0125] Step 404: If the verification result indicates that all time proofs pass the verification and the actual duration matches the true duration, determine that the clock environment of the node device is credible.

[0126] In the embodiments of the present application, the management device verifies each time proof in the historical time proof sequence and verifies the actual duration represented by the historical time proof sequence. When both verifications pass, it indicates that the clock environment of the node device is trustworthy and corresponding services can be safely performed. Since the calculation process of the historical time proof sequence must use the previous time proof as input to obtain a new time proof, that is, the calculation process is serial, it is impossible to predict what the subsequent time proof will be specifically, and once a certain time proof is modified, the historical time proof sequence cannot pass the verification. Therefore, the historical time proof sequence is used for time verification, which improves the credibility of the clock environment trustworthiness verification.

[0127] Please refer to Figure 5 , which is another schematic flowchart of the clock environment trustworthiness verification method provided by the embodiments of the present application. This method can be executed by the node device.

[0128] Step 501: In a loop iteration manner, call the set encryption method to generate a historical time proof sequence corresponding to the historical time period. Among them, in each iteration process, after obtaining the latest generated historical time proof in the historical time proof sequence of this node, use the historical time proof as input, call the encryption method to generate the current time proof corresponding to the current time, and link the current time proof to the historical time proof sequence.

[0129] Step 502: When the reporting opportunity arrives, send the historical time proof sequence to the management device so that the management device verifies the clock environment of the node device based on the historical time proof sequence.

[0130] In the embodiments of the present application, the node device uses the encryption method to generate time proofs, and these generated time proofs form a historical time proof sequence. Since the generation time of each time proof is generally fixed, the calculation of multiple time proofs requires a certain amount of time. Therefore, the historical time proof sequence can represent the passage of time in the node device. Moreover, since the calculation process of the historical time proof sequence must use the previous time proof as input to obtain a new time proof, that is, the calculation process is serial, it is impossible to predict what the subsequent time proof will be specifically, and once a certain time proof is modified, the historical time proof sequence cannot pass the verification. Therefore, the historical time proof sequence is used for time verification, which improves the credibility of the clock environment trustworthiness verification.

[0131] Since the method processes executed by the management device and the node device involve the interaction between the two, the following will introduce them in combination with the method processes on both sides. Refer to Figure 6 shown, which is yet another schematic flowchart of the clock environment trustworthiness verification method provided by the embodiments of the present application.

[0132] Step 601: The node end device installs and runs a business application integrated with a POH service software development kit (SDK), and generates a node identifier (UUID) and public-private keys for this node.

[0133] In the embodiments of the present application, the POH service SDK can be integrated into the business application. In this way, when the business application is running, the POH service SDK can be used to achieve time synchronization with the management end device, so as to ensure that the business process can be carried out in a trusted clock environment.

[0134] Step 602: The node end device reports the UUID and public-private keys to the management end device.

[0135] The node end device registers with the management end device and reports the UUID and public-private keys of this node.

[0136] Step 603: The management end device generates an initial time proof for this node end device.

[0137] Specifically, when the hash operation method is used as the encryption method, the historical time proof sequence generated by the node end device accordingly is a hash chain, and thus the initial time proof is the genesis hash of this node end device.

[0138] Step 604: The management end device sends the initial time proof and the current timestamp to the node end device.

[0139] In the embodiments of the present application, when the node end device accesses for the first time or the clock environment has an abnormality, the management end device needs to reset the time proof of the node end device, that is, send the initial time proof and the timestamp to it again, so that the node end device can start generating the historical time proof sequence again.

[0140] Specifically, when any of the following conditions is met, the node end device can reset the time proof of the node end device.

[0141] (1) When the management end device fails to pass the verification of each time proof in the historical time proof sequence, it indicates that the clock environment of the node end device may be modified and is untrusted, and then the node end device needs to be reset.

[0142] (2) When the management end device determines that the actual duration experienced by the node end device does not match the true duration, the clock of the node end device is abnormally refreshed and the clock environment is also untrusted, and then the node end device needs to be reset.

[0143] (3) When the node end device restarts, the node end device needs to be reset.

[0144] (4) If an abnormality occurs in the node end device, such as the node end device crashing abnormally, etc., and the clock environment is also untrusted, then the node end device needs to be reset.

[0145] Of course, other possible conditions may also be included, and the embodiments of the present application do not limit this.

[0146] Step 605: The node end device generates a historical time proof sequence based on the initial time proof and the current time stamp.

[0147] After the node end device receives the initial time proof and the time stamp sent by the management end device, it takes the initial time proof and the time stamp as inputs, calls an encryption method to generate the next time proof of the initial time proof, and links the next time proof to the initial time proof to form a historical time proof sequence. Among them, this process can be implemented, for example, through Figure 2 the historical proof generation module shown.

[0148] In the embodiments of the present application, taking SHA256 as an example, SHA256 is used as the VDF function of the node end device, which is irreversible and can only be calculated unidirectionally. The selected SHA256 function is collision-resistant, so that the historical time proof sequence can only be calculated and generated sequentially by a single computer thread. In the historical time proof sequence, the previous output is used as the current input of SHA256, and the data to be written is appended to the input. In this way, the output and the number of times of SHA256 are periodically recorded. The node end device obtains the required time interval by repeating this calculation process to represent the historical time consumed by the node end device. This method makes the recording of time not affected by the local time caused by transmission and changes.

[0149] As shown in Table 1 below, in the first hash calculation, the genesis hash and the time stamp sent by the management end device are used as the inputs of sha256 to obtain hash1. Hash1 and its index ID can form an entry array [1, hash1]. When the 200th hash calculation is performed, the previous output, that is, hash299, is used as the input of sha256 to obtain hash200. Hash200 and its index ID can form an entry array [200, hash200]. The remaining calculations are similar and will not be elaborated here.

[0150]

[0151] Table 1

[0152] Refer to Table 1. If the algorithm value is not actually run 300 times from the beginning, it is impossible to predict what the hash value at index 300 is. Therefore, we can infer from the data structure that the real time between index 0 and index 300 has passed.

[0153] In the embodiments of the present application, POH may adopt the following structure:

[0154]

[0155] Among them, hash represents the current proof of time, that is, the current hash. numHashes is the number of hashes, representing the number of generated proofs of time. tickNumber represents the current tick number, and slotStartTime represents the start time of the current slot, which can be represented by the physical time of the node-side device.

[0156] In the embodiments of the present application, the POH structure provides two hash operation methods, namely tick() and record(), which correspond to hash operations when there is no business event trigger and when there is a business event trigger, respectively.

[0157] (1) When there is no business event trigger and it is the time to generate the proof of time, tick() can be called for hash operation to generate the proof of time at the current moment.

[0158] Specifically, when tick() is called once, the numHashes variable in the POH object is incremented by 1, the hash variable of the POH object is updated to the new hash generated by the hash calculation, and tickNumber is incremented by 1.

[0159] (2) When there is a business event trigger and it is the time to generate the proof of time, record() can be called for hash operation to generate the proof of time at the current moment. When record() is called, the event message signature hash and the previous hash are mixed for hash operation.

[0160] Specifically, if a business event is triggered at the current time, the business event is digitally signed, and the digital signature result is hashed to obtain the business event hash value corresponding to the business event. Using the historical proof of time and the business event hash value as inputs, an encryption method is called to generate the proof of time corresponding to the current time.

[0161] In the embodiments of the present application, the Entry structure provides a method for generating the next hash value (nextHash), which is used to calculate the next hash based on the current hash. It calls the tick() method or the record() method of the poh instance according to whether there is an event message in the current entry.

[0162] Among them, the Entry structure contains three parameters: startHash string, numHashes int64, and messages[]string. startHash is the start hash, numHashes is the number of hashes, and messages is the event message. For example, the file tampering message. The historical proof verification module on the management side verifies the entry array here in parallel by sharding. For example, an Entry array can be expressed as {numHashes, hash, message}.

[0163] Specifically, when the node-side device triggers a business event message, it can process and assemble the business event message message in JSON format, sign it with the private key, perform a hash256 operation on the signature result, and then perform another hash256 operation on the obtained event signature hash and the previous hash as the input hash for the next hash calculation.

[0164] Step 606: The node-side device sends clock environment proof information to the management-side device, and the management-side device receives the clock environment proof information.

[0165] In the embodiment of the present application, when the reporting opportunity arrives, the node-side device will send clock environment proof information to the management-side device so that the management-side device can verify the clock environment of the node-side device based on the clock environment proof information.

[0166] Among them, the node side can report the clock environment proof information periodically or when the reporting condition is met, such as when an event message is triggered, etc.

[0167] Specifically, the clock environment proof information may include at least one of the following information:

[0168] (1) Historical time proof sequence

[0169] The historical time proof sequence reported by the node-side device to the management-side device can be reported in the form of multiple entry arrays. For example, [{1, hash1, null}{2, hash2, message}], where null indicates that no business event message was triggered at the moment when hash1 is located.

[0170] In practical applications, due to the continuous formation of time proofs by the node-side device, there are a large number of time proofs. When reporting, the updated time proofs can be reported, that is, the time proofs generated after the previous report and not yet reported.

[0171] (2) Start hash

[0172] Among them, the starting hash can refer to the genesis hash issued by the management device to the node device to assist in verifying the identity and clock environment of the node device. The starting hash can also be the starting hash of the current slot, or the previous hash of the historical proof-of-time sequence sent this time.

[0173] (3) Current tick

[0174] (4) Current slot

[0175] Of course, other information can also be included, and the embodiments of this application do not limit this.

[0176] Step 607: The management device verifies each proof of time and obtains a verification result.

[0177] In the embodiments of this application, the management device verifies each proof of time based on the previous proof of time of the first proof of time in the historical proof-of-time sequence and each proof of time in the historical proof-of-time sequence, and obtains a verification result.

[0178] Specifically, in order to improve the verification speed, the management device can use the concurrent verification method for verification, and when conditions permit, it can also use the GPU for verification to further improve the verification speed. When performing verification, the management device can perform sharding processing on the received historical proof-of-time sequence to obtain each proof of time, that is, the above-mentioned entry array. In this way, multiple proof-of-time combinations can be constructed based on the previous proof of time of the first proof of time and each proof of time. Each proof-of-time combination includes a first proof of time and a second proof of time generated with the first proof of time as the input.

[0179] For multiple proof-of-time combinations, the following operations are respectively performed:

[0180] For one of the proof-of-time combinations A, using the first proof of time included in the proof-of-time combination A as the input, the third proof of time is obtained by using the same encryption method as the node device, and then it is determined whether the third proof of time is consistent with the second proof of time included in a proof-of-time combination, and a determination result is obtained.

[0181] Furthermore, the management device obtains a verification result based on the determination results respectively corresponding to multiple proof-of-time combinations. When all determination results indicate consistency, the verification passes; otherwise, the verification fails.

[0182] In the embodiments of the present application, the verification process can be implemented by the historical proof verification module included in the management device. Since the time proof can be divided into two types, one is the time proof when the service event is not triggered, and the other is the time proof when the service event is triggered. In order to perform accurate verification, the historical proof verification module provides corresponding verification methods, that is, the verification methods are divided into tick verification and maxin verification. Tick verification does not mix business message content, that is, it verifies a simple hash, and maxin verification mixes business messages and verifies the hash with the business message signature.

[0183] Step 608: The management device determines whether the actual duration of the historical time period recorded by the node device matches the true duration.

[0184] In the embodiments of the present application, in addition to verifying the correctness of the above time proof, it is also necessary to verify whether the actual duration experienced by the node device is consistent with the true duration. Among them, the true duration can be obtained according to the time difference between the previous report and the current report, or can be calculated according to the tick or slot reported by the node device to verify whether the current tick or slot of the node device is correct.

[0185] Specifically, the management device can determine whether the actual duration of the historical time period recorded by the node device matches the true duration based on the number of time proofs included in the historical time proof sequence.

[0186] In one implementation, the management device can estimate the actual duration experienced by the node device based on the number of time proofs, and then determine whether the actual duration matches the true duration.

[0187] Specifically, the management device can determine the actual duration of the historical time period based on the number of time proofs included in the historical time proof sequence and the hash generation ability corresponding to the node device, and then determine whether the difference between the actual duration and the true duration is not greater than the set difference threshold. If the difference is not greater than the set difference threshold, the actual duration matches the true duration. If the difference is greater than the set difference threshold, the actual duration does not match the true duration.

[0188] Among them, the hash generation ability is used to represent the number of time proofs that the node device can generate per unit time. Generally speaking, the hash generation ability has a fixed value or range.

[0189] In one implementation, the management device can generate the range of the number of time proofs that can be generated within the historical time period based on the preset hash generation ability range, and then determine whether the reported number is within this range. Among them, the hash generation ability range can be the limit value range or the average value range obtained after statistics on a large number of models.

[0190] Specifically, the management device can determine the range of the number of time proofs that can be generated within the historical time period based on the actual duration, as well as the upper and lower limit values of the preset hash generation ability, and determine whether the number is within the range. If the number is within the range, it is determined that the actual duration is consistent with the true duration. If the number is not within the range, it is determined that the actual duration is inconsistent with the true duration.

[0191] The above process can be implemented by the historical proof time estimation and verification module included in the management device.

[0192] In the embodiment of the present application, when each time proof included in the historical time proof sequence includes an event time proof, and the event time proof is obtained by using the business event content and the latest time proof at the time when the business event occurs as inputs, then it is also possible to verify whether the time when the business event occurs is credible.

[0193] Specifically, the management device can determine the estimated time range when the business event occurs based on the number of time proofs included in the historical time proof sequence and the position of the event time proof in the historical time proof sequence. If it is determined that the estimated time range is within the range of the true duration, such as whether it matches the true timestamp, to determine whether the time when the business event occurs is credible.

[0194] Step 609: If the verification result indicates that all time proofs pass the verification and the actual duration is consistent with the true duration, the management device determines that the clock environment of the node device is credible.

[0195] Step 610: The management device records the current clock information of the node device.

[0196] If the management device determines that the clock environment of the node device is credible, it will store the current clock information of the node device through the historical proof storage module.

[0197] If the management device determines that the clock environment of the node device is not credible, the management device regenerates the initial time proof and sends the initial time proof and the timestamp of the current moment to the node device.

[0198] In summary, the node device in the embodiment of the present application uses the VDF function to encode time to generate a time proof, thereby maintaining its own clock. Since each node device maintains its own clock, the management device runs the VDF to prove that it has passed a specific time period (slot). That is to say, each node uses the number of time proofs generated per unit time as the basis to verify the passage of time to determine how much time has passed between events. Each hash represents a time unit (i.e., the time it takes to calculate the SHA-256 hash value), and each hash is associated with an id representing the order of the hash. Any device can use the historical proof to quickly verify whether the timestamp of the message is correct.

[0199] When the node device is first installed and started, the management device assigns a uuid and a genesis hash to the node. The node performs hash chain operations based on the genesis hash to generate historical proofs, and the management device verifies the historical proofs of the node at specific intervals. For the hash chain (i.e., POH) calculation of the node device, when business events such as file tampering events occur at the node device, the event message is signed and then hashed, and the hash calculation result is mixed into the poh calculation. In this way, the event is equivalent to being engraved with a historical record and occurs in a certain slot.

[0200] In addition, the node device performs hash chain calculations on a single core, and the management device performs verification. Even in an offline environment where the management device and the node device are disconnected from the network, the node device can still perform hash chain calculations. When the network is restored, the management device can perform verification, which solves the problem of time trust for time-sensitive products such as web anti-tampering, such as the problem of the trustworthiness of the protection effective time of the protected directory, and solves the problem of the trustworthiness of the node time in scenarios where the node is not connected to the time server or the node time is modified or attacked, providing a new way of time management and measurement, enabling users to complete business protection functions in a trusted clock environment.

[0201] Please refer to Figure 7 , based on the same inventive concept, the embodiment of the present application further provides a clock environment credibility verification device 70, which is applied to the management device included in the distributed service system. The device includes:

[0202] A receiving unit 701, configured to receive clock environment proof information sent by the node device. The clock environment proof information includes a historical time proof sequence composed of time proofs generated by the node device within a historical time period, and each time proof is obtained by using the corresponding previous time proof as an input;

[0203] A historical proof verification unit 702, configured to, based on a previous time proof of the first time proof in a historical time proof sequence, and each time proof in the historical time proof sequence, verify each time proof to obtain a verification result;

[0204] A historical proof timing verification unit 703, configured to determine whether an actual duration of a historical time period recorded by a node end device matches a true duration based on the number of time proofs included in the historical time proof sequence;

[0205] An output unit 704, configured to determine that the clock environment of the node end device is trustworthy if the verification result indicates that all time proofs pass the verification and the actual duration matches the true duration.

[0206] Optionally, the historical proof verification unit 702 is specifically configured to:

[0207] Slice the historical time proof sequence to obtain each time proof;

[0208] Construct multiple time proof combinations based on the previous time proof of the first time proof and each time proof, where each time proof combination includes a first time proof and a second time proof generated by using the first time proof as an input;

[0209] For multiple time proof combinations, perform the following operations respectively:

[0210] For a time proof combination, based on the first time proof included in the time proof combination, obtain a third time proof by using the same encryption method as the node end device;

[0211] Determine whether the third time proof is consistent with the second time proof included in the time proof combination to obtain a determination result;

[0212] Based on the determination results corresponding to multiple time proof combinations, obtain the verification result.

[0213] Optionally, the historical proof timing verification unit 703 is specifically configured to:

[0214] Determine the actual duration of the historical time period based on the number of time proofs included in the historical time proof sequence and the hash generation ability corresponding to the node end device; where the hash generation ability is used to represent the number of time proofs that the node end device can generate per unit time;

[0215] Determine whether the difference between the actual duration and the true duration is not greater than a set difference threshold; where if the difference is not greater than the set difference threshold, the actual duration matches the true duration, and if the difference is greater than the set difference threshold, the actual duration does not match the true duration.

[0216] Optionally, the historical proof timing verification unit 703 is specifically configured to:

[0217] Based on the actual duration, as well as the upper and lower limit values of the preset hash generation capability, determine the range of the number of time proofs that can be generated within the historical time period;

[0218] Determine whether the quantity is within the quantity range; wherein, if the quantity is within the quantity range, it is determined that the actual duration matches the true duration, and if the quantity is not within the quantity range, it is determined that the actual duration does not match the true duration.

[0219] Optionally, each time proof includes an event time proof, and the event time proof is obtained by using the business event content and the latest time proof at the time when the business event occurs as inputs; then the historical proof timing verification unit is further configured to:

[0220] Based on the number of time proofs included in the historical time proof sequence and the position of the event time proof in the historical time proof sequence, determine the estimated time range when the business event occurs;

[0221] If it is determined that the estimated time range is consistent with the time stamp of the business event, it is determined that the occurrence time of the business event is real.

[0222] Optionally, the device further includes a reset unit 705, configured to:

[0223] If at least one of the following conditions is satisfied, generate an initial time proof for the node-end device, and send the initial time proof and the time stamp of the current moment to the node-end device;

[0224] Wherein, the conditions include:

[0225] The verification result indicates that each time proof fails the verification;

[0226] The actual duration does not match the true duration;

[0227] The node-end device restarts;

[0228] The node-end device has an exception.

[0229] This device can be used to execute the methods executed by the management-end device in the embodiments of the present application. Therefore, for the functions that can be realized by each functional module of this device, reference can be made to the descriptions of the foregoing embodiments, and details are not described herein again.

[0230] Please refer to Figure 8 , based on the same inventive concept, an embodiment of the present application further provides a clock environment credibility verification device 80, which is applied to a node-end device included in a distributed service system. The device includes:

[0231] A historical proof generation unit 801, which is used to generate a historical time proof sequence corresponding to a historical time period by calling a set encryption method in a loop iteration manner; wherein, each iteration process includes the following steps:

[0232] Obtain the latest generated historical time proof in the historical time proof sequence of this node;

[0233] Use the historical time proof as input, call the encryption method to generate the current time proof corresponding to the current time, and link the current time proof to the historical time proof sequence;

[0234] A historical proof reporting unit 802, which is used to send clock environment proof information carrying the historical time proof sequence within the historical time period to the management device when the reporting opportunity arrives, so that the management device can verify the clock environment of the node device based on the clock environment proof information.

[0235] Optionally, the historical proof generation unit 801 is further used for:

[0236] Receive the initial time proof and time stamp sent by the management device;

[0237] Use the initial time proof and time stamp as input, call the encryption method to generate the next time proof of the initial time proof, and link the next time proof after the initial time proof to form a historical time proof sequence.

[0238] Optionally, the historical proof generation unit 801 is specifically used for:

[0239] If a service event is triggered at the current time, digitally sign the service event and perform a hash operation on the digital signature result to obtain the service event time proof corresponding to the service event;

[0240] Use the historical time proof and the service event time proof as input, call the encryption method to generate the current time proof corresponding to the current time.

[0241] This device can be used to execute the methods performed by the node device in the embodiments of the present application. Therefore, for the functions that can be realized by each functional module of this device, reference can be made to the descriptions of the foregoing embodiments, and details will not be repeated.

[0242] Please refer to Figure 9 , based on the same technical concept, the embodiments of the present application further provide a computer device 90, which can be Figure 1 the terminal device or server shown in the figure. This computer device 90 may include a memory 901 and a processor 902.

[0243] The memory 901 is used to store computer programs executed by the processor 902. The memory 901 may mainly include a program storage area and a data storage area. Among them, the program storage area may store an operating system, application programs required for at least one function, etc.; the data storage area may store data created according to the use of the computer device, etc. The processor 902 may be a central processing unit (CPU) or a digital processing unit, etc. In the embodiments of the present application, the specific connection medium between the above-mentioned memory 901 and the processor 902 is not limited. In the embodiments of the present application Figure 9 it is connected between the memory 901 and the processor 902 through a bus 903. The bus 903 is represented by a thick line in Figure 9 and the connection manners between other components are only for illustrative purposes and are not to be taken as limiting. The bus 903 may be divided into an address bus, a data bus, a control bus, etc. For the sake of convenience of representation, Figure 9 it is only represented by a thick line in, but it does not mean that there is only one bus or one type of bus.

[0244] The memory 901 may be a volatile memory, such as a random-access memory (RAM); the memory 901 may also be a non-volatile memory, such as a read-only memory, a flash memory, a hard disk drive (HDD) or a solid-state drive (SSD), or the memory 901 is any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited thereto. The memory 901 may be a combination of the above-mentioned memories.

[0245] The processor 902 is used to execute the methods executed by the devices in the above-mentioned embodiments when calling the computer programs stored in the memory 901.

[0246] In some possible implementation manners, various aspects of the method provided in the present application may also be implemented in the form of a program product, which includes program code. When the program product runs on a computer device, the program code is used to cause the computer device to execute the steps in the methods according to various exemplary embodiments of the present application described above in this specification. For example, the computer device may execute the methods executed by the devices in the above-mentioned embodiments.

[0247] The program product may employ any combination of one or more readable media. The readable media may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples (a non-exhaustive list) of the readable storage medium include: an electrical connection having one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0248] Although the preferred embodiments of the present application have been described, additional changes and modifications can be made to these embodiments by those skilled in the art once they learn of the basic creative concept. Therefore, the appended claims are intended to be construed to include the preferred embodiments as well as all changes and modifications that fall within the scope of the present application.

[0249] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalent technologies, the present application is also intended to include these modifications and variations.

Claims

1. A method for verifying the credibility of a clock environment, characterized in that Applied to the management terminal device included in the distributed service system, the method includes: Receiving clock environment proof information sent by the node terminal device, where the clock environment proof information includes a historical time proof sequence composed of time proofs generated by the node terminal device within a historical time period, and each time proof is obtained by using the corresponding previous time proof as input; Based on the previous time proof of the first time proof in the historical time proof sequence and each time proof in the historical time proof sequence, verifying each time proof to obtain a verification result; and, Based on the number of time proofs included in the historical time proof sequence and the hash generation ability of the node terminal device, determining whether the actual duration of the historical time period recorded by the node terminal device is consistent with the true duration; where the hash generation ability is used to represent the number of time proofs that the node terminal device can generate per unit time; or, based on the number of time proofs included in the historical time proof sequence and the preset upper and lower limit values of the hash generation ability, determining whether the actual duration is consistent with the true duration; If the verification result indicates that all time proofs pass the verification and the actual duration is consistent with the true duration, determining that the clock environment of the node terminal device is trustworthy.

2. The method according to claim 1, characterized in that, Based on the previous time proof of the first time proof in the historical time proof sequence and each time proof in the historical time proof sequence, verifying each time proof includes: Performing sharding processing on the historical time proof sequence to obtain each time proof; Based on the previous time proof of the first time proof and each time proof, constructing multiple time proof combinations, where each time proof combination includes a first time proof and a second time proof generated by using the first time proof as input; For the multiple time proof combinations, respectively perform the following operations: For a time proof combination, based on the first time proof included in the time proof combination, obtaining a third time proof by using the same encryption method as the node terminal device; Determining whether the third time proof is consistent with the second time proof included in the time proof combination to obtain a determination result; Based on the determination results corresponding to the multiple time proof combinations, obtaining the verification result.

3. The method according to claim 1, characterized in that Based on the number of time proofs included in the historical time proof sequence, determining whether the actual duration of the historical time period recorded by the node terminal device is consistent with the true duration includes: Based on the number of time proofs included in the historical time proof sequence and the hash generation ability corresponding to the node terminal device, determining the actual duration of the historical time period; Determining whether the difference between the actual duration and the true duration is not greater than a set difference threshold; where if the difference is not greater than the set difference threshold, the actual duration is consistent with the true duration, and if the difference is greater than the set difference threshold, the actual duration is not consistent with the true duration.

4. The method according to claim 1, characterized in that, Determine whether the actual duration of the historical time period recorded by the node-end device is consistent with the true duration based on the number of time proofs included in the historical time proof sequence, including: Based on the actual duration, as well as the upper and lower limit values of the preset hash generation capability, determine the range of the number of time proofs that can be generated within the historical time period; Determine whether the number is within the range of the number; wherein, if the number is within the range of the number, it is determined that the actual duration is consistent with the true duration, and if the number is not within the range of the number, it is determined that the actual duration is not consistent with the true duration.

5. The method according to any one of claims 1 to 4, characterized in that, Each of the time proofs includes an event time proof, and the event time proof is obtained by using the service event content and the latest time proof at the time when the service event occurs as inputs; then the method further includes: Based on the number of time proofs included in the historical time proof sequence and the position of the event time proof in the historical time proof sequence, determine the estimated time range when the service event occurs; If it is determined that the estimated time range is consistent with the time stamp of the service event, it is determined that the occurrence time of the service event is true.

6. A method for verifying the trustworthiness of a clock environment, characterized in that Applied to the node-end device included in the distributed service system, the method includes: Adopt a cyclic iterative manner to call the set encryption method to generate a historical time proof sequence corresponding to the historical time period; wherein, each iteration process includes the following steps: Obtain the latest generated historical time proof in the historical time proof sequence of the local node; Using the historical time proof as an input, call the encryption method to generate the current time proof corresponding to the current time, and link the current time proof to the historical time proof sequence; when the reporting opportunity arrives, send the clock environment proof information carrying the historical time proof sequence within the historical time period to the management-end device, so that the management-end device verifies the clock environment of the node-end device based on the clock environment proof information; wherein, when all the time proofs included in the historical time proof sequence pass the verification, and the actual duration of the historical time period recorded by the number of each time proof is consistent with the true duration, the clock environment of the node-end device is trustworthy, and the actual duration is determined according to the number of each time proof and the hash generation capability of the node-end device; or, whether the actual duration is consistent with the true duration is determined based on the number of each time proof and the upper and lower limit values of the preset hash generation capability.

7. A clock environment credibility verification device, characterized in that, Applied to the management-end device included in the distributed service system, the device includes: A receiving unit, configured to receive the clock environment proof information sent by the node-end device, where the clock environment proof information includes a historical time proof sequence composed of time proofs generated by the node-end device within the historical time period, and each time proof is obtained by using the corresponding previous time proof as an input; A historical proof verification unit for verifying each of the time proofs in the historical time proof sequence based on the previous time proof of the first time proof in the historical time proof sequence and each time proof in the historical time proof sequence, to obtain a verification result; A historical proof time estimation verification unit for determining whether the actual duration of the historical time period recorded by the node device matches the true duration based on the number of time proofs included in the historical time proof sequence and the hash generation ability of the node device; wherein, the hash generation ability is used to represent the number of time proofs that the node device can generate per unit time; or, determining whether the actual duration matches the true duration based on the number of time proofs included in the historical time proof sequence and a preset upper limit value and a lower limit value of the hash generation ability; An output unit for determining that the clock environment of the node device is trustworthy if the verification result indicates that all the time proofs pass the verification and the actual duration matches the true duration.

8. A clock environment credibility verification device, characterized in that Applied to a node device included in a distributed service system, the device includes: A historical proof generation unit for generating a historical time proof sequence corresponding to a historical time period by using a cyclic iteration method and invoking a set encryption method; wherein, each iteration process includes the following steps: Obtain the latest generated historical time proof in the historical time proof sequence of the local node; Using the historical time proof as an input, invoking the encryption method to generate a current time proof corresponding to the current time, and linking the current time proof to the historical time proof sequence; A historical proof reporting unit for sending clock environment proof information carrying the historical time proof sequence within the historical time period to a management device when the reporting opportunity arrives, so that the management device verifies the clock environment of the node device based on the clock environment proof information; wherein, when all the time proofs included in the historical time proof sequence pass the verification and the actual duration of the historical time period recorded by the number of all the time proofs matches the true duration, the clock environment of the node device is trustworthy, and the actual duration is determined according to the number of all the time proofs and the hash generation ability of the node device; or, whether the actual duration matches the true duration is determined based on the number of all the time proofs and a preset upper limit value and a lower limit value of the hash generation ability.

9. A computer device, including a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 5 or 6.

10. A computer storage medium, on which computer program instructions are stored, characterized in that When the computer program instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 5 or 6.

Images