Google Sheds Light on Data Encryption Practices

  /     /     /  
Publicated : 22/11/2024   Category : security


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. Todays 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 Googles infrastructure, she explains. When a user sends data to the Google Cloud, its 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 Googles control. Data within these boundaries is authenticated but not always encrypted because strong security measures are already in place.
When running at Googles 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 todays release.
On a network level, Google Clouds virtual network infrastructure automatically encrypts data moving between virtual machines if it crosses a physical boundary Google doesnt 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 Googles 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, its not designed to conceal the internal services communicating; as a result, it doesnt 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.

Last News

▸ Google and Facebook reassure U.K.: No snooping. ◂
Discovered: 26/12/2024
Category: security

▸ New startup offers human verification process. ◂
Discovered: 26/12/2024
Category: security

▸ Top 5 Data Breaches in Spring 2013. ◂
Discovered: 26/12/2024
Category: security


Cyber Security Categories
Google Dorks Database
Exploits Vulnerability
Exploit Shellcodes

CVE List
Tools/Apps
News/Aarticles

Phishing Database
Deepfake Detection
Trends/Statistics & Live Infos



Tags:
Google Sheds Light on Data Encryption Practices