Bidding document generation method, verification method, electronic equipment and medium

Abstract

The present application discloses a method for generating and verifying a bidding document. The generating method is applied to a first terminal, and the first terminal is connected to a first encryption lock in communication. The method comprises: based on a device private key in the first encryption lock, processing a first file and a serial number of the first encryption lock to obtain first data; wherein the first file comprises at least one operation record data, each operation record data is used to describe a behavior of performing a preset operation on the first file based on a specified encryption lock, and the operation record data comprises second data generated by processing the serial number of a specified encryption lock based on the device private key of the specified encryption lock; generating a bidding document, the bidding document comprises: a first file, first data, and certificate chain identification information for indicating a certificate chain. The above scheme can be used to record the operation history and verification data of the bidding document in the final bidding document, thereby providing a basis for solving the loopholes in the existing electronic bidding process.

Description

Technical Field

[0001] The present application relates to the technical field of tender document processing, and in particular to a method for generating a tender document and a method for verifying a tender document. In addition, the present application also relates to an electronic device and a computer-readable storage medium. Background Art

[0002] Electronic bidding, also known as e-tendering, mainly refers to the bidding activities that are completed in whole or in part by electronic means using data messages as the main carrier in accordance with the relevant national laws and regulations.

[0003] In order to prevent a bidding company from providing or producing multiple bidding documents and to prevent bidding rigging and collusion, many electronic bidding activities currently require the use of encryption locks and solutions to implement real-name registration of electronic bidding documents. In other words, the encryption lock is associated with the real identity of the bidder.

[0004] Electronic bidding usually needs to be implemented through an electronic bidding transaction system. When bidding, the transaction system associates the serial number of the encryption lock used by the bidder with the electronic bidding document in a single relationship, or uses an electronic signature to identify the legal identity of the bidder. However, the use of a single association between the encryption lock serial number and the electronic bidding document makes it difficult to identify the collusion and bidding rigging of some bidders. Summary of the invention

[0005] One of the purposes of the present application is to provide a method for generating a bidding document and a method for verifying a bidding document. The method provided in the embodiments of the present application can record the operation history and data required for verification in the bidding document production process based on the device key of the encryption lock, thereby facilitating the identification of possible violations such as bid collusion and bid rigging when verifying the bidding document.

[0006] A first aspect of the present application provides a method for generating a bidding document, which is applied to a first terminal, wherein the first terminal is communicatively connected to a first encryption lock, and the method comprises:

[0007] Based on the device private key in the first encryption lock, the first file and the serial number of the first encryption lock are processed to obtain first data; wherein the first file includes at least one operation record data, each of which is used to describe an action of performing a preset operation on the first file based on the specified encryption lock, and the operation record data includes second data generated by processing the serial number of the specified encryption lock based on the device private key of the specified encryption lock;

[0008] Generate a bidding document, the bidding document comprising: the first file, the first data and certificate chain identification information for indicating a certificate chain; wherein the certificate chain is used to verify the first data and the second data.

[0009] In combination with the first aspect, in a possible implementation manner, the operation record data further includes a corresponding sequence identifier, and the sequence identifier is used to uniquely identify the sequence of a preset operation performed on the first file.

[0010] In combination with the first aspect, in a possible implementation manner, the operation record data further includes a corresponding terminal identifier, where the terminal identifier is used to uniquely identify a terminal device based on which a preset operation is performed on the first file.

[0011] In combination with the first aspect, in a possible implementation, a first operation count is recorded in the first encryption lock, and the first operation count is used to describe the number of preset operations performed on the first file based on the first encryption lock; at least one operation record data in the bidding document is also used to indicate a second operation count.

[0012] A second aspect of the present application provides a bidding document verification method, which is applied to a server and includes:

[0013] Obtain a bidding document, the bidding document comprising: a first file, first data, and certificate chain identification information for indicating a certificate chain; wherein the first file comprises at least one operation record data, each of which is used to describe an action of performing a preset operation on the first file based on a specified encryption lock, and the operation record data comprises second data generated by processing a serial number of the specified encryption lock based on a device private key of the specified encryption lock;

[0014] In the case where the first data is verified successfully based on the certificate chain, determining a serial number of a designated encryption lock used to form the second data;

[0015] The bidding document is verified based on the serial number of the designated encryption lock and the serial number of the encryption lock pre-bound by the bidder of the bidding document.

[0016] In conjunction with the second aspect, in a possible implementation manner, the method further includes:

[0017] In a case where the second data and the first data are verified based on the certificate chain, determining a sequence identifier respectively included in the at least one operation record;

[0018] Based on the sequence identifier, the bid document is verified.

[0019] In conjunction with the second aspect, in a possible implementation manner, the method further includes:

[0020] Determine a terminal identifier based on which the second data is formed, where the terminal identifier is used to uniquely identify a terminal device based on which a preset operation is performed on the first file;

[0021] The bid document is verified based on the terminal identification and terminal identifications determined from other bid documents.

[0022] In conjunction with the second aspect, in a possible implementation manner, the method further includes:

[0023] In a case where the first data is verified successfully based on the certificate chain, determining a first operation number, where the first operation number is used to describe the number of times a preset operation is performed on the first file based on the first encryption lock;

[0024] Determine a second operation number based on the at least one operation record data, where the second operation number is used to indicate the number of times a preset operation is performed on the first file based on the specified encryption lock;

[0025] The bid document is verified based on the first operation number and the second operation number.

[0026] A third aspect of the present application provides an electronic device, including:

[0027] a memory configured to store predetermined computer instructions;

[0028] The processor is configured to execute the predetermined computer instructions to implement all or part of the steps of any method of the first aspect or the second aspect.

[0029] A fourth aspect of the present application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the processor executes any one of the methods of the first aspect or the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 A schematic diagram of the system architecture of an exemplary application scenario of the method of an embodiment of the present application.

[0031] Figure 2 The following is a flowchart of an exemplary method for generating a bidding document of the present application.

[0032] Figure 3 The present invention is a flowchart of another exemplary method for generating a bidding document of the present application.

[0033] Figure 4 The figure is a flowchart of an exemplary bidding document verification method of the present application.

[0034] Figure 5 A schematic diagram of the structure of an exemplary electronic device of the present application. DETAILED DESCRIPTION

[0035] In order to clearly and completely describe the technical solution of the present application, further explanation will be given below in combination with the embodiments and drawings. To facilitate understanding of the present solution, the following will first briefly introduce the bidding-related terms involved in the present solution, then introduce an exemplary system architecture, and then respectively illustrate the binding process between the encryption lock and the bidder, the generation process of the bidding document, and the verification process.

[0036] Bid collusion mainly refers to the act of collusion between bidders or between bidders and the tenderer (or intermediary agency) to defraud the bid.

