Secure Group Communications for incident response and operational communities

ABOUT ENISA

The European Union Agency for Cybersecurity (ENISA) has been working to make Europe cyber secure since 2004. ENISA works with the EU, its member states, the private sector and Europe’s citizens to develop advice and recommendations on good practice in information security. It assists EU member states in implementing relevant EU legislation and works to improve the resilience of Europe’s critical information infrastructure and networks. ENISA seeks to enhance existing expertise in EU member states by supporting the development of crossborder communities committed to improving network and information security throughout the EU. Since 2019, it has been drawing up cybersecurity certification schemes. More information about ENISA and its work can be found at www.enisa.europa.eu.

CONTACT

For contacting the authors please use CSIRT-Relations@enisa.europa.eu For media enquiries about this paper, please use press@enisa.europa.eu.

LEGAL NOTICE

Notice must be taken that this publication represents the views and interpretations of ENISA, following the consultation of experts in this area. This publication should not be construed to be a legal action of ENISA or the ENISA bodies unless adopted pursuant to the Regulation (EU) No 526/2013. This publication does not necessarily represent state-of the-art and ENISA may update it from time to time.

Third-party sources are quoted as appropriate. ENISA is not responsible for the content of the external sources including external websites referenced in this publication.

This publication is intended for information purposes only. It must be accessible free of charge. Neither ENISA nor any person acting on its behalf is responsible for the use that might be made of the information contained in this publication.

COPYRIGHT NOTICE

© European Union Agency for Cybersecurity (ENISA), 2019 Reproduction is authorised provided the source is acknowledged.

For any use or reproduction of photos or other material that is not under the copyright ENISA, permission must be sought directly from the copyright holders.

Catalogue number: TP-03-19-540-EN-N, ISBN: 978-92-9204-303-2, DOI: 10.2824/062571

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES

CONTENTS

1. INTRODUCTION 4

1.1 PREVIOUS ENISA WORK ON THE TOPIC 5

1.2 METHODOLOGY 5

1.3 CRITERIA 6

2. OVERVIEW OF SOLUTIONS 9

2.1 SOLUTIONS NOT COVERED 9

2.2 INDICATORS AND ABBREVIATIONS 9

2.3 FIRST STEP 9

2.3.1 Open Messaging Specifications 9 2.3.2 Central Messaging 10 2.3.3 Messenger 11 2.3.4 Encrypted Email Mailing lists 12 2.3.5 Email Encryption Gateways 13

2.4 SECOND STEP 13

2.4.1 Mailing Lists 14 2.4.2 Matrix 15 2.4.3 XMPP 16

3. RELEVANT RECENT IDEAS 17

3.1 PRACTICAL ENCRYPTED MAILING LISTS 17

3.2 GROUP WEB KEY DIRECTORY FOR OPENPGP 17

3.3 RESILIENT COMMUNICATION 17

3.4 INTERESTING RELATED RECENT CRYPTOGRAPHIC RESEARCH 18

4. BIBLIOGRAPHY 19 5. GLOSSARY AND ACRONYMS 20 SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES

EXECUTIVE SUMMARY

As of July 2019 there are more than 414 incident response teams in Europe . These teams work together to respond to cyber-attacks and need to use secure and reliable communication channels to share threat and incident information while protecting European citizens and businesses. With a number of cyber security incidents and an attack surface that increase every day, spanning from large infrastructures to the end users, there is the need to improve operational cooperation, preparedness and information exchange by promoting the use of complete and scalable secure communication solutions.

This document provides an overview of available solutions best known at the time of writing. Intentionally, it does not provide a conclusion that can be directly applied to all communities. However, it can serve as a starting point for a tailored evaluation.

The process works by first identifying available solutions best known at the time of writing of this report. The initial requirements were defined based on the use case of a group of incident response teams forming a decentralised community. The document provides and prioritizes criteria for the selection of available solutions for this scenario. The first round of chosen criteria were: secure group communication, archive, attachments, open specification, license, availability for all operating systems and maturity. It is important to underline that this report does not address the quality of encryption. After listing products along these criteria in a first round, available solutions scoring in all criteria are descripted. The secondary selection criteria used were: hosting, add-on compatibility, compatibility with existing infrastructure, backward compatibility and forward secrecy.

