System and method for secure communication / transactions in distributed ledger technology environment

Abstract

Disclosed is a system (100) for secure communication in a distributed ledger technology (DLT) environment The system includes a Principal Entity (PE) node (102) and a home DLT (104) configured to perform key exchange. The PE node (102) is configured to encrypt a message using a DLT encryption key, encode the encrypted message into a preset protocol format, and transmit the encoded message to a predefined route. The system further includes one or more other DLTs (106) communicatively coupled to the PE node (102) and the home DLT (104). A DLT of the one or more other DLTs (106) is configured to receive the encoded message, extract and compare message details against rules, decrypt the message using a DLT decryption key, apply template checking rules, and pass the decrypted message to a Short Message Service Center (SMSC) (108) for delivery.

Description

[0001] SYSTEM AND METHOD FOR SECURE COMMUNICATION / TRANSACTIONS IN DISTRIBUTED LEDGER TECHNOLOGY ENVIRONMENT

[0002] FIELD OF DISCLOSURE

[0003] The present disclosure relates to secure communication systems, and more particularly to a system and method for secure communication / transactions in a distributed ledger technology environment.

[0004] BACKGROUND

[0005] Distributed Ledger Technology (DLT) and blockchain systems have emerged as transformative technologies in various sectors, including finance, supply chain management, and telecommunications. These decentralized systems offer enhanced security, transparency, and immutability of recorded transactions. In the telecommunications industry, DLT has shown promise for improving processes related to messaging, user authentication, and regulatory compliance.

[0006] Existing DLT implementations in telecommunications often face challenges related to data privacy, scalability, and integration with legacy systems. While DLT provides a robust framework for recording transactions, the secure transmission of sensitive information between entities remains a concern. Current solutions may not adequately address the need for end-to-end encryption of messages or the secure exchange of cryptographic keys between participating nodes. Additionally, many systems struggle to balance the requirements of regulatory compliance, such as message content verification, with the need for user privacy and data protection.

[0007] Furthermore, conventional DLT-based messaging systems in telecommunications may suffer from performance limitations when handling high volumes of transactions. The process of reaching consensus across distributed nodes can introduce latency, potentially impacting real-time communication services. There is further a lack of standardized approaches for managing cryptographic key lifecycles and enforcing access controls within DLT environments, which can lead to security vulnerabilities and operational inefficiencies.

[0008] Therefore, there exists a need for a technical solution that solves the aforementioned problems of conventional communication systems.

[0009] SUMMARY

[0010] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

[0011] In an aspect of the present disclosure, a system for secure communication in a distributed ledger technology (DLT) environment is disclosed. The system includes a Principal Entity (PE) node and a home Distributed Ledger Technology (DLT). The PE node and the home DLT are configured to perform key exchange between each other. Upon confirmation of the key exchange, the PE node is configured to encrypt a message using a DLT encryption key to generate an encrypted message. The PE node encodes the encrypted message into a preset protocol format to generate an encoded message. The PE node transmits the encoded message to a predefined route. The system includes one or more other DLTs communicatively coupled to the PE node and the home DLT. A DLT of the one or more other DLTs is configured to receive the encoded message. The DLT extracts a message from the encoded message. The DLT compares a template lD and a sender lD of the extracted message against one or more rules. The DLT decrypts the information from the message using a DLT decryption key to generate a decrypted message. The DLT applies template checking rules and passes the decrypted message to a Short Message Service Center (SMSC) for delivery. In some aspects of the present disclosure, the PE node is registered with the home DLT. In some aspects of the present disclosure, the PE node is configured to receive a delivery status from the SMSC via the home DLT. The PE node receives the delivery status in the preset protocol format.

[0012] In some aspects of the present disclosure, the preset protocol format includes a Short Message Peer-to-Peer (SMPP) protocol format.

[0013] In some aspects of the present disclosure, to perform the key exchange between each other, the PE node is configured to generate a PE encryption key and a PE decryption key. The PE node transmits the PE encryption key to the home DLT. The home DLT is configured to generate a DLT encryption key and a DLT decryption key. The home DLT encrypts the DLT encryption key using the PE encryption key. The home DLT transmits the encrypted DLT encryption key to the PE node. The PE node is configured to decrypt the encrypted DLT encryption key using the PE decryption key and extract and store the DLT encryption key.

[0014] In some aspects of the present disclosure, the home DLT is configured to transmit the DLT decryption key to the one or more other DLTs using a blockchain network.

[0015] In some aspects of the present disclosure, the DLT encryption key and the DLT decryption key are generated based on one or more predefined conditions.

[0016] In some aspects of the present disclosure, upon receipt of an expiration request of the DLT encryption key and the DLT decryption key, the home DLT is configured to check validity of the one or more predefined conditions. The home DLT deletes the DLT encryption key and the DLT decryption key from a second key storage and generates an expiration signal. The home DLT transmits the expiration signal to the one or more other DLTs.

[0017] In some aspects of the present disclosure, the home DLT is configured to collect one or more statistics related to the used Template / Header combination for the expired pair of DLT encryption key and the DLT decryption key is used. In some aspects of the present disclosure, the PE node is configured to receive the expiration signal and the one or more statistics from the home DLT.

[0018] In an aspect of the present disclosure, a method for secure communication in a distributed ledger technology (DLT) environment is disclosed. The method includes performing key exchange between a Principal Entity (PE) node and a home Distributed Ledger Technology (DLT). Upon confirmation of the key exchange, the PE node encrypts a message using a DLT encryption key to generate an encrypted message. The PE node encodes the encrypted message into a preset protocol format to generate an encoded message. The PE node transmits the encoded message to a predefined route. A DLT of one or more other DLTs communicatively coupled to the PE node and the home DLT receives the encoded message. The DLT extracts a message from the encoded message. The DLT compares a template lD and a sender lD of the extracted message against one or more rules. The DLT decrypts the information from the message using a DLT decryption key to generate a decrypted message. The DLT applies template checking rules. The DLT passes the decrypted message to a Short Message Service Center (SMSC) for delivery.

