Secure instant messaging
Instant messaging (IM) is a type of online chat which offers real-time text transmission over the Internet. A LAN messenger operates in a similar way over a local area network.
Instant Messaging service includes the following functions:
- Sending and receiving text messages;
- Sending audio and video recordings;
- Send your images and file transfer;
- May take actions, such as sharing and drawing games;
- Group text chats;
- Videoconference and video chats.
Non-IM types of chat include multicast transmission, usually referred to as "chat rooms", where participants might be anonymous or might be previously known to each other (for example collaborators on a project that is using chat to facilitate communication). Instant messaging systems tend to facilitate connections between specified known users (often using a contact list also known as a "buddy list" or "friend list"). Depending on the IM protocol, the technical architecture can be peer-to-peer (direct point-to-point transmission) or client-server (a central server retransmits messages from the sender to the receiver).
Instant messaging services, are used as an alternative email. The prototype of IM were online chats, used since the early 1990s (of which was taken the basic principle of work - instant delivery of messages from a friend to the interlocutor). The first Internet-pager - ICQ ("I seek you"), it soon began to call these services and software clients, was launched in November 1996 by Mirabilis. The decision was a client-server architecture (become a classic for such systems) - the user downloaded the free software client that connects to the server that stores the registration information and a list of contacts.
The purpose of this paper is studying protocols for secure instant messaging.
The project objectives can be summarized as follows:
- Research the principle of operation of the Instant Messaging;
- Research secure protocol for Instant Messaging.
Modern, Internet-wide, GUI-based messaging clients as they are known today, began to take off in the mid-1990s with PowWow, ICQ, and AOL Instant Messenger . Similar functionality was offered by CU-SeeMe in 1992; though primarily an audio/video chat link, users could also send textual messages to each other. AOL later acquired Mirabilis, the authors of ICQ; a few years later ICQ (now owned by AOL) was awarded two patents for instant messaging by the U.S. patent office. Meanwhile, other companies developed their own software; (Excite, MSN, Ubique, and Yahoo!), each with its own proprietary protocol and client; users therefore had to run multiple client applications if they wished to use more than one of these networks. In 1998, IBM released IBM Lotus Sametime, a product based on technology acquired when IBM bought Haifa-based Ubique and Lexington-based Databeam.
In 2000, an open source application and open standards-based protocol called Jabber was launched. The protocol was standardized under the name Extensible Messaging and Presence Protocol (XMPP). XMPP servers could act as gateways to other IM protocols, reducing the need to run multiple clients. Multi-protocol clients can use any of the popular IM protocols by using additional local libraries for each protocol. IBM Lotus Sametime's November 2007 release added IBM Lotus Sametime Gateway support for XMPP.
As of 2010, social networking providers often offer IM abilities. Facebook Chat is a form of instant messaging, and Twitter can be thought of as a Web 2.0 instant messaging system.
Many instant messaging services offer video calling features, voice over IP and web conferencing services. Web conferencing services can integrate both video calling and instant messaging abilities. Some instant messaging companies are also offering desktop sharing, IP radio, and IPTV to the voice and video features.
The term "Instant Messenger" is a service mark of Time Warner and may not be used in software not affiliated with AOL in the United States. For this reason, in April 2007, the instant messaging client formerly named Gaim (or gaim) announced that they would be renamed "Pidgin".
Extensible Messaging and Presence Protocol (XMPP)
Extensible Messaging and Presence Protocol (XMPP) is a communications protocol for message-oriented middleware based on XML (Extensible Markup Language). The protocol was originally named Jabber, and was developed by the Jabber open-source community in 1999 for near real-time, instant messaging (IM), presence information, and contact list maintenance. Designed to be extensible, the protocol has also been used for publish-subscribe systems, signalling for VoIP, video, file transfer, gaming, Internet of Things (IoT) applications such as the smart grid, and social networking services.
Unlike most instant messaging protocols, XMPP is defined in an open standard and uses an open systems approach of development and application, by which anyone may implement an XMPP service and interoperate with other organizations' implementations. Because XMPP is an open protocol, implementations can be developed using any software license; although many server, client, and library implementations are distributed as free and open-source software, numerous freeware and commercial software implementations also exist.
The Internet Engineering Task Force (IETF) formed an XMPP working group in 2002 to formalize the core protocols as an IETF instant messaging and presence technology. The XMPP Working group produced four specifications (RFC 3920, RFC 3921, RFC 3922, RFC 3923), which were approved as Proposed Standards in 2004. In 2011, RFC 3920 and RFC 3921 were superseded by RFC 6120 and RFC 6121 respectively, with RFC 6122 specifying the XMPP address format. In addition to these core protocols standardized at the IETF, the XMPP Standards Foundation (formerly the Jabber Software Foundation) is active in developing open XMPP extensions.
XMPP-based software is deployed widely across the Internet, and by 2003, was used by over ten million people worldwide, according to the XMPP Standards Foundation.
The XMPP network uses a client–server architecture; clients do not talk directly to one another. The model is decentralized, anyone can run a server, but neither anonymous nor peer to peer, like Skype. By design, there is no central authoritative server as there is with services such as AOL Instant Messenger or Windows Live Messenger. Some confusion often arises on this point as there is a public XMPP server being run at jabber.org, to which a large number of users subscribe. However, anyone may run their own XMPP server on their own domain.
Every user on the network has a unique Jabber ID, often abbreviated as JID. To avoid requiring a central server to maintain a list of IDs, the JID is structured like an email address with a username and a domain name (or IP address) for the server where that user resides, separated by an at sign (@), such as email@example.com.
- Decentralization: The architecture of the XMPP network is similar to email; anyone can run their own XMPP server and there is no central master server .
- Open standards: The Internet Engineering Task Force has formalized XMPP as an approved instant messaging and presence technology under the name of XMPP (the latest specifications are RFC 6120 and RFC 6121). No royalties are required to implement support of these specifications and their development is not tied to a single vendor.
- Security: XMPP servers can be isolated from the public XMPP network (e.g., on a company intranet), and strong security (TLS) has been built into the core XMPP specifications .
- Flexibility: Custom functionality can be built on top of XMPP; to maintain interoperability, common extensions are managed by the XMPP Standards Foundation. XMPP applications beyond IM include groupchat, network management, content syndication, collaboration tools, file sharing, gaming, remote systems control and monitoring, geolocation, middleware and cloud computing, VoIP and Identity services .
- Doesn'tsupport Quality of Service (QoS): Assured delivery of messages has to be built on-top of the XMPP layer. Normally, this is done using simple sequence number attributes in stanzas.
- Text-based communication: Since XML is text based, normal XMPP has a higher network overhead compared to purely binary solutions. This issue is being addressed by the experimental XEP-0322: Efficient XML Interchange (EXI) Format, where XML is serialized in a very efficient binary manner, especially in schema-informed mode.
- In-band binary data transfer is limited: Binary data must be first base64 encoded before it can be transmitted in-band. Therefore any significant amount of binary data (e.g., file transfers) is best transmitted out-of-band, using in-band messages to coordinate. The best example of this is the Jingle XMPP Extension Protocol, XEP-0166.
Off-the-Record Messaging (OTR) Protocol
Off-the-Record Messaging (OTR) is a cryptographic protocol that provides encryption for instant messaging conversations. OTR uses a combination of AES symmetric-key algorithm with 128 bits key length, the Diffie–Hellman key exchange with 1536 bits group size, and the SHA-1 hash function. In addition to authentication and encryption, OTR provides perfect forward secrecy and malleable encryption.
The primary motivation behind the protocol was providing deniable authentication for the conversation participants while keeping conversations confidential, like a private conversation in real life, or off the record in journalism sourcing. This is in contrast with other cryptography tools that produce output which can be later used as a verifiable record of the communication event and the identities of the participants. The initial introductory paper was named "Off-the-Record Communication, or, Why Not To Use PGP .
The OTR protocol was designed by cryptographers Ian Goldberg and Nikita Borisov. They provide a client library to facilitate support for instant messaging client developers who want to implement the protocol. A Pidgin and Kopete plugin exists that allows OTR to be used over any IM protocol supported by Pidgin or Kopete, offering an auto-detection feature that starts the OTR session with the buddies that have it enabled, without interfering with regular, unencrypted conversations.
In addition to providing encryption and authentication — features also provided by typical public-key cryptography suites, such as PGP, GnuPG, and X.509 (S/MIME) — OTR also offers some less common features:
- Perfect forward secrecy: Messages are only encrypted with temporary per-message AES keys, negotiated using the Diffie-Hellman key exchange protocol. The compromise of any long-lived cryptographic keys does not compromise any previous conversations, even if an attacker is in possession of ciphertexts.
- Deniable authentication: Messages in a conversation do not have digital signatures, and after a conversation is complete, anyone is able to forge a message to appear to have come from one of the participants in the conversation, assuring that it is impossible to prove that a specific message came from a specific person. Within the conversation the recipient can be sure that a message is coming from the person they have identified.
As of OTR 3.1, the protocol supports mutual authentication of users using a shared secret through the socialist millionaire protocol. This feature makes it possible for users to verify the identity of the remote party and avoid a man-in-the-middle attack without the inconvenience of manually comparing public key fingerprints through an outside channel.
Due to limitations of the protocol, OTR does not support multi-user group chat as of 2009  but may be implemented in the future. As of version 3 of the protocol specification, an extra symmetric key is derived during authenticated key exchanges that can be used for secure communication (e.g., encrypted file transfers) over a different channel. Support for encrypted audio or video is not planned. (SRTP with ZRTP exists for that purpose.)
Since OTR protocol v3 (pidgin-otr 4.0.0 and libotr 4.0.0) the plugin supports multiple OTR conversations with the same buddy who is logged in at multiple locations.
Table overview of secure messengers
|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?||TCP||UDP|
|Telegram||GPL v2 (client), closed source (server)||yes||no||yes||no||no||1024||2048||yes||no||yes||no||no||no||yes||no|
Table criteria description
The table above describes an overview of Instant Messenger Clients, which are sending messages 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. To counter this, decentral server architectures have been developed, either via some peer-to-peer technology, or by open source chat servers, which can be set up by everyone. An architecture where nott all the messages pass through a central server is a big plus regarding security, because a one-stop-shop for surveillance is not as secure as if a decentral model is chosen.
- Symmetric encryption: In symmetric cryptography, the same key is used for encryption and decryption. Knowledge of this key needs to be limited to the two communication partners to ensure confidentiality.
- 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 its security is based on hard-to-solve 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 some alternatives, e.g. ElGamal or NTRU. NTRU is regarded as secure even for quantum computing.
- 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 encryption key every session or even instant.
- Multiencryption: 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 file transfer. 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.
- Transport protocols: Not all messengers support the most given transport protocols like TCP, UDP and SCTP.
Go to Bibliography
Back to Table of Contents