Reliable electronic signature system and method matching business processes

Abstract

The application discloses a reliable electronic signature system and method matched with a business process, relates to the technical field of information security, and comprises the following: a configuration module used for configuring a business process, a link and signature control information which need to be signed by an application system; an API interface SDK used for providing an electronic signature interface under different environments, acquiring signature configuration information through the SDK, and automatically storing electronic evidence after signature notification, signature willingness authentication and signature, so as to provide data for subsequent electronic evidence extraction; an API interface background module used for providing a support interface for the API interface, and safely storing signature control parameters and electronic evidence data; providing a configuration data storage service interface for the configuration module; providing an electronic evidence query service interface for an electronic evidence extraction module; and the electronic evidence extraction module used for analyzing and assembling stored electronic evidence to form comprehensive electronic evidence; and the application can provide reliable electronic signature services for the application system.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a reliable electronic signature system and method for matching business processes. Background Technology

[0002] Currently, electronic signature technology is increasingly widely used. Electronic signatures can verify the signer's acceptance of the signed information, serving functions such as identity authentication, data tamper prevention, and repudiation. However, electronic signature technology is a low-level security measure that requires standardized integration into business systems to ensure security throughout the entire business process. Currently, because various business systems integrate electronic signature technology as a low-level component, there are no standardized implementation methods for crucial aspects of the reliability and effectiveness of electronic signatures, such as pre-signing risk disclosure and signature intent authentication.

[0003] It is evident that when business systems integrate electronic signature technology as a technical component, the lack of standardized methods for key processes such as notification and electronic intent authentication before signing leads to non-standard and irregular integration. This results in flawed application of electronic signature technology (e.g., failure to adequately inform the signer of the signature content, leading to subsequent denial), making the final signature unreliable in legal disputes. Furthermore, in areas with high dispute rates, the demand for post-event proof is increasingly strong, and users are more proactive in pursuing their rights after losses. Component-based integration of electronic signature technology cannot provide business systems with a complete and reliable chain of electronic evidence. Summary of the Invention

[0004] This invention primarily addresses the issues of electronic signature notification / risk warning, electronic signature intent authentication, electronic signature result storage and evidence extraction, and flexible matching of electronic signature services to different business processes during the electronic signature process in business systems. The purpose of this invention is to provide a reliable electronic signature system and method that matches business processes. This invention can configure signature control information according to the electronic signature process steps required by different business processes of the application system, and provides an API interface SDK that adapts to various business application environments, providing reliable electronic signature services for application systems.

[0005] To achieve the above objectives, the technical solution adopted by this invention is: a reliable electronic signature system that matches business processes, comprising: a configuration module, an API interface SDK, an API interface backend module, and an electronic evidence extraction module; wherein:

[0006] The configuration module is used to configure the business processes, steps, and signature control information that require signatures in the application system.

[0007] The API interface SDK is used to provide electronic signature interfaces in different environments. By obtaining signature configuration information through the SDK, reliable electronic signatures can be achieved in the corresponding business process. At the same time, through pre-signature notification, signature intent authentication, and post-signature notification, the automatic storage of electronic evidence provides data for subsequent electronic evidence extraction.

[0008] The API interface backend module is used to provide support interfaces for the API interface, secure storage of signature control parameters and electronic evidence data. The support interfaces include application system access authentication, control parameter query service, and electronic evidence storage; it provides configuration data storage service interface for the configuration module; and it provides electronic evidence query service interface for the electronic evidence extraction module.

[0009] The electronic evidence extraction module is used to analyze and assemble stored electronic evidence to form comprehensive electronic evidence.

[0010] This invention also provides a reliable electronic signature method for matching business processes, implemented using the reliable electronic signature system for matching business processes as described above. The method includes the following steps:

[0011] Step 1: Configure the application access signature control parameter values, and configure the specific business links that require electronic signatures according to different business processes in the application system, and configure the signature configuration information for the specific business links.

[0012] Step 2: The business system calls the electronic signature interface through the API interface SDK. The API interface SDK notifies the system before signing based on the signing configuration information in the corresponding business process, performs signature intent authentication based on the signature intent expression authentication method, and notifies the system after signing based on the configuration and stores the electronic signature behavior evidence. This process is repeated until a process is completed.

