WO2025042326A1

WO2025042326A1 - System and method for secure email communication based on blockchain system

Info

Publication number: WO2025042326A1
Application number: PCT/SG2023/050569
Authority: WO
Inventors: Zhuo Jun LOH; Daphne Swee Lin NG; Zhibin Yu; Yuding WU
Original assignee: Dedoco Pte Ltd
Current assignee: Dedoco Pte Ltd
Priority date: 2023-08-18
Filing date: 2023-08-18
Publication date: 2025-02-27
Anticipated expiration: 2026-02-18

Abstract

The present invention relates to a method and system for secure email communication, incorporating encryption keys and blockchain technology for enhanced data integrity and authenticity. The method involves generating a unique pair of asymmetrical encryption keys. The sender's public key is used to encrypt email records and a sender's private key is used to digitally signed email record hashes that are stored in a blockchain ledger. A QR code is generated and embedded into the email for sending to a recipient for verification. The recipient can scan the QR code to retrieve the encrypted email records and the signed email record hashes for verification. An email risk score is calculated based on a verification result and sent do the recipient. This innovation provides a robust and efficient solution for secure email communication.

Description

SYSTEM AND METHOD FOR SECURE EMAIL COMMUNICATION BASED ON BLOCKCHAIN SYSTEM

TECHNICAL CONTRIBUTION

The present invention generally relates to a secure email method and system, and more particularly relates to a blockchain based secure email communication method and system for verification.

BACKGROUND

Email has become a ubiquitous means of communication in both personal and professional settings. However, the widespread use of email has also exposed users to various security risks and threats. Traditional email systems lack adequate security measures, making them susceptible to scams, unauthorized access, and malicious attacks.

Email scams, commonly known as phishing attacks, involve deceptive techniques that trick users into divulging sensitive information or clicking on malicious links embedded within emails. These scams often lead to identity theft, financial fraud, and unauthorized access to personal or organizational data.

Moreover, the traditional email infrastructure inherently possesses security vulnerabilities. Emails are typically transmitted in plain text, making it relatively easy for unauthorized entities to intercept and read the contents of the messages. Additionally, the centralized nature of email systems means that multiple entities, such as email service providers and network administrators, can potentially access users' email communications, increasing the risk of privacy breaches.

To address these critical security concerns, there is a clear need for an enhanced and more secure email system that incorporates robust verification mechanisms to ensure the authenticity of senders and the integrity of email content. Such a system should provide users with a higher level of confidence in the privacy and security of their email communications. Furthermore, other desirable feature and characteristics will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and this background of the disclosure.

SUMMARY OF INVENTION

In accordance with one aspect of the present invention, there is provided a method of secure email communication. The method includes: receiving an email from a sender with email metadata; creating an email record based on the email metadata of the email to uniquely identify the email; generating a pair of asymmetrical encryption keys, comprising a public key and a private key, for the sender; encrypting the email record using the sender's public key to create an encrypted email record; hashing the email record using a hash function to generate a hash email record; signing the hash email record using the sender’s private key to generate a signed email record hash; storing the generated signed email record hash in a blockchain system; generating a two-dimensional code representing the email based on the email record; embedding the two-dimensional code within the email; and sending the email with the two- dimensional code to the recipient for verification.

In some embodiments, the asymmetrical encryption keys are generated using an Rivest- Shamir-Adleman (RSA) or an Elliptic Curve Cryptography (ECC) algorithm.

In some embodiments, the hashing function is a SoliditySHA3 function.

In some embodiments, the two-dimensional code is a QR code or a bar code.

In some embodiments, the method further comprises a verification step: receiving the email by the recipient; scanning the two-dimensional code to retrieve the encrypted email record and the signed email record hash; decrypting the encrypted email record using the sender’s private key to extract the email record; comparing the decrypted email record with the sender's email record to determine whether the two email records match; decrypting the signed email record hash using the sender’s public key to extract the email record hash; generating an email record hash by hashing the email record; comparing the decrypted email record hash with the generated email record hash to determine whether the two email record hashes match; wherein the email is verified on the condition that both the decrypted email record matches with the sender's email record and the decrypted email record hash matches with the generated email record hash.

In some embodiments, the verification step further comprises steps performed by an artificial intelligence engine: receiving a recipient verification activity data associated with a user or entity, the verification data comprising a user-provided information and behavior-related data; analyzing the verification activity data to assess the authenticity and reliability of the recipient, wherein the analysis includes comparing the verification activity data with pre-validated data, and identifying any anomalies or suspicious activities; assigning weights or scores to different elements of the verification activity data based on their relevance and significance in determining a risk level; applying a machine learning algorithm to process the weighted verification data and generate a risk score that quantifies the likelihood being authentic or posing a potential risk; determining a risk threshold based on predefined criteria or system policies to differentiate between low, medium, and high-risk levels; comparing the generated risk score with the risk threshold to categorize the email as low, medium, or high-risk; and providing the risk score and verification result to the recipient.

In some embodiments, a warning is generated when the risk score is above a threshold value.

In some embodiments, an authorization token is generated for the sender or the recipient to log into a verification system.

In some embodiments, the method is implemented as an API integration for application generated emails or is implemented as an email plug-in/add-on for linking an email system with a verification system.

In accordance with another aspect of the present invention, there is provided a system of secure email communication comprising: a sender terminal for generating an email with email metadata; a verification server for creating an email record based on the email metadata to uniquely identify the email; a key generation module configured to generate a pair of asymmetrical encryption keys for the sender, including a public key and a private key; an encryption module configured to encrypt the email record using the sender's public key, a hashing module configured to generate a hash email record, which is further signed by the sender private key to produce a signed email record hash; a blockchain module configured to store the signed email record hash; an email two-dimensional code generation module configured to generate a two-dimensional code representing the email based on the email record; an embedding module configured to embed the two-dimensional code within the email; and a transmission module configured to send the email with the two-dimensional code to a recipient for verification.

