Digital signature method, system, electronic device, storage medium and program product

Abstract

The present application discloses a digital signature method, system, electronic device, storage medium and program product. It is applied to a signature device, including: receiving a signature strategy and a transaction message sent by a terminal device, wherein the signature strategy includes a signature private key list and a signature algorithm list; after detecting a confirmation instruction, traversing each private key in the signature private key list, and signing the transaction message according to the current traversal private key and the algorithm identifier corresponding to the current traversal private key included in the signature algorithm list to generate a digital signature; the confirmation instruction indicates the user's instruction to confirm the transaction message; the digital signature generated by each traversal is sent to the terminal device to achieve multi-signature protection. Since the present application generates multiple signatures after the user confirms once in a transaction signature process, it is suitable for the hybrid signature mechanism in post-quantum cryptography migration, which can improve user experience and signature performance.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a digital signature method, system, electronic device, storage medium, and program product. Background Art

[0002] USB keys (also known as USB shields or online banking shields), widely used in the financial industry, are security authentication devices (also known as signature devices) that combine digital certificates and hardware encryption technology. They resemble USB flash drives. Their core function is to provide user identity verification and transaction signature services, making them widely used in high-security scenarios such as online banking transfers and online transactions. The "What You See Is What You Sign" feature of USB keys works as follows: when a user initiates a transaction, the system displays key transaction information (such as the payee, amount, and account number) on the USB key's screen for verification. After confirming that everything is correct, the user presses the confirmation button on the USB key, which then signs the transaction data. This "What You See Is What You Sign" feature ensures both the authenticity of the signature and non-repudiation.

[0003] In the prior art, when a USB key is used to sign a transaction, the user needs to enter a PIN (Personal Identification Number), verify the transaction information, and press a button to confirm the operation.

[0004] In order to ensure the security of USB Keys during the "migration" and "transition" of post-quantum cryptographic algorithms, multiple signatures are required in transaction signature scenarios. However, if multiple signatures are to be generated, users need to repeat the above operations multiple times. The operation process is cumbersome, and it is difficult for users to verify whether the transaction data of multiple signatures is correct and consistent, resulting in a poor user experience.

[0005] The above statements are only used to provide background information related to the present application and do not necessarily constitute prior art. Summary of the Invention

[0006] In view of the above-mentioned related technologies, the present application provides a digital signature method, system, electronic device, storage medium and program product. In order to provide multi-signature protection, in a transaction signing process, the user confirms once and generates multiple signatures, thereby improving user experience and signature performance.

[0007] A first aspect of an embodiment of the present application provides a digital signature method, applied to a signature device, comprising:

[0008] Receive a signature policy and transaction message sent by a terminal device, wherein the signature policy includes a signature private key list and a signature algorithm list;

[0009] After detecting a confirmation instruction, traversing each private key in the signature private key list and signing the transaction message based on the currently traversed private key and the algorithm identifier corresponding to the currently traversed private key included in the signature algorithm list to generate a digital signature; the confirmation instruction represents an instruction from the user to confirm the transaction message;

[0010] The digital signature generated in each traversal is sent to the terminal device.

[0011] A second aspect of an embodiment of the present application provides a digital signature method, applied to a terminal device, comprising:

[0012] Sending a signature policy and a transaction message to a signing device, so that upon detecting a confirmation instruction, the signing device traverses the private keys in the signature private key list included in the signature policy, and signs the transaction message based on the currently traversed private key and the algorithm identifier corresponding to the currently traversed private key in the signature algorithm list included in the signature policy, thereby generating a digital signature; the confirmation instruction represents an instruction from the user to confirm the transaction message;

[0013] Receive the digital signature generated by each traversal returned by the signature device.

[0014] A third aspect of the embodiments of the present application provides a digital signature system, including: a signature device and a terminal device;

[0015] The terminal device is used to send a signature policy and a transaction message to the signing device, wherein the signature policy includes a signature private key list and a signature algorithm list;

[0016] The signing device is configured to, after detecting a confirmation instruction, traverse each private key in the signature private key list and sign the transaction message based on the currently traversed private key and the algorithm identifier corresponding to the currently traversed private key included in the signature algorithm list to generate a digital signature; the confirmation instruction represents an instruction from a user to confirm the transaction message;

[0017] The terminal device is further configured to receive the digital signatures generated in each traversal and returned by the signature device.

[0018] According to a fourth aspect of an embodiment of the present application, an electronic device is provided, comprising a memory, a processor, and a machine program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in the first or second aspect above.