During the project, it has been found that various solutions best known at the time of writing did not fit all criteria either because, at the time of writing, they do not provide the required end-toend encryption, they did not provide mature multi-platform support, they were not offering a secure group chat or they were missing an open specification. On closer examination of the various solutions and their evaluation with encrypted mailing lists, it became clear that having a message archive as well as forward secrecy is a challenge. Due to forward secrecy, in many end-to-end encrypted solutions, only existing members can access the full history, but newly added members can only access from the point when they have been added.

Based on this, a parallel setup of a chat solution and an encrypted mailing list seems the most fitting to cater both synchronous and asynchronous communication needs for the scenario of group of incident response teams forming a decentralised community considered in this document.

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES

1. INTRODUCTION

Computer Security Incident Response Teams (CSIRTs) around the world deal with security events, such as malware outbreaks or vulnerability discoveries, etc. Incident response teams 2 3 4 are often organized in communities such as CSIRTs Network , TF-CSIRT , FIRST and other regional, sub regional or sectorial communities. Typical information exchanged among teams include threat intelligence, indicators of compromise (IoCs), malware samples and details about relevant incidents.

To facilitate information exchange among teams and improve reaction time to security incidents, This document tailored communication solutions are required. These teams are often organized in groups

serves as a

forming a decentral community that needs to cooperate and have secure and reliable

starting point for

communication channels to share information.

other incident response

The type of work and decentralized organisational structure of these communities impose tough requirements on the chosen communication solutions. First and foremost, solutions must communities to implement end-to-end encryption protocols for group messaging because highly sensitive conduct their information is exchanged. Thus, to reduce the amount of required trust in providers, solutions own evaluation must implement end-to-end encryption with verifiable keys defined in an open specification. To

and see how

allow archive of previous incidents lesson learnt, these solutions must provide a way to archive

these tools can

conversations and storage of attachments. Finally, on premise hosting and the selection of free

fit their sizes and

software allows independent operation and extensibility by the managing member of the community. needs.

Recent cryptographic reports such as the ECRYPT 2018” Algorithms, Key Size and Protocols Report” focuses on fundamental algorithms and protocols. Previous ENISA work on the topic was 2014 “Algorithms, key sizes and parameters report” and “Study on cryptographic 7 8 protocols” Other projects, such as “Applied Crypto Hardening: bettercrypto.org” provide goodpractice configurations for server administrators. In contrast, this study focuses on real-world communication solutions for CSIRTs and it does not address the quality of encryption.

This project on secure communication solutions has been conducted with a specific community and scenario in mind. This community could be a group of incident response teams forming a decentral community or an operational community grouped in an information sharing and analysis centre (ISAC). This model community already have in place chat, encrypted email and a shared secure space on the web, where to share information, like many existent communities. The idea is to move from a set of tools and systems, created over time, to a more scalable and integrated set of tools. On this baseline, the document follows a methodology for evaluating best-known solutions at the time of writing. It explicitly does not provide results that can be automatically re-used for different communities or use case. However, it serves as a starting

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES

point for other operational communities to conduct their own evaluation and see how these tools could fit their sizes and needs.

1.1 PREVIOUS ENISA WORK ON THE TOPIC

Since 2005, ENISA has been supporting Member States and CSIRT communities in EU to build and advance their incident response capabilities with handbooks, online & onsite trainings and dedicated projects. ENISA’s portfolio of work is related to setting up, running or developing capabilities of Computer Security Incident Response Teams (CSIRTs). The goal is to define minimum common baseline practices across the EU to improve operational cooperation, preparedness and information exchange for the next generation of cyber-attacks. More info can be found at https://www.enisa.europa.eu/csirt-services

Relevant ENISA efforts are:

 Reference Security Incident Taxonomy Working Group  Exploring the opportunities and limitations of current Threat Intelligence Platforms  Actionable Information for Security Incident Response  Detect Share Protect - Solutions for Improving Threat Data Exchange  Proactive Detection of Network Security Incidents – Honeypots  Proactive Detection of Network Security Incidents – Data feeds – internal and external

Moreover, the following relevant trainings are also available for free download:

 Proactive incident detection: handbook and VM  Automation in incident handling: handbook and VM  Honeypots: handbook and VM  Presenting, correlating and filtering various feeds: handbook and 2 VMs

1.2 METHODOLOGY

This document presents an example of how to select suitable candidates from a large number of best known software solutions and see how they can fit the needs of the members of a specific incident response community. The key is to find many potential solutions and limit them quickly step by step.