In some embodiments, the asymmetrical encryption keys are generated using an RSA or an ECC algorithm.

In some embodiments, the hashing function is a SoliditySHA3 function.

In some embodiments, the two-dimensional code is a QR code or a bar code.

In some embodiments, the system further comprises a verification module, which comprising: a recipient terminal for receiving the email by the recipient; a scanning module for scanning the email two-dimensional code to retrieve the encrypted email record and the signed email record hash; a decrypting module for decrypting the encrypted email record using the sender’s private key to extract the email record; a comparing module for comparing the decrypted email record with the sender's email record to determine whether the two email records match; a decrypting module for decrypting the signed email record hash using the sender’s public key to extract the email record hash; a generating module for generating an email record hash using the email record; a comparing module for comparing the decrypted email record hash with the generated email record hash to determine whether the two email record hashes match; wherein the email is verified on the condition that both the decrypted email record matches with the sender's email record and the decrypted email record hash matches with the generated email record hash.

In some embodiments, the system further comprises an artificial intelligence engine for verification comprising: receiving a recipient verification activity data associated with a user or entity, the verification data comprising a user-provided information and behavior-related data; analyzing the verification activity data to assess the authenticity and reliability of the recipient, wherein the analysis includes comparing the verification activity data with prevalidated data, and identifying any anomalies or suspicious activities; assigning weights or scores to different elements of the verification data based on their relevance and significance in determining a risk level; applying machine learning algorithms to process the weighted verification activity data and generate a risk score that quantifies the likelihood of being authentic or posing a potential risk; determining a risk threshold based on predefined criteria or system policies to differentiate between low, medium, and high-risk levels; comparing the generated risk score with the risk threshold to categorize the email as low, medium, or high- risk; and providing the risk score and verification result to the recipient.

In some embodiments, the system is implemented as an API integration for application generated emails or is implemented as an email plug-in/add-on for linking an email system with a verification system.

In accordance with another aspect of the present invention, there is provided a computer- readable storage medium, on which a computer program is stored, wherein the computer program, when executed in a computer, causes the computer to perform any one of the methods discussed hereinabove.

In accordance with another aspect of the present invention, there is provided a memory and a processor, wherein the memory has stored therein executable code that when executed by the processor to perform any one of the methods discussed hereinabove.

It should be understood that the embodiments described herein are not exhaustive and that additional features and variations of the invention may be incorporated. Various other advantages and novel features of the invention will become apparent from the following detailed description when considered in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the present disclosure are described herein with reference to the drawings in which:

FIG. 1 is an architecture diagram of an email messaging system of the present invention.

FIG. 2 is a flowchart illustrating a secure email verification system in accordance with an embodiment of the present application.

FIG. 3A is a flowchart illustrating a secure email verification system using DeMail plug- in/add-on at the sender side in accordance with an embodiment of the present application.

FIG. 3B is a flowchart illustrating a secure email verification system using DeMail plug- in/add-on at both the sender and recipient sides in accordance with an embodiment of the present application.

FIG. 3C is a flowchart illustrating a secure email verification system using DeMail SDK at the sender side in accordance with an embodiment of the present application.

FIG. 3D is a flowchart illustrating a secure email verification system using DeMail SDK at the sender side and using DeMail plug-in/add-on at the recipient side in accordance with an embodiment of the present application.

FIG. 4 is a schematic diagram of an email to be sent containing a two-dimensional code in accordance with an embodiment of the present application.

FIG. 5 is a schematic representation of an exemplary embodiment of DeMail system 500. DETAILED DESCRIPTION

In the following detailed description, reference is made to the accompanying drawings, which form a part hereof. The illustrative embodiments described in the detailed description, drawings and claims are not meant to be limiting. Other embodiments can be utilized, and other changes can be made, without departing from the spirit or scope of the subject matter presented herein. Unless specified otherwise, the terms “comprising,” “comprise,” “including” and “include” used herein, and grammatical variants thereof, are intended to represent “open” or “inclusive” language such that they include recited elements but also permit inclusion of additional, unrecited elements.

To address the issued discussed above, a secure email communication system, called DeMail system, is provided that uses blockchain technologies to address challenges presented in the email communication system.

The secure DeMail system disclosed herein addresses the inherent vulnerabilities and security risks associated with traditional email communication. By leveraging the power of blockchain technology and cryptographic hashing algorithms, this innovative system ensures the authenticity, integrity, and privacy of email messages exchanged between users.

FIG. 1 is an architecture diagram of an email messaging system of the present invention. FIG. 1 shows a DeMail email sending and receiving system of the present invention. The system includes, but is not limited to, the sender terminal 101, the email server 102, the recipient terminal 104, and the DeMail system 103 for verification.

The sender terminal 101, and the recipient terminal 104 refer to the web application or third- party client (such as Outlook, Gmail), which is responsible for viewing, editing, retrieving and counting email.

The sender terminal 101 and the recipient terminal 104 can be any type of computer which is capable of connecting to and communicating emails over a data communication network. The data communication network can include the email servers 102 and the distributed database system among many other things. For example, the sender terminal 101 and the recipient terminal 104 can be a handheld computing device, a mobile phone, a laptop computer, a workstation, and/or a network of computing devices. The data communication network that the sender terminal 101 and the recipient terminal 104 communicate over can be any one or any combination of a local area network (LAN), wide area network (WAN), telephone network, wireless network, point-to-point network, star network, token ring network, hub network, or other appropriate configuration. The data communication network provides and supports data connectivity between the sender terminal 101 and the recipient terminal 104 and a system that includes the email servers 102. In practice, the data communication network may be any digital or other communications network capable of transmitting messages or data between devices, systems, or components. In certain embodiments, the data communication network includes a packet switched network that facilitates packet-based data communication, addressing, and data routing. The packet switched network could be, for example, a wide area network, the Internet, or the like. In various embodiments, the data communication network includes any number of public or private data connections, links or network connections supporting any number of communications protocols. The data communication network may include the Internet, for example, or any other network based upon a transfer control protocol and Internet protocol (TCP/IP) or other conventional protocols. That network will be used in many of the examples herein. However, it should be understood that the networks used with the embodiment described herein use are not so limited, although TCP/IP is a frequently implemented protocol. In various embodiments, the data communication network could also incorporate a wireless and/or wired telephone network, such as a cellular communications network for communicating with mobile phones, personal digital assistants, and/or the like. The data communication network may also incorporate any sort of wireless or wired local and/or personal area networks, such as one or more IEEE 802.3, IEEE 802.16, and/or IEEE 802.11 networks, and/or networks that implement a short range (e.g., Bluetooth) protocol.

