Anti-fraud short message signature authentication method and device, electronic equipment and alliance chain underlying platform

Abstract

The invention relates to an anti-fraud short message signature authentication method and device, electronic equipment and an alliance chain bottom layer platform. The method comprises the following steps: receiving contract parameters of a short message contract uploaded by a short message service provider in a target service group; packaging the contract parameters into blocks and uploading the blocks; receiving a digital signature of the target enterprise for the contract parameter; packaging the digital signature of the target enterprise for the contract parameter into a block and uploading the block, and configuring the contract state of the short message contract as a confirmed state; receiving the authorization information of the telecom operator for the short message contract, packaging the authorization information of the telecom operator for the short message contract into a block, and uploading the block; and when the short message service provider, the target enterprise and the telecom operator monitor that the on-chain event of the block chain of the target service group contains the authorization information of the telecom operator for the short message contract, confirming that the short message contract is signed and authenticated. Therefore, the alliance chain can be utilized to ensure that any data change needs to be agreed by most consensus nodes, the contract data tampering cost is improved, and the short message signature security is improved.

Description

Technical Field

[0001] This application relates to the field of SMS signature authentication technology, and in particular to an anti-fraud SMS signature authentication method, device, electronic device, and consortium blockchain underlying platform. Background Technology

[0002] SMS signature authentication is a key technology in the mobile communications field, primarily used to verify the authenticity of SMS senders and prevent security threats such as spam and fraudulent messages. As e-commerce, financial payments, and other services increasingly rely on SMS for identity verification and service notifications, the importance of SMS signature authentication technology is becoming increasingly apparent. Traditional SMS signature authentication schemes mainly rely on centralized public key infrastructure (PKI) or identity-based cryptography (IBC), but they face numerous challenges in handling cross-institutional collaboration, trusted data traceability, and high-concurrency scenarios.

[0003] Existing SMS signature authentication technologies mostly employ various forms of centralized or semi-centralized architectures, which suffer from single-point-of-failure risks, low efficiency in cross-institutional auditing, and insufficient data privacy protection. Especially in scenarios requiring collaboration among telecom operators, SMS service providers, and enterprise customers, existing solutions struggle to ensure efficient authentication while simultaneously achieving process transparency, data immutability, and operational traceability. Furthermore, enterprises and SMS service providers expect a degree of privacy protection during contract signature authentication to prevent unfair competition from peers. Summary of the Invention

[0004] Therefore, it is necessary to provide a fraud-proof SMS signature authentication method, device, electronic device, and consortium blockchain underlying platform to address the aforementioned technical issues. This platform can replace single-point trust dependence with a distributed trust model and utilize the consensus mechanism of the consortium blockchain to ensure that any data change requires the unanimous consent of a majority of authorized nodes. This increases the cost of tampering or malicious behavior from attacking a single center to simultaneously breaching multiple independent institutional nodes, fundamentally changing the attacker's cost-benefit calculation and significantly improving the security of SMS signatures.

[0005] According to a first aspect of certain exemplary embodiments of this disclosure, a fraud-proof SMS signature authentication method is provided, applied to a consortium blockchain underlying platform, comprising: receiving contract parameters of an SMS contract signed with a target enterprise uploaded by an SMS service provider in a target business group; packaging the contract parameters into a first block and uploading the first block to the blockchain of the target business group; receiving a digital signature of the contract parameters from the target enterprise, wherein, when the target enterprise detects that a first on-chain event of the blockchain contains contract parameters, it verifies the contract parameters in the first block and digitally signs the contract parameters after the verification is passed; and packaging the digital signature of the contract parameters from the target enterprise into a block. The system packages the SMS contract into a second block and uploads it to the blockchain of the target business group, configuring the contract status of the SMS contract to "confirmed". It then receives authorization information from the telecom operator for the SMS contract, packages this authorization information into a third block, and uploads it to the blockchain of the target business group. Specifically, the telecom operator authorizes the SMS contract when it detects an event in the second on-chain event of the blockchain indicating a confirmed contract status. Finally, the SMS service provider, the target enterprise, and the telecom operator confirm that the SMS contract has been signed and authenticated when they detect the third on-chain event of the blockchain of the target business group containing the third block.

[0006] In some exemplary embodiments, an anti-fraud SMS signature authentication method further includes: receiving an SMS template of an SMS contract uploaded by a target enterprise; packaging the SMS template into a fourth block and uploading the fourth block to the blockchain of the target business group; receiving the preliminary review result of the SMS service provider on the SMS template in the fourth block, wherein when the target enterprise detects that the SMS template is included in the fourth on-chain event of the blockchain, it verifies the SMS template in the fourth block and performs a preliminary review of the SMS template after the verification is passed; packaging the preliminary review result of the SMS service provider on the SMS template in the fourth block into a fifth block and uploading the fifth block to the target business group. The blockchain of the business group; the final review result of the telecom operator on the SMS template in the fourth block, wherein when the telecom operator hears the fifth on-chain event of the blockchain containing the preliminary review result, it verifies the SMS template in the fourth block and performs the final review of the SMS template after the verification is passed; the final review result of the telecom operator on the SMS template in the fourth block is packaged into the sixth block and uploaded to the blockchain of the target business group; wherein when the SMS service provider, the target enterprise and the telecom operator hear the sixth on-chain event of the target business group's blockchain containing the fifth and sixth blocks, they confirm that the SMS template has been certified.

[0007] In some exemplary embodiments, the SMS service provider, the target enterprise, and the telecommunications operator confirm successful anti-fraud SMS signature authentication upon confirming that the SMS contract has been signed and authenticated and the SMS template has been authenticated.

[0008] In some exemplary embodiments, an anti-fraud SMS signature authentication method further includes: after verifying the legitimate identities of the SMS service provider, the telecom operator, and the target enterprise through the node management contract of the consortium blockchain underlying platform, constructing the SMS service provider, the telecom operator, and the target enterprise into the target business group through the multi-group architecture of the consortium blockchain underlying platform.

[0009] In some exemplary embodiments, a fraud-proof SMS signature authentication method further includes: configuring a contract information data structure for the SMS contract in a smart contract of the blockchain of the target business group; wherein, the SMS service provider uploads contract parameters based on the contract information data structure, the target enterprise uploads a digital signature based on the contract information data structure, and the telecommunications operator uploads authorization information based on the contract information data structure.

[0010] In some exemplary embodiments, the SMS service provider uploads contract parameters through the uploadContract method of the smart contract. The contract parameters enter the transaction pool of the consensus nodes of the target business group. The uploadContract method is a custom-encapsulated smart contract deployment method. The master node in the consortium blockchain underlying platform, which dynamically confirms based on the consensus algorithm, packages the contract parameters into a first block and broadcasts the first block to each consensus node of the consortium blockchain underlying platform for verification. After the consensus nodes verify the first block, they upload it to the blockchain of the target business group. After the uploadContract method is successfully executed, the smart contract triggers the first on-chain event.

