VPN by Google One White Paper

VPN by Google One, explained

At Google, keeping our users safe online means continuously protecting the privacy and security of their personal information. As we design our products, we focus on three core principles: keeping our users’ information secure, treating it responsibly, and putting our users in control. Over the years, we’ve put these principles into practice introducing tools that allow users to manage their passwords, view and delete their activity history, set auto deletion timelines, turn off web & app activity,and turn on private browsing sessions.

We’ve also long encouraged the use of Transport Layer Security (TLS), the widely adopted cryptographic protocol for securing communication over networks, and other protections across the wider web ecosystem. Unfortunately, not every online service provider is committed to implementing rigorous data protection standards1, leaving gaps in how well consumers are protected and in how much control they have over who can access their network traffic data. Even if security protections are properly utilized by online service providers, information such as your IP address and the sites you visit are not always encrypted and can be accessed by others.

A VPN provides both encrypted transit and IP address dissociation for packets between users’ devices and the VPN servers. When securely implemented, this hides online activity from network nodes along the way that might have visibility into user traffic data, like public WiFi hotspots or other service providers. While this removes the ability for intermediaries to snoop on user traffic, this puts the VPN provider in a position to see all of a user’s unencrypted browsing traffic, e.g., the domain of every website visited. Because the VPN provider occupies this privileged position, the user must be able to trust that the VPN provider has strong privacy and security guarantees.

Unsecured connections v. VPN Connections

Figure 1: Unsecured connections v. VPN Connections

Demand for VPNs is growing, with evidence that it’s becoming more mainstream -- up to 25% of all Internet users accessed a VPN within the last month of 2019.2Unfortunately, not all VPN providers have been proven to be trustworthy: some services are vulnerable3, others request unnecessary access to their users’ data or monetize the same data that users are utilizing the VPN to keep private and secure, while others fail to deliver on the promise of not logging their users’ online activity.4

With growing demand for better privacy in a mixed landscape of solutions, we have used our expertise in privacy, cryptography, and infrastructure to build a Google-grade VPN that provides additional security and privacy to online connectivity without undue performance sacrifices. With VPN by Google One, users’ online activity is not identifiable to the VPN and not logged by the VPN. We believe a VPN must be transparent, and robust. That's why we have open sourced our client and conducted a third party audit of the solution to make them externally verifiable.

Under the hood

Privacy is at the core of the products and services we build. With VPN by Google One, we will never use the VPN connection to track, log, or sell your online activity. Some minimum logging is performed to ensure quality of service, but your network traffic or IP associated with the VPN is never logged. To demonstrate how our design works, we have open sourced the code that runs on a user’s device and we have conducted a third party audit of the system (report here), which provides independent assurance of our data and security practices.

Open sourcing our VPN and providing an audit are just some of the steps we are taking to ensure user privacy. While building VPN by Google One we realized it was important to strengthen some of the systems that are often attacked or compromised in order to access users’ personal data.

Traditional VPNs can sometimes compromise a users’ identity or online activity by linking the usage of their service to the activity they conduct by means of a session ID. This ID could allow VPN operators, or attackers that compromise their infrastructure, to "eavesdrop" and identify users’ and their activity.

Traditional Authentication Architecture

Figure 2: Traditional Authentication Architecture

We wanted to eliminate that vulnerability by separating the authentication of the subscriber from their use of the service. By employing a cryptographic blinding step between user subscription validation and connecting to the VPN, we give users a stronger guarantee that their online activity won't be tied back to their identity.

VPN by Google One’s authentication with blind signatures

Figure 3: VPN by Google One’s authentication with blind signatures

Architecturally, we’ve split authentication from the data tunnel setup into two separate services:

  • Authentication service: This service validates users’ access to VPN by Google One. The client first generates an OAuth token and a blinded token (see below for definition). Then, the authentication service validates and exchanges the OAuth token for a signed blinded token.
  • Key Management Service: The client can then ‘unblind’ this signed blinded token using cryptographic blinding. When the client connects to the data tunnel server, it provides only this signed unblinded token to the data tunnel server. Thus, the only piece that links the authentication server to the data tunnel server is a single, public key, used to sign all blinded tokens presented during a limited period of time.

The blinding algorithm employed was first described by Chaum in 19825, and is commonly referred to as ‘RSA Blind Signing’. The goal is to never use the same identifier in the Authentication server and the Key Management Service. To accomplish this, the client generates a token, hashes it using a Full Domain Hash, and combines it with a random value and the server’s public signing key to produce a blinded token. That blinded token is then signed by our authentication server. When the client wants to connect to the VPN, it can unblind the blinded token and its signature using the random value only it knows. The unblinded token and the signature are then verifiable by our Key Management Server.

The servers are physically distinct and only share a cryptographic root-of-trust to validate the signed unblinded token; they strictly share no other information - specifically, no user identifiable information is available to the data tunnel servers. As a result of this careful authentication architecture, it would be infeasible for an attacker to break the cryptographic protections of one of the services with enough time to break the second and thus be able to associate a user to their activity. We’ve calculated that it would take years to break both services, even when using the equivalent of roughly Google’s entire global computational capacity.

Users only benefit from a VPN when it is used. If the VPN is slow or unreliable, users may turn it off, putting their traffic at risk. Speed and reliability are at the core of our VPN. To ensure high throughput and minimal battery consumption, we will be adopting IPSec as the data tunnel protocol across platforms. Already adopted in iOS and coming to Android in 2022. We may eventually use other protocols, such as Wireguard, as their native support improves or on platforms where no specific protocols have a specific advantage.

Before the client initiates the data tunnel setup, it does a DNS query to resolve a pool of exit nodes topologically nearby in one of Google’s Points of Presence (PoP) locations. The client asks to be associated with this pool during the data tunnel setup, ensuring a low-latency connection on a node with reasonable load.

The VPN service does not limit the users throughput speed and will allow as much as the infrastructure is capable of delivering at any given time, often resulting in available user speeds above 300 Mbps.

While the user ID and IP data have already been protected by the authentication steps, the data tunnel path does not log any user data traffic; only recording aggregate metrics, without user identifiable information, where needed for reliability. This delivers a service with higher reliability while maintaining the VPN’s privacy guarantees. We combine these approaches with strict standards on logging and auditing of our open-source code to ensure the VPN remains trustworthy.

Using a VPN shouldn’t require that you completely turn over your trust to the VPN provider. A VPN provider should be able to transparently demonstrate how their service keeps your data private. Our VPN client-side code is open sourced so that users and privacy experts alike can verify how user data is handled.

Looking forward

We believe an easy to use, highly private and performant VPN will significantly help improve user privacy and security online. So it should come as no surprise that we want to make VPN technology available to as many users as possible.

In 2020, we launched the service on Android in the US. We have since scaled to iOS and more countries. We also plan on expanding to platforms like Windows and Mac.

Because a VPN sits at the interface between the device and the network, there are many interesting opportunities for it to provide additional security to users by blocking threats before they get to their devices. We will continue to explore these for future additions.