[0037] Bid rigging, also known as collusion in bidding, mainly refers to the means and behaviors of several bidders agreeing with each other to raise or lower their bid prices in order to restrict competition, exclude other bidders, and make a certain stakeholder win the bid, thereby seeking benefits.

[0038] Bid cancellation mainly refers to the situation where there are less than three suppliers who have registered to participate or substantively responded in the bidding activity, there are illegal and irregular behaviors that affect the fairness of procurement, all bids made by the tenderer are invalidated due to major changes, etc.

[0039] Generally speaking, the preparation of bidding documents often requires a lot of previous work results. For example, in the construction industry, the bidding documents of a project need to rely on the corresponding engineering documents, such as the pricing documents generated by professional pricing software. The pricing documents contain huge data tables with a large amount of data, and the resources required to calculate these data are also relatively large. If there are multiple bidders who want to collude or collude, in order to save costs, the bidding documents of these multiple bidders are often made by copying the same basic bidding documents or pricing documents, etc., and then slightly modifying them, or even using the same computer. For example, some bidders may only transfer the qualifications to participate in the bidding, and their bidding documents are all made by a company that leads the bid collusion. In this case, the aforementioned problems are likely to occur. Finally, each bidder or a bidder uses the encryption lock associated with the real identity of each bidder to make the final bidding document to participate in the bidding activities.

[0040] The electronic bidding transaction system can obtain the bidder's pre-registered bidder identity information and the associated encryption lock serial number. When a bidder participates in bidding through the transaction system based on the aforementioned bidding documents and encryption lock, the transaction system can obtain the serial number of the encryption lock used by the bidder when bidding. Then the serial number is compared with the encryption lock serial number pre-registered by the bidder. If they are consistent, it can be considered that the verification has passed.

[0041] From the above process, it can be seen that the single use of the encryption lock serial number and the bidding document to associate (hereinafter also referred to as the single association method) cannot identify problems that arise in the bidding document production process, making it difficult to identify collusion, bidding rigging, etc., or lead to problems such as bid cancellation and bidding document tampering, which in turn creates loopholes in the bidding process.

[0042] For example, suppose that a encryption lock is used in the early stage to prepare and edit multiple bidding documents at the same time, and each bidder's own encryption lock is only used when generating the final bidding document or participating in the bidding through the trading system. It is difficult for the trading system or the tenderer to identify such behavior.

[0043] For example, in some cases, some malicious bidders will use pirated encryption locks to generate the final bidding documents or participate in bidding. The serial number of the pirated encryption lock may imitate the serial number of the genuine encryption lock, that is, the same as the serial number of the genuine encryption lock of a compliant bidder. This will cause the encryption lock serial number associated with multiple files in the bidding documents to appear multiple times. In this case, during the bid opening verification, since it is impossible to clearly distinguish which bidder is a compliant bidder and which is a malicious bidder, or it is impossible to determine whether there are other non-compliant behaviors between these bidders, the transaction system or the tenderer may make a unified decision to invalidate, which leads to the situation of invalidating the bid. It can be seen that in the face of such a situation, a single association method is difficult to protect the legitimate rights and interests of compliant bidders. In recent years, in the field of engineering bidding, incidents of being identified as bid rigging and collusion due to the consistency of encryption lock serial numbers have been frequently disclosed, and the companies involved have been severely punished by the relevant supervision and management departments, which also reflects the urgent need for compliant bidders for other identification methods.

[0044] For example, if key business data or technical data in a bidding document is tampered with, it is difficult to identify whether the bidding document has been tampered with because the single association method can only provide a simple verification based on the encryption lock serial number.

[0045] The embodiment of the present application provides a bidding document generation method and a bidding document verification method. When generating a bidding document, the operation history and verification data of the bidding document are recorded in the final bidding document based on the device key of the encryption lock. In this way, when verifying the bidding document, possible problems can be identified based on the operation history and verification data of the bidding document, thereby providing a basis for solving loopholes in the existing electronic bidding process.

[0046] See also Figure 1 , Figure 1 The system architecture diagram of an exemplary application scenario of the method of the embodiment of the present application is shown in FIG. The system includes a server, a terminal device and a dongle.

[0047] The server in the embodiment of the present application can be used to implement some businesses or services related to bidding transactions that need to be implemented on the server. For example, the server can be used as a server of a bidding transaction platform.

[0048] It should be understood that the server in the embodiments of the present application can be an independent physical server, a server cluster composed of multiple physical servers, a cloud server or a cloud computing service center, or a combination of a physical server and a cloud server, etc. The present application does not limit the specific product form of the server.

[0049] The server may also include a transaction platform database, or a communication connection to the transaction platform database, so as to store data uploaded by users, such as the identity information of bidders, encryption lock serial numbers, bidding documents, etc., in the transaction platform database.

[0050] The terminal devices in the embodiments of the present application may include, but are not limited to, mobile phones, tablet computers, personal computers (PCs), wearable devices, Internet of Things devices, Internet of Vehicles devices, augmented reality (AR) / virtual reality (VR) devices, personal digital assistants (PDAs), and the like. The present application does not limit the specific product form / type of the electronic device.

[0051] For the sake of distinction, the terminal device used by a bidder is referred to as the first terminal in the embodiment of the present application. It should be understood that in actual application scenarios, the first terminal may include one or more terminals. This is because multiple users may be involved in the process of preparing bidding documents, such as multiple employees in an enterprise / organization. These multiple users can use the same terminal to complete the work they are responsible for, or they can use multiple terminals to complete it, and this application does not limit this.

[0052] The first terminal is connected to the server in communication. The user of the first terminal can access the bidding transaction platform on the first terminal to participate in the bidding activities. The user of the first terminal can also generate the final bidding document on the first terminal.

[0053] Specific software may be installed on the first terminal. In many industries, some data required for preparing bidding documents may require the use of some professional software. For example, engineering cost software, pricing software, and quantity calculation software in the construction industry. These software can output specific files, such as cost engineering files, pricing engineering files, etc. These files contain the data required for making bidding documents. It should be understood that these specific software can be configured to require the permission of the software developer under certain conditions to be used legally. The files output by these software can be private format files with their own unique extensions. In some application scenarios, generating bidding documents may also require the use of a specific software, such as software specified by the tenderer. It is understandable that the function of generating bidding documents and the function of preparing certain required data can be integrated in one software or implemented by multiple software. In other application scenarios, generating bidding documents may be implemented through a bidding transaction platform.

[0054] It should be understood that other possible device terminals may also be included in this exemplary system architecture. For example, other bidders may also use their own terminal devices (such as a second terminal, a third terminal, etc.) to exchange data with the server through the bidding transaction platform.

