Short message privacy protection method and device based on block chain, equipment and storage medium

Abstract

The invention relates to the technical field of information security, can be applied to the medical field and the financial science and technology field, and discloses a short message privacy protection method, device and equipment based on a block chain, and a storage medium, which are applied to payment verification and transaction confirmation scenes or remote medical consultation scenes. The method comprises the following steps: generating a sender private key and a sender public key in a trusted execution environment, and recording the sender public key in a public key warehouse on a block chain through a smart contract; when a short message sending request is received, generating an elliptic curve key pair, performing key verification, and generating a key negotiation parameter and a temporary session key; performing hierarchical encryption and assembly on the short message content, the temporary session key, the receiver identifier and the sender identifier to generate an encrypted short message packet; calculating a hash value of the encrypted short message packet as a short message identifier; and sending the encrypted short message packet to a receiver terminal for hierarchical decryption and verification. According to the invention, the security of short message privacy is improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of information security, and can be applied to the medical field and the financial technology field, and particularly relates to a short message privacy protection method and device based on a block chain, equipment and a storage medium. BACKGROUND

[0003] The existing encryption technology has obvious anti-attack layers. Although a high-strength encryption algorithm is used in the transmission process, the storage link often lacks effective protection. Poor key management leads to encryption being a mere formality. Once the attacker obtains the key, the historical communication records can be decrypted. In addition, the existing scheme is seriously insufficient in anonymizing metadata. By analyzing the mobile phone numbers and communication times of the sending and receiving parties, the user's identity and behavior patterns can be easily inferred, which may cause serious consequences in specific scenarios. Some schemes that attempt to combine blockchain technology also have obvious defects. Security vulnerabilities of smart contracts occur frequently, and security problems such as re-entrant attacks lead to the theft of user privacy credentials. The complexity of the contract code makes it difficult for ordinary users to audit its logic, and there is a risk of covert collection of user data. At the same time, the existing blockchain short message system lacks protection of a trusted execution environment in key links such as key management and session negotiation, and cannot effectively prevent attacks by malicious software. These technical defects seriously restrict the security and privacy of short message communication, especially in sensitive fields such as financial technology and medicine, such as payment verification and transaction confirmation scenarios in the financial technology field, or remote medical consultation scenarios in the medical field. There is an urgent need for a short message privacy protection scheme that can achieve end-to-end encryption protection while having high availability. SUMMARY

[0004] The purpose of the embodiments of the present application is to provide a short message privacy protection method, device, equipment and storage medium based on a block chain, to achieve end-to-end encryption protection and improve the security of short message privacy protection.

[0005] To solve the above technical problems, the embodiments of the present application provide a short message privacy protection method based on a block chain, comprising:

[0006] generating a sender private key and a sender public key in a trusted execution environment, and recording the sender public key in a public key repository on the block chain through a smart contract after the user identity verification is passed;

[0007] When receiving a short message sending request, generating an elliptic curve key pair and performing key verification based on the elliptic curve key pair and the short message sending request through the smart contract to generate a key negotiation parameter and a temporary session key, wherein the short message sending request includes short message content, a receiver public key, a sender identifier and a receiver identifier;

[0008] The short message content, the temporary session key, the receiver identifier and the sender identifier are hierarchically encrypted, and the hierarchically decrypted information is assembled to generate an encrypted short message package;

[0009] A hash value of the encrypted short message package is calculated, the hash value is taken as a short message identifier, and the short message identifier is stored into the blockchain;

[0010] The encrypted short message package is sent to a receiver terminal, so that the receiver terminal performs hierarchical decryption and verification on the encrypted short message package in the trusted execution environment.

[0011] To solve the above technical problems, an embodiment of the present application provides a short message privacy protection device based on a blockchain, comprising:

[0012] A sender key generation module is configured to generate a sender private key and a sender public key in a trusted execution environment, and record the sender public key in a public key warehouse on a blockchain through a smart contract after user identity verification is passed;

[0013] A temporary session key generation module is configured to generate an elliptic curve key pair when receiving a short message sending request, and perform key verification on the short message sending request based on the elliptic curve key pair through the smart contract to generate a key agreement parameter and a temporary session key, wherein the short message sending request comprises short message content, a receiver public key, a sender identifier and a receiver identifier;

[0014] A hierarchical encryption module is configured to hierarchically encrypt the short message content, the temporary session key, the receiver identifier and the sender identifier, and assemble the hierarchically decrypted information to generate an encrypted short message package;

[0015] A short message identifier generation module is configured to calculate a hash value of the encrypted short message package, take the hash value as a short message identifier, and store the short message identifier into the blockchain;

[0016] A short message package decryption module is configured to send the encrypted short message package to a receiver terminal, so that the receiver terminal performs hierarchical decryption and verification on the encrypted short message package in the trusted execution environment.

[0017] To solve the above technical problems, an embodiment of the present application provides a short message privacy protection device based on a blockchain, comprising:

[0018] To solve the above technical problems, one technical solution adopted by the present application is: a computer readable storage medium, the computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the short message privacy protection method based on a block chain.

[0019] The embodiment of the present application provides a short message privacy protection method, device and equipment based on a block chain and a storage medium. The method comprises the following steps: generating a sender private key and a sender public key in a trusted execution environment, and recording the sender public key in a public key warehouse on a block chain through a smart contract after user identity verification; when receiving a short message sending request, generating an elliptic curve key pair, and performing key verification on the short message sending request based on the elliptic curve key pair through the smart contract to generate a key negotiation parameter and a temporary session key, wherein the short message sending request comprises short message content, a receiver public key, a sender identifier and a receiver identifier; performing layered encryption on the short message content, the temporary session key, the receiver identifier and the sender identifier, and assembling information after layered decryption to generate an encrypted short message package; calculating a hash value of the encrypted short message package, taking the hash value as a short message identifier, and storing the short message identifier in the block chain; and sending the encrypted short message package to a receiver terminal, so that the receiver terminal performs layered decryption and verification on the encrypted short message package in the trusted execution environment. The embodiment of the present application generates a key through a trusted execution environment and performs verification through a block chain smart contract, and combines layered encryption and hash storage technology, so that end-to-end encryption protection is effectively realized, the metadata anonymity is ensured, and the security of short message privacy is improved through the non-tamperable nature of the block chain. BRIEF DESCRIPTION OF DRAWINGS