The email server 102 includes basic interface service, email protocol service, and message queue service. Among them, the basic interface service is the main service of the email server 102, which is responsible for receiving, distributing and responding to requests from the email client, especially assembling and parsing the content of the mail according to the basic format of the email (MIME format). The protocol service is the core service of the email server. It supports SMTP, LMTP, POP3, IMAP and JMAP and other standard email protocols, and is responsible for sending and receiving emails. The DeMail system 103 is in responsible the email verification. The DeMail system 103 incorporates a decentralized blockchain network that acts as a tamper-proof ledger for storing and verifying the email metadata and cryptographic hashes. By distributing the data across multiple nodes in the network, it significantly reduces the risk of unauthorized access or modification.

FIG. 2 is a flowchart illustrating a secure email verification system in accordance with an embodiment of the present application. As a preliminary matter, it should be understood that steps of the method 200 are not necessarily limiting, and that steps can be added, omitted, and/or performed simultaneously without departing from the scope of the appended claims. It should be appreciated that the method 200 may include any number of additional or alternative tasks, that the tasks shown in FIG. 2 need not be performed in the illustrated order, and that the method 200 may be incorporated into a more comprehensive procedure or process having additional functionality not described in detail herein. Moreover, one or more of the tasks shown in FIG. 2 could be omitted from an embodiment of the method 200 as long as the intended overall functionality remains intact. It should also be understood that the illustrated method 200 can be stopped at any time. The method 200 is computer-implemented in that various tasks or steps that are performed in connection with the method 200 may be performed by software, hardware, firmware, or any combination thereof.

This method is primarily designed for application-generated emails like invoices and billing notifications with the application programming interface (API) integration to the existing email system. The API services facilitate seamless interaction between the client application servers and the DeMail system. User can also be triggered by third party's email plug-in/add-on unit, for example, Outlook plug-in unit, Gmail plug-in unit etc. These plug-ins/add-ons enable individual users to link their email accounts with the DeMail system.

For the DeMail verification system, it includes the application server 201, DeMail mobile app 202, DeMail server 203, DeMail public infrastructure key server 204, DeMail database server 205, DeMail blockchain server 206, DeMail Al engine 207, and/or DeMail data warehouse 208. The secure email communication method then begins at step S201 when the sender composes the email content on the email sender terminal (web application end or third-party client). After that, the sender sends the email to the email application server 201 and can choose to trigger the email verification process by using the DeMail system. The email web end or email plug- in/add-on unit receives the trigger request that user triggers, together with the metadata of the email.

In a preferred embodiment, the system may require an authorization token generated by the DeMail system in order to use the DeMail email verification system. Before triggering the email verification process, the sender needs to be authenticated by the DeMail system. The initial step entails requesting authentication by providing the credentials, such as the email address. Upon successful verification, users will be granted an authentication token that serves as a unique identifier and access pass. This token acts as a safeguard, ensuring that only authenticated users can interact with the system, safeguarding sensitive information and preventing unauthorized access. This step can be done by the DeMail mobile app 202.

After the request is triggered, the system sends the email metadata to the DeMail server 203 at S202. The metadata of the email include at least one of the information related to the sender, recipient, email subject, and timestamp etc. At S203, upon the receipt of email metadata and/or the appropriate authorization token, the DeMail server 203 uses the information to generate an email record with a unique identifier. And this email record can be used to uniquely identify the email.

At S204, a pair of asymmetrical encryption keys, comprising a public key and a private key, is generated for the sender using the DeMail public infrastructure key server (PKI) 204. The keys are generated by employing an Rivest-Shamir-Adleman/Elliptic Curve Cryptography (RSA/ECC) algorithms. The sender's public key is used to encrypt the email record, subsequently the encrypted email record data is returned to the DeMail server 203 at S205. It should be noted that other asymmetrical key generation methods can also be used without departing from the scope of the invention. At S206, this encrypted email record data is then stored in the DeMail database server 205, for example the MongoDB database. This encryption process ensures that the email content remains confidential and inaccessible to unauthorized entities during transmission and storage.

At S207, in parallel, a version of the email record is hashed using a hashing function, such as the SoliditySHA3 function, and signed before being stored on the DeMail blockchain server 206, providing a means of data integrity validation. It should be noted that other hashing algorithms may also be employed. After generating the hashed email record, it is further signed using the sender private key to generate the signed email record hash at S208. At S209, the signed email record hash is returned back to the DeMail server 203. At S210, the generated signed email record hash is stored in the DeMail blockchain server 206. This cryptographic hash serves as a digital fingerprint of the email and is a crucial component in the subsequent verification process.

At S211, once these processes are completed, a two-dimensional code for the email, such QR code or bar code, is generated based on the email record information and sent back to the application server 201. This email two-dimensional code, which is for uniquely identifying the email, is then embedded within the email, and sent to the recipient at S212.

At S221, to view the content, the recipient needs to download the DeMail mobile app 202 from the app store or play store. On the first use, the app prompts the recipients to verify their email ownership via a one-time password (OTP), after which they receive an authorization token for using the DeMail verification system.