One task is to find out about type of users to aim for. This means asking a number of questions, such as:

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES

 What communication workflows are already well established?  What solutions are in use? What experience background do people have with them?  What type of support the different users provide? For example hosting, budget or training?  How important are the different aspects of the solutions? For example in communication speed or attachment size?

The second task is to find and weight potential solutions. For this, a variant of David A. Wheeler's IRCA approach was used where IRCA stands for

 Identify candidates Read existing reviews The main goal of   Compare the leading programs' basic attributes to your needs this exercise is  Analyze the top candidates in more depth. to find solutions

capable of

In the initial discovery phase, overview articles, search engines and Wikipedia entries were

allowing secure

used to find candidates . In the review phase, credible third party descriptions or assessments

communications

from experts in the area were used to get an overview of the claimed properties of a solution.

among incident

The first list of findings was reviewed in the light of the particular use case and refined.

response and 1.3 CRITERIA operational

In this section, the evaluation criteria are presented. As discussed in the introduction, it is communities. important to note that this study’s focus is on incident response teams forming a decentralised community. Other scenarios may require different criteria and will most probably lead to a different prioritization and outcome.

The following seven criteria have been identified as important:

 Secure Group Communication: The main goal of this evaluation is to find solutions capable of allowing secure communications among teams dealing with security incidents, such as CSIRTs. Thus, secure group communication is the main requirement for all discussed solutions. One specific requirement in this study is that the intended solution provides communication groups with a certain level of security, authenticated members and a key management where users are associated to cryptographic identity keys. Furthermore, there must be a way to verify relationships between identity keys and users via out-of-band verification schemes. Conclusively, a simple TLS-based in-transit-encryption is not sufficient for the intended use case of CSIRT communication.  Archive: An archive must be provided to look up previous discussions. Furthermore, it must be possible to add new members to an existing group discussion and allow them access to the message history. This is a difficult criteria for secure communication groups. In many encryption solutions, only existing members can access the full history, but newly added members can only access from the point when they have been added. Furthermore, for CSIRTs, it should be possible to have functional (nonpersonalized) mailboxes/accounts.  Attachments: To exchange files, such as documents, source code, or IOCs, the solution should provide the ability to exchange attachments of any file type.

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES

 Open Specification: The communication protocol/solution should be specified in

an open way to allow auditing of security features and reliability requirements.

This requirement is explicitly not about end-user documentation, but documentation about the architecture.  License: To allow auditing the code by independent reviewers, the source code of the intended communication solution should be licensed under a Free Software license approved by the Free Software Foundation (FSF) or the Open Source Initiative 22 23 24 (OSI) (CIRCL, 2018). Popular licenses include Apache v2 , GNU GPL and Xorg- Style (aka MIT) . Closed source solutions will be annotated as “proprietary”. Because some solutions provide encryption capabilities as add-ons for proprietary products, this requirement is relaxed in these cases, to only cover the add-on. When there are multiple implementations of a solution with different licenses, but Free Software Solutions exist for all operating systems, these solutions are annotated with “Free Software”. This is especially true for many open messaging specifications with multiple clients.  All Operating Systems (OS): The solution should be available on all major desktop operating systems (Windows, Mac OS, GNU/Linux) and mobile operating systems (iOS, Android). This requirement is only applicable for client software.  Maturity: Due to its long-term operation as one important communication medium among CSIRTs, the intended solution should be “future proof”. While this criteria is difficult to assess, the authors consider a finalized protocol specification, clients released as stable versions and a stable business model as indicators for a project’s maturity.