[0019] In some aspects of the present disclosure, the method includes registering the PE node with the home DLT.

[0020] In some aspects of the present disclosure, the method includes the PE node receiving a delivery status from the SMSC via the home DLT. The delivery status is received in the preset protocol format.

[0021] In some aspects of the present disclosure, the preset protocol format includes a Short Message Peer-to-Peer (SMPP) protocol format.

[0022] In some aspects of the present disclosure, performing the key exchange includes the PE node generating a PE encryption key and a PE decryption key. The PE node transmits the PE encryption key to the home DLT. The home DLT generates a DLT encryption key and a DLT decryption key. The home DLT encrypts the DLT encryption key using the PE encryption key. The home DLT transmits the encrypted DLT encryption key to the PE node. The PE node decrypts the encrypted DLT encryption key using the PE decryption key. The PE node extracts and stores the DLT encryption key.

[0023] In some aspects of the present disclosure, the method includes the home DLT transmitting the DLT decryption key to the one or more other DLTs using a blockchain network.

[0024] In some aspects of the present disclosure, the DLT encryption key and the DLT decryption key are generated based on one or more predefined conditions.

[0025] In some aspects of the present disclosure, upon receipt of an expiration request of the DLT encryption key and the DLT decryption key, the method includes the home DLT checking validity of the one or more predefined conditions. The home DLT deletes the DLT encryption key and the DLT decryption key from a second key storage and generates an expiration signal. The home DLT transmits the expiration signal to the one or more other DLTs.

[0026] In some aspects of the present disclosure, the method includes the home DLT collecting one or more statistics related to the used Template / Header combination for the expired pair of DLT encryption key and the DLT decryption key is used.

[0027] In some aspects of the present disclosure, the method includes the PE node receiving the expiration signal and the one or more statistics from the home DLT.

[0028] The foregoing general description of the illustrative aspects and the following detailed description thereof are merely exemplary aspects of the teachings of this disclosure and are not restrictive.

[0029] BRIEF DESCRIPTION OF FIGURES

[0030] The following detailed description of the preferred aspects of the present disclosure will be better understood when read in conjunction with the appended drawings. The present disclosure is illustrated by way of example, and not limited by the accompanying figures, in which like references indicate similar elements. FIG. 1 illustrates a block diagram of a system for secure communication / transaction in Distributed Ledger Technology (DLT) system, according to an aspect of the present disclosure;

[0031] FIG. 2 illustrates a flowchart of a method for key generation and key exchange, according to an aspect of the present disclosure;

[0032] FIG. 3 illustrates a flowchart of a method for key validity and key expiration, according to an aspect of the present disclosure;

[0033] FIG. 4 illustrates a flowchart of a method for secure communication / transaction in DLT system, according to an aspect of the present disclosure; and

[0034] FIG. 5 illustrates a flowchart of a method for overall secure communication / transaction in DLT environment, according to an aspect of the present disclosure.

[0035] DETAILED DESCRIPTION

[0036] The following description sets forth exemplary aspects of the present disclosure. It should be recognized, however, that such description is not intended as a limitation on the scope of the present disclosure. Rather, the description further encompasses combinations and modifications to those exemplary aspects described herein.

[0037] The present disclosure provides a system and method for secure communication and transactions in a distributed ledger technology (DLT) environment. The system includes a principal entity node and a home DLT, both configured to perform a key exchange process. Upon successful key exchange, the principal entity node encrypts a message using a DLT encryption key, encodes the encrypted message into a preset protocol format, and transmits the encoded message to a predefined route. The system further includes one or more other DLTs communicatively coupled to the principal entity node and the home DLT. A DLT receives the encoded message, extracts the message, compares certain details of the extracted message against predefined rules, decrypts the message using a DLT decryption key, applies template checking rules, and passes the decrypted message to a Short Message Service Center (SMSC) for delivery. The system and method ensure secure communication and transactions in a DLT environment by providing end-to-end encryption of messages and secure exchange of cryptographic keys.

[0038] FIG. 1 illustrates a block diagram of a system 100 for secure communication in a distributed ledger technology (DLT) environment. The system 100 comprises a Principal Entity (PE) Node 102, a Home DLT 104, and one or more other DLTs 106.

[0039] The PE node 102 may include a protocol decoder / encoder 108, a first communication unit 110, an RSA 3072 key generator 112, a first key storage 114, a first field extractor 116, an encryption engine 118, a message service 120, an SMPP / Any TCP server 122, a web campaign manager 124, a CRM plugin 126, a database 128, and an API adapter 130.

[0040] The protocol decoder / encoder 108 may include suitable circuitry to perform one or more operations. The protocol decoder / encoder 108 may be communicatively coupled to the first communication unit 110. The protocol decoder / encoder 108 may be configured to encode and decode messages according to a preset protocol format. In some aspects of the present disclosure, the preset protocol format may include a Short Message Peer-to-Peer (SMPP) protocol format. The protocol decoder / encoder 108 may be further configured to handle various communication protocols for secure transmission of data within the system 100.

