Method for establishing secure communication channel between mobile applications based on smart contract

Abstract

A method of secure communication between applications by invoking a public smart contract. Wherein the application program uploads a mapping information packet containing a public key of the application program and a decentralized identifier to the public smart contract and submits the mapping information packet to the public smart contract to execute a group of application program mapping information packets stored by the public smart contract on the virtual state machine based on the distributed account book. When a sender application program sends a message to a receiver application program, a sender quotes a public smart contract according to a receiver identifier to obtain a receiver public key, and then uses the receiver public key to establish a shared secure communication protocol between the two application programs by using elliptic curve Diffie-Hellman key exchange. Wherein communication between application programs and between application programs and public smart contracts can use zero-knowledge proof to verify information authenticity and ownership of information.

Description

Technical Field

[0001] The present invention relates to blockchain technology, smart contracts, cryptography and zero-knowledge proof, and in particular to a method for establishing a secure communication channel by using symmetric key encryption between mobile applications based on smart contracts. Background Art

[0002] In mobile operating systems (iOS / Android), it is a common practice for applications to interact by launching each other. However, this practice has many risks.

[0003] When an application uses a custom URL scheme to wake up and launch other applications, there is no guarantee that the application that is actually launched is the same application that was originally intended to be launched, because a third party may maliciously register the same URL scheme and install malware on the same mobile device. Therefore, when relying solely on the URL to launch the target application, it is actually possible to inadvertently open a malicious application. Malicious third-party applications can even use names and icons similar to the target application to further confuse users, making manual inspection to avoid such attacks even less feasible.

[0004] At the same time, data transmission security in the operating system is also a concern, because mobile applications need to ensure that the data transmitted between them cannot be intercepted or tampered with by unauthorized individuals. Preventing man-in-the-middle attacks is also a challenge that mobile applications must face.

[0005] Man-in-the-middle attacks are a common type of cyberattack in which attackers steal or manipulate information by intercepting and tampering with communications between two parties. The attacker inserts himself between the mobile app and the server and intercepts the communication data between the two parties. The user and the server mistakenly believe that they are communicating directly with each other, but in fact, all data passes through the attacker. The attacker can not only read the content of the communication, but also tamper with the data. For example, the attacker can modify the bank transfer amount or change the login credentials. The user's personal information, login credentials, bank account information and other sensitive data may be stolen.

[0006] In addition, given the prevalence of jailbroken and rooted mobile operating systems, the trust between unfamiliar applications within the operating system cannot be guaranteed, resulting in potential leakage risks for any plaintext data transmission. On jailbroken or rooted devices, malicious applications can gain higher permissions and access the data of other applications. This can lead to the theft of users' personal information, login credentials, and other sensitive data. The operating systems of such devices are also more vulnerable to man-in-the-middle attacks. Attackers can exploit security vulnerabilities in the device to intercept and tamper with communications between applications to obtain sensitive information. If the sender application passes any sensitive information in plaintext to the intended recipient application, the malware will not only become the actual recipient, but also directly read the data content because the data transmission is not encrypted, resulting in privacy data leakage.

[0007] In iOS / iPadOS systems, applications can wake up and communicate with each other through Universal Link. This mechanism allows applications to automatically open and process specific content when the user clicks on a link. However, this convenience also brings potential security risks. Malicious users can use this mechanism to send forged third-party Universal Links to recipients. These links look normal, but they do not actually belong to the original application. After clicking on these links, the recipient may be misled to establish a connection with malicious third-party software, thereby exposing sensitive transmission information. This type of attack may not only lead to data leakage, but may also further infect the recipient's device with malware, endangering the user's privacy and security.

[0008] In theory, establishing a centralized key management server for applications to find and download each other's key information can alleviate the above problems. Applications can also load the public key information of the target application in advance for future use. But in reality, as the number of applications that need to communicate increases, the number of communication requests that the central server and applications need to meet also increases, and the number of public keys that need to be stored increases rapidly, resulting in a surge in operating costs and maintenance complexity. Therefore, a practical solution that is independent of traditional centralization is needed. Summary of the invention

[0009] The present invention provides a method for establishing a secure communication channel by using symmetric key encryption between mobile applications based on smart contracts, while ensuring the credibility of the application identity. Public smart contracts can execute mobile applications to upload or retrieve other mobile application mapping information uploaded to the blockchain dictionary, thereby avoiding the risk of applications directly starting each other to interact. The mapping information stored in the blockchain public smart contract contains the decentralized identifier and public key information of the receiving application in the communication, wherein the receiving mobile application decentralized identifier can be the hash value of the receiving mobile application URL scheme. The sending application in the communication uses the key-value mapping to retrieve the result, thereby establishing an encrypted secure communication channel with the receiving party based on the elliptic curve key exchange mechanism (ECDHE).

[0010] When an application uploads its own mapping information, it uploads an application mapping information package including the application decentralized identifier string and the application public key to the public smart contract. The public smart contract can additionally require the mobile program to provide independent zero-knowledge proof information to verify the uploader's ownership of the public key and identifier and the authenticity of the information. When this verification condition is met, the public smart contract immediately accepts and stores the uploaded mapping information in the blockchain dictionary.

