I saw an article describing the use of decentralized communication with Bluetooth used by protestors in Hong Kong. (Wakefield, 2019) The decentralization of communication relates to the ideas in CSCC46 of network robustness and the connectedness of graphs.
In the protests, many protestors were using the messaging app Telegram to coordinate protests, and to communicate in a large group. However, this had a few issues. Telegram, as a cloud-based messaging app uses a centralized network model, where communications between devices must travel through their server. (Telegram, n.d.) For example, for ‘Alice’ to contact ‘Bob’, through Telegram, Alice sends a message from her phone, to Telegram’s server, who sends it to Bob. However, this presents a few issues. First, in a large protest with many people, cell towers can quickly become overloaded, making it difficult to send messages. Another point of failure is that if Telegram’s server encounters issues, then a message cannot be sent, this happened in June 2019, when Telegram’s servers faced a DDOS attack. (Shieber, 2019)
Due to these risks, protestors started using apps such as Bridgefy and Firechat, which use peer-to-peer communication through Bluetooth to communicate. (Wakefield, 2019) In the context of a protest, it seems feasible. In a crowd, people are physically close together, so Bluetooth’s short 100m range is not an issue. (Wakefield, 2019) If a cell tower is overloaded, the users in that immediate area can still communicate with other users in the immediate area. If there are many users in the area using the app, they all assist in distributing messages to each other.
In the context of CSCC46, if we consider devices and equipment such as phones and cell towers to be nodes, and a connection between them to be edges, this decentralized communication allows for greater network robustness, as the graph does not quickly become disconnected when one important node (the cell tower) is removed. The distance between nodes can also be shorter, as the minimum distance is now phone directly to phone, instead of travelling through a cell tower and a server. This allows for more stable communication in tightly packed local areas, as long as there are enough nodes.
Decentralized communication through Bluetooth allows for a more robust network in small areas. This has applications outside of protests in any event with large crowds which may overload cell towers, such as a baseball game, a concert, or a natural disaster. (Bridgefy, n.d.) Using our knowledge of CSCC46 helps us analyze why some forms of communication can be more stable than others in certain situations.
References:
Bridgefy. (n.d.). Bridgefy. Retrieved from Bridgefy: https://bridgefy.me/
Shieber, J. (2019, June 13). Telegram faces DDoS attack in China… again | TechCrunch. Retrieved from TechCrunch: https://techcrunch.com/2019/06/12/telegram-faces-ddos-attack-in-china-again/
Telegram. (n.d.). Telegram Messenger. Retrieved from Telegram: https://telegram.org/
Wakefield, J. (2019, September 3). Hong Kong protesters using Bluetooth Bridgefy app – BBC news. Retrieved from BBC News: https://www.bbc.com/news/technology-49565587
Using a decentralized network indeed ease the traffic of all the messages, however, this network is easier to be hacked than a central server and therefore leak critical information that is only available to a certain group of people. For example, if Bob is a decentralized network and plans to arrange a protest, he will send information of the protest to protester A (who is trusted by Bob) and protester A send to protester B (who is trusted by protester A) and keep sending to the remaining protesters. However, let’s say one of the protest’s accounts got hacked, then the hacker can interrupt the information of the protest and send a fake message to other protesters. Since there is a Web of Trust in a decentralized network, the remaining protester will blindly believe that the fake message is trustworthy and cause them to show up in the wrong place or even resulting in them being arrested by the police. Thus I am curious how applications such as Bridgefy can prevent this kind of attack from happening.
In terms of security, Bridgefy doesn’t do much different compared to other communications apps, the purpose of Bridgefy is to ensure availability of communications without the use of a central source such as a cell tower.
For communication, Bridgefy uses a Decentralized model (the mesh network).
But for security, it seems like they use a Centralized model, similar to other messaging platforms, such as WhatsApp
Bridgefy actually has two main communication modes:
1. Broadcast to everyone (not encrypted, no security)
2. Direct message to someone specific that you already know (E2E encrypted)
For broadcast messages: No security!
To be available to everyone, such as the use case of a natural disaster, where users may have no internet access, and may not have had access prior to the disaster, broadcast has no security everything is open. Since the broadcaster doesn’t need to verify their account, anyone can broadcast, including those attempting to spread misinformation, or just spamming it with garbage. It’d be like yelling in a crowd to whoever is close by, there is no one in charge of this kind of this communication, so you would probably be a bit more cautious acting on information received in this way, since there are no authorities in broadcast, you shouldn’t blindly trust everything said here. Broadcast doesn’t try to establish a web of trust, users should view everything said on here with some skepticism, since anyone can say anything. Verified users will have their phone numbers visible, but you would only know if they are an authority if you already knew their number in advance, which can’t be guaranteed.
For direct messaging:
For direct messaging you need to setup an account with Bridgefy beforehand (when you have internet access), and verify your account online with Bridgefy’s servers. The catch is that you also can only direct message a contact that you have added in the app, and this contact must have also added you as a contact. The contacts need to add each other ahead of time, when they have internet access, and have verified their accounts on Bridgefy’s servers.
Why this limitation?
For direct messaging, a spokesperson for Bridgefy said they use end-to-end encryption with RSA. (Forbes link)
Since RSA is asymmetric, for asymmetric encryption to work, the key exchange needs to be done securely. Since Bridgefy makes you verify your account first before allowing direct messaging, it seems like they use a centralized trust model for direct messages – Bridgefy’s servers allow the transfer of public keys.
This is likely why direct messaging only works for contacts that have both added each other in advance on Bridgefy, the sender needs to know the recipient’s public key (retrieved beforehand from Bridgefy’s server) to encrypt the message, and the recipient needs to use their own private key to decrypt the message. Using public/private key pairs prevents anyone else in the mesh network from reading (or modifying in a meaningful way) direct messages that they may be relaying, since they won’t have the recipient’s private key.
Good summary of Bridgefy:
https://medium.com/bridgefy/how-to-use-the-bridgefy-offline-messaging-app-b4799af7649b
Spokesperson comment about RSA:
https://www.forbes.com/sites/thomasbrewster/2019/09/04/hong-kong-protesters-are-using-this-mesh-messaging-app–but-should-they-trust-it/#598d27f518b4