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
WebAuthn, FIDO2 Infuse Browsers, Platforms with Strong Authentication
John Fontana, Standards & Identity Analyst, Yubico,  9/19/2018
Turn the NIST Cybersecurity Framework into Reality: 5 Steps
Mukul Kumar & Anupam Sahai, CISO & VP of Cyber Practice and VP Product Management, Cavirin Systems,  9/20/2018
NSS Labs Files Antitrust Suit Against Symantec, CrowdStrike, ESET, AMTSO
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-11763
PUBLISHED: 2018-09-25
In Apache HTTP Server 2.4.17 to 2.4.34, by sending continuous, large SETTINGS frames a client can occupy a connection, server thread and CPU time without any connection timeout coming to effect. This affects only HTTP/2 connections. A possible mitigation is to not enable the h2 protocol.
CVE-2018-14634
PUBLISHED: 2018-09-25
An integer overflow flaw was found in the Linux kernel's create_elf_tables() function. An unprivileged local user with access to SUID (or otherwise privileged) binary could use this flaw to escalate their privileges on the system. Kernel versions 2.6.x, 3.10.x and 4.14.x are believed to be vulnerabl...
CVE-2018-1664
PUBLISHED: 2018-09-25
IBM DataPower Gateway 7.1.0.0 - 7.1.0.23, 7.2.0.0 - 7.2.0.21, 7.5.0.0 - 7.5.0.16, 7.5.1.0 - 7.5.1.15, 7.5.2.0 - 7.5.2.15, and 7.6.0.0 - 7.6.0.8 as well as IBM DataPower Gateway CD 7.7.0.0 - 7.7.1.2 echoing of AMP management interface authorization headers exposes login credentials in browser cache. ...
CVE-2018-1669
PUBLISHED: 2018-09-25
IBM DataPower Gateway 7.1.0.0 - 7.1.0.23, 7.2.0.0 - 7.2.0.21, 7.5.0.0 - 7.5.0.16, 7.5.1.0 - 7.5.1.15, 7.5.2.0 - 7.5.2.15, and 7.6.0.0 - 7.6.0.8 as well as IBM DataPower Gateway CD 7.7.0.0 - 7.7.1.2 are vulnerable to a XML External Entity Injection (XXE) attack when processing XML data. A remote atta...
CVE-2018-1539
PUBLISHED: 2018-09-25
IBM Rational Engineering Lifecycle Manager 5.0 through 5.02 and 6.0 through 6.0.6 could allow remote attackers to bypass authentication via a direct request or forced browsing to a page other than URL intended. IBM X-Force ID: 142561.