[0020] In order to more clearly illustrate the scheme in the present application, the drawings needed in the description of the embodiments of the present application will be briefly introduced. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without creative labor.

[0021] Figure 1 is an application environment schematic diagram of the short message privacy protection method based on a block chain in an embodiment of the present application;

[0022] Figure 2 is an implementation flowchart of the short message privacy protection method based on a block chain provided by the embodiment of the present application;

[0023] Figure 3 is Figure 2 is a specific implementation flowchart of step S1 in the embodiment;

[0024] Figure 4 is Figure 2 A specific implementation flowchart of step S2 in

[0025] Figure 5 is Figure 2 A specific implementation flowchart of step S3 in

[0026] Figure 6 is Figure 5 A specific implementation flowchart of step S31 in

[0027] Figure 7 is Figure 2 A specific implementation flowchart of step S4 in

[0028] Figure 8 is a flowchart of implementation of a method for short message privacy protection based on a block chain according to another embodiment of the present application;

[0029] Figure 9 is a schematic diagram of a device for short message privacy protection based on a block chain according to an embodiment of the present application;

[0030] Figure 10 is a schematic diagram of a terminal device according to an embodiment of the present application. DETAILED DESCRIPTION

[0031] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs; the terminology used in the description herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the description and claims of this application as well as the above abstract are intended to cover any and all adaptations or variations of the present application; the terminology in the description of the application shall include all technical and scientific terms or their future equivalents known in the art that could give the same meaning to one of ordinary skill in the art; the terms "comprise", "comprising", "include", "including", "have", "has", "contain", "containing", "contain" and "contains" used in the description and the claims of this application and the above abstract are intended to cover non-exclusive inclusion; the terms "first", "second", and the like used in the description of the application are intended to distinguish different objects, not to describe a particular order.

[0032] Reference herein to "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the application. The appearance of the phrase in various places in the specification does not necessarily all refer to the same embodiment, nor is it necessary that a separate or alternative embodiment be developed in order to incorporate the essential attributes of the application. It is explicitly and implicitly recognized that embodiments described herein can be combined with other embodiments.

[0033] In order to make the technical personnel in the art better understand the scheme of the present application, the technical solutions in the embodiments of the present application will be described clearly and completely in conjunction with the drawings.

[0034] The application will be described in detail below with reference to the accompanying drawings and embodiments.

[0035] It should be noted that the short message privacy protection method based on the blockchain provided in the embodiments of the present application is generally executed by a terminal device, and accordingly, the short message privacy protection device based on the blockchain is generally configured in the terminal device.

[0036] The short message privacy protection method based on the blockchain provided in the embodiments of the present application can be applied in an application environment such as Figure 1 , wherein the sender terminal device can send a short message sending request and various key information to the blockchain through a network, the blockchain verifies the identity information and the key information, and when the verification is passed, sends the short message content and the sender identifier to the receiver terminal. After the receiver terminal receives the short message content and the sender identifier, etc., the decryption information can be obtained from the blockchain to decrypt the short message content and the sender identifier. The sender terminal device and the receiver terminal device can be, but are not limited to, various smart phones, tablet computers that can send and receive short messages, etc. The present application will be described in detail below through specific embodiments.

[0037] The short message privacy protection method based on the blockchain provided in the embodiments of the present application can be applied in the payment verification and transaction confirmation scene of the financial technology field, or in the remote medical consultation scene of the medical field.

[0038] In the prior art, the short message privacy protection system generally adopts a centralized architecture, which has the risk of single point failure and data leakage. For example, the short message service platform of a financial institution relies on a centralized server cluster. Once the core node is subjected to a network attack or hardware failure, it may cause service interruption or user privacy leakage. The existing encryption scheme usually only protects the transmission channel, and the short message content is still in plaintext form in the storage stage. The administrator's abuse of power or key management vulnerabilities can easily cause secondary leakage. Metadata is not anonymized, and the mobile phone number is directly associated with the user's identity. By analyzing the short message sending and receiving records, the user's behavior pattern can be inferred. The application of smart contract in the key management link has code vulnerabilities, and some platforms have caused key leakage or loss of control due to contract logic defects.

[0039] To solve the above problems, the core defect of the existing technical architecture is the excessive reliance on centralized trust mechanisms. First, the traditional key generation process is exposed to the general operating system environment, and the private key is vulnerable to malicious programs. Second, the key agreement process lacks a multi-party verification mechanism, and the security of the session key depends on a single communication channel. In addition, the mixed processing of metadata and encrypted data leads to the failure of anonymization. By analyzing the distributed ledger characteristics of blockchain technology, the public key storage and verification process can be transferred to the on-chain smart contract execution, combined with the trusted execution environment to achieve physical isolation of key generation and storage. To address the issue of incomplete encryption coverage, a layered encryption strategy is adopted, with differentiated encryption processing for content, keys, and identification information. To address the risk of metadata association, a hash algorithm is introduced to perform one-way conversion on the identification information, cutting off the direct association between the original data and the encrypted data.