[0019] According to a fifth aspect of the embodiments of the present application, a computer-readable storage medium is provided, on which a computer program is stored. The program is executed by a processor to implement the method described in the first or second aspect above.

[0020] In a sixth aspect of the embodiments of the present application, a computer program product is provided, including a computer program, wherein the computer program is executed by a processor to implement the method described in the first aspect or the second aspect.

[0021] Based on the digital signature method, system, electronic device, storage medium, and program product described above, this application has at least the following beneficial effects:

[0022] The signing device receives the signature policy and transaction message from the terminal device. After detecting that the user has confirmed the transaction, it sequentially traverses each private key in the signature private key list included in the signature policy, and signs the transaction message using the currently traversed private key and the algorithm identifier corresponding to the currently traversed private key in the signature algorithm list included in the signature policy. After completing the traversal of the signature private key list, it ultimately obtains multiple digital signatures and provides them to the terminal device, thereby achieving multi-signature protection. Because this application generates multiple signatures in a transaction signing process with a single user confirmation, it can improve user experience and signature performance.

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

[0024] Various other advantages and benefits will become apparent to those skilled in the art upon reading the detailed description of the embodiments below. The accompanying drawings are only for the purpose of illustrating the embodiments of the present application and are not to be considered as limiting the present application. In addition, the same reference numerals are used throughout the drawings to represent the same components. In the drawings:

[0025] Figure 1 A flowchart of a digital signature method provided according to some embodiments of the present application;

[0026] Figure 2 A flowchart of another digital signature method provided according to some embodiments of the present application;

[0027] Figure 3 An interactive flow chart of a digital signature system provided according to some embodiments of the present application;

[0028] Figure 4 This is a schematic structural diagram of an electronic device provided according to some embodiments of the present application. DETAILED DESCRIPTION

[0029] The following embodiments of the technical solution of the present application will be described in detail with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present application and are therefore only examples and are not intended to limit the scope of protection of the present application.

[0030] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application belongs; the terms used herein are only for the purpose of describing specific embodiments and are not intended to limit this application; the terms "including" and "having" and any variations thereof in the specification and claims of this application and the above-mentioned figure descriptions are intended to cover non-exclusive inclusions.

[0031] In the description of the embodiments of this application, the technical terms "first" and "second" are used only to distinguish different objects and should not be understood to indicate or imply relative importance or implicitly specify the quantity, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, the meaning of "plurality" is more than two, unless otherwise clearly and specifically defined.

[0032] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.

[0033] With the development of quantum computing technology, traditional asymmetric cryptographic algorithms, such as RSA (Rivest-Shamir-Adleman) and ECC (Elliptic Curve Cryptography), which are based on the difficulty of large integer factorization and the elliptic curve discrete logarithm problem, face the threat of Shor's algorithm in the post-quantum era, and the risk of being cracked is increasing. As quantum computers supporting more qubits are developed, the security risks of these traditional asymmetric cryptographic algorithms becoming even more prominent.

[0034] Post-quantum cryptography has emerged to address the threat posed by quantum computing to traditional asymmetric cryptographic algorithms. However, research on post-quantum cryptography is relatively recent, and the effectiveness of various security analyses remains to be determined, with standardization still underway. Based on the experience of building and upgrading the RSA algorithm security system and migrating national secret algorithms, the migration process to post-quantum cryptography is bound to be a lengthy one. During the post-quantum cryptographic algorithm migration and transition phase, a hybrid signature approach combining traditional asymmetric cryptography with post-quantum cryptography is a viable option, providing security comparable to that of traditional cryptographic algorithms. However, the choice of hybrid signature depends on the specific business scenario, workload, overhead, complexity, and other factors.

[0035] As mentioned above, the existing USB Key technology requires verifying the user's PIN, checking the transaction information, and pressing a key to confirm a transaction signature. If multiple signatures are to be generated, the above operations need to be repeated multiple times. The process is cumbersome and it is difficult for users to verify whether the transaction data of multiple signatures is correct and consistent, resulting in a poor user experience.

[0036] Based on the above-mentioned problems existing in related technologies, some embodiments of the present application propose a digital signature method, system, electronic device, and storage medium. After verifying the user's PIN, the digital signature method receives the signature policy and transaction message from the terminal device. After detecting that the user has confirmed the transaction, the signature device uses multiple signature algorithms and multiple private keys specified by the signature policy to sign the same transaction message, outputting multiple digital signatures to the terminal device, thereby achieving multi-signature protection. Because the present application verifies and confirms the user's PIN once in a transaction signing process, multiple signatures can be generated, thus improving user experience and signature performance.