The remaining criteria have been identified as secondary selection criteria. These often require more detailed discussions and may not be answered easily. Furthermore, some make only sense for email-based solutions.

 Hosting: It is differentiated between completely decentralized, federated, centralized, and centralized but hosted on-premise solutions. While completely decentralized solutions form a communication network using distributed data structures shared by all clients, federated solutions require a number of hosted nodes that process and distribute messages hosted by participating CSIRTs. For centralized solutions, a special attention is given to on-premise solutions that can be hosted by the managing organization. In addition, for centralized solutions, the legal base should be in the EU or EFTA countries. In general, more decentralized solutions are preferred for inter-CSIRT communication.  Add-on Compatibility: Email-based solutions should allow an integration into best known email programs at the time of writing, to be adopted by end-users. This criteria is not relevant for standalone clients.  Compatibility with Existing Infrastructure: This shall just describe if there is an easy integration with already existing administration infrastructure, like a directory service.  Backward Compatibility: Older conversations, available in archives, must be still accessible years after their creation. For encrypted communication, this means that older identity keys should be available or messages were re-encrypted.

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES

 Forward Secrecy: Due to the popularity of Double-Ratchet-based protocols , such as 27 28 the Signal Protocol , OMEMO and others, the property of forward secrecy received a lot of attention in recent years in the Privacy Enhancing Technologies community. An attacker compromising the keys at a specific point in time should not be able to decrypt previously recorded encrypted communication from the past. Note that “perfect” forward secrecy cannot be achieved in an asynchronous protocol, because an online connection is required to execute a key agreement for a new ephemeral key that does not depend on a previous one. In addition to forward secrecy, the opposite direction has recently been defined as “post-compromise security” because the previous terms “backward secrecy” or “future secrecy” were confusing. An attacker compromising keys at a specific point in time should not be able to decrypt future communication, i.e., the protocol should be “self-healing”.

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES

2. OVERVIEW OF SOLUTIONS

First, a list of communication solutions best known at the time of writing is created to provide a coarse-grained overview. This is done by evaluating solutions best known at the time of writing with respect to the seven criteria identified as important selection criteria. After the first step, individual solutions that fulfil with all important criteria are filtered into a second step. These are discussed in detail, also with respect to secondary criteria.

2.1 SOLUTIONS NOT COVERED

While it is acceptable that non-email solutions require the installation of new clients, emailbased solutions should integrate with the teams existing email infrastructure. For the purpose of this study email-based solutions that are hosted in the cloud and require the users to create new email accounts were not covered. These do not integrate with existing email accounts and are thus not applicable to the scenario envisioned in this study.

2.2 INDICATORS AND ABBREVIATIONS

If not otherwise specified inside the tables, the following indicators and abbreviations are used throughout this assessment:

● full ○ no support ○/● partial support ? unclear N/A not applicable

2.3 FIRST STEP

For a better overview, solutions best known at the time of writing are categorized into coarse classes: Open Messaging Specifications, Central Messaging, Messengers, Encrypted Email Mailing lists, Email Encryption Gateways.

Obviously, there is some overlap among all these categories. The most prominent example is email communication, which is based on Internet Engineering Task Force - IETF standards, such as Simple Mail Transfer Protocol (SMTP) and Internet Message Access Protocol (IMAP) , i.e. it is an Open Messaging Specification. Still, email can be used in a large number of different setups and software configurations. Thus, there is a differentiation between different email setups in their own categories.

2.3.1 Open Messaging Specifications

Solutions best known at the time of writing based on openly specified standards. These typically have a wide range of different clients, as any developer is allowed to implement these specifications.

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES

Table 1: Overview of open messaging specifications

2.3.2 Central Messaging

Solutions best known at the time of writing that typically provided as on-premise or SaaS solutions, these messaging systems provide unified access and easy on-boarding.

Table 2: Overview of central messaging solutions

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES 2.3.3 Messenger

Solutions best known at the time of writing that, coming from a user experience perspective, focus on mobile first, nowadays messengers dominate the market for private users.

Table 3: Overview of modern messengers

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES 2.3.4 Encrypted Email Mailing lists

Solutions best known at the time of writing based on the email standards and OpenPGP or

S/MIME (Secure/Multipurpose Internet Mail Extensions) . These solutions support an encrypted mailing list among all participants.

Table 4: Overview of encrypted email mailing lists: OpenPGP and S/MIME

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES 2.3.5 Email Encryption Gateways

Solutions best known at the time of writing based on email standards: encryption gateways can transparently handle encryption and decryption for organizations. Most of the selected criteria are not directly applicable to email encryption gateways. Some solutions offer a TLS secured web-interface. The typical scenario is that emails are sent in plaintext to the gateway and then encrypted for the transmission over the Internet to the intended recipient. Thus, “encrypted groups” can be set up as usual. Some gateways may provide tools and policies to ease this, but in the scope of this study, it was not possible to evaluate each gateway in-depth.

Table 5: Overview of encryption email gateways

2.4 SECOND STEP