[0011] Before the sender application establishes communication with the receiver application, the sender application calls the smart contract to obtain the receiver's public key information. The sending application uses the receiver's decentralized identifier to retrieve the mapping information of the blockchain dictionary and receive the receiver's public key information through the public smart contract.

[0012] The sender application uses the public key information and its own private key to derive a first symmetric encryption key through ECDHE and uses the first symmetric encryption key to encrypt the string data message. The encrypted data message and the sender's public key constitute the communication payload and are passed from the sender application to the receiver application.

[0013] The receiving mobile application uses the communication payload and the receiving mobile application private key to derive a second symmetric encryption key, so that the second symmetric encryption key is equal to the first symmetric encryption key. The receiving application can then use the second symmetric encryption key to decrypt the string data message to complete the communication process between the sender and the receiver.

[0014] In some embodiments, the sender application is run by a sender system, which includes: a communication module configured to call a public smart contract using a recipient application decentralized identifier string; a receiving module configured to receive a recipient mobile application public key from the public smart contract; a key generation module configured to derive a first symmetric encryption key using a sender application private key and a recipient mobile application public key; and a sending module configured to send a communication payload to the recipient application.

[0015] In some embodiments, the receiving application is run by a receiving system, which includes: an upload module configured to upload a receiving application mapping information package to a public smart contract; a receiving module configured to receive a communication payload sent by a sending application; a key generation module configured to derive a second symmetric encryption key using the communication payload and the receiving application private key; and a decryption module configured to decrypt a string data message using the second symmetric encryption key.

[0016] In some embodiments, a public smart contract is run by a public smart contract system, which includes: a receiving module configured to receive application mapping information packages and call requests; a storage module configured to store recipient application mapping information packages; a verification module configured to verify the recipient application decentralized identifier string; and a sending module configured to send the recipient application public key to the sending application.

[0017] In some embodiments, the key can be used once. After the receiving application decrypts the string data message, all or part of the sending application private key, the first symmetric encryption key, the receiving application private key and the second symmetric encryption key are automatically invalidated, so that a new key needs to be generated or calculated using the above method for subsequent communication.

[0018] In some embodiments, the receiving application may use the receiving mobile application decentralized identifier string to call a public smart contract to update the already uploaded receiving mobile application mapping information package. The update may be proactively performed by the receiving application, but the public smart contract may also automatically retire some or all of the stored mobile application mapping information package after a preset expiration time limit, and then prompt the receiving mobile application to update the receiving mobile application decentralized identifier string or the receiving mobile application public key.

[0019] In some embodiments, the receiving application uploads a public key array containing multiple receiving application public keys to the public smart contract, and specifies to the public smart contract the use conditions of any receiving application key in the public key array. The use conditions can be determined based on the required security level of the communication and the corresponding computing cost.

[0020] In some embodiments, the sender application uploads a communication payload containing the sender application public key and a string data message to a public message bus. The message payload can be stored on the message bus and can be sent to the mobile application through a message middleware process. Or the message payload can be read by all applications published on the message center, so that multiple parties including the recipient application can selectively establish secure communication with the sender mobile application.

[0021] In some embodiments, the application object of this technical solution can be further extended to any two applications or entities that communicate using strings. For example, the sender application and the receiver application can be associated with an email server, and the receiver mobile application URL scheme is an email address.

[0022] In some embodiments, snapshots of smart contracts and uploaded mobile application mapping information packages are stored on a local storage medium for use as an offline directory, and the offline directory can reconnect to the network to update the snapshot content to reflect the latest smart contract and uploaded mobile application mapping information package status.

[0023] The technical solution provided by the present invention exchanges a consistent dedicated symmetric encryption key between the sending application and the receiving application through ECDHE. Before the key exchange, the two applications do not transmit any private information. Only after the keys are exchanged, important data will be encrypted and transmitted. The plaintext information visible to the third party is limited to the public key, so the actual communication information and data cannot be decrypted, thereby ensuring that the communication software will not leak any privacy due to the communication content being monitored by malicious third-party applications. Even if a malicious third party intercepts and cracks the private key information of the communicating parties, the one-time use of the key and the update of the mapping information on the public smart contract make the cracked information lose any actual value, further reducing the possibility of replay attacks. In combination with the public smart contract application, the zero-knowledge proof circuit is used to independently judge the accuracy of the uploaded information and the application's ownership of it, ensuring that the correct data is involved in the calculation and transmission, and eliminating the possible information tampering and deception. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] The accompanying drawings are further described by way of example. These descriptions and diagrams are for the purpose of illustration and aiding understanding only and are not limiting in any way. The embodiments are now described by way of example with reference to the accompanying drawings, wherein:

[0025] Figure 1 An example of a security vulnerability in communication between unfamiliar applications within a mobile operating system is shown.

[0026] Figure 2 The overall process of establishing a communication channel between mobile applications using a public smart contract to retrieve mapping information is shown.

[0027] Figure 3 The generation process of the identity solution is shown.

[0028] Figure 4 The structure of mapping information in a public smart contract is shown.

[0029] Figure 5 It shows the process of an application uploading mapping information to a public smart contract.

[0030] Figure 6 The process of establishing an encrypted communication channel between a sender application and a receiver application using a public smart contract is shown.

[0031] Figure 7 A system block diagram showing a sender, a receiver, and a public smart contract.