[0040] Therefore, the present application proposes a blockchain-based short message privacy protection method, applied to the sender terminal device of a short message, which includes: generating a sender private key and a sender public key in a trusted execution environment, and recording the sender public key in the public key repository on the blockchain through a smart contract after the user identity verification is passed; when receiving a short message sending request, generating an elliptic curve key pair and performing key verification based on the elliptic curve key pair and the short message sending request through a smart contract to generate key negotiation parameters and a temporary session key, wherein the short message sending request includes short message content, a receiver public key, a sender identifier, and a receiver identifier; performing layered encryption on the short message content, the temporary session key, the receiver identifier, and the sender identifier, and assembling the layered decrypted information to generate an encrypted short message package; calculating the hash value of the encrypted short message package, taking the hash value as a short message identifier, and storing the short message identifier in the blockchain; and sending the encrypted short message package to the receiver terminal to enable the receiver terminal to perform layered decryption and verification on the encrypted short message package in the trusted execution environment. Specifically, the trusted execution environment initializes a secure isolation area in the device startup phase to generate an asymmetric key pair to isolate potential attacks at the operating system level. After the user completes the biometric verification, the smart contract verifies the validity of the identity credentials on the blockchain network, and writes the public key into the distributed ledger through the consensus mechanism. When sending a short message, the terminal generates a temporary elliptic curve key in a secure environment, and the smart contract calls the receiver public key stored on the chain for cross verification to ensure the legality of the identities of both parties. In the layered encryption process, the short message content is encrypted with a temporary session key, which is encrypted with the receiver public key to form an independent ciphertext package, and the sender and receiver identifiers are processed by a hash to eliminate identifiable features. The hash value of the encrypted data package is written to the blockchain through the smart contract to form a globally unique and tamper-proof transaction record. The receiver terminal uses the private key to decrypt the session key in the trusted environment, and then decrypts the short message content while verifying the hash consistency of the blockchain evidence.

[0041] Please refer toFigure 2 , Figure 2 An embodiment of a blockchain-based short message privacy protection method is shown.

[0042] It should be noted that the method of the present application is not limited to the sequence of the flow shown, and includes the following steps: Figure 2 The method includes the following steps:

[0043] S1: Generate a sender private key and a sender public key in a trusted execution environment, and record the sender public key in a public key repository on a blockchain through a smart contract after user identity verification.

[0044] The trusted execution environment refers to a secure computing area with a hardware-level isolation mechanism, which can be implemented using Intel SGX or ARM TrustZone technology, and the key generation process is protected from operating system layer attacks through memory encryption and remote authentication technology.

[0045] Please refer to Figure 3 , Figure 3 An embodiment of step S1 is shown as follows:

[0046] S11: Receive a registration request initiated by a user, and generate the sender private key and the sender public key in the trusted execution environment according to the registration request.S12: Store the sender private key in a device security chip.S13: Send the sender identifier and the sender public key to the blockchain.S14: Receive the registration request through the smart contract, and perform a live detection on the user according to the registration request, and generate an encrypted identity token.S15: Verify the validity of the live detection and the encrypted identity token through the smart contract, and if the verification is passed, record the sender public key in the public key repository.

[0047] Specifically, the registration request triggers the trusted execution environment to generate an asymmetric key pair, the private key is written to the protected storage area of the secure chip and cannot be read externally. After the user identification and public key are transmitted to the blockchain node through the encrypted channel, the smart contract initiates the live detection process to collect user biometric data, and generates an encrypted token containing a timestamp and a random number. After the live detection confirms the user's real existence and the encrypted token passes the elliptic curve digital signature verification, the smart contract binds the public key with the user identification and writes it into the distributed ledger of the blockchain, forming an unalterable public key registration record. The embodiments of the application block the key leakage path through the hardware-level protection of the trusted execution environment and the secure chip, and combine the two-factor authentication mechanism of live detection and dynamic token to effectively solve the security risks of false identity registration and key storage. The unalterable nature of the blockchain ensures the credibility of the public key registration data, avoiding the risk of tampering with the centralized database. The embodiments of the application realize the full-closed protection of the key generation process to prevent malicious software from stealing private key data; block false identity impersonation behavior through live biometric feature verification to ensure the authenticity of the public key registration subject; and eliminate the single point failure risk by using the distributed storage feature of the blockchain to protect the integrity and traceability of the public key repository data.

[0048] Among them, the device security chip refers to a special hardware module with physical tamper-proofing characteristics, which can be implemented by SE security element or TPM trusted platform module, and the private key is prevented from being illegally exported by isolating the key storage area from the main processor. Live detection refers to a dynamic identity verification technology based on biometric features, which can be implemented by 3D structured light face recognition or iris dynamic tracking algorithm, and whether the user is a real live body is determined by detecting facial micro-expression or eye movement features. The encrypted identity token refers to a dynamically generated one-time identity credential, which can be implemented by using the HMAC-SHA256 algorithm based on timestamp combined with asymmetric encryption technology, and the double encryption mechanism ensures the unforgeability of the token.

[0049] S2: When receiving the short message sending request, an elliptic curve key pair is generated, and key verification is performed on the short message sending request based on the elliptic curve key pair through the smart contract to generate key negotiation parameters and a temporary session key. Among them, the short message sending request includes short message content, receiver public key, sender identification and receiver identification.

[0050] Specifically, before the short message sending request, identity verification is required through the blockchain to ensure the legality and authenticity of the user's identity. In the short message sending process, end-to-end encryption technology is used to ensure that the short message content is always in an encrypted state during transmission, preventing data leakage at intermediate links.

[0051] The elliptic curve key pair refers to a temporary key combination generated based on an elliptic curve cryptography algorithm, for example, a key agreement implemented by using an ECDH algorithm, which functions to ensure forward security of a session key. The sender identifier and the receiver identifier can be a mobile phone number of the sender and a mobile phone number of the receiver, respectively.

[0052] Referring to Figure 4 , Figure 4 An embodiment of step S2 is shown as follows:

[0053] S21: When receiving the short message sending request, an elliptic curve algorithm is used to generate the elliptic curve key pair, wherein the elliptic curve key pair includes a temporary public key and a temporary private key. S22: The short message sending request and the temporary public key are sent to the block chain. S23: The short message sending request is received by the smart contract, and the validity of the sender identity is verified by the identity authentication engine based on the short message sending request through the smart contract. S24: The receiver public key is obtained from the public key warehouse based on the receiver identifier through the smart contract, and the validity of the receiver public key is verified. S25: If the validity verification is passed, the key agreement parameter and the temporary session key are generated based on the receiver public key and the temporary public key.