[0041] The first communication unit 110 may include suitable circuitry to perform one or more operations. The first communication unit 110 may be communicatively coupled to the protocol decoder / encoder 108 and the home DLT 104. The first communication unit 110 may be configured to establish and manage communication between the PE node 102 and other components of the system 100, such as the home DLT 104 and the one or more other DLTs 106. The first communication unit 110 may include suitable logic, circuitry, and interfaces that may be configured to support wired or wireless communication. The RS A 3072 key generator 112 may include suitable circuitry to perform one or more operations. The RS A 3072 key generator 112 may be communicatively coupled to the first key storage 114. The RS A 3072 key generator 112 may be configured to generate a PE encryption key and a PE decryption key. The RSA 3072 key generator 112 may utilize the RSA (Rivest-Shamir-Adleman) algorithm with a 3072-bit key length to ensure a high level of security for the generated keys. The 3072-bit length is chosen to provide long-term security against potential future advances in cryptanalysis.

[0042] The first key storage 114 may include suitable circuitry to perform one or more operations. The first key storage 114 may be communicatively coupled to the RSA 3072 key generator 112 and the encryption engine 118. The first key storage 114 may be configured to securely store the PE encryption key and the PE decryption key generated by the RSA 3072 key generator 112. The first key storage 114 may further be configured to store a DLT encryption key received from the home DLT 104.

[0043] The first field extractor 116 may include suitable circuitry to perform one or more operations. The first field extractor 116 may be communicatively coupled to the protocol decoder / encoder 108 and the encryption engine 118. The first field extractor 116 may be configured to extract relevant fields from incoming messages, such as template lD and sender lD, for further processing and validation.

[0044] The encryption engine 118 may include suitable circuitry to perform one or more operations. The encryption engine 118 may be communicatively coupled to the first key storage 114 and the first field extractor 116. The encryption engine 118 may be configured to encrypt messages using the DLT encryption key stored in the first key storage 114. The encryption engine 118 may further be configured to decrypt encrypted messages received from the home DLT 104 using the PE decryption key.

[0045] The message service 120 may include suitable circuitry to perform one or more operations. The message service 120 may be communicatively coupled to the encryption engine 118 and the SMPP / Any TCP server 122. The message service 120 may be configured to manage and process messages within the PE node 102, including handling message queues and ensuring proper message routing.

[0046] The SMPP / Any TCP server 122 may include suitable circuitry to perform one or more operations. The SMPP / Any TCP server 122 may be communicatively coupled to the message service 120 and the protocol decoder / encoder 108. The SMPP / Any TCP server 122 may be configured to handle SMPP protocol communications and other TCP-based protocols for secure message transmission.

[0047] The web campaign manager 124 may include suitable circuitry to perform one or more operations. The web campaign manager 124 may be communicatively coupled to the message service 120 and the CRM plugin 126. The web campaign manager 124 may be configured to manage and execute messaging campaigns, including scheduling and tracking message deliveries.

[0048] The CRM plugin 126 may include suitable circuitry to perform one or more operations. The CRM plugin 126 may be communicatively coupled to the web campaign manager 124 and the database 128. The CRM plugin 126 may be configured to integrate customer relationship management functionalities with the messaging system, allowing for personalized and targeted communication.

[0049] The database 128 may be communicatively coupled to the CRM plugin 126 and the API adapter 130. The database 128 may be configured to store various types of data associated with the system 100, including customer information, message templates, and transaction logs.

[0050] The API adapter 130 may include suitable circuitry to perform one or more operations. The API adapter 130 may be communicatively coupled to the database 128 and the first communication unit 110. The API adapter 130 may be configured to facilitate integration with external systems and services through standardized APIs, enabling seamless data exchange and interoperability.

[0051] The home DLT 104 may include a second communication unit 132, an RSA 2032 key generator 134, a timer and event generator 136, a second key storage 138, a protected encoder / decoder 140, a DLT rules validator 142, a second field extractor 144, a blockchain connector 148, and a templates storage 150.

[0052] The second communication unit 132 may include suitable circuitry to perform one or more operations. The second communication unit 132 may be communicatively coupled to the first communication unit 110 of the PE node 102 and the one or more other DLTs 106. The second communication unit 132 may be configured to establish and manage communication between the home DLT 104 and other components of the system 100.

[0053] The RS A 2032 key generator 134 may include suitable circuitry to perform one or more operations. The RS A 2032 key generator 134 may be communicatively coupled to the second key storage 138. The RSA 2032 key generator 134 may be configured to generate a DLT encryption key and a DLT decryption key. The RSA 2032 key generator 134 may utilize the RSA algorithm with a 2032-bit key length to ensure secure key generation. The 2032-bit length is chosen to balance security requirements with performance considerations, particularly to fit within the 254-byte limit of the SMPP protocol's short message parameter.

[0054] The timer and event generator 136 may include suitable circuitry to perform one or more operations. The timer and event generator 136 may be communicatively coupled to the second key storage 138 and the DLT rules validator 142. The timer and event generator 136 may be configured to manage key expiration events and trigger key renewal processes based on predefined conditions. The conditions may include timebased expiration (e.g., keys valid for a specific duration), usage-based expiration (e.g., keys valid for a certain number of messages), or a combination of both. The DLT encryption key and DLT decryption key may be generated based on one or more predefined conditions. In some aspects, the conditions may include time-based validity periods, such as keys that expire after a certain number of days. In other aspects, the conditions may include usage limits, where keys are valid for a specific number of messages. In some cases, the conditions may be a combination of factors determined by network policies and security requirements. The timer and event generator 136 may monitor the conditions and trigger key renewal processes as needed.

[0055] The second key storage 138 may be communicatively coupled to the RSA 2032 key generator 134 and the protected encoder / decoder 140. The second key storage 138 may be configured to securely store the DLT encryption key and the DLT decryption key generated by the RSA 2032 key generator 134.