[0037] In some embodiments of the present application, the terminal device can be understood as a host computer, such as a mobile phone, tablet computer, or computer. The signature device can be a USB (Universal Serial Bus) device or a Bluetooth device, such as a USBKey, which can be plugged into the terminal device for signature processing.

[0038] Some embodiments of the present application provide a digital signature method, the execution subject of the digital signature method can be a signature device, see Figure 1 , the method includes the following steps 101-103.

[0039] Step 101: Receive a signature policy and transaction message sent by a terminal device. The signature policy includes a signature private key list and a signature algorithm list.

[0040] Step 102: After detecting the confirmation instruction, the private keys in the signature private key list are traversed, and the transaction message is signed based on the currently traversed private key and the algorithm identifier corresponding to the currently traversed private key included in the signature algorithm list to generate a digital signature; the confirmation instruction indicates the user's instruction to confirm the transaction message;

[0041] Step 103: Send the digital signature generated in each traversal to the terminal device.

[0042] The signature policy is used to describe the specific behavior of a transaction signature. Usually, the signature policy sent by the terminal device comes from the transaction system. It can include descriptions of the signature private key list and the signature algorithm list. The signature private key list gives the private key ID used to generate multiple signatures. The signature algorithm list gives the algorithm identifiers of the asymmetric algorithm and hash algorithm used to generate multiple signatures. One signature corresponds to one algorithm identifier, and the algorithm identifier can be used to locate the specific asymmetric algorithm and hash algorithm to be used.

[0043] Specifically, in the list, each private key ID corresponds to an asymmetric algorithm and hash algorithm identifier. That is, the number of private key IDs in the signature private key list matches the number of algorithm identifiers in the signature algorithm list. In one example, the order of the private key IDs in the signature private key list matches the order of the algorithms in the signature algorithm list. That is, the order of the private key IDs and algorithm identifiers determines the signing order.

[0044] It can be seen that the signature strategy also implicitly includes information about the signature order. The above-mentioned form of the signature order is only an example, and other forms are of course possible.

[0045] A transaction message can be understood as data to be digitally signed. Typically, the transaction message sent by a terminal device comes from a transaction system and includes transaction data involved in a transaction, such as the payee, amount, and payment account number.

[0046] It should be noted here that the signature policy can be transmitted during the transaction negotiation process, and the transaction message can be transmitted after the signature policy check is passed. In this way, the signing device checks the signature policy of the transaction negotiation to ensure the internal security status of the device. If the signature policy check fails, the signature can be rejected to avoid leakage of transaction data.

[0047] The confirmation instruction can be understood as the user's confirmation of the transaction message on the signature device, that is, the user agrees to proceed with the transaction. The confirmation instruction can be triggered by the user pressing a button to confirm or by other means, which is not specifically limited in this application.

[0048] For example, the signature private key list includes: private key 1 and private key 2 in sequence, and the signature algorithm list includes: algorithm identifier 1 and algorithm identifier 2 in sequence. Assuming that signing is required in sequence, when traversing private key 1 in the signature private key list, the transaction message is signed according to the asymmetric algorithm and hash algorithm indicated by private key 1 and algorithm identifier 1. When traversing to private key 2, the same transaction message is signed according to the asymmetric algorithm and hash algorithm indicated by private key 2 and algorithm identifier 2, thereby obtaining two digital signatures.

[0049] The embodiment of the present application does not specifically limit the type of multiple digital signatures. If the algorithm identifier is a traditional asymmetric cryptographic algorithm, a traditional asymmetric cryptographic algorithm digital signature is performed; if the algorithm identifier is a post-quantum cryptographic algorithm, a post-quantum cryptographic algorithm digital signature is performed; if the algorithm identifier includes both a traditional asymmetric cryptographic algorithm and a post-quantum cryptographic algorithm, a hybrid signature is performed.

[0050] In the above embodiment, the signing device receives the signature policy and transaction message from the terminal device. After detecting that the user has confirmed the transaction, it sequentially traverses each private key in the signature private key list included in the signature policy, and signs the transaction message using the currently traversed private key and the algorithm identifier corresponding to the currently traversed private key in the signature algorithm list included in the signature policy. After completing the traversal of the signature private key list, it ultimately obtains multiple digital signatures and provides them to the terminal device, thereby implementing multi-signature protection. Because this application generates multiple signatures in a single transaction signing process with a single user confirmation, it can improve user experience and signature performance.

