A double signature payment method supporting ML-DSA algorithm and SM2 algorithm

Abstract

This invention discloses a dual-signature payment method supporting both ML-DSA and SM2 algorithms, relating to the fields of network information security and electronic payment technology. The method includes: pre-installing an SM2 public key certificate and an ML-DSA public key certificate in the user's secure medium; after the user verifies and confirms the transaction via a one-time PIN code, the secure medium is controlled to sign the data to be signed using the pre-installed SM2 private key and ML-DSA private key, respectively, and encapsulated into a signed data packet; the server parses the signed data packet, verifies the SM2 signature and ML-DSA signature in the signed data packet respectively, and returns a structured response object; if the verification result codes of both the SM2 verification item and the ML-DSA verification item in the structured response object are successful, the payment transaction is executed. This invention smoothly introduces quantum-resistant signatures while meeting national cryptographic compliance requirements, providing a feasible solution for the banking industry's transition to quantum-resistant cryptography.

Description

Technical Field

[0001] This invention relates to the fields of network information security and electronic payment technology, and in particular to a dual-signature payment method that supports the ML-DSA algorithm and the SM2 algorithm. Background Technology

[0002] With the booming development of the digital economy, online banking has become a major channel for financial transactions. Currently, the banking industry generally adopts digital certificate systems based on public-key cryptography algorithms such as RSA, ECC, and SM2 to ensure the confidentiality, integrity, and non-repudiation of transaction data. However, the rapid development of quantum computing technology poses a potential threat to this foundation of trust. The emergence of quantum algorithms such as Shor's algorithm means that public-key cryptography algorithms considered secure on traditional computers are at risk of being quickly cracked. Once quantum computers reach a practical scale, the existing financial security system will face severe challenges. Therefore, the financial system urgently needs a smooth transition to quantum-resistant cryptography systems.

[0003] In response to the quantum threat, some countries and international organizations have begun to promote the standardization and migration of quantum-resistant cryptography. When transitioning to quantum-resistant algorithms, existing technologies attempt to employ dual-signature schemes, that is, adding a quantum-resistant signature while retaining the original SM2 signature, to meet the compliance and security requirements of the transition period. These schemes typically involve simply overlaying two independent signature processes; for example, the client calls both the SM2 signature interface and the PQC signature interface, while the server deploys two separate signature verification modules and simply merges the verification results.

[0004] However, this superimposed approach to existing technologies has significant drawbacks. First, there's a conflict between compatibility and compliance. Directly switching to a pure quantum-resistant algorithm might lead to incompatibility with existing system interface specifications, raising compliance risks and affecting interoperability with existing systems. Second, the user experience is fragmented. Users need to confirm both the SM2 signature and the PQC signature separately when executing a transfer, such as entering a PIN code twice or pressing a USB key twice, severely reducing the payment experience and transaction efficiency. Furthermore, the system is highly coupled, lacking a unified encapsulation mechanism to shield the differences in underlying algorithms. The server and client need to develop multiple sets of interfaces for different algorithms, increasing development and maintenance costs. Moreover, when signature verification fails, it's difficult to accurately pinpoint whether the problem lies with the SM2 algorithm or the PQC algorithm.

[0005] Therefore, there is an urgent need for a dual-signature payment solution that can keep up with the trend of quantum migration to ensure long-term financial security, while also taking into account the compliance of existing national cryptographic standards and being transparent to users, so as to support the smooth evolution of the banking industry in the field of future financial quantum security. Summary of the Invention

[0006] This invention aims to overcome the shortcomings of the prior art, and specifically provides the following technical solution: 1) In a first aspect, the present invention provides a dual-signature payment method supporting both the ML-DSA algorithm and the SM2 algorithm, the specific technical solution of which is as follows: Pre-install SM2 public key certificates and ML-DSA public key certificates that are related to the same user identity information in the user's secure medium; In response to the initiated payment transaction, the extended transaction signature interface is called, passing in the SM2 key container identifier, the ML-DSA key container identifier, and the data to be signed; After the user verifies and confirms the transaction via a one-time PIN code, the control security medium uses the pre-set SM2 private key and ML-DSA private key to sign the data to be signed, resulting in an SM2 signature and an ML-DSA signature. Receive the SM2 signature and ML-DSA signature returned by the security medium, obtain the SM2 public key certificate from the security medium based on the SM2 key container identifier, obtain the ML-DSA public key certificate from the security medium based on the ML-DSA key container identifier, and encapsulate the SM2 signature, ML-DSA signature, and the obtained SM2 public key certificate and ML-DSA public key certificate into the same signature data packet; The signed data packet is sent to the server so that the server can parse the signed data packet, verify the SM2 signature and ML-DSA signature in the signed data packet respectively, and return a structured response object containing the verification result code corresponding to each signature item; Receive the structured response object. If the verification result codes of both the SM2 verification item and the ML-DSA verification item in the structured response object are successful, then execute the payment transaction.

[0007] The beneficial effects of the dual-signature payment method supporting both ML-DSA and SM2 algorithms provided by this invention are as follows: The system pre-installs interconnected SM2 and ML-DSA public key certificates, each corresponding to the same user identity information, in the user's secure medium. By extending the transaction signature interface and passing in both the SM2 and ML-DSA key container identifiers at once, the user only needs one PIN code verification and one physical button confirmation to simultaneously generate both the SM2 and ML-DSA signatures. This solves the problem of fragmented user experience in existing technologies where users need to confirm two signatures separately. The SM2 signature, ML-DSA signature, and the obtained SM2 and ML-DSA public key certificates are encapsulated in a single PKCS#7 format signature data packet. The server calls the dual-signature verification interface to parse this data packet and verify both signatures separately, returning a structured response object containing both SM2 and ML-DSA verification items. This achieves unified encapsulation and transmission of dual signatures, reduces system coupling, and avoids the development and maintenance costs of multiple interfaces. The server returns a structured response object. The payment transaction is executed when both the SM2 and ML-DSA verification codes are successful. Otherwise, it can accurately distinguish whether the SM2 signature verification failed or the ML-DSA signature verification failed. This solves the problem of difficulty in locating signature verification failures in existing technologies. While meeting the national cryptographic compliance requirements, it smoothly introduces quantum-resistant signatures, providing a feasible solution for the banking industry to transition to quantum-resistant cryptography.

[0008] Based on the above scheme, the dual-signature payment method supporting ML-DSA and SM2 algorithms of the present invention can be further improved as follows.

[0009] Further, determine whether the user has verified and confirmed the transaction via a one-time PIN code, including: When the secure medium receives a call to the extended transaction signature interface, it prompts the user to enter a PIN code for verification. If the PIN code verification fails, or if the user does not perform a physical button confirmation operation based on the transaction key information displayed on the screen within a preset time after successful verification, the transaction is deemed to have failed the one-time verification and confirmation, and the signature process is terminated. If the PIN code verification passes, and the user performs a physical button confirmation operation based on the transaction key information displayed on the secure medium's screen, the transaction is deemed to have passed the one-time PIN code verification and confirmation.

[0010] The beneficial effects of adopting the above-mentioned further solution are as follows: The secure medium prompts the user to enter a PIN code for verification, and after successful verification, the screen displays key transaction information for the user to check. Verification is only considered successful after the user confirms the transaction via a physical button. This process enables the user to complete all user interactions required for dual signature with a single PIN code input and a single physical button press, solving the cumbersome interaction problem caused by the need for separate confirmations of two signatures in existing technologies. Simultaneously, the mechanism of displaying key transaction information on the screen and waiting for physical button confirmation ensures that the user is verifying the actual transaction content displayed on the secure medium's hardware screen, effectively preventing client software from tampering with transaction information and improving transaction security. The introduction of a preset timeout avoids the secure medium waiting for user operation for an extended period, ensuring the reliable execution of the signature process.

[0011] Furthermore, the server parses the signed data packet and verifies the SM2 signature and ML-DSA signature in the signed data packet, including: the server calls the dual signature value verification interface, parses the signed data packet to obtain the original text and the SM2 signature and ML-DSA signature, calls the corresponding verification logic to verify the SM2 signature and ML-DSA signature respectively, and assembles a structured response object according to the verification result of each signature.

[0012] The beneficial effects of adopting the above-mentioned further solution are as follows: The server calls the dual-signature verification interface, uniformly parses the signature data packet, and calls the corresponding verification logic to verify the SM2 signature and ML-DSA signature respectively, realizing parallel processing and verification of dual signatures within the same interface. Based on the verification result of each signature, a structured response object containing SM2 and ML-DSA verification items is assembled, enabling the business system to obtain the independent verification result code for each signature. This approach solves the problem of single verification results and inability to distinguish specific signature algorithm failures in existing technologies, reduces the coupling between the server-side verification module and business logic, and provides technical support for security monitoring and accurate fault location during the post-quantum migration transition period.

[0013] Furthermore, it also includes: if any verification result code in the SM2 verification item or the ML-DSA verification item in the structured response object fails, the payment transaction will be rejected, and the corresponding audit log will be recorded according to the error description in the failed verification item to distinguish whether it is an SM2 signature verification failure or an ML-DSA signature verification failure.

[0014] The beneficial effects of adopting the above-mentioned further scheme are as follows: It checks the verification result codes of SM2 and ML-DSA verification items in the structured response object. When either verification result code fails, the payment transaction is rejected, and the corresponding audit log is recorded based on the error description in the failed verification item. This process achieves precise differentiation between SM2 signature verification failures and ML-DSA signature verification failures, solving the problem in existing technologies where signature verification failures cannot pinpoint specific algorithmic faults. By recording differentiated audit logs, it provides clear fault source data for security monitoring, fault diagnosis, and system optimization during the post-quantum cryptography migration transition period, avoiding the risk of incorrect handling or misjudgment of security events due to ambiguity in fault source.

[0015] Furthermore, the signature data packet is in PKCS#7 format. The signer information field of the PKCS#7 format signature data packet contains two independent signer information structures corresponding to the SM2 signature item and the ML-DSA signature item, respectively. The SM2 signature item contains the SM2 signature, and the ML-DSA signature item contains the ML-DSA signature.

[0016] The beneficial effects of adopting the above-mentioned further solution are as follows: The signature data packet is encapsulated using the PKCS#7 standard format, and two independent signer information structures are set in the signer information field, corresponding to the SM2 signature item and the ML-DSA signature item respectively. This standardized encapsulation achieves unified carrying and transmission of SM2 and ML-DSA signatures within the same data packet, solving the problem of high system coupling caused by the separate encapsulation of multiple algorithm signatures in existing technologies. The independent signer information structure allows the server to parse and verify the two signatures separately, providing a data foundation for the subsequent return of a structured response object containing SM2 and ML-DSA verification items, ensuring the accuracy and distinguishability of the dual-signature verification process, and improving interoperability with existing PKCS#7 standard-compatible systems.

[0017] 2) Secondly, the present invention also provides a dual-signature payment system supporting the ML-DSA algorithm and the SM2 algorithm, the specific technical solution of which is as follows: It includes a pre-built module, a call input module, a signature module, a receive and encapsulate module, a parsing and return module, and an execution module; The pre-installed module is used to: pre-install interrelated SM2 public key certificates and ML-DSA public key certificates corresponding to the same user identity information in the user's secure medium; The incoming module is used to: respond to the initiated payment transaction, call the extended transaction signature interface, and pass in the SM2 key container identifier, ML-DSA key container identifier, and the data to be signed; The signature module is used to: after a user verifies and confirms a transaction via a one-time PIN code, control the security medium to sign the data to be signed using the preset SM2 private key and ML-DSA private key respectively, to obtain the SM2 signature and ML-DSA signature; The receiving and encapsulation module is used to: receive the SM2 signature and ML-DSA signature returned by the security medium, obtain the SM2 public key certificate from the security medium based on the SM2 key container identifier, obtain the ML-DSA public key certificate from the security medium based on the ML-DSA key container identifier, and encapsulate the SM2 signature, ML-DSA signature, and the obtained SM2 public key certificate and ML-DSA public key certificate into the same signature data packet; The parsing return module is used to: send the signed data packet to the server so that the server can parse the signed data packet, verify the SM2 signature and ML-DSA signature in the signed data packet respectively, and return a structured response object containing the verification result code corresponding to each signature item; The execution module is used to: receive a structured response object; and if the verification result codes of both the SM2 verification item and the ML-DSA verification item in the structured response object are successful, then execute the payment transaction.

