How Does Bleep Work?

Farid Fadaie —  September 17, 2014 — 23 Comments

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.

 

Bleep Peer Overview.jpg

 

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.

Farid Fadaie

Posts Twitter

Farid is the head of product for BitTorrent Bleep.
  • wagaf

    Farid,
    Bleep seems to be awesome.

    We are also working on a similar technology based on SIP and a custom DHT, that will be free software.

    What I’m reading here is very interesting, as it exactly describes the challenges we are also facing. Unlike you, we don’t have the power to change the mainline dht protocol to fit our needs :-)

    Is Bleep going to be opensource ? If you don’t plan to release the sources, your technology seems to be a bit pointless, because it’s gonna be difficult to trust. If you do plan to release the sources, it would be cool if there was some place to discuss/document the protocol, propose pull requests etc. before you release the first public version.

    • gubatron

      hi what is the name of your technology? what opensource license will you be chosing for it.

      At OpenBazaar.org we’re looking at different DHT implementations, so far our best pick (after Maidsafe’s but we couldn’t pick it because it was GPL) is libtorrent’s, and we might have to extend it to use it for our purposes.

      • wagaf

        Hi.
        Our project is OpenDHT – https://github.com/savoirfairelinux/opendht however it’s also GPLv3.
        It supports an optional public-key crypto layer and arbitrary value types.

      • http://tradle.io Gene @ Tradle.io

        @gubatron:disqus at Tradle ( see https://github.com/tradle ) we are using mainline DHT (the one that is used for trackerless torrents), and are extending it. Would love to exchange the experience and to collaborate. Recently noticed that Mike Hearn’s comment that OpenBazaar had problems with the DHT, along with BitSquare and Coinffeine. Are you guys using TomP2P like these guys?

  • Laurie Cooper

    Hi Farid, could you tell me how the Android app maintains availablility to
    incoming messages? Is the mechanism portable to other platforms, e.g. iOS?
    (example: incoming message notification, via push notification service)

    • http://bittorrent.com/ Farid Fadaie

      For the time being, Android works similarly to our desktop clients while in the background. We don’t use push notifications (it’s all local for the time being). iOS is a bit different in the sense that it only supports TCP when in the background. We will release more information on how the iOS version works once it’s available.

      • Laurie Cooper

        I think the mobile edge cases for voice are tricky. Maybe you just won’t support them, but I’d love to see a P2P voice client able to nicely switch access points or bearers during a call. Good luck – it’s really nice to see the efforts that people are taking on behalf of privacy. +1 for open source, btw – so long as nobody nicks your technology. How about independent audit? Is that a good compromise?

  • Paul Troon

    Bleep would not be appropriate for anonymous communication in a Wikileaks type scenario (anonymous source talking to a public journalist) because the nodes establish a direct connection using their IP addresses, or possibly a relay. Is my understanding correct?

    • http://bittorrent.com/ Farid Fadaie

      You are correct. This version doesn’t support onion routing for the moment. This is something that is on the roadmap though.

      Edit: An option (for now) is to use it over a VPN service to conceal the IP (not ideal).

      • Paul Troon

        Excellent that you have onion routing on the roadmap. I see a growing nexus of projects forming around DHT and public key encryption. I hope you have found a way to make these technologies something anyone can use.

        You just need to work Bitcoin in for a trifecta!

  • simon

    How does it protected metadata if it establishes a direct connection between two peers? An adversary watching src and dst networks collects the connection as “metadata”.

  • folex

    Can you please tell in more detail about obtaining IP from DHT having only user’s public key?
    Thanks in advance.

    • http://bittorrent.com/ Farid Fadaie
      • http://tradle.io Gene @ Tradle.io

        Farid, thx for the info. Could you confirm whether you are using BEP 44 to store and lookup the encrypted IP:port of each party based on the mutable store using public keys of each party?

        • http://bittorrent.com/ Farid Fadaie

          We are using BEP 44.

  • recapture

    Thx for your contribution for privacy communication!

    I really would like these features
    1) Use of multiple Identities (Like in BitMessage)
    2) Ability to hide IP (eg Tor)
    3) Protect Private Keys with password
    4) Possiblity to use your infrastructure in own applications (BleepCore availably as Open Source)

  • Sandeep Pathivada

    Is there an API/ Source code available for Bleep?

  • Ilias Alexopoulos

    Hi, Is it possible to use your SDK in an iOS app?

  • Arek

    How to remove email and/or phone number from your authentication server?

  • timkofu

    Does it work behind NAT?

  • Music never stops

    How decentralization it can reach? E.g. in China, the national firewall(Great Firewall) can easily block the bootstrap server if it’s hardcoded. Will you consider the same issue if ISP take actions?

  • https://www.aeyoun.com/ Daniel Aleksandersen

    When will it be open-sourced? Or at least offer specs for a compatible client to be written.

  • Giấc Mộng Trần Gian

    Bleep can not install using setup.exe for Windows , blocked by network download from the internet system of government. Please support help. Thank you.