[0051] In some embodiments of the present application, a signature policy may further include a signature mode and a signature count. The signature mode refers to the method for generating multiple signatures, and the signature count refers to the number of signatures that can be generated by the signature policy used in this transaction. The signature device controls the algorithm, signature sequence, and signature mode of the multiple signatures included in the signature policy to avoid unsafe combinations.

[0052] The signature mode can include either independent multi-signature mode or serial multi-signature mode. Independent multi-signature mode refers to the use of multiple sets of private keys and signature algorithms to independently sign the same signature source text. Serial multi-signature mode refers to the use of multiple sets of private keys and signature algorithms to perform serial signatures. During the serial signature process, the first set of private keys and signature algorithms signs the signature source text, and the second set of private keys and signature algorithms signs the signature result of the previous set of private keys and signature algorithms.

[0053] Assume that the signing process uses multiple signature private keys and signature algorithms to sign the same signature text m multiple times. If it is an independent multi-signature mode, the output multiple signature results are: S1(H1(m)), S2(H2(m)), ..., Sn(Hn(m)), each signature result is independent of each other and can be verified independently; if it is a serial multi-signature mode, the output multiple signature results are: R1=S1(H1(m)), R2=S2(H2(R1)), ..., Rn=Sn(Hn(Rn-1)). When verifying, first verify R1, then use R1 as the original text to verify R2, and so on.

[0054] For example, a signature policy might consist of the following:

[0055] SignMode | nSign | PrivateKID1~n | SignAlgID1~n | HashAlgID1~n

[0056] Assume that the traditional asymmetric cryptographic algorithm + post-quantum cryptographic algorithm: ECC P256 + ML-DSA are used to cascade multiple signatures, as shown in Table 1 below.

[0057] Table 1

[0058]

[0059] Based on this, the process of step 101 may include:

[0060] After the PIN sent by the terminal device is verified, receiving the signature policy from the terminal device;

[0061] When checking that the signature policy meets the preset rule conditions, determine whether the whitelist contains the combination list of the signature mode and signature algorithm list in the signature policy; the whitelist contains the combination list of the signature mode and signature algorithm list recognized by the signature device;

[0062] If the judgment is yes, a successful negotiation result is returned to the terminal device;

[0063] Receive transaction messages from terminal devices.

[0064] Before executing transaction negotiation, the signature device can also receive the PIN entered by the user on the terminal device and verify the PIN to achieve the user's PIN authority. If the verification fails, a verification failure notification can be returned to the terminal device, thereby rejecting the transaction negotiation.

[0065] In one example, when the signing device and the terminal device conduct transaction negotiation, the transaction negotiation is performed by transmitting a transaction negotiation instruction carrying a signature policy.

[0066] For example, when a signature policy is received, the signature mode, signature private key list, signature order (which can be determined by the order of the private keys), and algorithm identifier corresponding to the private key ID in the signature policy can be recorded and stored.

[0067] The preset rule conditions can be understood as logical rules that the signature policy needs to meet to avoid insecure signature policies.

[0068] The whitelist is a combination list of signature modes and signature algorithms that the signature policy stored inside the signature device can have, that is, it contains a description of the combination list of allowed signature algorithms, signature orders and signature modes.

[0069] For example, one of the allowed policies in the list is: independent multi-signature mode, first signing with RSA2048+SHA256, then signing with ML-DSA+SHA512; another allowed policy in the list is: concatenated signature mode, first signing with ECC P256+SHA256, then signing with ML-DSA+SHA512.

[0070] It should be noted here that if the signature policy does not meet the preset rule conditions or the signature policy is not a policy allowed in the whitelist, the signing device will reject the signature and return a negotiation failure result.

[0071] In this embodiment, the signature policy of the transaction negotiation is checked and matched from two dimensions: logical rules and the whitelist permission policy built into the device to ensure the secure combination of the signature policy. Based on the successful negotiation, the transaction message is further transmitted to avoid the leakage of transaction data.

[0072] In one embodiment, the process of checking whether the signature policy meets the preset rule conditions may include the following steps:

[0073] Determine whether the signature mode matches the number of signatures. In other words, in multi-signature mode, the number of signatures is an integer greater than 1.

[0074] If they match, check whether the length of the signature private key list and the length of the signature algorithm list are the same as the value of the number of signatures;

[0075] If they are the same, check whether each private key in the signature private key list supports the algorithm indicated by the corresponding algorithm identifier in the signature algorithm list;