[0056] The protected encoder / decoder 140 may include suitable circuitry to perform one or more operations. The protected encoder / decoder 140 may be communicatively coupled to the second key storage 138 and the second communication unit 132. The protected encoder / decoder 140 may be configured to encode and decode messages securely using the stored encryption and decryption keys.

[0057] The DLT rules validator 142 may include suitable circuitry to perform one or more operations. The DLT rules validator 142 may be communicatively coupled to the timer and event generator 136 and the second field extractor 144. The DLT rules validator 142 may be configured to validate incoming messages against predefined rules and ensure compliance with the DLT protocol. The rules may include checks for message format, content restrictions, and sender authentication.

[0058] The second field extractor 144 may include suitable circuitry to perform one or more operations. The second field extractor 144 may be communicatively coupled to the DLT rules validator 142 and the protected encoder / decoder 140. The second field extractor 144 may be configured to extract relevant fields from incoming messages for further processing and validation.

[0059] The blockchain connector 148 may include suitable circuitry to perform one or more operations. The blockchain connector 148 may be communicatively coupled to the second communication unit 132 and the one or more other DLTs 106. The blockchain connector 148 may be configured to facilitate secure communication and data exchange between the home DLT 104 and other DLTs 106 in the blockchain network. The system 100 may be designed to comply with various data protection regulations, such as the General Data Protection Regulation (GDPR). In some aspects, the PE node 102 and home DLT 104 may implement data minimization principles, ensuring that only necessary personal data is processed and transmitted. The encryption mechanisms provided by the encryption engine 118 and protected encoder / decoder 140 ensure secure storage and transmission of personal data. In some cases, the system 100 may provide mechanisms for data subject access requests and the right to be forgotten, which can be managed through the API adapter 130 and implemented across the DLT network.

[0060] The templates storage 150 may be communicatively coupled to the DLT rules validator 142. The templates storage 150 may be configured to store message templates and associated rules for message validation and processing. The templates may define the structure and content requirements for different types of messages.

[0061] The one or more other DLTs 106 may be communicatively coupled to the PE node 102 and the home DLT 104. The one or more other DLTs 106 may be configured to receive encoded messages, extract message content, compare template lD and sender lD against predefined rules, decrypt messages using the DLT decryption key, apply template checking rules, and pass decrypted messages to a Short Message Service Center (SMSC) for delivery.

[0062] In operation, the system 100 enables secure communication in a distributed ledger technology environment by performing key exchange between the PE node 102 and the home DLT 104, encrypting messages using the exchanged keys, encoding the encrypted messages into a preset protocol format, transmitting the encoded messages through a predefined route, and processing the messages at the receiving DLT nodes while ensuring compliance with predefined rules and templates.

[0063] PIG. 2 illustrates a flowchart of a method 200 for key generation and exchange in the distributed ledger technology (DLT) environment. The method 200 begins at step 202, where a Principal Entity (PE) node locally generates a key pair consisting of a PE encryption key and a PE decryption key. At step 202, the PE node 102 may utilize the RSA 3072 key generator 112 to generate the PE encryption key and the PE decryption key. The RSA 3072 key generator 112 may employ the RSA algorithm with a 3072-bit key length to ensure a high level of security for the generated keys.

[0064] At step 204, the PE node 102 stores the generated key pair in the first key storage 114. The first key storage 114 may securely store the PE encryption key and the PE decryption key generated by the RSA 3072 key generator 112. The first key storage 114 may implement various security measures to protect the stored keys from unauthorized access or tampering.

[0065] At step 206, the PE node 102 transmits a request signal that includes the PE encryption key to the home DLT 104. The first communication unit 110 of the PE node 102 may transmit the request signal to the second communication unit 132 of the home DLT 104. The request signal may be encoded using the protocol decoder / encoder 108 to ensure secure transmission.

[0066] At step 208, the home DLT 104 decodes the received request signal and extracts the required fields. The protected encoder / decoder 140 of the home DLT 104 may decode the received request signal. The second field extractor 144 may then extract the required fields, including the PE encryption key.

[0067] At step 210, the home DLT 104 stores the PE Encryption key in the second Key Storage 138. The second key storage 138 of the home DLT 104 may securely store the received PE encryption key for future use in secure communication with the PE node 102.

[0068] At step 212, the home DLT 104 generates an RSA Key pair comprising a DLT encryption key and a DLT decryption key. The RSA 2032 key generator 134 of the home DLT 104 may generate the DLT encryption key and the DLT decryption key using the RSA algorithm with a 2032-bit key length.

[0069] At step 214, the home DLT 104 stores the RSA Key Pair in the second key storage. The second key storage 138 may securely store the generated DLT encryption key and DLT decryption key for use in secure communication within the DLT network. At step 216, the home DLT 104 shares the generated DLT Decryption Key with one or more other DLTs 106 in a blockchain network. The blockchain connector 148 of the home DLT 104 may facilitate the secure sharing of the DLT decryption key with other DLTs 106 in the blockchain network.

[0070] At step 218, the home DLT 104 encrypts the DLT Encryption key using the PE Encryption key and sends it back as a response to the PE node 102. The protected encoder / decoder 140 of the home DLT 104 may encrypt the DLT encryption key using the PE encryption key stored in the second key storage 138. The encrypted DLT encryption key may then be transmitted to the PE node 102 via the second communication unit 132.

[0071] At step 220, the PE node 102 receives the response, decodes it, and extracts the required fields, such as the DLT encryption key. The protocol decoder / encoder 108 of the PE node 102 may decode the received response. The first field extractor 116 may then extract the required fields, including the encrypted DLT encryption key. The encryption engine 118 may decrypt the DLT encryption key using the PE decryption key stored in the first key storage 114.

