Secure Instant Messaging

Instant messaging (IM) is a type of communication which allows you to send data over the Internet from one user to another using a certain application. Ideally, no one but these two users should be able to read these messages.

In order to protect your digital communication, you will need to address a variety of threats. Doing so requires some technical knowledge, like understanding what happens to your messages between your device and that of the recipient, but it also requires good habits like keeping your device secure from malware, using strong passwords, avoiding phishing attempts and maintaining a communication plan that suits your needs.

Instant Messaging includes the following functions:

• user authentication
• sending and receiving data like text messages, audio and video messages, etc.
• VoIP
• having group chats

Below are a few general concepts that will help you understand where your digital communication might be exposed and how you can reduce some of those risks.

Рarticipants that take part in application development and the subsequent processing of necessary data. In any data transmission type 2 parties are present, and the most spread architecture is client - server. When considering the exposure of your digital communication, you still have to worry about those who might directly observe the messages you send and receive, but you also have to consider things like network infrastructure, provider policies and encryption.

According to the standard model of data transmitting in messaging applications there are 3 participants in it:

Client is an end-user which execute application for different data and messages transmitting. He possess one or several devices with essential software installed. End user owns the following artifacts: Client data, tools, device(s), web browser applications.

App Provider is responsible for application business logic, herein: user and device authorization, user data storing, which platform or services providers will have access to which data, messaging history collecting, user identification, billing services etc. Application server is able to share its responsibilities with 3rd party services. Thus, application server is responsible for usage of certain providers in the application.

App server owns the following artifacts: set of backend services, data storage resources.

3rd party services and platforms (PaaS, SaaS, etc.) provide necessary functionality for business logic implementation (e.g. Nexmo, Twilio, Firebase, etc. they offer ready-made functionality for developers) and/or responsible for transferring data over internet (internet service providers) and other related services (e.g., statistics etc).

3rd party services owns the following artifacts: computing networks, storage systems, ready-to-use software, authentication services and other business logic services.

From the data security perspective you can divide ready made app solution on two types of communication - secure and insecure.

Non-protected communication between two or more parties which can be affected by data breach issues. Main problem of insecure communication is the possibility of sensitive personal data to be read by 3rd parties if they can get access to it. Your communication could be targeted by criminals, governments, companies, social groups or individuals. They might be seeking valuable information, harassing people who fit a certain profile or trying to prevent you from doing your work, among other possible motives.

Nowadays, in order to prevent data breaches and protect sensitive data privacy there are a lot of prescriptions and rules that require to make your communication secured according to the laws of data privacy (GDPR, HIPAA).

Communication type where people can share information with varying degrees of certainty that third parties cannot intercept what was said or sent. Security goals of communication are reached with the help of encryption.

Encryption is a way of using mathematics to scramble the content of a digital file or message so that it can only be decrypted and read by someone who has a particular piece of information, such as a password or an encryption key.

End-to-end encryption. The most common type of encryption for secure instant messaging is end-to-end encryption. End-to-end encryption is when the content you send and receive is encrypted throughout the entire path between your device to the device of the person or people with whom you are communicating. It protects that content from your service provider, the service provider of the other participant and anybody else along that path.

Let's have a look at the properties of insecure messenger.

• Sending unencrypted data and files. If data is not encrypted in transmission, hacker can easily read it in case of intercepting. Moreover, the user is obliged to encrypt data in accordance with modern rules and regulations;

• Wrong or weak encryption algorithms (RSA, DES, RC4). When using algorithms with weak crypto-complexity user has to understand that they are easily exposed to crypto-analysis, and thus easily deciphered.

• Relying on standard encryption and data transmission approaches, such as HTTPS (SSL). Mostly all modern security standards do not supply SSL because it has a low configuration level in versions below 3.0 and its high availability to attacks. TLS (ssl) and HTTPS only encrypt communication between your device and the service you are using. Once it reaches the server, it will be decrypted, stored, scanned and quite possibly sent elsewhere.

• Man-in-the-middle and other hacker attacks which are widely spread for the client-server architecture. The more connections are present in the architecture - the more possibilities for hacker to intercept data, even while passing through a physical cable.

• Wrong key management. Insecure key transit, key validity period, automatic key replacement, storing users’ private keys in insecure way (for example, in databases), users’ private encryption keys are not under the users control because they are generated by application servers;

• Using 3rd-party providers and commercial services that have unauthorized access to users’ data (e.g. statistics services and applications)