At S222, the recipient can then use the DeMail app 202 to scan the QR code, which, along with the authorized token if available, is sent to the DeMail Server 203. At S223, the DeMail server 203 retrieves the email record with the QR code. The DeMail server 203 then further retrieves the corresponding encrypted email record at S224 from the DeMail database server 205, and decrypts the encrypted email record using the stored sender private key at S225. The DeMail server 203 conducts a comparison of the decrypted email record with the sender’ s email record to determine whether the two email records match. If the recipient's received email record at S223 doesn't match the decrypted email record at S225, the request is deemed invalid and rejected. However, if the recipient's email aligns with the email record, the DeMail server 203 crossverifies the email record with the SoliditySHA3 hashed version on the blockchain to ensure its integrity at S228-230. At S228, the DeMail server 203 gets the signed hashed email record from the DeMail blockchain server 206. And the signed hashed record is returned at S229. At the DeMail server 203, it first decrypts the signed email record hash using the sender's public key to extract the email record hash. Subsequently, the DeMail server 203 calculates an email record hash by hashing the email record and compares it with the decrypted email record hash. The email is verified at S230 on the condition that both the decrypted email record matches with the sender's email record and the decrypted email record hash matches with the generated email record hash.

The verification process presented herein establishes a robust two-layer verification system, elevating security measures to ensure utmost data integrity and user authenticity. This verification process ensures the integrity of the email and establishes trust in the communication between the sender and recipient. Furthermore, it confirms that the email content has remained unchanged during transit and storage, providing assurance that the email has not been tampered with or modified. By combining two distinct layers of verification, this innovative approach significantly enhances the overall security.

Furthermore, the system may utilize smart contracts on the blockchain network to automate and enforce the verification process. These smart contracts validate the email record and the signed email record hash, providing an additional layer of security and trustworthiness to the email communication.

In a preferred embodiment, the recipient verification activity is then submitted to the DeMail artificial intelligence (Al) Engine 207 at S241. The DeMail Al Engine 207 is an integral part of the system that serves to assess and predict potential risks even after successfully verifying the email record and decrypted hash. While the cryptographic processes involving the sender's public and private keys, along with blockchain verification, ensure the integrity of the email record, the DeMail Al Engine 207 focuses on analyzing the recipient's scanning activities. After the recipient has successfully verified the email record and decrypted hash, the DeMail Al Engine 207 comes into play to evaluate the recipient's behavior and interactions with the QR code scanning process. It analyzes various factors, such as the frequency of identical scans, time gaps between scans, or instances of QR code scans by non-owners, among others. The DeMail Al Engine 207 's role is to detect any unusual or suspicious patterns in the recipient's scanning behavior, which may indicate potential risks or compromised QR codes that are not related to the content of the email itself. The purpose of this additional verification step is to provide an extra layer of security beyond the initial cryptographic verification. While the core verification of the email record and decrypted hash ensures the integrity of the email content, the DeMail Al Engine 207 focuses on assessing the user's interactions with the system. Depending on the risk score generated by the DeMail Al Engine 207, the recipient may be alerted if there is a medium to high risk of QR code compromise. The recipient can then proceed with caution or take appropriate measures to secure their communications.

At S243, the DeMail Al Engine 207, having been previously trained with various verification activities and rule sets (such as identical QR code scans frequency, the time gap between scans, or instances of QR code scans by non-owners), analyzes this verification activity to assign a risk score. The details of assigning a risk score comprising the following steps: The DeMail Al engine 207 receives a recipient verification activity data associated with a user or entity, and the verification data comprising user-provided information and behavior-related data. The recipient verification activity data is stored in the DeMail data warehouse 208 at step S242. The DeMail Al engine 207 analyzes the verification activity data to assess the authenticity and reliability of the recipient, wherein the analysis includes comparing the verification activity data with pre-validated data, and identifying any anomalies or suspicious activities.

In a preferred embodiment, before calculating the risk score for the user, the DeMail Al engine 207 would calculate a risk threshold value. Firstly, the weights or scores to different elements of the verification activity data are assigned based on their relevance and significance in determining a risk level. Machine learning algorithms are applied to process the weighted verification data and generate a risk score that quantifies the likelihood of the recipient being authentic or posing a potential risk. A risk threshold is then determined based on predefined criteria or system policies to differentiate between low, medium, and high-risk levels.

When the user verification activity data is sent to the DeMail Al engine 207, a user verification risk score is calculated at S243. The DeMail Al engine then compares the generated risk score with the risk threshold to categorize the user or entity as low, medium, or high-risk. At S244, the DeMail Al engine 207 returns the risk score and verification result to the DeMail server 203 for decision-making and security enhancement.

Upon receipt of this risk score, the DeMail server 203 communicates the email metadata and risk score to the DeMail mobile app 202 at S250, which is further shown to the recipient at S251. If there is a medium to high risk of QR code compromise, the DeMail app 202 alerts the recipient by displaying a warning alongside the email metadata and the risk score. If it is low risk or the email is verified to be safe, the DeMail app 202 would inform the recipient that the email is safe by displaying a sign confirming that the email received from the sender is safe and is not tampered.

Overall, the blockchain-based email system described herein offers enhanced security and privacy by encrypting and storing email information in distributed storage, generating and storing encrypted hashes in the blockchain, and employing a user verification process to validate the integrity of the email content. This system provides users with a secure and trustworthy platform for exchanging confidential email communications.

Advantageously, by leveraging blockchain technology, the email verification process offers heightened security compared to traditional methods. The decentralized nature of blockchain ensures that email verification records are distributed across multiple nodes, making it difficult for malicious actors to tamper with or forge verification data. This provides a robust and secure mechanism for verifying the authenticity of emails.

The integration of blockchain ensures that once email verification data is stored in the blockchain, it becomes immutable and tamper-proof. This means that the verification records cannot be altered or modified without leaving a trace, maintaining the integrity and transparency of the verification process. The transparent nature of blockchain also allows users to independently verify the authenticity of the verification records, enhancing trust.