[0011] In some exemplary embodiments, the target enterprise calls the `confirmContract` method of the smart contract to upload a digital signature. The digital signature enters the transaction pool of the consensus nodes of the target business group. The `confirmContract` method is a custom-encapsulated auxiliary method for verifying the contract deployment result. The new master node in the consortium blockchain underlying platform, dynamically confirmed based on the consensus algorithm, packages the digital signature into a second block and broadcasts the second block to each consensus node of the consortium blockchain underlying platform for verification. After the consensus nodes verify the block, the second block is uploaded to the blockchain of the target business group. After the `confirmContract` method is successfully executed, the smart contract triggers a second on-chain event, which includes an event for the `ContractConfirmed` method, a custom-encapsulated method for confirming the contract deployment result. When the telecom operator detects the `ContractConfirmed` method event, it authorizes the SMS contract.

[0012] According to a second aspect of certain exemplary embodiments of this disclosure, an anti-fraud SMS signature authentication device is provided, applied to a consortium blockchain underlying platform, comprising: a first receiving module, configured to receive contract parameters of an SMS contract signed with a target enterprise uploaded by an SMS service provider in a target business group; a first uploading module, configured to package the contract parameters into a first block and upload the first block to the blockchain of the target business group; a second receiving module, configured to receive a digital signature of the contract parameters by the target enterprise, wherein, when the target enterprise detects that a first on-chain event of the blockchain contains contract parameters, it verifies the contract parameters in the first block and digitally signs the contract parameters after the verification is passed; the second uploading module is configured to receive the target... The enterprise packages the digital signature of the contract parameters into a second block and uploads the second block to the blockchain of the target business group, and configures the contract status of the SMS contract to be confirmed. The third receiving module is used to receive the authorization information of the telecom operator for the SMS contract, package the authorization information of the telecom operator into a third block, and upload the third block to the blockchain of the target business group. Among them, the telecom operator authorizes the SMS contract when it hears an event in the second chain event of the blockchain that includes the contract status as confirmed. When the SMS service provider, the target enterprise, and the telecom operator hear the third chain event of the blockchain of the target business group that includes the third block, they confirm that the SMS contract has been signed and authenticated.

[0013] According to a third aspect of certain exemplary embodiments of the present disclosure, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the above methods.

[0014] According to a fourth aspect of certain exemplary embodiments of this disclosure, a consortium blockchain underlying platform is provided. The consortium blockchain underlying platform includes multiple blockchain nodes, including nodes of an SMS service provider, a target enterprise, and a telecommunications operator within a target business group. The multiple blockchain nodes also include a master node dynamically confirmed based on a consensus algorithm. The SMS service provider uploads the contract parameters of the SMS contract signed with the target enterprise to the target business group. The master node packages the contract parameters into a first block and uploads the first block to the blockchain of the target business group. When the target enterprise detects that a first on-chain event on the blockchain contains contract parameters, it processes the first block... The contract parameters are verified, and upon successful verification, the contract parameters are digitally signed and uploaded to the target business group. The master node packages the target enterprise's digital signature of the contract parameters into a second block and uploads the second block to the blockchain of the target business group, configuring the contract status of the SMS contract to "confirmed." When the telecom operator detects an event on the second chain of the blockchain that indicates the contract status is "confirmed," it authorizes the SMS contract and uploads the authorization information of the SMS contract to the target business group. The master node packages the telecom operator's authorization information of the SMS contract into a third block and uploads the third block to the blockchain of the target business group. Specifically, when the SMS service provider, the target enterprise, and the telecom operator detect a third block in the third chain of the blockchain of the target business group, they confirm that the SMS contract has been signed and authenticated.

[0015] The aforementioned anti-fraud SMS signature authentication method, device, electronic device, and consortium blockchain underlying platform include: receiving contract parameters of an SMS contract signed with a target enterprise, uploaded by an SMS service provider in a target business group; packaging the contract parameters into a first block and uploading the first block to the blockchain of the target business group; receiving the target enterprise's digital signature on the contract parameters, wherein, when the target enterprise detects that the first on-chain event of the blockchain contains the contract parameters, it verifies the contract parameters in the first block and digitally signs the contract parameters after the verification is successful; packaging the target enterprise's digital signature on the contract parameters into a second block and uploading the second block to the blockchain of the target business group, and configuring the contract status of the SMS contract to a confirmed state; receiving authorization information of the telecommunications operator for the SMS contract, packaging the telecommunications operator's authorization information of the SMS contract into a third block and uploading the third block to the blockchain of the target business group; wherein, when the telecommunications operator detects that the second on-chain event of the blockchain contains an event with the contract status as confirmed, it authorizes the SMS contract; wherein, when the SMS service provider, the target enterprise, and the telecommunications operator detect that the third on-chain event of the blockchain of the target business group contains the third block, they confirm that the SMS contract has been signed and authenticated. Therefore, a distributed trust model can replace single-point trust dependence. The consensus mechanism of the consortium blockchain built on the underlying platform ensures that any change to contract data requires the unanimous agreement of a majority of consensus nodes. This increases the cost of tampering or malicious behavior from attacking a single center to simultaneously breaching multiple independent institutional nodes, fundamentally changing the attacker's cost-benefit calculation and significantly improving the security of SMS signatures. Attached Figure Description

[0016] Figure 1 This is a schematic diagram illustrating an application scenario of an anti-fraud SMS signature authentication method as one of the exemplary embodiments of this disclosure. Figure 2 This is a flowchart illustrating an anti-fraud SMS signature authentication method as one of the exemplary embodiments of this disclosure; Figure 3 This is a flowchart illustrating the specific business process of contract signature authentication in some exemplary embodiments of this disclosure; Figure 4 This is a flowchart illustrating the SMS template review process in some exemplary embodiments of this disclosure; Figure 5 This is a structural block diagram of an anti-fraud SMS signature authentication device in some other exemplary embodiments of this disclosure; Figure 6 This is a diagram illustrating the internal structure of an electronic device in some other exemplary embodiments of this disclosure. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0018] The following detailed descriptions are provided to aid the reader in gaining a comprehensive understanding of the methods, apparatus, electronic devices, storage media, and / or computer program products described herein. However, upon understanding the disclosure of this disclosure, various changes, modifications, and equivalents of the methods, apparatus, storage media, and / or computer program products described herein will become apparent. For example, the order of operations described herein is merely illustrative and is not limited to those orders set forth herein, but may be changed as will become clear upon understanding the disclosure of this disclosure, except for operations that must occur in a specific order. Furthermore, for clarity and conciseness, descriptions of features known in the art may be omitted.