[0032] Figure 8 A schematic diagram of the structure of a computer device is shown. DETAILED DESCRIPTION

[0033] The central problem that the present invention aims to solve is that the communication security between unfamiliar applications cannot be guaranteed. Figure 1 As shown, when mobile application A and mobile application B attempt to establish communication, mobile application A 110 has no way of verifying whether the Schema 140 it uses will send the communication information to its intended recipient, mobile application B 120 or the fake mobile application B'130. A malicious third party can use many means to make the actual recipient of the communication become the fake mobile application B'130, thereby causing data transmission leakage. These means include session hijacking, replay attacks, man-in-the-middle attacks, malware injection, etc.

[0034] In general, if Figure 2 As shown, the present invention provides a method for establishing a secure communication channel between mobile applications using symmetric key encryption based on smart contracts and ensuring the credibility of the application identity. The communication protocol provided by the present invention utilizes a public smart contract 250 to maintain the mapping information 260 uploaded by the application, thereby avoiding the risk of direct interaction between mobile application A 210 and mobile application B 220. By using the smart contract registration / upload secure communication mode proposed herein, the mode can include mapping information stored on a virtual state machine (such as an Ethereum virtual machine) based on a distributed ledger to specify how applications send messages to each other, for example, using secure communication encrypted by an ECDHE key protocol.

[0035] Before the mobile application uploads the mapping information to the blockchain public smart contract, the mobile application side in the development stage, such as Figure 5As shown, the following preparations are required:

[0036] App developers can choose the appropriate URL scheme for their app. Using URL schemes allows flexible definition or addition without restrictions on quantity or content. In addition, developers can choose to use different domain URLs, namely Universal Link or App Link, depending on the operating system.

[0037] In step 511, the application 510 calculates the hash (URL scheme) in advance, for example, the result is recorded as xxxxxx for the convenience of explanation, and assembles it into a decentralized identity (DID) string did:ohmpp:xxxxxx. Figure 3 It is further explained that, since the link modes 310 between different applications are not completely consistent (such as URL, Universal Link or AppLink), and considering the later expansion to different operating systems, the present invention adopts a more compatible DID as the identity solution 320.

[0038] In step 512, the application 510 further generates an elliptic curve public-private key pair PublicKey and PrivateKey. In step 513, the application maps the DID string did:ohmpp:xxxxx calculated above to the public key PublicKey, and finally sends "[did:ohmpp:xxxxxx]=PublicKey" to the public smart contract 250. In step 514, the public smart contract 250 records the DID as mapping information for retrieval by other applications.

[0039] Mapping information is a data structure used to map keys to values. Application mapping refers to the process of identifying and recording applications and their dependencies in computer networks and systems. In blockchain smart contracts, key-value mapping is a method of data storage and retrieval. During the retrieval process, a key is a unique identifier used to find the corresponding value. In some embodiments, the specific meanings of the keys and values ​​in the mapping information are as follows: Figure 4 Further explanation:

[0040] Key 320: A DID string, such as did:ohmpp:xxxxxx, where xxxxxx represents a hash value derived from the mobile app's custom URL scheme or Universal Link or App Link (i.e., domain URL).

[0041] Value 410: publicKey (elliptic curve public key) and msg.sender.

[0042] In some embodiments, the public smart contract requires the mobile program to provide independent zero-knowledge proof (ZKP) information to verify the uploader's ownership of the public key and identifier and the authenticity of the information. Zero-knowledge proof is a cryptographic technique that allows one party (the prover) to prove to another party (the verifier) ​​that a statement is true without revealing any additional information. This technique involves building complex mathematical circuits to ensure the correctness and confidentiality of the proof. These circuits are composed of logic gates and arithmetic operations that can process input data and generate proofs. In this case, the uploader needs to generate a zero-knowledge proof that it does have the uploaded public key and identifier and that the information is authentic.

[0043] When the zero-knowledge proof provided by the uploader meets the verification conditions, the public smart contract will accept the proof and store the uploaded mapping information in the blockchain dictionary. The blockchain dictionary is a decentralized database that ensures that all stored information is tamper-proof and verifiable. This mechanism not only improves the security and reliability of data, but also enhances the transparency and trust of the system.

[0044] In some embodiments, the receiving application can call a public smart contract by using the DID string of the receiving mobile application to update the already uploaded receiving mobile application mapping information package. This update can be initiated by the receiving application to ensure the timeliness and accuracy of the information. However, the public smart contract can also automatically retire part or all of the contents of the stored mobile application mapping information package after a preset expiration time limit. This automatic retirement mechanism helps to maintain the validity and security of the data and prevent the accumulation of expired or invalid information. When the public smart contract performs an automatic retirement operation, it prompts the receiving mobile application to update its decentralized identifier string or public key to ensure the security and reliability of subsequent communications. In this way, the system can dynamically maintain and update key data without relying on centralized management, thereby improving the security and efficiency of the overall system.

[0045] like Figure 6 As shown, before the sender and receiver communicate, the sender mobile application 610 calls the public smart contract 250 using the decentralized identifier string of the receiver mobile application 620, and the public smart contract 250 verifies the decentralized identifier string of the receiver mobile application 620 to retrieve and pass the corresponding mapping information (including the receiver application public key) to the sender mobile application 610.