[0013] Step 3: When electronic evidence is required, extract the electronic evidence based on the business process identifier and assemble the electronic evidence.

[0014] As a further improvement of the present invention, step 1 specifically includes the following steps:

[0015] Step 1.1: Assign application identifiers and application keys to the access application systems, which serve as the basis for application access authentication and a security control mechanism;

[0016] Step 1.2: Create a business process for the application that requires electronic signatures, including the business process code and business process name, as the basis for subsequent evidence extraction;

[0017] Step 1.3: Configure the process steps that require electronic signatures for the corresponding business processes;

[0018] Step 1.4: Configure pre-signature notification, signature intent authentication method, and post-signature notification control information for the process steps that require electronic signatures.

[0019] As a further improvement of the present invention, in step 1.4, the signature intention authentication method is PIN code authentication, facial recognition authentication, or SMS authentication.

[0020] As a further improvement of the present invention, step 2 specifically includes the following steps:

[0021] Step 2.1: The API interface SDK determines whether the application system's authentication is successful. If successful, proceed to step 2.2; otherwise, return to the application system and end the process.

[0022] Step 2.2: The signer reviews the notification content in the pre-signing notification user interface and confirms or cancels the signature; the API interface SDK decides whether to proceed with further processing based on the user's specific interface operation result. If the user cancels the signature, the signing process ends and the user's cancellation result is returned to the application system; if the user confirms the signature, proceed to step 2.3; at the same time, the API interface SDK records relevant log records. The API interface SDK calculates the hash value of the pre-signing notification content, the relevant pre-signing notification process logs, and the user's operation result logs, and records it as hash_bn;

[0023] Step 2.3: The API SDK initiates signer authentication based on the signature intent authentication method. It activates the appropriate authentication component based on the signer's client environment to complete the signer authentication and logs the entire authentication process as evidence. The signer completes authentication according to the signature intent authentication method. The API SDK determines the authentication result; if authentication fails, it returns specific error information to the business system and terminates the signing process. If authentication succeeds, proceed to Step 2.4. Simultaneously, the API SDK records relevant log entries, including the signature authentication process logs and authentication evidence, and calculates a hash value, denoted as hash_au.

[0024] Step 2.4: After the signer views the signature, the user interface is notified. The API interface SDK records the relevant signature notification evidence and calculates the hash value of the signature notification evidence, denoted as hash_pn. The API interface backend stores the signature evidence information and adds a timestamp to the signature evidence using the server's digital certificate when storing the signature evidence.

[0025] As a further improvement of the present invention, step 2.1 specifically includes the following steps:

[0026] Step 2.1.1: The signer performs an electronic signature on the application system. At this time, the signer is operating on a certain business process instance of the application system.

[0027] Step 2.1.2: The application system prepares the original signature text and related signature control parameter values. The specific signature control parameter value list includes: application identifier, random number, timestamp, unique process identifier, unique process instance identifier, process instance code, process instance name, unique stage identifier, original signature text, parameter value of information provided before signing, parameter value of information provided after signing, and calculates the signature value of the signature control parameter values.

[0028] Step 2.1.3: The application system calls the signature interface of the API to perform electronic signature;

[0029] Step 2.1.4: The API interface SDK calculates the SM3 algorithm parameter hash value hash_arg for the call parameters, random number, and timestamp, and verifies the application system identity and the correctness of the call parameters through the API interface backend;

[0030] Step 2.1.5: The API interface backend finds the corresponding application key based on the application system's application identifier, decrypts the signature value of the parameter value calculated by the application system, and the decryption result is the parameter hash value hash_arg'. It is compared with the parameter hash value hash_arg. If they are equal, the verification passes; otherwise, the verification fails.

[0031] As a further improvement of the present invention, step 2.2 specifically includes the following steps:

[0032] Step 2.2.2: The API interface SDK calls the API interface backend service to obtain signature control parameters based on the application identifier, process unique identifier, and stage unique identifier;

[0033] Step 2.2.3: The API interface backend queries the configuration information stored in the signature control parameter data structure based on the application identifier, process unique identifier, and stage unique identifier. It retrieves the signature control parameter information for pre-signature notification, signature intention authentication method, and post-signature notification, and returns it to the API interface SDK.

