Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

6/27/2019
03:48 PM
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

Inside MLS, the New Protocol for Secure Enterprise Messaging

As personal messaging platforms see the rise of end-to-end encryption, businesses struggle to provide strong levels of security.

As the world moves toward end-to-end encryption for personal messaging platforms, businesses are challenged to integrate the same level of security in corporate messaging apps.

Even encryption protocols for person-to-person messaging are still undergoing development. Services want to reduce the amount of sensitive data they store; however, only a few encryption protocols – Signal, for one – have been scrutinized for security.

The Signal protocol, which rolled out to WhatsApp's base of one billion users in 2016, is the first end-to-end encryption protocol to be globally deployed. Security guarantees of the open-source protocol include forward-secrecy and recovery from key compromise. And while a few personal messaging systems have adopted Signal, corporate messaging has failed to follow.

"In the consumer space there are a few services with end-to-end encryption but in the business space it's very rare," says Raphael Robert, head of security at Wire, which launched in 2014 as a secure messenger primarily built for consumers. Since then, it has repositioned itself to build a secure business collaboration system. Wire is currently in the midst of working to develop Messaging Layer Security (MLS), a new protocol designed to facilitate more secure enterprise messaging platforms.

Technical challenges often hold companies back from adopting end-to-end encryption. "The bigger the organization, the harder it is to make a change in general," says Robert. Scalability is a key problem: WhatsApp, for example, uses a protocol dubbed Sender-Keys to support group chats. The problem is, the protocol doesn't support post-compromise-security, meaning in a simple deployment an employee who left the company may still read messages.

In many modern enterprise environments, products use transport encryption between client and server but messages and content being shared aren't encrypted on the server. This information usually ends up in a large database, he continues, where it's vulnerable to third-party access. A cybercriminal needs only an employee's credentials to break in and get it.

"This is a huge risk, which doesn't really meet the requirements of businesses in general," he adds. "There is typically very sensitive information."

Messaging Layer Security (MLS): A New Protective Protocol

To address the many issues in enterprise messaging security, the Internet Engineering Task Force (IETF) is building the MLS group messaging protocol. Its goals for MLS differ from those of pairwise protocols: it aims to allow practical groups up to 50,000 clients, cover multiple industry use cases including federation and Web browser support, and offer formal security guarantees.

When Wire introduced end-to-end encryption to its system in 2016 and open-sourced its code base, secure messaging protocols were "always a big issue," says Robert. There was no open standard they could adopt. That summer, during the IETF meeting in Berlin, Wire proposed a standard that was protected by modern security properties and could be used by companies large and small.

MLS has since been undergoing development. While initiated by Wire, along with Mozilla and Cisco, in 2016, it has received support from major tech companies along the way: Facebook, Google, INRIA, and Twitter have all contributed to the effort. "In the past 18 months we've worked a lot on the core protocol to make sure of what kind of security guarantees we want to achieve and how we can achieve them," says Robert. Now, they're finalizing it for the academic community to review.

How will it be different? Researchers proposed it should be possible to use MLS in a federated environment, meaning you don't need a central server or central cloud to implement it. Employees should be able to communicate across clouds and devices, Robert explains.

Many businesses also struggle with the risk of shadow IT, he continues. People rely on their mobile apps to communicate internally and externally, and it's difficult to regulate. Most employees use multiple devices, which most existing protocols "never really took into account," he adds. Since its inception, the people behind MLS wanted to address security across devices.

"One of the core goals of MLS was to support multi-device scenarios and support groups, particularly large groups, and to make encryption as efficient as possible," he adds. With many protocols, encryption for groups can get expensive.

By next year, he hopes, MLS will be ready to integrate into messaging platforms. Robert, along with INRIA's Benjamin Beurdouche and independent researcher Katriel Cohn Gordon, will discuss the research behind, and details of, MLS this summer at Black Hat USA in a briefing entitled "Messaging Layer Security: Towards a New Layer of Secure Group Messaging."