[0054] Specifically, after the short message sending request is triggered, the elliptic curve algorithm dynamically generates a temporary public-private key pair for the current session only, and the temporary public key and the request information are submitted to the block chain for non-tamperable storage. The smart contract first calls the identity authentication engine to verify the authenticity of the sender identity, including comparing the biological characteristics with the block chain registration record; then extracts the receiver public key from the public key warehouse to verify whether it is in a valid registration state. After the double verification is passed, the key agreement protocol is executed based on the receiver long-term public key and the sender temporary public key to generate a temporary session key with forward security, ensuring that even if the long-term private key is leaked in the future, the current session security will not be affected. If the validity verification of the receiver public key is passed, the smart contract executes the core logic of the ECDH agreement, and a shared secret is generated by using the receiver public key, the temporary public key and the secret parameter of the smart contract itself. Based on the shared secret, a unique, temporary and symmetric session key is derived; then the smart contract generates key agreement parameters, which contain enough information to enable the receiver to also independently calculate the same SessionKey, but the design can resist man-in-the-middle attacks (for example, containing the sender and receiver public key information, temporary public key, contract signature, etc.). The smart contract securely sends the temporary session key (only exists temporarily in the memory) and the key agreement parameters back to the sender terminal device (through a secure channel such as TLS).

[0055] The application effectively prevents intermediaries from launching attacks by forging identities or tampering with public keys, ensures that the key agreement process is completed in a verifiable secure environment; the dynamic key generation mechanism uses independent keys for each session, avoiding the decryption of historical communication content due to the leakage of a single key; the tamper-proof nature of blockchain storage provides auditability for the key exchange process, facilitating the tracing of the root cause of security incidents.

[0056] Among them, the identity authentication engine refers to a verification module integrating live detection and digital certificate verification, which can be implemented by calling a biological feature comparison interface and a blockchain certificate library query interface, and is used to confirm the consistency of the sender's identity and registration information. The public key validity verification refers to checking the registration status and validity period of the receiver's public key in the blockchain public key repository, which can be implemented by querying the blockchain transaction record and timestamp, to prevent the use of expired or unauthorized public keys for key agreement.

[0057] S3: Hierarchical encryption is performed on the short message content, the temporary session key, the receiver identifier and the sender identifier, and the information after hierarchical decryption is assembled to generate an encrypted short message package.

[0058] Among them, hierarchical encryption includes symmetric encryption of short message content, asymmetric encryption of session key and hash conversion of identifier information, which can specifically use AES-GCM algorithm to encrypt content, RSA-OAEP algorithm to encrypt key and SHA-3 algorithm to process identifier information, to realize the security protection of different data types.

[0059] Please refer to Figure 5 , Figure 5 A specific implementation of step S3 is shown as follows:

[0060] S31: The short message content is encrypted to generate content ciphertext, and a content integrity check code is generated based on the content ciphertext. S32: The temporary session key is encrypted by the sender's public key to generate a key container. S33: The receiver identifier and the sender identifier are hashed respectively to generate a receiver unique identifier and a sender unique identifier. S34: The content ciphertext, the content integrity check code, the key container, the receiver unique identifier and the sender unique identifier are assembled to generate the encrypted short message package.

[0061] Specifically, the short message content is first symmetrically encrypted by a temporary session key to generate content ciphertext, and a hash value of the original content is calculated as an integrity check reference. The temporary session key is encrypted by the sender's public key to form a key container, preventing man-in-the-middle attacks from obtaining the key. The receiver and sender identifiers are subjected to irreversible hash operation to generate unique identifiers, effectively hiding sensitive metadata such as real mobile phone numbers. Finally, the content ciphertext, check code, key container, and anonymous identifier are assembled according to a preset data structure to form a complete data packet containing encrypted content, verification mechanism, and anonymous identifier. This process is completed in a trusted execution environment, and each encryption step forms a progressive protection system that ensures content confidentiality and anonymizes metadata. The present application effectively solves the encryption missing problem of short message content in the storage link, realizes key life cycle protection through the key container, and eliminates the risk of content decryption due to key leakage. The anonymous identifier generated by the hash retains the necessary information for communication while preventing the reverse deduction of user identity through metadata analysis. The introduction of the content integrity check code can detect data tampering during transmission, such as identifying short message text content that has been maliciously modified.

[0062] The content ciphertext refers to the data obtained by encrypting the short message content using a symmetric encryption algorithm, which can be implemented using the AES-256 algorithm combined with a temporary session key. This process is completed in a trusted execution environment to ensure key security. The content integrity check code is a verification data generated by a hash algorithm, which can be calculated by using the SHA-256 algorithm to generate a hash value of the short message content, and is used to verify the integrity of the decrypted content. The key container is a carrier of the temporary session key protected by asymmetric encryption, which is encrypted by the sender's public key using RSA-OAEP to ensure that the key is not stolen during transmission. The receiver's unique identifier and the sender's unique identifier are anonymous identifiers generated by one-way hash operation, which can be processed by using the HMAC-SHA3 algorithm to process the original identifier information, eliminating the association between metadata and the user's real identity.

[0063] Please refer to Figure 6 , Figure 6 An embodiment of step S31 is shown as follows:

[0064] S311: encrypt the short message content based on the temporary session key and symmetric encryption algorithm to generate the content ciphertext. S312: calculate the hash value of the short message content as the content integrity check code.

[0065] Specifically, the short message content is converted into ciphertext form through a temporary session key and a symmetric encryption algorithm, for example, the text data is block encrypted in CBC mode using the AES-256 algorithm. During encryption, each data block is XORed with the previous ciphertext block to form a chained encryption structure. After encryption is complete, the original short message content is hashed, for example, a 256-bit hash value is generated as a check code using the SHA-3 algorithm. The temporary session key used in the encryption process is dynamically generated through a key agreement protocol, for example, an independent key is generated at each communication based on the elliptic curve Diffie-Hellman protocol. The receiving end needs to use the temporary session key to restore the plaintext and recalculate the hash value to verify the data integrity when decrypting. The present application effectively solves the key leakage risk and integrity loss problem existing in the short message content encryption process. The dynamically generated temporary session key avoids the security risks caused by long-term key storage, and the symmetric encryption algorithm meets the real-time communication efficiency requirements while ensuring the encryption strength. The introduction of the hash check mechanism builds an end-to-end data integrity verification system that can accurately identify any data tampering behavior that occurs during transmission. The combination of the double protection mechanism enables the short message content to have both confidentiality and integrity protection capabilities during encrypted storage and transmission.