By utilizing the blockchain for storing hashed email properties, the process ensures reliable and permanent storage of verification data. Traditional methods often rely on centralized databases, which are susceptible to data loss or corruption. In contrast, the decentralized and distributed nature of blockchain ensures that verification data remains intact and accessible, even in the event of hardware failures or network disruptions.

Furthermore, the decentralized nature of blockchain allows for scalability and flexibility in the email verification process. As the number of verification requests increases, the distributed network can handle the load efficiently, ensuring that verification remains fast and reliable.

The email verification process offers an efficient and user-friendly verification experience. The generation of QR codes simplifies the verification process, allowing users to easily scan the code using a mobile app or use Gmail or Outlook plug-in/add-ons to automatically verify the email with blockchain details. This streamlined approach reduces the time and effort required for verification, enhancing user convenience.

Additionally, the email verification process can seamlessly integrate with existing email platforms such as Gmail and Outlook, making it compatible with widely used email services. This compatibility ensures that users can easily adopt and utilize the verification process without the need for major system changes or disruptions. Hence, the process can be adapted to work with various email providers, making it versatile and adaptable to different environments.

FIG. 3A is a flowchart illustrating a secure email verification system using DeMail plugin/ Add-on at the sender side in accordance with an embodiment of the present application. The DeMail system can function as a plug-in/add-on to the existing email system. The standard email client could have a plug-in/add-on, which interacts with the email client’s user interface to capture the content of the email. After the sender comprising the email, the sender can trigger the email verification process by launching the DeMail plug-in/add-on. The verification process is similar to what have disclosed in FIG. 2. Detailed explanation can be referring to that of FIG. 2.

At step A01, the sender 301 composes the email using the existing email software 302, such as Outlook, Gmail etc. In step A02, the DeMail plug-in/add-on 3O3A will read the email properties from the email software 302. A plug-in, also known as an add-on or extension, is a modular piece of software designed to extend the functionality of an existing application or system. Plug-ins are created to integrate seamlessly with a host application, allowing users to add custom features or enhancements without modifying the core codebase. For the secure email communication system, the DeMail plug-in/add on 3O3A is integrated into the existing email system to enhance the security of the email system. By leveraging the plug-in/add-on, developers can ensure that the core functionality of their applications remains intact while granting users the freedom to expand the application's capabilities according to their requirements.

At step A03, the email properties are sent to the DeMail server 304 for encryption. At step A04, the sender private/public key is obtained from the public key infrastructure server 307. The email message undergoes encryption using asymmetric encryption algorithms, which employ both public and private keys generated by the public key infrastructure server 307. This encryption process ensures that the email content remains confidential and inaccessible to unauthorized entities during transmission and storage. When an email is sent, the DeMail server 304 encrypts the content using a public key associated with the sender. This encryption process confirms that the emails are from the sender, as the only registered and whitelisted sender can send the email using the DeMail system. At step A05, the encrypted email is stored in the centralized private immutable database 306.

At step A06, simultaneously, the server 304 generates a signed hash of the email content using the sender’s private key. This hash serves as a digital fingerprint of the encrypted message, uniquely representing its contents. The signed hash, along with other relevant metadata, are then stored in the decentralized blockchain network 305.

At step A07, a QR code/DeMail identifier which is to uniquely identify the email is generated and sends to the DeMail plug-in/add-on 3O3A. At step A08, the DeMail plug-in/add-on 3O3A attaches the QR code/DeMail identifier into the email and sends to the email software 302. The email is then sent together with the QR code to the recipient at step A09 through the email exchange servers 308. At the recipient's end 309, the email is received by the email software 302. The email verification process begins upon receiving the email for reading by the recipient 309 at step A10. At step Al l, when the recipient 309 receives the email, the recipient will use the DeMail verifier app 310A installed on the mobile device for verification. The recipient 309 scans the QR code in the email to retrieve the email properties. At step A12, the information of the scanned QR code is sent to the DeMail server 304. At step A13, the DeMail serve 304 retrieves the email properties and signed hash based on the QR code. The decryption module utilizes the sender's private key to decrypt the email message and restore its original content. Simultaneously, the system retrieves the corresponding signed hash stored on the blockchain network 305. At step A 14, the sender public key is retrieved.

At step A15, to verify the authenticity and integrity of the email message, the DeMail verifier mobile app 310A compares the decrypted signed hash with a recalculated hash of the decrypted message. If the hashes match, it indicates that the email message has not been tampered with during transit and remains unaltered. In parallel, the recipient manually cross-checks the decrypted email properties with the email they read. The email is verified on the condition that both the decrypted email record matches with the sender's email record and the decrypted email record hash matches with the generated email record hash.

This verification process ensures the integrity of the email and establishes trust in the communication between the sender and recipient. The secure email system described herein offers users a robust and reliable platform to exchange confidential information securely. By leveraging blockchain technology, cryptographic hashing, and encryption algorithms, it mitigates the risks of scams, unauthorized access, and privacy breaches prevalent in traditional email systems. Overall, the blockchain-based email system described herein offers enhanced security and privacy by encrypting and storing email information in distributed storage, generating and storing encrypted hashes in the blockchain, and employing a user verification process to validate the integrity of the email content. This system provides users with a secure and trustworthy platform for exchanging confidential email communications.

FIG. 3B is a flowchart illustrating a secure email verification system using DeMail plug-in/add- on at both the sender and recipient sides in accordance with an embodiment of the present application. This embodiment is similar to that of FIG. 3A. In both the sender side and the recipient side, the DeMail system functions as plug-in/add-on to the existing email system. Therefore, when the recipient conducts the verification process, there is no need to do it manually by scanning the QR code. Specifically, at step BIO in FIG. 3B, the DeMail verifying plug-in/add on 31 OB would automatically identify the email properties received from the email QR code.