Related Content:

 

 Black Hat USA returns to Las Vegas with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions and service providers in the Business Hall. Click for information on the conference and to register.

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance & Technology, where she covered financial ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
tdsan
50%
50%
tdsan,
User Rank: Ninja
6/30/2019 | 6:09:35 PM
Not sure what we don't use IPv6 and the real reason this protocol is being developed
I think the real reason behind this is because they don't want the feds reading their emails.
Technical challenges often hold companies back from adopting end-to-end encryption. "The bigger the organization, the harder it is to make a change in general," says Robert. Scalability is a key problem: WhatsApp, for example, uses a protocol dubbed Sender-Keys to support group chats. The problem is, the protocol doesn't support post-compromise-security, meaning in a simple deployment an employee who left the company may still read messages.

I am not sure why we are not utilizing one of the best transport mechanisms on earth (IPv6), we have not even began to leverage all of its capability:
  • Protection against man in the middle attacks
  • IPv6 AES256 ESP/AH VPN capabilities
  • Faster transport mechanisms and improved processing of packets (faster transport speeds)
  • Tunnel capabiltieis of from 6-to-4 and 4-to-6
  • 17 quintillion addresses (an IP address for every grain of sand)
  • Ability to transport data across MPLS/IP networks at faster speeds
  • Authenticate and Encapsulate security packets across the network
  • Integrates with IS-IS (Intermediate-Systems/Intermediate-Systems) to run both protocols like ships in the night

Identify which users are trying to access which system because it uses a 1 to 1 connection instead of using multiple hop count (determine where the attack took place). We could encrypt the data packet from end to end.

Link "IPv6 Benefits"
Security
IPSec, which provides confidentiality, authentication and data integrity, is baked into in IPv6. Because of their potential to carry malware, IPv4 ICMP packets are often blocked by corporate firewalls, but ICMPv6, the implementation of the Internet Control Message Protocol for IPv6, may be permitted because IPSec can be applied to the ICMPv6 packets.

If malware is carried, we can employ Authenticated headers to ensure the data packets are sent only after it is considered a viable connection or limit the ability of others to connect to the network
ip6tables -I INPUT 1 -p tcp -m multiport -s 2606:a000:111f:efd::/64 -d 2606:a000:111f:efd::/64 --dport 22,25,80,443 -m conntrack --ctstate NEW,RELATED,ESTABLISHED -j ACCEPT # Logs the connections with SSH and web traffic
Todd S, Enterprise Architect
ITOTS Networks, LLC
US Turning Up the Heat on North Korea's Cyber Threat Operations
Jai Vijayan, Contributing Writer,  9/16/2019
Preventing PTSD and Burnout for Cybersecurity Professionals
Craig Hinkley, CEO, WhiteHat Security,  9/16/2019
NetCAT Vulnerability Is Out of the Bag
Dark Reading Staff 9/12/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-16413
PUBLISHED: 2019-09-19
An issue was discovered in the Linux kernel before 5.0.4. The 9p filesystem did not protect i_size_write() properly, which causes an i_size_read() infinite loop and denial of service on SMP systems.
CVE-2019-3738
PUBLISHED: 2019-09-18
RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to an Improper Verification of Cryptographic Signature vulnerability. A malicious remote attacker could potentially exploit this vulnerability to coerce two parties into computing the same predictable shared key.
CVE-2019-3739
PUBLISHED: 2019-09-18
RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to Information Exposure Through Timing Discrepancy vulnerabilities during ECDSA key generation. A malicious remote attacker could potentially exploit those vulnerabilities to recover ECDSA keys.
CVE-2019-3740
PUBLISHED: 2019-09-18
RSA BSAFE Crypto-J versions prior to 6.2.5 are vulnerable to an Information Exposure Through Timing Discrepancy vulnerabilities during DSA key generation. A malicious remote attacker could potentially exploit those vulnerabilities to recover DSA keys.
CVE-2019-3756
PUBLISHED: 2019-09-18
RSA Archer, versions prior to 6.6 P3 (6.6.0.3), contain an information disclosure vulnerability. Information relating to the backend database gets disclosed to low-privileged RSA Archer users' UI under certain error conditions.