[0019] The features described herein may be implemented in different forms and should not be construed as limited to the examples described herein. Rather, the examples described herein are provided only to illustrate some of the many feasible ways of implementing the methods, electronic devices, and / or storage media described herein, many of which will become clear upon understanding this disclosure.

[0020] The terminology used herein is for the purpose of describing various examples only and is not intended to limit disclosure. Unless the context clearly indicates otherwise, the singular form is intended to include the plural form as well. The terms “comprising,” “including,” and “having” indicate the presence of the described features, quantities, operations, components, elements, and / or combinations thereof, but do not exclude the presence or addition of one or more other features, quantities, operations, components, elements, and / or combinations thereof. Unless otherwise stated, “ / ” means “or,” for example, A / B can mean A or B; “and / or” in the text is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can mean: A alone, A and B simultaneously, and B alone. Furthermore, in the description of embodiments of the invention, “multiple” means two or more.

[0021] Unless otherwise defined, all terms used herein (including technical and scientific terms) shall have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains upon understanding this disclosure. Unless expressly defined herein, terms (such as those defined in a general dictionary) shall be interpreted as having a meaning consistent with their meaning in the context of the relevant field and in this disclosure, and shall not be interpreted in an idealized or overly formalistic manner.

[0022] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in some of the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0023] Furthermore, in the description of the examples, detailed descriptions of well-known related structures or functions will be omitted when it is believed that such detailed descriptions would lead to a vague interpretation of this disclosure.

[0024] In the following description, embodiments will be described in detail with reference to the accompanying drawings. However, embodiments may be implemented in various forms and are not limited to the examples described herein.

[0025] In some exemplary embodiments of this disclosure, a method for fraud-proof SMS signature authentication is provided, applied to a consortium blockchain underlying platform. A method for fraud-proof SMS signature authentication is applied to, for example... Figure 1 The application environment shown. For example... Figure 1As shown, the consortium blockchain underlying platform is configured with multiple nodes, such as node 101, node 102, node 103, node 104, node 105, and node 106. These nodes communicate with each other via the network. A target business group 110 is constructed using the multi-group architecture of the consortium blockchain underlying platform. Target business group 110 includes nodes 101, 102, and 103. Node 101 corresponds to the SMS service provider, node 102 corresponds to the target enterprise, and node 103 corresponds to the telecom operator. The consortium blockchain underlying platform dynamically determines the master node through a consensus algorithm; for example, the master node could be node 104. The master node of the consortium blockchain underlying platform executes an anti-fraud SMS signature authentication method. Specifically, the master node receives the contract parameters of the SMS contract signed with the target enterprise, uploaded by the SMS service provider in target business group 110; packages the contract parameters into a first block and uploads the first block to the blockchain of the target business group; receives the digital signature of the contract parameters from the target enterprise, wherein when the target enterprise detects that the first on-chain event of the blockchain contains the contract parameters, it verifies the contract parameters in the first block and digitally signs the contract parameters after the verification is successful; packages the digital signature of the contract parameters from the target enterprise into a second block and uploads the second block to the blockchain of the target business group, and configures the contract status of the SMS contract to the confirmed state; receives the authorization information of the telecom operator for the SMS contract, packages the authorization information of the telecom operator for the SMS contract into a third block and uploads the third block to the blockchain of the target business group; wherein the telecom operator authorizes the SMS contract when it detects that the second on-chain event of the blockchain contains an event with the contract status of confirmed; wherein when the SMS service provider, the target enterprise, and the telecom operator detect that the third on-chain event of the blockchain of the target business group contains the third block, they confirm that the SMS contract has been signed and authenticated.

[0026] In some exemplary embodiments of this disclosure, such as Figure 2 As shown, a method for fraud prevention SMS signature authentication is provided. Taking the application of this method to the master node of a consortium blockchain underlying platform as an example, the method includes the following steps: Step S201: Receive the contract parameters of the SMS contract signed with the target enterprise uploaded by the SMS service provider in the target business group.

[0027] Specifically, the underlying platform of the consortium blockchain can be the FISCO BCOS platform, and the contract parameter can be the contract hash value. The SMS service provider uploads the contract hash value of the SMS contract signed with the target enterprise to the target business group. Other nodes in the target business group, such as the target enterprise and the telecom operator, can share the uploaded contract hash value.

[0028] In one example of this embodiment, before step S201, the following steps are included: after verifying the legitimate identities of the SMS service provider, the telecom operator, and the target enterprise through the node management contract of the consortium blockchain underlying platform, the SMS service provider, the telecom operator, and the target enterprise are constructed into the target business group through the multi-group architecture of the consortium blockchain underlying platform.

[0029] Specifically, to achieve secure, efficient, and auditable collaborative authentication between enterprises, SMS service providers, and telecom operators, while strictly protecting sensitive information such as business relationships, the node management contract of the consortium blockchain platform verifies the legitimate identities of SMS service providers, telecom operators, and target enterprises. Then, a multi-group architecture on the consortium blockchain platform achieves business data isolation. Each business relationship forms an independent business group; for example, enterprise A, SMS service provider B, and telecom operator form a target business group. Ledger data is shared within each group, while data is completely isolated between groups. This mechanism ensures the privacy of business partnerships while allowing the three major telecom operators to participate in multiple groups as joint verification nodes. The implementation of the group architecture relies on the group genesis file configuration, which defines basic information such as the group consensus algorithm and node list. By configuring different group IDs, the same physical node can participate in multiple logically independent business groups, achieving efficient resource utilization and natural data isolation.

[0030] Step S202: Package the contract parameters into a first block and upload the first block to the blockchain of the target business group.

[0031] In this embodiment, the SMS service provider broadcasts the transaction constructed using hash parameters. This transaction is broadcast to the entire P2P network of the consortium blockchain's underlying platform and enters the transaction pool of all consensus nodes. Within the consortium blockchain's underlying platform, the master node for the current round is determined according to the RPBFT consensus algorithm. The master node collects the transaction from the transaction pool, packages it into a new first block, and then broadcasts this first block to other consensus nodes for verification. Once consensus is reached, the first block is uploaded to the blockchain of the target business group.

[0032] In one example of this embodiment, before step S202, the method further includes the step of configuring the contract information data structure of the SMS contract in the smart contract of the blockchain of the target business group; wherein, the SMS service provider uploads contract parameters based on the contract information data structure, the target enterprise uploads digital signature based on the contract information data structure, and the telecom operator uploads authorization information based on the contract information data structure.

