Over the course of this article I will analyse three key elements which all messenger applications must consider.
- Metadata: Any information, aside from the actual message, which is transmitted and can be exposed to third parties.
- Encryption: How your messages are encoded to obfuscate their content.
- Scalability and Attacks: How well the messenger responds to increases in usage and if there are any known attack vectors or exploits to the specific system.
I will also explore how centralisation/decentralisation can affect the privacy and security of each element. Centralisation, in this context, refers to whether the messenger architecture has a group of permissioned non federated servers, which are the sole servers and can hold or relay messages.
Through these lenses, I will examine the most popular messaging services which claim to be encrypted, or private, along with Loki messenger.
- Centralised server models, like Telegram, Facebook Messenger, Signal, Whatsapp or XMPP (Federated)
- Decentralised messengers like Tox and Bitmessage
- Mixnet based messengers like Loki Messenger
Metadata
Think about it like this: if I send a letter by post to my friend, I will put their full name and address on the front, and my full name and address on the back so that I can receive a reply. Although no one can see inside my letter and read its contents, the postal service now has a good idea of who I am, who I sent my letter to, and what time I sent my letter. This information is typically referred to as metadata.
Here’s a great quote from Kurt Opsahl from the EFF, writing on the topic of government metadata collection:
“They know you rang a phone sex service at 2:24 am and spoke for 18 minutes. But they don’t know what you talked about.
They know you called the suicide prevention hotline from the Golden Gate Bridge. But the topic of the call remains a secret.
They know you spoke with a HIV testing service, then your doctor, then your health insurance company in the same hour. But they don’t know what was discussed.” [1]
And Michael Hayden (former Director of the NSA)
“We kill people based on metadata” [2]
Now how does this relate to private messaging?
CENTRALISED SERVICES
When you use a service like Whatsapp, Telegram or Signal, you connect directly to a server owned by one of these companies. When you send a message, you must somehow tell that centralised server who you are and who the recipient of your message is. You will also typically give up your IP address and your phone number, depending on the client you use.
These centralised services have the capacity to collect metadata. Some providers, like Whatsapp and Facebook Messenger, openly admit to collecting and storing their user’s metadata. [3][4] Some services, like Signal and Telegram, have policies against storage of user metadata. [5][6] These policies require a significant amount of trust, however it has been shown countless times that as soon as trust is involved in user privacy, companies and governments will violate that trust. Look no further than popular ‘private’ email service, Hushmail, which was compelled legally to hand over users’ private information to governments. [7]The only solution to this problem is for these centralised, privacy centric services to never have the ability to collect sensitive user data.
(A note on XMPP)
Messengers based on XMPP are slightly different in their construction since they operate on a federated model. [8] This means that only a protocol is provided, users/providers can operate their own servers (which means that metadata is held by individual servers), and users have more choice in the parties they trust to store their data. This is a step in the right direction, though XMPP servers can still collect this data and have the ability to transmit it to third parties.
DECENTRALISED SERVICES
So how do the decentralised models deal with metadata? Well, there’s a few out there and they each approach metadata in a different way.
Services like Tox, and other P2P messengers, by their very nature do not require metadata to be stored on any centralised server, since messages are routed directly to their participants rather than traveling through servers or hopping through a mixing network. On the surface this can sound great, but really it gives more power to ISPs. Although the packets of data may be encrypted, ISPs can see the IP address of the person you are messaging, and if they can resolve the IP address of the recipient then they are able to very accurately ascertain information on who you messaged and at what time. This is something centralised services (Telegram, Signal, and WhatsApp) prevent. If encrypted properly, your ISP only knows you are communicating with a messaging service server, and never knows the actual IP address of your recipient.
Bitmessage is one of the other fully decentralised messaging models and might be the next best for hiding message metadata. Bitmessage operates a floodfill network, meaning that messages aren’t directed towards specific participants like they are in most other networks. In Bitmessage, every user is distributed a copy of every encrypted message. Once a user receives a message, they must attempt to decrypt the payload. This means when I want to send a message, I “flood” the message to the peers I know, who then flood the message to the peers they know. This technique makes it difficult to ascertain whether a user is merely relaying a message, or if they are the source of the message. It is also imposible to ascertain whom the true recipient is, as all clients receive all messages and attempt to decrypt them. However, there are significant downsides to operating floodfill networks, such as the high bandwidth consumption and computational overhead of attempting to decrypt each message you receive.
LOKI MESSENGER
Loki Messenger uses a number of different techniques for obfuscating metadata. In the context of the above, it is close to a mashup of Bitmessage and the Tor network. Like Bitmessage, Loki Messenger uses a decentralised set of nodes (Service Nodes) to relay messages to other users. Service Nodes are incentivised by the Loki blockchain and undertake the job of relaying messages to receive a small reward in cryptocurrency.
To avoid metadata collection in both offline and online communications, a method called onion routing is employed. Onion routing in Loki positions a set of randomly selected (simplified) Service Nodes between the user and the destination of their message. As the message hops through each Service Node toward the final recipient, a layer of encryption is removed. This onion routing provides a number of protections:
- In a typical connection it is not possible for a single Service Node to gather enough metadata to form a connection between the sender and receiver of a message.
- Service Nodes are run by the community, and are globally distributed, which makes targeted legal action difficult.
- Service Nodes require a large amount of the Loki cryptocurrency, meaning they are staked into the system. Any actions which reduce the usefulness of the Loki Messenger will likely also reduce the value of the Loki cryptocurrency. This financially incentivises good behaviour.
When a direct link between users cannot be established (the recipient is offline), Loki can also enable metadata protection for offline messages. This is done through a process called Swarm messaging. Each Loki Messenger user resides in a swarm of 10 Service Nodes. To contact another user, I can use their public key to figure out their swarm identity. My message is then sent to one of the ten nodes in their swarm, which will flood the message to the 9 others. When the user comes online, they will randomly query a node in their swarm. If that Service Node is holding a message for them, the user will download it directly from the Service Node.
Alice sends a message to Bob, Bob’s assigned Swarm is B, When Bob comes online, he queries a random node in his swarm and receives Alice’s message.
Encryption
Encryption refers to the methods each messenger uses to obfuscate the actual data inside a message. It’s easy to think of encryption as an on/off switch, but in actuality encryption is more like a volume knob – there are various features and implementation details which can marginally increase or decrease the security of the encryption in an app.
CENTRALISED SERVICES
There is significant variance when it comes to how Telegram, Whatsapp, Signal and Facebook Messenger deal with encryption – with some services providing strong, mandatory and auditable encryption, and others providing much weaker protections.
Signal
Signal is widely considered to be the best private messaging app when it comes to encryption standards as all Signal conversions are end to end encrypted by default. Signal uses the aptly named Signal protocol, which is developed as an open source project by Open Whisper Systems. [9][10] The Signal protocol has also undergone a security audit, and the results were generally positive finding only minor vulnerabilities. [11]
When correctly implemented, the Signal protocol maintains both Perfect Forward Secrecy (PFS) and Deniable Authentication (DA) in both synchronous (online) and asynchronous (offline) messages. Signal also applies encryption automatically to group chats. PFS is the ability for a protocol to tolerate the loss of a private key, without compromising the privacy of other encrypted messages that are not part of the exposed session key. DA is the ability for each party to prove to themselves that a message was signed by the other participant, but can also deny this fact to a third party. The combination of both properties allows for a messenger where messages are end to end encrypted, selective key loss is tolerable, and the origin of sent messages can never be proven to any party other than the desired recipient. These are very strong guarantees, which in essence emulate the properties of a real world conversation. Hence, a messenger with both these properties is typically referred to as an Off The Record (OTR) messenger.
WhatsApp
WhatsApp provides end to end encryption on all messages by default (including group chats), and it uses the Signal protocol for its encryption. WhatsApp also maintains a public partnership with Open Whisper Systems, who assisted them in their implementation of the Signal protocol. [12] However, WhatsApp is not open source, which means there must be a degree of trust that WhatsApp’s implementation of the Signal protocol doesn’t expose vulnerabilities.
Telegram
Telegram provides end to end encryption, but only does so for ‘secret chats.’ These chats are opt in, which means usage is low. Telegram does not yet support encrypted group chats.
For the encryption of its secret chats, Telegram currently uses the MTProto 2.0 protocol, which provides both PFS and DA. The MTProto protocol is a unique protocol, and like Signal, MTProto 1.0 has undergone formal security audits. Though in the case of MTProto 1.0, it was found that MTProto:
“is not IND-CCA secure, since it is possible to turn any ciphertext into a different ciphertext that decrypts to the same message.” [13]
With researchers also mentioning that
“The take-home message (once again) is that well-studied, provably secure encryption schemes that achieve strong definitions of security (e.g., authenticated-encryption) are to be preferred to home-brewed encryption schemes.” [14]
Since this audit, Telegram has overhauled its MTProto protocol and released version 2.0, which addresses many of the concerns that were raised in the independent security audits. [15] However many have lost trust in MTProto’s security guarantees based on the aforementioned attacks.
Facebook Messenger
Facebook Messenger provides two person end to end encrypted chats, but like Telegram, this encryption is only offered in ‘secret conversations’ and are opt in, meaning that the majority of users are left unprotected. For encryption, Facebook uses the Signal protocol, similar to WhatsApp (owned by Facebook), and is not open source meaning it is difficult for users to verify Facebook’s claims beyond assurances from Open Whisper Systems that the “integration was done appropriately.” [16]
DECENTRALISED SERVICES
Tox
Tox provides end to end encryption by default on all chats (including group chats). Tox clients all implement the Tox protocol, which uses libsodiums crypto_box implementation. Tox provides PFS and DA for all messages (other than friend requests), however Tox does not support the sending of offline messages. [17]Tox has not undergone a security audit and has come under less cryptographic scrutiny, compared to centralised messengers, due to its smaller user base.
Bitmessage
Bitmessage’s encryption is the most basic of the available decentralised messengers. This is mainly due to its asynchronous (offline) operation. Bitmessage encrypts only for longterm public key/private key pairs, meaning that it does not maintain PFS or DA. Bitmessage has not undergone a formal security audit, though community members expressed concern around some of the design decisions, which led to updated designs being released. [18]
XMPP
Since XMPP is simply a protocol, it does not enforce any type of message encryption. Though there are a number of plugins for XMPP servers and clients to enable OTR messaging, like Pidgin’s OTR, and OMEMO extensions. [19]
LOKI MESSENGER
Loki Messenger is a fork of the Signal messenger, which means Loki Messenger fully implements the Signal protocol and maintains all the properties of OTR. All Loki Messenger code is open source, allowing users and auditors to ensure the viability of our implementation. [20] There are a number of differences between Loki Messenger and Signal messenger, though encryption wise the only major difference is the storage of pre keys, which in the case of Loki Messenger does not occur on a set of centralised servers, but as the result of prekeys being passed as extra data in message payloads.
Scalability and Attacks
Although there are effective methods for relaying messages across infrastructure that is being passively surveilled, these methods often present a clear trade-off to the end user or relay operators; an increase in bandwidth, or processing power for a increase in privacy. In addition, we should consider specific attacks that can be effective against both centralised and decentralised architectures.
CENTRALISED SERVICES
Established centralised messaging services like Signal, Telegram, and WhatsApp all have frameworks which enable them to scale with their users. Because they make no overt attempt to obfuscate metadata on a protocol level, their servers can simply relay messages from the source directly to the destination – this level of activity has low overheads. Centralised server models also have an easier time dealing with spam, since they can (and do) impose identity thresholds. These thresholds commonly require a user to sign up to their service using a valid mobile phone number. This limits the number of fake accounts a malicious actor can create.
However, this type of centralisation can also present significant problems. Primarily, these services become centralised points of data collection, meaning they can expose themselves to requests from law enforcement or face legal action for activity that is occurring on their platforms. It also creates a honeypot for hackers seeking to obtain sensitive information. Additionally, most of these messengers are free to use, which means they need alternative means to pay for the infrastructure costs and staff. In order to create a viable business model, these businesses often attempt to montiese their user base by selling user data to advertisers.
DECENTRALISED SERVICES
Decentralised services primarily suffer attacks related to their inability to associate a physical identity with each one of their virtual users. This makes many decentralised models vulnerable to Sybil attacks, which can manifest as denial of service attacks or attacks that are used to passively surveil the network.
In particular services, like Bitmessage, which maintain no concept of a trusted authority, an attacker can generally operate a large portion of the client architecture and pretend to be many legitimate users. In this instance, the attacker could attempt to flood a large number of messages into the system inundating its network. Bitmessage has provided a solution to this through a small proof of work which is generated for each message sent, making it prohibitively costly for an attacker to spam thousands of messages using numerous fake identities.
A separate kind of Sybil attack can target network routing architecture. As there is a relatively low cost to running this architecture, operating a majority of the routers in the network can enable passive temporal analysis. In Tox, this can lead to flooding the DHT (a distributed table which holds the state of the network) with malicious nodes which can then segment users, cause denial of service to the ‘real’ Tox network, or even errode the effectiveness of the onion routing that Tox uses to update its DHT. [21][22]
LOKI MESSENGER
Loki introduces proof-of-work (PoW) on messages that are stored offline. Depending on the Time To Live (TTL) on the message, the difficulty of the PoW is adujsted to be easier or more difficult. For messages that do not require storage, there is no PoW needed as the overhead of processing these messages on Service Nodes is relatively low.
Loki Messenger is able to reduce the impact of Sybil attacks on the routing architecture by requiring that each Service Node lock a large amount of Loki in a special time-locked transaction. This creates an inherent market-based Sybil resistance, making it prohibitively expensive for any single actor to own a large enough number of nodes to perform effective temporal analysis. [23]
Additionally, requiring that each Service Node stake an amount of Loki makes enforcement of good behaviour much easier. If a Service Node is acting poorly, then their stake will remain frozen and they will not receive any rewards for their staking period. This negative consequence (loss of opportunity cost) constitutes a programmatically self-policed punishment system which is run by the Service Nodes themselves in a system called ‘swarm flagging.’ [24]
Summary
The messenger landscape is full of emerging and established projects. It is important for consumers to critically analyse each messenger against key metadata, encryption, and scalability/attack resistant criteria. Although some messengers may provide strong encryption, they may not protect users’ metadata. As data breaches on centralised services continue, consumers are calling for more privacy centric applications. As the decentralised ecosystem grows, centralised services like WhatsApp, Signal and Telegram will have to compete against decentralised or federated alternatives. Ultimately, the service which maintains the highest privacy and best user experience is likely to be the winner of this battle.
REFERENCES
[1] “Why Metadata Matters | Electronic Frontier Foundation.” 7 Jun. 2013, https://www.eff.org/deeplinks/2013/06/why-metadata-matters. Accessed 10 Sep. 2018.
[2] “Former NSA boss: “We kill people based on metadata”” https://youtu.be/UdQiz0Vavmc?t=27s Accessed 10 Sep. 2018.
[3] “WhatsApp security and role of metadata in preserving privacy, https://arxiv.org/ftp/arxiv/papers/1701/1701.06817.pdf. Accessed 5 Jul. 2018.
[4] “Facebook scraped call, text message data for years … – Ars Technica.” 24 Mar. 2018, https://arstechnica.com/information-technology/2018/03/facebook-scraped-call-text-message-data-for-years-from-android-phones/. Accessed 5 Jul. 2018.
[5] “Battle of the Secure Messaging Apps: How Signal Beats WhatsApp.” https://theintercept.com/2016/06/22/battle-of-the-secure-messaging-apps-how-signal-beats-whatsapp/. Accessed 10 Sep. 2018.
[6] “Telegram Privacy Policy – Telegram Messenger.” https://telegram.org/privacy. Accessed 10 Sep. 2018.
[7] “Hushmail warns users over law enforcement backdoor • The Register.” 20 Nov. 2007, https://www.theregister.co.uk/2007/11/20/hushmail_update/. Accessed 10 Sep. 2018.
[8] “XMPP | XMPP Main.” https://xmpp.org/. Accessed 11 Sep. 2018.
[9] “GitHub – signalapp/libsignal-protocol-c: Signal Protocol C Library.” https://github.com/signalapp/libsignal-protocol-c. Accessed 11 Sep. 2018.
[10] “Open Whisper Systems – Wikipedia.” https://en.wikipedia.org/wiki/Open_Whisper_Systems. Accessed 11 Sep. 2018.
[11] “A Formal Security Analysis of the Signal Messaging Protocol.” 27 Oct. 2016, https://eprint.iacr.org/2016/1013.pdf. Accessed 11 Sep. 2018.
[12] “Signal >> Blog >> Open Whisper Systems partners with WhatsApp to ….” 18 Nov. 2014, https://signal.org/blog/whatsapp/. Accessed 12 Sep. 2018.
[13] “On the CCA (in)security of MTProto – Cryptology ePrint Archive.” https://eprint.iacr.org/2015/1177.pdf. Accessed 12 Sep. 2018.
[14] “On the CCA (in)security of MTProto – Cryptology ePrint Archive.” https://eprint.iacr.org/2015/1177.pdf. Accessed 12 Sep. 2018.
[15] “MTProto Mobile Protocol – Telegram APIs.” https://core.telegram.org/mtproto. Accessed 12 Sep. 2018.
[16] “Signal >> Blog >> Facebook Messenger deploys Signal Protocol for ….” 8 Jul. 2016, https://signal.org/blog/facebook-messenger/. Accessed 12 Sep. 2018.
[17] “otr-like offline messages · Issue #1432 · irungentoo/toxcore · GitHub.” https://github.com/irungentoo/toxcore/issues/1432. Accessed 13 Sep. 2018.
[18] “My Security Analysis of Bitmessage.” 20 May. 2013, https://bitmessage.org/forum/index.php?topic=1666.0. Accessed 13 Sep. 2018.
[19] “#16801 (Add OMEMO Encryption support to XMPP) – Pidgin.” 10 Feb. 2011, https://developer.pidgin.im/ticket/16801. Accessed 13 Sep. 2018.
[20] “GitHub – loki-project/loki-messenger: Signal — Private Messenger for ….” 24 Aug. 2018, https://github.com/loki-project/loki-messenger. Accessed 13 Sep. 2018.
[21] “Tox should be resilient to Sybil attack. · Issue #517 · TokTok/c-toxcore ….” https://github.com/TokTok/c-toxcore/issues/517. Accessed 14 Sep. 2018.
[22] “GitHub – irungentoo/toxcore: Tox Onion routing spec..” https://github.com/irungentoo/toxcore/blob/5ea703c844b12e86702c35b53b0b798fe5f86634/docs/Prevent_Tracking.txt Accessed 14 Sep. 2018.
[23] “Cryptoeconomics of the Loki network.” 11 Jul. 2018, https://loki.network/Cryptoeconomics. Accessed 14 Sep. 2018.
[24] “White Paper – Loki Network.” 13 Jul. 2018, https://loki.network/wp-content/uploads/2018/08/LokiWhitepaperV3_1.pdf. Accessed 14 Sep. 2018.