The detailed processing steps are as follows: At step B01, the email sender composes the email using the email software 302. At step B02, the DeMail composer plug-in/add-on 3O3B reads the email properties. At step B03, the email properties are sent to the DeMail server 304 for encryption. At step B04, the sender private/public key is obtained, and the email message undergoes encryption using asymmetric encryption algorithms, which employ both public and private keys generated by the public key infrastructure server 307. At step B05, the encrypted email is stored in the centralized private immutable database 306. At step B06, simultaneously, the DeMail server 304 generates a signed hash of the email content, and it saves the email properties and the signed hash in the decentralized public blockchain 305. At step B07, the QR code/DeMail identifier is generated and sent back to the DeMail composer plug-in/add-on 3O3B. At step B08, the QR code/DeMail identifier is attached to the email. At the step B09, the email together with the QR code/DeMail identifier is sent to the recipient 309 through the email exchange servers 308. At step B10, the DeMail verifying plug-in/add-on 310B reads the email properties from the email software 302. At step Bl l, the DeMail verifying plug-in/add- on 310B sends the email properties to the DeMail server 304. At step B12, DeMail server 304 returns the email properties and the signed hash. At step B 13, the sender public key is obtained. At step B 14, the verification results are returned to the email software 302. Hence, the system can do the verification automatically and show the verification status to the recipient 309 at step B15. Again, the email is verified on the condition that both the decrypted email record matches with the sender's email record and the decrypted email record hash matches with the generated email record hash.

FIG. 3C is a flowchart illustrating a secure email verification system using DeMail Software Development Kit (SDK) at the sender side in accordance with an embodiment of the present application. This embodiment is similar to that of FIG. 3 A. In the sender side, instead of using the plug-in/add-on, the Demail software development kit is used. The DeMail SDK is a set of tools to build software for the DeMail verification platform. It allows the developer to build an app which can integrate with the existing email platform to facilitate the email verification process automatically.

An SDK is a comprehensive set of tools, libraries, documentation, and APIs to streamline the process of creating applications for a specific platform or programming language. SDKs offer a standardized framework to interact with the underlying software or hardware. By utilizing an SDK, developers can access pre-built functionalities, reducing the need to reinvent the wheel and enabling them to focus on building specific features or solutions. Additionally, web development SDKs facilitate interaction with web services, databases, and other common functionalities, accelerating the creation of robust web applications.

By integrating this SDK into the DeMail system, users no longer need to manually configure access controls or permission settings. The security system SDK offers a seamless experience, automating the email verification process based on a predefined set of rules or access control policies. It efficiently verifies the email, safeguards sensitive data, and prevents unauthorized access. This approach not only reduces the burden of manual setup but also ensures robust security measures without compromising on user experience or application performance. In the recipient side, the recipient needs to download the DeMail app to conduct the verification process. The verification process is similar to what have been disclosed in FIG. 3A.

The detailed processing steps are as follows: At step C01, an email trigger event is trigged by the system 301C and the system email composer 302C composes the email. At step C02, the DeMail SDK 3O3C reads the email properties. At step C03, the email properties are sent to the DeMail server 304 for encryption. At step C04, the sender private/public key is obtained, and the email message undergoes encryption using asymmetric encryption algorithms, which employ both public and private keys generated by the public key infrastructure server 307. At step C05, the encrypted email is stored in the centralized private immutable database 306. At step C06, simultaneously, the DeMail server 304 generates a signed hash of the email content, and it saves the email properties and the signed hash in the decentralized public blockchain 305. At step C07, the QR code/DeMail identifier is generated and sent back to the DeMail SDK 3O3C. At step C08, the QR code/DeMail identifier is attached to the email. At the step C09, the email together with the QR code/DeMail identifier is sent to the recipient 309 through the email exchange servers 308. At step CIO, the recipient 309 read the email from the email software 302. At step Cl 1, when the recipient 309 receives the email, the recipient will use the DeMail verifier app 310C installed on the mobile device for verification. The recipient scans the QR code in the email to retrieve the email properties. At step C12, the information of the scanned QR code is sent to the DeMail server 304. At step C13, the DeMail serve 304 returns the email properties and signed hash based on the QR code. At step C14, the sender public key is retrieved. At step C15, to verify the authenticity and integrity of the email message, the DeMail verifier mobile app 310C compares the decrypted signed hash with a recalculated hash of the decrypted message. It shows the email properties and the signed hash verification status to the recipient. In parallel, the recipient manually cross-checks email properties with the email they read. Again, the email is verified on the condition that both the decrypted email record matches with the sender's email record and the decrypted email record hash matches with the generated email record hash.

FIG. 3D is a flowchart illustrating a secure email verification system using DeMail SDK at the sender side and using DeMail plug-in/add-on on the receiver side in accordance with an embodiment of the present application. This embodiment is similar to that of FIG. 3A. In the sender side, instead of using the plug-in/addon, the Demail software development kit is used. In the recipient side, the DeMail system functions as plug-in/add-on to the existing system. Therefore, verification process is conducted automatically to improve the verification performance and the user experience.

The detailed processing steps are as follows: At step DOI, an email trigger event is trigged by the system 301D and the system email composer 302D composes the email. At step D02, the DeMail SDK 3O3D reads the email properties. At step D03, the email properties are sent to the DeMail server 304 for encryption. At step D04, the sender private/public key is obtained, and the email message undergoes encryption using asymmetric encryption algorithms, which employ both public and private keys generated by the public key infrastructure server 307. At step D05, the encrypted email is stored in the centralized private immutable database 306. At step D06, simultaneously, the DeMail server 304 generates a signed hash of the email content, and it saves the email properties and the signed hash in the decentralized public blockchain 305. At step D07, the QR code/DeMail identifier is generated and sent back to the DeMail SDK 3O3D. At step D08, the QR code/DeMail identifier is attached to the email. At the step D09, the email together with the QR code/DeMail identifier is sent to the recipient 309 through the email exchange servers 308. At step Dl l, the DeMail verifying plug-in/add-on 310D reads the email properties from the email software 302. At step Dl l, the DeMail verifying plug- in/add-on 310D sends the email properties to the DeMail server 304. At step D12, DeMail server 304 returns the email properties and the signed hash. At step D13, the sender public key is obtained. At step D14, the verification results are returned to the email software 302. Hence, the system can do the verification automatically and show the verification status to the recipient 309 at step D15. Again, the email is verified on the condition that both the decrypted email record matches with the sender's email record and the decrypted email record hash matches with the generated email record hash.

