WO2018096539A1 - Controlling access to electronic messages and shared data - Google Patents

Controlling access to electronic messages and shared data Download PDF

Info

Publication number
WO2018096539A1
WO2018096539A1 PCT/IL2017/051283 IL2017051283W WO2018096539A1 WO 2018096539 A1 WO2018096539 A1 WO 2018096539A1 IL 2017051283 W IL2017051283 W IL 2017051283W WO 2018096539 A1 WO2018096539 A1 WO 2018096539A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
recipient
sender
secure
sma
Prior art date
Application number
PCT/IL2017/051283
Other languages
French (fr)
Inventor
Uriel R. Brison
Shlomo Cohen
Original Assignee
Logdog Information Security Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Logdog Information Security Ltd filed Critical Logdog Information Security Ltd
Publication of WO2018096539A1 publication Critical patent/WO2018096539A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0407—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the identity of one or more communicating identities is hidden
    • H04L63/0421—Anonymous communication, i.e. the party's identifiers are hidden from the other party or parties, e.g. using an anonymizer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • the present invention relates to the field of data privacy. More particularly, the invention relates to a method and system for controlling data after being shared with another party.
  • Private information includes, for instance, financial information (e.g. bank account details, credit card numbers and tax statements), intimate information (e.g. private conversations and photographs), work documents (e.g. scanned documents and confidential files) and passwords (e.g. clear text passwords, Social Security numbers and ID). Any piece of such information is required to be kept secure and highly protected from being accessed by unwanted parties.
  • financial information e.g. bank account details, credit card numbers and tax statements
  • intimate information e.g. private conversations and photographs
  • work documents e.g. scanned documents and confidential files
  • passwords e.g. clear text passwords, Social Security numbers and ID
  • Double Ratchet algorithm An exemplary common practice algorithm in digital communication security is the Double Ratchet algorithm that manages renewal and maintenance of short-lived cryptographic keys after an initial key exchange in instant messaging. This algorithm provides authentication, encryption, deniability and forward and future secrecy.
  • Double Ratchet algorithm may not be sufficient in all cases. For instance, in case the identity of the recipient of a message is unknown, or in case the recipient of the message doesn't have the messaging application through which the message was sent by the sender, the Double Ratchet algorithm will be insufficient.
  • Another solution is PGP-style protection, in which each user has a pair of private and public keys, and each message is encrypted by the sender with the recipient's public key (previously obtained by the sender) and signed with the sender's private key. This solution is not always sufficient because it doesn't provide forward secrecy, i.e. if at any time one's private key is compromised then any future or past message received thereby may be compromised.
  • the PGP-style solution doesn't provide deniability / privacy, i.e. any third party is able to verify the signature of the sender. Consequently, after a message has been sent, the sender cannot hide the fact that the message was sent by him.
  • Another solution is a single-ratchet protocol, Silent Circle Instant Messaging Protocol (SCIMP). Beginning with a common secret, each time a user sends a message, the user's key is hashed to generate the key for the next message and delete the old key from the memory. The drawback of this solution is that if a key is compromised at any point, the future messages are affected.
  • SCIMP Silent Circle Instant Messaging Protocol
  • Another method of protecting messages is by use of secure messaging. These use a single AES sender key that is published thereby on a separate channel (e.g. in person, mail or private message). In this method, however, any party holding the AES key is able to read any past or future messages sent by the sender.
  • the present invention relates to a method for controlling access to a message, characterize in that an exchange of encryption keys is initiated by a recipient upon receipt of a recipient's request by a sender, wherein said message may comprise one or more attached documents.
  • the method further comprises:
  • SMA Secure Messaging software Application
  • the remote server will notify the sender (e.g., via device OS/SMA) that the recipient would like to have access to the message (this after authenticating and verifying the recipient). Upon sender approval, the remote server will grant the permission to the recipient. If the sender has granted an access before, there is a configurable option that the remote server will automatically grant access for the next messages (e.g., either limited by time or number of messages).
  • the SMA communicates with the messaging host software application via at least one data input means associated with said host software application, by capturing data provided via said at least one data input means, wherein in particular the data input means is a virtual keyboard or a microphone of the sender/recipient device or any other data input means suitable for capturing data.
  • the data input means is a virtual keyboard or a microphone of the sender/recipient device or any other data input means suitable for capturing data.
  • the data input is performed by: a) text input capturing; b) accessibility API; c) OS API hooking; d) functioning as a keyboard where all text goes through; e) sharing to another app; and/or f) using browser extension to hook all activities.
  • the message comprises one or more of the following: text, an image, a document, an audio clip, or other data.
  • the access grant decision of the server is further based recipient's device associated data.
  • one of the message metadata rules comprises enabling the sender to approve or deny a recipient access.
  • the method further comprising allowing the sender to revoke the message after the message has been received by the recipient.
  • the message metadata comprises rules defining behavior of the message.
  • the behavior of the message includes one or more of the following aspects:
  • the recipient's device associated data may comprise: device oriented items, physical meters such as date, time and geolocation, and/or operational metrics.
  • the present invention relates to a method for creating a secure messaging channel between a sender and a recipient, comprising:
  • the metadata of the root message defines the behavior of the entire secure channel.
  • revocation of a root message causes revocation of other messages sent through the secure channel.
  • the present invention relates to a system for controlling access to a message comprising a first apparatus for delivering an encryption key request from a sender to a recipient, and a second apparatus for sending said request to said sender by said recipient upon receipt of a request, wherein said message may comprise one or more attached documents.
  • system further comprising:
  • a secure messaging server comprising a key exchange module configured to manage exchange of encryption keys between users; a message broker module configured to manage transport of messages, permissions and properties between users; a Data Loss Prevention (DLP) configuration module comprising configurable lists of words that invoke suggestions to use an encryption option; a database for storing messages, keys and user IDs; and
  • DLP Data Loss Prevention
  • the first and second apparatuses are user electronic communication devices capable of communicating over the internet with the secure messaging server and with the one or more transport medium servers, wherein each device comprising a transport application; and a secure messaging application (SMA) configured to block the transport application from accessing contents of a message, while generating another message to be sent using the transport application indicating that a secure message has been created.
  • SMA secure messaging application
  • the secure messaging server further comprises: a) a front end module communicating bi-directionally over the Internet with the user device's SMA; b) an in-queue module configured to receive incoming messages from user devices' SMAs; c) an out-queue module configured to receive outgoing messages for user devices' SMAs; and d) a push messaging manager configured to push notifications from the out-queue to SMAs of user devices.
  • Fig. 1 shows a system diagram of a system for securely transferring messages and shared data, according to an embodiment of the present invention
  • Fig. 2 shows a system diagram of a secure messaging system server according to an embodiment of the present invention
  • Fig. 3 shows a flowchart describing a process of securely sending a message from a sender to a recipient, according to an embodiment of the present invention
  • Fig. 4A shows a flowchart of a bootstrapping process in which a user enlists to a secure messaging system, according to an embodiment of the invention
  • Fig. 4B shows a flowchart describing a process of securely sending a message, according to an embodiment of the present invention
  • Fig. 5 shows a flowchart describing a process of responding to a message, according to an embodiment of the present invention
  • Fig. 6 shows a flowchart describing a process of securely sending a message, according to another embodiment of the present invention
  • Fig. 7 shows a flowchart describing a process of securely sending a message, according to yet another embodiment of the present invention
  • Fig. 8 illustrates screen displays of a sender and a recipient when a message is sent by the sender, according to an embodiment of the present invention.
  • messages is used to indicate an electronic form of exchanging digital content from a sender to one or more recipients. This term does not imply any particular messaging method, and the invention is applicable to all suitable methods of exchanging digital messages such as email, SMS, Instant Messaging (IM), Social Media Websites and the like.
  • IM Instant Messaging
  • the secure messaging method of the present invention allows controlling data after being shared with another party, regardless of the communication application being used.
  • the method comprises utilizing a secure messaging software application installed on a digital communication device of a user, the software application allowing the user to secure any online communication channel, regardless of whether the channel is secure, unsecure, public or private.
  • the software application (hereinafter the app) is agnostic to specifically used messaging applications, i.e. users are able to continue using the messaging application of their choice while the app sees to securing the communication channel.
  • the app provides presentation level security as an additional security level over other existing security levels (e.g. device-to-device).
  • the app provides a message sender control over information sent thereby even on devices of other parties.
  • the control is applied as retrieving, deleting, forward locking and auto- destructing messages.
  • the app provides context activated encryption by automatically identifying sensitive information and prompting users to send such information via a secured keyboard, as part of the system of the present invention. More specifically, on the sender side the app enables entered text to be captured and replaced with a secured message link. On the recipient side the app enables to capture a click on a link within a secured message and pass the handling to the app (access granting and decryption). The means for capturing text and clicks may vary.
  • One of the goals of the secure messaging app is to make digital security and privacy more accessible for users.
  • the following are examples in which users require a high level of security and protection of the data that they share with another user.
  • a user may wish to send a credit card PIN code to the user's spouse. In this case it is essential to protect the PIN code even in case the spouse's device is stolen.
  • a patient may send a photograph of the patient's private parts to a doctor in order to receive an opinion.
  • the patient would likely allow only one single view of the photo (for the doctor to see in order to diagnose), and wouldn't like it to appear in the doctor's message thread for bystanders to see.
  • the patient would like to make sure that only the doctor views the photograph by requiring the entry of the doctor's code.
  • the patient would like to prevent the doctor from downloading the photograph to a digital device or from capturing the screen without authorization from the patient.
  • the patient is capable of deleting the photograph from afar or automatically, for instance an hour after it is sent.
  • a user sends a private message to a group of friends. Because the message is private, the user wishes the message not to appear on the friends' message threads, or for their spouses to be able to read the message. The user wishes to be able to know exactly who views the message and to control who is permitted to view it, and to delete the message from afar (or automatically).
  • a recruiter reaches out to a potential candidate who is currently unemployed. The recruiter sends the candidate a direct message via, for instance, Linkedln, but doesn't want to make the candidate feel uncomfortable in case someone at his workplace gets a peek at his digital device.
  • the sender wants the ability to encrypt the subject line of a message as well as the content of the message. The sender wants to allow only the candidate to be able to read the message.
  • an insurance agent receives a copy of a client's passport in order to prepare travel insurance for the client for departure taking place in another 6 hours.
  • the client shared the document with the agent. Two hours afterwards the agent forwards the document to the insurance company in order to finalize the policy.
  • Fig. 1 shows a system diagram of a system 100 for controlling messages and shared data, according to an embodiment of the present invention.
  • System 100 comprises a secure messaging system server 110, one or more transport medium servers 160, and a plurality of user electronic communication devices (e.g. 140 and 150).
  • Each of devices 140 and 150 can be a smartphone, a wearable computer, a PDA, a tablet computer, a laptop computer, a personal computer, or any other electronic device capable of communicating over the internet with system server 110 and with the one or more transport medium servers 160.
  • transport medium servers 160 may include a messaging application server (e.g. WhatsApp, Google Hangouts), an email server (e.g. Gmail or Yahoo), a social network server (e.g. Twitter, Instagram, Facebook) or any other server through which digital data is transferred between users.
  • a messaging application server e.g. WhatsApp, Google Hangouts
  • an email server e.g. Gmail or Yahoo
  • social network server e.g. Twitter, Instagram, Facebook
  • System server 110 comprises backend software components 120, including a key exchanging module 122 configured to manage exchange of encryption keys between users, a message broker module 124 configured to manage transport of messages, permissions and properties between users (e.g. deny, forward, self-destruct, pin-code required, etc.) and a Data Loss Prevention (DLP) configuration module 126 comprising configurable lists of words that invoke suggestions to use an encryption option. For example if a user types a message containing the phrase "credit card", the app can suggest to encrypt the message. DLP 126's lists may be updated per user, or per group of users.
  • System server 110 further comprises at least one database 130 for storing messages, public keys, and user IDs.
  • Each user device 140 and 150 comprises a transport application, 142 and 152 respectively and a secure messaging application, 144 and 154 respectively, which is associated with the present invention.
  • Secure Messaging Application (SMA) 144 and 154 is a software application that, when installed in advance on a device and activated during the operation of another (non-secure) messaging software application (e.g. WhatsApp), blocks the transport application from accessing the message text, while generating another message to be sent using the transport application indicating that a secure message has been created.
  • another messaging software application e.g. WhatsApp
  • Fig. 2 shows a detailed system diagram of secure messaging system server 110 according to an embodiment of the present invention.
  • a front end module 200 communicates bi- directionally over the Internet with the user device's SMA 210. Messages arriving from the user device's SMA are directed to an in-queue (MQ IN 220). Messages arriving for the user device's secure messaging app are directed to an out-queue (MQ OUT 230).
  • a push messaging manager 240 is provided, configured to push notifications from the out-queue to CLIENTS 210, e.g. in case of asynchronous communication, or in case the client is not connected with the backend when the message is sent.
  • Keys exchange module 122 manages the secure key exchange in the different flows.
  • Message broker 124 stores the encrypted messages, and serves them from database 130, and follows the business rules defined by the users (revoking a message, time limited messages, etc.).
  • DLP configuration module 250 stores and serves the keyword lists.
  • the secure messaging application prepares the message to comprise the following components:
  • a message is prepared and ready, it is shared with potential recipients by sending a message invitation via a messaging host software application (e.g. WhatsApp, Messenger, Hangout, Twitter etc.).
  • a messaging host software application e.g. WhatsApp, Messenger, Hangout, Twitter etc.
  • the messaging system determines if the request can be fulfilled or not by examining the message meta-data and optionally performing actions implied from the metadata before the final approval or denial is established. If the result of the examination is an approval, the message data is sent to the recipient.
  • Fig. 3 shows a flowchart 300 describing a process of securely sending a message from a sender to a recipient, according to an embodiment of the present invention.
  • the sender composes a new secure message on the sender's device.
  • the message may be composed using the secure messaging application (SMA) or using a host software application (e.g. WhatsApp). In the latter case the message is replaced with a link by the SMA.
  • SMA secure messaging application
  • a host software application e.g. WhatsApp
  • the recipient taps a link that appears in the invitation message and the recipient's device captures the tap and identifies the link as belonging to the secure messaging system.
  • the capturing and identification is performed, for instance, according to the above mentioned methods, depending on the device and operating system used by the recipient.
  • the SMA on the recipient's device receives the message metadata (e.g. ID) and takes responsibility for handling the message.
  • the secure messaging application on the recipient's device communicates with the secure messaging server requesting access for the recipient to the message. Alongside this request, the recipient's device-data is collected and sent to the secure messaging server.
  • the secure messaging server makes a decision as to whether or not to grant access to the recipient.
  • the decision is meta-data driven, i.e. according to rules that are executed by the secure messaging server.
  • the recipient's device data is used as input for these rules.
  • one of the meta-data rules includes the secure messaging server asking the sender for approval before granting the recipient access. If the decision is a denial, then in step 308 the recipient denied access to the message and is notified of the denial. If the decision is an approval, then in step 309 the secure messaging server asks the sender to send the actual message data to the recipient. In the next step 310, the recipient receives the message data and may view it inside the secure messaging app.
  • the meta-data of a secure message defines the message's behavior in several aspects. Below is a list of exemplary aspects, which is brought for sake of demonstration. The present invention, however, is not limited to the below list of aspects and may comprise any other aspect that is apparent to the skilled person.
  • the meta-data may control when a message will expire (i.e. when the message will not be accessible anymore). This can be represented as:
  • a period of absolute time (1 day, 1 week, 1 month);
  • a period of elapsed time (can view for 30 seconds);
  • Geolocation Determining a geographical area in which a message may be viewed from. Any requests originating from outside the designated area will be immediately declined.
  • the data of a user's device is collected by the secure messaging application from the device on which it is installed.
  • the data items can be, but are not limited to: • Device oriented items, e.g. OS version, whether it is rooted, jailbroken or hacked;
  • Operational metrics for instance whether a screenshot was made, or the period of time during which a message was viewed.
  • a device is labeled as a high-risk device when it is more vulnerable to malicious attacks.
  • rooted Android devices and jailbroken iOS devices significantly increase the device vulnerability to malware.
  • Another example is the presence of unknown key-loggers, that can dramatically increase the risk mark of the device.
  • the device-data is used for breach control, i.e. to alert a sender about suspicious activity related to a secure message.
  • exemplary alerts may include, for instance:
  • a message was accessed outside a predefined geo area
  • a message was left open for a long period of time on a device
  • a sender may choose to revoke a message as a reaction to an alert, or the SMA may revoke the message automatically. Because messages are not stored locally on the recipient SMA device and are presented only through the SMA - revoking a message includes changing the meta-data of the message on the server to revoke future access to the message, instructing the SMA to revoke current access of the message by means of push or by SMA poll to check access rights. When the SMA will not have access to the server a default operation is applied, e.g. denying access to the message until connectivity is restored.
  • each secure message can contain one or more messages.
  • the first secure message is called the "root message".
  • each secure message is an entry gate to a secure channel, that once established may contain one or more messages.
  • the meta-data of the root message controls the entire secure channel behavior, as explained above in conjunction with the meta-data of a general secure message. For example, if a root message is revoked then the whole secure channel created by it is also revoked.
  • Messages in the secure channel are End-to-End encrypted same as the root message. All secure channel messages are created and maintained as the root message. The differences are: 1. They are created in the SMA Ul app (under the root message), hence no invitation link is sent. 2. They are attached to the root message Ul wise and meta-data wise (inherit its access permissions).
  • a secure message is not transferred as plain text or an image. Instead a link is communicated, that when clicked by a user may grant the user the ability to enter a corresponding secured channel and participate actively in a discussion/conversation/chat.
  • Secure messages sent using the secure messaging system are encrypted end-to-end, i.e. only the participating parties are able to access and read messages sent from one to the other. Messages are not stored on a middle server in a way that it can be read by an unwanted third party.
  • Fig. 4A shows a flowchart 400a of a bootstrapping process in which a user enlists to a secure messaging system (e.g. system 100 of Fig. 1), according to an embodiment of the invention.
  • a secure messaging software application is downloaded to and installed on a messaging device, which may be any electronic device with which a user may send a digital message to a message recipient.
  • an identity key pair i.e. including a private key and a public key
  • the public key of the identity key pair represents the identity of the user.
  • the public key is an elliptic curve Diffie-Hellman key
  • the identity key pair is a long-term Curve25519 key.
  • the private key is stored on the messaging device, whereas the public key is sent to a remote server that is part of the secure messaging system and stored thereon alongside an identifier of the user.
  • the user is prompted to choose a PIN code that will be used to encrypt all of the private and symmetric keys associated with the user.
  • a salted hash of the PIN is stored on the user's messaging device.
  • the PIN is hashed using Bcrypt with sufficient difficulty.
  • Fig. 4B shows a flowchart describing a process 400b of securely sending a message by a sender enlisted (e.g. according to process 400a of Fig. 4A) to a secure messaging system (e.g. system 100 of Fig. 1), according to an embodiment of the present invention.
  • a sender enlisted e.g. according to process 400a of Fig. 4A
  • a secure messaging system e.g. system 100 of Fig. 1
  • user verification is required, and a key is exchanged per message or per sessions.
  • the sender activates a host software messaging application (e.g. WhatsApp), and activates the secure messaging application (SMA).
  • a host software messaging application e.g. WhatsApp
  • SMA secure messaging application
  • the sender types a message on the secure messaging app or in the host software application.
  • the message is stored locally on the sender's device and a message ID is derived and sent to the secure messaging server.
  • the sender's secure messaging app generates a deep-link and sends it to a transport medium server (e.g. 160 of Fig. 1), along with the message ID.
  • a recipient of the message receives the deep-link through the transport medium and taps the deep-link.
  • the recipient's secure messaging app sends an authorization request to the secure messaging server, along with the message ID, so as to authorize (or deny) the recipient as the intended addressee of the message.
  • the secure messaging server forwards the authorization request to the sender along with the message ID.
  • the sender sends an authorization to the secure messaging server and in step 414 the secure messaging app of the sender and the recipient exchange public keys for the session.
  • the sender's secure messaging app encrypts the message and sends the encrypted message to the secure messaging server, along with the message ID.
  • the message is encrypted by a key derivation function.
  • the secure messaging server forwards the encrypted message to the recipient's secure messaging app with a push, after which, in final step 417, the recipient's secure messaging app decrypts the message and the recipient may now read the message.
  • process 400b may be applied to other data sent from a sender to a recipient.
  • a photograph meant to be sent to the recipient is chosen (or captured) in step 407.
  • the data (photograph) is encrypted in step 415 by the sender's secure messaging app, and decrypted in step 417 by the recipient's secure messaging app.
  • Fig. 5 shows a flowchart 500 describing a process of responding to a message, according to an embodiment of the present invention.
  • the recipient and the sender of a process of responding to a message are referred to as the responder and the initiator, respectively.
  • the responder types a response message on the recipient's secure messaging, after which in step 502 the response message is stored locally on the responder's device and a message ID is derived and sent to the messaging system server.
  • the responder's secure messaging app In the next step, 503, the responder's secure messaging app generates a deep-link and sends it to the transport medium server, along with the message ID, after which in step 504 the initiator receives the deep-link through the transport medium and taps the deep-link.
  • the initiator's secure messaging app requests the message from the secure messaging server according to the message ID, and the server forwards the request to the responder's secure messaging app with a silent-push.
  • the responder's secure messaging app encrypts the response message and sends the encrypted response message to the secure messaging server, along with the message ID.
  • the response message is encrypted by a key derivation function.
  • the server forwards the encrypted response message to the initiator's secure messaging app after which, in step 508, the initiator's secure messaging app decrypts the response message and the initiator may now read the response message.
  • Fig. 6 shows a flowchart 600 describing a process of securely sending a message by a sender enlisted (e.g. according to process 400a of Fig. 4A) to a secure messaging system (e.g. system 100 of Fig. 1) where a key is exchanged per session (i.e., there is no need to approve each message by the sender), according to another embodiment of the present invention.
  • the purpose of this flowchart 600 is to depict user authorization per sessions.
  • the sender activates a software messaging application (e.g. WhatsApp), and activates the secure messaging application (app), after which, in step 602 the sender types a message on the secure messaging app.
  • a software messaging application e.g. WhatsApp
  • the secure messaging app encrypts the message and generates a message ID, and sends the encrypted message along with the message ID to a secure messaging server.
  • the sender's secure messaging app generates a deep-link and sends it to the transport medium server along with the message ID, after which, in step 605, a recipient of the message receives the deep-link through from transport medium server and taps the deep-link.
  • the recipient's secure messaging app sends an authorization request to the secure messaging server, along with the message ID, so as to allow the sender to authorize the recipient as the intended addressee of the message, after which, in step 607 the secure messaging server forwards the authorization request to the sender along with the message ID.
  • the recipient next read approval requests will be approved by the server without the sender action (step 609).
  • the encryption occurs on the sender's side SMA - since it is an End-to-End (E2E) encryption (step 610).
  • the server here will silent push the sender's SMA in order to encrypt the massage and send it to the recipient (step 611).
  • the recipient's secure messaging app decrypts the message and the recipient may now read the message.
  • Fig. 7 shows a flowchart describing a process 700 of an E2E encryption, according to yet another embodiment of the present invention.
  • Process 800 refers to securely sending a message by a sender enlisted (e.g. according to process 400a of Fig. 4A) to a secure messaging system (e.g. system 100 of Fig. 1).
  • the sender activates a software messaging application (e.g. WhatsApp), and activates the secure messaging application (app), after which, in step 702 the sender types a message on the secure messaging app.
  • the secure messaging app generates an ID for the message, and sends ID to the secure messaging server.
  • a software messaging application e.g. WhatsApp
  • the sender's secure messaging app creates a deep-link that is sent to the transport medium server along with the message ID.
  • the recipient receives the deep-link through the transport medium server and taps the deep-link, after which, in step 706 the recipient's secure messaging app sends an authorization request to the secure messaging server, along with the message ID, so as to allow the sender to authorize (or deny) the recipient as the intended addressee of the message.
  • the secure messaging server forwards the authorization request to the sender along with the message ID, after which, in step 708 (assuming the sender authorizes the recipient), the sender's secure messaging app sends the authorization to the recipient's secure messaging app.
  • the recipient's secure messaging application sends the authorization to the secure messaging server, and a double-ratchet session is established between the sender and the recipient for the deep-link generated (step 710).
  • Messages will be exchanged between the parties inside the SMA app with no need to send further deep links through the transport medium (the secure channel) - each message here will derive its metadata and permission from the root message.
  • Fig. 8 (A-F) illustrates screen displays of a sender and a recipient when a message is sent by the sender using the secure messaging method and system, according to an embodiment of the present invention.
  • the present invention is not limited to the specific messaging software application presented in Fig. 9 (A-F), nor is the invention limited to any other aspect presented in Fig. 9 (A-F) such as the visual or textual features of the secure messaging application.
  • Fig. 9(A) shows a screen display 901 of a sender's messaging software application, after the recipient ("Alice Wonder") has been designated (902), the message "Hello” has been typed (903), and the secure messaging app has been activated (904).
  • the secure messaging application is activated by tapping the "s" key three consecutive times (as implied in Fig. 9 by the auto-completion suggestion 905).
  • Fig. 9(B) shows the screen display 901 of the sender after the message 903 has been swapped with a secure message notification 906.
  • Fig. 9C shows the screen display 901 of the sender after notification 906 has been sent to Alice Wonder.
  • FIGD shows the screen display 907 of the recipient (Alice Wonder) after tapping the notification message 906, wherein an authorization request layer 908 is presented, implying that the message 903 may be accessed only after the sender ("Bob") approves the access request.
  • Fig. 9E shows the screen display 901 of the sender, in which an authorization approval layer 909 is presented, allowing the sender to approve or decline access of the recipient to the message 903.
  • Fig. 9F shows the screen display 901 of the sender after a secure channel has been established between the sender and the recipient. Furthermore, Fig. 9F shows an icon 909 that when tapped grants the sender access to all messages sent from any host software application.
  • Fig. 9F shows another icon 911 that when tapped allows to destroy/revoke a specific message from all recipients of the message, including messages that are attached to the root message/channel.
  • the secure messaging system of the present invention provides several benefits over the prior art systems.
  • the benefits include, among others, the ability to create secure messages from any messaging software application (host-app) and invite new participants to view messages over other host-apps. For example a sender can create a secure message invitation in a first host-app (e.g.
  • WhatsApp send the invitation to a first recipient, and then invite a second recipient over a second host-app (e.g. email) to join the same secure channel.
  • a second host-app e.g. email
  • the second recipient follows the link in the second host-app (e.g. email) the second recipient joins the same secure channel that the sender and first recipient are sharing, that was originally initiated over the first host-app (WhatsApp).
  • a message doesn't comprise the contents of the message itself (e.g. text or an image), but it comprises a link to the contents, thereby granting an extra level of indirection.
  • each new viewer can be approved before viewing message data.
  • a message may be revoked thereby permanently erasing any copy of the message data, whether existing on the sender's device or on an approved viewer's device. From this point on, any further requests from anyone to read the revoked message, whether from previously approved viewers or from other viewers, are denied by the secure messaging server.
  • Alerts may be defined to trigger a sender's device when certain conditions are met in a secure message shared by the sender, as discussed below.
  • the secure messaging server protects senders from such actions using image traceability, in which a securely sent image is marked with a hidden mark, identifying the intended viewer (i.e. the recipient).
  • the hidden mark can be the recipient's number or any other unique identifying data, and is implemented using steganography.
  • the hidden mark's properties may be, but are not limited to:
  • a user may import data (e.g. images) to the secure messaging system, thereby preventing direct access to the data whereas access is granted only through the secure messaging app.
  • data e.g. images
  • This embodiment helps protecting users from unwanted peeking in case a device is stolen or lost.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

The present invention relates to a method for controlling access to a message, characterize in that an exchange of encryption keys is initiated by a recipient upon receipt of a recipient's request by a sender, wherein said message may comprise one or more attached documents.

Description

CONTROLLING ACCESS TO ELECTRONIC MESSAGES AND SHARED DATA Field of the Invention
The present invention relates to the field of data privacy. More particularly, the invention relates to a method and system for controlling data after being shared with another party.
Background of the Invention
In the present era, a vast amount of a person's private information can be found online. Private information includes, for instance, financial information (e.g. bank account details, credit card numbers and tax statements), intimate information (e.g. private conversations and photographs), work documents (e.g. scanned documents and confidential files) and passwords (e.g. clear text passwords, Social Security numbers and ID). Any piece of such information is required to be kept secure and highly protected from being accessed by unwanted parties.
Several systems exist nowadays allowing to keep one's information protected when shared with other parties, however most of these systems depend on protection mechanisms applied on the other parties' sides, e.g. via private social networks (e.g. WhatsApp, Email, Dropbox, Twitter, Linkedln and Facebook). In these systems when private data leaves a user's possession (e.g. the user's digital device or online account) and is shared with another party, the user no longer possesses control over the data (e.g. further distribution of the data).
An exemplary common practice algorithm in digital communication security is the Double Ratchet algorithm that manages renewal and maintenance of short-lived cryptographic keys after an initial key exchange in instant messaging. This algorithm provides authentication, encryption, deniability and forward and future secrecy.
The Double Ratchet algorithm, however, may not be sufficient in all cases. For instance, in case the identity of the recipient of a message is unknown, or in case the recipient of the message doesn't have the messaging application through which the message was sent by the sender, the Double Ratchet algorithm will be insufficient. Another solution is PGP-style protection, in which each user has a pair of private and public keys, and each message is encrypted by the sender with the recipient's public key (previously obtained by the sender) and signed with the sender's private key. This solution is not always sufficient because it doesn't provide forward secrecy, i.e. if at any time one's private key is compromised then any future or past message received thereby may be compromised. Furthermore the PGP-style solution doesn't provide deniability / privacy, i.e. any third party is able to verify the signature of the sender. Consequently, after a message has been sent, the sender cannot hide the fact that the message was sent by him.
Another solution is a single-ratchet protocol, Silent Circle Instant Messaging Protocol (SCIMP). Beginning with a common secret, each time a user sends a message, the user's key is hashed to generate the key for the next message and delete the old key from the memory. The drawback of this solution is that if a key is compromised at any point, the future messages are affected.
Another method of protecting messages is by use of secure messaging. These use a single AES sender key that is published thereby on a separate channel (e.g. in person, mail or private message). In this method, however, any party holding the AES key is able to read any past or future messages sent by the sender.
Unfortunately the above mentioned methods require previous exchanging of cryptographic keys between senders and recipients, and information regarding the identity of the recipients.
There is need for a method and system to secure electronic messages and shared data that overcomes the deficiencies of the above prior art. It is therefore an object of the present invention to provide a method and system for controlling data after being shared with another party.
It is yet another object of the present invention to provide a method and system for securing and controlling data after being shared with another party wherein no information regarding the other party is available prior to a request of the other party to access the data. Other objects and advantages of the invention will become apparent as the description proceeds.
Summary of the Invention
The present invention relates to a method for controlling access to a message, characterize in that an exchange of encryption keys is initiated by a recipient upon receipt of a recipient's request by a sender, wherein said message may comprise one or more attached documents.
According to an embodiment of the invention, the method further comprises:
a) generating, by a dedicated Secure Messaging software Application (SMA) on a sender's device (the sender's SMA), a message ID, a message hyperlink and message metadata comprising one or more rules according to which recipients are granted or denied access to the message;
b) sending to a remote server, by the sender's SMA, the message ID and metadata;
c) sending to a recipient's device, by a messaging host software application on the sender's device, an invitation to access the data, the invitation comprising the message hyperlink; d) upon activating the message hyperlink, receiving control and the message ID, by a SMA on a recipient's device (the recipient's SMA), wherein the recipient's SMA collecting data associated with the recipient's device;
e) sending a request, by the recipient's SMA, to the remote server to receive access to the message, wherein the request comprising the recipient's device associated data and the message ID; and
f) deciding, by the remote server, whether or not to grant access to the recipient according to the message metadata.
According to an embodiment of the invention, the remote server will notify the sender (e.g., via device OS/SMA) that the recipient would like to have access to the message (this after authenticating and verifying the recipient). Upon sender approval, the remote server will grant the permission to the recipient. If the sender has granted an access before, there is a configurable option that the remote server will automatically grant access for the next messages (e.g., either limited by time or number of messages).
According to an embodiment of the invention, the SMA communicates with the messaging host software application via at least one data input means associated with said host software application, by capturing data provided via said at least one data input means, wherein in particular the data input means is a virtual keyboard or a microphone of the sender/recipient device or any other data input means suitable for capturing data.
According to an embodiment of the invention, the data input is performed by: a) text input capturing; b) accessibility API; c) OS API hooking; d) functioning as a keyboard where all text goes through; e) sharing to another app; and/or f) using browser extension to hook all activities.
According to an embodiment of the invention, the message comprises one or more of the following: text, an image, a document, an audio clip, or other data.
According to an embodiment of the invention, the access grant decision of the server is further based recipient's device associated data.
According to an embodiment of the invention, one of the message metadata rules comprises enabling the sender to approve or deny a recipient access.
According to an embodiment of the invention, the method further comprising allowing the sender to revoke the message after the message has been received by the recipient.
According to an embodiment of the invention, the message metadata comprises rules defining behavior of the message.
According to an embodiment of the invention, the behavior of the message includes one or more of the following aspects:
expiry of the message, i.e. time or action dependent;
sender approval requirements of the message;
re-authentication limitation;
screenshot limitations;
geolocation viewing limitations; and/or
reader safety limitations. According to an embodiment of the invention, the recipient's device associated data may comprise: device oriented items, physical meters such as date, time and geolocation, and/or operational metrics.
In another aspect, the present invention relates to a method for creating a secure messaging channel between a sender and a recipient, comprising:
a) sending a root message from the sender to the recipient according to the method for controlling access to a message as described hereinabove;
b) establishing a secure channel between the sender and the recipient; and
c) sending other messages between the recipient and the sender through the secure channel.
According to an embodiment of the invention, the metadata of the root message defines the behavior of the entire secure channel.
According to an embodiment of the invention, revocation of a root message causes revocation of other messages sent through the secure channel.
In another aspect, the present invention relates to a system for controlling access to a message comprising a first apparatus for delivering an encryption key request from a sender to a recipient, and a second apparatus for sending said request to said sender by said recipient upon receipt of a request, wherein said message may comprise one or more attached documents.
According to an embodiment of the invention, the system further comprising:
a) a secure messaging server, comprising a key exchange module configured to manage exchange of encryption keys between users; a message broker module configured to manage transport of messages, permissions and properties between users; a Data Loss Prevention (DLP) configuration module comprising configurable lists of words that invoke suggestions to use an encryption option; a database for storing messages, keys and user IDs; and
b) one or more transport medium servers. According to an embodiment of the invention, the first and second apparatuses are user electronic communication devices capable of communicating over the internet with the secure messaging server and with the one or more transport medium servers, wherein each device comprising a transport application; and a secure messaging application (SMA) configured to block the transport application from accessing contents of a message, while generating another message to be sent using the transport application indicating that a secure message has been created.
According to an embodiment of the invention, the secure messaging server further comprises: a) a front end module communicating bi-directionally over the Internet with the user device's SMA; b) an in-queue module configured to receive incoming messages from user devices' SMAs; c) an out-queue module configured to receive outgoing messages for user devices' SMAs; and d) a push messaging manager configured to push notifications from the out-queue to SMAs of user devices.
Brief Description of the Drawings
In the drawings:
Fig. 1 shows a system diagram of a system for securely transferring messages and shared data, according to an embodiment of the present invention;
Fig. 2 shows a system diagram of a secure messaging system server according to an embodiment of the present invention;
Fig. 3 shows a flowchart describing a process of securely sending a message from a sender to a recipient, according to an embodiment of the present invention;
Fig. 4A shows a flowchart of a bootstrapping process in which a user enlists to a secure messaging system, according to an embodiment of the invention;
Fig. 4B shows a flowchart describing a process of securely sending a message, according to an embodiment of the present invention;
Fig. 5 shows a flowchart describing a process of responding to a message, according to an embodiment of the present invention;
Fig. 6 shows a flowchart describing a process of securely sending a message, according to another embodiment of the present invention;
Fig. 7 shows a flowchart describing a process of securely sending a message, according to yet another embodiment of the present invention; and Fig. 8 (A-F) illustrates screen displays of a sender and a recipient when a message is sent by the sender, according to an embodiment of the present invention.
Detailed Description of the Invention
Reference will now be made to an embodiment of the present invention, examples of which are illustrated in the accompanying figures for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed, mutatis mutandis, without departing from the principles of the claimed invention.
Throughout this description the term "message" is used to indicate an electronic form of exchanging digital content from a sender to one or more recipients. This term does not imply any particular messaging method, and the invention is applicable to all suitable methods of exchanging digital messages such as email, SMS, Instant Messaging (IM), Social Media Websites and the like.
The secure messaging method of the present invention allows controlling data after being shared with another party, regardless of the communication application being used. The method comprises utilizing a secure messaging software application installed on a digital communication device of a user, the software application allowing the user to secure any online communication channel, regardless of whether the channel is secure, unsecure, public or private. The software application (hereinafter the app) is agnostic to specifically used messaging applications, i.e. users are able to continue using the messaging application of their choice while the app sees to securing the communication channel. Furthermore, the app provides presentation level security as an additional security level over other existing security levels (e.g. device-to-device).
The app provides a message sender control over information sent thereby even on devices of other parties. The control is applied as retrieving, deleting, forward locking and auto- destructing messages. Furthermore the app provides context activated encryption by automatically identifying sensitive information and prompting users to send such information via a secured keyboard, as part of the system of the present invention. More specifically, on the sender side the app enables entered text to be captured and replaced with a secured message link. On the recipient side the app enables to capture a click on a link within a secured message and pass the handling to the app (access granting and decryption). The means for capturing text and clicks may vary. For example the following methods may be used: text input capturing (Application Programming Interface (API) hooking for instance on Windows), accessibility API (applicable on Android and Windows Operating Systems (OSs)), functioning as a keyboard where all text goes through (applicable on iOS, Android and Windows OSs), OS IPC options - sharing to other app (applicable on Android and iOS OSs), and using browser extension to hook all activities (applicable on Windows, OSX and Linux OSs).
One of the goals of the secure messaging app is to make digital security and privacy more accessible for users. The following are examples in which users require a high level of security and protection of the data that they share with another user.
As a first example, a user may wish to send a credit card PIN code to the user's spouse. In this case it is essential to protect the PIN code even in case the spouse's device is stolen.
As a second example, a patient may send a photograph of the patient's private parts to a doctor in order to receive an opinion. The patient would likely allow only one single view of the photo (for the doctor to see in order to diagnose), and wouldn't like it to appear in the doctor's message thread for bystanders to see. Furthermore the patient would like to make sure that only the doctor views the photograph by requiring the entry of the doctor's code. Moreover the patient would like to prevent the doctor from downloading the photograph to a digital device or from capturing the screen without authorization from the patient. In addition, the patient is capable of deleting the photograph from afar or automatically, for instance an hour after it is sent.
As a third example, a user sends a private message to a group of friends. Because the message is private, the user wishes the message not to appear on the friends' message threads, or for their spouses to be able to read the message. The user wishes to be able to know exactly who views the message and to control who is permitted to view it, and to delete the message from afar (or automatically). As a fourth example, a recruiter reaches out to a potential candidate who is currently unemployed. The recruiter sends the candidate a direct message via, for instance, Linkedln, but doesn't want to make the candidate feel uncomfortable in case someone at his workplace gets a peek at his digital device. The sender wants the ability to encrypt the subject line of a message as well as the content of the message. The sender wants to allow only the candidate to be able to read the message.
As a fifth and final example, an insurance agent receives a copy of a client's passport in order to prepare travel insurance for the client for departure taking place in another 6 hours. The client shared the document with the agent. Two hours afterwards the agent forwards the document to the insurance company in order to finalize the policy.
It is noted that the above examples were brought merely for the sake of demonstrating the necessity of the present solution. The present invention however is not limited by the above examples in any way to specific uses, scenarios, cases, solutions or any other aspect of the invention that may implied therefrom.
Fig. 1 shows a system diagram of a system 100 for controlling messages and shared data, according to an embodiment of the present invention. System 100 comprises a secure messaging system server 110, one or more transport medium servers 160, and a plurality of user electronic communication devices (e.g. 140 and 150). Each of devices 140 and 150 can be a smartphone, a wearable computer, a PDA, a tablet computer, a laptop computer, a personal computer, or any other electronic device capable of communicating over the internet with system server 110 and with the one or more transport medium servers 160. According to an embodiment of the present invention, transport medium servers 160 may include a messaging application server (e.g. WhatsApp, Google Hangouts), an email server (e.g. Gmail or Yahoo), a social network server (e.g. Twitter, Instagram, Facebook) or any other server through which digital data is transferred between users.
System server 110 comprises backend software components 120, including a key exchanging module 122 configured to manage exchange of encryption keys between users, a message broker module 124 configured to manage transport of messages, permissions and properties between users (e.g. deny, forward, self-destruct, pin-code required, etc.) and a Data Loss Prevention (DLP) configuration module 126 comprising configurable lists of words that invoke suggestions to use an encryption option. For example if a user types a message containing the phrase "credit card", the app can suggest to encrypt the message. DLP 126's lists may be updated per user, or per group of users. System server 110 further comprises at least one database 130 for storing messages, public keys, and user IDs.
Each user device 140 and 150 comprises a transport application, 142 and 152 respectively and a secure messaging application, 144 and 154 respectively, which is associated with the present invention. Secure Messaging Application (SMA) 144 and 154 is a software application that, when installed in advance on a device and activated during the operation of another (non-secure) messaging software application (e.g. WhatsApp), blocks the transport application from accessing the message text, while generating another message to be sent using the transport application indicating that a secure message has been created.
Fig. 2 shows a detailed system diagram of secure messaging system server 110 according to an embodiment of the present invention. A front end module 200 communicates bi- directionally over the Internet with the user device's SMA 210. Messages arriving from the user device's SMA are directed to an in-queue (MQ IN 220). Messages arriving for the user device's secure messaging app are directed to an out-queue (MQ OUT 230). A push messaging manager 240 is provided, configured to push notifications from the out-queue to CLIENTS 210, e.g. in case of asynchronous communication, or in case the client is not connected with the backend when the message is sent. Keys exchange module 122 manages the secure key exchange in the different flows. Message broker 124 stores the encrypted messages, and serves them from database 130, and follows the business rules defined by the users (revoking a message, time limited messages, etc.). DLP configuration module 250 stores and serves the keyword lists.
When a sender prepares a message to be securely sent using the secure messaging system and method according to the present invention, the secure messaging application prepares the message to comprise the following components:
a. message ID - a globally unique identifier of the message;
b. data - the original contents of the message that the sender wishes to send, optionally comprising text, images, documents, audio clips or other data; and c. meta-data - several attributes describing the desired behavior of the message. Once a message is prepared and ready, it is shared with potential recipients by sending a message invitation via a messaging host software application (e.g. WhatsApp, Messenger, Hangout, Twitter etc.). When a recipient receives the invitation and requests to access the message contents, the messaging system determines if the request can be fulfilled or not by examining the message meta-data and optionally performing actions implied from the metadata before the final approval or denial is established. If the result of the examination is an approval, the message data is sent to the recipient.
Fig. 3 shows a flowchart 300 describing a process of securely sending a message from a sender to a recipient, according to an embodiment of the present invention. In the first step 301, the sender composes a new secure message on the sender's device. The message may be composed using the secure messaging application (SMA) or using a host software application (e.g. WhatsApp). In the latter case the message is replaced with a link by the SMA. In the next step 302, an invitation message is sent from the sender to the recipient using a messaging host software application, after which in step 303 the recipient receives the invitation message in the recipient's messaging host software application. In the next step 304, the recipient taps a link that appears in the invitation message and the recipient's device captures the tap and identifies the link as belonging to the secure messaging system. The capturing and identification is performed, for instance, according to the above mentioned methods, depending on the device and operating system used by the recipient. In the next step 305, the SMA on the recipient's device receives the message metadata (e.g. ID) and takes responsibility for handling the message. In the next step 306, the secure messaging application on the recipient's device communicates with the secure messaging server requesting access for the recipient to the message. Alongside this request, the recipient's device-data is collected and sent to the secure messaging server. In the next step 307, the secure messaging server makes a decision as to whether or not to grant access to the recipient. The decision is meta-data driven, i.e. according to rules that are executed by the secure messaging server. According to an embodiment of the invention, the recipient's device data is used as input for these rules. According to another embodiment of the invention, one of the meta-data rules includes the secure messaging server asking the sender for approval before granting the recipient access. If the decision is a denial, then in step 308 the recipient denied access to the message and is notified of the denial. If the decision is an approval, then in step 309 the secure messaging server asks the sender to send the actual message data to the recipient. In the next step 310, the recipient receives the message data and may view it inside the secure messaging app.
The meta-data of a secure message defines the message's behavior in several aspects. Below is a list of exemplary aspects, which is brought for sake of demonstration. The present invention, however, is not limited to the below list of aspects and may comprise any other aspect that is apparent to the skilled person.
• Expiry - The meta-data may control when a message will expire (i.e. when the message will not be accessible anymore). This can be represented as:
A period of absolute time (1 day, 1 week, 1 month);
A period of elapsed time (can view for 30 seconds); and/or
A function of some activity (Bob can view the message one time only. This means closing the message data view, immediately expires the message).
• Approval - Determining when the sender would be asked to approve a recipient.
Optional values of this attribute are:
Always - sender is required to approve each recipient trying to view a message; Once - the sender is required to approve each new recipient, although any recipient once approved, may view a message unlimitedly; and/or
Never - no approval is required.
• Re-authentication - Requiring (or not) a recipient to set up a PIN code (and use it) before being granted access to a message.
• Screenshots - Allowing (or preventing) a recipient to capture a screenshot of the message or data.
• Geolocation - Determining a geographical area in which a message may be viewed from. Any requests originating from outside the designated area will be immediately declined.
• Reader Safety - Read requests originating from what the secure messaging system considers an unsafe device (as is defined hereinafter), are denied.
• Forwarding restrictions - denying the forwarding of a message to another recipient (once the intended recipient was approved we can deny all other request to read the message automatically from the server.
The data of a user's device is collected by the secure messaging application from the device on which it is installed. The data items can be, but are not limited to: • Device oriented items, e.g. OS version, whether it is rooted, jailbroken or hacked;
• Physical meters, e.g. date, time and geolocation; and/or
• Operational metrics, for instance whether a screenshot was made, or the period of time during which a message was viewed.
According to an embodiment of the present invention, a device is labeled as a high-risk device when it is more vulnerable to malicious attacks. For example rooted Android devices and jailbroken iOS devices significantly increase the device vulnerability to malware. Another example is the presence of unknown key-loggers, that can dramatically increase the risk mark of the device.
The device-data is used for breach control, i.e. to alert a sender about suspicious activity related to a secure message. Exemplary alerts may include, for instance:
A message was accessed outside a predefined geo area;
A message was accessed in abnormal hours;
A message was accessed many times by the same viewer;
A message was left open for a long period of time on a device;
A message was screenshot;
A message was forward to many others in a short period of time; or
A message was rightfully viewed but on a high risky device.
According to an embodiment of the present invention, a sender may choose to revoke a message as a reaction to an alert, or the SMA may revoke the message automatically. Because messages are not stored locally on the recipient SMA device and are presented only through the SMA - revoking a message includes changing the meta-data of the message on the server to revoke future access to the message, instructing the SMA to revoke current access of the message by means of push or by SMA poll to check access rights. When the SMA will not have access to the server a default operation is applied, e.g. denying access to the message until connectivity is restored.
According to an embodiment of the present invention, each secure message can contain one or more messages. The first secure message is called the "root message". Once a sender sends a secure message to a recipient, and the recipient is approved to access it, the sender and recipient may continue their discussion, exclusively using the secure messaging app. In another aspect, each secure message is an entry gate to a secure channel, that once established may contain one or more messages. The meta-data of the root message controls the entire secure channel behavior, as explained above in conjunction with the meta-data of a general secure message. For example, if a root message is revoked then the whole secure channel created by it is also revoked.
Messages in the secure channel are End-to-End encrypted same as the root message. All secure channel messages are created and maintained as the root message. The differences are: 1. They are created in the SMA Ul app (under the root message), hence no invitation link is sent. 2. They are attached to the root message Ul wise and meta-data wise (inherit its access permissions).
Generally, a secure message is not transferred as plain text or an image. Instead a link is communicated, that when clicked by a user may grant the user the ability to enter a corresponding secured channel and participate actively in a discussion/conversation/chat. Secure messages sent using the secure messaging system are encrypted end-to-end, i.e. only the participating parties are able to access and read messages sent from one to the other. Messages are not stored on a middle server in a way that it can be read by an unwanted third party.
Fig. 4A shows a flowchart 400a of a bootstrapping process in which a user enlists to a secure messaging system (e.g. system 100 of Fig. 1), according to an embodiment of the invention. In the first step, 401, a secure messaging software application is downloaded to and installed on a messaging device, which may be any electronic device with which a user may send a digital message to a message recipient. In the next step, 402, an identity key pair (i.e. including a private key and a public key) is generated, wherein the public key of the identity key pair represents the identity of the user. According to an embodiment of the present invention, the public key is an elliptic curve Diffie-Hellman key, and the identity key pair is a long-term Curve25519 key. In the next step, 403, the private key is stored on the messaging device, whereas the public key is sent to a remote server that is part of the secure messaging system and stored thereon alongside an identifier of the user. In the next step, 404, the user is prompted to choose a PIN code that will be used to encrypt all of the private and symmetric keys associated with the user. In the next step, 405, a salted hash of the PIN is stored on the user's messaging device. According to an embodiment of the present invention, the PIN is hashed using Bcrypt with sufficient difficulty.
Fig. 4B shows a flowchart describing a process 400b of securely sending a message by a sender enlisted (e.g. according to process 400a of Fig. 4A) to a secure messaging system (e.g. system 100 of Fig. 1), according to an embodiment of the present invention. In this embodiment user verification is required, and a key is exchanged per message or per sessions.
In the first step, 406, the sender activates a host software messaging application (e.g. WhatsApp), and activates the secure messaging application (SMA). In the next step, 407, the sender types a message on the secure messaging app or in the host software application. In the next step, 408, the message is stored locally on the sender's device and a message ID is derived and sent to the secure messaging server. In the next step, 409, the sender's secure messaging app generates a deep-link and sends it to a transport medium server (e.g. 160 of Fig. 1), along with the message ID. In the next step, 401, a recipient of the message receives the deep-link through the transport medium and taps the deep-link. In the next step, 411, the recipient's secure messaging app sends an authorization request to the secure messaging server, along with the message ID, so as to authorize (or deny) the recipient as the intended addressee of the message. In the next step, 412, the secure messaging server forwards the authorization request to the sender along with the message ID. In the next step, 413, the sender sends an authorization to the secure messaging server and in step 414 the secure messaging app of the sender and the recipient exchange public keys for the session. In the next step, 415, the sender's secure messaging app encrypts the message and sends the encrypted message to the secure messaging server, along with the message ID. According to an embodiment of the invention, the message is encrypted by a key derivation function. In the next step, 416, the secure messaging server forwards the encrypted message to the recipient's secure messaging app with a push, after which, in final step 417, the recipient's secure messaging app decrypts the message and the recipient may now read the message.
According to an embodiment of the present invention, process 400b may be applied to other data sent from a sender to a recipient. For instance, a photograph meant to be sent to the recipient is chosen (or captured) in step 407. Accordingly the data (photograph) is encrypted in step 415 by the sender's secure messaging app, and decrypted in step 417 by the recipient's secure messaging app.
Fig. 5 shows a flowchart 500 describing a process of responding to a message, according to an embodiment of the present invention. Along the description of Fig. 5, the recipient and the sender of a process of responding to a message (e.g., as described hereinabove with respect to process 400b of securely sending a message in Fig. 4B) are referred to as the responder and the initiator, respectively. In the first step, 501, the responder types a response message on the recipient's secure messaging, after which in step 502 the response message is stored locally on the responder's device and a message ID is derived and sent to the messaging system server. In the next step, 503, the responder's secure messaging app generates a deep-link and sends it to the transport medium server, along with the message ID, after which in step 504 the initiator receives the deep-link through the transport medium and taps the deep-link. In the next step, 505, the initiator's secure messaging app requests the message from the secure messaging server according to the message ID, and the server forwards the request to the responder's secure messaging app with a silent-push. In step 506 the responder's secure messaging app encrypts the response message and sends the encrypted response message to the secure messaging server, along with the message ID. According to an embodiment of the invention, the response message is encrypted by a key derivation function. In the next step, 507, the server forwards the encrypted response message to the initiator's secure messaging app after which, in step 508, the initiator's secure messaging app decrypts the response message and the initiator may now read the response message.
Fig. 6 shows a flowchart 600 describing a process of securely sending a message by a sender enlisted (e.g. according to process 400a of Fig. 4A) to a secure messaging system (e.g. system 100 of Fig. 1) where a key is exchanged per session (i.e., there is no need to approve each message by the sender), according to another embodiment of the present invention. The purpose of this flowchart 600 is to depict user authorization per sessions. In the first step, 601, the sender activates a software messaging application (e.g. WhatsApp), and activates the secure messaging application (app), after which, in step 602 the sender types a message on the secure messaging app. In the next step 603, the secure messaging app encrypts the message and generates a message ID, and sends the encrypted message along with the message ID to a secure messaging server. In the next step 604, the sender's secure messaging app generates a deep-link and sends it to the transport medium server along with the message ID, after which, in step 605, a recipient of the message receives the deep-link through from transport medium server and taps the deep-link. In the next step 606, the recipient's secure messaging app sends an authorization request to the secure messaging server, along with the message ID, so as to allow the sender to authorize the recipient as the intended addressee of the message, after which, in step 607 the secure messaging server forwards the authorization request to the sender along with the message ID. In the next step 608, assuming that the sender authorizes the recipient, then for a specific period of time or messages count (i.e., the session), the recipient next read approval requests will be approved by the server without the sender action (step 609). During the session, the encryption occurs on the sender's side SMA - since it is an End-to-End (E2E) encryption (step 610). The server here will silent push the sender's SMA in order to encrypt the massage and send it to the recipient (step 611). In the next step 612, the recipient's secure messaging app decrypts the message and the recipient may now read the message.
Fig. 7 shows a flowchart describing a process 700 of an E2E encryption, according to yet another embodiment of the present invention. Process 800 refers to securely sending a message by a sender enlisted (e.g. according to process 400a of Fig. 4A) to a secure messaging system (e.g. system 100 of Fig. 1). In the first step 701, the sender activates a software messaging application (e.g. WhatsApp), and activates the secure messaging application (app), after which, in step 702 the sender types a message on the secure messaging app. In the next step 703, the secure messaging app generates an ID for the message, and sends ID to the secure messaging server. In the next step 704, the sender's secure messaging app creates a deep-link that is sent to the transport medium server along with the message ID. In step 705 the recipient receives the deep-link through the transport medium server and taps the deep-link, after which, in step 706 the recipient's secure messaging app sends an authorization request to the secure messaging server, along with the message ID, so as to allow the sender to authorize (or deny) the recipient as the intended addressee of the message. In the next step, 707, the secure messaging server forwards the authorization request to the sender along with the message ID, after which, in step 708 (assuming the sender authorizes the recipient), the sender's secure messaging app sends the authorization to the recipient's secure messaging app. In the next step 709, the recipient's secure messaging application sends the authorization to the secure messaging server, and a double-ratchet session is established between the sender and the recipient for the deep-link generated (step 710). Messages will be exchanged between the parties inside the SMA app with no need to send further deep links through the transport medium (the secure channel) - each message here will derive its metadata and permission from the root message.
Fig. 8 (A-F) illustrates screen displays of a sender and a recipient when a message is sent by the sender using the secure messaging method and system, according to an embodiment of the present invention. Obviously, the present invention is not limited to the specific messaging software application presented in Fig. 9 (A-F), nor is the invention limited to any other aspect presented in Fig. 9 (A-F) such as the visual or textual features of the secure messaging application.
Fig. 9(A) shows a screen display 901 of a sender's messaging software application, after the recipient ("Alice Wonder") has been designated (902), the message "Hello" has been typed (903), and the secure messaging app has been activated (904). According to an embodiment of the invention, the secure messaging application is activated by tapping the "s" key three consecutive times (as implied in Fig. 9 by the auto-completion suggestion 905). Fig. 9(B) shows the screen display 901 of the sender after the message 903 has been swapped with a secure message notification 906. Fig. 9C shows the screen display 901 of the sender after notification 906 has been sent to Alice Wonder. Fig. 9D shows the screen display 907 of the recipient (Alice Wonder) after tapping the notification message 906, wherein an authorization request layer 908 is presented, implying that the message 903 may be accessed only after the sender ("Bob") approves the access request. Fig. 9E shows the screen display 901 of the sender, in which an authorization approval layer 909 is presented, allowing the sender to approve or decline access of the recipient to the message 903. Fig. 9F shows the screen display 901 of the sender after a secure channel has been established between the sender and the recipient. Furthermore, Fig. 9F shows an icon 909 that when tapped grants the sender access to all messages sent from any host software application. Also displayed are the statuses of each message (security status, access permission etc.) alongside allowing the user to act on the messages from there, e.g revoke message permission. In addition, Fig. 9F shows another icon 911 that when tapped allows to destroy/revoke a specific message from all recipients of the message, including messages that are attached to the root message/channel. The secure messaging system of the present invention provides several benefits over the prior art systems. The benefits include, among others, the ability to create secure messages from any messaging software application (host-app) and invite new participants to view messages over other host-apps. For example a sender can create a secure message invitation in a first host-app (e.g. WhatsApp), send the invitation to a first recipient, and then invite a second recipient over a second host-app (e.g. email) to join the same secure channel. When the second recipient follows the link in the second host-app (e.g. email) the second recipient joins the same secure channel that the sender and first recipient are sharing, that was originally initiated over the first host-app (WhatsApp).
Another benefit over other prior art systems is the fact that a message doesn't comprise the contents of the message itself (e.g. text or an image), but it comprises a link to the contents, thereby granting an extra level of indirection. Moreover, and inherent from the said benefits, each new viewer can be approved before viewing message data. Furthermore, at any point in time, a message may be revoked thereby permanently erasing any copy of the message data, whether existing on the sender's device or on an approved viewer's device. From this point on, any further requests from anyone to read the revoked message, whether from previously approved viewers or from other viewers, are denied by the secure messaging server. Furthermore, Alerts may be defined to trigger a sender's device when certain conditions are met in a secure message shared by the sender, as discussed below.
Traditionally, when an image is sent from a sender to a recipient, the recipient is free to do as his will with the image. The image can be distributed to other viewers using the app over which the image was received or using other sharing channels. Furthermore, a recipient can screen capture the image, or take a photograph of the image using another imaging device. According to an embodiment of the present invention, the secure messaging server protects senders from such actions using image traceability, in which a securely sent image is marked with a hidden mark, identifying the intended viewer (i.e. the recipient). The hidden mark can be the recipient's number or any other unique identifying data, and is implemented using steganography. According to an embodiment of the invention, the hidden mark's properties may be, but are not limited to:
1. visuality, i.e. it will remain in new copies of the original image taken with, for instance, an external camera; and 2. concealment, i.e. a recipient cannot remove the mark with a reasonable effort without damaging the original image.
According to an embodiment of the present invention, a user may import data (e.g. images) to the secure messaging system, thereby preventing direct access to the data whereas access is granted only through the secure messaging app. This embodiment helps protecting users from unwanted peeking in case a device is stolen or lost.
Although embodiments of the invention have been described by way of illustration, it will be understood that the invention may be carried out with many variations, modifications, and adaptations, without exceeding the scope of the claims.

Claims

Claims
1. A method for controlling access to a message, characterize in that an exchange of encryption keys is initiated by a recipient upon receipt of a recipient's request by a sender, wherein said message may comprise one or more attached documents.
2. A method according to claim 1, wherein the controlling comprising:
a) generating, by a dedicated Secure Messaging software Application (SMA) on a sender's device (the sender's SMA), a message ID, a message hyperlink and message metadata comprising one or more rules according to which recipients are granted or denied access to the message;
b) sending to a remote server, by the sender's SMA, the message ID and metadata; c) sending to a recipient's device, by a messaging host software application on the sender's device, an invitation to access the data, the invitation comprising the message hyperlink;
d) upon activating the message hyperlink, receiving control and the message ID, by a SMA on a recipient's device (the recipient's SMA), wherein the recipient's SMA collecting data associated with the recipient's device;
e) sending a request, by the recipient's SMA, to the remote server to receive access to the message, wherein the request comprising the recipient's device associated data and the message ID; and
f) deciding, by the remote server, whether or not to grant access to the recipient according to the message metadata.
3. A method according to claim 2, wherein the SMA communicates with the messaging host software application via at least one data input means associated with said host software application, by capturing data provided via said at least one data input means.
4. A method according to claim 3, wherein the data input is performed by: text input capturing;
• accessibility API;
• OS API hooking;
• functioning as a keyboard where all text goes through;
• sharing to another app; and/or • using browser extension to hook all activities.
5. A method according to claim 1, wherein the message comprises one or more of the following:
i. text;
ii. an image;
iii. a document;
iv. an audio clip; or
v. other data.
6. A method according to claim 2, wherein the access grant decision of the server is further based recipient's device associated data.
7. A method according to claim 2, wherein one of the message metadata rules comprises enabling the sender to approve or deny a recipient access.
8. A method according to claim 1, further comprising allowing the sender to revoke the message after the message has been received by the recipient.
9. A method according to claim 2, wherein the message metadata comprises rules defining behavior of the message.
10. A method according to claim 9, wherein the behavior of the message includes one or more of the following aspects:
expiry of the message, i.e. time or action dependent;
sender approval requirements of the message;
re-authentication limitation;
screenshot limitations;
geolocation viewing limitations; and/or
reader safety limitations.
11. A method according to claim 2, wherein the recipient's device associated data comprises:
device oriented items;
physical meters, i.e. date, time and geolocation; and/or operational metrics.
12. A method for creating a secure messaging channel between a sender and a recipient, comprising:
sending a root message from the sender to the recipient according to the method of claim 1;
establishing a secure channel between the sender and the recipient; and
sending other messages between the recipient and the sender through the secure channel.
13. A method according to claim 12, wherein the metadata of the root message defines the behavior of the entire secure channel.
14. A method according to claim 12, wherein revocation of a root message causes revocation of other messages sent through the secure channel.
15. A system for controlling access to a message comprising a first apparatus for delivering an encryption key request from a sender to a recipient, and a second apparatus for sending said request to said sender by said recipient upon receipt of a request, wherein said message may comprise one or more attached documents.
16. A system according to claim 15, further comprising:
c) a secure messaging server, comprising a key exchange module configured to manage exchange of encryption keys between users; a message broker module configured to manage transport of messages, permissions and properties between users; a Data Loss Prevention (DLP) configuration module comprising configurable lists of words that invoke suggestions to use an encryption option; a database for storing messages, keys and user IDs; and
d) one or more transport medium servers.
17. A system according to claim 16, wherein the first and second apparatuses are user electronic communication devices capable of communicating over the internet with the secure messaging server and with the one or more transport medium servers, wherein each device comprising a transport application; and a secure messaging application (SMA) configured to block the transport application from accessing contents of a message, while generating another message to be sent using the transport application indicating that a secure message has been created.
18. A system according to claim 17, in which the secure messaging server further comprises: a) a front end module communicating bi-directionally over the Internet with the user device's SMA; b) an in-queue module configured to receive incoming messages from user devices' SMAs; c) an out-queue module configured to receive outgoing messages for user devices' SMAs; and d) a push messaging manager configured to push notifications from the out-queue to SMAs of user devices.
PCT/IL2017/051283 2016-11-23 2017-11-23 Controlling access to electronic messages and shared data WO2018096539A1 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201662425621P 2016-11-23 2016-11-23
US62/425,621 2016-11-23
IL255865A IL255865B (en) 2017-11-22 2017-11-22 Controlling access to electronic messages and shared data
IL255865 2017-11-22