[0034] Step 2.2.4: The API interface SDK determines whether there is pre-signing notification information. If so, it generates a pre-signing notification user interface based on the notification template, customized UI, and pre-signing notification content parameter values, and displays it to the signer.

[0035] As a further improvement of the present invention, step 2.4 specifically includes the following steps:

[0036] Step 2.4.1: The API interface SDK calculates the hash value of the original signature, denoted as hash_or;

[0037] Step 2.4.2: The API interface SDK determines whether there is a signed notification message. If so, it generates a signed notification user interface based on the notification template, customized UI, and the parameter values ​​of the signed notification content, and displays it to the signer. The API interface records relevant log records.

[0038] Step 2.4.3: The API interface SDK calls the user's digital certificate private key to sign hash_bn, hash_au, hash_pn, and hash_or respectively to obtain the signature value of the evidence before signing, the signature value of the evidence during the identity authentication process, the signature value of the evidence after signing, and the signature value of the original text. At this time, the API interface SDK calls the specific signer's digital certificate private key to perform the signing based on the specific environment of the signer's client.

[0039] Step 2.4.4: The application system receives the original signature value and saves it;

[0040] Step 2.4.5: The API interface backend stores signature evidence information, including evidence information of the content provided before signing and the signature value of the evidence of the content provided before signing, evidence information of the identity authentication of the signer during signing and the signature value of the evidence, evidence information of the content provided after signing and the signature value of the evidence of the content provided after signing, and the signature value of the original signature text. At the same time, when storing signature evidence, the server's digital certificate is used to add a timestamp to prove the storage time of the evidence, and the added timestamp is added to the entire signature evidence record.

[0041] As a further improvement of the present invention, step 3 specifically includes the following steps:

[0042] Step 3.1: The API interface backend extracts the corresponding signature evidence list of all process nodes under a specific process instance through the application identifier, process unique identifier, and process instance unique identifier; the evidence list is sorted according to the time order of the timestamps.

[0043] Step 3.2: The API interface backend parses the query results, and during parsing, it retrieves the corresponding information based on the signature control parameter data structure.

[0044] Step 3.3: For each piece of data, the API backend parses the pre-signature notification evidence, the signature authentication evidence, and the post-signature notification evidence, and returns the final result.

[0045] This invention divides an electronic signature action at a process node in a business process into three important stages: "notification before signing, authentication of signing intent, and notification after signing." These three stages are treated as a complete transaction of the signing action, perfectly mapping the "pre-signing, during-signing, and post-signing" electronic signature business control mechanism. It also preserves relevant electronic signature evidence for "notification before signing, authentication of signing intent, and notification after signing," ultimately forming a complete chain of evidence for the signing action "before, during, and after," thus avoiding related legal risks.

[0046] This invention uses signature control parameters to match the electronic signature links in different business processes of a business system. It can also configure pre-signature notification, signature intent authentication method, and post-signature notification for each signature link in the process to refine a signature behavior. Furthermore, it achieves the goal of user-friendly interaction for signers and flexible configuration of signature process control through parameter configuration.

[0047] This invention provides a unified one-time signature call interface service for application systems through an API interface SDK. The API interface SDK can generate a notification user interface adapted to the signer's client environment based on the signature control parameters of the electronic signature process, and generate notification content information adapted to the needs of the application system. This can effectively avoid problems such as unclear notification content, inconsistent notification interfaces, inability to record the signer's confirmation of the notification content, and inability to collect and preserve evidence of the signer's confirmation of the notification content.

[0048] This invention provides application systems with a signature intent authentication method adapted to the needs of a single signature action through an API interface SDK. It can flexibly match the signature intent authentication method adopted according to the risk level of a single signature action, and can also perform client environment detection on this basis to adopt a more flexible signature intent authentication method. At the same time, it records the entire signature intent authentication process of the signer, forming evidence of the signature intent authentication behavior, effectively solving the problem of the inability to collect and preserve evidence of the signer's signature intent authentication behavior.

[0049] This invention can effectively collect signature behavior data from the signature stage of an overall business process, forming electronic evidence of signature behavior. It categorizes signature behavior evidence into "pre-signature notification," "signature intent authentication," and "post-signature notification." Furthermore, it records the electronic signature behavior evidence at each actual process node of a specific instance within the overall business process, perfectly matching the business process handling procedure. Moreover, this invention can not only extract evidence of a specific signature behavior but also extract electronic evidence from the entire business process, forming a complete evidence chain for the business process.