FIG. 4 is a schematic diagram of an email to be sent containing a two-dimensional code in accordance with an embodiment of the present application. After the sender generating the content of the email 400, a two-dimensional code 402 (for example QR code), which is uniquely identifying the email content 401, is generated and embedded into the email.

By incorporating such a two-dimensional code 402, the authenticity of the email 400 can be better assured, as recipients can easily verify the legitimacy of the sender and the message's origin. This implementation significantly mitigates the risk of counterfeit emails or phishing attempts. It is essential to mention that the mail client used for this purpose could be of various types, such as an Outlook type email client or a web version email client. Moreover, to ensure swift and seamless integration, the two-dimensional code can be added through either a plugin or API integration, catering to different client environments and user preferences. Therefore, for bulk and system generated email, the organization can embed the DeMail into their existing software through a simple API integration, or use an easy to use email plugin to attach the unique two-dimensional code to the email.

Furthermore, the encrypted two-dimensional code mentioned in the concept of this specification need not be limited to a specific form. Instead, it can take the form of any encrypted picture or encoding, such as QR code, bar code or any other forms, thereby providing flexibility and security in the anti-counterfeiting process.

When a recipient receives an email containing a two-dimensional code, they can scan or interact with the code to access additional information or verify the sender's identity. This process empowers users to distinguish between legitimate communications and potential phishing attempts or counterfeit emails.

In conclusion, by incorporating encrypted two-dimensional codes linked to the email content and enabling their easy integration through plug-in/add-on or API, the proposed solution reinforces the protection against counterfeiting and unauthorized access to sensitive information. This versatile approach enhances the security and trustworthiness of the mail communication system, benefiting both senders and recipients alike.

Overall, the inclusion of a warning through the use of two-dimensional codes contributes significantly to protecting the integrity and security of email communications. It adds an additional layer of defense against cyber threats, instilling confidence in users that their interactions with emails are more secure and reliable.

FIG. 5 is a schematic representation of an exemplary embodiment of DeMail system 500 suitable for use in an email verification system such as that depicted in FIG. 1. The DeMail system 500 can be integrated within the sender terminal 101 or the recipient terminal 104.

The exemplified configuration of system 500 include, but is not limited to, the following components: at least one processor 502, a memory 504, a user interface 506, a communication module 508, a display element 510, and an email system 512. In practicality, these elements within system 500 can be interconnected through a bus or any appropriate interconnection architecture.

The processor 502 can be implemented using various technologies and architectures designed to fulfil the described functions. It may be realized as a general-purpose processor, content addressable memory, digital signal processor, application-specific integrated circuit, field- programmable gate array, programmable logic device, discrete gate or transistor logic, discrete hardware components, or a combination thereof. Additionally, a processor can take the form of a microprocessor, controller, microcontroller, or state machine. Furthermore, the processor may be realized through a combination of computing devices, such as combining a digital signal processor with a microprocessor, utilizing multiple microprocessors, integrating one or more microprocessors with a digital signal processor core, or employing any other suitable configuration.

The memory 504 may be realized as RAM memory, flash memory, EPROM memory, EEPROM memory, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. In this regard, the memory 504 can be coupled to the processor 502 such that the processor 502 can read information from, and write information to, the memory 504. In the alternative, the memory 504 may be integral to the processor 502.

The user interface 506 may include or cooperate with various features to allow a user to interact with the system 500. Accordingly, the user interface 506 may include various human-to- machine interfaces, e.g., a keypad, keys, a keyboard, buttons, switches, knobs, a touchpad, a joystick, a pointing device, a virtual writing tablet, a touch screen, a microphone, or any device, component, or function that enables the user to select options, input information. The user interface 506 can be integrated connected to the sender terminal 101 or the recipient terminal 104.

The communication module 508 facilitates data communication as needed during the operation of the system 500. An embodiment of the system 500 may support wireless data communication and/or wired data communication, using various data communication protocols.

The display element 510 is suitably configured to enable the system 500 to render and display various screens, graphical user interfaces (GUIs), drop down menus, auto-fill fields, text entry fields, message fields, or the like. Of course, the display element 510 may also be utilized for the display of other information during the operation of the system 500, as is well understood. Notably, the specific configuration, operating characteristics, size, resolution, and functionality of the display element 510 can vary depending upon the practical implementation of the system 500. For example, if the system 500 is a desktop computer, then the display element 510 may be a relatively large monitor. Alternatively, if the system 500 is a cellular telephone device, then the display element 510 may be a relatively small integrated display screen, which may be realized as a touch screen. The email system 512 comprises the hardware, software, firmware, and/or processing logic that supports the various email messaging features and functions described herein that allow the user to send, receive and process email messages. In certain non-limiting embodiments, the email system 512 could be an email message application, a SMS message application, a text message application, chat message application, voice message application, P2P message application, P2M message application, M2M message application, M2P message application, etc.

Any suitable programming language can be used to implement the routines of particular embodiments including C, C++, Java, assembly language, etc. Different programming techniques can be employed such as procedural or object oriented. The routines can execute on a single processing device or multiple processors.

Particular embodiments may be implemented in a computer-readable storage medium (also referred to as a machine-readable storage medium) for use by or in connection with the instruction execution system, apparatus, system, or device. Particular embodiments can be implemented in the form of control logic in software or hardware or a combination of both. The control logic, when executed by one or more processors, may be operable to perform that which is described in particular embodiments.

