Cloud

12/13/2017
04:55 PM
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail
50%
50%

Google Sheds Light on Data Encryption Practices

Google explains the details of how it secures information in the cloud and encrypts data in transit.

Following a year of major cyberattacks and security threats, Google has published two whitepapers to explain how it secures data. One focuses on encryption of data in transit; the other on service-to-service communication using Application Layer Transport Security (ALTS).

Google gets a lot of questions from customers on how it protects data, says Maya Kaczorowski, Google Cloud security and privacy product manager. Today's release details the steps taken to protect authenticity, integrity, and privacy by verifying data sources, ensuring data arrives unchanged, and keeping data confidential while in transit.

Encryption in transit refers to "how data moves from a user to Google, and how it moves within Google's infrastructure," she explains. When a user sends data to the Google Cloud, it's encrypted in transit by default using HTTPS and TLS. Both of these are common practice; Google introduces more security for data traveling outside its infrastructure.

Google Cloud encrypts and authenticates all data in transit, at multiple network layers, when it moves outside physical boundaries not under Google's control. Data within these boundaries is authenticated but not always encrypted because strong security measures are already in place.

"When running at Google's scale, performance is important," Kaczorowski says. "Different modes of protection we use depend on the threat model and performance requirements that we have."

To protect against potential threats, she continues, Google assumes the external wide-area network "is only semi-trusted." Encrypting data protects it from active adversaries who could spy, inject, or alter traffic on the wire, Kaczorowski explains in a blog post on today's release.

On a network level, Google Cloud's virtual network infrastructure automatically encrypts data moving between virtual machines if it crosses a physical boundary Google doesn't control.

"Once the data is inside Google, the first thing to understand is not all data in transit within Google is protected the same way," says Kaczorowski.

The ALTS protocol, discussed in detail in the second whitepaper, is a mutual authentication and transport encryption system. Google usually uses it to secure Remote Procedure Call (RPC) communications from service to service within its infrastructure. Each of these internal services has a service account identity with cryptographic credentials used for authentication.

ALTS is similar to TLS but designed specifically for Google's data centers. It relies on two protocols, the Handshake and Record protocols, both of which dictate how sessions are established, authenticated, encrypted, and resumed, as explained in the paper.

The trust models of TLS with HTTPS semantics, and ALTS, are significantly different, Google says in the paper. The former binds server identities to a specific name and associated naming schemes. The latter uses the same identity for multiple naming schemes, adding flexibility and simplifying the process of load balancing, microservice replication, and scheduling between hosts. ALTS is simpler in design and implementation, Google says, making it easier to monitor for bugs and vulnerabilities using manual source code inspection or fuzzing.

There are a few trade-offs to using ALTS over TLS, the company points out. For example, it's not designed to conceal the internal services communicating; as a result, it doesn't encrypt handshake messages to hide identities.

The ALTS handshake protocol is also susceptible to Key Compromise Impersonation attacks. If an attacker compromises the Diffie-Hellman key used during the handshake, or the resumption key of a workload, they can use that key to make illegitimate workloads appear authentic.

On top of default protections, Google lists additional options to encrypt data in transit: IPsec tunnels, free and automated TLS certificates, and Istio, an open-source service mesh developed by Google and other companies, including Lyft and IBM, to help with service discovery.

Related Content:

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
When Your Sandbox Fails
Kowsik Guruswamy, Chief Technology Officer at Menlo Security,  4/11/2019
Julian Assange Arrested in London
Dark Reading Staff 4/11/2019
8 'SOC-as-a-Service' Offerings
Steve Zurier, Freelance Writer,  4/12/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-1840
PUBLISHED: 2019-04-18
A vulnerability in the DHCPv6 input packet processor of Cisco Prime Network Registrar could allow an unauthenticated, remote attacker to restart the server and cause a denial of service (DoS) condition on the affected system. The vulnerability is due to incomplete user-supplied input validation when...
CVE-2019-1841
PUBLISHED: 2019-04-18
A vulnerability in the Software Image Management feature of Cisco DNA Center could allow an authenticated, remote attacker to access to internal services without additional authentication. The vulnerability is due to insufficient validation of user-supplied input. An attacker could exploit this vuln...
CVE-2019-1826
PUBLISHED: 2019-04-18
A vulnerability in the quality of service (QoS) feature of Cisco Aironet Series Access Points (APs) could allow an authenticated, adjacent attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to improper input validation on QoS fields within Wi-Fi fra...
CVE-2019-1829
PUBLISHED: 2019-04-18
A vulnerability in the CLI of Cisco Aironet Series Access Points (APs) could allow an authenticated, local attacker to gain access to the underlying Linux operating system (OS) without the proper authentication. The attacker would need valid administrator device credentials. The vulnerability is due...
CVE-2019-1830
PUBLISHED: 2019-04-18
A vulnerability in Locally Significant Certificate (LSC) management for the Cisco Wireless LAN Controller (WLC) could allow an authenticated, remote attacker to cause the device to unexpectedly restart, which causes a denial of service (DoS) condition. The attacker would need to have valid administr...