Publications (1)

Publication Number Publication Date
WO2018096539A1 true WO2018096539A1 (en) 2018-05-31

Family

ID=61198586

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IL2017/051283 WO2018096539A1 (en) 2016-11-23 2017-11-23 Controlling access to electronic messages and shared data

Country Status (2)

Country Link
IL (1) IL255865B (en)
WO (1) WO2018096539A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109691013A (en) * 2018-08-16 2019-04-26 区链通网络有限公司 Block chain communication method between nodes, device and storage medium, block catenary system

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8176324B1 (en) * 2009-07-02 2012-05-08 Exelis Inc. Method and system for a secure virtual keyboard
US20140258724A1 (en) * 2013-03-06 2014-09-11 Marvell World Trade Ltd. Secure simple enrollment
US20150096042A1 (en) * 2013-10-02 2015-04-02 Innovative Venture, S.A. a Panama Corporation Method and apparatus for improved private messaging
US20150350163A1 (en) * 2014-06-02 2015-12-03 Blackberry Limited System and method for initiating protected instant messaging conversations

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8176324B1 (en) * 2009-07-02 2012-05-08 Exelis Inc. Method and system for a secure virtual keyboard
US20140258724A1 (en) * 2013-03-06 2014-09-11 Marvell World Trade Ltd. Secure simple enrollment
US20150096042A1 (en) * 2013-10-02 2015-04-02 Innovative Venture, S.A. a Panama Corporation Method and apparatus for improved private messaging
US20150350163A1 (en) * 2014-06-02 2015-12-03 Blackberry Limited System and method for initiating protected instant messaging conversations

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109691013A (en) * 2018-08-16 2019-04-26 区链通网络有限公司 Block chain communication method between nodes, device and storage medium, block catenary system

