Your adversary: Who’s a hacker, anyway?

It’s time to talk about a fundamental concept underpinning the entire field of cybersecurity: your adversary. Now that we’ve completed our implementation of the Session Protocol, we want to take a moment to talk about threat modelling and security design. Without adversaries, there wouldn’t really be any need for cryptography or anonymity systems. The concept of an adversary is quite simple — adversaries are any two parties who, for whatever reason, have opposing interests. In this article we’ll assume that one of these parties is you — someone using Session. 

Adversary, adversary, what do you want with me?

There are a number of different groups who may present themselves as adversaries to Session users.

Hackers — generally individuals or small groups; maybe they’re just trying to break the system to show they can; they might not even be interested in you specifically, just creating chaos and poking holes. Nonetheless, if hackers are trying to penetrate a system you’re using — they’re your adversary. 

Criminals — normally financially motivated, a criminal adversary generally want to gain information they can turn into dollars in their pocket. 

Vigilantes — also commonly referred to as hacktivists, these kinds of adversaries are similar to hackers, but with the added twist of a political or philosophical message they hope to convey by attacking you or the system you’re using. 

Last but certainly not least, nation-states — probably the most competent, well-resourced, and imposing of the adversaries we’re considering here, this category includes things like military groups and intelligence agencies. Nation-state adversaries can be expected to conduct attacks intended to further the goals of the state — whatever those goals may be. 

Our systems are down! Adversary attack!

It’s important to consider the kinds of things that adversaries can actually (try to) do to you or the system you’re using. Ultimately, an adversary can try to compromise any combination of the privacy, integrity, or availability of a system. 

If the privacy of the system is compromised, that means some information about the system, its users, or its operation, is being exposed to the adversary. In the case of a messaging app, this might be things like your identity, the contents of your messages, the people you are talking to, or when you’re talking to them. 

On the other hand, compromising the integrity of a system means the adversary can somehow alter or otherwise affect the system. For messaging apps, this might mean editing messages, making messages look like they were sent by someone else, or sending completely fake messages. 

An availability compromise is exactly what it sounds like — an attack that makes a service unavailable. This might mean preventing messages from being sent or received, blocking logins to the service, or stopping you from downloading the application at all. 

Cyber shields back up to 100%

So, attacks on privacy, integrity, and availability are the main ways a pesky attacker might attempt to compromise a system, and we know some of the motivations attackers might have, but what does an attack actually look like? 

The exact kind of attack always depends on the kind of system we are dealing — but let’s consider a few examples where Alice (A) wants to send a message to Bob (B). 

Example 1: Central server, transit encryption only

In this example, the privacy, integrity, and accessibility of the system are completely dependent on the server (S). The server can freely store, read, share, alter, or just choose not to deliver the message Alice is trying to send to Bob. Let’s have a look at what a bad actor could do to compromise Alice and Bob’s communications in this very basic scenario.

Privacy: Alice’s message is not private. The server operator can read it themselves or share it with whoever they like. They know Alice sent the message, what Alice said, and that they’re saying it to Bob.

Integrity: The integrity of Alice’s message cannot be verified by Bob. The server operator could alter the message however they like before delivering it to Bob.

Availability: The availability of the message is not guaranteed. Alice may not be able to reach the server, the server can choose not to  deliver the message to Bob, or something may prevent the server from delivering the message.

But, what if Alice end-to-end encrypted their message to Bob?

Example 2: Central server, end-to-end encryption

Our system now has some privacy — the server can’t freely read, share, or alter the contents of the message without Bob and Alice realising. However, the server still knows who Alice is, knows who Bob is, and knows exactly when they are messaging. On top of that, the server can decide (or be forced) to stop delivering messages at any time. So what could bad actors do to compromise Alice and Bob’s communications with end-to-end encryption in the mix?

Privacy: The server no longer knows what Alice is saying, however they still know that Alice is speaking to Bob, including when they exchange messages.

Integrity: The server can’t alter the message Alice sends Bob — if it tries to, Bob will be able to tell the message was signed by someone other than Alice. That is, assuming the server has given you and Bob the correct information to encrypt messages for each other. Read our article about trust on first use to understand more about this problem!

Availability: In terms of availability, we still have all the same problems from example 1.

Now, one of Session’s hallmark features is using onion requests over a decentralised network — what if we add that into the equation? 

Example 3: Decentralised network, onion routing

Looking much better. There’s no more central server, and the message is encrypted multiple times for each node it travels through, meaning the system has more privacy — all N₁ knows is that Alice is sending a message somewhere, all N₂ knows is that someone is sending a message somewhere, and all N₃ knows is someone is sending a message to Bob. 

All these layers of protection mean that it’s also much harder to compromise the accessibility of this system in a targeted way. Even if N₁ decides that they don’t want to propagate Alice’s message (or is forced not to propagate the message), Alice can just as easily build a new path using a different node in the network. Problem solved — all thanks to the epic power of decentralisation. Let’s take a look at exactly what bad actors could do to compromise Alice and Bob’s communications here:

Privacy: Just like before, the contents of Alice’s messages are completely private. On top of that, none of the nodes actually know that Alice is talking to Bob at all. And in the case of Session, because it doesn’t use personal identifiers (like phone numbers), there isn’t really a good way to know who Alice or Bob truly are at all.

Integrity: Alice’s messages cannot be altered, and if any of the nodes try to alter or corrupt the message, Bob will know. 

Availability: Because the network is decentralised, no single node failing or misbehaving can prevent the delivery of a message. If one node is down or can’t forward the message, you can simply use a different node in the network. 

Thanks to its combination of decentralisation, onion routing, end-to-end encryption, and anonymous sign-up, Session brings you a messaging system that is extremely resilient in terms of privacy, integrity, and accessibility.  

Different designs depending on your adversary

It’s pretty much impossible for one system to be completely bullet-proof. With Session, we’ve taken every measure we can to try and create as secure of a system as possible without having to resort to one-time pads and smoke signals, but it’s always important to consider what kinds of threats you want to protect against when you are picking something as crucial as a messaging app. 

Depending on where you are, who you are, and what you’re doing — different systems and strategies might be required. For example, if you’re somewhere that is often subjected to internet shutdowns, things like mesh networking might be relevant — but if you’re sipping lattes in Sacramento, a mesh-based solution might be more frustrating than helpful. We all live and work in very different situations, and those situations come with very different security and privacy requirements. It’s important to consider what your needs are, so you can make the best choices for you.