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
Election Websites, Back-End Systems Most at Risk of Cyberattack in Midterms
Kelly Jackson Higgins, Executive Editor at Dark Reading,  8/14/2018
Intel Reveals New Spectre-Like Vulnerability
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/15/2018
Australian Teen Hacked Apple Network
Dark Reading Staff 8/17/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-15504
PUBLISHED: 2018-08-18
An issue was discovered in Embedthis GoAhead before 4.0.1 and Appweb before 7.0.2. The server mishandles some HTTP request fields associated with time, which results in a NULL pointer dereference, as demonstrated by If-Modified-Since or If-Unmodified-Since with a month greater than 11.
CVE-2018-15505
PUBLISHED: 2018-08-18
An issue was discovered in Embedthis GoAhead before 4.0.1 and Appweb before 7.0.2. An HTTP POST request with a specially crafted "Host" header field may cause a NULL pointer dereference and thus cause a denial of service, as demonstrated by the lack of a trailing ']' character in an IPv6 a...
CVE-2018-15492
PUBLISHED: 2018-08-18
A vulnerability in the lservnt.exe component of Sentinel License Manager version 8.5.3.35 (fixed in 8.5.3.2403) causes UDP amplification.
CVE-2018-15494
PUBLISHED: 2018-08-18
In Dojo Toolkit before 1.14, there is unescaped string injection in dojox/Grid/DataGrid.
CVE-2018-15495
PUBLISHED: 2018-08-18
/filemanager/upload.php in Responsive FileManager before 9.13.3 allows Directory Traversal and SSRF because the url parameter is used directly in a curl_exec call, as demonstrated by a file:///etc/passwd value.