We unveiled Bleep a few weeks ago, and we have received nothing but love from our users. We’ve also had many great questions that we will be gradually answering in blog posts, our forums and other social channels. And today we’ve taken a step further, bringing Bleep to Open Alpha and adding clients for Mac and Android. There’s more to Bleep than we can fit in a single blog post, but here’s an overview of the big picture, including some high level technical details and answers to some of the questions around how Bleep works.
We have previously described the software architecture of Bleep here, and in this piece I’ll focus on Bleep’s P2P engine. Here is a list of its major functionalities:
Creating and authenticating the identity: When users install Bleep for the first time, the engine creates a new private key that can be used across multiple devices. That key is encrypted under the user account, so other local users cannot access it. Bleep registers all users as incognito initially, but in the cases where the user chooses to verify her identity via email or phone number, the engine asks our authentication server to send a token to make sure the user actually owns what she claims. A public key, derived from the private key, is then registered on our server, and it is only used when another user wants to find or add a friend via phone or email address. We also implemented a protocol to limit BitTorrent Inc.’s exposure to the graph of friends: This lookup is only done once when a user adds a contact. After that point, all lookups (i.e. actually finding the IP address of the contact) is done via our DHT. Incognito users do not register their public key on our server, but they do have to use a QR code or direct public keys to be added as contacts by somebody else.
Joining the DHT network: As we explained, Bleep uses a DHT that is similar to that of BitTorrent clients, and we’ll eventually use that same DHT for those clients in the near future. We have improved our DHT protocol to support many features needed to support Bleep, and we updated both uTorrent and BitTorrent mainline to support Bleep nodes. These improvements are necessary to guarantee our users’ privacy because simply being distributed doesn’t mean it’s secure– unlike what some P2P messaging applications wrongfully claim. A very important feature in Bleep is that the DHT traffic is disconnected from a user’s public key. It’s extremely difficult to figure out what public key corresponds to what IP if the attacker is not a friend of the victim. This makes it practically impossible to figure out who is talking to who at what time (i.e. metadata) even if the attacker has access to ISP-type information.
The Bleep engine talks to our bootstrap server to randomly obtain a few peers that are already participating in the DHT. However, this is only the case if the cache is empty and our node doesn’t have any node that it was previously connected to. Obtaining the initial peers to connect to can theoretically be done through other methods (or other bootstrap servers), and you can read more information on this subject on our forum.
It is important to mention that the number of nodes that are participating in the DHT directly affects users’ privacy. As you can imagine, if only few nodes are participating in the network, it’s easy to inject more nodes into that network and collect some information that might lead to the leakage of metadata. Bleep will eventually use the same DHT network as uTorrent, which has millions of active nodes already. In other words, using an already established network allows us to offer Bleep as a private messaging app to even our first few users, eliminating that chicken-and-egg problem.
We have already provided some information about how the DHT lookups work in this post.
Protecting metadata: Metadata, in the context of messaging, is defined as the data that describes who called/messaged whom at what time and for how long. Bleep (and its engine) is designed to not have a central repository of this metadata. Its architecture also makes it difficult for a skilled attacker with access to network traffic to gain access to targeted metadata.
Private Invitations: When a user adds someone to her contact list, an invitation is sent to that user that asks if he would allow her to see that he is online and able to receive messages. Once two users have each other’s public key, they can find each other’s IP and port on the DHT and establish a direct connection (or via a relay server, if the network condition doesn’t allow direct connections). This invitation is encrypted in a way that only the user who is meant to receive it can decrypt and read it.
Establishing a secure tunnel: Once a user accepts an invitation from a friend, the engine creates an encrypted tunnel over UDP between the two peers. The messages that are sent over the tunnel are all end-to-end encrypted. We also support forward secrecy, which essentially means that we change the encryption key every once in a while to make it even harder to decrypt the traffic — even if, by some miracle, the encryption key is compromised.
SIP/RTP interface: The engine offers a SIP interface (as described here) for the UI, so when the engine receives a SIP message from the SIP User Agent Client (UAC), it looks at its destination: the public key of the receiver. The engine creates or picks the right encrypted tunnel with the right contact and sends the SIP message, which will be received by another Bleep engine at the other end. We modify some SIP headers to make it seamless to the SIP agent, meaning that we theoretically support any messaging app that uses SIP. The engine also forwards all RTP traffic over the encrypted tunnel, which enables voice calls.
We designed our protocols to support private communications in a way that is unique to Bleep. There are other messaging apps that are peer-to-peer and have passionate fans. However, many of those apps have oversimplified privacy, equating it with being peer-to-peer. I hope that providing these details sheds some light on why Bleep is truly unique, and can be used as the backbone of future communications.