[0076] If both are supported, it is determined that the signature policy meets the preset rule conditions.

[0077] It is understandable that there is no restriction on the order in which the above-mentioned checking steps may be performed. If all the checking steps are passed, it means that the signature policy meets the preset rule conditions.

[0078] In this embodiment, by performing logical rule checks on each element in the signature policy, the security and reliability of the signature policy can be ensured.

[0079] In other embodiments of the present application, when it is determined that the whitelist contains a combined list of signature modes and signature algorithm lists in the signature policy, signature permissions can be set for each private key in the signature private key list. Only when it is recognized that the private key is set with signature permissions, the private key is used for signing.

[0080] Furthermore, after signing the transaction message using the current traversal private key and the algorithm identifier corresponding to the current traversal private key included in the signature algorithm list, the signature permission corresponding to the current traversal private key is deleted, causing the current traversal private key to lose its signature permission. The signature permission indicates that the corresponding private key is allowed to sign once. For example, if the signature permission is set to "1" for a private key, the "1" is deleted after the private key is used to complete the signature.

[0081] In this embodiment, after the user PIN is verified and the signature policy check of the transaction negotiation is passed, signing permissions are set for each private key in the signature policy, and the signing permissions are cleared after the private key is used to sign, so that each private key has the opportunity to obtain signing permissions once.

[0082] In some other embodiments of the present application, after receiving the transaction message sent by the terminal device, the following steps may also be included:

[0083] Check whether the signature mode and signature algorithm list included in the signature policy are consistent with the signature description carried in the transaction message;

[0084] If they are consistent, the key transaction information in the transaction message will be displayed for the user to confirm.

[0085] The transaction message can include a description of the signature policy, namely the signature mode, signature algorithm list, and signature order. Taking the signature order as the order of algorithm identifiers in the signature algorithm list as an example, the signature description in the transaction message is: SignMode | SignAlgID1~n | HashAlgID1~n, where SignMode represents the signature mode information, and SignAlgID1~n and HashAlgID1~n represent the algorithm identifiers of the asymmetric algorithm and hash algorithm combination in the signature algorithm list.

[0086] In specific implementation, after the transaction negotiation is passed, the signature device checks the transaction message format and the signature description in the message when parsing the transaction message. The specific process of checking the signature description in the transaction message includes:

[0087] a) Compare the SignMode in the transaction message to see if it is consistent with the SignMode in the signature policy during the transaction negotiation process. If they are inconsistent, a failure is returned;

[0088] b) Compare SignAlgID1~n in the transaction message to see if they are consistent with SignAlgID1~n in the signature policy during the transaction negotiation process (both in order and value). If they are not consistent, a failure is returned.

[0089] c) Compare HashAlgID1~n in the transaction message to see if they are consistent with HashAlgID1~n in the transaction negotiation instruction (both in order and value). If they are not consistent, a failure is returned.

[0090] In this embodiment, by declaring a description of the signature policy in the transaction message, the signing device compares the consistency between the signature description in the transaction message and the signature policy negotiated for the transaction. This can prevent an attacker from forging a multi-signature transaction by repeatedly calling the single signature function of the signing device, thereby achieving non-repudiation of the multi-signature transaction.

[0091] In some embodiments of the present application, based on the different signature modes given above, the process of step 102 may include: signing the transaction message using the current traversal private key and the algorithm identifier corresponding to the current traversal private key according to the signature mode;

[0092] That is, the signature original text m is the transaction message, and when traversing n private keys and the signature mode is independent multi-signature mode, the generated signature results are: S1(H1(m)), S2(H2(m)), ..., Sn(Hn(m));

[0093] When the signature mode is the serial multi-signature mode, a) the first traversal private key is used to sign the signature original m, and the signature result is R1=S1(H1(m)); b) R1 is used as the signature original (or part of the original) of the next traversal private key, R2=S2(H2(R1)); c) and so on, the signature result of the last traversal private key is Rn=Sn(Hn(Rn-1)), so the output signature results are R1, R2, ..., Rn.

[0094] Some embodiments of the present application provide another digital signature method, the execution subject of the digital signature method can be a terminal device, see Figure 2 , the method includes the following steps 201-202.

[0095] Step 201: Sending a signature policy and a transaction message to a signing device. After detecting a confirmation instruction, the signing device traverses the private keys in the signature private key list included in the signature policy, and signs the transaction message based on the currently traversed private key and the algorithm identifier corresponding to the currently traversed private key in the signature algorithm list included in the signature policy, thereby generating a digital signature. The confirmation instruction indicates the user's instruction to confirm the transaction message.