[0033] In this example, a new `ContractInfo` struct instance is created in the storage space of the smart contract on the target business group's blockchain to configure the contract information data structure for SMS contracts. The `ContractInfo` data structure is defined in the `ContractAuth.sol` smart contract; it is a standard, public data template visible to all nodes on the network after deployment. Any node, such as a telecom operator, SMS service provider, or the target enterprise, will have a copy of the same `ContractInfo` data structure when running this smart contract locally.

[0034] The ContractInfo data structure is defined as follows: struct ContractInfo { bytes32 contractHash; / / Contract hash value; address enterprise; / / Enterprise address; address serviceProvider; / / Service provider address; address[] operators; / / List of operator addresses; ContractStatus status; / / Contract status; uint256 confirmTime; / / Confirmation timestamp; uint256 authorizeTime; / / Authorization timestamp; }

[0035] In addition, smart contracts predefine data structures for contract states. For example, the contract state definition is: `enumContractStatus { Pending, Confirmed, Authorized, Rejected}`. After the transactions in the first block are executed by each node, the `uploadContract` function is executed, creating a new `ContractInfo` structure instance in the smart contract's storage space and initializing its contract state to `Pending`. At this point, the contract information has been "uploaded" to the blockchain.

[0036] Step S203: Receive the digital signature of the contract parameters from the target enterprise. When the target enterprise detects that the first on-chain event of the blockchain contains the contract parameters, it verifies the contract parameters in the first block and digitally signs the contract parameters after the verification is successful.

[0037] In this embodiment, during the enterprise confirmation stage: the target enterprise confirms the SMS contract by comparing contract parameters, such as the contract hash value. After confirming that the SMS contract is a valid contract, the enterprise uses its private key to sign the contract hash.

[0038] Specifically, after the uploadContract function executes successfully, the smart contract triggers a first on-chain event. The target company's nodes can continuously listen for these events to "discover" contracts awaiting confirmation. Subsequently, the target company's nodes construct a new transaction and attach a digital signature.

[0039] Step S204: Package the target enterprise's digital signature on the contract parameters into a second block and upload the second block to the blockchain of the target business group, and configure the contract status of the SMS contract to the confirmed status.

[0040] Specifically, the master node constructs a new transaction for the target enterprise node, repeats the aforementioned propagation, packaging, and consensus process, and after verification by the consensus node, packages the digital signatures of the contract parameters into a second block and uploads the second block to the target business group's blockchain. Furthermore, a timestamp is recorded: when the second block containing the confirmed transaction is formed, the timestamp in the block header of that second block is considered an authoritative and immutable time record. When the smart contract code executes the `confirmContract` method, it automatically records this timestamp in the `confirmTime` field of the `ContractInfo` structure. This timestamp is jointly confirmed by the consensus mechanism.

[0041] Step S205: Receive authorization information from the telecom operator for the SMS contract, package the authorization information into a third block, and upload the third block to the blockchain of the target business group; wherein, the telecom operator authorizes the SMS contract when it detects an event on the second chain of the blockchain that indicates the contract status is confirmed.

[0042] Specifically, when SMS service providers, target enterprises, and telecom operators detect that the third-chain event of the target business group's blockchain contains a third block, they confirm that the SMS contract has been signed and authenticated.

[0043] In this embodiment, when the target enterprise calls the `confirmContract` method and successfully signs the contract hash value, the smart contract execution changes the contract state when the transaction is packaged and uploaded to the blockchain after consensus, for example, changing it from `Pending` to `Confirmed`. Simultaneously, the smart contract can be designed to trigger a specific second on-chain event at this moment, such as the `ContractConfirmed(bytes32 contractHash)` on-chain event. The telecom operator's node program continuously and proactively listens for events related to itself on the blockchain within the target business group, filtering and capturing the `ContractConfirmed` on-chain event.

[0044] Telecom operator authorization phase: The telecom operator's node program calls the `authorizeContract` method to finally authorize the confirmed SMS contract. The contract status only changes to "authorized" after all telecom operators specified in the SMS contract have completed their authorization. For SMS service providers sending SMS messages with a company's signature, commercial SMS messages can only be successfully sent through the telecom operator's SMS interface when the contract status is authorized.

[0045] It should be noted that after the telecom operator completes the final authorization of the SMS contract, the telecom operator's authorization information for the SMS contract is packaged into a third-party block and uploaded to the blockchain. At this time, the smart contract triggers an event on the third-party blockchain. Both the target enterprise in the target business group and the SMS service provider can listen to the event on the third-party blockchain, thereby confirming that the telecom operator has completed the final authorization of the SMS contract, and thus confirming that the SMS contract has completed signature authentication. After confirming that the SMS contract has completed signature authentication, the SMS service provider, the target enterprise, and the telecom operator can subsequently send commercial SMS messages to the target enterprise. The SMS sending process is as follows: the target enterprise sends an SMS message, the SMS service provider's interface receives and forwards it to the relevant telecom operator's interface, the telecom operator receives the SMS message, and then reaches the user.

[0046] Preferably, in one embodiment, the SMS contract signature authentication also requires the authentication of the SMS contract's SMS template. The specific process for authenticating the SMS contract's SMS template is as follows: Before or after step S205 above, an anti-fraud SMS signature authentication method further includes the following steps: receiving an SMS template of an SMS contract uploaded by a target enterprise; packaging the SMS template into a fourth block and uploading the fourth block to the blockchain of the target business group; receiving the preliminary review result of the SMS service provider on the SMS template in the fourth block, wherein, when the target enterprise detects that the fourth on-chain event of the blockchain contains an SMS template, it verifies the SMS template in the fourth block and performs a preliminary review of the SMS template after the verification is passed; packaging the preliminary review result of the SMS service provider on the SMS template in the fourth block into a fifth block and uploading the fifth block. The process involves: accessing the blockchain of the target business group; obtaining the final review results of the SMS templates in the fourth block from the telecom operator, whereby the telecom operator verifies the SMS templates in the fourth block when it detects the preliminary review results in the fifth on-chain event of the blockchain, and conducts a final review of the SMS templates after the verification is passed; packaging the final review results of the SMS templates in the fourth block into a sixth block and uploading the sixth block to the blockchain of the target business group; and confirming that the SMS templates have been certified when the SMS service provider, the target enterprise, and the telecom operator detect that the sixth on-chain event of the blockchain of the target business group contains both the fifth and sixth blocks.

[0047] Among them, SMS service providers, target enterprises, and telecom operators confirm successful anti-fraud SMS signature authentication when they confirm that the SMS contract has been signed and authenticated and the SMS template has been authenticated.