• Malware infected devices of clients or on the server side. ( e.g. wifi router, pc, smartphone, isp equipment)

Main user problem is the absence of reliable and secure storage for their keys and secret data. Each platform or programming language provides its own storage for keys and secret data. Developers often try to develop cross-platform solutions and as the result they do not take into account all the storing shortcomings and therefore make security mistakes when developing their solutions.

Secure communication can be characterized by the following features:

1. Confidentiality. Confidentiality ensures that the necessary level of secrecy is enforced at each junction of data processing, preventing unauthorized disclosure. Confidentiality can be provided by encrypting data while it is stored and transmitted. In cryptographic protocols confidentiality is essential to ensure that keys and other data are available only as intended.

   Example: Bob is unable to read the message if he is not authorized, he also is not able to read this message if he managed to intercept it.

2. Integrity. Integrity ensures that no one throughout the transmission modifies the messages. Hardware, software, and communication mechanisms must work in concert to maintain, process, and move data to intended destinations, without unexpected alterations. Systems that enforce and provide this security property ensure that attackers, or mistakes by users, do not compromise the integrity of systems or data.

   Example: If Bob sends a message to Alice, both must be sure that no one modified this message in transit even if he managed to intercept it.

3. Authentication. Authentication is meant to identify the parties in a conversation.

   Example: If Bob gets a message from Alice he must be sure that Alice herself send this message and had necessary permissions.

4. Perfect forward secrecy. Perfect forward secrecy is a feature of specific key agreement protocols that gives assurances that session keys will not be compromised even if the private key of the server is compromised. Forward secrecy protects past sessions against future compromises of secret keys. By generating a unique session key for every session a user initiates, the compromise of a single session key will not affect any data other than that exchanged in the specific session protected by that particular key.

   Example: If Bobs’ message and session key were intercepted, then the hacker will get access only to this message and not to forward correspondence.

5. Backward secrecy. Backward secrecy guarantees the "opposite direction" of forward secrecy. In other words, this security guarantees that the encrypted messages in a session should remain secure even if "backward" long-term key corruption occurs.

   Example: If all Bobs’ messages and only one session key were intercepted, hacker gets access only to the message that matches a session key, and all other messages stay encrypted.

6. Deniability. Deniability is a property common to new secure messaging protocols, where it is not possible for others to prove that the data was sent by some particular conversation party.

   Example: If Alice sent a message in a chat, no one can prove that it was Alice who sent the message.

1. Trust Equality. No single participant has more trust or responsibility, within the group, than any other.

   Example: If Bob and Alice have same encryption key, they have same access to data in the chat.

2. Contractible Membership. No need to restart the security protocol when a member leaves the conversation.

   Example: If Bob deleted Alice from a group chat there is no need to create a new chat or create new security keys for other chat members.

3. Expandable Membership. No need to restart the security protocol when adding a new member after the group has been generated.

   Example: If Alice added Bob to the chat, there is no need to create new security keys for other members of the chat.

Developers and service providers often sacrifice security for user convenience and audience growth. Thus, even if you focus on convenience, this convenience should possess such properties:

1. Out-of-order Resilience. If a message is delayed in transit, but eventually arrives, its contents are accessible upon arrival.

   Example: If Alice got a message from Bob while she had no internet connection, she will get it at the moment she connected to internet and will be able to read it.

2. Dropped Message Resilient. Messages can be decrypted without receipt of all previous messages. This is desirable for asynchronous and unreliable network services.

   Example: Alice added Bob to a group chat, but she doesn't want him to read previous messages.

3. Asynchronous. Messages can be sent securely to devices which are not connected to the Internet at the time of sending.

   Example: If message was sent to Bob while he was not connected to the internet, message will not be intercepted and/or modified while he is offline.

1. Multi-Device Support. A user can connect to the conversation from multiple devices at the same time, and have the same view of the conversation as the others.

   Example: Bob is in his office and using a laptop to chat, but he needs to go out and can take his smartphone with him. Smartphone or any other his device is able to decrypt all necessary messages in the chat. And cryptographic keys are sent securely to a new device.

1. No Additional Service. The protocol does not require any infrastructure other than the protocol participants. Specifically, the protocol must not require additional servers for relaying messages or storing any kind of key material.

   Example: Bobs’ security key is stored and generated in his device, not on the server.

In order to compare applications and choose one you consider the most secure please visit https://www.securemessagingapps.com