[0055] The encryption lock in the embodiment of the present application is an information security device. In a broad sense, encryption locks can include hardware encryption locks, cloud locks, soft locks, etc. The hardware encryption lock can be physically connected to the terminal device through USB, parallel port, etc. to transmit data. For example, the terminal device or specific software installed on the terminal device can access the hardware encryption lock through the USB port, such as Figure 1 As shown. A soft lock mainly refers to an encrypted container stored on a terminal device such as a computer. The terminal device or some software on the terminal device can access the local encrypted container through a driver. A cloud lock mainly refers to an encryption lock cloud service running on a server, and can also be understood as an encryption lock entity running on the server. A terminal device or some software on a terminal device can access the cloud lock through a network such as the Internet or a local area network. The specific product form of the encryption lock is not limited in the embodiments of the present application.

[0056] Each dongle can store a dongle serial number (SN) to identify a dongle within a certain range. It is understandable that regular dongle manufacturers usually assign dongle serial numbers to dongles, and the serial numbers are usually unique within a certain range to verify the legal identity of the product. For other dongles, such as pirated dongles, the serial numbers may not be unique, for example, they may be the same as the serial number of a genuine dongle, so as to impersonate the genuine dongle.

[0057] The encryption lock can also store device keys. The device key can be used to generate bidding documents, and its use will be described in more detail later. In some implementations, the device key is associated with the bidder. Different bidders have different device keys to indicate the identity of the bidder. When the device key adopts an asymmetric key, the device key includes a device private key and a corresponding device public key, and the device private key can be stored in the encryption lock. For ease of understanding, the embodiment of the present application will take the form of an asymmetric key as an example to illustrate the scheme of the embodiment of the present application.

[0058] It should be understood that a bidder may have one or more different device keys, or may have multiple encryption locks. These multiple encryption locks may be assigned to different users for use. The device keys stored in different encryption locks may be the same or different. Exemplarily, for the same bidding project, the same device key may be stored in one or more encryption locks owned by the project team; for different bidding projects, different device keys may be stored in encryption locks owned by different project teams.

[0059] In some implementations, the device keys stored in the dongle, especially the device private key, can be generated inside the dongle and can be set to not be exported outside the dongle, thereby enhancing the security of the device keys. In other words, the keys stored in the dongle can only be used under the conditions that they meet, and cannot be exported or read.

[0060] In the scheme of the embodiment of the present application, when the user needs to perform certain specific operations on the bidding document, such as opening, editing, and storing the bidding document, an encryption lock is required, such as the encryption lock serial number, device key, etc. in the encryption lock.

[0061] For ease of description, in the embodiment of the present application, the encryption lock that is connected to the first terminal and used to generate the bidding document is referred to as the first encryption lock. The embodiment of the present application takes the processing between the first terminal, the first encryption lock and the server as an example to describe the process of binding, generating bidding documents and verifying bidding documents.

[0062] The bidder must first bind the bidder's identity information and the corresponding encryption lock serial number on the trading platform.

[0063] The bidder in the embodiment of the present application may be, for example, a legal person such as an enterprise / company, an unincorporated organization, a natural person, etc. The identity information of the bidder may include the legal qualification information of the bidder, which may be, for example, the business license and unified credit code of the enterprise / company, the organizational code of the unincorporated organization, the ID number of the natural person, etc.

[0064] The serial number of the encryption lock in the embodiment of the present application can refer to the relevant description in the previous text. Generally, when a bidder purchases a genuine encryption lock, the encryption lock serial number is usually unique within a certain range. When a bidder purchases a genuine encryption lock, the encryption lock manufacturer can generate a device key for the bidder and store the device key in the encryption lock. As mentioned above, the device key is associated with the bidder and can be used to represent the identity of the bidder. When issuing a digital certificate containing a device key, the issuing authority can sign it using its own private key (for example, the private key of the self-built CA of the encryption lock manufacturer). In this way, other entities such as servers can determine the legitimacy of a device key of an encryption lock (for example, a device public key corresponding to a device private key) by verifying the signature.

[0065] The bidder connects the encryption lock to the terminal device used. The terminal device can read the serial number of the encryption lock and submit it and the bidder's identity information to the server of the trading platform. After obtaining the bidder's identity information and the encryption lock serial number, the server of the trading platform can associate and store the two in the trading platform database for subsequent use in verifying the bidding documents.

[0066] The embodiment of the present application provides a method for generating a bidding document, which can be executed by a first terminal, or by the first terminal and a first encryption lock. For ease of understanding, the steps of the generating method are described below by taking a certain file (the first file) as an example.

[0067] See also Figure 2 and Figure 3 , Figure 2 The following is a flowchart of an exemplary method for generating a bidding document of the present application. Figure 3 This is a flowchart of another exemplary method for generating a bidding document of the present application. The method may include steps S101 to S102.

[0068] S101: The first terminal processes a first file and a serial number of the first encryption lock based on a device private key in the first encryption lock to obtain first data.

[0069] The first file may be a process file in the process of making a bidding document. For example, the first file may be a cost engineering file, a pricing engineering file, etc. The terminal device (which may be the first terminal or other terminals) is installed with software corresponding to the first file, such as engineering cost software, engineering pricing software, etc. The first file can be opened, edited, saved, etc. by the corresponding software. It should be understood that before the final bidding document is generated, the file may be operated multiple times.

[0070] The first file in the embodiment of the present application can be a private format file. The private format file is a file of a specific format that can be developed by a certain developer. In general, the private format file can be set so that only the specific software (i.e., the corresponding software) developed by the software developer can open the private format file. That is, the private format file can be set so that only the software developed by the developer of the specific software associated with the private format file can open it. Of course, it should be understood that in some cases, other software developers may also develop other software that is compatible with opening these private format files. Such a situation is sometimes not completely controlled by the developer of the specific software.

[0071] The preset operation can be used to instruct the first file to be opened, edited, stored, etc. Exemplarily, the user edits in a specific software on the terminal device, and then clicks a button such as "Save" in the specific software, thereby inputting the preset operation to the terminal device to instruct the terminal device to store the edited file.

[0072] In some implementations, when a preset operation is performed on the file, the terminal device may be triggered to process the file using a specified encryption lock, thereby storing information related to the operation history of the file in the file to form operation record data. It should be understood that when the terminal device stores the operation record data, the terminal device needs to be connected to the specified encryption lock. The specified encryption lock here may be the first encryption lock mentioned above, or it may be another encryption lock. It should also be understood that since the file may undergo multiple preset operations, one or more operation record data may be stored in the file. Each operation record data is used to describe the behavior of performing a preset operation on the file based on a specified encryption lock. The specified encryption locks described in different operation record data may be the same or different.