[0046] In step 612, the sender mobile application 610 generates a temporary elliptic curve key pair, and uses the temporary private key and the recipient's public key obtained from the public smart contract to generate a symmetric key identical to the recipient below according to ECDHE in step 613. This symmetric key can use different types of algorithms according to different encryption properties, such as 128-bit, 192-bit or 256-bit keys under the Advanced Encryption Standard (AES).

[0047] The elliptic curve is a mathematical curve used in encryption algorithms. It is used in blockchain wallets to generate public and private key pairs to improve security and efficiency. Specifically, the elliptic curve digital signature algorithm is based on the elliptic curve and realizes the generation of public and private keys and transaction signatures.

[0048] ECDHE is a key exchange protocol that securely exchanges encryption keys through elliptic curve algorithms to establish secure communication channels. The two communicating parties each generate a pair of elliptic curve key pairs (public key and private key). After exchanging public keys, each party uses its own private key and the other party's public key to calculate a shared symmetric encryption key through the elliptic curve Diffie-Hellman algorithm. This key shared by the two communicating parties is used to encrypt and decrypt subsequent communications to ensure the confidentiality and security of data transmission. The main feature of ECDHE is that a new temporary key is generated for each session, which improves security.

[0049] In step 615, the sender mobile application 610 is then started and passes the information payload to the receiver application 620. The information payload content includes: the URL scheme of the sender application (encrypted using a symmetric key); the current timestamp (encrypted using a symmetric key); the string data message payload (encrypted using a symmetric key); the sender application temporary public key (plain text), and signatures and ZKP (step 614) can be used to ensure that this information has not been tampered with.

[0050] The string data message payload in the information payload is the specific content of the communication message between applications. Applications can send various information through strings, such as: text messages - applications can send simple text messages, such as the content of conversations in chat applications; commands and instructions - applications can send commands or instructions to trigger specific operations, such as controlling devices or starting a function; data transmission - applications can send data through strings, such as transmitting user input data or settings in configuration files; status updates - applications can send status update information, such as notifying another application of the current running status or progress; error information - applications can send error information or logs for debugging and troubleshooting.

[0051] In step 621, the receiving application 620 starts and receives the information payload from the sending application 610, and verifies the ZKP and public signal value to ensure that the information has not been tampered with. The receiving application 620 uses the sending application's temporary public key transmitted in plain text and the receiving application's private key to calculate the same symmetric key as the sender. The symmetric nature of this key allows the receiving application to directly decrypt the information payload through a calculation result independent of the sender, even though the symmetric key itself is not transmitted in plain text. The receiving application 620 processes the decrypted communication message, thereby completing the one-way communication process between the two parties.

[0052] Step 622 indicates the start of reverse communication. In the reverse communication process from the receiver to the sender, the roles of the receiver's mobile application and the sender's application are interchanged, but the specific steps are consistent with the forward communication described above.

[0053] like Figure 7 As shown, in some embodiments, the receiver, sender and public smart contract system of the present invention can all be operated by a specially configured system, wherein the systems are coupled to each other using communication. The receiver system 710 includes the following modules: an upload module 711 is configured to upload a receiver application mapping information package to a public smart contract, the information package containing a decentralized identifier string and a public key of the receiver application; a receiving module 712 is responsible for receiving a communication payload sent by a sender application, the communication payload including a public key of the sender application and a string data message encrypted using a first symmetric encryption key; the receiving module 712 simultaneously processes and verifies the received communication payload to ensure the authenticity of its source and the integrity of the data; a key generation module 713 uses the communication payload and the private key of the receiver application to derive a second symmetric encryption key, i.e., a symmetric encryption key that is the same as the first symmetric encryption key of the sender application; and a decryption module 714 uses the second symmetric encryption key to decrypt the string data message and ensure that the received data can be correctly decrypted and read. In some other embodiments, the recipient system 710 may also be configured using the update module 715 to call a public smart contract using the recipient application decentralized identifier string to update part or all of the contents of the uploaded recipient application mapping information package.

[0054] The sender system 720 may include the following modules: a communication module 721 is configured to call a public smart contract using a receiver application decentralized identifier string; a receiving module 722 is configured to receive a communication payload sent by the sender application; a key generation module 723 is configured to derive a second symmetric encryption key using the communication payload and the receiver application private key; and a decryption module 724 is configured to decrypt the string data message using the second symmetric encryption key. In some other embodiments, the receiving module 722 is further configured to receive a message that the receiver application successfully decrypts the string data message; after receiving the message, one or both of the sender application private key and the first symmetric encryption key are automatically invalidated. The receiving module 722 may also be configured to upload the communication payload containing the sender mobile application public key and the string data message to the public message bus.

[0055] The public smart contract system 730 may include the following modules: a receiving module 731 configured to receive an application mapping information package containing a receiver application decentralized identifier string and a public key and receive a call request using the receiver application decentralized identifier string; a storage module 732 configured to store the receiver application mapping information package; a verification module 733 configured to verify the receiver application decentralized identifier string; and a sending module 734 configured to determine whether the verification is passed and send the receiver application public key to the sending application. In some embodiments, the receiving module 731 is further configured to accept the receiver application mapping information package on the condition that a zero-knowledge proof transmission is generated by a zero-knowledge proof protocol, which independently verifies the authenticity of the receiver mobile application mapping information package and the receiver mobile application's ownership of the mapping information package. In some other embodiments, the storage module 732 automatically retires part or all of the content in the stored mobile application mapping information package after a preset expiration time limit, and prompts the receiver mobile application to use the update module 715 to update the receiver mobile application decentralized identifier string or the receiver mobile application public key via the sending module 734.