[0066] Among them, the symmetric encryption algorithm refers to an algorithm that uses the same key for encryption and decryption, which can be implemented using the AES-256 algorithm to ensure encryption strength while improving data processing efficiency. The inner hash value refers to a fixed-length data fingerprint generated by a hash function, which can be implemented using the SHA-3 algorithm to establish a unique correspondence between the original data and the ciphertext. The content integrity check code refers to a verification code used to verify data integrity, which can be detected by comparing the difference in hash values to detect data tampering behavior.

[0067] S4: Calculate the hash value of the encrypted short message package, use the hash value as the short message identifier, and store the short message identifier in the blockchain.

[0068] Among them, the blockchain storage of the short message identifier refers to writing the hash value of the encrypted data package into a distributed ledger, for example, using the immutable storage mechanism of Hyperledger Fabric to form a traceable evidence record.

[0069] Please refer to Figure 7 , Figure 7 An embodiment of step S4 is shown, described as follows:

[0070] S41: uploading the encrypted short message package and the identity proof of the sender to a blockchain node through an HTTPS / TLS protocol. S42: verifying the validity of the identity proof, the receiver identifier and the sender identifier through the smart contract. S43: if the verification is passed, calculating the hash value of the encrypted short message package through the smart contract, and taking the hash value as the short message identifier. S44: storing the short message identifier into the blockchain.

[0071] Specifically, after the encrypted short message package is completed with layered encryption, the sender terminal establishes a secure connection through the HTTPS / TLS protocol, and uploads the identity proof containing the digital signature and the encrypted short message package to the blockchain node. After the blockchain node triggers the smart contract, the contract code first parses the digital signature in the identity proof, and performs matching verification with the public key registered in the public key repository, while verifying whether the receiver identifier and the sender identifier meet the format specification registered on the blockchain. After the verification is passed, the smart contract calls the built-in hash function to calculate the encrypted short message package byte by byte, and generates a 256-bit hash value as a unique identifier. The identifier is written into the distributed ledger of the blockchain through the consensus mechanism, forming a tamper-proof record with a timestamp. The present application effectively prevents the short message identifier from being stolen or tampered with during the transmission stage, and solves the single point failure problem existing in the traditional storage mode. Through the automatic execution of the verification logic by the smart contract, the identity misjudgment caused by manual review is avoided, for example, in a certain test case, 23% of the fake identity proof attacks were successfully intercepted. The hash value stored in the blockchain forms a traceable audit chain, which can provide a verification basis for the integrity of the encrypted short message package in case of dispute.

[0072] Among them, the HTTPS / TLS protocol refers to establishing an encrypted communication channel by using the transport layer security protocol, which can be implemented by using the TLS1.3 version, verifying the node identity and encrypting the transmission data through the digital certificate, preventing man-in-the-middle attacks and data eavesdropping. The smart contract verifies the identity proof, which means that the automatic verification process is performed through the contract code preloaded on the blockchain, which can be implemented by using zero-knowledge proof technology to verify the validity of the identity proof on the premise of protecting privacy.

[0073] S5: sending the encrypted short message package to the receiver terminal, so that the receiver terminal performs layered decryption and verification on the encrypted short message package in the trusted execution environment.

[0074] Specifically, the encrypted short message package is sent to the receiver terminal, so that the receiver terminal performs layered decryption and verification on the encrypted short message package in the trusted execution environment. The decryption path in the receiver terminal is to first decrypt the RSA key container with the receiver private key; then restore the temporary session key through the elliptic curve algorithm, and finally decrypt the AES ciphertext through the temporary session key and verify the hash value; when the verification is passed, the decrypted short message package is obtained.

[0075] Referring to Figure 8 , Figure 8 Another specific embodiment of the present application is shown as follows:

[0076] S61: Real-time on-chain transaction and contract event is monitored by the blockchain monitoring node, and if a preset abnormal pattern is detected, abnormal event information is obtained. S62: Based on the abnormal event information, the emergency response smart contract performs abnormal root cause positioning to obtain an abnormal root cause positioning result. S63: A preset fuse mechanism is triggered according to the abnormal root cause positioning result.

[0077] Specifically, when the blockchain network is running, the monitoring node continuously scans the newly chained transaction data, and compares the transaction characteristics with the preset abnormal pattern library through the built-in rule engine. For example, when it is detected that a certain account initiates 20 contract call requests containing the same receiving address within 1 second, it is determined to be a DDoS attack feature, and the hash value, initiator address and other event information of the batch of transactions are immediately captured. After the emergency response smart contract receives the event information, it starts the trace analysis process, constructs the associated transaction graph of the account by querying the historical transaction records, identifies the difference characteristics of abnormal transactions and normal transactions in parameter construction, and finally locates the contract function parameter overflow vulnerability used by the attacker. According to the type of the vulnerability, a preset disposal strategy is matched, a consensus protocol update instruction between nodes is triggered, and the contract interface with the vulnerability is automatically closed in the next block confirmation period, and a safety alarm is broadcast to the entire network. The fuse mechanism is set to three levels of plans, including freezing the suspected account, recalling unread ciphertext, and generating a judicial evidence report. Freezing the suspected account marks the state of the located suspicious account (UserID_Blockchain) as “frozen”, preventing all subsequent operations (sending, receiving, key update, etc.). Recall unread ciphertext: Send a notification or instruction to the receiving party associated with the encrypted information package that has not been read by the receiving party, which involves leaking keys, to prevent it from decrypting or securely erasing the ciphertext package on the client. Generate a judicial evidence report: The contract automatically aggregates all on-chain evidence related to the leakage event: transaction ID, receiving party identifier and sending party identifier mapping result (after security desensitization), key negotiation record, operation log, timestamp, etc., to generate a structured judicial evidence report with contract signature and blockchain Merkle proof.