[0096] Step 202: Receive the digital signatures generated by each traversal returned by the signature device.

[0097] For the specific implementation of this embodiment, please refer to the above Figure 1 The relevant descriptions in the illustrated embodiments will not be repeated in this application.

[0098] In some embodiments of the present application, the process of step 202 may include:

[0099] Send a result-getting instruction to the signature device and increase the number of times it is sent by 1;

[0100] When the digital signature returned by the signature device is received, the step of sending the result-retrieval instruction to the signature device is continued until the number of transmissions reaches the number of signatures included in the signature policy.

[0101] In this embodiment, considering that the signature lengths generated by different signature algorithms are different, for example, the signature length generated by the post-quantum cryptography algorithm is longer than the signature length generated by the traditional asymmetric cryptography algorithm, if multiple digital signatures are spliced ​​together, then the signature length may exceed the one-time transmission capacity of the device or communication protocol. Therefore, when the terminal device obtains the signature result, it sends the result retrieval instruction to the signature device in sequence according to the signature strategy negotiated in the transaction to obtain multiple digital signatures. Since one digital signature is transmitted each time, this can ensure that the length of the transmitted data does not exceed the limit.

[0102] It should be noted that the length of a signature generated using a post-quantum cryptographic algorithm may also exceed the transmission capacity of the device or communication protocol. In another embodiment, when transmitting a digital signature, the number of transmissions of the digital signature can be determined based on the length and transmission capacity of the digital signature to be transmitted. Therefore, a signature result may be returned through multiple transmissions.

[0103] Some embodiments of the present application also provide a digital signature system, which is used to execute the digital signature method provided by any of the above embodiments. Figure 3The interactive flow chart of the fault detection system shown in the figure includes: a terminal device and a signature device. For ease of understanding, the terminal device is used as the host computer, and the signature device is used as a USB key. The USB key is plugged into the host computer and communicates with the host computer via hardware media. Before executing the transaction signature negotiation, the USB key receives the APDU (Application Protocol Data Unit) instruction from the host computer to verify the user's PIN and verifies the user's PIN to ensure that the user's PIN is authorized. After successful verification, the multi-signature process includes the following steps:

[0104] Step 1: The USB Key receives the transaction negotiation instruction (APDU instruction) issued by the host computer. The USB Key parses the signature policy information declared in the transaction negotiation instruction and checks whether the signature policy meets the preset rule conditions. If so, it determines whether the signature policy matches the built-in whitelist. If not, the signature is rejected and a negotiation failure is returned. If they match, the negotiation is successful and enters Step 2.

[0105] Step 2: The USB Key receives the APDU instruction for the transaction message transmission from the host computer. Depending on the length of the transaction data to be transmitted, the host computer may send multiple instruction sequences. After receiving the transaction message, the USB Key verifies the integrity and format of the transaction message and compares the signature description in the transaction message with the signature policy used during the transaction negotiation process. If the message fails to be received, the check fails, or the policy is inconsistent, the signature is rejected. Otherwise, the USB Key displays the message and proceeds to Step 3.

[0106] Step 3: The USB Key waits for the user to verify the message and confirm it by pressing a key. During this time, the USB Key can receive a key status query from the host computer and return information about whether the user has pressed a key. If the user cancels the key press or the key press times out, the signing process exits; otherwise, it proceeds to Step 4. This applies to signature devices such as single-button USB Keys; for standard USB Keys, there is no key status query.

[0107] Step 4: The USB Key receives the APDU instruction (Get Result) from the host computer. Based on the negotiated signature mode, the USB Key iterates through the private keys in the signature private key list, signs the signature using the found private key and the corresponding signature algorithm, and returns the signature to the host computer. Upon receiving the Get Result instruction from the host computer, the USB Key continues to iterate through the private keys, signing the signature using the found private key and the corresponding signature algorithm, and returns the signature to the host computer. This continues until all private keys have been signed. The host computer then concatenates multiple digital signatures to complete the multi-signature output. It should be noted that if a signature failure occurs during execution, the signature is aborted and a signature failure error code is returned.

[0108] The digital signature system provided in the embodiment of the present application and the method provided in the embodiment of the present application are based on the same inventive concept and have the same beneficial effects as the methods adopted, operated or implemented by them.

[0109] The above description of the various embodiments tends to emphasize the differences between the various embodiments. The same or similar aspects can be referenced with each other and will not be repeated herein for the sake of brevity.