[0056] In some practical examples, the symmetric key pair generated in the above method and system is automatically invalidated after a communication is completed. After the receiving application decrypts the string data message, all or part of the sending application private key, the first symmetric encryption key, the receiving application private key and the second symmetric encryption key are automatically invalidated, so that new keys are required for any subsequent communication.

[0057] In some embodiments, the receiving mobile application uploads a public key array containing multiple receiving mobile application public keys to the public smart contract. Since an application can be configured with multiple URL schemes, and each URL scheme can be associated with a public key, an application can correspond to multiple public keys. These public key arrays can contain multiple different public keys corresponding to different usage scenarios and security requirements. The receiving mobile application can also specify the use conditions of any one of the receiving mobile application keys in the public key array to the public smart contract. These use conditions can be determined based on the security level requirements of the communication and the corresponding computational costs. For example, in communications that require a high level of security, you can choose to use a public key with a higher computational cost but stronger security; in general communications, you can choose a public key with a lower computational cost to improve efficiency.

[0058] In some embodiments, the application object of this technical solution can be further extended to any two applications or entities that use strings to communicate. This means that it is not limited to a specific type of mobile application, and any system that can transmit data through strings can benefit from this technical solution. For example, the sender application and the receiver application can be associated with an email server. In this case, the URL scheme of the receiver mobile application can be an email address.

[0059] In some embodiments, the sender application uploads a communication payload containing the sender application public key and a string data message to a common message bus. A common message bus is a broker mechanism that allows data exchange and communication between multiple applications. By uploading the communication payload to the common message bus, the sender application can enable multiple parties, including the recipient application, to choose to establish secure communication with the sender mobile application.

[0060] Specifically, in this embodiment, the sender application first generates a communication payload containing its public key and a string data message. Then, this communication payload is uploaded to the public message bus. The receiver application and other potential receivers can obtain this communication payload from the public message bus and use the sender's public key for verification and decryption, thereby establishing a secure communication channel.

[0061] In some embodiments, snapshots of public smart contracts and uploaded mobile application mapping information packages can be stored on a local storage medium as an offline directory. The snapshot content of the offline directory includes the current state of the smart contract and detailed information of the mobile application mapping information package. This offline directory can provide access when the device cannot connect to the network, ensuring that the mobile application can still view and use the stored mapping information package and retrieve the mapping information of other applications for establishing a confidential communication channel.

[0062] When the device reconnects to the network, the offline directory in this embodiment can automatically update the snapshot content to reflect the latest smart contract status and changes in the uploaded mobile application mapping information package. This mechanism ensures that the information in the offline directory is always up to date, and mobile applications can rely on this information for operation without worrying about outdated or inaccurate data.

[0063] In view of the deficiencies in the prior art, the solution proposed in the present invention has the following advantages:

[0064] By using ECDHE symmetric keys to encrypt communications between applications, the present invention eliminates the risk of data leakage during the communication process. By using public keys stored in smart contracts, the present invention ensures that malicious applications cannot achieve their harmful intentions by imitating the same URL structure or link. This is because malicious applications cannot use ECDHE to decrypt intercepted data without holding the private keys of both communicating parties.

[0065] With blockchain and smart contracts, the sending application can query the public key of any other application through the URL scheme or link. Since the URL scheme can be chosen arbitrarily, this also eliminates the possibility of the scheme being maliciously registered - if the URL scheme is found to have been preemptively registered during the application development phase, the developer can change it at any time. Once the registration in the public smart contract is successfully confirmed, the application can be safely released.

[0066] In addition to the temporarily created public key, all messages are encrypted with ECDHE symmetric keys and data integrity is verified using ZKP. This ensures that the transmitted data is not affected by malicious sniffing, tampering, or replay attacks. Although the temporarily created public key is transmitted in plain text, it is meaningless for an attacker to obtain it. This is because the public key is only valid when used with the application's private key, and the public key will not be used subsequently.

[0067] The protocol in the present invention is a one-way and disposable communication protocol. By repeating this one-way and disposable protocol, multiple communications between applications can be achieved. The advantage of this method is that the applications do not need to maintain any session information (although they can choose to maintain sessions at the application layer, it is not necessary at the protocol layer). This design simplifies the communication process and reduces the complexity and resource consumption of the system. Since there is no need to maintain the session state, the application can process communication requests more efficiently, especially in a high-concurrency environment. In addition, this protocol also improves security because each communication is independent and attackers cannot obtain continuous communication data by hijacking the session.

[0068] The communication protocol does not have a dedicated handshake phase. The first message sent carries the application layer communication content in the information payload and is transmitted in a secure and encrypted manner. This design simplifies the communication process and avoids the extra steps required by traditional handshake protocols, thereby improving communication efficiency. After all, in mobile operating systems, each inter-application communication through redirection will incur a certain cost to the user experience. By omitting the handshake phase, applications can establish communication connections more quickly, reduce latency, and improve user experience.

