3-bit Framework for Planning Secure Communications over Internet Protocols

A few days ago, I was talking with a friend and colleague about secure messengers. A lot of times, when a new boutique tool pops up on the market my first question “Why not use Signal?” (and then usually an explanation of how I differentiate secure messaging apps like Signal from messaging apps that are generally secure like WhatsApp).

In my opinion, “Why not Signal?” is the first litmus test any new internet based, secure, messaging system needs to pass in order to be considered for ops. Don’t get me wrong though: Signal is arguably the best secure messenger (probably tied with Threema), but there are no solutions, only tradeoffs.

There are several reasons you might not want to use Signal. The main one, in my opinion, is that Signal is relatively loud on the wire. To surveillance, censors, and network defenders alike Signal is glaring light in network traffic. You can’t crack it yet, but you still always know when its there. In places where the app is very popular and legal, that may not matter all too much. If it’s in legal gray space, or rare, it produces a signal in the noise for monitors (pun only partially intended).

These tradeoffs lead us into a discussion: How do you build a communications plan leveraging internet protocols (IP)?

Most good communications plans have three or four “lines” or options. Usually, we describe this a PACE plan: primary, alternate, contingency, and emergency lines of communication. Getting this far is easy, but filling it in with quality procedures and tools is harder…

1. Primary – Signal!

2. Alternate – Encrypted email?

3. Contingency – Um, email? Text message?

4. Emergency – Runner and/or smoke signal

To be able to make a good PACE plan, we need a way to match tools and procedures to the context we’re working in. One way to do that is to evaluate the threat actors and how they’ll interact with your operations—frequently called Operations Security or OPSEC—but in my personal opinion we’re generally lacking a framework for plugging our IP communication tools into that OPSEC picture.

To begin answering that question, I propose the “3-bit” internet protocol communications framework, or “3-bit framework” going forward. This framework is aimed at helping your team or organization select IP based tools for your PACE plans.

It has three criteria, each of which can be “yes” or “no”—1 or 0. Hence bits. These criteria provide broad, fast, and simple rules of thumb to help you understand the tradeoffs of your internet communications.

• Is it fast? – Does the tool allow you to quickly send short messages for rapid back and forth communication, or is it slow and longer form? Speed here is broadly referring to how quick the message is to make, send, receive, and read. E.g. is it Instant Messaging (fast), or email (slow)?

• Is it quiet? – How well does the tool blend in with the rest of the noise, how discrete is the tool, or how observable is it? You might think of this one as “how easy is it to tell that I’m using this tool?” judged in terms of adversary effort. E.g. Signal is easy to spot on the wire (loud) but a boutique secure tool tailored for your team requires statistical analysis to spot (quiet – and we’re assuming a lot about the tool being well built here!)

• Is it protected? – Are internal communications encrypted? If someone can snag my message off the wire or camp on a server relaying it, can they read it? E.g. Messages encrypted with end-to-end encryption where you control the keys (protected) vs email sent via stock Gmail (unprotected)

There’s probably more to say about applying these rules and building out decision making frameworks around them, for example: if it’s loud you probably want to be the same kind of loud as everyone else. However, I think these three are good enough to get the ball rolling.

3-bits gives us 8 combinations. For our given context, we need to pick the four best options given our needs. Slow, loud, and unprotected is probably always our least desirable choice because it takes a while, is obvious what it is, and is readable if intercepted. Fast, quiet, and protected is likely our most desirable choice because it’s quick, discrete, and encrypted if intercepted.

With this in mind, we can then build a quick PACE plan. Say for example we’re in a generic central Asian country where secure communications and messengers are allowed but generally spoken against and monitored—or at least readily blocked at the first sign of political turmoil. Because the 3-bit framework focuses on IP based communications, I’m not going to address the tradeoffs associated with device inspections or security, which are valid concerns in the real world (e.g. What do you do when simply having Signal installed at customs or a border checkpoint gets you in trouble?)

In this situation I’m going to assume that it’s best for me if my team uses cheap, fast, encrypted tools and only drops back to the crem de la crem when there’s pressure or unrest:

1. Primary – Signal; Fast, loud, protected (and free!)

2. Alternate – Specialized secure messenger; Fast, quiet, protected (probably $$$$$)

3. Contingency – Regular business email with encrypted messages; Slow, quiet, protected (reasoning that regular business email blends in and is frequently encrypted for legitimate business reasons)

4. Emergency – Regular business email; Slow, quiet, unprotected (and reasonably available as long as there’s internet)

Is it perfect? Nope, not at all. Is it good enough to get you started evaluating continuity of communications using internet tools? Probably. At a minimum, I think engaging in these three rules of thumb will guide you through discussing the grey areas.

What do you think? Is this heading in the right direction or missing the mark?