[0018] 3) In a third aspect, the present invention also provides an electronic device, the electronic device including a processor coupled to a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor, so as to enable the electronic device to implement any of the above-mentioned dual-signature payment methods supporting the ML-DSA algorithm and the SM2 algorithm.

[0019] 4) In a fourth aspect, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-mentioned dual-signature payment methods supporting the ML-DSA algorithm and the SM2 algorithm.

[0020] It should be noted that the beneficial effects of the technical solutions of the second to fourth aspects of the present invention and their corresponding possible implementations can be found in the above description of the technical effects of the first aspect and its corresponding possible implementations, and will not be repeated here. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments of the present invention will be briefly introduced below: Figure 1 This is one of the flowcharts illustrating a dual-signature payment method supporting the ML-DSA and SM2 algorithms according to an embodiment of the present invention. Figure 2This is a second flowchart illustrating a dual-signature payment method supporting both ML-DSA and SM2 algorithms according to an embodiment of the present invention. Figure 3 This is a schematic diagram of the structure of a dual-signature payment system supporting the ML-DSA algorithm and the SM2 algorithm according to an embodiment of the present invention. Detailed Implementation

[0022] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0023] The technical solution of the present invention and how the technical solution of the present invention solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of the present invention will now be described with reference to the accompanying drawings.

[0024] like Figure 1 As shown in the figure, an embodiment of the present invention provides a dual-signature payment method supporting both the ML-DSA and SM2 algorithms, comprising the following steps: S1. Pre-install mutually related SM2 public key certificates and ML-DSA public key certificates corresponding to the same user identity information in the user's secure medium. The specific implementation process is as follows: S10. When a user activates online banking services or uses the quantum-resistant signature function for the first time, the bank counter system or the user initiates the security medium initialization process online through self-service channels. The client software first connects to the user's security medium and sends instructions to the security medium, requesting it to generate SM2 and ML-DSA key pairs internally. Upon receiving the instructions, the security medium uses its built-in true random number generator to generate high-quality random numbers as private key seeds for the SM2 and ML-DSA key pairs. Based on these seed data, the security chip internally performs key generation operations for the SM2 and ML-DSA algorithms, obtaining the SM2 private key and SM2 public key, and the ML-DSA private key and ML-DSA public key, respectively. The generated private key is always stored in the non-volatile storage area of ​​the security medium and is protected by the security medium's access control policy, preventing direct external reading. The generated public key can be exported by the security medium for subsequent certificate application processes.

[0025] S11. Simultaneously or before generating the key pair on the secure medium, the client software prompts the user to enter their personal identification information, such as name, ID card number, and bank card number. The client transmits this information to the bank's server via an encrypted channel. Upon receiving the information, the server compares and verifies it against the user's account opening information pre-stored in the bank's core system. Only when the user's entered identification information completely matches the information recorded in the bank's system does the server confirm the user's identity as authentic and valid, and authorize the issuance of a digital certificate for the user, ensuring that the subsequently issued SM2 public key certificate and ML-DSA public key certificate can be accurately bound to the real user's identity information.

[0026] S12. After successful user authentication, the client reads the generated SM2 public key and ML-DSA public key from the secure medium. Based on these two public keys, the client constructs two public key certificate issuance requests, i.e., certificate requests in PKCS#10 format. Each certificate request contains the corresponding public key information and the user identity information obtained from the bank's server. For example, the SM2 certificate request contains the SM2 public key and the user identity information string, while the ML-DSA certificate request contains the ML-DSA public key and the same user identity information string.

[0027] S13. Upon receiving two certificate requests, the Certificate Authority (CA) on the bank's server first verifies the integrity and legitimacy of the requests' origins. Then, according to the configured certificate policy, the CA generates X.509 format digital certificates for both the SM2 and ML-DSA certificate requests. When generating the SM2 public key certificate, the CA writes the user's identity information into the certificate's body field, uses the SM2 public key as the certificate's public key field, and finally signs the certificate using the CA's SM2 root certificate private key. Similarly, when generating the ML-DSA public key certificate, the CA writes the same user identity information into the certificate's body field, uses the ML-DSA public key as the public key field, and signs the certificate using the CA's ML-DSA root certificate private key. In this way, the two certificates are cryptographically associated with the same user identity information, achieving the first level of association.

[0028] S14. After issuing the SM2 public key certificate and the ML-DSA public key certificate, the Certificate Authority (CA) sends these two certificates back to the client software via an encrypted communication channel. Upon receiving the certificate data, the client software invokes the write interface of the user's security media. Upon receiving the write command, the security media divides its internal storage space into different key containers. The first key container stores the SM2 key pair and its corresponding SM2 public key certificate, and the second key container stores the ML-DSA key pair and its corresponding ML-DSA public key certificate. The security media logically associates the SM2 private key with the SM2 public key certificate in the first key container, and logically associates the ML-DSA private key with the ML-DSA public key certificate in the second key container. At this point, both certificates are physically pre-installed on the same user's security media.

[0029] S15. After certificate pre-configuration is completed, the bank's server-side security audit system records the correspondence between user identity information, SM2 public key certificate serial number, ML-DSA public key certificate serial number, and the unique serial number of the security medium, forming a three-way association table. This table is permanently stored in the server-side database. When subsequent payment transactions occur, after successful signature verification, the server further verifies the consistency between the user identity information in the certificate subject and the transaction initiating account information, and checks whether the two certificates are associated with the same user identity information and security medium. This background association recording mechanism ensures at the system level that although the SM2 public key certificate and ML-DSA public key certificate are stored in different key containers, they always correspond to the unique user identity information in business logic. This fully realizes the entire process of pre-configuring mutually related SM2 public key certificates and ML-DSA public key certificates corresponding to the same user identity information in the user's security medium.

[0030] In this invention, the user's security medium refers to a dedicated hardware device held by the user for storing digital certificates, public-private key pairs, and performing cryptographic operations. This device has an independent security chip that generates and stores the private key and performs digital signature operations internally, ensuring that the private key never leaves the security medium and thus preventing unauthorized reading or copying. In this embodiment, the user's security medium is specifically in the form of a USB Key, Bluetooth Key, etc., used to provide clients with strong authentication and transaction data signature services in online banking transactions.

[0031] User identity information refers to the set of data that uniquely identifies a user in an online banking system. This information typically includes the user's name, ID card number, bank account number, mobile phone number, and other personally identifiable information. In digital certificate systems, user identity information is usually included in the certificate's subject field, such as the Subject Distinguished Name in an X.509 certificate. This field is used to bind the public key certificate to a specific certificate holder, ensuring that the identity represented by the certificate is authentic and trustworthy.

[0032] S2. In response to the initiated payment transaction, the extended transaction signature interface is called, passing in the SM2 key container identifier, the ML-DSA key container identifier, and the data to be signed. The specific implementation process is as follows: S20. After the user completes the transfer information and clicks the submit button on the online banking front-end interface, the front-end JavaScript code or the business logic layer of the mobile app captures this click event and recognizes it as a formally initiated payment transaction. The system then extracts key information such as the transfer amount, payee's account, payer's account, transaction serial number, and transaction time from the interface input fields according to the transaction message format defined by the bank's backend. This information is then concatenated into a continuous byte sequence according to the agreed order and encoding rules. To ensure the security and efficiency of the signature process, the client calls a cryptographic hash function on this byte sequence, such as using the SM3 algorithm to calculate a 256-bit hash value, or using the SHA-512 algorithm to calculate a 512-bit hash value. This hash value is then Base64 encoded into a printable string, serving as the final form of the data to be signed, ready to be passed to the extended transaction signature interface.

[0033] S21. When a user logs into the online banking system or inserts the security medium for the first time, the client software has already obtained a list of information about all key containers within the medium through the enumeration function provided by the security medium. This list contains the type, identifier, and summary information of the associated certificate for each container. The client stores the identifier of the SM2 type container in the memory variable sm2ContainerId and the identifier of the ML-DSA type container in the memory variable pqContainerId. When a payment transaction is initiated, the client directly reads the current values ​​of these two variables from memory. To ensure the validity of the identifiers, the client can also send a query command to the security medium again before calling the interface to dynamically obtain the list of available containers and filter out the correct SM2 key container identifier and ML-DSA key container identifier according to the certificate type, preventing the identifiers from becoming invalid due to medium replacement or status changes.

[0034] S22. The client creates a parameter object to encapsulate all the data that needs to be passed to the extended transaction signature interface. This object contains at least three properties: the first property is named `hContainer`, and its value is an SM2 key container identifier string; the second property is named `hPQContainer`, and its value is an ML-DSA key container identifier string; the third property is named `b64SrcData`, and its value is a Base64 encoded string of the data to be signed. In some implementations, the parameter object may also contain other optional properties, such as `classicHashAlg` to specify the classic signature digest algorithm type, whose value can be set to an enumerated constant of SM3; and `pqHashAlg` to specify the post-quantum signature digest algorithm type, whose value can be set to an enumerated constant of SM3 or SHA-512. These digest algorithm identifiers are used to inform the secure medium client of the hash algorithm used when calculating the data to be signed, so as to perform consistency processing during the signing process. After the parameter object is constructed, the client saves it in the calling context, ready to pass it to the interface function.

[0035] S23. In a PC browser environment, the front-end JavaScript code calls the interface through a pre-registered global function. Assuming the function is named `PQECCDigestSignData`, the call statement is `PQECCDigestSignData(digestSignParams, callback)`, where `digestSignParams` is the parameter object constructed in the previous step, and `callback` is the callback function used to handle the asynchronous return result. In the mobile app, the call is made through a native method provided by the security SDK, such as calling `sign_pqc(sm2ContainerId, pqContainerId, classicHashAlg, pqHashAlg, b64SrcData, callback)`, where `classicHashAlg` is the identifier for the classic signature digest algorithm, `pqHashAlg` is the identifier for the post-quantum signature digest algorithm, and `b64SrcData` is the data to be signed. After the call, the extended transaction signature interface immediately returns a status value indicating that the request has been received; for example, returning 0 indicates successful operation. The actual signature result will be asynchronously transmitted later through the callback function. This asynchronous design avoids blocking the user interface thread by waiting for a long time for the secure medium to respond.

[0036] S24. Upon receiving the call, the implementation code of the extended transaction signature interface first performs a validity check on the passed parameter object. This check includes verifying whether the SM2 key container identifier is a non-empty string with the correct length, whether the ML-DSA key container identifier is in the correct format, and whether the Base64 encoding of the data to be signed is valid. If any check fails, the interface immediately returns an error code via a callback function and terminates the subsequent process. After successful verification, the interface converts the parameters into a data structure recognizable by the underlying driver. On the PC side, the interface calls the SKFE_PQECCDigestSignData extension function of the SKF driver library, passing the SM2 key container identifier, ML-DSA key container identifier, classic signature digest algorithm identifier, post-quantum signature digest algorithm identifier, and the data to be signed as input parameters, and specifying a buffer for receiving the returned data. On the mobile device, the interface establishes a connection with the Bluetooth Key via Bluetooth or OTG, constructs an APDU command according to the device-defined instruction format, and packages the two container identifiers, two digest algorithm identifiers, and the data to be signed into a package and sends it to the secure medium. Upon receiving the instruction, the secure medium performs necessary processing on subsequent signing operations based on the passed digest algorithm identifiers.