[0069] Through the protocol provided by the present invention, messages between applications are encrypted using ECDHE symmetric keys. The ECDHE protocol ensures that different temporary keys are used for each communication session. This temporary nature improves security because even if the key of a session is cracked, it will not affect the security of other sessions. Since EDCHE uses temporary key pairs, it also provides forward secrecy, which means that even if the long-term key is leaked, past session data is still safe.

[0070] Before a trusted data channel is established, all data transmitted between applications is non-private data. If this data is tampered with or illegally obtained by a third party, it will be discovered in time during the user confirmation phase. To ensure security, in the final zero-knowledge proof circuit phase, some of the data transmitted at the beginning is also verified twice.

[0071] ZKP effectively balances the privacy and verifiability requirements in information transmission. Mobile applications use ZKP to prove the relationship between public and private key pairs, but at the same time hide the private key and only disclose the public key. In addition, because applications must use ZKP to prove their ownership and authenticity of the private-public key pair of the relevant DID string, it prevents the possibility of data being tampered with from leaving the sending application to reaching the receiving application, while preventing malicious third parties from deliberately passing the architecture of another application to achieve attack behavior.

[0072] In practice, the systems and methods described herein can be used to establish secure communication channels to protect the highly sensitive communication data content between applications. From a technical perspective, these methods are necessary because mobile device operating systems usually impose network security restrictions on their applications to establish a "walled city" to effectively isolate memory, storage, and execution area components, resulting in the security of communication between applications outside of individual "walled cities" cannot be guaranteed.

[0073] In some cases, a user may have multiple interconnected mobile applications on their mobile device. As a non-limiting example, a financial institution may use multiple mobile applications simultaneously to provide services to its customers, such as an online banking application, an investment application, a budgeting application, a children's spending tracking application, a promotional discount / offer application, an airport lounge application, etc. However, due to technical isolation, these applications can only communicate in limited ways, or not at all.

[0074] Communication between applications may include single sign-on credentials, data records shared from one application to another, and function calls from one application to another through public APIs. Although deep links or universal links can be used between applications, these schemes have technical shortcomings in terms of communication capabilities and network security vulnerabilities related to third-party interception. They are also vulnerable to attacks by applications that may impersonate each other, for example, "twin applications" with the same or similar identifiers to confuse users and operating systems.

[0075] The present invention describes an improved method of using a public smart contract as a middleware intermediary between different applications, where the smart contract can be used as a facilitator for messaging between applications. In operation, applications pre-register by uploading their confidential messaging patterns to a public smart contract. When an application is requested to send a message to another application, the application can reference the pattern of the application based on an identifier, and then use the pattern to establish a secure communication protocol shared between the two applications, using the derivation method described herein. The sender can send secure string messages using a variety of different messaging methods, such as direct communication between applications, or placing the communication content on a message center bus. Zero-knowledge proofs, temporary keys, and expiration times of keys are variants that can be used in different proposed embodiments to reduce the feasibility of replay attacks when messages are intercepted, providing an additional layer of network security protection. To further reduce the possibility of replay attacks, another variant describes the use of a set of keys instead of uploading a single pattern or key.

[0076] In the method proposed in the present invention, although the application will increase the computational cost / complexity and potential computational expenses in accessing and updating smart contract data objects, this is a worthwhile technical trade-off, especially for highly sensitive data messaging such as identity authentication or other personal privacy information.

[0077] Figure 8 Schematic diagram of the structure of a computer device according to one aspect of the present invention. Figure 8As shown, the computing device may include: at least one processor ( Figure 8 Only one is shown in the figure), a memory, a computer-readable storage medium, and a computer program stored on the computer-readable storage medium in the memory and executable on at least one processor, and when the processor executes the computer program, the steps in the above-mentioned method embodiment for establishing a secure communication channel between mobile applications based on smart contracts are implemented. Those skilled in the art can understand that Figure 8 These are merely examples of computer devices and do not constitute limitations on the computer devices. The computer devices may include more or fewer components than those shown in the figure, or a combination of certain components, or different components. For example, they may also include a network interface, a display screen, and an input device.

[0078] Each process, method and algorithm described in the preceding section may be embodied in a code module executed by one or more computer systems or computer processors including computer hardware and implemented in full or in part automatically. Processing and algorithms may be implemented in part or in whole in a dedicated circuit. The various features and processes described above may be used independently of each other, or may be combined in various ways. All possible combinations and sub-combinations are intended to fall within the scope of this article. In addition, certain methods or processing blocks may be omitted in some embodiments. The methods and processes described herein are also not limited to any particular order, and the blocks or states associated therewith may be executed in other appropriate orders. For example, the blocks or states described may be executed in a different order than that specifically disclosed, or multiple blocks or states may be combined in a single block or state. Examples of blocks or states may be executed serially, in parallel, or in some other manner. Blocks or states may be added to or removed from the disclosed embodiments. Examples of systems and components described herein may be configured differently from those described. For example, elements may be added, removed, or rearranged compared to the disclosed embodiments.