[0073] In some implementations, the operation record data may include second data generated by processing the serial number of the specified encryption lock based on the device private key of the specified encryption lock. Exemplarily, when the terminal device receives an operation instruction that requires performing a storage operation on the first file, it may determine a specified encryption lock connected to it, and then call the specified encryption lock to use the device private key stored in the lock to process the serial number of the specified encryption lock, such as signing or encrypting, and then return the processing result to the terminal device, and the terminal device forms the second data based on the processing result.

[0074] In some implementations, the terminal device may directly use the aforementioned processing result as the second data to form the operation record data. In other implementations, the terminal device may apply blockchain technology to the formation of the operation record data, or the terminal device may generate a corresponding sequence identifier for the processing result to uniquely identify the order of this operation, so that the order of multiple operation record data contained in the first text that has undergone multiple operations is clear, and an operation behavior chain can be formed.

[0075] Exemplarily, the terminal device can obtain the timestamp of this operation as a sequence identifier. The terminal device then forms the second data based on the timestamp and the aforementioned processing result, for example, by concatenating the two to form a string, thereby ensuring that the second data formed each time is not repeated. The timestamp can be used to indicate the time of this operation on the first file. It should be understood that the timestamp here can be generated by the encryption lock and transmitted to the terminal device, or it can be generated by the terminal device itself, and this application does not limit this.

[0076] As another example, the terminal device may also generate a sequence number according to a preset rule as a sequence identifier. The sequence identifiers in the operation record data may be used to verify the bidding document later, for example, to determine whether there are abnormal operations in the bidding document, or whether there are missing operation record data in the operation behavior chain.

[0077] In some implementations, the operation record data may include a corresponding terminal identifier, which is used to uniquely identify the terminal device on which a preset operation is performed on the first file. Exemplarily, the terminal device can obtain the MAC address of the terminal device on which this operation is based, etc., as the terminal identifier. The terminal device then forms the second data based on the MAC address and the aforementioned processing result, for example, by concatenating the two to form a string. Of course, the terminal device can also form the second data based on the MAC address, the aforementioned sequence identifier and the aforementioned processing result, for example, by concatenating the three to form a string. The terminal identifiers in these operation record data can be used to verify the bidding documents later, for example, to determine whether a bidding document is operated by multiple terminal devices, whether multiple bidding documents are operated by one terminal device, etc.

[0078] It should be understood that, in addition to the aforementioned second data, sequence identifier and / or terminal identifier, the operation record data may also include other possible information, which is not limited in the present application.

[0079] It should also be understood that for pirated encryption locks, since they do not have legal device keys, operation record data may not be generated based on the pirated encryption locks, or even if operation record data similar to those of genuine encryption locks can be generated, the second data in these operation record data will not pass the verification during the stage of verifying the bidding documents.

[0080] The device private key in the first encryption lock is used to prove the legal identity of the first encryption lock. The device private key or device key can refer to the above-mentioned related description, which will not be repeated here. It should be understood that for a genuine encryption lock, it has a verifiable device key, while for a pirated encryption lock, it does not have a verifiable device key. Conventional pirated encryption locks can only imitate the serial number of the encryption lock, but cannot obtain the legal device key.

[0081] Based on the device private key in the first encryption lock, the first file and the serial number of the first encryption lock are processed to obtain the first data, and the first data is carried in the finally generated bidding document, so that the server can verify whether the content of the bidding document has been tampered with. This step can be implemented in a variety of different ways, and some of the implementation ways are described as examples below.

[0082] In some implementations, the first encryption lock can use the device private key to process part or all of the content in the first file. For ease of description, these data are referred to as third data in the embodiments of the present application.

[0083] In some implementations, the first terminal may regard the entire first file as the third data and process it using the first encryption lock to obtain a processing result. In some cases, the data volume of the first file or the content to be processed therein may be large. Therefore, in some other implementations, the first terminal may regard the content to be processed as a data stream and process it using the first encryption lock in batches, then the data stream or the part of the data stream processed each time may be regarded as the third data.

[0084] In other implementations, the first terminal may extract some key data (such as bid price, construction area, unit cost, etc.) from the first file as the third data. Then, the first terminal processes the third data using the first encryption lock to obtain a processing result.

[0085] In some other implementations, the first terminal may use the key data in the first file and the serial number of the currently connected encryption lock (ie, the first encryption lock) as the third data.

[0086] In some other implementations, the first terminal may transform the key data in the first file and the serial number of the first encryption lock together, for example, by performing a hash operation, and regard the hash operation result as the third data. Exemplarily, the first terminal may use an algorithm such as sha256 to operate on the key data and the serial number of the first encryption lock, generate a 64-bit operation result, and transmit it to the first encryption lock as the third data. Of course, the transformation process may also be performed by the first encryption lock. Compared with the method in which the first encryption lock performs the processing, the method in which the first terminal performs the transformation process can reduce the requirements on the computing power of the first encryption lock.

[0087] In some implementations, the first encryption lock may process the third data using the device private key, such as encrypting or signing, and return the processing result, such as the encryption result or the signature result, to the first terminal. The first terminal forms the first data based on the aforementioned processing result. Exemplarily, the first terminal may directly use the aforementioned processing result as the first data. In another exemplary embodiment, the first terminal may also concatenate the aforementioned processing result and the serial number of the first encryption lock to obtain the first data.

[0088] It should be understood that if the third data does not include the serial number of the first encryption lock, the first data can be formed based on the processing result and the serial number of the first encryption lock; if the third data includes the serial number of the first encryption lock, the first data can be formed based on at least the processing result. In this way, the final generated bidding document will include the serial number information of the first encryption lock.

[0089] S102: The first terminal generates a bidding document, which includes: a first file, first data, and certificate chain identification information.

[0090] The certificate chain identification information is used to indicate a certificate chain, and the certificate chain can be used to verify the first data and the second data in the bidding document.

[0091] The certificate chain may include key information of the device key used to verify the bid document. For ease of explanation, a pair of device keys (device private key and device public key) will be used as an example in the following description. It should be understood that the certificate chain may include information about the device public key corresponding to the device private key (for ease of distinction, hereinafter referred to as the first public key information). The first public key information may be the device public key itself, or it may be information used to indicate the device public key. This application does not limit its specific form, as long as the server responsible for verifying the bid document can obtain the corresponding device public key based on the first public key information when it needs to use the device public key.

[0092] In some implementations, the aforementioned device key may be issued by a CA (e.g., a self-built CA of a dongle manufacturer), and the device public key certificate (hereinafter referred to as the first public key certificate for the sake of distinction) containing the device public key may be signed by the private key of the CA. Therefore, the certificate chain may also include the public key information of the CA (hereinafter referred to as the second public key information for the sake of distinction). That is, in this case, the certificate chain includes the first public key information and the corresponding second public key information.