[0110] Based on the above embodiments, it can be seen that the present application scheme can support various digital signature scenarios, such as "one-time multiple signatures" of traditional asymmetric cryptographic algorithms, "one-time multiple signatures" of post-quantum cryptographic algorithms, and "one-time multiple signatures" of a mixture of post-quantum cryptographic algorithms and traditional asymmetric cryptographic algorithms.

[0111] Among them, "one-time multi-signature" means that in a transaction signing process, "the user PIN is entered once, the user presses the button to confirm once, multiple signature algorithms and multiple private keys are used to sign the same transaction message, multiple signature results are output, and the signature permission is cleared." That is: multiple signatures are treated as an atomic operation inside the USB Key, multiple digital signatures are successful, and the signature permission is cleared.

[0112] Other embodiments of the present application provide an electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the digital signature method of any of the above-mentioned embodiments.

[0113] like Figure 4 As shown, the electronic device 60 may include: a processor 600, a memory 601, a bus 602 and a communication interface 603, and the processor 600, the communication interface 603 and the memory 601 are connected via the bus 602; the memory 601 stores a computer program that can be run on the processor 600, and when the processor 600 runs the computer program, it executes the method provided in any of the aforementioned embodiments of the present application.

[0114] Memory 601 may include high-speed random access memory (RAM) and may also include non-volatile memory, such as at least one disk storage device. Communication between the system network element and at least one other network element is achieved through at least one communication interface 603 (which may be wired or wireless), and may utilize the Internet, a wide area network, a local area network, a metropolitan area network, or the like.

[0115] Bus 602 may be an ISA bus, a PCI bus, or an EISA bus. Buses may be classified as address buses, data buses, and control buses. Memory 601 is used to store programs, and processor 600 executes the programs upon receiving execution instructions. The methods disclosed in any of the aforementioned embodiments of the present application may be applied to or implemented by processor 600.

[0116] The processor 600 may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by hardware integrated logic circuits in the processor 600 or by software instructions. The above processor 600 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium mature in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory 601 , and the processor 600 reads the information in the memory 601 and completes the steps of the above method in combination with its hardware.

[0117] The electronic device provided in the embodiments of the present application and the method provided in the embodiments of the present application are based on the same inventive concept and have the same beneficial effects as the methods adopted, operated or implemented by them.

[0118] Other embodiments of the present application provide a computer-readable storage medium having a computer program stored thereon, which is executed by a processor to implement the method of any of the above embodiments.

[0119] The computer-readable storage medium provided in the embodiment of the present application and the method provided in the embodiment of the present application are based on the same inventive concept and have the same beneficial effects as the method adopted, operated or implemented by them.

[0120] An embodiment of the present application also provides a computer program product corresponding to the method provided in the aforementioned embodiment. The computer program product includes a computer program, which is executed by a processor to implement the digital signature method provided in the aforementioned embodiment.

[0121] The computer program product provided by the above-mentioned embodiments of the present application and the method provided by the embodiments of the present application are based on the same inventive concept and have the same beneficial effects as the method adopted, run or implemented by the application program stored therein.

[0122] The above description of the various embodiments tends to emphasize the differences between the various embodiments. The same or similar aspects can be referenced with each other and will not be repeated herein for the sake of brevity.

Claims

1. A digital signature method, characterized in that: Applicable to signature devices, including: Receive a signature policy and transaction message sent by a terminal device, wherein the signature policy includes a signature private key list and a signature algorithm list; After detecting a confirmation instruction, traverse each private key in the signature private key list and sign the transaction message based on the currently traversed private key and the algorithm identifier corresponding to the currently traversed private key included in the signature algorithm list to generate a digital signature; the confirmation instruction represents an instruction from the user to confirm the transaction message once; wherein the signature policy is used to specify multiple signature algorithms and multiple private keys to sign the same transaction message and output multiple signatures; The digital signature generated in each traversal is sent to the terminal device.

2. The method according to claim 1, characterized in that The signature strategy also includes a signature mode; the signature strategy and transaction message sent by the receiving terminal device include: receiving a signature policy from the terminal device after the personal identification number (PIN) sent by the terminal device is verified; When checking that the signature policy satisfies a preset rule condition, determining whether the whitelist includes a combination list of signature modes and signature algorithm lists in the signature policy; the whitelist includes a combination list of signature modes and signature algorithm lists recognized by the signature device; If the judgment is yes, returning a result of successful negotiation to the terminal device; Receive a transaction message from the terminal device.