[0037] S25. After the instruction is successfully sent to the secure medium, the synchronization part of the extended transaction signature interface is complete. The interface returns a status code to the caller, indicating that the request has been successfully submitted to the underlying hardware. The subsequent signature result will be notified asynchronously through a callback mechanism. At this time, the client can display the prompt message "Please check the secure medium screen and confirm the transaction," guiding the user to complete the subsequent PIN code input and physical button confirmation operations. This call process of the extended transaction signature interface is now complete. The mission specified in step S2—"in response to the initiated payment transaction, call the extended transaction signature interface, and pass in the SM2 key container identifier, ML-DSA key container identifier, and the data to be signed"—has been completed. The subsequent signature calculation and result return fall under the scope of subsequent steps S3 and S4.

[0038] The Extended Transaction Signature Interface (ETI) is a programming interface defined by client software and exposed to upper-layer applications to support dual-algorithm signature operations. This interface encapsulates the low-level details of communication with the user's secure medium and is specifically designed to trigger the dual digital signature process using the SM2 and ML-DSA algorithms. In a PC browser environment, this interface typically manifests as an ActiveX control or a JavaScript function in a browser extension, such as `PQECCDigestSignData`; in mobile apps, it appears as a function in a security software development kit, such as `sign_pqc`. This interface accepts the SM2 key container identifier, the ML-DSA key container identifier, and the data to be signed as input parameters. After being called, it is responsible for passing these parameters to the secure medium driver layer and ultimately sending the signature result returned by the secure medium back to the upper-layer application.

[0039] The SM2 key container identifier is an identifier used within the user's secure media to uniquely index and access the SM2 key pair and its associated public key certificate. This identifier is typically a string or handle, created and assigned by the secure media during the pre-configuration of the SM2 certificate. When a payment transaction is initiated, the client uses this identifier to inform the secure media which specific SM2 private key should be used to sign the data to be signed. The SM2 key container identifier can take the form of a container name, such as "SM2_KEY_CONTAINER_01", or a numeric index or object identifier, functioning similarly to a file path in a file system, ensuring that the secure media can accurately locate the correct key storage area.

[0040] The ML-DSA key container identifier is an identifier used within the user's secure medium to uniquely index and access the ML-DSA key pair and its associated public key certificate. This identifier, also a string or handle, is similar to the SM2 key container identifier and is created and assigned by the secure medium during the pre-configured ML-DSA certificate phase. During the double-signature process, the client passes this identifier to the extended transaction signature interface. The secure medium uses this identifier to find the corresponding ML-DSA private key and performs a quantum-resistant signature operation on the same data to be signed. The naming convention for the ML-DSA key container identifier can be independent of the SM2 container identifier, for example, "PQC_KEY_CONTAINER_01," so that the secure medium can distinguish between the two different types of key containers.

[0041] S3. After the user verifies and confirms the transaction via a one-time PIN code, the control security medium uses the preset SM2 private key and ML-DSA private key to sign the data to be signed, respectively, to obtain the SM2 signature and ML-DSA signature. This includes determining whether a user has verified and confirmed the transaction using a one-time PIN code, including: When the secure medium receives a call to the extended transaction signature interface, it prompts the user to enter a PIN code for verification. If the PIN code verification fails, or if the user does not perform a physical button confirmation operation based on the transaction key information displayed on the screen within a preset time after successful verification, the transaction is deemed to have failed the one-time verification and confirmation, and the signature process is terminated. If the PIN code verification succeeds, and the user performs a physical button confirmation operation based on the transaction key information displayed on the secure medium's screen, the transaction is deemed to have passed the one-time PIN code verification and confirmation. The specific implementation process is as follows: 1) When the secure medium receives an extended transaction signature interface call instruction from the client via the driver or Bluetooth channel, its internal security chip first parses the instruction, recognizing it as a dual-signature request requiring both the SM2 private key and the ML-DSA private key. The secure medium then enters a state awaiting user interaction. At this time, the secure medium sends a status signal to the connected PC or mobile device through its hardware interface, informing the client software that "the request has been received and is awaiting user verification." Upon receiving this signal, the client software displays a prompt on the computer or mobile phone screen, guiding the user to observe the secure medium's display and prepare to enter the PIN code.

[0042] 2) The secure medium displays a message such as "Please enter PIN code" on its screen. The user presses each digit of the PIN code onto the secure medium's built-in numeric keypad. The secure medium internally collects the key input values ​​in real time and temporarily stores these values ​​in the secure chip's temporary buffer. When the user finishes inputting, they usually press the confirmation key to indicate the end of the input, or the secure medium automatically determines the end based on a preset number of digits. The secure chip then compares the user-input value with the PIN code hash or encrypted value pre-stored in the secure medium's secure storage area. If they do not match, the secure medium immediately displays a "PIN code error" message on the screen and records one failed attempt. If the number of consecutive errors reaches the upper limit specified by the security policy, such as three times, the secure medium will automatically lock, no longer accepting any operations, and return the final result of PIN code verification failure to the upper-level application.

[0043] 3) If PIN code verification is successful, the secure medium extracts key transaction information from the data carried by the extended transaction signature interface call. This information may be contained in specific fields of the data to be signed, or it may be directly passed in through interface parameters. The secure medium organizes key data such as the transaction amount, payee account, and transaction serial number into an easily readable string according to a pre-defined display format and clearly displays it on its screen. For example, the first line of the screen displays "Amount: 1000.00 yuan", the second line displays the payee's identity information such as name and ID number, and the third line displays "Press OK to confirm". This display process aims to give the user the opportunity to ultimately verify whether the transaction content matches their expectations. Figure 1 The security medium simultaneously starts an internal timer with a preset timeout period, such as 30 seconds or 60 seconds, to wait for the user's next action.

[0044] 4) After carefully reviewing the key transaction information on the screen, the user makes a judgment based on the accuracy of the information. If the information is correct, the user actively presses the physical confirmation button on the secure medium, such as the button labeled "OK". The security chip detects the level change or interrupt signal of this button and records it as a confirmation event. If the user finds that the information displayed on the screen does not match the actual transaction, or if the user intends to cancel the transaction, they can press the physical cancel button, such as the button labeled "C" or "Cancel". The security chip also detects the press of the cancel button and immediately terminates the current signature process, returning an error code for the user's cancellation operation to the client.

[0045] 5) While displaying key transaction information on the screen, the internal timer of the secure medium continuously counts down. If, within the preset time, the secure medium does not detect either the pressing of the physical confirm button or the physical cancel button, the timer will time out. Upon the timeout, the secure medium automatically terminates the current signature process, clears the transaction data in the temporary cache, and returns an "Operation Timeout" error code to the client. Upon receiving the timeout error, the client software will notify the user that the transaction has expired and needs to be re-initiated. This timeout mechanism effectively prevents the secure medium from remaining in a waiting state for extended periods, ensuring the timely release of system resources.

[0046] 6) After the above steps, the secure medium finally obtains a clear user interaction result: either the PIN code verification is successful and the user confirms via physical key press, or the PIN code verification fails, or the user cancels, or a timeout occurs. If the result is successful PIN code verification and user confirmation via physical key press, the secure medium determines that the transaction has passed one-time verification and is confirmed. Subsequently, it automatically triggers the internal secure chip to execute the signature operation on the data to be signed using the SM2 private key and the ML-DSA private key. If the result is any other failure scenario, the secure medium determines that the transaction has not passed one-time verification and is not confirmed. It immediately terminates all subsequent signature calculation processes and returns the corresponding failure reason to the client. The client records this in the log and prompts the user that the transaction failed. The entire determination process is logically clear, ensuring that only transactions that have undergone dual user interaction verification can enter the final signature generation stage.

[0047] PIN code, short for Personal Identification Number, refers to a password that a user pre-sets on a secure medium to verify their identity. This password typically consists of 4 to 6 digits and is known only to the user. During the payment transaction signing process, the user enters the PIN code to prove to the secure medium that they are the rightful holder of the secure medium. PIN code verification is a necessary step before the secure medium performs the signing operation, preventing unauthorized personnel from impersonating the secure medium to confirm transactions.

[0048] The key transaction information displayed on the screen refers to the core elements of the transaction presented to the user on its built-in display after receiving a signature request. This information typically includes data that uniquely identifies a transaction, such as the transaction amount, recipient account number, and transaction serial number. The secure medium displays this information clearly and completely for the user to verify before pressing the confirmation button. This mechanism ensures that the transaction confirmed by the user is completely consistent with the transaction initiated by the client, preventing malicious software from tampering with transaction data.

[0049] Physical buttons are physical buttons on the secure medium for user interaction. Common physical buttons include confirmation buttons, cancel buttons, and directional buttons. In this embodiment of the invention, a physical button specifically refers to a button used by the user to explicitly confirm a transaction, such as the OK button or confirmation button on a USB key. After verifying that the key transaction information displayed on the screen is correct, the user presses this physical button to send a command to the secure medium agreeing to execute the current transaction. The pressing action of a physical button is an unforgeable hardware event, effectively resisting software-level simulation attacks.

[0050] Specifically, the control security medium uses a pre-set SM2 private key and ML-DSA private key to sign the data to be signed, obtaining the SM2 signature and ML-DSA signature, respectively. The specific implementation process is as follows: 1) After the user verifies the transaction via a one-time PIN code and confirms it by pressing a physical key, the security chip in the security medium transitions from a waiting state to a signature execution state. The security chip first reads the data to be signed, passed through the extended transaction signature interface, from the volatile temporary storage area, denoted as... . This is binary data constructed by the client, typically a digest value of key transaction information obtained through cryptographic hashing. The security chip simultaneously locates the corresponding key storage area in the non-volatile storage region based on the previously received SM2 key container identifier and ML-DSA key container identifier. The SM2 private key is then read from the SM2 key container. It is then loaded into the dedicated register of the security chip; the ML-DSA private key is read from the ML-DSA key container. And load it into another set of registers. It is a satisfaction integers, Elliptic curve base points used in the SM2 algorithm The rank. It is a secret data structure consisting of multiple vectors, specifically containing a seed and several secret vectors, used for signature generation in the ML-DSA algorithm.

[0051] 2) The security chip calls the internally embedded SM2 signature algorithm module, with the SM2 private key as the input parameter. and data to be signed The module first performs the following according to the SM2 standard: Process as integers Specifically, if If the length is less than 256 bits, then in Left-hand padding from zero to 256 bits; if If the length is greater than 256 bits, the cryptographic hash function SM3 is used first for calculation. The hash value is then converted into an integer. Next, the security chip generates a random integer using its internal true random number generator. ,satisfy Then calculate the points on the elliptic curve: ,in This represents scalar multiplication of elliptic curves, i.e., point... self-added Next. Points obtained. coordinate Next, the first component of the signature is calculated. : .

[0052] if or Then regenerate Then repeat the above calculation. If the condition is met, calculate the second component of the signature. : ,in express mold The multiplicative inverse. If Then it will be regenerated. And repeat the calculation. Finally, you get pairs of integers. This serves as the original value for the SM2 signature. The security chip encodes it according to the ASN.1DER encoding rules. Encapsulated into a byte sequence, the final SM2 signature is obtained. The entire calculation process is completed inside the secure chip, and all intermediate values ​​(such as...) are stored within the chip. , (etc.) are not exposed to the outside of the safety medium.