For the second round of assessments, email encryption gateways were omitted completely due to the following reasons: for a decentralized setup, like the one considered for the scenario of this report, gateways would need to be deployed at each of the teams, which have heterogeneous infrastructures. Thus integrating these with existing email gateways is difficult. Also, one of the advertised advantages of email encryption gateways is that they work with range of different encryption techniques (OpenPGP/MIME, S/MIME, password-basedencryption) with external recipients. Because a community of CSIRTs is a closed group of users, external recipients are a rare use case. Furthermore, if email decryption is handled at the

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES

Internet gateway and then stored unencrypted on IMAP or transmitted to the endpoint, additional encryption must be employed to re-transmit this for consumption on mobile devices.

Table 6: overview of the solutions best known at the time of writing that score all first step criteria

In the following paragraphs, these solutions are discussed in-depth. First, the primary criteria presented in Table 6 are discussed. This includes an assessment whether the design of the encrypted group communication fits into the scenario of having decentralized teams organized in a community. Furthermore, whether the provided archive and attachment capabilities are suitable and the availability of an open specification. For these solutions the remaining secondary criteria presented in Section 2 are discussed, namely Hosting (decentralized, federated, centralized, on-premise), Add-on Compatibility, Compatibility w/ Existing Infrastructure, Backward Compatibility and Forward Secrecy.

2.4.1 Mailing Lists

In general, mailing lists have the advantage of an organized threaded archive that can also be accessed at a later point. Importantly, users that have been added later can also access this archive. This allows reconstructing a discussion even for someone who was not a member of the lists at that point.

Mailing lists can be hosted on-premise and easily integrate with the existing infrastructure. They provide no additional forward secrecy due to their reliance on OpenPGP that typically have key rollovers of over 1 year. On the client side at the time of writing, OpenPGP add-ons exist for all systems.

Schleuder is a well maintained candidate of a re-encrypting mailing list based on OpenPGP. While Sympa is well maintained but it only supports S/MIME, not OpenPGP that users, like the one considered for the scenario of this report, are more accustomed to in compliance with RFC 2350 .

2.4.1.1 Schleuder

For Schleuder mailing lists, a mailing list key pair is generated by the list provider. A sender encrypts his/her email on the client side using this public key and transmits the email to the mailing list provider. On the mailing list provider side, the email is decrypted and re-encrypted using the individual recipients’ public keys.

The threat model of Schleuder is a “wanted Man-in-the-Middle”: The emails are protected against wiretapping by the email provider, but can be read during re-encryption by the list provider. However, if the list provider is compromised at a specific point in time, previous

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES

discussions cannot be decrypted by the adversary, only future communication is compromised. Conclusively, one can view the list provider to be “just another” subscriber to the mailing list that has no way of accessing old conversations.

To provide better resilience when deploying Schleuder, it should be considered to run fallback Schleuder instances at the local organization to switch over to in case the main Schleuder instance cannot be reached. A few simple feature additions to Schleuder, such as adding an

Mailing lists

import function for a fixed subscriber list would ease administration of this deployment.

have the advantage of an

2.4.1.2 OpenPGP/MIME vs. OpenPGP “Inline”

organized

Simply encrypting/signing the payload of an email is called OpenPGP “Inline”. This is not

threaded archive

standardized properly and requires a separate encryption for each attachment. A more

that can also be

comfortable attachment and encoding handling with OpenPGP according to the standard is only

accessed at a

provided by with clients implementing OpenPGP/MIME. Thus, in case OpenPGP encrypted

later point.

mailing lists are chosen, it is recommended to use modern email client add-ons that implement OpenPGP/MIME.

2.4.2 Matrix

In Matrix, group communication takes place in rooms. The protocol uses a one-to-one Double Ratchet (as in the Signal Protocol) between each other in a full mesh (“Olm ratchet”) . A simpler hash ratchet is used to encrypt sequences of messages from each device to other devices in a room (Megolm ratchet) . The state of each device's megolm ratchet ("Megolm key") is sent to all the other devices in the room over the secure one-to-one Olm channel, such that they can decrypt the messages and message history as long as they have the necessary Megolm session keys. The sessions are regularly re-established to avoid reusing the same key throughout the lifetime of the room (especially as users join/part the room). This scheme allows partial forward secrecy, but no post-compromise security (called “backward secrecy” in Matrix’ specification) as long as the session is continued and not re-established. This design allows newly added members to decrypt previous communication by retrieving Megolm session keys from other participants.