[0093] In some implementations, when the above-mentioned CA also has an upper-level CA, the public key certificate containing the public key of the CA (hereinafter referred to as the second public key certificate for the sake of distinction) may be signed by the private key of the upper-level CA. Therefore, the certificate chain may also include the public key information of its upper-level CA (hereinafter referred to as the third public key information for the sake of distinction). By analogy, the certificate chain may also include the public key information of the upper-level CA (i.e., the fourth public key information), the public key information of the upper-level CA (i.e., the fifth public key information), and so on, until the public key information of the root CA. The public key indicated by the upper-level public key information can be used to verify the signature of the lower-level public key certificate. Through level-by-level verification, the legitimacy of the device public key can be guaranteed, thereby ensuring the reliability of the verification results of the bidding documents.

[0094] In some implementations, the first encryption lock can send identification information of the certificate chain used to verify the bid document to the first terminal, so that the first terminal can store it in the finally generated bid document, and can be used to verify the first data and second data stored therein when needed later (for example, when verifying the bid document).

[0095] The aforementioned certificate chain can come from the first encryption lock or from other possible devices, as long as the server responsible for verification can obtain the certificate chain according to the identification information of the certificate chain when needed. Exemplarily, the trading platform can also provide an encryption lock certificate chain upload function. When the bidder binds his own encryption lock serial number with his identity information, the terminal device can read the corresponding certificate chain from the encryption lock to be bound and upload it to the server of the trading platform. In this way, when verifying the bidding documents, the server can search for a matching certificate chain from the uploaded certificate chain according to the certificate chain identification information in the bidding documents, and use the certificate chain to verify the first data and the second data.

[0096] It should be understood that, in general, bidders will use a bound genuine encryption lock when generating the final bidding document. Therefore, when the server verifies the bidding document, it can often find a certificate chain that matches the certificate chain identification information in the bidding document. In this case, the first data can often pass the verification based on the certificate chain. However, if the bidder uses a pirated encryption lock in the process of making the bidding document, or uses other genuine encryption locks, it is possible that the second data contained in at least a portion of the operation record data is difficult to pass the verification based on the certificate chain.

[0097] In other cases, if the bidder uses a pirated dongle (whose dongle serial number may be the same as that of a genuine dongle to impersonate the genuine dongle) to bind and generate the final bid document, the bid document will also be difficult to pass the verification of the server. This is mainly because the pirated dongle does not have the legal device key that the genuine dongle has, so it is difficult to generate the first data and the second data, or even if similar first data and second data are generated, these data are actually difficult to pass the verification based on the certificate chain.

[0098] It should also be understood that the bidding documents may also include other possible data, which is not limited in this application.

[0099] In some implementations, the encryption lock may record the number of operations, where the number of operations is used to describe the number of times a preset operation is performed on the first file based on the encryption lock.

[0100] For a bidding project of a bidder, the bidder usually uses the same encryption lock (e.g., the first encryption lock that has been bound) in the process of preparing the bidding document. Each time a preset operation is performed on the bidding document, the terminal device needs to use the encryption lock to store the operation record data in the file. Accordingly, the terminal device can also record the number of times the encryption lock is used in the encryption lock. Exemplarily, the terminal device can call the encryption lock behavior recording interface and record the number of operations through the code in the lock.

[0101] It should be understood that the encryption lock can record the number of operations corresponding to different files for different bidding files. In the embodiment of the present application, taking the first file as an example, the number of operations on the file based on the first encryption lock is referred to as the first number of operations. Each time a preset operation is performed on the file, the count value of the corresponding number of operations is updated in the first encryption lock. The first number of operations can be used to verify the bidding document in the future, for example, to determine whether the number of operations indicated by at least one operation record data in the bidding document (for ease of distinction, it is referred to as the second number of operations in the embodiment of the present application) matches the number of operations recorded in the first encryption lock.

[0102] In some implementations, each piece of operation record data may be stored as a string of fixed length. The second number of operations may be determined by dividing the data length of all operation record data by the fixed length of each piece of operation record data. In other implementations, the second number of operations may be determined by the number of sequence identifiers in the operation record data. In addition, other possible methods may be used to determine the second number of operations.

[0103] The embodiment of the present application provides a method for verifying a bid document, which can be performed by a server of a trading platform, or other electronic devices connected to the server. In the embodiment of the present application, it is collectively referred to as a server. For ease of understanding, the following takes the aforementioned bid document as an example to describe the steps of the method for verifying the bid document by the server.

[0104] See also Figure 4 , Figure 4 The flowchart of an exemplary bidding document verification method of the present application is shown in FIG.

[0105] S201: The server obtains a bidding document, which includes: a first file, first data, and certificate chain identification information for indicating a certificate chain.

[0106] Among them, the first file includes at least one operation record data, each operation record data is used to describe the behavior of performing a preset operation on the first file based on the specified encryption lock, and the operation record data includes second data generated by processing the serial number of the specified encryption lock based on the device private key of the specified encryption lock.

[0107] The above-mentioned first file, operation record data, designated encryption lock, second data, first data, certificate chain identification information and certificate chain can refer to the relevant description in the previous text and will not be repeated here.

[0108] S202: The server verifies the first data in the bidding document based on the certificate chain.

[0109] The server can search for a matching certificate chain in the certificate chain of the encryption lock corresponding to the bound bidder based on the certificate chain identification information.

[0110] It should be understood that for the bidding documents generated by compliant bidders, the server should be able to find a matching certificate chain. However, if the encryption lock based on which the final bidding document is generated is a pirated encryption lock, it is possible that a matching certificate chain cannot be found, or, although a matching certificate chain can be found, the first data cannot pass the verification based on the certificate chain. In some implementations, if the server cannot find a matching certificate chain, it is determined that the bidding document verification has failed.

[0111] In some implementations, the server may decrypt or verify the first data using the device public key indicated by the certificate chain. Exemplarily, when the first encryption lock uses the device private key to sign the third data, the first data includes the signature result, and accordingly, the server may verify the signature result. Exemplarily, when verifying the signature, the server may determine the fourth data based on the first file (which may be consistent with the way the first terminal determines the third data). The server then calculates the hash value of the fourth data, and uses the corresponding device public key to decrypt the aforementioned signature result to obtain the fifth data. The fifth data is compared with the hash value of the fourth data to determine whether the two match. If they do not match, it can be considered that the first data cannot pass the verification based on the certificate chain.

[0112] In some implementations, the device public key comes from the device public key certificate (i.e., the aforementioned first public key certificate). In addition to determining whether the hash value of the fourth data matches the fifth data based on the device public key, the second public key contained in the public key certificate of the upper-level CA (i.e., the aforementioned second public key certificate) can also be used to verify the signature of the first public key certificate. On the basis that the signature of the first public key certificate is verified, the third public key contained in the public key certificate of the upper-level CA (i.e., the third public key certificate) can also be used to verify the signature of the second public key certificate. And so on, one level at a time, until the self-signature of the root certificate is verified using the public key certificate of the root CA. If all verifications are passed, it can be considered that the first data can pass the verification based on the certificate chain. If any level of verification fails, it can be considered that the first data cannot pass the verification. The information of the public key used for each level of verification can be indicated by the certificate chain.