[0072] FIG. 3 illustrates a flowchart of a method 300 for managing key expiration in the distributed ledger technology (DLT) environment. The method 300 begins with step 302, where the Home DLT 104 checks for an expiration signal.

[0073] At step 302, the timer and event generator 136 of the home DLT 104 may continuously monitor for key expiration events based on predefined conditions. The predefined conditions may include time-based expiration, usage limits, or other security-related factors.

[0074] At step 304, the method 300 determines if a signal is received. When no signal is received, the method 300 loops back to step 302 to continue checking. The timer and event generator 136 may continue monitoring for expiration events until a signal is detected. At step 306, when a signal is received, the Home DLT 104 checks the validity of conditions on which the key pair is generated. The DLT rules validator 142 may verify the conditions that led to the key pair generation and determine if the expiration is valid based on predefined rules and policies.

[0075] At step 308, the Home DLT 104 marks or deletes the Keys in the second Key storage 138 and communicates this action to other DLTs 106. The second key storage 138 may mark the expired keys as invalid or delete them entirely. The blockchain connector 148 may then communicate this action to the one or more other DLTs 106 in the blockchain network.

[0076] At step 310, the method 300 waits to receive confirmation from all the other DLTs 106. The second communication unit 132 may wait for acknowledgments from the one or more other DLTs 106 to ensure that all nodes in the network are aware of the key expiration.

[0077] At step 312, the method 300 checks if confirmation has been received. When confirmation is not received, it loops back to step 310 to continue waiting. The second communication unit 132 may implement a timeout mechanism to handle cases where confirmations are not received within a specified timeframe.

[0078] At step 314, once confirmation is received, the Home DLT 104 gathers all statistics related to the used Template / Header combination for which the secured key pair is being used and transmits the information to the PE node. The DLT rules validator 142 may collect usage statistics from the templates storage 150, and the second communication unit 132 may transmit the information to the PE node 102. The statistics may include information such as the number of messages processed, the distribution of traffic among DLTs, and performance metrics like throughput and latency. In some aspects of the present disclosure, the home DLT 104 may collect comprehensive statistics related to the used Template / Header combinations for expired key pairs. The statistics may include message volumes, delivery success rates, latency measurements, and usage patterns across different DLTs in the network. The database 128 of the home DLT 104 may store the statistics, which can be used for performance optimization, capacity planning, and identifying potential security threats. The PE node 102 may receive the statistics along with the key expiration confirmation, allowing for informed decision-making in future communications.

[0079] At step 316, the PE node 102 receives the key delete / disable confirmation along with the gathered statistics. The first communication unit 110 of the PE node 102 may receive the information, and the message service 120 may process and store the received statistics for future analysis and optimization of the secure communication system.

[0080] FIG. 4 illustrates a flowchart of a method 400 for secure communication in the distributed ledger technology (DLT) environment. The method 400 begins at step 402, where the PE node 102 uses the DLT Encryption Key to encrypt a SMS message.

[0081] At step 402, the encryption engine 118 of the PE node 102 may encrypt the SMS message using the DLT encryption key stored in the first key storage 114. The encryption ensures that the message content remains secure during transmission.

[0082] At step 404, the PE node 102 encodes the encrypted message into an agreed protocol format. The protocol decoder / encoder 108 may encode the encrypted message into a preset protocol format, such as the Short Message Peer-to-Peer (SMPP) protocol format.

[0083] At step 406, the PE node 102 transmits the encoded message to a desired route. The first communication unit 110 may transmit the encoded message to a predefined / desired route, which may include one or more DLTs in the network.

[0084] At step 408, a receiver node (either an Aggregator or Super Aggregator) passes the encoded and encrypted message until it reaches a DLT. The message may be routed through various nodes in the network until it reaches the intended DLT.

[0085] At step 410, the DLT extracts the message and compares the Template lD and Header against the rules. A second field extractor of the receiving DLT may extract the message, and a DLT rules validator of the receiving DLT may compare the Template !!) and Header against predefined rules stored in a templates storage of the receiving DLT. This step ensures that the message adheres to the agreed-upon format and content guidelines.

[0086] At step 412, the DLT uses the DLT Decrypt Key of the home DLT 104 shared in a secured Blockchain to decrypt the Message content. A protected encoder / decoder of the receiving DLT may use the DLT decryption key, which was previously shared via the blockchain network, to decrypt the message content. This step ensures that only authorized DLTs can access the original message content.

[0087] At step 414, the DLT applies template checking rules and passes the Decrypted message along with other required parameters to a Telecom SMSC node for Delivery. A DLT rules validator of the receiving DLT may apply template checking rules to ensure the message content complies with predefined templates stored in a templates storage of the receiving DLT. The rules may include checks for message length, content type, and any specific formatting requirements. After validation, a communication unit of the receiving DLT may pass the decrypted message to the SMSC for delivery.

[0088] At step 416, the SMSC node processes the message and routes it to a terminating network node. The SMSC may handle the final routing and delivery of the message to the intended recipient. This step may involve various processes such as message queuing, recipient address resolution, and protocol conversion if necessary. The SMSC may further apply additional filters or checks as required by local regulations or network policies.

[0089] At step 418, the terminating network node applies firewall rules and takes it further for delivery. The terminating network node may implement additional security measures to ensure the message complies with network policies before final delivery. This may include spam filtering, content analysis, and other security checks to protect the enduser and maintain network integrity. At step 420, the terminating network node confirms the transaction. The confirmation may include details such as delivery status (e.g., delivered, failed, pending) and timestamp. The confirmation serves as an acknowledgment that the message has been successfully processed and delivered or that an attempt at delivery has been made.