[0048] In this embodiment, in addition to contract authorization (i.e., the SMS service provider uploading the contract, the target enterprise's signature authentication, and the telecom operator's authorization), SMS template authentication is also required. That is, the target enterprise initiates the uploading of the SMS template to the blockchain, and the SMS service provider and telecom operator review the SMS content on the blockchain. Only after the review is passed can the SMS be sent according to the above process.

[0049] Specifically, a master node, dynamically and randomly elected based on a consensus algorithm, receives an SMS template sent by the target company. After obtaining the consensus verification results from all consensus nodes, it writes the SMS template into the Nth block of the blockchain. The SMS service provider and the telecom operator monitor on-chain events within the target business group. Upon detecting the on-chain event of the target company sending the SMS template, they respectively review the Nth block. If the review is successful, they generate new blocks N+1 and N+2 respectively, updating the review status field in the template structure via a function and simultaneously sending a review success / failure message. The target company listens to messages within the target business group and takes subsequent actions.

[0050] More preferably, in steps S201 and S202 above, the SMS service provider uploads contract parameters through the uploadContract method of the smart contract. The contract parameters enter the transaction pool of the consensus node of the target business group. The uploadContract method is a custom-encapsulated smart contract deployment method. The master node in the consortium blockchain underlying platform, which dynamically confirms based on the consensus algorithm, packages the contract parameters into a first block and broadcasts the first block to each consensus node of the consortium blockchain underlying platform for verification. After the consensus nodes verify the first block, it is uploaded to the blockchain of the target business group. After the uploadContract method is successfully executed, the smart contract triggers the first on-chain event.

[0051] Specifically, the SMS service provider, through its node, calls the `uploadContract` method of the `ContractAuth.sol` smart contract to upload and store parameters such as the hash value of the contract signed with the target enterprise on the blockchain, thus forming a transaction. At this stage, the `onlyServiceProvider` decorator ensures that only legitimate SMS service providers can perform this operation. The master node in the consortium blockchain platform, dynamically confirmed based on a consensus algorithm, packages the contract parameters into the first block and uploads it to the blockchain after verification by the consensus nodes.

[0052] More preferably, in steps S203, S204, and S205 above, the target enterprise calls the `confirmContract` method of the smart contract to upload a digital signature. The digital signature enters the transaction pool of the consensus nodes of the target business group. The `confirmContract` method is a custom-encapsulated auxiliary method for verifying the contract deployment result. The new master node in the consortium blockchain underlying platform, dynamically confirmed based on the consensus algorithm, packages the digital signature into a second block and broadcasts the second block to each consensus node of the consortium blockchain underlying platform for verification. After verification by each consensus node, the second block is uploaded to the blockchain of the target business group. Upon successful execution of the `confirmContract` method, the smart contract triggers a second on-chain event, which includes an event for the `ContractConfirmed` method, a custom-encapsulated method for confirming the contract deployment result. When the telecom operator detects the `ContractConfirmed` method event, it authorizes the SMS contract.

[0053] Specifically, the target company calls the `confirmContract` method to confirm the contract hash value. The smart contract verifies the validity of the target company's digital signature using the `ecrecover` function, ensuring the non-repudiation of the target company's actions. Once the target company successfully signs the contract hash value using the `confirmContract` method, the smart contract execution changes the contract state when the transaction is packaged and uploaded to the blockchain after consensus. For example, it changes from Pending to Confirmed. Simultaneously, the smart contract can be designed to trigger a specific second-chain event at this moment, such as the `ContractConfirmed(bytes32 contractHash)` on-chain event. The telecom operator's node program continuously and proactively listens for relevant events on the blockchain within the target business group, filtering and capturing the `ContractConfirmed` on-chain event.

[0054] Telecom operator authorization phase: The telecom operator's node program calls the authorizeContract method to give final authorization to the confirmed SMS contract.

[0055] Specifically, the telecom operator initiates an authorization transaction: After receiving the notification, the telecom operator's system calls the `authorizeContract` method through its nodes to form a new transaction. This transaction is broadcast to the network, packaged into a new block by the current round's master node, and verified and confirmed by all network nodes via the RPBFT consensus algorithm. The code logic of the `authorizeContract` function in the smart contract includes the instruction to modify the contract status to "authorized". Simultaneously, it executes a line of code similar to `contractInfo.authorizeTime = block.timestamp`. Here, `block.timestamp` is a global variable representing the timestamp at which the current block is recognized by consensus. This timestamp is proposed by the master node, but the final value must be recognized by all consensus nodes, thus possessing consistent authority across the entire network. Once the block is successfully uploaded to the blockchain, this `authorizeTime`, assigned by the block's timestamp, is permanently and immutably recorded in the contract's `ContractInfo` structure.

[0056] In summary, the anti-fraud SMS signature authentication method proposed in this application mainly includes two aspects. One aspect is the contract signature authentication agreement and process, and the other aspect is the SMS template review agreement and cross-review mechanism.

[0057] Firstly, the contract signature authentication process and procedures: The smart contract for contract signature authentication (ContractAuth.sol) is responsible for managing the notarization and authorization of the cooperation relationship between the target enterprise and the SMS service provider. Its core data structure and interface design are as follows: / / Definition of contract status: enum ContractStatus { Pending, Confirmed, Authorized, Rejected}.

[0058] / / Contract information structure: struct ContractInfo { bytes32 contractHash; / / Contract hash value; address enterprise; / / Enterprise address; address serviceProvider; / / Service provider address; address[] operators; / / List of operator addresses; ContractStatus status; / / Contract status; uint256 confirmTime; / / Confirmation timestamp; uint256 authorizeTime; / / Authorization timestamp; }

[0059] / / Core method interface: function uploadContract(bytes32 _hash, address _enterprise) externalreturns(bool); function confirmContract(bytes32 _hash, bytes memory _signature)external returns(bool); function authorizeContract(bytes32 _hash) external returns(bool); function getContractStatus(bytes32 _hash) public view returns(ContractStatus); Specifically, such as Figure 3As shown, the specific business process for contract signature authentication includes: Contract hash notarization phase: The SMS service provider calls the uploadContract method to upload the hash value of the contract signed with the target company to the blockchain for notarization. This phase uses the onlyServiceProvider decorator to ensure that only legitimate service providers can perform this operation.

[0060] Enterprise Confirmation Phase: The target enterprise confirms the SMS contract by comparing its hash value. After confirming the contract is valid, the enterprise signs the hash using its private key and calls the `confirmContract` method for confirmation. The smart contract verifies the signature validity using the `ecrecover` function, ensuring the non-repudiation of the confirmation.