[0050] The beneficial effects of this invention are:

[0051] This invention solves the problem of application systems being unable to flexibly configure and match specific business process steps during the use of electronic signatures, including pre-signature notification, signature intent authentication, and post-signature notification for a single electronic signature transaction. It also addresses the issues of evidence collection and extraction during these processes. Therefore, the application of this invention provides application systems and signers with a more reliable electronic signature process, avoiding non-standard or irregular situations when integrating electronic signature technology into application systems, and preventing flaws in the application of electronic signature technology. Attached Figure Description

[0052] Figure 1 This is a schematic diagram of the signature system in an embodiment of the present invention;

[0053] Figure 2 This is a flowchart of the signature method in an embodiment of the present invention;

[0054] Figure 3 This is a flowchart illustrating the configuration of application access signature control parameters in an embodiment of the present invention;

[0055] Figure 4 This is a schematic diagram of the signature control parameter data structure in an embodiment of the present invention;

[0056] Figure 5-1 This is a first flowchart of the process by which the business system implements electronic signature through API interface calls in an embodiment of the present invention;

[0057] Figure 5-2 This is a second flowchart illustrating how the business system implements electronic signatures through API interface calls in this embodiment of the invention.

[0058] Figure 6 This is a schematic diagram of the signature evidence storage data structure in an embodiment of the present invention;

[0059] Figure 7 This is a flowchart of the electronic evidence extraction process in an embodiment of the present invention. Detailed Implementation

[0060] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0061] Example:

[0062] like Figure 1As shown, a reliable electronic signature system 100 that matches business processes includes a configuration module 101, an API interface SDK 102, an API interface backend module 103, and an electronic evidence extraction module 104. The configuration module 101 configures the business processes, steps, and signature control information required by the application system. The API interface SDK 102 provides electronic signature interfaces for different environments. By obtaining signature configuration information through the SDK, reliable electronic signatures can be achieved in the corresponding business steps. Simultaneously, through pre-signature notification, signature intent authentication, and post-signature notification, the automatic storage of electronic evidence provides data for subsequent electronic evidence extraction. The API interface backend module 103 provides support interfaces for the API interface, secure storage of signature control parameters and electronic evidence data. The support interfaces include application system access authentication, control parameter query services, and electronic evidence storage. It provides a configuration data storage service interface for the configuration module and an electronic evidence query service interface for the electronic evidence extraction module. The electronic evidence extraction module 104 analyzes and assembles the stored electronic evidence to form comprehensive electronic evidence.

[0063] like Figure 2 As shown, this embodiment also provides a reliable electronic signature method for matching business processes, including the following steps:

[0064] S10: Configure application access control parameters, and configure the specific business links that require electronic signatures according to different business processes in the application system, and configure the signature configuration information for the specific business links.

[0065] S20: The business system calls the electronic signature interface through the API interface SDK. The API interface SDK notifies the system before signing based on the signing configuration information in the corresponding business process, performs signature authentication based on the signature intention expression authentication method, and notifies the system after signing based on the configuration and stores the electronic signature behavior evidence. This process is repeated until a process is completed.

[0066] S30: When electronic evidence is required, extract the electronic evidence based on the business process identifier and assemble the electronic evidence.

[0067] The signature method of this embodiment will be further explained below:

[0068] S10 Configuring Application Access Signature Control Parameters: See the procedure for configuring application access signature control parameters. Figure 3 The required signature control parameter data structure can be found in [link / reference]. Figure 4 , Figure 3 The process is described as follows:

[0069] S1001: Assign (app_id, app_secret) to apps (access application systems) as the basis for application access authentication and security control mechanism.

[0070] S1002: Create a process (business process) for the application that requires electronic signature, including (process_code, process_name) as an important basis for subsequent evidence extraction.

[0071] S1003: Configure the nodes (process steps) that require electronic signatures for the corresponding business process.

[0072] S1004: Configure the before_sign (notify before signing) control information for nodes (process steps) that require electronic signatures.

[0073] S1005: Configure sign_auth (signature intent authentication method) control information for nodes (process steps) that require electronic signatures.