[0053] 3) After the SM2 signature is generated, the security chip immediately starts the ML-DSA signature algorithm module. This module takes the ML-DSA private key as input. and the same data to be signed The ML-DSA algorithm is based on the modular lattice problem, and its signature generation steps are as follows: From private key See the public matrix seed from the parsing and secret vector Security chips utilize Generate the public matrix using the extension function The matrix is ​​composed of It consists of a polynomial ring of elements, all of which are in the modulus. On the integer ring, where It is a preset modulus. Next, the security chip generates a random mask vector. Each of its components comes from a specific distribution Mid-sampling, Let be the standard deviation parameter. Calculate the commitment vector: ,here This represents the multiplication of a matrix and a vector, and the result is a... A dimensional vector. Then, the security chip treats the signature data. With promise Perform cryptographic hashing to obtain the challenge value. : Where Hash is a hash function that outputs a fixed-length bit string, such as SHAKE-256. This indicates the concatenation of byte strings. Challenge Value It is usually encoded as a short integer or polynomial.

[0054] Next, the response vector is calculated: , Represents scalar with vector Component-wise multiplication. After generating the response, it needs to be checked. Does the size of each component exceed a preset limit? If any component , If the conditions are not met, the security chip will abandon the generation process. and Then, start the sampling step again to ensure that the signature does not reveal private key information. Repeat this process until a result is generated. The constraints are met. Finally, the ML-DSA signature is generated by the challenge value. and response vector It also includes the prompt h, and sometimes also contains a promise. A certain compressed form. The security chip encodes these elements into a byte sequence according to the ML-DSA standard format to obtain the final ML-DSA signature. .

[0055] 4) The security chip was successfully generated. and Then, the two signature values ​​are stored in two separate output buffers. Simultaneously, the security chip reads the SM2 public key certificate and ML-DSA public key certificate from the corresponding key container, preparing to return these certificate data along with the signature values. To ensure the integrity of the returned data, the security chip optionally appends a message authentication code calculated by the chip's internal master key to the end of the data packet. All sensitive data, including the private key and random number... and intermediate variables , Once the signing is complete, the data is immediately cleared from the register, retaining only the final signature result and certificate data.

[0056] 5) The security chip, through its communication interface, such as a USB or Bluetooth module, outputs data from the buffer... , The corresponding public key certificate is packaged according to the agreed response format and sent to the upper-layer client software. After sending, the security chip completely clears all temporary storage areas, returns to an idle state, and waits for the next instruction. At this point, the entire process of "controlling the security medium to sign the data to be signed using the preset SM2 private key and ML-DSA private key respectively, to obtain the SM2 signature and ML-DSA signature" has been completed, and the two signature values ​​have been successfully generated and delivered to the client for subsequent encapsulation.

[0057] S4. Receive the SM2 signature and ML-DSA signature returned by the security medium, obtain the SM2 public key certificate from the security medium based on the SM2 key container identifier, obtain the ML-DSA public key certificate from the security medium based on the ML-DSA key container identifier, and encapsulate the SM2 signature, ML-DSA signature, and the obtained SM2 public key certificate and ML-DSA public key certificate into the same signature data packet. The signature data packet is in PKCS#7 format. The signer information field of the PKCS#7 format signature data packet contains two independent signer information structures corresponding to the SM2 signature item and the ML-DSA signature item, respectively. The SM2 signature item contains the SM2 signature, and the ML-DSA signature item contains the ML-DSA signature.

[0058] The specific implementation process of S4 is as follows: S40. After the user verifies the transaction via a one-time PIN code and confirms it by pressing a physical key, the secure medium internally performs signature operations on the data to be signed using the SM2 private key and the ML-DSA private key, generating the SM2 signature and the ML-DSA signature. The secure medium then packages these two signature values ​​according to the agreed response format and sends them to the client via its communication interface, such as USB or Bluetooth. Upon receiving the complete data packet, the client software parses the SM2 signature data block and the ML-DSA signature data block from the packet and temporarily stores them in memory variables. and These two variables will be used later to encapsulate the signed data packet. The client has already saved the SM2 key container identifier during previous calls. This identifier is a string or handle used to uniquely identify the container in the security medium that stores the SM2 key pair and its certificate. The client constructs a certificate retrieval command conforming to the security medium instruction set specification, passing the SM2 key container identifier as a parameter, and sends it to the security medium through the driver. After receiving the command, the security medium locates the corresponding storage area based on the container identifier, reads the pre-installed SM2 public key certificate, and returns the binary data of the certificate to the client. After receiving the data, the client parses it into an X.509 format certificate object, extracts necessary fields such as issuer, serial number, and public key information, and saves a complete binary copy of the certificate. .

[0059] S41. The client retrieves the ML-DSA public key certificate from the secure medium based on the ML-DSA key container identifier. The client also uses the previously saved ML-DSA key container identifier to construct another certificate retrieval command and sends it to the secure medium. The secure medium locates the ML-DSA key container based on the identifier, reads the ML-DSA public key certificate from it, and returns the certificate's binary data. The client receives, parses, and saves it as... At this point, the client has two signature values ​​and two public key certificates, ready for subsequent encapsulation. According to the PKCS#7 standard, the construction of the SignedData structure requires explicit version number, digest algorithm list, content type, etc. The client sets the version number to 3 to support multiple signers and certificate sets. Since the original data to be signed is already local to the client and may be sent with the request in subsequent transmissions, the client chooses to use detached signing mode, i.e., it does not embed the original content in the PKCS#7 packet, but instead sets the content type to id-data and leaves the content field empty. Simultaneously, the client determines the digest algorithm: for SM2 signatures, the SM3 digest algorithm is typically used, with OID 1.2.156.10197.1.401; for ML-DSA signatures, SHA-512 can be chosen according to the security policy, with OID 2.16.840.1.101.3.4.2.3, or the SM3 algorithm can be used. The client records the OIDs of these two digest algorithms in the digest algorithm set.

[0060] S42. The client constructs the PKCS#7 certificate set field. The certificate set is a collection type used to store all certificates related to the signature. The client then uses the SM2 public key certificate binary data obtained in step two. And the binary data of the ML-DSA public key certificate obtained in step three. The certificates are sequentially added to the certificate set. Each certificate must maintain its original DER encoding format when added. The certificate set will ultimately be a component of the SignedData structure. The client creates a new SignerInfo structure object. First, the version number is set to 1. Then, the DER encoding of the issuer name and the serial number are extracted from the SM2 public key certificate and combined into the issuerAndSerialNumber field. Next, the digestAlgorithm field is set, filled with the OID of the SM3 algorithm, i.e., 1.2.156.10197.1.401. The digestEncryptionAlgorithm field is set, filled with the OID of the SM2 signature algorithm, which is 1.2.156.10197.1.301,1 as defined by the State Cryptography Administration, and the parameters field is set to NULL. According to the PKCS#7 standard, the rules for determining the signature primitive are as follows: if the signer information structure contains an authenticatedAttributes field, the signature primitive is the ASN.1DER encoded value of that field; if the authenticatedAttributes field does not exist, the signature primitive is the content of the contentInfo field in the SignedData structure. The client chooses not to use authentication attributes, therefore the authenticatedAttributes field is omitted. Finally, the SM2 signature value saved in the first step is... Fill in the encryptedDigest field. After the signer information structure is encoded, temporarily save it as... .

[0061] The client creates another signer information structure object, also with version number 1. It extracts the issuer and serial number from the ML-DSA public key certificate and populates them into issuerAndSerialNumber. The `digestAlgorithm` field is filled with the OID of the digest algorithm used, and the `digestEncryptionAlgorithm` field is filled with the custom OID of the ML-DSA signature algorithm. This OID is predefined by the banking system and registered on the server. For example, the OID of the ML_DSA_44_SHA512 signature algorithm is 2.16.840.1.101.3.4.3.32, and the digest algorithm is SHA512 (2.16.840.1.101.3.4.2.3); the OID of the ML_DSA_65_SHA512 signature algorithm is 2.16.840.1.101.3.4.3.33, and the digest algorithm is SHA512 (2.16.840.1.101.3.4.2.3); the OID of the ML_DSA_87_SHA512 signature algorithm is... D is 2.16.840.1.101.3.4.3.34, the hash algorithm is SHA512 (2.16.840.1.101.3.4.2.3), the OID of the ML_DSA_44_SM3 signature algorithm is 1.3.6.1.4.1.46210.1.905.1, the hash algorithm is SM3 (1.2.156.10197.1.401), ML_DSA_6 The OID of the 5_SM3 signature algorithm is 1.3.6.1.4.1.46210.1.905.2, and the digest algorithm is SM3 (1.2.156.10197.1.401). The OID of the ML_DSA_87_SM3 signature algorithm is 1.3.6.1.4.1.46210.1.905.3, and the digest algorithm is SM3 (1.2.156.10197.1.401). The parameters field is set to NULL. Similarly, according to the PKCS#7 standard, the rules for determining the signature text are consistent with those for the SM2 signature item; that is, if authenticatedAttributes exist, their encoded values ​​are used; otherwise, the content in contentInfo is used. In this embodiment of the invention, the client also does not use authentication attributes. The ML-DSA signature value... Enter the encryptedDigest field. Save the encoded data temporarily. .

[0062] The client creates a collection object, which will... and The signature information field is formed by sequentially adding these elements to the set. Next, the client constructs a `SignedData` structure, filling in version number 1. The digest algorithm set includes SM3 and SHA-512 OIDs. The content information field is of type `id-data` and empty. The signature information set is then filled with the newly constructed set. The client can also choose to add other information such as CRL, but this is not necessary in this scheme. Finally, the client serializes the entire `SignedData` structure according to the ASN.1DER encoding rule to obtain the final binary data packet of the signed data packet. .

[0063] To ensure the packaging process is error-free, the client may optionally modify the generated... Perform a local parsing test to confirm that the two signer information structures and certificates can be correctly extracted. If the test passes, the client will... Saved as a data block to be sent. At this point, the entire process of receiving the signature value, obtaining the certificate, and encapsulating it into the same PKCS#7 signature data packet is complete. The client is now ready to send the signature data packet to the server for further verification.

[0064] Signer Information Field: The signer information field is a core data structure field in the PKCS#7 format signature data packet, specifically referring to the signerInfos field in the SignedData structure. This field is a collection type used to hold one or more signer information structures. In a dual-signature payment scheme, the signer information field is designed to contain two independent signer information structures, corresponding to the SM2 signature and the ML-DSA signature respectively. During signature verification, the server can iterate through each signer information structure in the signer information field to verify the signature value of each signer one by one, thereby achieving item-by-item verification of the dual signature.

[0065] Signer Information Structure: The signer information structure is a data structure defined in the PKCS#7 standard used to describe detailed information about a signer. This structure typically includes fields such as version number, issuer and serial number of the signer's certificate, digest algorithm identifier, signature algorithm identifier, optional authentication attributes, and signature value. In dual-signature payment schemes, the client creates separate signer information structures for SM2 signatures and ML-DSA signatures. Each signer information structure is associated with the corresponding signing certificate through its certificate identifier field, specifies the type of signature algorithm used through its signature algorithm identifier field, and carries the specific signature value through its cryptographic digest field. During signature verification, the server can obtain all the necessary elements by parsing the signer information structure.

[0066] S5. Send the signed data packet to the server so that the server can parse the signed data packet, verify the SM2 signature and ML-DSA signature in the signed data packet respectively, and return a structured response object containing the verification result code corresponding to each signature item. Specifically: The server calls the dual-signature verification interface to parse the signed data packet to obtain the original text and the SM2 and ML-DSA signatures. It then calls the corresponding verification logic to verify the SM2 and ML-DSA signatures respectively, and assembles a structured response object based on the verification result of each signature. The specific implementation process is as follows: After receiving a payment transaction request from the client, the S50 online banking server parses the transaction-related parameters from the HTTP or HTTPS request body. The key parameter is the client-encapsulated signature data packet, which is binary data in PKCS#7 format, denoted as […]. Simultaneously, the server extracts the original transaction message from the request. This message has already been used on the client to generate the data to be signed, denoted as... . This is the original text information required for signature verification. The server will... and As input parameters, prepare to call the dual-signature value verification interface.