[0061] Telecom operator authorization phase: The telecom operator node calls the `authorizeContract` method to give final authorization to the confirmed SMS contract. The contract status only changes to "authorized" after all telecom operators specified in the SMS contract have completed authorization. For SMS service providers sending SMS messages with a company signature, commercial SMS messages can only be successfully sent through the telecom operator's SMS interface when the contract status is authorized.

[0062] Secondly, the SMS template review contract and cross-review mechanism: The smart contract (TemplateAudit.sol) for SMS template review implements a two-factor authentication mechanism to ensure that SMS content complies with operator policies and service provider standards. / / Review status definition: enum AuditStatus { Submitted, SPAuditing, OPEauditing, Approved, Rejected}.

[0063] / / Template information structure: struct TemplateInfo { string content; / / Template content; address enterprise; / / Submit the enterprise; AuditStatus status; / / Audit status; bool spApproved; / / Service provider review result; bool operatorApproved; / / Operator's approval result; string rejectReason; / / Reason for rejection;}

[0064] / / Core method interface: function submitTemplate(string memory _content) external returns(bytes32); function auditBySP(bytes32 _templateId, bool _approved) externalreturns(bool); function auditByOperator(bytes32 _templateId, bool _approved)external returns(bool); function getTemplateStatus(bytes32 _templateId) public view returns(AuditStatus).

[0065] Specifically, such as Figure 4 As shown, the SMS template approval process is managed using a state machine model: SMS template submission: The target company calls the submitTemplate method to submit the SMS template, and the initial status is "Submitted". This process generates a TemplateSubmitted event, notifying relevant parties that a new template is pending review.

[0066] SMS service provider review: The SMS service provider uses the `auditBySP` method to conduct a preliminary review, and the review results are recorded on the blockchain. At this stage, the service provider primarily assesses whether the template content complies with the cooperation agreement between the enterprise and the service provider.

[0067] Telecom operator review: The telecom operator uses the `auditByOperator` method for final review, focusing on whether the template complies with telecommunications industry regulations and anti-fraud requirements. After approval, the review compares whether the SMS service provider has genuinely signed a contract with the enterprise. Once a contract is confirmed, the template status changes to "Approved" and it can be used for SMS sending.

[0068] Furthermore, this application also provides a consortium blockchain underlying platform. In one embodiment, the consortium blockchain underlying platform includes multiple blockchain nodes, including nodes of SMS service providers, nodes of target enterprises, and nodes of telecommunications operators in the target business group. The multiple blockchain nodes also include a master node dynamically confirmed based on a consensus algorithm. The SMS service provider uploads the contract parameters of the SMS contract signed with the target enterprise to the target business group. The master node packages the contract parameters into a first block and uploads the first block to the blockchain of the target business group. When the target enterprise detects that the first on-chain event contains contract parameters, it verifies the contract parameters in the first block, digitally signs the contract parameters after successful verification, and uploads the digital signature to the target business group. The master node packages the target enterprise's digital signature on the contract parameters into a second block and uploads the second block to the blockchain of the target business group, and configures the contract status of the SMS contract to be confirmed. When the telecom operator detects an event in the second chain of the blockchain that indicates the contract status is confirmed, it authorizes the SMS contract and uploads the authorization information of the SMS contract to the target business group. The master node packages the telecom operator's authorization information for the SMS contract into a third block and uploads the third block to the blockchain of the target business group. When the SMS service provider, the target enterprise, and the telecom operator detect a third block in the third chain of the blockchain of the target business group, they confirm that the SMS contract has been signed and authenticated.

[0069] Specifically, the underlying platform of the consortium blockchain can be the FISCO BCOS platform. The FISCO BCOS platform provides a complete set of system smart contracts at the underlying level, serving as the infrastructure for blockchain network governance. These smart contracts are automatically deployed when the blockchain network starts. The smart contracts include core modules such as the system proxy contract (SystemProxy.sol), the node management contract (NodeAction.sol), and the permission management contract (AuthorityFilter.sol). The system proxy contract serves as a unified entry point, managing the addresses of each contract through a routing table; the node management contract is responsible for maintaining network node information; and the permission management contract implements function-level access control based on a role-based permission model. See the table below for details: Contract Module Main functions effect System Agent Contract Provides contract routing services and manages system contract addresses in a unified manner. Provides addressing services for business contracts, enabling transparent contract upgrades. Node Management Contract Manage network node registration, deregistration, and status maintenance. Verify the legitimate identities of various nodes in SMS service providers, enterprises, and telecom operators. Access Management Contract Implement role-based function-level access control. Control permissions for key operations such as contract uploading and review. Full network configuration contract Manage blockchain network parameter configurations. Configure SMS service parameters, such as transaction validity period.

[0070] Based on the aforementioned consortium blockchain platform, the nodes of the SMS service provider, the target enterprise, and the telecom operator perform the operations described in the above embodiments when implementing the anti-fraud SMS signature authentication method, which will not be detailed here.

[0071] This application discloses a fraud-proof SMS signature authentication method and a consortium blockchain underlying platform, which specifically achieves the following technical effects: 1. Business data isolation based on a multi-group architecture protects the privacy of contractual information between enterprises and SMS service providers. Specifically, independent business groups are dynamically created for different "enterprise-SMS service provider" SMS services within the consortium blockchain to achieve logical isolation and privacy protection of business data. This includes group creation rules, access control mechanisms for nodes joining groups, and specific protocols for cross-group data interaction.

[0072] 2. Automated signature authentication and verification based on smart contracts protect the transparency and legitimacy of contracts and SMS messages during the sending process. Specifically, this involves a series of specific smart contract function logics and workflows. For example, the `confirmContract(bytes32 hash, bytes memory signature)` function defined in `ContractAuth.sol` contains logic for verifying the enterprise's digital signature and the logic for transitioning the contract state machine from "pending confirmation" to "confirmed." The dual-verification state machine implemented in `TemplateAuditContract.sol` specifically stipulates that the state automatically changes to "verified" only after receiving approval from two specific verifiers.

[0073] 3. A comprehensive and trustworthy traceability system for SMS anti-fraud, ensuring the transparency and traceability of all approval processes during SMS authorization and delivery. Specifically, this includes an on-chain evidence storage structure and query method for the entire operation log, from signature authorization and SMS template review to SMS delivery. Technical measures include: linking key information at each stage (such as operator identity, timestamp, and transaction hash) to form a complete and tamper-proof evidence chain; and efficiently retrieving all records throughout the entire lifecycle using an index (such as SMS ID or signature ID).

[0074] It should be understood that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order constraint on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0075] In some exemplary embodiments of this disclosure, such as Figure 5As shown, an anti-fraud SMS signature authentication device is provided, applied to a consortium blockchain underlying platform, including a first receiving module 501, a first uploading module 502, a second receiving module 503, a second uploading module 504, and a third receiving module 505. The first receiving module 501 is used to receive contract parameters of SMS contracts signed with target enterprises uploaded by SMS service providers in the target business group; the first uploading module 502 is used to package the contract parameters into a first block and upload the first block to the blockchain of the target business group; the second receiving module 503 is used to receive the digital signature of the contract parameters by the target enterprise, wherein when the target enterprise detects that the first on-chain event of the blockchain contains contract parameters, it verifies the contract parameters in the first block and digitally signs the contract parameters after the verification is successful; the second uploading module 504 is used to package the digital signature of the contract parameters by the target enterprise into a second block and... The second block is uploaded to the blockchain of the target business group, and the contract status of the SMS contract is configured as confirmed. The third receiving module 505 is used to receive the authorization information of the telecom operator for the SMS contract, package the authorization information of the telecom operator for the SMS contract into a third block, and upload the third block to the blockchain of the target business group. Among them, the telecom operator authorizes the SMS contract when it hears an event in the second chain event of the blockchain that includes the contract status as confirmed. When the SMS service provider, the target enterprise, and the telecom operator hear the third chain event of the blockchain of the target business group that includes the third block, they confirm that the SMS contract has been signed and authenticated.

