Technical Article on our Security Updates

Diving In

This is a technical article that talks in detail about the security at Bridgefy, past and present. We explain what the Bridgefy security model was like before, and how it works now for the Bridgefy SDK 3.0 update. Click here to read the (non-technical) press release.

The original Bridgefy security model

Bridgefy’s original security model was based on asymmetric key encryption. Upon account activation, each Bridgefy device created a private/public key pair that was used to encrypt every message payload sent to the mesh. Both keys were stored locally in the Keychain but the public key was shared via a handshake mechanism when two users in the mesh wanted to start a conversation, so each user could store the other’s public key in a local database and use it to decrypt messages received from the sender in the future. This way, the local database grew whenever a new conversation began with a new user. This encryption model, however, was only used in the message payloads (the content that is being sent by the user), not the mesh frames that contained them. This meant that user IDs, control messages, and conversation metadata traveled through the mesh in cleartext.

In order to keep up with app re-installations, a mechanism was also put in place for a device to rotate their keys and send the updated public key to their previous contacts so they could continue to talk to each other. This was done via a message similar to the handshake that shares the initial keys. Specifically (using Alice and Bob), it sent a specific control message through the mesh that contained the instruction to “replace Alice’s public key with this new public key”. When Bob’s phone received that message, it would immediately update its local database and assume that every new message coming from Alice would be encrypted with that new public key.

Since all of these control messages traveled in cleartext, an attacker that passively listened to the traffic on the network could send a message to both Alice and Bob, making them believe that their keys had changed to the attacker’s public key, thus positioning itself in the middle of the conversation. This is what enabled Man-In-The-Middle and impersonation attacks. If this same attacker also started logging all traffic, they could determine which users participated in the mesh, which of them had conversations, etc. making way to historical proximity tracking and other kinds of intel gathering that could expose users during a protest or other sensitive scenarios.

We realized that there was no point in patching a design that was just barely appropriate for when Bridgefy was a small startup, and even less for the scale it has today and the growth we want to achieve in the future.

The new Bridgefy security model

To redesign our security, we decided to think outside the box and consider the possibility of rewriting our entire model from scratch, and build a new one that would get rid of all the issues right away. We searched for an existing solution that we could use that was already validated by the industry and security experts. We chose to work with the Signal Protocol.

The Signal Protocol is a very popular technology already in use by apps that have millions of users (Signal, WhatsApp, Facebook Messenger, etc.) and it’s a great way to achieve encryption in online communications. By integrating it into our SDK, we make our users feel more confident to use our product and most importantly, we will be delegating all the security heavy-lifting to the real experts, so as to focus more on the actual peer-to-peer mesh technology that makes our company and our products unique.

The first thing we did is delete all the code for the old security model from our SDK, while keeping only our core mesh communications framework. Next, we started integrating Signal into the stack by using the Java library for Android and the C library for iOS. We had to adjust some key implementation elements (without altering any of the underlying libraries) to make it work through the mesh network instead of bouncing off a server over the internet, so we made all key exchanges happen in direct line-of-sight communication only (instead of over the mesh). We only used the server for initial device activations. In just a few development sprints, the Signal Protocol was now encrypting every message payload between our users and even between platforms, with no issues.

We didn’t want to stop there, though, because although we knew Signal took care of the message payloads perfectly, we still needed to do something about all the mesh-control traffic happening in cleartext. To fix this, we decided to implement AES128 symmetric key encryption to protect every single message going through the mesh. Since we have our user-facing chat app and our clients also use our SDK to build a series of other apps, we decided it was best to make encryption happen application-wide, meaning each different app gets its own symmetric key and encrypts their traffic with it. Only activated users of each app can then get to read traffic in their mesh. This way, we mitigate the risk of a passive attacker collecting metadata from the traffic it sees on every Bridgefy mesh they could listen to. Although an authorized and activated app user could still try these attacks, there is a much greater chance of containing the risk now that we’ll have a limited number of users accessing the data.

The future of Bridgefy security

With the new security model in place, we are much more confident that users will feel safe and protected when using our chat app or any of our clients’ apps, regardless of the scenario they’re using it in. Users will now enjoy encryption and the greater sense of privacy this brings, especially when they engage in activities that may put their lives and their privacy at significant risk. 

In conclusion, these are the issues we solved:

• All messages will be encrypted
• A third person will no longer be able to impersonate any other user
• Man-in-the-middle attacks done by modifying stored keys will no longer be possible
• One-to-one messages sent over the mesh network will no longer contain the sender and receiver IDs in plain text
• A third person will no longer be able to use the server’s API to learn others’ usernames
• All payloads will be encrypted
• Historical proximity tracking will not be possible

We have no evidence, technological or from our users, that any of the pre-existing vulnerabilities were exploited or ever happened, but we can now safely say we’ve gotten rid of them.

Moving Forward

As the Bridgefy app user base grew, we started growing with it. Security is a never-ending process that we’re committed to, and our SDK customers and mobile app users can be confident we are constantly looking for ways to improve. Bridgefy will never stop efforts to keep our users safe.

Press Contact

Jorge Rios

Bridgefy CEO

contact@bridgefy.me

Access the Bridgefy press kit