[0074] S1006: Configure post_sign (notify after signing) for nodes (process steps) that require electronic signatures.

[0075] Figure 4 The signature control parameter data structure is described in detail below:

[0076] The `apps` (access application system) stores all access application systems. `app_id` (application identifier) ​​is a unique identifier for the access application system, and `app_secret` (application key) is an important piece of information for verifying user identity and ensuring security when the access application system makes API calls. The two are used together to verify the identity of the access application system.

[0077] The `process` (business process) and `nodes` (process steps) are used to store the business processes within the application system and the corresponding process steps that require electronic signatures.

[0078] `before_sign` (pre-signature notification) stores control information for pre-signature notifications in the electronic signature process. `if_notice` (yes / no notification) indicates whether a notification message will appear before signing. `notice_template` (notification template) uses a text template, and parameters are replaced during notification to ultimately form the notification content. `custom_ui` (custom UI) can store information for custom UIs according to the needs of the application system.

[0079] The sign_auth (signature intention authentication method) stores the identity authentication method required for the corresponding process step when making an electronic signature, such as PIN code authentication, face scan authentication, SMS authentication, etc. This information controls which identity authentication method the API interface uses to authenticate the signer's identity when making an electronic signature.

[0080] post_sign (notify after signing) is similar to before_sign (notify before signing), so I won't go into details.

[0081] The S20 business system implements electronic signatures through API interface calls: When the signer operates within the application system and performs an electronic signature at a specific stage of a business process, the business system calls the electronic signature interface of the API interface SDK to implement the electronic signature. See the detailed process below. Figure 5-1 , Figure 5-2 The data structure of the relevant electronic evidence stored when a digital signature is successfully completed is shown below. Figure 6 The process is described as follows:

[0082] S2001: The signer performs an electronic signature on an application system operation. At this time, the signer's operation is a business step of a business process instance of the application system.

[0083] S2002: The application system prepares the original signature text and related signature control parameter values. The specific list of signature control parameter values ​​includes: application identifier (app_id), random number (nonce), ts (timestamp), process unique identifier (process_id), process instance unique identifier (process_instance), process instance code (instance_code), process instance name (instance_name), stage unique identifier (node_id), signature text (contents), pre-signature informed content parameter values ​​(before_args), post-signature informed content parameter values ​​(post_args), and the signature value calculated using the HMAC_SM3 algorithm based on the above parameter values ​​(the specific signature process can be implemented through the API interface SDK).

[0084] S2003: The application system calls the signature interface of the API interface to perform electronic signature.

[0085] S2004: The API interface SDK calculates the SM3 algorithm parameter hash value hash_arg for call parameters, random numbers, and timestamps, and verifies the application system's identity and the correctness of the call parameters through the API interface backend.

[0086] S2005: The API interface backend finds the corresponding application key (app_secret) based on the application system's app_id, decrypts the signature value of the parameter value calculated by the application system, and the decryption result is the parameter hash value hash_arg'. It is compared with the parameter hash value hash_arg. If they are equal, the verification passes; otherwise, the verification fails.

[0087] S2006: The API interface SDK determines whether the application system's authentication is successful. If successful, proceed to S2007; otherwise, return to the application system and terminate.

[0088] S2007: The API interface SDK calls the API interface backend service to obtain signature control parameters based on the application identifier (app_id), process unique identifier (process_id), and stage unique identifier (node_id).

[0089] S2008: The API interface backend queries the signature control parameter data structure based on app_id, process_id, and node_id. Figure 4 The configuration information stored in the database can be used to retrieve the signature control parameters before_sign (notify before signing), sign_auth (signing intention authentication method), and post_sign (notify after signing), and then the API interface SDK is returned.

[0090] S2009: If the API interface SDK determines that "if_notice (yes / no notification)" of before_sign (notify before signing) is "yes", it will generate the user interface for notifying before signing based on notice_template (notification template), custom_ui (custom UI), and the parameter value of the notification before signing content (before_args), and display it to the signer. During this process, the API interface SDK records relevant log records.

[0091] S2010: The signer views the notification content in the pre-signing notification user interface and confirms / cancels the signature.