[0076] In some exemplary embodiments, an anti-fraud SMS signature authentication device further includes an SMS template authentication module, used to receive SMS templates of SMS contracts uploaded by a target enterprise; package the SMS templates into a fourth block and upload the fourth block to the blockchain of the target business group; receive the preliminary review result of the SMS service provider on the SMS templates in the fourth block, wherein when the target enterprise detects that the fourth on-chain event of the blockchain contains an SMS template, it verifies the SMS templates in the fourth block and performs a preliminary review of the SMS templates after the verification is passed; package the preliminary review result of the SMS service provider on the SMS templates in the fourth block into a fifth block and upload the fifth block... Upload the SMS template to the blockchain of the target business group; the final review result of the telecom operator on the SMS template in the fourth block, wherein when the telecom operator hears the fifth on-chain event of the blockchain containing the preliminary review result, it verifies the SMS template in the fourth block and performs the final review of the SMS template after the verification is passed; package the final review result of the telecom operator on the SMS template in the fourth block into the sixth block and upload the sixth block to the blockchain of the target business group; wherein when the SMS service provider, the target enterprise and the telecom operator hear the sixth on-chain event of the blockchain of the target business group containing the fifth and sixth blocks, they confirm that the SMS template has been certified.

[0077] In some exemplary embodiments, the SMS service provider, the target enterprise, and the telecommunications operator confirm successful anti-fraud SMS signature authentication upon confirming that the SMS contract has been signed and authenticated and the SMS template has been authenticated.

[0078] In some exemplary embodiments, an anti-fraud SMS signature authentication device further includes a business group construction module, which is used to construct the SMS service provider, the telecom operator, and the target enterprise into the target business group through the multi-group architecture of the consortium blockchain underlying platform after verifying the legitimate identities of the SMS service provider, the telecom operator, and the target enterprise through the node management contract of the consortium blockchain underlying platform.

[0079] In some exemplary embodiments, an anti-fraud SMS signature authentication device further includes a contract data structure configuration module, used to configure the contract information data structure of the SMS contract in the smart contract of the blockchain of the target business group; wherein, the SMS service provider uploads contract parameters based on the contract information data structure, the target enterprise uploads a digital signature based on the contract information data structure, and the telecommunications operator uploads authorization information based on the contract information data structure.

[0080] In some exemplary embodiments, the SMS service provider uploads contract parameters through the uploadContract method of the smart contract. The contract parameters enter the transaction pool of the consensus nodes of the target business group. The uploadContract method is a custom-encapsulated smart contract deployment method. The master node in the consortium blockchain underlying platform, which dynamically confirms based on the consensus algorithm, packages the contract parameters into a first block and broadcasts the first block to each consensus node of the consortium blockchain underlying platform for verification. After the consensus nodes verify the first block, they upload it to the blockchain of the target business group. After the uploadContract method is successfully executed, the smart contract triggers the first on-chain event.

[0081] In some exemplary embodiments, the target enterprise calls the `confirmContract` method of the smart contract to upload a digital signature. The digital signature enters the transaction pool of the consensus nodes of the target business group. The `confirmContract` method is a custom-encapsulated auxiliary method for verifying the contract deployment result. The new master node in the consortium blockchain underlying platform, dynamically confirmed based on the consensus algorithm, packages the digital signature into a second block and broadcasts the second block to each consensus node of the consortium blockchain underlying platform for verification. After the consensus nodes verify the block, the second block is uploaded to the blockchain of the target business group. After the `confirmContract` method is successfully executed, the smart contract triggers a second on-chain event, which includes an event for the `ContractConfirmed` method, a custom-encapsulated method for confirming the contract deployment result. When the telecom operator detects the `ContractConfirmed` method event, it authorizes the SMS contract.

[0082] For specific limitations regarding the anti-fraud SMS signature authentication device, please refer to the limitations of the anti-fraud SMS signature authentication method described above, which will not be repeated here. Each module in the aforementioned anti-fraud SMS signature authentication device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the electronic device in hardware form, or stored in the memory of the electronic device in software form, so that the processor can call and execute the operations corresponding to each module.

[0083] In some exemplary embodiments of this disclosure, an electronic device is provided, which may be a server of the master node of a consortium blockchain underlying platform, and its internal structure diagram may be as follows: Figure 5 As shown, the electronic device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database stores contract-related data, etc. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements an anti-fraud SMS signature authentication method.

[0084] Those skilled in the art will understand that Figure 6The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0085] In some exemplary embodiments of this disclosure, an electronic device is provided, including 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 the steps of an anti-fraud SMS signature authentication method as described in any of the exemplary embodiments above.

[0086] In some exemplary embodiments of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of an anti-fraud SMS signature authentication method as described in any of the exemplary embodiments above.

[0087] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0088] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0089] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for fraud-proof SMS signature authentication, characterized in that, The method, applied to the underlying platform of a consortium blockchain, includes: Receive contract parameters from SMS service providers within the target business group, showing the SMS contracts signed with the target company. The contract parameters are packaged into a first block and the first block is uploaded to the blockchain of the target business group; The target enterprise receives the digital signature of the contract parameters, wherein when the target enterprise detects that the contract parameters are included in the first on-chain event of the blockchain, it verifies the contract parameters in the first block and digitally signs the contract parameters after the verification is successful. The target enterprise's digital signature on the contract parameters is packaged into a second block and uploaded to the blockchain of the target business group. The contract status of the SMS contract is configured as confirmed. The system receives authorization information from a telecommunications operator for the SMS contract, packages this authorization information into a third block, and uploads the third block to the blockchain of the target business group. The telecommunications operator authorizes the SMS contract when it detects an event in the second chain of the blockchain that indicates the contract status is confirmed. When the SMS service provider, the target enterprise, and the telecom operator detect that the third block is included in the third-chain event of the blockchain of the target business group, they confirm that the SMS contract has been signed and authenticated.