[0067] S51, the server-side business layer will use internal service calls or API requests to... and The signature is passed to the dual-signature verification interface provided by the encryption service platform. The programming interface name of this interface is verifyMixSignedMessage. When called, the interface receives two parameters: the first parameter is an array of bytes representing the signature data packet. The second parameter is the original byte array. The interface returns a structured response object containing a list of validation results and other relevant information.

[0068] S52, First of all ASN.1DER decoding is performed to reconstruct the SignedData structure of PKCS#7. The version number, digest algorithm set, certificate set, and signer information field are extracted from SignedData. The signer information field is a set containing two signer information structures. The interface iterates through the signer information field, processing each signer information structure sequentially. For each signer information structure, the following fields are parsed: issuerAndSerialNumber (issuer and serial number), digestAlgorithm (digest algorithm identifier), digestEncryptionAlgorithm (signature algorithm identifier), and encryptedDigest (signature value). Based on the value of the signature algorithm identifier field, the interface can distinguish whether the current signer is performing an SM2 signature or an ML-DSA signature. If the OID of the signature algorithm identifier is an SM2 signature algorithm OID, it is determined to be an SM2 signature; if it is an ML-DSA signature algorithm OID, it is determined to be an ML-DSA signature. Simultaneously, the interface searches the certificate set for an X.509 certificate matching issuerAndSerialNumber to obtain the corresponding public key. For SM2 signatures, the SM2 public key is obtained. For ML-DSA signature entries, obtain the ML-DSA public key. .

[0069] S53. According to the PKCS#7 standard, the original text protected by the signature may come from two sources: if the signer information structure contains an authenticatedAttributes field, the object of the signature is the DER encoding of these authentication attributes; if it does not contain an authenticatedAttributes field, the object of the signature is the content in contentInfo. In this embodiment of the invention, the client does not use authentication attributes during encapsulation, therefore the signature object is the content in contentInfo. However, due to the use of detached signature mode, the content field in contentInfo is empty, and the actual original text is passed in from the outside. Provided. The interface will As the original signature data, denoted as .

[0070] S54. Based on the signature algorithm identifier, select the SM2 signature verification logic module. The signature verification process of this module is as follows: First, the original text... Process into integers according to the requirements of the SM2 algorithm. .like If the length is less than 256 bits, padding to 256 bits is used; if the length is greater than 256 bits, the SM3 hash function is used for calculation. hash value and will Convert to integer Then, from the SM2 signature value Extracting integer components from the data and These two components are ASN.1DER encoded. Verification and Is it within the range? Inside, among which Base point of SM2 elliptic curve The order of the sign. If it is not within the range, the verification fails. Calculation: ,if Verification failed. Calculate the elliptic curve points: ,in, Indicates the base point of Double point, Public key of The doubling of points, addition, is the point addition operation for elliptic curves. It yields the points. coordinate .calculate: ,if If the verification result is positive, the signature verification is successful; otherwise, the signature verification fails. The signature verification logic module returns a boolean value indicating the verification result. ,in This indicates success. This indicates failure.

[0071] S55. Based on the signature algorithm identifier, select the ML-DSA signature verification logic module. The signature verification process of this module is as follows: from the ML-DSA signature value... The challenge value was analyzed. and response vector At the same time from the public key The public matrix is ​​parsed from the middle. And other parameters. First, verify according to the signature algorithm specification. Whether the size of each component is within the allowable range; if any component exceeds the limit. If not, the signature verification fails. Then, the commitment vector is recalculated: Where h is a prompt, From public key, The modulus is used. The calculation yields... Afterwards, regarding the original text and Perform hash calculation: ,if If the verification result is positive, the signature verification is successful; otherwise, the signature verification fails. The signature verification logic module returns a boolean value indicating the verification result. .

[0072] S56, the dual-signature verification interface creates a structured response object containing a list field `verifyItems`. Each element in the list corresponds to a verification result item from the signer. The interface first creates a verification item object, corresponding to the SM2 signature verification result. This object contains the following properties: `certAlgoType` is set to "SM2"; `resultCode` is based on... The settings are as follows: 0 for success, and the corresponding error code for failure; the message is filled with description information based on the resultCode; simultaneously, the SM2 public key certificate information obtained from the certificate set is filled in, including the certificate's Base64 encoding b64Cert, serial number serialNumber, subject DN subjectDn, issuer DN issuerDn, validity period start and end times validFrom and validTo. The interface adds the first verification item object to the verifyItems list. Then, the interface creates the second verification item object, corresponding to the ML-DSA signature verification result. certAlgoType is set to "ML-DSA"; the resultCode is filled with description information based on the resultCode. Set up the message; populate the corresponding description; also fill in the same information for the ML-DSA public key certificate. Add the second verification item object to the verifyItems list. Finally, encapsulate the verifyItems list into a structured response object, which may also include other global information such as processing timestamps, request IDs, etc. After assembly, the dual-signature verification interface returns this structured response object to the server caller.

[0073] S57. After receiving the structured response object, the server-side business layer can perform subsequent business logic judgments based on the verification result codes in the verifyItems list, such as executing or rejecting the transaction and recording audit logs. At this point, the entire process of "causing the server to call the dual-signature verification interface, parsing the signature data packet to obtain the original text and the SM2 signature and ML-DSA signature, calling the corresponding verification logic to verify the SM2 signature and ML-DSA signature respectively, and assembling the structured response object based on the verification result of each signature" is completed.

[0074] The signature verification logic refers to a set of verification procedures implemented for a specific signature algorithm, used to verify whether a given signature value has been signed by the corresponding private key and whether the data has been tampered with. In this embodiment of the invention, the corresponding signature verification logic includes two parts: SM2 signature verification logic and ML-DSA signature verification logic. The SM2 signature verification logic is based on the SM2 elliptic curve public key cryptography algorithm standard issued by the State Cryptography Administration. It takes an SM2 public key, the plaintext to be signed, and an SM2 signature value as input, and outputs a result indicating successful or failed verification. The ML-DSA signature verification logic is based on the Modular Digital Signature Algorithm standard. It takes an ML-DSA public key, the plaintext to be signed, and an ML-DSA signature value as input, and outputs a verification result. Within the dual-signature verification interface, the server dynamically selects and calls the corresponding signature verification logic module to complete the verification based on the algorithm type identified in the signer information structure.

[0075] The dual-signature verification interface is an application programming interface (API) provided by the server-side encryption service platform. It is specifically designed to verify PKCS#7 format signature data packets submitted by clients, containing both SM2 and ML-DSA signatures. The interface's input parameters include the binary data of the signature data packet and the binary data of the original transaction message. The output is a structured response object. Internally, the interface parses the PKCS#7 packet, extracts the two signature values ​​and their corresponding certificates, calls the SM2 and ML-DSA verification logic respectively for verification, and encapsulates the verification result of each signature along with the certificate information into an independent verification item. Finally, all verification items are combined into a list and returned. This interface design allows upper-layer business systems to avoid the complexity of the underlying multi-algorithm verification process and only need to make business judgments based on the returned structured results.

[0076] S6. Receive the structured response object. If both the SM2 verification item and the ML-DSA verification item in the structured response object have successful verification results, then execute the payment transaction. The specific implementation process is as follows: In the online banking server-side business logic, payment transaction requests submitted by the client are forwarded to the business processing module after pre-processing. The business processing module constructs a request containing a signed data packet and the original transaction message, and calls the `verifyMixSignedMessage` interface of the encryption service platform, i.e., the dual-signature verification interface. After verification, this interface returns the result as a structured response object. The business processing module receives this object synchronously and assigns it to a local variable, denoted as . . It is an in-memory data structure containing a list field named verifyItems. This object contains a resultCode property that can be used to quickly determine globally whether all signatures have passed. The status code for all successful signatures is the string 200.

[0077] The business processing module retrieves the list of verification items by accessing the `verifyItems` property of the `CryptoVerifySignedMessageResponse` object. This list exists in memory as an array or collection. Since the dual-signature verification interface guarantees that the returned list contains at least two verification items, corresponding to the SM2 signature and the ML-DSA signature respectively, the business processing module can expect the list length to be at least 2. The business processing module can access the list directly based on the list index or find the verification items for a specific algorithm by traversing the list.

[0078] Business processing module traversal Each element in the list is an object `CryptoVerifySignedItemResponse`, containing the following fields: `private String b64Cert`, `private String certAlias`, `private String serialNumber`, `private String subjectDn`, `private String issuerDn`, `private Long validFrom`, `private Long validTo`, and `private String certAlgoType`. For each element, the value of its `certAlgoType` field is read. If the field value is the string "SM2", the element is marked as an SM2 validation item. If the field value is the string "ML-DSA-44 / 65 / 87", the element is marked as an ML-DSA validation item. To ensure completeness, the business processing module should check whether these two verification items have been successfully found. If either one is missing, the verification process is considered abnormal and should be transferred to the exception handling process (e.g., reject the transaction and log it).

[0079] from Read the value of the resultCode field in the middle, and denote it as .from Read the value of the resultCode field in the middle, and denote it as According to the system's preset success result code definition, the success value is usually an integer of 200. The processing module will... and Compare with 200 respectively.

[0080] The business processing module executes the following logical judgment: If and If both conditions are met, it means that both SM2 signature verification and ML-DSA signature verification have passed, and the dual signatures are valid overall. If either condition is not met, the transaction will proceed to the transaction rejection branch, and an audit log will be recorded based on the message field in the failure item to distinguish whether the failure was due to SM2 verification or ML-DSA verification.

[0081] After confirming that both signature verifications were successful, the business processing module then... Extract the subjectDn field of the certificate subject from... Similarly, the `subjectDn` is extracted. Simultaneously, the business processing module retrieves the payer's account information from the current transaction context, such as the account number or customer identifier. The business processing module calls the certificate parsing function to extract information uniquely identifying the user from `subjectDn`, such as the ID number or customer ID in the generic name field. This information is then compared with the payer's account information in the transaction context. If they match, it confirms that the transaction was indeed initiated by the certificate holder; if they do not match, it is considered a certificate-account mismatch, and the process is transferred to the exception handling procedure and recorded in the security audit log.

[0082] After all the above verification steps are successful, the business processing module constructs a payment instruction and calls the transfer interface of the bank's core accounting system. This interface receives core elements such as the transaction amount, payee's account, and payer's account, and executes the actual fund transfer operation. Upon successful call, the core system returns a successful transfer result, including the transaction serial number and processing time.

[0083] The business processing module writes complete transaction information, including transaction serial number, transaction time, amount, payee, and detailed information for the two signature verification items (certificate serial number, verification result code, etc.), into the transaction log database for subsequent auditing and reconciliation. Finally, the business processing module returns a payment success HTTP response to the client, notifying the user that the transaction is complete. At this point, the entire process of "receiving a structured response object; if the verification result codes for both the SM2 and ML-DSA verification items in the structured response object are successful, then executing the payment transaction" is complete.

[0084] The SM2 verification item is a specific entry in the structured response object returned by the dual-signature value verification interface, which describes the verification result of the SM2 signature. This entry contains multiple fields, primarily including: the `certAlgoType` field, which identifies the algorithm corresponding to the verification item and whose value is fixed as SM2; the `resultCode` field, which stores the result code of the SM2 signature verification, typically 0 indicating successful verification, and non-zero values ​​corresponding to specific error types; the `message` field, which provides a readable description of the result code; and detailed information about the SM2 public key certificate used by the signature item, including the certificate's Base64 encoding (`b64Cert` field, which stores the Base64 encoding format of the certificate for reconstructing the complete certificate content); the `serialNumber` field, which stores the certificate's serial number, uniquely identifying a certificate within a certificate authority; the `subjectDn` field, which stores the certificate's distinguished name, used to identify the signer's identity; the `issuerDn` field, which stores the certificate's distinguished name, used to identify the certificate authority that issued the certificate; and the `validFrom` and `validTo` fields, which represent the start and end times of the certificate's validity period, used to determine whether the certificate is valid at the current transaction time. By parsing the SM2 verification item, the server-side business system can accurately understand the verification status of the SM2 signature and the associated certificate information.