[0092] S2011: The API interface SDK determines whether to perform further processing based on the user's specific interface operation results. When the user "cancels", the signing process ends and the "user cancels" result is returned to the application system; when the user "confirms", it enters S2012; during this process, the API interface SDK records relevant log records.

[0093] S2012: The API interface SDK calculates the hash value (hash_bn) of the pre-signature notification content, the related pre-signature notification process logs, and the user's operation result logs.

[0094] S2013: The API interface SDK initiates signer identity authentication based on sign_auth (signing intention authentication method). This process will enable the corresponding authentication component to complete the signer identity authentication according to the specific environment of the signer's client. The entire signer identity authentication process is logged as evidence.

[0095] S2014: The signer completes the signer identity authentication according to the authentication process in the signature intention authentication method.

[0096] S2015: The API interface SDK determines the signature authentication result. If the authentication fails, it returns specific error information to the business system and ends the signing process; if the authentication succeeds, it proceeds to S2016.

[0097] S2016: The API interface SDK records log information related to the signer's identity authentication process and related identity authentication evidence information, and calculates the hash value (hash_au) of the above information.

[0098] S2017: The API interface SDK calculates the hash value (hash_or) of the original signature (contents).

[0099] S2018: If the "if_notice (yes / no notification)" of post_sign (signed notification) is "yes", the API interface SDK will generate the signed notification user interface based on notice_template (notification template), custom_ui (custom UI), and the signed notification content parameter value (post_args), and display it to the signer. The API interface records relevant log records during this process.

[0100] S2019: The signer displays the signature in the user interface.

[0101] S2020: The API interface SDK records the relevant signature and then provides evidence, and calculates the hash value (hash_pn) of the evidence provided after signing.

[0102] S2021: The API interface SDK calls the user's digital certificate private key to sign hash_bn, hash_au, hash_pn, and hash_or respectively to obtain the signature value of the evidence before signing (sign_bn), the signature value of the evidence during the identity authentication process during signing (sign_au), the signature value of the evidence after signing (sign_pn), and the signature value of the original text (sign_or). At this time, the API interface SDK calls the specific signer's digital certificate private key to perform the signing according to the specific environment of the signer's client.

[0103] S2022: The application system receives the original signature value (sign_or) and saves it.

[0104] S2023: The API interface backend stores signature evidence information, including evidence information of the notification content before signing and the signature value of the notification evidence before signing (sign_bn), evidence information of the signer's identity authentication at the time of signing and the signature value of the evidence (sign_au), evidence information of the notification content after signing and the signature value of the notification evidence after signing (sign_pn), and the signature value of the original signature text (sign_or). At the same time, when storing signature evidence, the server's digital certificate is used to add a timestamp to prove the storage time of the evidence, and the added timestamp is applied to the entire signature evidence record.

[0105] Throughout the signing process, the API SDK treats a signing activity as a transaction.

[0106] The data structure for storing signed evidence is detailed below:

[0107] `sign_evidence` stores all signature evidence information, including: `app_id` (application), representing the specific application system storing the evidence; `process_id` (process), representing which business process's evidence is stored; `process_instance` (process instance identifier), storing the identifier of a specific process instance, used to distinguish different process instances under the same `process_id`; `instance_code` (process instance code), a unique attribute value corresponding to the process instance `process_instance`, facilitating data retrieval; `instance_name` (process instance name), a unique attribute value corresponding to the process instance `process_instance`, facilitating data retrieval; and `node_id` (stage), used to distinguish between the same... A process is defined by a specific step in a process using a process_id; sign_subject (signer): stores the signer's information, typically the signer's digital certificate when using digital certificates; sign (signature value): the signature value of the original signed text; timestamp: stores the time the evidence was stored and uses timestamp technology to prevent tampering; before_evidence (evidence before signing): stores the evidence information provided before signing and the signature value of the corresponding evidence; auth_evidence (evidence for signature authentication): stores the identity authentication evidence information provided by the signer at the time of signing and the signature value of the corresponding evidence; post_evidence (evidence after signing): stores the evidence information provided after signing and the signature value of the corresponding evidence.

[0108] S30 Electronic Evidence Extraction Process: When it is necessary to extract signed electronic evidence, the corresponding electronic evidence can be extracted through the electronic evidence extraction process. See details below. Figure 7 The description is as follows:

[0109] S3001: The API interface backend can extract the corresponding signature evidence list of all process nodes under a specific process instance (process_instance) through app_id, process_id, and process_instance; the evidence list is sorted according to the time order of the timestamps.

[0110] S3002: The API interface backend parses the query results. During parsing, it retrieves the corresponding information (such as process_code, process_name, instance_code, instance_name, node_code, node_name, etc.) based on the "signature control parameter data structure".

[0111] S3003: For each piece of data, the API backend parses before_evidence (evidence before signing), auth_evidence (evidence for signing authentication), and post_evidence (evidence after signing), and returns the final result.

[0112] The embodiments described above are merely illustrative of specific implementations of the present invention, and while the descriptions are detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention.

Claims

1. A reliable electronic signature method for matching business processes, characterized in that, A reliable electronic signature system matching the business process is adopted. The system includes: a configuration module, an API interface SDK, an API interface backend module, and an electronic evidence extraction module; wherein: The configuration module is used to configure the business processes, steps, and signature control information that require signatures in the application system. The API interface SDK is used to provide electronic signature interfaces in different environments. By obtaining signature configuration information through the SDK, reliable electronic signatures can be achieved in the corresponding business process. At the same time, through pre-signature notification, signature intent authentication, and post-signature notification, the automatic storage of electronic evidence provides data for subsequent electronic evidence extraction. The API interface backend module is used to provide support interfaces for the API interface, secure storage of signature control parameters and electronic evidence data. The support interfaces include application system access authentication, control parameter query service, and electronic evidence storage; it provides configuration data storage service interface for the configuration module; and it provides electronic evidence query service interface for the electronic evidence extraction module. The electronic evidence extraction module is used to analyze and assemble stored electronic evidence to form comprehensive electronic evidence. The method includes the following steps: Step 1: Configure the application access signature control parameter values, and configure the specific business links that require electronic signatures according to different business processes in the application system, and configure the signature configuration information for the specific business links. Step 1 specifically includes the following steps: Step 1.1: Assign application identifiers and application keys to the access application systems, which serve as the basis for application access authentication and a security control mechanism; Step 1.2: Create a business process for the application that requires electronic signatures, including the business process code and business process name, as the basis for subsequent evidence extraction; Step 1.3: Configure the process steps that require electronic signatures for the corresponding business processes; Step 1.4: Configure pre-signature notification, signature intent authentication method, and post-signature notification control information for the process steps that require electronic signatures; Step 2: The business system calls the electronic signature interface through the API interface SDK. The API interface SDK notifies the system before signing based on the signing configuration information in the corresponding business process, performs signature intent authentication based on the signature intent expression authentication method, and notifies the system after signing based on the configuration and stores the electronic signature behavior evidence. This process is repeated until a process is completed. Step 2 specifically includes the following steps: Step 2.1: The API interface SDK determines whether the application system's authentication is successful. If successful, proceed to step 2.2; otherwise, return to the application system and end the process. Step 2.2: The signer reviews the notification content in the pre-signing notification user interface and confirms or cancels the signature; the API interface SDK decides whether to proceed with further processing based on the user's specific interface operation result. If the user cancels the signature, the signing process ends and the user's cancellation result is returned to the application system; if the user confirms the signature, proceed to step 2.3; at the same time, the API interface SDK records relevant log records. The API interface SDK calculates the hash value of the pre-signing notification content, the relevant pre-signing notification process logs, and the user's operation result logs, and records it as hash_bn; Step 2.3: The API SDK initiates signer authentication based on the signature intent authentication method. It activates the appropriate authentication component based on the signer's client environment to complete the signer authentication and logs the entire authentication process as evidence. The signer completes authentication according to the signature intent authentication method. The API SDK determines the authentication result; if authentication fails, it returns specific error information to the business system and terminates the signing process. If authentication succeeds, proceed to Step 2.

4. Simultaneously, the API SDK records relevant log entries, including the signature authentication process logs and authentication evidence, and calculates a hash value, denoted as hash_au. Step 2.4: After the signer views the signature, the user interface is notified. The API interface SDK records the relevant signature notification evidence and calculates the hash value of the signature notification evidence, denoted as hash_pn. The API interface backend stores the signature evidence information and adds a timestamp to the signature evidence using the server's digital certificate when storing the signature evidence. Step 3: When electronic evidence is required, extract the electronic evidence based on the business process identifier and assemble the electronic evidence.