[0113] In some implementations, the server can verify the legitimacy of the device public key based on the certificate chain. The verification method is similar to the aforementioned level-by-level verification and is not repeated here. After verifying that the device public key is legitimate, the server uses the device public key and the third data to verify the first data. The verification method can be similar to the aforementioned implementation.

[0114] By adopting the above method, it is possible to verify whether the content of the bidding document, especially the third data (such as key data) in the first file, has been tampered with, thereby solving the problem that the bidding document has been tampered with but is difficult to identify. In addition, when generating the bidding document, the first terminal can use the key data in the first file and the serial number of the first encryption lock as the third data, and when verifying the bidding document, it is determined that the third data has not been tampered with. In this case, the bidding document is verified based on the serial number of the first encryption lock, so that the verification strength of the bidding document is higher and it is more helpful to identify possible problems in the bidding process.

[0115] It is understandable that, when the first data can pass the verification, the device public key indicated by the certificate chain and the device private key in the first encryption lock must correspond, and the first encryption lock can be considered as the encryption lock pre-bound by the bidder.

[0116] In some implementations, when the first data passes verification, the serial number of the first encryption lock used to form the first data is determined. In some cases, the server can directly extract the serial number of the first encryption lock from the verified first data; in other implementations, the server may not be able to directly extract the serial number of the first encryption lock from the verified first data, but can only extract its hash value or the hash value calculated by splicing it with key information, etc. It is understandable that since the serial number of the bound encryption lock is stored on the server, the server can also obtain the key information of the first file, etc., and thus the serial number of the first encryption lock can also be indirectly determined based on this information.

[0117] S203: When the second data is verified successfully based on the certificate chain, the server determines the serial number of the designated encryption lock used to form the second data.

[0118] In some cases, the server can directly extract the serial number of the specified encryption lock from the operation record data; in other implementations, the server may not be able to directly extract the serial number of the specified encryption lock from the operation record data, but can only extract its hash value or the hash value calculated by splicing it with other information, etc. It is understandable that since the serial number of the bound encryption lock is stored on the server, the server can also obtain other information in the operation record data in some cases, and thus can indirectly determine the serial number of the specified encryption lock based on this information, and then use the two to verify the bidding documents.

[0119] In some implementations, the server may use the device public key of the first encryption lock to decrypt the second data in at least one operation record data to obtain a decryption result. If the second data in a certain operation record data is generated based on an encryption lock other than the first encryption lock, the second data may not be successfully decrypted using the device public key of the first encryption lock, or even if the decryption result can be obtained, the serial number of the specified encryption lock extracted therefrom (which is considered to be the serial number of the specified encryption lock during the verification process, but in fact its value may be different from the serial number of the specified encryption lock actually used when forming the operation record data) is inconsistent with the pre-bound encryption lock serial number.

[0120] S204: The server verifies the bidding document based on the serial number of the designated encryption lock and the serial number of the encryption lock pre-bound by the bidder of the bidding document.

[0121] In some implementations, if the serial number of the designated dongle extracted in the aforementioned step is the same as the pre-bound dongle serial number, the server may deem that the bid document has failed verification.

[0122] In other implementations, as mentioned above, the server may not be able to directly extract the serial number of the specified encryption lock from the operation record data, but can only extract its hash value or the hash value calculated by splicing it with other information, etc. In this case, the server may not directly compare the two serial numbers, but verify the bid document by comparing the values ​​of the two serial numbers after the operation. Exemplarily, the server can extract the hash value of the serial number of the specified encryption lock from the operation record data, and the server performs a hash operation on the pre-bound encryption lock serial number to obtain the operation value. Then the server determines whether there are operation records of other encryption locks other than the bound encryption lock in the operation record data by comparing whether the two are consistent, and then determines whether the bid document passes the verification.

[0123] When at least one piece of operation record data also includes other information, the server may also perform other possible verifications using the other information included therein.

[0124] In some implementations, when the operation record data also includes a corresponding sequence identifier, the server can verify the bid document according to the sequence identifier. Exemplarily, in the entire operation behavior chain, each operation record data can be different, and the sequence is clear. Based on the sequence identifier, it can be determined whether there is an abnormal operation in the bid document, or whether there is a missing operation record data in the operation behavior chain. This also increases the difficulty of tampering with the operation record data in the bid document to a certain extent.

[0125] For example, regarding the aforementioned bid-rigging problem, suppose that in the early stage, one encryption lock (encryption lock A) is used to simultaneously prepare and edit multiple bid documents, and in the later stage, each bidder's own encryption lock (encryption lock B, etc.) is used to edit and generate the final bid document. It stands to reason that the bid document obtained in this way may include operation record data formed based on multiple encryption locks. Generally, this situation can be identified when verifying the second data based on the certificate chain. However, if the operation record data generated based on encryption lock A in the first file is manually deleted, the bid document generated in this way can still pass the verification of the server of the trading platform, resulting in the problem of bid-rigging that cannot be identified by the trading platform. If the server also needs to verify the bid document based on the sequence identifier, the server can identify that there is a missing operation behavior chain, thereby identifying the above-mentioned bid-rigging problem.

[0126] In some implementations, when the operation record data includes a corresponding terminal identifier, the server can verify the bidding document based on the terminal identifier, thereby identifying the situation where multiple bidding documents are prepared on one terminal device, and further preventing problems such as bid rigging and collusion.

[0127] Optionally, the method executed by the server further includes:

[0128] Determine a terminal identifier based on which the second data is formed, the terminal identifier being used to uniquely identify a terminal device based on which a preset operation is performed on the first file; or determine a terminal identifier based on which the first data is formed, the terminal identifier being used to uniquely identify a terminal device based on which a bidding document is generated;

[0129] The bid document is verified based on the terminal identification and terminal identifications determined from other bid documents.

[0130] Taking the case where the terminal identifier is a MAC address as an example, assuming that the bidding documents of multiple bidders are generated based on their respective encryption locks, and the first data and the second data therein can also pass the verification based on the certificate chain smoothly, but if the MAC addresses used to form the first data or the second data in their respective bidding documents are the same, then the multiple bidders are likely to be involved in bid collusion. That is, the above implementation method can better identify possible bid collusion and other problems.

[0131] In some implementations, the number of operations may be recorded in the dongle, and the server may determine whether the number of operations recorded in the dongle (generally the first dongle) based on which the current bidding activity is based matches the number of operations indicated by the operation record data of the bidding document.