In their reference implementation, the exchange of Megolm session keys can be configured per room. The possible settings are: “Anyone”, “Members only (since the point in time of selecting this option)”, “Members only (since they were invited)” and “Members only (since they joined)”.

The solution Matrix provides is fully decentralized and federated. In practice, each user is registered at a homeserver and all messages in a communication room are replicated over all homeservers of the room’s participants. Thus, every homeserver connected to a room, through a user in this room, keeps a content of the room’s history. If a homeserver goes down, the conversation can still go on as the remaining homeservers are still exchanging messages. If a homeserver is back online it can re-synchronise messages, i.e., receiving old ones from other homeservers and inserting its own into the timeline of others.

Matrix is openly specified and implemented. On one hand, its reference implementation “Riot” has already several features and allows end-to-end encryption. On the other hand, Riot on desktop systems is implemented using web technology, and native clients, such as nhekoreborn, still lack in certain areas, such as encryption reliability. While there seem to be a

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES

development team of several full-time persons, at time of writing, there is no indication that this team has found a stable business model yet.

In 2018, the French Ministry of Digital reached out to the Matrix developers and a collaborative project called DINSIC started . Since January 2019, Matrix solutions are getting rolled out to the ministries . This effort also led to increased work on finalizing the Matrix Version 1.0 Specification. In parallel, ANSSI and EY are working on an audit. Interesting features on the implementation roadmap in regards to end-to-end encrypted are end-to-end capable search and turning on end-to-end encryption by default for rooms with private history.

2.4.3 XMPP

XMPP (Extensible Messaging and Presence Protocol) is an extensible standard for real-time communication. It is openly specified since 1999. The difficulty of evaluating XMPP lies in its history as an evolving standard. There exists a number of different cryptographic protocol extensions XEPs (XMPP Extension Protocol) . The currently valid ones on the Standard track 49 50 are XEP-0373: OpenPGP for XMPP , XEP-0384: OMEMO , XEP-0396: Jingle Encrypted 51 52 53 Transports – OMEMO . In addition, OTRv3 /OTRv4 is often used as an encryption protocol on-top of XMPP. A sensible selection of XEPs, that are required to provide a secure and modern group communication, has been defined by the Conversations team in their XMPP Compliance Tester . While this tester is focused on server providers, the selected XEPs must also be implemented on the client side to provide the required features. This makes it especially difficult to select the correct clients. If XMPP is chosen, a list of preferred clients should be distributed among participating organizations. Again, a difficult trade-off lies in the “archive” and “forward secrecy” requirement. While OMEMO and OTR provide forward secrecy, there is no way to provide an archive of messages . The newer OpenPGP extension, on the other hand, allows archiving, but no forward secrecy. A lot of comparisons between Matrix and XMPP can be found on the Internet. Here the focus is on three main points:

1) If one Matrix homeserver fails, Matrix can still re-synchronize missing messages between the remaining homeservers participating in a group discussion. Due to its real-time communication focus, this is not part of a normal XMPP server. Thus, Matrix

is in principle more resilient to network failures and disruptions.

2) Matrix’ Megolm protocol is unique in its properties and has been especially designed for group chats, choosing a promising set of tradeoffs. However, only the primary client Riot supports all features. 3) XMPP is a mature federated protocol with a long history. In contrast to Matrix, it has been proven in real world deployments. Matrix protocol is still in development, at the time of writing, and has a lot of room for improvement and stability issues.

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES

3. RELEVANT RECENT IDEAS

3.1 PRACTICAL ENCRYPTED MAILING LISTS

A new proposal has been published as a whitepaper named “Practical Encrypted Mailing Lists” (Walfield, 2018). It does not require plaintext access on the list provider. For this, the

encryption public keys of all subscribers are bound as subkeys to a new OpenPGP key. A new key flag is defined for special handling of these subkeys. To send a new email to this list, the sender selects this OpenPGP key, the email is encrypted to all subkeys and then relayed by the list provider to all recipients. While a prototype implementation is available , it requires changes to the OpenPGP standard and it is not available in a stable GnuPG release or other OpenPGP

58 59 Deploying end-

implementations, such as OpenPGP.js or OpenKeychain . Thus, while the proposal is sound,

to-end encrypted

it is not considered as a stable candidate, at the time of writing. However, it serves as an

communication