[0085] The ML-DSA verification item is another specific entry in the structured response object returned by the dual-signature verification interface, used to describe the verification result of the ML-DSA signature. This entry also includes a `certAlgoType` field, whose value is fixed as ML-DSA; a `resultCode` field storing the ML-DSA signature verification result code; a `message` field providing corresponding descriptive information; and detailed information about the ML-DSA public key certificate used by this signature item. The field definitions are consistent with the certificate information in the SM2 verification item, including `b64Cert` (certificate Base64 encoding), `serialNumber` (certificate serial number), `subjectDn` (subject DN), `issuerDn` (issuer DN), `validFrom` (validity start time), and `validTo` (validity end time). The existence of the ML-DSA verification item enables the business system to independently evaluate the verification result of quantum-resistant signatures, providing fine-grained data for security monitoring during the post-quantum migration transition.

[0086] Optionally, the above technical solution also includes: S7. If either the SM2 verification item or the ML-DSA verification item in the structured response object fails, the payment transaction will be rejected. The corresponding audit log will be recorded based on the error description in the failed verification item to distinguish between SM2 signature verification failure and ML-DSA signature verification failure. The specific implementation process is as follows: S70. In the online banking server-side business processing module, after calling the dual-signature value verification interface verifyMixSignedMessage, the returned structured response object is obtained. The business processing module assigns this object to a variable. Subsequently, through access The verifyItems property retrieves the list of verification items, denoted as . It is an array or collection in memory whose elements are instances of SM2 and ML-DSA verification items.

[0087] Traversal For each element, read the value of its certAlgoType field. If the field value is the string "SM2", then record that element as an SM2 verification item. If the field value is "ML-DSA", then the record is an ML-DSA validation item, denoted as... After the traversal is complete, the business processing module checks whether it has found the correct method. and If any one of these is missing, it is considered a structural error in the verification process. In this case, the transaction should be rejected directly, and a special audit log entry should be recorded stating "The verification items returned by the dual signature verification are incomplete." Then, the transaction rejection processing steps should be executed.

[0088] S71, Business Processing Module Read the value of the resultCode field in the middle, and denote it as .from Read the value of the resultCode field in the middle, and denote it as Simultaneously, the value of the message field is read from each validation item and recorded as follows: and This is for use in subsequent log recording.

[0089] S72. Business processing module execution condition judgment: If or If either of the failure conditions is met, the transaction is transferred to the transaction rejection branch. If both verification result codes are 0, the transaction should be transferred to the transaction execution branch. However, this technical solution describes the failure case, so it is assumed here that at least one is not 0.

[0090] The business processing module checks respectively and The value of the verification result code is used to determine if the verification result code is not zero. There are three possible scenarios: only the SM2 verification item fails, only the ML-DSA verification item fails, or both fail. For each failed item, the business processing module needs to extract complete information from that verification item, including certAlgoType, resultCode, message, and certificate information fields (b64Cert, serialNumber, subjectDn, issuerDn, validFrom, validTo). This information will be used to construct a detailed audit log.

[0091] S73. The business processing module creates an audit log object containing the following fields: log timestamp (current system time); transaction serial number (obtained from the current transaction context); user identifier (obtained from the session); operation type: "payment transaction"; event type: "signature verification failed". For each failed verification item, the log records its algorithm type, result code, error description, and certificate serial number. For successfully verified items, a verification result code of 0 can also be recorded, but it is not mandatory. After formatting, the audit log object is written to a persistent storage system, such as a database or a dedicated log file system, through the log service interface. After successful writing, the log is available for subsequent auditing and analysis.

[0092] S74. The business processing module calls the transaction control component to mark the current transaction status as "failed" and ensures that no transfer request is sent to the core accounting system. Subsequently, the business processing module constructs a response to the client, typically including an HTTP status code 200 (indicating the request has been processed) and a JSON response body containing a transaction result code such as "FAILURE" and optional error messages, such as "Transaction signature verification failed, please try again later." To avoid revealing too many security details, the error message usually does not distinguish which specific algorithm failed, but internal audit logs record it in detail.

[0093] After the transaction processing flow ends, the business processing module releases relevant resources, clears temporary variables, and returns control to the upper-layer calling framework. Throughout the process, the payment transaction is not executed, and the detailed reasons for the failure are accurately recorded in the audit logs. This achieves the technical effect of "distinguishing between SM2 signature verification failure and ML-DSA signature verification failure," providing data support for subsequent security monitoring and troubleshooting.

[0094] The structured response object is a data encapsulation returned to the caller by the dual-signature verification interface after signature verification. This object is organized in a predefined format and typically contains a list field named `verifyItems`, where each element corresponds to a signer's verification result. Additionally, the structured response object may contain metadata such as request identifiers and processing timestamps. By parsing this object, the caller can obtain detailed status information for each signature verification, rather than just a simple pass or fail result.

[0095] The verification result code is an integer field in the verification item, used to represent the specific result of the corresponding signature verification operation. The system predefines a set of result code values, where 0 indicates successful verification, and non-zero values ​​correspond to various error types, such as 1 indicating that the certificate has expired, 2 indicating that the signature value does not match, 3 indicating that the certificate chain is untrusted, and 4 indicating that the algorithm is not supported, etc. The business system can quickly determine whether the signature verification passed or failed and the specific reason for failure by checking the verification result code.

[0096] The error description is a string field in the verification item that provides a readable explanation of the verification result code. This description is typically presented in human-readable language, such as "SM2 signature verification failed: certificate expired" or "ML-DSA signature verification failed: invalid signature value." The error description is primarily used for logging, displaying user-friendly error messages when necessary, and assisting technical personnel in troubleshooting.

[0097] Audit logs are a persistent storage mechanism in bank information systems used to record security-related events. Audit logs typically include fields such as timestamp, transaction serial number, user identifier, operation type, and verification result details (e.g., algorithm type, result code, error description, certificate serial number). Once written, audit logs are immutable and are used to meet compliance requirements, support post-event auditing, trace security incidents, and monitor system operation.