[0132] Optionally, when the first data is verified based on the certificate chain, a first operation number is determined, where the first operation number is used to describe the number of times a preset operation is performed on the first file based on the first encryption lock;

[0133] Determine a second operation number based on the at least one operation record data, where the second operation number is used to indicate the number of times a preset operation is performed on the first file based on the specified encryption lock;

[0134] The bid document is verified based on the first operation number and the second operation number.

[0135] For compliant bidders, they always use the bound encryption lock to operate the first file or generate the bidding document, so the number of operations recorded in the bound encryption lock should match the number of operations recorded in the first file. If there is an inconsistency or a large difference between the two, there may be problems in the preparation process of the bidding document.

[0136] Exemplarily, if the second operation number is greater than or much greater than the first operation number, it means that the bidding document has also performed preset operations based on other encryption locks. Exemplarily again, if the second operation number is less than or much less than the first operation number, it means that the operation record data in the bidding document may be partially deleted.

[0137] It should be understood that in the embodiment of the present application, whether the two operation times match can be determined according to the set rules, and it is not necessary for the two to be equal to be determined as a match. In some cases, the two can also be determined as a match if they are not equal. Different judgment rules can be set in different application scenarios.

[0138] The solution of the present application is described below through two exemplary implementations.

[0139] Example 1

[0140] 1) Preparation of bidding documents

[0141] Step 1: Sign the encryption lock SN of the current operation file using the device private key in the encryption lock to generate signature data D1.

[0142] Step 2: The signature data D1 + current timestamp are concatenated into a string D2 and stored in the file.

[0143] Each time a bidding document is edited, such as opening, modifying, saving, etc., steps 1 and 2 are repeated, and the generated data is stored in the file in sequence, forming a complete operation behavior chain.

[0144] Step 3: After the bidding document is edited, save the document. Obtain N key data of the current document (bid price, construction area, unit cost, etc.) to generate data D3.

[0145] Step 4: Use the sha256 algorithm to generate a 64-bit result data D4 using the data D3 and the current encryption lock SN.

[0146] Step 5: Sign D4 with the device private key in the encryption lock to generate signed data D5.

[0147] Step 6: Store the data D5 + timestamp + public key P1 used to verify the signature data in the final bidding document.

[0148] 2) Verification of bidding and tendering trading platform

[0149] Step 1: The platform uses the encryption lock device certificate chain verification provided by the bidding enterprise to verify the legitimacy of the device public key (P1) used for verification contained in the bidding document to ensure that the P1 public key in the file is legal and trusted.

[0150] Step 2: The verified public key P1 will verify (decrypt) the signed data in the bidding document.

[0151] Step 3: Use the public key P1 to verify (decrypt) the data D5 in the file and obtain the hash value of the key data D3.

[0152] Step 4: Calculate the hash of the key value in the original data of the bidding document, and compare the value with the data D3 value obtained in step 3 to ensure that the data is consistent and has not been tampered with.

[0153] Step 5: Use P1 to verify (decrypt) D2 in the file and obtain the SN number of the encryption lock used to make the bidding document.

[0154] Step 6: Verify the obtained encryption lock SN number and the bidding enterprise registration information stored in the transaction platform database (including the bound encryption lock SN number).

[0155] Example 2

[0156] 1) Preparation of bidding documents

[0157] Step 1: Sign the encryption lock SN of the current operation file using the device private key in the encryption lock to generate signature data D1.

[0158] Step 2: Concatenate the signature data D1 + current timestamp + computer MAC address into a string D2 and store it in the file.

[0159] Adding a timestamp can ensure that each data generation is unique. Adding a computer MAC address can prevent multiple bidding documents from being produced on one computer.

[0160] Each time the bidding document is edited, steps 1 and 2 are repeated, and the generated data is stored in the file in sequence, forming a complete operation behavior chain.

[0161] Step 3: Count each operation (file opening and saving) of the bidding document, and record the operation count through the code in the lock by calling the encryption lock behavior recording interface. Repeat the above operation for each bidding document operation, and accumulate the count in the lock.

[0162] Step 4: After the bidding document is edited and published as the final document for bidding, it is necessary to obtain N key data of the current document (bid price, construction area, unit cost, etc.) to generate data D3.

[0163] Step 5: Use the sha256 algorithm to generate a 64-bit result data D4 using the data D3 and the current encryption lock SN.

[0164] Step 6: Call the encryption lock interface with data D4, count the operation of D4 + bidding documents stored in the encryption lock, sign with the device private key, generate signed data D5 and transmit it from the encryption lock.

[0165] Step 7: Store the data D5 + timestamp + public key P1 used to verify the signature data in the final bidding document.

[0166] 2) Verification of bidding and tendering trading platform

[0167] Step 1: The platform uses the encryption lock device certificate chain verification provided by the bidding enterprise to verify the legitimacy of the public key (P1) contained in the bidding document to ensure that the P1 public key in the document is legal and trusted.

[0168] Step 2: The verified public key P1 will verify (decrypt) the signed data in the bidding document.

[0169] Step 3: Use the public key P1 to verify (decrypt) the data D5 in the file, and obtain the hash value of the key data D3 and the bidding document operation count value recorded in the lock.

[0170] Step 4: Calculate the hash of the key value in the original data of the bidding document, and compare the value with the signature verification data D3 value obtained in step 3 to ensure that the data is consistent and has not been tampered with.

[0171] Step 5: For the operation record data stored in the bidding document, use division to obtain the original value of the number of operations in the bidding document, and compare the original value with the bidding document operation count value recorded in the lock obtained in step 4 to prevent the bidding document operation record from being tampered with.

[0172] The original value of the number of operations in the bidding document is stored as fixed-length data. The number of bidding document operations can be obtained by calculating the data length stored in all operation records and dividing it by the fixed data length.

[0173] Step 6: Use the public key P1 to verify (decrypt) D2 in the file and obtain the SN number of the encryption lock for the tender file and the computer MAC address.

[0174] Step 6: Verify the obtained encryption lock SN number and the bidding company registration information stored in the database, and compare the MAC address with the MAC addresses stored in the bidding documents of other bidding companies to screen whether there are identical MAC addresses in different bidding documents.

[0175] Please combine Figure 5 In an embodiment of the present application, a terminal device is also provided. The electronic device 300 may include:

[0176] Memory 301, configured to store predetermined computer instructions;

[0177] The processor 302 is configured to execute predetermined computer instructions to implement part or all of the steps implemented by the first terminal in any of the aforementioned implementations.

[0178] An encryption lock is also provided in an embodiment of the present application, and the encryption lock may include:

[0179] a memory configured to store predetermined computer instructions;

