Joël Alwen, Cryptographer @ Wickr
A recent work by researchers at Ruhr-University Bochum (Germany) has kicked off an important discussion about the security of group conversations in several messaging tools. Of all the security issues covered in the paper perhaps the most impactful and certainly the most discussed questions involve attackers adding themselves (or other users) to group chats despite not actually having been invited by authorized group members (i.e. group administrator). The details for how these issues can be exploited vary between analyzed apps as a result of various platform design and business decisions.
In light of the attention focused on how the security of group messaging can be implemented better, here is how Wickr fares against these types of attacks. In a nutshell, none of these attacks (nor anything similar) will work against Wickr. Here is why.
Wickr supports two types of group messaging forums called Rooms and Conversations. Put simply, both allow multiple participants to talk with each other. For the purpose of this post, the main difference between the two is that in a Room, there is a special subset of participants called the administrators while in a Conversation every participant is also an admin. Here is what they can and cannot do:
- Only admins may invite new participants to the group chat — whether Conversation or Room;
- In a Room, an admin may remove any participant from the room (including other admins);
- In a Conversation, only participants may remove themselves from the room (by leaving the room).
Here is how Wickr implements these groups, and why the attacks described in the paper do not work against Wickr.
From 1:1 to Groups
For starters, let’s take a quick look at how Wickr establish the cryptographic keys for encrypting and authenticating group chat related content. *The method is the same for both types of groups.
From the start, the Wickr protocol was designed with group communications among multiple users with multiple devices in mind. As such, an important difference between our implementation and other platforms examined by the Bochum team is that Wickr’s method for establishing fresh ephemeral, secret and authenticated key material for each new message in the 1:1 case actually scales very well to the 1:n case. In fact, the 1:1 setting is really just a straightforward special case of the more general 1:n setting on Wickr.
This focus on groups, has motivated us to use the following protocol:
- To send a message, Alice first builds the list R of all n recipient devices.
- She then encrypts and authenticates her message with a freshly sampled 256-bit key k.
- To convey this key to each recipient, she also runs her half of an ECDH key agreement protocol with each device in R.
- This results in n ephemeral, secret and authenticated keys which she uses to encrypt n copies of k.
- These n cipher texts are bundled together with her encrypted message into a single packet which is signed by Alice and sent off to the Wickr server.
- Whenever the server receives such a packet, it immediately adds the packet to the download queues of each devices in R.
For more details, check out the White Paper “Wickr’s Messaging Protocol”.
Group Membership Management
So what about groups? Well, suppose Bob wants to make a change to the state of a group (e.g. by adding a user). He does this by preparing a special group management message in exactly the same way a normal message is put together. The resulting packet is sent to the Wickr server which then puts it in the download queue of each recipient.
Whenever Alice fetches a new packet (nominally sent by Bob) from her queue, she first verifies that it in fact was sent by Bob. Technically, she checks that the digital signature in the packet matches the long term keys she has on file for Bob.
If the check fails, she drops and ignores the packet. Otherwise, she completes her half of the relevant ECDH, decrypts the key k and finally decrypts the message. If the message turns out to be a group management message, she then checks whether Bob has the permissions in the group to make the changes he is proposing. If not, she drops and ignores the message. Otherwise she goes ahead and modifies her view of the group state according to Bob’s proposal.
So About the Discovered Attacks…
The most egregious of the attacks uncovered by the Bochum team allows a corrupt server to make unsanctioned modifications to a group membership roster. As described above, Wickr is not prone to such attack simply because the Wickr server on its own is given no such authority. Indeed, for a group management message to be accepted by Alice, it must (amongst other things) be signed using keys of a group member. However, the Wickr server is not privy to any such key material and so it could not produce such a message even if it wanted/was compelled to.
The second attack method to add an unauthorized user to a group described in the paper won’t work against Wickr either. In that scenario, an attacker sends a group management message to Alice despite not being an administrator of the group. If Alice happened to already have the attacker’s long term keys in her contact list (and the attacker was able to produce the correct Group ID for that group), then Alice would accept the proposed changes to the group state. In Wickr, such a message will be rejected by Alice as she will end up dropping the packet as soon as the permissions check fails.
These observations hold regardless of whether we are talking about Rooms or Conversations. The reason why is that the only difference between how they are handled lies in the rules governing the permission check performed by Alice. In either case, Alice will only accept legitimate management messages that pass the relevant checks.