[0078] The blockchain monitoring node refers to a special monitoring service node deployed in the blockchain network, which can be implemented by a blockchain full node with event subscription function. By real-time analysis of transaction metadata and contract call logs in the block data packet, abnormal behavior characteristics are identified. The preset abnormal mode refers to a predefined suspicious operation characteristic set, which can be implemented by transaction frequency threshold monitoring and contract function call parameter compliance verification rules. For example, if the transaction volume of a single account exceeds 50 per second, an early warning is triggered. The emergency response smart contract refers to an on-chain program module with automatic analysis function, which can be implemented by an attack path backtracking algorithm based on a graph database and a vulnerability mode matching script. By analyzing the transaction correlation graph, the abnormal source is located.

[0079] The application can be applied to multiple scenarios in the financial technology field and the medical field, such as payment verification and transaction confirmation scenarios, credit risk information verification scenarios, and cross-border remittance supervision compliance application scenarios in the financial technology field. In the payment verification and transaction confirmation scenario, the pain points are that payment verification SMS is hijacked by middleware (such as Trojan programs), and sensitive information such as transaction amount and account tail number is transmitted in plaintext. The application can encrypt payment instructions with AES-256-GCM and upload them to the chain. The bank system acts as the receiver and decrypts it with a secure chip private key. The SMS content is prohibited from being stored persistently. This scenario can effectively improve the security of SMS content transmission and reduce the payment identification rate. It can be applied to electronic prescription flow scenarios, clinical research data collection scenarios, and remote medical consultation scenarios in the medical field. In the remote medical consultation scenario, the pain point is that the doctor-patient communication contains medical privacy, but the doctor's private mobile phone records are stored, and the hospital cannot trace the consultation process disputes. The application can realize end-to-end encryption of consultation content, erasure of doctor device session key after use, and retrieval of blockchain evidence through a unique identifier in case of disputes. The application can effectively improve the efficiency of medical dispute handling and protect user privacy.

[0080] In the embodiments of the present application, the sender private key and the sender public key are generated in the trusted execution environment, and after the user identity verification is passed, the sender public key is recorded in the public key warehouse on the blockchain through the smart contract. When receiving a short message sending request, an elliptic curve key pair is generated, and key verification is performed on the short message sending request based on the elliptic curve key pair through the smart contract to generate a key agreement parameter and a temporary session key, wherein the short message sending request includes short message content, a receiver public key, a sender identifier and a receiver identifier. The short message content, the temporary session key, the receiver identifier and the sender identifier are hierarchically encrypted, and the hierarchically decrypted information is assembled to generate an encrypted short message package. The hash value of the encrypted short message package is calculated, the hash value is taken as a short message identifier, and the short message identifier is stored in the blockchain. The encrypted short message package is sent to a receiver terminal, so that the receiver terminal performs hierarchical decryption and verification on the encrypted short message package in the trusted execution environment. The embodiments of the present application generate keys through the trusted execution environment and verify them by using the blockchain smart contract, and combine the hierarchical encryption and hash storage technology to effectively realize end-to-end encryption protection, ensure the anonymity of metadata, and improve the security of short message privacy through the non-tamperability of the blockchain.

[0081] The embodiments of the present application convert the identifier information through a hash algorithm to block the association analysis of the metadata and the user identity. The conventional key agreement process lacks an on-chain verification link, and a multi-party key generation and verification mechanism is realized by combining the smart contract and elliptic curve cryptography. The traditional short message system uses a unified encryption strength to process all data, and the embodiments of the present application implement differentiated encryption strategies according to the data types to optimize the allocation of computing resources while ensuring security.

[0082] The embodiments of the present application effectively solve the trust defects of the centralized architecture, eliminate the single point failure risk through the distributed storage of the blockchain, cover the whole life cycle of data through the hierarchical encryption mechanism, prevent the chain reaction of data leakage caused by key leakage, and block the user portrait analysis based on communication behavior after the metadata is processed by the hash. The combination of the trusted execution environment and the smart contract ensures that the key generation, storage and use links are in a controlled and secure environment, and significantly reduces the success rate of malicious code attacks.

[0083] Please refer to Figure 9 , as an implementation of the method shown in Figure 2 , the present application provides an embodiment of a short message privacy protection device based on a blockchain. The device embodiment corresponds to the method embodiment shown in Figure 2 , and the device can be applied to various terminal devices.

[0084] As Figure 9As shown, the SMS privacy protection device based on the blockchain in the embodiment includes a sender key generation module 71, a temporary session key generation module 72, a hierarchical encryption module 73, an SMS identifier generation module 74, and an SMS package decryption module 75, wherein:

[0085] The sender key generation module 71 is configured to generate a sender private key and a sender public key in a trusted execution environment, and record the sender public key in a public key repository on a blockchain through a smart contract after user identity verification is passed.

[0086] The temporary session key generation module 72 is configured to generate an elliptic curve key pair when receiving an SMS sending request, and perform key verification on the SMS sending request based on the elliptic curve key pair through the smart contract to generate a key agreement parameter and a temporary session key, wherein the SMS sending request includes SMS content, a receiver public key, a sender identifier, and a receiver identifier.

[0087] The hierarchical encryption module 73 is configured to perform hierarchical encryption on the SMS content, the temporary session key, the receiver identifier, and the sender identifier, and assemble the information after hierarchical decryption to generate an encrypted SMS package.

[0088] The SMS identifier generation module 74 is configured to calculate a hash value of the encrypted SMS package, take the hash value as an SMS identifier, and store the SMS identifier in the blockchain.

[0089] The SMS package decryption module 75 is configured to send the encrypted SMS package to a receiver terminal, so that the receiver terminal performs hierarchical decryption and verification on the encrypted SMS package in the trusted execution environment.

[0090] Further, the sender key generation module 71 includes:

[0091] A registration request receiving unit is configured to receive a registration request initiated by a user, and generate the sender private key and the sender public key in the trusted execution environment according to the registration request.

[0092] A sender private key storage unit is configured to store the sender private key in a device security chip.

[0093] A sender public key sending unit is configured to send the sender identifier and the sender public key to the blockchain.