[0090] At step 422, the SMSC node converts the response into an agreed protocol (e.g., SMPP). The SMSC may encode the delivery confirmation into the same preset protocol format used for the original message transmission. This ensures consistency in communication protocols throughout the message lifecycle and allows for standardized processing of delivery reports.

[0091] At step 424, the SMSC node transmits the converted response back to the receiving DLT. The response may be routed through the DLT network back to the originating DLT. This step ensures that the sender receives confirmation of the message's status, maintaining end-to-end accountability in the messaging process.

[0092] At step 426, the PE node 102 receives the status of the message, completing the secure communication process in the DLT environment. The first communication unit 110 of the PE node 102 may receive the status message, and the message service 120 may process and store the delivery status for tracking and reporting purposes. The final step allows the sender to verify the successful transmission and delivery of their message, and may trigger further actions or notifications based on the delivery status. In cases of message delivery failures or network errors, the system 100 may implement robust error handling mechanisms. The message service 120 of the PE node 102 may be configured to manage automatic retries in case of delivery failures. The home DLT 104 and other DLTs 106 may implement alternative routing strategies to bypass network issues. In some aspects, the database 128 may store detailed error logs for subsequent analysis and system improvement. The comprehensive error handling approach ensures high reliability and facilitates continuous enhancement of the communication system.

[0093] FIG. 5 illustrates a flowchart of a method 500 for secure communication in the distributed ledger technology (DLT) environment. The method 500 begins with step 502, where a key exchange is performed between a Principal Entity (PE) node 102 and a home DLT 104.

[0094] At step 502, the PE node 102 and the home DLT 104 may perform a key exchange process as described in the method 200 (FIG. 2). This step ensures that both entities have the necessary encryption and decryption keys for secure communication. The key exchange process may be initiated periodically or based on certain triggers to maintain the security of the system 100.

[0095] At step 504, following the key exchange, a message is encrypted using a DLT encryption key to generate an encrypted message. The encryption engine 118 of the PE node 102 may encrypt the message using the DLT encryption key stored in the first key storage 114. The encryption ensures that the message content remains confidential during transmission through potentially unsecured networks.

[0096] At step 506, the encrypted message is encoded into a preset protocol format to generate an encoded message. The protocol decoder / encoder 108 may encode the encrypted message into a preset protocol format, such as the Short Message Peer-to-Peer (SMPP) protocol format. The encoding ensures compatibility with existing telecom infrastructure and standardizes the message format for efficient processing.

[0097] At step 508, the encoded message is transmitted to a predefined route. The first communication unit 110 of the PE node 102 may transmit the encoded message to a predefined route within the DLT network. The route may be determined based on factors such as network topology, load balancing, or specific routing rules defined in the system 100.

[0098] At step 510, a DLT receives the encoded message. One of the other DLTs 106 in the network may receive the encoded message through a communication unit. The DLT acts as an entry point for the message into the secure DLT environment.

[0099] At step 512, the message is extracted from the encoded message. The field extractor of the receiving DLT may extract the message content from the encoded format. This step prepares the message for further processing and validation within the DLT environment.

[0100] At step 514, the template lD and sender lD are compared against rules. The DLT rules validator of the receiving DLT may compare the extracted template lD and sender lD against predefined rules stored in the templates storage of the receiving DLT. The comparison ensures that the message adheres to the agreed-upon format and originates from an authorized sender.

[0101] At step 516, the information is decrypted using a DLT decryption key to generate a decrypted message. The protected encoder / decoder of the receiving DLT may use the DLT decryption key, which was previously shared via the blockchain network, to decrypt the message content. This step reveals the original message content for further processing and delivery.

[0102] At step 518, template checking rules are applied and the decrypted message is passed to a Short Message Service Center (SMSC) for delivery. The DLT rules validator of the receiving DLT may apply template checking rules to ensure the message content complies with predefined templates. The rules may include checks for message length, content type, and any specific formatting requirements. After validation, the communication unit of the receiving DLT may pass the decrypted message to the SMSC for delivery.

[0103] At step 520, a delivery status is received from the SMSC via the home DLT 104 in the preset protocol format, completing the secure communication process in the DLT environment. The delivery status may be routed back through the DLT network to the PE node 102, where it can be processed and stored for tracking and reporting purposes. The status may include information such as successful delivery, delivery failure, or pending status, along with relevant timestamps.

[0104] The system 100 and methods 200, 300, 400, and 500 described above provide a comprehensive solution for secure communication in a DLT environment. The system 100 ensures end-to-end encryption of messages, secure key exchange and management, compliance with predefined rules and templates, and efficient message routing and delivery.

[0105] The use of different key lengths (3072 bits for PE and 2032 bits for DLT) balances security requirements with performance considerations, particularly to fit within the constraints of existing protocols like SMPP. The system's ability to manage key expiration and gather usage statistics allows for continuous improvement and optimization of the communication process.

[0106] The template checking and rule validation mechanisms ensure that all messages comply with predefined standards and regulations, which is crucial in the telecommunications industry. The integration with existing telecom infrastructure, such as SMSCs, allows for seamless adoption of the secure communication system without requiring significant changes to the overall network architecture.

[0107] The system's blockchain-based approach to sharing decryption keys among DLTs ensures that the network remains secure and decentralized, preventing single points of failure and enhancing overall system resilience. The ability to handle various types of messages and campaigns through the web campaign manager and CRM integration provides flexibility for different use cases within the telecom industry.

[0108] In cases of failed message deliveries or other error scenarios, the system 100 provides detailed status reports and statistics, allowing for quick identification and resolution of issues. The scalability of the system 100 is enhanced by its distributed nature, allowing it to handle high volumes of messages by distributing the processing load across multiple DLT nodes.