Also Published As

Publication number Publication date
IL255865B (en) 2021-01-31
IL255865A (en) 2018-01-31

Similar Documents

Publication Publication Date Title
US11914684B2 (en) Secure messaging service with digital rights management using blockchain technology
CN106104562B (en) System and method for securely storing and recovering confidential data
US11412385B2 (en) Methods for a secure mobile text message and object sharing application and system
US20160065571A1 (en) System and methods for secure file sharing and access management
US9866591B1 (en) Enterprise messaging platform
CN106790037B (en) User mode encrypted instant messaging method and system
US10237057B2 (en) Method and system for controlling the exchange of privacy-sensitive information
US20170279807A1 (en) Safe method to share data and control the access to these in the cloud
US10708237B2 (en) System and method for chat messaging in a zero-knowledge vault architecture
JP2010522488A (en) Secure electronic messaging system requiring key retrieval to distribute decryption key
US20160359822A1 (en) Sovereign share encryption protocol
CN108768613A (en) A kind of ciphertext password method of calibration based on multiple encryption algorithms
US11153286B1 (en) Encrypting content and facilitating legal access to the encrypted content
US11444897B2 (en) System and method for providing privacy control to message based communications
Alatawi et al. Sok: An analysis of end-to-end encryption and authentication ceremonies in secure messaging systems
WO2016033208A1 (en) System and methods for secure file sharing and access management
US11848754B1 (en) Access delegation leveraging private keys on keystores read by provisioned devices
US11330003B1 (en) Enterprise messaging platform
WO2018096539A1 (en) Controlling access to electronic messages and shared data
Mahbod et al. Cybersecurity Challenges and Application within the Army National Guard.
US11736462B1 (en) Hybrid content protection architecture for email
Saharan et al. Secure End-to-End Chat Application: A Comprehensive Guide.
Asha et al. ACCESS CONTROL MECHANISM BASED MESSENGER APPLICATION FOR SECURE COMMUNICATION USING AES ENCRYPTION METHODOLOGY
Bhadoria et al. ChatApp with Encryption using Firebase
Albert Computer Security Tools and Concepts for Lawyers

Legal Events

Date Code Title Description
DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17875043

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 29.08.2019)

122 Ep: pct application non-entry in european phase

Ref document number: 17875043

Country of ref document: EP

Kind code of ref document: A1