[0079] The various operations of the methods described herein may be performed at least in part by one or more processors that are temporarily configured (e.g., by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors may constitute a processor-implemented engine that is used to perform one or more operations or functions described herein.

[0080] Similarly, the methods described herein may be implemented at least in part by a processor, wherein a specific processor is an example of hardware. At least some of the operations of the method may be performed by one or more processors or an engine implemented by the processor. In addition, one or more processors may also be operable to support the performance of related operations in a "cloud computing" environment, or as a "software as a service" (SaaS) operation. For example, at least some operations may be performed by a group of computers (as an example of a machine including a processor), which may be accessed via a network (e.g., the Internet) via one or more appropriate interfaces (e.g., application programming interface (API)).

[0081] The performance of certain operations can be distributed among processors, not only residing in a single machine, but also deployed across multiple machines. In some embodiments, the processor or the engine implemented by the processor can be located in a single geographic location (e.g., in a home environment, an office environment, or a server farm). In other embodiments, the processor or the engine implemented by the processor can be distributed in multiple geographic locations.

[0082] Although an overview of the subject matter has been described with reference to specific embodiments, various modifications and changes may be made to these embodiments without departing from the broader scope of the embodiments herein. The specific embodiments should not be construed as limiting, and the scope of the various embodiments is limited only by the appended claims and the full scope of equivalents to which such claims are assigned. In addition, the terms "step 1", "step 2", "step 3" or similar words do not represent a limitation on the order of steps in this article, but rather represent a feasible order in the implementation case. In addition, the terms "one", "an" and "multiple" do not represent a limitation on quantity in this article, but rather represent the presence of at least one of the items described.

Claims

1. A method for securely communicating with a sender application by calling a public smart contract, characterized in that: The public smart contract executes a set of application mapping information packages stored on a virtual state machine based on a distributed ledger, including: Uploading a recipient application mapping information package to the public smart contract, wherein the recipient application mapping information package includes a recipient application decentralized identifier string and a recipient application public key; receiving a communication payload sent by the sender application, the communication payload comprising a sender application public key and a character string data message encrypted using a first symmetric encryption key; deriving a second symmetric encryption key using the communication payload and a recipient application private key, the second symmetric encryption key being the same as the first symmetric encryption key; The string data message is decrypted using the second symmetric encryption key.

2. The method according to claim 1, characterized in that Further comprising: after successfully decrypting the string data message using the second symmetric encryption key, all or part of the first symmetric encryption key, the second symmetric encryption key and the recipient application private key are invalidated.

3. The method according to claim 1, characterized in that Further comprising calling the public smart contract using the recipient application decentralized identifier string to update part or all of the contents of the uploaded recipient application mapping information package.

4. The method according to claim 1, characterized in that It further includes uploading a public key array containing multiple public keys of the recipient application to the public smart contract, and specifying the usage conditions of each of the recipient application keys in the public key array to the public smart contract.

5. A method for securely communicating with a recipient application by calling a public smart contract, characterized in that: The public smart contract executes a set of application mapping information packages stored on a virtual state machine based on a distributed ledger, including: Invoking the public smart contract using the recipient application decentralized identifier string; receiving, from the public smart contract, a recipient mobile application public key corresponding to the recipient application decentralized identifier string; deriving a first symmetric encryption key using a sender application private key and said recipient mobile application public key; A communication payload is sent to the receiving application, the communication payload including a sender application public key and a string data message encrypted using the first symmetric encryption key.

6. The method according to claim 5, characterized in that Further including: Receiving a message indicating that the receiving application successfully decrypts the string data message; One or both of the sender application private key, the first symmetric encryption key, or both are automatically invalidated.

7. The method according to claim 5, characterized in that Further including: The communication payload including the sender mobile application public key and the string data message is uploaded to a common message bus.

8. A method for facilitating secure communication between applications, characterized in that: Executes a set of application mapping information packages stored on a distributed ledger-based virtual state machine, including: receiving a receiver application mapping information package, the receiver application mapping information package including a receiver application decentralized identifier string and a receiver application public key; Receiving a public smart contract call request from a sender application, wherein the call request includes a decentralized identifier string of the receiver application; Verifying the recipient application decentralized identifier string; If the verification is successful, the receiving application public key corresponding to the receiving application decentralized identifier string is sent to the sending application.

9. The method according to claim 8, characterized in that The receiving receiver application mapping information packet further includes: Acceptance of the recipient application mapping information package is conditional upon transmission of a zero-knowledge proof generated by a zero-knowledge proof protocol that independently verifies the authenticity of the recipient mobile application mapping information package and ownership of the mapping information package by the recipient mobile application.

10. The method according to claim 8, characterized in that Automatically decommissioning part or all of the stored content in the mobile application mapping information package after a preset expiration time limit, prompting the receiving mobile application to update the receiving mobile application decentralized identifier string or the receiving mobile application public key.

11. The method according to any one of claims 1 to 10, characterized in that The recipient mobile application decentralized identifier is a hash value of the recipient mobile application URL scheme.

12. The method according to claim 11, characterized in that The sender application and the receiver application are associated with an email server, and the receiver application URL scheme is an email address.

13. The method according to any one of claims 1 to 10, characterized in that The snapshot of the public smart contract and the uploaded recipient mobile application mapping information package are stored on a local storage medium as an offline directory, and the offline directory can reconnect to the network to update the snapshot content to reflect the latest status of the public smart contract and the mobile application mapping information package.

14. A receiving system for secure communication by calling a public smart contract, characterized in that: The receiving application is run on the system, and the public smart contract executes a set of application mapping information packages stored in a virtual state machine based on a distributed ledger, including: An upload module configured to upload a recipient application mapping information package to the public smart contract, wherein the recipient application mapping information package includes a recipient application decentralized identifier string and a recipient application public key; a receiving module configured to receive a communication payload sent by the sender application, the communication payload comprising a sender application public key and a character string data message encrypted using a first symmetric encryption key; a key generation module configured to derive a second symmetric encryption key using the communication payload and a recipient application private key, the second symmetric encryption key being identical to the first symmetric encryption key; A decryption module is configured to decrypt the string data message using the second symmetric encryption key.

15. The system of claim 14, wherein: After the decryption module successfully decrypts the character string data message using the second symmetric encryption key, all or part of the first symmetric encryption key, the second symmetric encryption key and the recipient application private key become invalid.

16. The system of claim 14, wherein: Further comprising an update module configured to call the public smart contract using the recipient application decentralized identifier string to update part or all of the contents of the uploaded recipient application mapping information package.

17. The system of claim 14, wherein: The upload module further uploads a public key array containing multiple public keys of the recipient application to the public smart contract, and specifies the usage conditions of each of the recipient application keys in the public key array to the public smart contract.

18. A sender system for secure communication by calling a public smart contract, characterized in that: The receiving application is run on the system, and the public smart contract executes a set of application mapping information packages stored in a virtual state machine based on a distributed ledger, including: a communication module configured to invoke the public smart contract using a recipient application decentralized identifier string; a receiving module configured to receive, from the public smart contract, a recipient mobile application public key corresponding to the recipient application decentralized identifier string; a key generation module configured to derive a first symmetric encryption key using a sender application private key and said recipient mobile application public key; A sending module is configured to send a communication payload to the receiving application, wherein the communication payload includes a sender application public key and a character string data message encrypted using the first symmetric encryption key.

19. The system of claim 18, wherein: The receiving module is further configured to receive a message indicating that the receiving application successfully decrypts the string data message; after receiving the message indicating that the receiving application successfully decrypts the string data message, one or both of the sending application private key and the first symmetric encryption key automatically become invalid.

20. The system of claim 18, wherein: The sending module is further configured to upload the communication payload including the sender mobile application public key and the string data message to a common message bus.

21. A public smart contract system that facilitates secure communication between applications, characterized in that: It executes a set of application mapping information packages stored on a distributed ledger-based virtual state machine, including: A receiving module configured to: receiving a recipient application mapping information packet, the recipient application mapping information packet comprising a recipient application decentralized identifier string and a recipient application public key; and Receiving a public smart contract call request from a sender application, wherein the call request includes a decentralized identifier string of the receiver application; A storage module configured to store the receiving-side application mapping information package; a verification module configured to verify the recipient application decentralized identifier string; A sending module is configured to send a receiving application public key corresponding to the receiving application decentralized identifier string to the sending application if the verification is successful.

22. The system of claim 21, wherein: The receiving module is further configured to accept the recipient application mapping information package conditional on the transmission of a zero-knowledge proof generated by a zero-knowledge proof protocol, wherein the zero-knowledge proof protocol independently verifies the authenticity of the recipient mobile application mapping information package and the recipient mobile application's ownership of the mapping information package.

23. The system of claim 21, wherein: The storage module automatically retires part or all of the stored content in the mobile application mapping information package after a preset expiration time limit, and prompts the receiving mobile application via the sending module to update the receiving mobile application decentralized identifier string or the receiving mobile application public key.

24. The system according to any one of claims 14 to 23, characterized in that The recipient mobile application decentralized identifier is a hash value of the recipient mobile application URL scheme.

25. The system of claim 24, wherein: The sender application and the receiver application are associated with an email server, and the receiver application URL scheme is an email address.

26. The system according to any one of claims 14 to 23, characterized in that The snapshot of the public smart contract and the uploaded recipient mobile application mapping information package are stored on a local storage medium as an offline directory, and the offline directory can reconnect to the network to update the snapshot content to reflect the latest status of the public smart contract and the mobile application mapping information package.

27. A computer device for securely communicating between applications by calling a public smart contract, characterized in that: include: one or more processors; and one or more computer readable memories coupled to the one or more processors and having instructions stored thereon, the instructions being executable by the one or more processors to perform the steps of the method of any one of claims 1 to 10.

28. A computer device for securely communicating between applications by calling a public smart contract, characterized in that: include: one or more processors; and one or more computer readable memories coupled to the one or more processors and having instructions stored thereon, the instructions being executable by the one or more processors to perform the steps of the method as recited in claim 11.

29. A computer device for securely communicating between applications by calling a public smart contract, characterized in that: include: one or more processors; and one or more computer readable memories coupled to the one or more processors and having instructions stored thereon, the instructions being executable by the one or more processors to perform the steps of the method as recited in claim 12.

30. A computer device for securely communicating between applications by calling a public smart contract, characterized in that: include: one or more processors; and one or more computer readable memories coupled to the one or more processors and having stored thereon instructions executable by the one or more processors to perform the steps of the method as recited in claim 13.

31. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 10 are implemented.

32. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to claim 11 are implemented.

33. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to claim 12 are implemented.

34. A computer-readable storage medium storing a computer program, characterized in that: When the computer program is executed by a processor, the steps of the method according to claim 13 are implemented.

Images