[0180] The processor is configured to execute predetermined computer instructions to implement part or all of the steps implemented by the encryption lock in any of the aforementioned implementations.

[0181] A server is also provided in an embodiment of the present application, and the server may include:

[0182] a memory configured to store predetermined computer instructions;

[0183] The processor is configured to execute predetermined computer instructions to implement part or all of the steps implemented by the server in any of the aforementioned implementations.

[0184] Those skilled in the art should understand that the embodiments of the present application can be provided as methods, devices, computer-readable storage media or computer program products. Therefore, the present application can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware.

[0185] The present application may also be in the form of a computer program product implemented on one or more computer-readable storage media containing computer-usable program code. That is, a computer-readable storage medium is also provided in an embodiment of the present application, storing a computer program, and when the computer program is executed by a processor, the processor executes part or all of the steps implemented by the first electronic device or the second electronic device in any of the aforementioned implementations. Of course, in some cases, the storage medium may also store computer programs executed by two electronic devices.

[0186] When implemented by software, the functions may be stored in or transmitted as one or more instructions or codes on a computer-readable medium.

[0187] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

[0188] The product embodiments described above are merely illustrative. For example, the division of units is only a logical function division, and there may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed.

[0189] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Those skilled in the art may select some or all of the units according to actual needs to achieve the purpose of the solution of this embodiment.

[0190] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0191] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the part of the technical solution of the present application that contributes to the prior art, or part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (Read-Only Memory, ROM), random access memory (RandomAccess Memory, RAM), disk or optical disk and other media that can store programs.

[0192] It should be understood that in various embodiments of the present application, the execution order of each step should be determined by its function and internal logic, and the size of the sequence number of each step does not mean the order of execution, and does not constitute any limitation on the implementation process of the embodiment. For example, the aforementioned step S102 and step S103 can be performed simultaneously or in any order, and the present application does not limit this, but step S104 needs to be performed after steps S102 and S103.

[0193] It should also be understood that, in order to facilitate the clear description of the technical solutions of the embodiments of the present application, the words "first", "second", etc. are used in the embodiments of the present application to distinguish between the same items or similar items with substantially the same functions and effects, or concepts with certain differences. Those skilled in the art can understand that the words "first", "second", etc. do not limit the quantity and execution order, and the words "first", "second", etc. do not necessarily limit the difference.

[0194] The same or similar parts between the various embodiments in this specification can be referred to each other. As long as there is no logical contradiction, different embodiments can be combined with each other.

Claims

1. A method for generating a bidding document, characterized in that: Applied to a first terminal, the first terminal is in communication connection with a first encryption lock, the method includes: Based on the device private key in the first encryption lock, the first file and the serial number of the first encryption lock are processed to obtain first data; wherein the first file includes at least one operation record data, each of which is used to describe an action of performing a preset operation on the first file based on the specified encryption lock, and the operation record data includes second data generated by processing the serial number of the specified encryption lock based on the device private key of the specified encryption lock; Generate a bidding document, the bidding document comprising: the first file, the first data and certificate chain identification information for indicating a certificate chain; wherein the certificate chain identification information can be used by the server to find the certificate chain of the encryption lock pre-bound by the bidder, the certificate chain at least including information of a device public key corresponding to a device private key in the pre-bound encryption lock, for verifying the first data and the second data; the first encryption lock, the designated encryption lock and the pre-bound encryption lock are the same as or different from each other.

2. The method according to claim 1, characterized in that: The operation record data also includes a corresponding sequence identifier, and the sequence identifier is used to uniquely identify the sequence of a preset operation performed on the first file.

3. The method according to any one of claims 1 to 2, characterized in that: The operation record data also includes a corresponding terminal identifier, where the terminal identifier is used to uniquely identify a terminal device based on which a preset operation is performed on the first file.

4. The method according to any one of claims 1 to 2, characterized in that: The first encryption lock records a first operation number, which is used to describe the number of times a preset operation is performed on the first file based on the first encryption lock; at least one operation record data in the bidding file is also used to indicate a second operation number.

5. The method according to claim 3, characterized in that: The first encryption lock records a first operation number, which is used to describe the number of times a preset operation is performed on the first file based on the first encryption lock; at least one operation record data in the bidding file is also used to indicate a second operation number.

6. A method for verifying a bidding document, characterized in that: Applicable to servers, including: Obtain a bidding document, the bidding document comprising: a first file, first data, and certificate chain identification information for indicating a certificate chain; wherein the first file comprises at least one operation record data, each of which is used to describe an action of performing a preset operation on the first file based on a specified encryption lock, and the operation record data comprises second data generated by processing a serial number of the specified encryption lock based on a device private key of the specified encryption lock; In the case where the first data is verified successfully based on the certificate chain, determining a serial number of a designated encryption lock used to form the second data; The bidding document is verified based on the serial number of the designated encryption lock and the serial number of the encryption lock pre-bound by the bidder of the bidding document.

7. The method according to claim 6, characterized in that Also includes: In a case where the second data and the first data are verified based on the certificate chain, determining a sequence identifier respectively included in the at least one operation record; Based on the sequence identifier, the bid document is verified.

8. The method according to any one of claims 6 to 7, characterized in that: Also includes: Determine a terminal identifier based on which the second data is formed, where the terminal identifier is used to uniquely identify a terminal device based on which a preset operation is performed on the first file; The bid document is verified based on the terminal identification and terminal identifications determined from other bid documents.

9. The method according to any one of claims 6 to 7, characterized in that: Also includes: In a case where the first data is verified to be successful based on the certificate chain, determining a first operation count, where the first operation count is used to describe the number of times a preset operation is performed on the first file based on the first encryption lock; Determine a second operation number based on the at least one operation record data, where the second operation number is used to indicate the number of times a preset operation is performed on the first file based on the specified encryption lock; The bid document is verified based on the first operation number and the second operation number.

10. The method according to claim 8, characterized in that Also includes: In a case where the first data is verified to be successful based on the certificate chain, determining a first operation count, where the first operation count is used to describe the number of times a preset operation is performed on the first file based on the first encryption lock; Determine a second operation number based on the at least one operation record data, where the second operation number is used to indicate the number of times a preset operation is performed on the first file based on the specified encryption lock; The bid document is verified based on the first operation number and the second operation number.

11. An electronic device, characterized in that: include: a memory configured to store predetermined computer instructions; The processor is configured to run the predetermined computer instructions to implement the method for generating a bidding document applied to the first terminal as described in any one of claims 1 to 5, or to implement the method for verifying a bidding document applied to the server as described in any one of claims 6 to 10.

12. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the processor executes the method for generating a bidding document applied to a first terminal as described in any one of claims 1 to 5, or the method for verifying a bidding document applied to a server as described in any one of claims 6 to 10.

Images