[0094] A live body detection unit is configured to receive the registration request through the smart contract, perform live body detection on the user according to the registration request, and generate an encrypted identity token.

[0095] The sender public key recording unit is configured to record the sender public key in the public key repository through the smart contract after verifying the validity of the liveness detection and the encrypted identity token.

[0096] Further, the temporary session key generation module 72 comprises:

[0097] The elliptic curve key pair generation unit is configured to generate the elliptic curve key pair including a temporary public key and a temporary private key by using an elliptic curve algorithm when receiving the SMS sending request.

[0098] The temporary public key sending unit is configured to send the SMS sending request and the temporary public key to the blockchain.

[0099] The sending request receiving unit is configured to receive the SMS sending request through the smart contract and verify the validity of the sender identity based on the SMS sending request through the identity authentication engine.

[0100] The receiver public key verification unit is configured to obtain the receiver public key from the public key repository based on the receiver identifier through the smart contract and verify the validity of the receiver public key.

[0101] The key agreement parameter generation unit is configured to generate the key agreement parameter and the temporary session key based on the receiver public key and the temporary public key if the validity verification is passed.

[0102] Further, the hierarchical encryption module 73 comprises:

[0103] The SMS content encryption unit is configured to encrypt the SMS content, generate content ciphertext, and generate a content integrity check code based on the content ciphertext.

[0104] The key container generation unit is configured to encrypt the temporary session key by using the sender public key to generate a key container.

[0105] The unique identifier generation unit is configured to hash the receiver identifier and the sender identifier respectively to generate a receiver unique identifier and a sender unique identifier.

[0106] The SMS package assembling unit is configured to assemble the content ciphertext, the content integrity check code, the key container, the receiver unique identifier, and the sender unique identifier to generate the encrypted SMS package.

[0107] Further, the SMS content encryption unit comprises:

[0108] a content ciphertext generation unit configured to encrypt the short message content based on the temporary session key and a symmetric encryption algorithm to generate the content ciphertext;

[0109] a content integrity check code generation unit configured to calculate a hash value of the short message content as the content integrity check code.

[0110] Further, the short message identifier generation module 74 comprises:

[0111] an encrypted short message package sending unit configured to upload the encrypted short message package and the identity proof of the sender to a blockchain node through an HTTPS / TLS protocol;

[0112] an identity proof verification unit configured to verify the validity of the identity proof, the receiver identifier and the sender identifier through the smart contract;

[0113] a hash value calculation unit configured to calculate a hash value of the encrypted short message package through the smart contract if the verification is passed, and take the hash value as the short message identifier;

[0114] a short message identifier storage unit configured to store the short message identifier into the blockchain.

[0115] Further, the blockchain-based short message privacy protection device further comprises:

[0116] an abnormality monitoring module configured to monitor real-time on-chain transactions and contract events through the blockchain monitoring node, and obtain abnormal event information if a preset abnormal pattern is detected;

[0117] a root cause positioning module configured to perform abnormal root cause positioning based on the abnormal event information through an emergency response smart contract to obtain an abnormal root cause positioning result;

[0118] a fuse mechanism triggering module configured to trigger a preset fuse mechanism according to the abnormal root cause positioning result.

[0119] To solve the above technical problems, the embodiment of the present application further provides a terminal device. For details, please refer to Figure 10 , Figure 10 The following is a basic structure block diagram of the terminal device of the present embodiment.

[0120] The terminal device 8 comprises a memory 81, a processor 82 and a network interface 83 which are connected to each other through a system bus. It should be pointed out that, Figure 10The terminal device 8 is shown to have three components, a memory 81, a processor 82, and a network interface 83, but it is understood that not all of the components shown need be implemented, and more or fewer components can be implemented instead. As understood by one skilled in the art, the terminal device is a device that can automatically perform numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, a microprocessor, an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a digital signal processor (DSP), an embedded device, etc.

[0121] The terminal device can be various smart phones, tablets capable of sending and receiving short messages, etc. The terminal device can interact with the user through a touch panel or a voice control device, etc.

[0122] The memory 81 includes at least one type of readable storage medium, including a flash memory, a hard disk, a multimedia card, a card-type memory (e.g., an SD or DX memory, etc.), a random access memory (RAM), a static random access memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, etc. In some embodiments, the memory 81 can be an internal storage unit of the terminal device 8, such as a hard disk or a memory of the terminal device 8. In other embodiments, the memory 81 can also be an external storage device of the terminal device 8, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc. equipped on the terminal device 8. Of course, the memory 81 can also include both the internal storage unit and the external storage device of the terminal device 8. In the present embodiment, the memory 81 is generally used to store an operating system and various application software installed on the terminal device 8, such as program codes of the short message privacy protection method based on the blockchain, etc. In addition, the memory 81 can also be used to temporarily store various data that have been output or will be output.

[0123] The processor 82 may, in some embodiments, be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 82 is generally used to control the overall operation of the terminal device 8. In the present embodiment, the processor 82 is configured to run program codes or process data stored in the memory 81, such as program codes of the blockchain-based short message privacy protection method described above, to implement various embodiments of the blockchain-based short message privacy protection method.

[0124] The network interface 83 may include a wireless network interface or a wired network interface, and is generally used to establish a communication connection between the terminal device 8 and other electronic devices.

[0125] The present application also provides another embodiment, i.e., a computer-readable storage medium storing a computer program, which can be executed by at least one processor to cause the at least one processor to perform the steps of a blockchain-based short message privacy protection method as described above.

[0126] From the above description of the embodiments, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software and the necessary general hardware platform, of course, they can also be implemented by hardware, but in many cases, the former is a better embodiment. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, which is stored in a storage medium (such as a ROM / RAM, a magnetic disk, or an optical disk) and includes a number of instructions for causing a terminal device to perform the methods of the various embodiments of the present application.

[0127] Obviously, the above-described embodiments are only some embodiments of the present application, not all embodiments, and the preferred embodiments of the present application are given in the drawings, but do not limit the scope of the present application. The present application can be implemented in many different forms, and conversely, the purpose of providing these embodiments is to make the disclosure of the present application more thorough and comprehensive. Although the present application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent replacements to some technical features. Any equivalent structure made by referring to the contents of the specification and drawings, directly or indirectly applied to other related technical fields, is also within the scope of protection of the present application.

