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.

Endpoint

10/26/2016
10:30 AM
Connect Directly
Facebook
LinkedIn
RSS
E-Mail vvv
50%
50%

Getting To The 'Just Right' Level Of Encryption

The key to unlocking secure business messaging is controlling who has the key.

These days, the collaboration industry is abuzz with consumer-focused companies implementing end-to-end security in their messaging products. It started with Apple and its battle with the US government on access to iPhone data. Then, WhatsApp switched its messaging technology in such a way that no one could access messages except for the end-user client. These tools may seem like a good fit for workplace collaboration, but a quick look under the hood shows they’re not.

The workplace environment isn’t that simple. The cloud is constantly enabling more value-added features and functionality such as bots, artificial intelligence, and third-party integration. But for many cloud providers, “adding value” often means having full access to user data and content.

Enterprises are in search of the “Goldilocks” form of encryption — not too insecure, but also not too locked down. They need a balance between desirable access for groups such as IT and undesirable access from cloud providers, attackers, and more. Legal departments and information security teams also have a different set of requirements for access to information. In the end, enterprises need more flexibility to allow these additional features but also exclusive control over the management of their encryption keys and the confidentiality of their data.  

Fully locked-down end-to-end consumer tools (such as WhatsApp) prevent data access from attackers and as well as the cloud provider (WhatsApp itself), but also prevent data access for anyone else, including IT. If you work for any business seriously considering “just use WhatsApp at work,” this should give you great pause.

On the other end of the spectrum, we have enterprise messaging providers such as Slack and HipChat. They typically use transport security combined with encrypted databases. This weaker form of security ultimately enables the provider, attackers, and perhaps enterprise IT (assuming such features are developed and made available) to have access. In this case, critical business data is potentially in the hands of many, and the more popular the tool, the more enticing it becomes for attackers. Most recently, Google launched Allo, promising much in the way of app performance, but with it made a huge sacrifice on privacy benefits. So how do we adapt the solution to maintain usability without compromising security?

Messaging services should be designed to ensure the value-added services themselves (such as message search, content transcoding, or integration with third-party applications) are visible to and authorized by enterprise IT. Most importantly, IT must be able to revoke access to these services in a way that can't be bypassed by the messaging service provider. “Just right” encryption begins with an open architecture for the secure distribution of encryption keys, allowing enterprises to gain exclusive control over the management of these keys and the confidentiality of their data.

The cornerstone of this architecture is called the key management server (KMS), a dedicated server responsible for creating, storing, authorizing, and providing access to the encryption keys that each client uses to encrypt and decrypt content. True end-to-end encryption then becomes possible through an architectural and operational separation between the KMS and the rest of cloud service. Think of them as being in separate realms, or trust domains, in the cloud. The KMS is in the “security realm” and all other component services that make up the cloud-based messaging app are in the “core.”

A basic message exchange in this model could go something like this: When a user wants to send content to a team member, the user’s client connects to its KMS and requests a key to encrypt the content. The key server authenticates the client, and vice versa, all in a way that is separate from the core messaging service. Then the client uses this key to encrypt the content and sends that to the core messaging provider, which delivers it to the team member. The team member follows a similar process and requests access to the key to decrypt the content.  

Because the key server is under control of the enterprise, the enterprise can control what clients — including bots and other applications — get access to the keys. In addition, the enterprise can itself access information to handle situations such as forensic investigations, subpoenas for information, or digital loss prevention. 

Related Content:

Jonathan Rosenberg is responsible for the architecture and overall technology direction of Cisco's collaboration portfolio, and is focused on evolving Cisco's technology to address the market transitions in cloud and mobile. Rosenberg is a widely recognized technologist. He ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Purtier
50%
50%
Purtier,
User Rank: Strategist
10/17/2017 | 4:16:01 AM
More Privacy To Users
This encryption provides more privacy to users.
forskolinfuel
50%
50%
forskolinfuel,
User Rank: Apprentice
10/29/2016 | 10:55:44 PM
forskolin fuel
Nice post
Microsoft Patches Wormable RCE Vulns in Remote Desktop Services
Kelly Sheridan, Staff Editor, Dark Reading,  8/13/2019
The Mainframe Is Seeing a Resurgence. Is Security Keeping Pace?
Ray Overby, Co-Founder & President at Key Resources, Inc.,  8/15/2019
GitHub Named in Capital One Breach Lawsuit
Dark Reading Staff 8/14/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-15132
PUBLISHED: 2019-08-17
Zabbix through 4.4.0alpha1 allows User Enumeration. With login requests, it is possible to enumerate application usernames based on the variability of server responses (e.g., the "Login name or password is incorrect" and "No permissions for system access" messages, or just blocki...
CVE-2019-15133
PUBLISHED: 2019-08-17
In GIFLIB before 2019-02-16, a malformed GIF file triggers a divide-by-zero exception in the decoder function DGifSlurp in dgif_lib.c if the height field of the ImageSize data structure is equal to zero.
CVE-2019-15134
PUBLISHED: 2019-08-17
RIOT through 2019.07 contains a memory leak in the TCP implementation (gnrc_tcp), allowing an attacker to consume all memory available for network packets and thus effectively stopping all network threads from working. This is related to _receive in sys/net/gnrc/transport_layer/tcp/gnrc_tcp_eventloo...
CVE-2019-14937
PUBLISHED: 2019-08-17
REDCap before 9.3.0 allows time-based SQL injection in the edit calendar event via the cal_id parameter, such as cal_id=55 and sleep(3) to Calendar/calendar_popup_ajax.php. The attacker can obtain a user's login sessionid from the database, and then re-login into REDCap to compromise all data.
CVE-2019-13069
PUBLISHED: 2019-08-17
extenua SilverSHielD 6.x fails to secure its ProgramData folder, leading to a Local Privilege Escalation to SYSTEM. The attacker must replace SilverShield.config.sqlite with a version containing an additional user account, and then use SSH and port forwarding to reach a 127.0.0.1 service.