Secure instant messaging
Secure instant messaging is a form of instant messaging. Both terms refer to an informal means for computer users to exchange messages commonly referred to as 'chats'. Instant messaging can be compared to texting as opposed to making the cell phone call. In the case of messaging it is like a short form of emailing. Secure instant messaging is a specialized form of Instant Messaging that along with other differences encrypts and decrypts the contents of the messages such that only the actual users can understand them.
Instant messaging background
Instant messaging has been around in some form or another for decades. Generally it is a process by which users on a computer network can quickly communicate with one another using short text based sentences rather than using email. Each user has a client piece of software that communicates with a common server that orchestrates the chat sessions. Instant messaging is similar in concept to texting rather than making the phone call. Over the years two distinct settings for the use of instant messaging have evolved.
The first would be the corporate or institutional environment composed of many potential users but who are all under the same organizational umbrella.
The second setting would be individual users ‘after work’ or at home who do not have a mission oriented commonality between them but more likely are family and friends.
In the first corporate setting security risks became apparent from the outset. What stops a disgruntled employee from messaging some sensitive company data to a colleague outside the enterprise? The reverse of that would be the example disgruntled employee downloading some virus or spyware onto his machine inside the corporate firewall to release as desired. Accordingly organizational offerings have become very sophisticated in their security and logging measures. Typically an employee or organization member must be granted a login and suitable permissions to use the messaging system. This creating of a specific account for each user allows the organization to identify, track and record all use of their messenger system on their servers.
The specialized requirements of the organizational messaging system however, run almost completely contrary to what an individual user may need. Typically non organizational use instant messengers advertise their availability to the Internet at large so that others may know if that person is online. The trend has been too that manufacturers of instant messaging clients offer interoperability with other manufacturer’s clients.
This competitive edge grew out of the heretofore use of proprietary communications protocols used by the client manufacturers. Compatibility between clients is likely to become almost universal as a unified messenger protocol the ‘Extensible Messaging and Presence Protocol’ (XMPP) is being adopted by more and more manufacturers. The XMPP has been at least in part been formalized by the Internet Engineering Task Force as RFC 6120, RFC 6121 and RFC 6122 which will further the trend towards instant messaging standardization.
For the typical social individual user this product evolution spells greater ease of use and more features.
- Presence and Status Broadcasting - Messengers attempt to maintain a social environment and always stay 'connected'.
- Interoperability – Many other manufacturers can interoperate with the example messenger.
- Contact Lists - Maintains lists of all desired contacts.
- Client-Server Design – Requires use of third party servers to provide chat functionality to messenger clients.
- Logs Messages – Messages and other events are recorded.
Security is more than content encryption
Certainly the contents of the messages must be understandable only to the desired parties but what of other behaviors or traits of instant messengers? Almost by definition alone a secure messenger cannot be a social messenger. Therefore to be considered secure a messenger must behave differently than a normal messenger in more areas than just encrypted vs. plain text message contents.
- A secure messenger must never broadcast its status or presence online.
- A secure messenger must not be able to send messages in clear text form.
- A secure messenger must never log or store any information regarding any message or its contents.
- A secure messenger must never log or store any information regarding any session or event.
- A secure messenger must not rely on third party servers for message security and handling.
Secure instant messaging is a form of instant messaging wherein at the very least the users are exchanging chat messages the contents of which they have caused to be encrypted with keys they generate and control.
Recent news events have revealed that the NSA is not only collecting emails and im messages but also tracking relationships between senders and receivers of those chats and emails in a process known as 'meta data' collection.
Although innocuous sounding the term 'meta data' that refers to the data concerned about the chat or email as opposed to its actual contents has been shown to something valuable to collect.
Therefore instant messengers that not only encrypt message contents but also offer a 'stealth' presence on the Internet will provide their users more overall security during chat sessions.
Secure instant messengers aren’t needed for every chat session but when there is a requirement for private, secure and untraceable messaging there is no other means to effect those requirements.
Table overview of secure messengers
||It has been suggested that this section be merged into Comparison of instant messengers. (Discuss) Proposed since July 2014.|
|Client Name||Open Source License||Without Central Server||Symmetric Encryption (e.g. AES, Camellia)||Asym.: RSA, DSA||Asym.: NTRU||Asym.: ElGamal||Default Asym. Keysize||Max. Asymm. Keysize||Forward Secrecy||Multi-Encryption||Clientside Encryption||Encrypted Groupchat||Encrypted Filetransfer||Public Key not stuck to IP?||Proxy /Tor||Chat to offliners||TCP||UDP||SCTP||Serversoftware open source||Website|
|Telegram||GPL v2 (client), closed source (server)||Yes||no||Yes||no||no||1024||2048||Yes||no||Yes||no||no||no||?||no||Yes||no||no||No||https://www.telegram.org|
Table criteria description
The table above describes an overview of Instant Messenger Clients, which are sending the Message encrypted. For that, several criteria are to consider.
- open source
- Encryption algorithms must be transparent. For that, the open source status of the application is essential. Messengers, which are not revealing the source, must be trusted by the company, offering the messenger. To find flaws and failures in the code, only an audit of a community being able to look into the source can check, if the encryption implementation has been done in a proper way. In general it is recommended to not trust closed source encrytion.
- decentralized model
- A messenger will fail, if a central server is closed or surveilled. For that decentral server architectures have been developed, either bei a peer-to-peer technology, or by open source chat servers, which can be set up by everyone. An architecture, where all the messages go not through a central server is a big plus in redard for security, because a one-stop-shop for surveillance is not as secure as if a decentral model is chosen.
- symmetric encryption
- Symmetric enrcyption describe a kind of passphrase, only both users know to decrypt the message. It is a hidden secret, only both participants know.
- alternatives in asymmetric encryption
- Asymmetric encryption means, that both participants have a private and public key. The public key must be exchanged. A mathematical operation then encrypts the message with the public key of the receiver. Mostly the RSA Algorythm is used here. As it is based on not-solveable complex mathematical operations, the encryption might be regarded as safe. But what happens if the complex problem is soon a simple one? Better to not have only RSA as the only method in this regard, but also here some alternatives: e.g. ElGamal or NTRU. NTRU is regarded as secure even for quantumcomputing.
- key size
- The key size describes the length of the needed mathematical operation. Simply spoken, the longer the key, the longer it takes to crack it. Today a key size of 2048 for asymmetric keys is recommended.
- forward secrecy
- Forward secrecy describes the option to change the encrryption key every session or even instant.
- Multiencryption describes several layers of encryption. E.g. you can add a symmetric encryption within an asymmetric encryption, the ciphertext then is locked once more with an additional password.
- clientside encryption
- The encryption key must be stored on the device of the user, not on a remote server in the web. Also the plaintext should be processed to ciphertext on the device of the user. It must happen in his hand, not on a remote server.
- group chat and file transfer
- Some messengers offer Groupchat and Filetransfer. These features as well should transfer only encrypted bytes.
- key not stuck to IP?
- Public keys are used to identify users. A user's IP address can in some cases be related to his or her public key. Messengers that do not relate the user's public key to the user's IP address are considered more secure. This offers more security because the IP cannot be targeted to gain access to the private key. If an attacker knows the IP related to a public key, he or she can try to get on the remote machine, download and decrypt the private key and thus decrypt all encrypted communication.
- chat to offline users
- Messengers without a central server need special means to be able to message to friends, which are offline. This is mostly done by storing the messages in other online friends. As this is a quite convenient feature, some messengers offer this in an encrypted way too.
- transport protocols
- Not all messengers support the most given transport protocols like TCP, UDP and SCTP.
- chat server open source
- As some Messenger need a central server, the source of this chat server need to be published, to be transparent and auditable as well for this bridge, a message takes. Here as well as for the client the claim should be, that this part of the software should be open source as well.
- Cisco WebEx Connect IM - Products & Services - Cisco
- HowStuffWorks "How Instant Messaging Works"
- XMPP Technologies Overview – The XMPP Standards Foundation
- Secure Instant Messenger - SDC
- A Primer on Metadata: Separating Fact from Fiction | Privacy By DesignPrivacy By Design