[0109] The distributed nature of the system 100 allows for horizontal scaling to handle increasing message volumes. In some aspects, the home DLT 104 and other DLTs 106 may implement load balancing mechanisms to distribute traffic across multiple nodes. This approach ensures optimal performance even during peak usage periods. The blockchain connector 148 may facilitate the coordination of the distributed processing, allowing the system 100 to scale efficiently as the number of messages and participating nodes increases. This scalability, combined with the secure and compliant nature of the system 100, makes it suitable for a wide range of telecommunications applications, from small-scale messaging services to large-scale, high-volume communication platforms.

[0110] Thus, the system 100 and associated methods 200, 300, 400, and 500 may provide significant technical advancements in secure communication within distributed ledger technology environments. By implementing end-to-end encryption between principal entities and DLT nodes, the system 100 prevents unauthorized access and tampering during message transmission. The automated generation, exchange, and expiration of cryptographic keys enhance security measures while reducing the risk of key compromise. Message processing and validation are optimized across the DLT network, allowing for efficient handling of high transaction volumes and improved scalability. Template-based message validation and rule enforcement at the DLT node level ensure adherence to industry standards and regulatory requirements. Privacy protection is further enhanced by encrypting message content before transmission through intermediary nodes, effectively preventing information leakage to unauthorized parties. Additionally, the system's secure logging and statistics gathering capabilities improve auditability and traceability of transactions, facilitating comprehensive monitoring and analysis of system usage.

[0111] Aspects of the present disclosure are discussed here with reference to flowchart illustrations and block diagrams that depict methods, systems, and apparatus in accordance with various aspects of the present disclosure. Each block within these flowcharts and diagrams, as well as combinations of these blocks, can be executed by computer-readable program instructions. The various logical blocks, modules, circuits, and algorithm steps described in connection with the disclosed aspects may be implemented through electronic hardware, software, or a combination of both. To emphasize the interchangeability of hardware and software, the various components, blocks, modules, circuits, and steps are described generally in terms of their functionality. The decision to implement such functionality in hardware or software is dependent on the specific application and design constraints imposed on the overall system. Person having ordinary skill in the art can implement the described functionality in different ways depending on the particular application, without deviating from the scope of the present disclosure.

[0112] The flowcharts and block diagrams presented in the figures depict the architecture, functionality, and operation of potential implementations of systems, methods, and apparatus according to different aspects of the present disclosure. Each block in the flowcharts or diagrams may represent an engine, segment, or portion of instructions comprising one or more executable instructions to perform the specified logical function(s). In some alternative implementations, the order of functions within the blocks may differ from what is depicted. For instance, two blocks shown in sequence may be executed concurrently or in reverse order, depending on the required functionality. Each block, and combinations of blocks, can further be implemented using special-purpose hardware-based systems that perform the specified functions or tasks, or through a combination of specialized hardware and software instructions.

[0113] Although the preferred aspects have been detailed here, it should be apparent to those skilled in the relevant field that various modifications, additions, and substitutions can be made without departing from the scope of the disclosure. These variations are thus considered to be within the scope of the disclosure as defined in the following claims. Features or functionalities described in certain example aspects may be combined and re-combined in or with other example aspects. Additionally, different aspects and elements of the disclosed example aspects may be similarly combined and recombined. Further, some example aspects, individually or collectively, may form components of a larger system where other processes may take precedence or modify their application. Moreover, certain steps may be required before, after, or concurrently with the example aspects disclosed herein. It should be noted that any and all methods and processes disclosed herein can be performed in whole or in part by one or more entities or actors in any manner.

[0114] Although terms like "first," "second," etc., are used to describe various elements, components, regions, layers, and sections, these terms should not necessarily be interpreted as limiting. They are used solely to distinguish one element, component, region, layer, or section from another. For example, a "first" element discussed here could be referred to as a "second" element without departing from the teachings of the present disclosure.

[0115] The terminology used here is intended to describe specific example aspects and should not be considered as limiting the disclosure. The singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms "comprises," "includes," "comprising," and "including," as used herein, indicate the presence of stated features, steps, elements, or components, but do not exclude the presence or addition of other features, steps, elements, or components. As used herein, the term "or" is intended to be inclusive, meaning that "X employs A or B" would be satisfied by X employing A, B, or both A and B. Unless specified otherwise or clearly understood from the context, this inclusive meaning applies to the term "or."

[0116] Unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the relevant art. Terms should be interpreted consistently with their common usage in the context of the relevant art and should not be construed in an idealized or overly formal sense unless expressly defined here.

[0117] The terms "about" and "substantially," as used herein, refer to a variation of plus or minus 10% from the nominal value. This variation is always included in any given measure.

[0118] In cases where other disclosures are incorporated by reference and there is a conflict with the present disclosure, the present disclosure takes precedence to the extent of the conflict, or to provide a broader disclosure or definition of terms. If two disclosures conflict, the later-dated disclosure will take precedence.

[0119] The use of examples or exemplary language (such as "for example") is intended to illustrate aspects of the invention and should not be seen as limiting the scope unless otherwise claimed. No language in the specification should be interpreted as implying that any non-claimed element is essential to the practice of the invention.

[0120] While many alterations and modifications of the present invention will likely become apparent to those skilled in the art after reading this description, the specific aspects shown and described by way of illustration are not intended to be limiting in any way. A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the scope of the disclosure. Accordingly, other implementations are within the scope of the following claims.

Claims

I CLAIMS:

1. A system ( 100) for secure communication in a distributed ledger technology (DLT) environment, the system (100) comprising: a Principal Entity (PE) node (102) and a home Distributed Ledger Technology (DLT) (104), wherein the PE node (102) and the home DLT (104) are configured to perform key exchange between each other; wherein, upon confirmation of the key exchange, the PE node (102) is configured to (i) encrypt a message using a DLT encryption key to generate an encrypted message, (ii) encode the encrypted message into a preset protocol format to generate an encoded message, (iii) transmit the encoded message to a predefined route; one or more other DLTs (106) communicatively coupled to the PE node (102) and the home DLT (104), wherein a DLT of the one or more other DLTs (106) is configured to (i) receive the encoded message, (ii) extract a message from the encoded message, (iii) compare a template lD and a sender lD of the extracted message against one or more rules, (iv) decrypt the information from the message using a DLT decryption key to generate a decrypted message, and (v) apply template checking rules and pass the decrypted message to a Short Message Service Center (SMSC) (108) for delivery.

2. The system as claimed in claim 1, wherein the PE node (102) is registered with the home DLT (104).

3. The system as claimed in claim 1, wherein the PE node (102) is configured to receive a delivery status from the SMSC (108) via the home DLT (104), wherein the PE node (102) receives the delivery status in the preset protocol format.

4. The system (100) of claim 1, wherein the preset protocol format comprises a Short Message Peer-to-Peer (SMPP) protocol format.

5. The system (100) of claim 1, wherein to perform the key exchange between each other: the PE node (102) is configured to: generate a PE encryption key and a PE decryption key; and transmit the PE encryption key to the home DLT (104); and the home DLT (104) is configured to: generate a DLT encryption key and a DLT decryption key; encrypt the DLT encryption key using the PE encryption key; and transmit the encrypted DLT encryption key to the PE node (102). wherein, the PE node (102) is configured to decrypt the encrypted DLT encryption key using the PE decryption key and extract and store the DLT encryption key.

6. The system (100) as claimed in claim 1 , wherein the home DLT (104) is configured to transmit the DLT decryption key to the one or more other DLTs (106) using a blockchain network.

7. The system (100) as claimed in claim 1, wherein the DLT encryption key and the DLT decryption key are generated based on one or more predefined conditions.

8. The system (100) as claimed in claim 7, upon receipt of an expiration request of the DLT encryption key and the DLT decryption key, the home DLT (104) is configured to: check validity of the one or more predefined conditions; delete the DLT encryption key and the DLT decryption key from a second key storage (138) and generate an expiration signal; and transmit the expiration signal to the one or more other DLTs (106).

9. The system (100) as claimed in claim 8, wherein the home DLT (104) is configured to collect one or more statistics related to the used Template / Header combination for which the expired pair of DLT encryption key and the DLT decryption key is used.

10. The system (100) as claimed in claim 8, wherein the PE node (102) is configured to receive the expiration signal and the one or more statistics from the home DLT (104).I L A method (500) for secure communication in a distributed ledger technology (DLT) environment, the method (500) comprising: performing key exchange between a Principal Entity (PE) node (102) and a home Distributed Ledger Technology (DLT) (104); upon confirmation of the key exchange: encrypting, by the PE node (102), a message using a DLT encryption key to generate an encrypted message; encoding, by the PE node (102), the encrypted message into a preset protocol format to generate an encoded message; transmitting, by the PE node (102), the encoded message to a predefined route; receiving, by a DLT of one or more other DLTs (106) communicatively coupled to the PE node (102) and the home DLT (104), the encoded message; extracting, by the DLT, a message from the encoded message; comparing, by the DLT, a template lD and a sender lD of the extracted message against one or more rules; decrypting, by the DLT, the information from the message using a DLT decryption key to generate a decrypted message; applying, by the DLT, template checking rules; and passing, by the DLT, the decrypted message to a Short Message Service Center (SMSC) for delivery.

12. The method (500) as claimed in claim 11, further comprising registering the PE node (102) with the home DLT (104).

13. The method (500) as claimed in claim 11, further comprising: receiving, by the PE node (102), a delivery status from the SMSC via the home DLT (104), wherein the delivery status is received in the preset protocol format.

14. The method (500) as claimed in claim 11, wherein the preset protocol format comprises a Short Message Peer-to-Peer (SMPP) protocol format.

15. The method (500) as claimed in claim 11, wherein performing the key exchange comprises: generating, by the PE node (102), a PE encryption key and a PE decryption key; transmitting, by the PE node (102), the PE encryption key to the home DLT (104); generating, by the home DLT (104), a DLT encryption key and a DLT decryption key; encrypting, by the home DLT (104), the DLT encryption key using the PE encryption key; transmitting, by the home DLT (104), the encrypted DLT encryption key to the PE node (102); decrypting, by the PE node (102), the encrypted DLT encryption key using the PE decryption key; and extracting and storing, by the PE node (102), the DLT encryption key.

16. The method (500) as claimed in claim 11, further comprising transmitting, by the home DLT (104), the DLT decryption key to the one or more other DLTs (106) using a blockchain network.

17. The method (500) as claimed in claim 11, wherein the DLT encryption key and the DLT decryption key are generated based on one or more predefined conditions.

18. The method (500) as claimed in claim 17, further comprising, upon receipt of an expiration request of the DLT encryption key and the DLT decryption key: checking, by the home DLT (104), validity of the one or more predefined conditions; deleting, by the home DLT (104), the DLT encryption key and the DLT decryption key from a second key storage and generating an expiration signal; and transmitting, by the home DLT (104), the expiration signal to the one or more other DLTs (106).

19. The method (500) as claimed in claim 18, further comprising collecting, by the home DLT (104), one or more statistics related to the used Template / Header combination for which the expired pair of DLT encryption key and the DLT decryption key is used.

20. The method (500) as claimed in claim 18, further comprising receiving, by the PE node (102), the expiration signal and the one or more statistics from the home DLT (104).

Images