[0098] Example 1: Corporate online banking PC-based transfer transaction (based on SKF extension interface): like Figure 2 As shown, this embodiment demonstrates the complete process of quantum-resistant secure transfers via a user's secure medium (i.e., USBKey) in a PC browser environment. Specifically, it includes the following steps: S101. The user initiates a transfer operation on the corporate online banking interface (i.e., " Figure 2In the "Start: User Initiates Transfer" section, the front-end JavaScript code extracts key information such as the transfer amount, recipient's account, payer's account, transaction serial number, and transaction time from the interface input fields according to the transaction message format defined by the bank's backend. This information is then concatenated into a continuous byte sequence according to an agreed-upon order and encoding rules. To ensure the security and efficiency of the signing process, the client calls a cryptographic hash function on this byte sequence, such as using the SM3 algorithm to calculate a 256-bit hash value, or using the SHA-512 algorithm to calculate a 512-bit hash value. This hash value is then Base64 encoded into a printable string format, which serves as the data to be signed (i.e.,...). Figure 2 The final form of the text "b64SrcData" in the code. The front-end JavaScript code constructs a signature parameter object, which is called the call parameter object of the extended transaction signature interface. This object contains the following properties: the first property is the SM2 key container identifier (i.e.,...). Figure 2 The "dual-signature handle" is a component of the key container, whose value points to the name of the pre-stored SM2 key container in the user's security media, such as "SM2_KEY_CONTAINER_01"; the second attribute is the ML-DSA key container identifier (i.e., Figure 2 The "double signer handle" is a component of the ML-DSA key container, whose value points to the name of the ML-DSA key container pre-stored in the user's secure medium, such as "PQC_KEY_CONTAINER_01"; the third attribute is the post-quantum digest algorithm identifier (i.e., ulPQHashAlg), used to specify the digest algorithm used for ML-DSA signing, which can be set to an enumerated constant of SM3 or SHA-512; the fourth attribute is the data to be signed (i.e., Figure 2 The value of “b64SrcData” is the Base64 encoded string generated in the first step.

[0099] S102, The front-end JavaScript code calls the newly added transaction signature function (i.e. Figure 2 The "Transaction Signature Interface PQECCDigestSignData" is called by passing the handle of the dual signer (i.e., Figure 2The signature requires the SM2 key container identifier and ML-DSA key container identifier (corresponding to the "dual signer handle"), as well as the data to be signed. The specific implementation is `PQECCDigestSignData(digestSignParams, callback)`. Here, `digestSignParams` is the parameter object constructed in the previous step, and `callback` is the callback function used to handle asynchronous return results. Internally, this function forwards the request to the browser's signature control. Upon receiving the call, the signature control first performs a validity check on the passed parameter object, including checking whether the SM2 key container identifier and ML-DSA key container identifier are non-empty strings with correct format, and checking whether the Base64 encoding of the data to be signed is valid. If the checks pass, execution continues; otherwise, an error code is immediately returned via the callback function.

[0100] S103. The signature control calls the underlying hardware extension interface SKFE_PQECCDigestSignData (i.e., ...) through the SKF driver layer. Figure 2 The command in the document "Calling the SKF extended interface SKFE_PQECCDigestSignData" takes the SM2 key container identifier, ML-DSA key container identifier, post-quantum digest algorithm identifier, and the data to be signed as input parameters, and specifies a buffer for receiving the returned data. Upon receiving the command, the secure medium (i.e., the USBKey) parses the command using its internal security chip, recognizing that both the SM2 private key and the ML-DSA private key are required for signing. The secure medium then enters a state awaiting user interaction and sends a status signal to the connected PC via its hardware interface, informing the client software that "the request has been received and is awaiting user verification." The client software displays a prompt on the computer screen, guiding the user to observe the secure medium's display and prepare to enter the PIN code. The secure medium displays "Please enter PIN code" or a similar prompt on its screen. The user presses each digit of the PIN code onto the secure medium's built-in numeric keypad. The secure medium internally collects the key input values ​​in real time and temporarily stores these values ​​in the security chip's temporary buffer. After the user completes input, the security chip compares and verifies the entered value with the PIN code hash value pre-stored in the secure storage area of ​​the secure medium. This process corresponds to... Figure 2The system displays the "PIN code permission status". If the two do not match, the security medium immediately displays a "PIN code error" message on the screen and records the number of incorrect attempts. If the number of consecutive incorrect attempts reaches the upper limit specified by the security policy, the security medium automatically locks and returns a PIN code verification failure result to the upper-layer application. If the PIN code verification is successful, the security medium extracts key transaction information from the data carried by the extended transaction signature interface call, such as transaction amount, payee account, and transaction serial number. The security medium displays this information according to a pre-defined display format. Figure 2 The "Screen Display of Transaction Information (Amount / Account)" is clearly displayed on the screen for user verification. Simultaneously, the secure medium starts an internal timer with a preset timeout period, such as 30 or 60 seconds, to await the user's next action. After carefully reviewing the key transaction information on the screen, the user makes a judgment based on the accuracy of the information. The secure medium is currently in [a state of readiness]. Figure 2 The system is in the "Waiting for User Physical Key Press" state. If the information is correct, the user actively presses the physical confirmation button (OK button) on the secure medium. The secure chip detects this button press event and records it as a confirmation operation. If the user finds that the information displayed on the screen does not match the actual transaction, or if the user intends to cancel the transaction, they can press the physical cancel button. The secure chip detects the cancel button and immediately terminates the signature process, returning an error code indicating user cancellation to the client. If the secure medium does not detect either the confirmation or cancel button within a preset time, the timer expires, the secure medium automatically terminates the signature process, and returns an "Operation Timeout" error code to the client. If the result is that the PIN code verification is successful and the user confirms with a physical key press, the secure medium determines that the transaction has passed one-time verification and is confirmed. Subsequently, it automatically triggers the internal secure chip to perform signature calculations and enters the next stage. Figure 2 The atomic computation stage in the process. The security chip reads the data to be signed from the temporary buffer, denoted as... Simultaneously, based on the SM2 key container identifier and the ML-DSA key container identifier, the corresponding key storage area is located, and the SM2 private key is loaded. and ML-DSA private key The security chip calls the internally embedded SM2 signature algorithm module and inputs... and The process of generating an SM2 signature includes: Process as integers Generate random integers satisfy ( Base point of SM2 elliptic curve (order of elliptic curve) , calculate the points of the elliptic curve ,calculate ,calculate Finally, we get pairs of integers. And encapsulated into an SM2 signature according to ASN.1DER encoding. The security chip calls its internally embedded ML-DSA signature algorithm module and inputs... and Generate an ML-DSA signature, i.e. Figure 2 The phrase "generating Sig_PQC using an ML-DSA private key" refers to this process. During generation, the secure chip uses the input post-quantum digest algorithm identifier to calculate the challenge value using a specified hash algorithm (e.g., SHA-512). Specifically, this process includes calculating the response vector. , Represents scalar with vector Component-wise multiplication. After generating the response, it needs to be checked. Does the size of each component exceed a preset limit? If any component , If the conditions are not met, the security chip will abandon the generation process. and Then, start the sampling step again to ensure that the signature does not reveal private key information. Repeat this process until a result is generated. The constraints are met. Ultimately, it will... h and Encoded as ML-DSA signature The security chip will generate and The signatures are stored separately in the output buffer, and the SM2 public key certificate and ML-DSA public key certificate are read from the corresponding key container. The security chip packages these two signature values ​​and the corresponding public key certificates according to the agreed response format through its communication interface (such as USB) and sends them to the browser's signature control (i.e., ...). Figure 2 The text in the message reads "Returns two signature values ​​(optionally, the corresponding certificate)". After sending, the security chip clears all temporary data and returns to an idle state.

[0101] S104. The browser signature control receives the SM2 signature returned by the user's secure medium. and ML-DSA signature These are temporarily stored in memory variables. The control sends a certificate retrieval command to the user's security medium based on the SM2 key container identifier. The security medium returns the SM2 public key certificate binary data, which the control saves as... Similarly, obtain the ML-DSA public key certificate based on the ML-DSA key container identifier and save it as... The control constructs a signed data packet according to the PKCS#7 standard. First, the version number is determined to be 3, using detached signing mode, and the content type is set to id-data, with the content field empty. The digest algorithm set includes SM3 and SHA-512 OIDs. The control constructs the certificate set field, and... and Place them sequentially. The control constructs the signer information structure corresponding to the SM2 signature. Set the version number to 1, extract the issuer name's DER encoding and serial number from the SM2 public key certificate and fill them into the issuerAndSerialNumber field, fill the digestAlgorithm field with the OID of the SM3 algorithm, fill the digestEncryptionAlgorithm field with the OID of the SM2 signature algorithm (1.2.156.10197.1.501) and leave the parameters empty, excluding the authenticatedAttributes field, and fill the encryptedDigest field with... According to the PKCS#7 standard, since authenticatedAttributes are absent, the signature plaintext points to the content in contentInfo. However, in detached signature mode, contentInfo is empty, and the actual plaintext will be passed in by the server through other parameters. This signer information structure is encoded and temporarily stored. The control constructs the signer information structure corresponding to the ML-DSA signature. Similarly, the digestAlgorithm field is filled with the OID of the digest algorithm used (e.g., SHA-512), the digestEncryptionAlgorithm field is filled with the custom OID of the ML-DSA signature algorithm (e.g., 1.3.6.1.4.1.99999.1.1) and the parameters are empty, and the encryptedDigest field is filled with... It also does not include authentication attributes. The control adds the two signer information structures to the signer information field, forming the signerInfos collection, i.e. Figure 2 The process involves encapsulating "PKCS#7SignedData (signerInfos contains 2 SignerInfos)". Then, a complete SignedData structure is constructed, including the version number, digest algorithm set, content information, certificate set, and signer information set. Finally, the entire SignedData is serialized according to ASN.1DER encoding to obtain the final signed data packet binary data, denoted as... The control then sends the encapsulated, signed data packet to the server.

[0102] S105. The online banking backend receives a payment transaction request initiated by the client and parses the signature data packet from the request body. and the original transaction message The online banking backend calls the dual-signature verification interface of the encryption service platform (i.e., ...) via API. Figure 2 (The "call verifyMixSignedMessage" function in the code). When calling it, pass in... and As a parameter. First, for Decode the ASN.1DER to reconstruct the SignedData structure and extract the certificate set and signer information fields. Iterate through each signer information structure in the signer information field, parsing the issuerAndSerialNumber, digestAlgorithm, digestEncryptionAlgorithm, and encryptedDigest fields. Distinguish the signature type based on the OID of digestEncryptionAlgorithm: if it's an SM2 signature algorithm OID, it's an SM2 signature; if it's an ML-DSA signature algorithm OID, it's an ML-DSA signature. Simultaneously, search the certificate set for the certificate matching issuerAndSerialNumber and obtain the corresponding public key. Since the signer information structure does not contain authentication attributes, the original signature text is the content of contentInfo. However, since a split signature mode is used here, contentInfo is empty; therefore, the externally passed-in key is used. As the original text of the signature, it is recorded as follows: The corresponding signature verification logic is invoked to verify the SM2 signature. The interface selects the SM2 signature verification logic module, and the SM2 public key is entered. ,original and signature value The verification process includes: Process as integers Parsing from the signature and ,verify and In the interval Inside, calculation ,like If it fails, otherwise calculate the elliptic curve points. ,get ,calculate ,like If the verification is successful, then the verification is successful; otherwise, it fails. The verification result is recorded as follows: The corresponding signature verification logic is invoked to verify the ML-DSA signature. The interface selects the ML-DSA signature verification logic module, and the ML-DSA public key is input. ,original and signature value The signature verification process includes: from the ML-DSA signature value The challenge value was analyzed. and response vector At the same time from the public key The public matrix is ​​parsed from the middle. And other parameters. First, verify according to the signature algorithm specification. Whether the size of each component is within the allowable range; if any component exceeds the limit. If not, the signature verification fails. Then, the commitment vector is recalculated: Where h is a prompt, Derived from public key, The modulus is used. The calculation yields... Afterwards, regarding the original text and Perform hash calculation: ,if If the result is positive, the visa verification is successful; otherwise, the verification fails. The verification result is recorded as follows: The dual-signature verification interface creates a structured response object containing a list field `verifyItems`. First, it creates a verification item corresponding to the SM2 signature, setting `certAlgoType` to "SM2", and then sets `resultCode` according to... Configure the following settings (0 for success, corresponding error code for failure): The `message` field provides a description, and the SM2 public key certificate information is entered into `b64Cert`, `serialNumber`, `subjectDn`, `issuerDn`, `validFrom`, and `validTo`. Add this verification item to the `verifyItems` list. Then create a second verification item corresponding to the ML-DSA signature, similarly setting `certAlgoType` to "ML-DSA", `resultCode`, `message`, and certificate information. Finally, encapsulate the `verifyItems` list into a structured response object and return it to the online banking backend.

[0103] S106. The online banking back-end system receives the structured response object and extracts the verifyItems list. The system iterates through the verifyItems list, locates the SM2 and ML-DSA verification items, and obtains their resultCode values, denoted as... and The business system checks if both result codes are successful (i.e., equal to 0). If both are successful, it proceeds to the fourth sub-step. If both verification items are successful, the business system further extracts the certificate subject information (subjectDn) from the verification items and compares it with the current transaction account information to ensure that the certificate holder matches the transaction initiator. After successful comparison, the business system calls the bank's core accounting system to execute the transfer processing, records a successful transaction log, and returns a successful transaction response to the client. If any verification item fails, the business system records an audit log based on the specific circumstances of the failure: if the SM2 verification item fails, it records "SM2 signature verification failed" along with the corresponding error description and certificate information; if the ML-DSA verification item fails, it records "ML-DSA signature verification failed" along with the corresponding information. Simultaneously, the business system refuses to execute the payment transaction, returns a transaction failure response to the client, and prompts the user that the transaction failed verification.

[0104] Example 2: Mobile Banking Transactions (Based on Bluetooth Key SDK). This example demonstrates the complete process of quantum-resistant secure transfers via a user's secure medium (i.e., Bluetooth Key) in a mobile environment. Each step will be described in detail below, including: S201. When a user initiates a transfer operation in the mobile banking APP, the client (i.e., the mobile banking APP) calls the device connection interface in the security software development kit to establish a connection with the user's security medium (i.e., the mobile USB key) via Bluetooth and obtains the device handle for subsequent communication.

[0105] S202. The client calls the mobile extended transaction signature interface. The specific implementation function of this interface on the mobile terminal is named `sign_pqc`. The following core parameters are passed during the interface call: ① SM2 key container identifier: This specifies the key container in the user's secure medium that stores the SM2 private key and SM2 public key certificate. This identifier is obtained by the client through enumeration after the device is connected. ② ML-DSA key container identifier: This specifies the key container that stores the ML-DSA private key and ML-DSA public key certificate. ③ Post-quantum digest algorithm identifier: This specifies the hash algorithm used for ML-DSA signing, such as SM3 or SHA-512. This parameter is called `ulPQHashAlg` in Example 1. ④ Encrypted PIN code: This is the `pin` parameter. The PIN code entered by the user through the mobile phone screen is encrypted by the client and passed in for user authentication in the secure medium. The client assembles the key transaction information (such as amount and payee account) and calculates the hash value to obtain the final form of the data to be signed, `signData`. The above parameters are passed to the secure medium driver layer through the interface, preparing to trigger the hardware signature operation.

[0106] S203. After receiving the call to the extended transaction signature interface, the user's secure medium executes the same signature operation process as in Example 1: The secure medium first verifies the encrypted PIN code. If the verification passes, it extracts the data to be signed. The internal secure chip of the secure medium uses the preset SM2 private key and ML-DSA private key to sign the data to be signed, generating an SM2 signature and an ML-DSA signature. This process is a dual-private-key operation mechanism. The secure medium returns the generated SM2 signature, ML-DSA signature, and corresponding SM2 public key certificate and ML-DSA public key certificate to the mobile APP via Bluetooth. The returned data is the dual-signed data.

[0107] S204. After receiving the SM2 signature and ML-DSA signature returned by the security medium, the mobile app encapsulates them into the same PKCS#7 format signature data packet in the same manner as in Example 1. The mobile app uploads the encapsulated signature data packet along with the original transaction message to the server. Upon receiving the request, the server calls the dual-signature verification interface, passing in the signature data packet and the original transaction message. This interface executes the same verification logic as in Example 1: parsing the PKCS#7 packet, verifying the SM2 signature and ML-DSA signature respectively, and generating a structured response object containing SM2 verification items and ML-DSA verification items. The server-side business system judges based on the verification result codes in the structured response object: if both verification result codes are successful, the payment transaction is executed; otherwise, the transaction is rejected and an audit log is recorded based on the failure item. This process ensures the uniformity of security policies under multi-terminal access.

[0108] The technical solution of this invention can solve the problems of poor compatibility, cumbersome user interaction, and difficulty in locating signature verification faults in the migration process of quantum-resistant algorithms in existing technologies. This method defines an extended transaction signature interface between the client and the user's secure medium to support the input of SM2 key container identifiers and ML-DSA key container identifiers. On the server side, a dual-signature verification interface is introduced to return a structured response object containing SM2 and ML-DSA verification items. This method enables the user to complete the dual generation of SM2 and ML-DSA signatures with one PIN code verification and one physical key confirmation operation, i.e., dual signature in one interaction. The server verifies the verification results of the two signatures separately through the verification items in the structured response object, i.e., item-by-item verification. This method ensures quantum-resistant security of transactions while providing fine-grained verification result feedback to the server-side business system. By introducing the ML-DSA algorithm (Module-Lattice-Based Digital Signature Algorithm), it can resist attacks from future quantum computers and ensure long-term asset security. The SM2 algorithm is retained to meet the current compliance requirements of the financial industry for national cryptographic algorithms, while also achieving a smooth transition. An innovative extended transaction signature interface and secure medium interaction logic are designed, allowing users to complete complex underlying SM2 and ML-DSA signature calculations simply by entering a one-time PIN code, with the operation process identical to traditional single-signature methods. The signature data packet is encapsulated in PKCS#7 format, facilitating parsing, unloading, and forwarding by existing online banking systems, reducing the complexity of system modification and integration. Through the verification item list in the structured response object returned by the server, the banking system can accurately distinguish whether the SM2 algorithm has been compromised or is malfunctioning, or whether the ML-DSA algorithm is abnormal, providing crucial data support for security monitoring and emergency response during the post-quantum cryptography migration transition.

[0109] In the above embodiments, although the steps are numbered S1, S2, etc., they are only specific embodiments given by the present invention. Those skilled in the art can adjust the execution order of S1, S2, etc. according to the actual situation. The scheme after adjusting the order is also within the protection scope of the present invention. It can be understood that in some embodiments, some or all of the above embodiments may be included.

[0110] like Figure 3 As shown, an embodiment of the present invention provides a dual-signature payment system supporting ML-DSA and SM2 algorithms, comprising a preset module, a call input module, a signature module, a receiving and encapsulating module, a parsing and returning module, and an execution module. The pre-installed module is used to: pre-install interrelated SM2 public key certificates and ML-DSA public key certificates corresponding to the same user identity information in the user's secure medium; The incoming module is used to: respond to the initiated payment transaction, call the extended transaction signature interface, and pass in the SM2 key container identifier, ML-DSA key container identifier, and the data to be signed; The signature module is used to: after a user verifies and confirms a transaction via a one-time PIN code, control the security medium to sign the data to be signed using the preset SM2 private key and ML-DSA private key respectively, to obtain the SM2 signature and ML-DSA signature; The receiving and encapsulation module is used to: receive the SM2 signature and ML-DSA signature returned by the security medium, obtain the SM2 public key certificate from the security medium based on the SM2 key container identifier, obtain the ML-DSA public key certificate from the security medium based on the ML-DSA key container identifier, and encapsulate the SM2 signature, ML-DSA signature, and the obtained SM2 public key certificate and ML-DSA public key certificate into the same signature data packet; The parsing return module is used to: send the signed data packet to the server so that the server can parse the signed data packet, verify the SM2 signature and ML-DSA signature in the signed data packet respectively, and return a structured response object containing the verification result code corresponding to each signature item; The execution module is used to: receive a structured response object; and if the verification result codes of both the SM2 verification item and the ML-DSA verification item in the structured response object are successful, then execute the payment transaction.

[0111] Optionally, the above technical solution further includes a determination module, which is used for: When the secure medium receives a call to the extended transaction signature interface, it prompts the user to enter a PIN code for verification. If the PIN code verification fails, or if the user does not perform a physical button confirmation operation based on the transaction key information displayed on the screen within a preset time after successful verification, the transaction is deemed to have failed the one-time verification and confirmation, and the signature process is terminated. If the PIN code verification passes, and the user performs a physical button confirmation operation based on the transaction key information displayed on the secure medium's screen, the transaction is deemed to have passed the one-time PIN code verification and confirmation.

[0112] Optionally, in the above technical solution, the parsing return module is specifically used to: enable the server to call the dual-signature value verification interface, parse the signature data packet to obtain the original text and the SM2 signature and ML-DSA signature, call the corresponding verification logic to verify the SM2 signature and ML-DSA signature respectively, and assemble a structured response object according to the verification result of each signature.

[0113] Optionally, in the above technical solution, the execution module is further configured to: if any verification result code in the SM2 verification item or the ML-DSA verification item in the structured response object fails, refuse to execute the payment transaction, and record the corresponding audit log according to the error description in the failed verification item, so as to distinguish whether it is an SM2 signature verification failure or an ML-DSA signature verification failure.

[0114] Optionally, in the above technical solution, the signature data packet is in PKCS#7 format. The signer information field of the PKCS#7 format signature data packet contains two independent signer information structures corresponding to the SM2 signature item and the ML-DSA signature item, respectively. The SM2 signature item contains the SM2 signature, and the ML-DSA signature item contains the ML-DSA signature.

[0115] It should be noted that the beneficial effects of the dual-signature payment system supporting ML-DSA and SM2 algorithms provided in the above embodiments are the same as those of the dual-signature payment method supporting ML-DSA and SM2 algorithms described above, and will not be repeated here. Furthermore, the system provided in the above embodiments is only illustrated by the division of the above functional modules. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the system can be divided into different functional modules according to the actual situation to complete all or part of the functions described above. In addition, the system and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiments, and will not be repeated here.

[0116] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned dual-signature payment methods supporting the ML-DSA algorithm and the SM2 algorithm.

[0117] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-mentioned dual-signature payment methods supporting the ML-DSA algorithm and the SM2 algorithm.

[0118] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0119] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A dual-signature payment method supporting both ML-DSA and SM2 algorithms, characterized in that, include: Pre-install SM2 public key certificates and ML-DSA public key certificates that are related to the same user identity information in the user's secure medium; In response to the initiated payment transaction, the extended transaction signature interface is called, passing in the SM2 key container identifier, the ML-DSA key container identifier, and the data to be signed; After the user verifies and confirms the transaction via a one-time PIN code, the security medium controls the data to be signed to be signed using the preset SM2 private key and ML-DSA private key, respectively, to obtain the SM2 signature and ML-DSA signature. Receive the SM2 signature and the ML-DSA signature returned by the security medium, obtain the SM2 public key certificate from the security medium based on the SM2 key container identifier, obtain the ML-DSA public key certificate from the security medium based on the ML-DSA key container identifier, and encapsulate the SM2 signature, the ML-DSA signature, and the obtained SM2 public key certificate and ML-DSA public key certificate into the same signature data packet; The signature data packet is sent to the server so that the server can parse the signature data packet, verify the SM2 signature and ML-DSA signature in the signature data packet respectively, and return a structured response object containing the verification result code corresponding to each signature item; If the structured response object is received and both the SM2 verification item and the ML-DSA verification item in the structured response object are successful, then the payment transaction is executed.

2. The dual-signature payment method supporting ML-DSA and SM2 algorithms according to claim 1, characterized in that, Determining whether a user has verified and confirmed a transaction via a one-time PIN code includes: When the secure medium receives a call to the extended transaction signature interface, it prompts the user to enter a PIN code for verification. If the PIN code verification fails, or if the user does not perform a physical button confirmation operation based on the transaction key information displayed on the screen within a preset time after successful verification, it is determined that the one-time verification and transaction confirmation have failed, and the signature process is terminated. If the PIN code verification passes, and the user performs a physical button confirmation operation based on the transaction key information displayed on the secure medium's screen, it is determined that the one-time PIN code verification and transaction confirmation have passed.

3. The dual-signature payment method supporting ML-DSA and SM2 algorithms according to claim 1, characterized in that, The server parses the signature data packet and verifies the SM2 signature and ML-DSA signature in the signature data packet, including: the server calls the dual signature value verification interface, parses the signature data packet to obtain the original text and the SM2 signature and ML-DSA signature, calls the corresponding verification logic to verify the SM2 signature and ML-DSA signature respectively, and assembles the structured response object according to the verification result of each signature.

4. A dual-signature payment method supporting both ML-DSA and SM2 algorithms according to any one of claims 1 to 3, characterized in that, Also includes: If either the SM2 verification item or the ML-DSA verification item in the structured response object fails, the payment transaction will be refused, and the corresponding audit log will be recorded according to the error description in the failed verification item to distinguish whether it is an SM2 signature verification failure or an ML-DSA signature verification failure.

5. A dual-signature payment method supporting both ML-DSA and SM2 algorithms according to any one of claims 1 to 3, characterized in that, The signature data packet is in PKCS#7 format. The signer information field of the PKCS#7 format signature data packet contains two independent signer information structures corresponding to the SM2 signature item and the ML-DSA signature item, respectively. The SM2 signature item contains the SM2 signature, and the ML-DSA signature item contains the ML-DSA signature.

6. A dual-signature payment system supporting both ML-DSA and SM2 algorithms, characterized in that, It includes a pre-built module, a call input module, a signature module, a receive and encapsulate module, a parsing and return module, and an execution module; The pre-installed module is used to: pre-install an SM2 public key certificate and an ML-DSA public key certificate that are related to each other and correspond to the same user identity information in the user's security medium; The call input module is used to: in response to an initiated payment transaction, call the extended transaction signature interface, and pass in the SM2 key container identifier, the ML-DSA key container identifier, and the data to be signed; The signature module is used to: when a user verifies and confirms a transaction via a one-time PIN code, control the security medium to sign the data to be signed using a preset SM2 private key and ML-DSA private key respectively, to obtain an SM2 signature and an ML-DSA signature; The receiving and encapsulation module is configured to: receive the SM2 signature and the ML-DSA signature returned by the security medium; obtain the SM2 public key certificate from the security medium based on the SM2 key container identifier; obtain the ML-DSA public key certificate from the security medium based on the ML-DSA key container identifier; and encapsulate the SM2 signature, the ML-DSA signature, and the obtained SM2 public key certificate and ML-DSA public key certificate into the same signature data packet. The parsing return module is used to: send the signature data packet to the server so that the server parses the signature data packet, verifies the SM2 signature and ML-DSA signature in the signature data packet respectively, and returns a structured response object containing the verification result code corresponding to each signature item; The execution module is used to: receive the structured response object, and if the verification result codes of both the SM2 verification item and the ML-DSA verification item in the structured response object are successful, then execute the payment transaction.

7. A dual-signature payment system supporting ML-DSA and SM2 algorithms according to claim 6, characterized in that, It also includes a determination module, which is used for: When the security medium receives the call to the extended transaction signature interface, it prompts the user to enter a PIN code and verify it. If the PIN code verification fails, or if the user does not perform a physical button confirmation operation based on the transaction key information displayed on the screen within a preset time after successful verification, it is determined that the one-time verification and transaction confirmation have failed, and the signature process is terminated. If the PIN code verification is successful, and the user confirms the transaction by pressing a physical button after the key transaction information is displayed on the screen of the secure medium, then the transaction is determined to have passed one-time PIN code verification and been confirmed.

8. A dual-signature payment system supporting ML-DSA and SM2 algorithms according to claim 7, characterized in that, The parsing return module is specifically used to: enable the server to call the dual-signature value verification interface, parse the signature data packet to obtain the original text and the SM2 signature and the ML-DSA signature, call the corresponding verification logic to verify the SM2 signature and the ML-DSA signature respectively, and assemble the structured response object according to the verification result of each signature.

9. An electronic device, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements a dual-signature payment method supporting the ML-DSA algorithm and the SM2 algorithm as described in any one of claims 1 to 5.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements a dual-signature payment method supporting the ML-DSA algorithm and the SM2 algorithm as described in any one of claims 1 to 5.

Images