2. The reliable electronic signature method for matching business processes according to claim 1, characterized in that, In step 1.4, the signature intent authentication method is PIN code authentication, facial recognition authentication, or SMS authentication.

3. The reliable electronic signature method for matching business processes according to claim 1, characterized in that, Step 2.1 specifically includes the following steps: Step 2.1.1: The signer performs an electronic signature on the application system. At this time, the signer is operating on a certain business process instance of the application system. Step 2.1.2: The application system prepares the original signature text and related signature control parameter values. The specific signature control parameter value list includes: application identifier, random number, timestamp, unique process identifier, unique process instance identifier, process instance code, process instance name, unique stage identifier, original signature text, parameter value of information provided before signing, parameter value of information provided after signing, and calculates the signature value of the signature control parameter values. Step 2.1.3: The application system calls the signature interface of the API to perform electronic signature; Step 2.1.4: The API interface SDK calculates the SM3 algorithm parameter hash value hash_arg for the call parameters, random number, and timestamp, and verifies the application system identity and the correctness of the call parameters through the API interface backend; Step 2.1.5: The API interface backend finds the corresponding application key based on the application system's application identifier, decrypts the signature value of the parameter value calculated by the application system, and the decryption result is the parameter hash value hash_arg'. It is compared with the parameter hash value hash_arg. If they are equal, the verification passes; otherwise, the verification fails.

4. The reliable electronic signature method for matching business processes according to claim 3, characterized in that, Step 2.2 specifically includes the following steps: Step 2.2.2: The API interface SDK calls the API interface backend service to obtain signature control parameters based on the application identifier, process unique identifier, and stage unique identifier; Step 2.2.3: The API interface backend queries the configuration information stored in the signature control parameter data structure based on the application identifier, process unique identifier, and stage unique identifier. It retrieves the signature control parameter information for pre-signature notification, signature intention authentication method, and post-signature notification, and returns it to the API interface SDK. Step 2.2.4: The API interface SDK determines whether there is pre-signing notification information. If so, it generates a pre-signing notification user interface based on the notification template, customized UI, and pre-signing notification content parameter values, and displays it to the signer.

5. The reliable electronic signature method for matching business processes according to claim 4, characterized in that, Step 2.4 specifically includes the following steps: Step 2.4.1: The API interface SDK calculates the hash value of the original signature, denoted as hash_or; Step 2.4.2: The API interface SDK determines whether there is a signed notification message. If so, it generates a signed notification user interface based on the notification template, customized UI, and the parameter values ​​of the signed notification content, and displays it to the signer. The API interface records relevant log records. Step 2.4.3: The API interface SDK calls the user's digital certificate private key to sign hash_bn, hash_au, hash_pn, and hash_or respectively to obtain the signature value of the evidence before signing, the signature value of the evidence during the identity authentication process, the signature value of the evidence after signing, and the signature value of the original text. At this time, the API interface SDK calls the specific signer's digital certificate private key to perform the signing based on the specific environment of the signer's client. Step 2.4.4: The application system receives the original signature value and saves it; Step 2.4.5: The API interface backend stores signature evidence information, including evidence information of the content provided before signing and the signature value of the evidence of the content provided before signing, evidence information of the identity authentication of the signer during signing and the signature value of the evidence, evidence information of the content provided after signing and the signature value of the evidence of the content provided after signing, and the signature value of the original signature text. At the same time, when storing signature evidence, the server's digital certificate is used to add a timestamp to prove the storage time of the evidence, and the added timestamp is added to the entire signature evidence record.

6. The reliable electronic signature method for matching business processes according to claim 5, characterized in that, Step 3 specifically includes the following steps: Step 3.1: The API interface backend extracts the corresponding signature evidence list of all process nodes under a specific process instance through the application identifier, process unique identifier, and process instance unique identifier; the evidence list is sorted according to the time order of the timestamps. Step 3.2: The API interface backend parses the query results, and during parsing, it retrieves the corresponding information based on the signature control parameter data structure. Step 3.3: For each piece of data, the API backend parses the pre-signature notification evidence, the signature authentication evidence, and the post-signature notification evidence, and returns the final result.

Images