Secure Messaging (SM) platforms are an increasingly vital tool for both individuals and entire organizations to protect themselves from a wide variety of threats. In this post, I’ll discuss what I believe to be an important, yet sometimes overlooked, distinction to be made between Managed SM (MSM) platforms and (the much more common) Unmanaged ones (USM). I’ll explain what distinguishes the two from each other and, more importantly, why I believe that those differences make Managed SMs fundamentally more suitable, secure, and powerful for protecting organizations’ communications than their unmanaged counterparts.
Unmanaged vs. Managed
Messaging Platforms: For the purpose of this post, a “message platform” is any distributed system which facilitates asynchronous real-time communication between its users. By “asynchronous,” I mean that when a user goes offline, all of their incoming messages are buffered by the system until they come online again. On the other hand, if both sender and receiver(s) are online at the same time, then the system provides a (near) real-time communication channel. Think: Wickr Messenger, Pro, and Enterprise, etc. Traditionally, we would expect such a platform to provide (at the very least) for text comms. Though more powerful and modern platforms may also enable other methods of communication such as file transfers, voice & video (even conference) calling, and screen sharing.
Secure Messaging: In restricting this discussion to “Secure” messaging platforms, I’m focusing my attention on those that provide (at the very least) for what has recently emerged as the industry gold standard in terms of protecting user’s communication; namely platforms that provide end-to-end security, Forward Security, and some variant of Post-Compromise Security (a.k.a. “future security,” “backwards security,” or “channel healing”). The exact nature of these security notions is an interesting (and rather extensive) topic in its own right but remains outside the scope of this blog post. Suffice it to say that a key aspect is their focus on protecting a user’s ongoing comms both from adversarial infrastructure in the distributed system as well as from past and future compromise of the users’ (and their contacts’) devices. Put simply, the goal is, above all, to empower and protect the end users.
It’s fair to say that this security goal does represent a fairly high bar. For example, it rules out such widely deployed platforms as Slack, Google Hangouts, Facebook Messenger, Threema, PGP Encrypted Email, S/MIME, and many others. However, given the growing number, flexibility, and availability of platforms that do meet this security goal, I think it is quite reasonable to demand such a high standard from our tools.
Unmanaged SM: Put simply, an unmanaged SM is a single global network managed centrally by a single service provider; e.g. Wickr Messenger. Intuitively, in a USM there are only two types of non-adversarial actors; users (which make up the end-points in the communication network) and the service provider, whose most important job is to maintain the infrastructure (and, usually, the code base/protocol) upon which the distributed system relies.
Managed SM: In a Managed SM platform, there is a third type of actor; namely, the administrator. Rather than being a single global network like a USM, an MSM is really a collection of distinct sub-networks. Each subnet belongs to, and is managed by, its own admin, while each user belongs to a particular home subnet. In other words, Alice@Net1 is a different user than Alice@Net2. In a federated MSM, users on different subnets can, in general, still communicate with each other across subnet boundaries.
The role of the service provider in an MSM is diminished compared to that in a USM. They are now primarily responsible only for maintaining the system’s specification and code base, providing customer support, and (in the federated case) maintaining the infrastructure required to enable federation.
The real difference between an MSM and a USM is the introduction of administrators, who are in charge of managing their subnets. Which precise capabilities and responsibilities this entails will vary from platform to platform. However, an almost universal feature is that admins have control over creating and deleting user accounts on their subnet. More generally, the role of the admin is to set security policies across their subnet. For example, in AWS Wickr (which is a federated MSM), an admin can determine things like:
- Network Segmentation; that is, the admin controls with which accounts any given user is able to communicate. For example, the admin can decide which types of users can communicate with other specific types. Similarly, the admin decides for each user (type), which other subnets are available via federation.
- The admin also decides what the permitted minimum and maximum Time-To-Live and Burn-On-Read can be for each user (type).
- The admin controls the home network’s authentications policy. E.g. the admin may opt to integrate an external single-sign-on system.
- The admin determines how the subnet’s infrastructure should be deployed. E.g. for ease of use, the infrastructure can be hosted in the Amazon cloud. Alternatively, it can be self-hosted a.k.a. “On Prem,” which affords the admin greater control and (potentially) greater security.
The key point here is that all of this is decided upon by the admin and is specific to the subnet under their control. In contrast, in a USM, this type of control (if at all possible) is almost exclusively the purview of the service provider and applies globally to all users on the platform.
It is important to note that, despite the admin’s relative power, the security model for the actual comms transported by an MSM remains very user-oriented, just as in a USM. For example, even a rogue admin should not have the capability of reading any users’ messages, nor modifying/forging messages on their behalf.
Messaging for Organizations
With these differences in mind, I think it’s safe to say that these fundamental differences between USMs and MSMs will matter to almost any user deciding on how to protect their communication. In a nutshell, this all stems from the fact that these two classes of platform are designed to reflect two quite different kinds of power and control structures in their user base.
Reflecting Real-World Power Structures and Relationships in Messaging Platforms.
On the one hand, USMs focus exclusively on the individual that exists, to some extent, in a vacuum. Thus, they model the relationship between any pair of individuals in the system as being (a priori) equivalent to the relationship between any other pair of individuals. When I join Wickr Messenger, I can add any other Wickr Messenger user as a contact and start chatting to them. We all have the same powers, functionality, and security needs in a USM. For example, in a USM it is up to me, and me alone, when to create and delete my accounts.
On the other hand, MSMs make explicit the existence of a more complex power structure, in that they allow users to be collected into related groups. After all, even before we ever actually talk to each other, my relationship with my coworker is quite different from a relationship with a total stranger who just so happens to use the same SM platform as I do. Moreover, MSMs account for some amount of hierarchy in the structures they model. A user is subject to some control by an admin just as an employee might be subject to the decisions of their boss.
What this all boils down to is that when people decide on which SM to use, it is important for them to consider the difference between USMs and MSMs in order to understand which type of system will best fit their needs. And fundamental to that choice is to consider which type of real-world power structures and control structures they want to have reflected in their communication tools.
Why Managed Messaging Makes Sense for Almost Any Organization.
The more people communicate within the context of some centralized, hierarchical, and/or closed group, the more appropriate an MSM becomes. Here are just a few examples of how natural power and relationship structures in an organization are reflected in an MSM.
- Membership: In almost all organizations (be they government, business, NGOs, etc.), membership of a given individual is not (exclusively) up to that individual. Rather, it is decided upon by the organization itself. How should this be reflected in the organization’s communication system? Suppose, for example, a company ends its employment of an employee. Then it is very much in the interest of the company to have the capability to immediately and unilaterally (i.e. at their own discretion) remove the former employee from any and all company internal communications channels. This need is directly reflected by the capability of an MSM admin to de-provision user accounts.
- Controlled Information Flows: Another example of structures arising naturally in most organizations (that should be reflected in the secure messaging platform) are information boundaries. Typically, membership in an organization confers new information access and communication privileges upon the member compared to non-members. For example, employees could be privy to secret business intel which they need to discuss with each other that should not leak to non-employees. An MSM can be a useful tool for reflecting and enforcing such natural boundaries via network segmentation. For example, users that have no legitimate need to communicate with external individuals can simply have that capability removed by the admin. In fact, beyond protecting against adversaries, I think the biggest concrete benefit of network segmentation of comms is the reduction of the risk of unintentional information leakage. For example, with appropriate segmentation in place, there is no more risk of, say, mistakenly CC’ing outside parties on sensitive comms or sending messages to the wrong “Mike”. More generally, having a trained admin set security policy rather than leaving such choices up to each user helps avoid unintentional security lapses due to poor configuration by untrained users. It is as unreasonable to expect every last member of your organization to have sufficient security knowledge to make policy decisions correctly as it is to hope that a one-size-fits-all security policy decided upon by a global service provider of a USM will be the right choice for your particular organization.
- Private Infrastructure: Finally, for organizations with extremely sensitive comms, it can be worthwhile to invest in a communication system which allows explicitly routing all internal comms exclusively via an organization-owned and controlled infrastructure. For example, this can be particularly useful in defending against government surveillance and traffic analysis, as well as to limit exposure to upstream ISPs and the SM platform’s service provider. Here too, MSMs (at least those with On Prem. capabilities) will be of particular interest to achieve these security goals.
These are just a few examples of why managed SMs, like AWS Wickr and Wickr Enterprise, are more aligned with the needs of organizations than unmanaged ones like Wickr ME. And this list goes on: maintaining a unified and centrally managed security policy, implementing an organization-wide compliance policy, integrating with the organization’s other IT infrastructure, customizing the UI of the messaging apps to fit the organization branding, etc. With this in mind, I think it’s fair to say that Managed and Unmanaged messaging platforms are truly different beasts. As such, as a user of secure messaging it is worth it to spend a moment reflecting on the differences in order to choose the best tool for our communication needs.