Claims

1. A blockchain-based method for protecting SMS privacy, applied to the sending terminal device of an SMS message, characterized in that, include: In a trusted execution environment, a sender's private key and a sender's public key are generated, and after the user's authentication is successful, the sender's public key is recorded in the public key repository on the blockchain via a smart contract; When a text message sending request is received, an elliptic curve key pair is generated, and the smart contract performs key verification based on the elliptic curve key pair and the text message sending request to generate key negotiation parameters and a temporary session key. The text message sending request includes the text message content, the recipient's public key, the sender's identifier, and the recipient's identifier. The SMS content, the temporary session key, the recipient identifier, and the sender identifier are encrypted in layers, and the information after layer-by-layer decryption is assembled to generate an encrypted SMS packet. Calculate the hash value of the encrypted SMS packet, use the hash value as the SMS identifier, and store the SMS identifier in the blockchain; The encrypted SMS packet is sent to the receiving terminal, so that the receiving terminal can perform layered decryption and verification of the encrypted SMS packet in the trusted execution environment.

2. The blockchain-based SMS privacy protection method according to claim 1, characterized in that, The process of generating a sender's private key and a sender's public key in a trusted execution environment, and recording the sender's public key in a public key repository on the blockchain via a smart contract after successful user authentication, includes: Receive a registration request initiated by a user, and generate the sender's private key and the sender's public key in the trusted execution environment according to the registration request; The sender's private key is stored in the device's security chip; Send the sender identifier and the sender public key to the blockchain; The smart contract receives the registration request, performs liveness detection on the user based on the registration request, and generates an encrypted identity token. The smart contract verifies the validity of the liveness detection and the encrypted identity token. If the verification is successful, the sender's public key is recorded in the public key repository.

3. The blockchain-based SMS privacy protection method according to claim 1, characterized in that, When a text message sending request is received, an elliptic curve key pair is generated, and the smart contract performs key verification based on the elliptic curve key pair and the text message sending request to generate key negotiation parameters and a temporary session key, including: When the SMS sending request is received, the elliptic curve algorithm is used to generate the elliptic curve key pair, wherein the elliptic curve key pair includes a temporary public key and a temporary private key; Send the SMS sending request and the temporary public key to the blockchain; The smart contract receives the SMS sending request and calls the identity authentication engine to verify the validity of the sender's identity based on the SMS sending request. The smart contract retrieves the recipient's public key from the public key repository based on the recipient's identifier and verifies the validity of the recipient's public key. If the validity verification passes, the key negotiation parameters and the temporary session key are generated based on the recipient's public key and the temporary public key.

4. The blockchain-based SMS privacy protection method according to claim 1, characterized in that, The step of performing layered encryption on the SMS content, the temporary session key, the recipient identifier, and the sender identifier, and then assembling the decrypted information to generate an encrypted SMS packet, includes: The SMS content is encrypted to generate ciphertext, and a content integrity verification code is generated based on the ciphertext. The temporary session key is encrypted using the sender's public key to generate a key container; The receiver identifier and the sender identifier are hashed respectively to generate a unique receiver identifier and a unique sender identifier; The encrypted SMS packet is generated by assembling the encrypted content, the content integrity check code, the key container, the unique identifier of the recipient, and the unique identifier of the sender.

5. The blockchain-based SMS privacy protection method according to claim 4, characterized in that, The step of encrypting the SMS content to generate ciphertext, and generating a content integrity verification code based on the ciphertext, includes: The SMS content is encrypted using the temporary session key and a symmetric encryption algorithm to generate the ciphertext content. The hash value of the SMS content is calculated as the content integrity verification code.

6. The blockchain-based SMS privacy protection method according to claim 1, characterized in that, The step of calculating the hash value of the encrypted SMS packet, using the hash value as an SMS identifier, and storing the SMS identifier in the blockchain includes: The encrypted SMS packet and the sender's identity verification are uploaded to the blockchain node via the HTTPS / TLS protocol; The validity of the identity verification, the recipient identifier, and the sender identifier is verified through the smart contract. If the verification is successful, the hash value of the encrypted SMS packet is calculated through the smart contract, and the hash value is used as the SMS identifier. The SMS identifier is stored in the blockchain.

7. The blockchain-based SMS privacy protection method according to any one of claims 1 to 6, applied to the SMS sending terminal device, characterized in that, The method further includes: By monitoring real-time on-chain transactions and contract events through the blockchain listening node, if a preset abnormal pattern is detected, abnormal event information is obtained. The root cause of the anomaly is located by using the emergency response smart contract based on the abnormal event information, and the result of the anomaly root cause location is obtained. The preset circuit breaker mechanism is triggered based on the result of the abnormal root cause location.

8. A blockchain-based SMS privacy protection device, characterized in that, include: The sender key generation module is used to generate a sender private key and a sender public key in a trusted execution environment, and after the user is authenticated, the sender public key is recorded in the public key store on the blockchain through a smart contract; The temporary session key generation module is used to generate an elliptic curve key pair when a text message sending request is received, and to perform key verification with the text message sending request based on the elliptic curve key pair through the smart contract to generate key negotiation parameters and a temporary session key. The text message sending request includes text message content, recipient public key, sender identifier and recipient identifier. The layered encryption module is used to perform layered encryption on the SMS content, the temporary session key, the receiver identifier, and the sender identifier, and to assemble the layered decrypted information to generate an encrypted SMS packet. The SMS identifier generation module is used to calculate the hash value of the encrypted SMS packet, use the hash value as the SMS identifier, and store the SMS identifier in the blockchain; The SMS packet decryption module is used to send the encrypted SMS packet to the receiving terminal, so that the receiving terminal can perform layered decryption and verification of the encrypted SMS packet in the trusted execution environment.

9. A terminal device, characterized in that, It includes a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the blockchain-based SMS privacy protection method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the blockchain-based SMS privacy protection method as described in any one of claims 1 to 7.

Images