3. The method according to claim 2, characterized in that The signature strategy also includes the number of signatures; and the step of checking that the signature strategy meets the preset rule conditions includes: Determining whether the signature pattern matches the number of signatures; If they match, check whether the length of the signature private key list and the length of the signature algorithm list are the same as the value of the number of signatures; If they are the same, check whether each private key in the signature private key list supports the algorithm indicated by the corresponding algorithm identifier in the signature algorithm list; If both are supported, it is determined that the signature strategy meets the preset rule conditions.

4. The method according to claim 2, characterized in that The method further comprises: If it is determined that the whitelist contains a combination of the signature mode and signature algorithm list in the signature policy, setting signature permissions for each private key in the signature private key list; Furthermore, after signing the transaction message according to the current traversal private key and the algorithm identifier corresponding to the current traversal private key included in the signature algorithm list, the signature authority corresponding to the current traversal private key is deleted.

5. The method according to any one of claims 1 to 4, characterized in that After receiving the signature policy and transaction message sent by the terminal device, the method further includes: Check whether the signature mode and signature algorithm list included in the signature policy are consistent with the signature description carried in the transaction message; If they are consistent, the key transaction information in the transaction message is displayed for the user to confirm.

6. The method according to claim 1, characterized in that The step of sending the digital signature generated in each traversal to the terminal device includes: Each time a result-getting instruction is received from the terminal device, one of the digital signatures is returned to the terminal device until all the digital signatures generated in each traversal are sent.

7. The method according to claim 1, characterized in that The signature strategy also includes a signature mode; signing the transaction message according to the current traversal private key and the algorithm identifier corresponding to the current traversal private key included in the signature algorithm list includes: Signing the transaction message using the current traversal private key and the algorithm identifier corresponding to the current traversal private key according to the signature mode; The signature mode includes any one of an independent multi-signature mode and a serial multi-signature mode. The independent multi-signature mode refers to using multiple sets of private keys and signature algorithms to independently sign the same signature original. The serial multi-signature mode refers to using multiple sets of private keys and signature algorithms to perform serial signatures. During the serial signature process, the first set of private keys and signature algorithms sign the signature original, and starting from the second set of private keys and signature algorithms, the signature results of the previous set of private keys and signature algorithms are signed.

8. A digital signature method, characterized in that: Applied to terminal equipment, including: Sending a signature policy and a transaction message to a signing device, so that upon detecting a confirmation instruction, the signing device traverses the private keys in the signature private key list included in the signature policy, and signs the transaction message based on the currently traversed private key and the algorithm identifier corresponding to the currently traversed private key in the signature algorithm list included in the signature policy, thereby generating a digital signature; the confirmation instruction represents an instruction from a user to perform a single confirmation of the transaction message; wherein the signature policy is used to specify multiple signature algorithms and multiple private keys to sign the same transaction message, thereby outputting multiple signatures; Receive the digital signature generated by each traversal returned by the signature device.

9. The method according to claim 8, characterized in that The receiving of the digital signatures generated by each traversal returned by the signature device includes: Send a result-getting instruction to the signature device and increase the number of times it is sent by 1; When the digital signature returned by the signature device is received, the step of sending a result-getting instruction to the signature device is continued until the number of sending times reaches the number of signatures included in the signature policy.

10. A digital signature system, characterized in that: include: Signature devices and terminal equipment; The terminal device is used to send a signature policy and a transaction message to the signing device, wherein the signature policy includes a signature private key list and a signature algorithm list; The signing device is configured to, after detecting a confirmation instruction, traverse each private key in the signature private key list and, based on the currently traversed private key and the algorithm identifier corresponding to the currently traversed private key included in the signature algorithm list, sign the transaction message to generate a digital signature; the confirmation instruction represents an instruction from a user to perform a single confirmation of the transaction message; wherein the signature policy is configured to specify multiple signature algorithms and multiple private keys to sign the same transaction message, thereby outputting multiple signatures; The terminal device is further configured to receive the digital signatures generated in each traversal and returned by the signature device.

11. An electronic device, characterized in that: The invention comprises a memory, a processor and a machine program stored in the memory and operable on the processor, wherein the processor executes the program to implement the method according to any one of claims 1 to 9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: The program is executed by a processor to implement the method according to any one of claims 1 to 9.

13. A computer program product comprising a computer program, characterized in that The computer program is executed by a processor to implement the method according to any one of claims 1 to 9.

Images