2. The method according to claim 1, characterized in that, The method further includes: Receive the SMS template of the SMS contract uploaded by the target company; The SMS template is packaged into a fourth block and the fourth block is uploaded to the blockchain of the target business group; The system receives the initial review result of the SMS service provider on the SMS template in the fourth block. When the target enterprise detects that the SMS template is included in the fourth chain event of the blockchain, it verifies the SMS template in the fourth block and conducts an initial review of the SMS template after the verification is passed. The SMS service provider's preliminary review results of the SMS templates in the fourth block are packaged into a fifth block and the fifth block is uploaded to the blockchain of the target business group; The final review result of the telecommunications operator on the SMS template in the fourth block, wherein when the telecommunications operator detects that the preliminary review result is included in the fifth chain event of the blockchain, the telecommunications operator verifies the SMS template in the fourth block and performs a final review on the SMS template after the verification is passed; The telecommunications operator packages the final review results of the SMS templates in the fourth block into a sixth block and uploads the sixth block to the blockchain of the target business group; When the SMS service provider, the target enterprise, and the telecom operator detect that the sixth on-chain event of the blockchain of the target business group includes the fifth block and the sixth block, they confirm that the SMS template has been authenticated.

3. The method according to claim 2, characterized in that, When the SMS service provider, the target enterprise, and the telecom operator confirm that the SMS contract has been signed and authenticated and the SMS template has been authenticated, the anti-fraud SMS signature authentication is confirmed to be successful.

4. The method according to claim 1, characterized in that, The method further includes: After verifying the legitimate identities of the SMS service provider, the telecom operator, and the target enterprise through the node management contract of the underlying consortium blockchain platform, the SMS service provider, the telecom operator, and the target enterprise are constructed into the target business group through the multi-group architecture of the underlying consortium blockchain platform.

5. The method according to claim 4, characterized in that, The method further includes: Configure the contract information data structure of the SMS contract in the smart contract of the blockchain of the target business group; Specifically, the SMS service provider uploads the contract parameters based on the contract information data structure, the target enterprise uploads the digital signature based on the contract information data structure, and the telecom operator uploads the authorization information based on the contract information data structure.

6. The method according to claim 4, characterized in that, in, The SMS service provider uploads the contract parameters through the uploadContract method of the smart contract, and the contract parameters enter the transaction pool of the consensus node of the target business group. The uploadContract method is a custom-encapsulated smart contract deployment method. In the underlying platform of the consortium blockchain, the master node dynamically confirms the contract parameters based on the consensus algorithm, packages the contract parameters into a first block, and broadcasts the first block to each consensus node of the underlying platform of the consortium blockchain for verification. After the consensus nodes verify the first block, the first block is uploaded to the blockchain of the target business group. Upon successful execution of the uploadContract method, the smart contract triggers the first on-chain event.

7. The method according to claim 6, characterized in that, in, The target enterprise calls the confirmContract method of the smart contract to upload the digital signature, and the digital signature enters the transaction pool of the consensus node of the target business group. The confirmContract method is a custom-encapsulated auxiliary method for verifying the contract deployment result. The new master node in the consortium blockchain underlying platform, which is dynamically confirmed based on the consensus algorithm, packages the digital signature into a second block and broadcasts the second block to each consensus node of the consortium blockchain underlying platform for verification. After the consensus nodes have verified the second block, it is uploaded to the blockchain of the target business group. Wherein, after the confirmContract method is successfully executed, the smart contract triggers the second on-chain event, which includes an event for the ContractConfirmed method, which is a custom-encapsulated method for confirming the contract deployment result; When the telecommunications operator detects an event in the ContractConfirmed method, it authorizes the SMS contract.

8. A fraud-proof SMS signature authentication device, characterized in that, The device, applied to the underlying platform of a consortium blockchain, includes: The first receiving module is used to receive the contract parameters of the SMS contract signed with the target enterprise uploaded by the SMS service provider in the target business group. The first upload module is used to package the contract parameters into a first block and upload the first block to the blockchain of the target business group; The second receiving module is used to receive the digital signature of the contract parameters by the target enterprise, wherein when the target enterprise detects that the contract parameters are included in the first on-chain event of the blockchain, it verifies the contract parameters in the first block and digitally signs the contract parameters after the verification is passed. The second upload module is used to package the target enterprise's digital signature on the contract parameters into a second block and upload the second block to the blockchain of the target business group, and configure the contract status of the SMS contract to be confirmed. The third receiving module is used to receive authorization information from the telecom operator for the SMS contract, package the authorization information from the telecom operator for the SMS contract into a third block, and upload the third block to the blockchain of the target business group; wherein, the telecom operator authorizes the SMS contract when it detects an event in the second chain event of the blockchain that indicates the contract status is confirmed. When the SMS service provider, the target enterprise, and the telecom operator detect that the third block is included in the third-chain event of the blockchain of the target business group, they confirm that the SMS contract has been signed and authenticated.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A consortium blockchain underlying platform, characterized in that, The underlying platform of the consortium blockchain includes multiple blockchain nodes, which include nodes of SMS service providers, nodes of target enterprises, and nodes of telecom operators in the target business group. The multiple blockchain nodes also include a master node that is dynamically confirmed based on a consensus algorithm. The SMS service provider uploads the contract parameters of the SMS contract signed with the target enterprise to the target business group; The master node packages the contract parameters into a first block and uploads the first block to the blockchain of the target business group; When the target enterprise detects that the contract parameters are included in the first on-chain event of the blockchain, it verifies the contract parameters in the first block, digitally signs the contract parameters after the verification is passed, and uploads the digital signature to the target business group. The master node packages the target enterprise's digital signature on the contract parameters into a second block and uploads the second block to the blockchain of the target business group, and configures the contract status of the SMS contract to be confirmed. When the telecom operator detects an event on the second chain of the blockchain that indicates the contract status is confirmed, it authorizes the SMS contract and uploads the authorization information of the SMS contract to the target business group. The master node packages the authorization information of the telecom operator for the SMS contract into a third block and uploads the third block to the blockchain of the target business group; When the SMS service provider, the target enterprise, and the telecom operator detect that the third block is included in the third-chain event of the blockchain of the target business group, they confirm that the SMS contract has been signed and authenticated.

Images