example that innovations may become available as implementations of new cryptographic

solutions for

approaches are evolving.

groups raises the challenge of 3.2 GROUP WEB KEY DIRECTORY FOR OPENPGP managing who is

Deploying end-to-end encrypted communication solutions for groups face the challenge of

part of a group

managing who is part of a group and how to find the public keys associated with a person.

and how to find

Using a central solution in the use case analysed here would make it a single-point of failure.

the public keys 60 associated with

When this is not the case, a new solution could be based on the Web Key Directory (WKD) , as

61 a person.

proposed and implemented by GnuPG since 2016. This mechanism could be extended for group establishment. WKD works like this: Per email address, a TLS connection is established to the email address' domain to retrieve the public key. Now, the email client can automatically encrypt to this email address. WKD builds upon the wide spread usage of the X.509 based certificate system for web servers. It allows for a better user experience for end-to-end encrypted mails.

To extend WKD for groups, a list of email addresses could be transferred. This way each organisation announces which email addresses belong to a group. Email clients would need to be extended to do this extra request and to be able to encrypt to a number of recipients automatically. The idea seems promising for smaller communities.

3.3 RESILIENT COMMUNICATION

In case of catastrophic events or an Internet lock-down, alternative means of establishing a peer-to-peer network are required that are not covered by the previously discussed solutions. These forms of communication are often called “Off-Grid Communication”. At IETF, the Bundle Protocol (RFC 5050bis ) is being standardized for Store-Carry-Forward routing (“Delay- Tolerant Networks”). This allows forwarding of messages hop-by-hop directly over different

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES 3.4 INTERESTING RELATED RECENT CRYPTOGRAPHIC RESEARCH

Besides the difficult trade-off between archive access and forward secrecy/post-compromise security, there are additional security properties that could be evaluated. An example is “transcript consistency” (Unger, 2015; Rösler, 2018) that defines the assurance that all members of a conversation are seeing the same message transcript, rather than messages which are selectively delivered or re-ordered to only some members, or messages which contain different plaintext for different members.

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES

4. BIBLIOGRAPHY

CIRCL Computer Incident Response Center Luxembourg, CSIRT Tooling: Best Practices in Developing, Maintaining and Distributing Open Source Tools, 2018-11-06, https://github.com/CIRCL/compliance/blob/master/csirt-tooling-best-practices/index.md

ECRYPT CSA Algorithms, Key Size and Protocols Report (2018) European Network of Excellence in Cryptology (ECRYPT CSA), 2018, www.ecrypt.eu.org/csa/documents/D5.4- FinalAlgKeySizeProt.pdf

P. Rösler, C. Mainka and J. Schwenk, More is Less: On the End-to-End Security of Group Chats in Signal, WhatsApp, and Threema, IEEE European Symposium on Security and Privacy (EuroS&P), 2018

N. Unger, S. Dechand, J. Bonneau, S. Fahl, H. Perl, I. Goldberg, & M. Smith, SoK: secure messaging, IEEE Symposium on Security and Privacy (SP), 2015

N. H. Walfield, Practical Encrypted Mailing Lists, 2016, ftp://ftp.gnupg.org/people/neal/openpgpmailing-lists.pdf

SECURE GROUP COMMUNICATIONS FOR INCIDENT RESPONSE AND OPERATIONAL COMMUNITIES

5. GLOSSARY AND ACRONYMS

Please refer to ENISA glossary https://www.enisa.europa.eu/topics/threat-riskmanagement/risk-management/current-risk/bcm-resilience/glossary and ENISA list of acronyms https://www.enisa.europa.eu/media/media-press-kits/enisa-glossary

-N -EN -540 -19 -03 TP

ABOUT ENIS A

The European Union Agency for Cybersecurity (ENISA) has been working to make Europe cyber secure since 2004. ENISA works with the EU, its member states, the private sector and Europe’s citizens to develop advice and recommendations on good practice in information security. It assists EU member states in implementing relevant EU legislation and works to improve the resilience of Europe’s critical information infrastructure and networks. ENISA seeks to enhance existing expertise in EU member states by supporting the development of cross-border communities committed to improving network and information security throughout the EU. Since 2019, it has been drawing up cybersecurity certification schemes. More information about ENISA and its work can be found at www.enisa.europa.eu.

ISBN: 978-92-9204-303-2, DOI: 10.2824/062571