While various aspects and embodiments have been disclosed herein, it will be apparent that various other modifications and adaptations of the invention will be apparent to the person skilled in the art after reading the foregoing disclosure without departing from the spirit and scope of the invention and it is intended that all such modifications and adaptations come within the scope of the appended claims. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit of the invention being indicated by the appended claims.

Claims

1. A method of secure email communication comprising the steps of: receiving an email from a sender with email metadata; creating an email record based on the email metadata of the email to uniquely identify the email; generating a pair of asymmetrical encryption keys, comprising a public key and a private key, for the sender; encrypting the email record using the sender's public key to create an encrypted email record; hashing the email record using a hash function to generate a hash email record; signing the hash email record using the sender’s private key to generate a signed email record hash; storing the generated signed email record hash in a blockchain system; generating a two-dimensional code representing the email based on the email record; embedding the two-dimensional code within the email; and sending the email with the two-dimensional code to the recipient for verification.

2. The method of claim 1, wherein the asymmetrical encryption keys are generated using an RSA or an ECC algorithm.

3. The method of claim 1, wherein the hashing function is a SoliditySHA3 function.

4. The method of claim 1, wherein the two-dimensional code is a QR code or a bar code.

5. The method of claim 1, further comprising a verification step: receiving the email by the recipient; scanning the two-dimensional code to retrieve the encrypted email record and the signed email record hash; decrypting the encrypted email record using the sender’s private key to extract the email record; comparing the decrypted email record with the sender's email record to determine whether the two email records match; decrypting the signed email record hash using the sender’s public key to extract the email record hash; generating an email record hash by hashing the email record; comparing the decrypted email record hash with the generated email record hash to determine whether the two email record hashes match; wherein the email is verified on the condition that both the decrypted email record matches with the sender's email record and the decrypted email record hash matches with the generated email record hash.

6. The method of claim 5, the verification step further comprising steps performed by an artificial intelligence engine: receiving a recipient verification activity data associated with a user or entity, the verification data comprising a user-provided information and behavior-related data; analyzing the verification activity data to assess the authenticity and reliability of the recipient, wherein the analysis includes comparing the verification activity data with prevalidated data, and identifying any anomalies or suspicious activities; assigning weights or scores to different elements of the verification activity data based on their relevance and significance in determining a risk level; applying a machine learning algorithm to process the weighted verification data and generate a risk score that quantifies the likelihood being authentic or posing a potential risk; determining a risk threshold based on predefined criteria or system policies to differentiate between low, medium, and high-risk levels; comparing the generated risk score with the risk threshold to categorize the email as low, medium, or high-risk; and providing the risk score and verification result to the recipient.

7. The method of claim 6, wherein a warning is generated when the risk score is above a threshold value.

8. The method of claim 1, wherein an authorization token is generated for the sender or the recipient to log into a verification system.

9. The method of claim 1, wherein the method is implemented as an API integration for application generated emails or is implemented as an email plug-in/add-on for linking an email system with a verification system.

10. A system of secure email communication comprising: a sender terminal for generating an email with email metadata; a verification server for creating an email record based on the email metadata to uniquely identify the email; a key generation module configured to generate a pair of asymmetrical encryption keys for the sender, including a public key and a private key; an encryption module configured to encrypt the email record using the sender's public key, a hashing module configured to generate a hash email record, which is further signed by the sender private key to produce a signed email record hash; a blockchain module configured to store the signed email record hash; an email two-dimensional code generation module configured to generate a two- dimensional code representing the email based on the email record; an embedding module configured to embed the two-dimensional code within the email; and a transmission module configured to send the email with the two-dimensional code to a recipient for verification.

11. The system of claim 10, wherein the asymmetrical encryption keys are generated using an RSA or an ECC algorithm.

12. The system of claim 10, wherein the hashing function is a SoliditySHA3 function.

13. The system of claim 10, wherein the two-dimensional code is a QR code or a bar code.

14. The system of claim 10, further comprising a verification module, which comprising: a recipient terminal for receiving the email by the recipient; a scanning module for scanning the email two-dimensional code to retrieve the encrypted email record and the signed email record hash; a decrypting module for decrypting the encrypted email record using the sender’s private key to extract the email record; a comparing module for comparing the decrypted email record with the sender's email record to determine whether the two email records match; a decrypting module for decrypting the signed email record hash using the sender’s public key to extract the email record hash; a generating module for generating an email record hash using the email record; a comparing module for comparing the decrypted email record hash with the generated email record hash to determine whether the two email record hashes match; wherein the email is verified on the condition that both the decrypted email record matches with the sender's email record and the decrypted email record hash matches with the generated email record hash.

15. The system of claim 14, the system further comprises an artificial intelligence engine for verification comprising: receiving a recipient verification activity data associated with a user or entity, the verification data comprising a user-provided information and behavior-related data; analyzing the verification activity data to assess the authenticity and reliability of the recipient, wherein the analysis includes comparing the verification activity data with prevalidated data, and identifying any anomalies or suspicious activities; assigning weights or scores to different elements of the verification data based on their relevance and significance in determining a risk level; applying machine learning algorithms to process the weighted verification activity data and generate a risk score that quantifies the likelihood of being authentic or posing a potential risk; determining a risk threshold based on predefined criteria or system policies to differentiate between low, medium, and high-risk levels; comparing the generated risk score with the risk threshold to categorize the email as low, medium, or high-risk; and providing the risk score and verification result to the recipient.

16. The system of claim 6, wherein a warning is generated when the risk score is above a threshold value.

17. The system of claim 1, wherein an authorization token is generated for the sender or the recipient to log into a verification system.

18. The system of claim 1, wherein the system is implemented as an API integration for application generated emails or is implemented as an email plug-in/add-on for linking an email system with a verification system.

19. A computer-readable storage medium, on which a computer program is stored, wherein the computer program, when executed in a computer, causes the computer to perform the method of any of claims 1-4.

20. A computing device comprising a memory and a processor, wherein the memory has stored therein executable code that when executed by the processor implements the method of any of claims 1-4.