> The fundamental anonymity model Google have employed is that the VPN tunnel is authenticated using "blind tokens" which are signed by an authorization service "Zinc." The Zinc service validates OAuth credentials passed in from the client app to verify a user's subscription, then signs the blind token created by the client app to authorize the user's session with the actual VPN backend "Copper." Ostensibly, this will separate the user's Google identity from the VPN identity since the VPN service only knows that it got a valid, signed user token, not what user that token belongs to.
In case you needed even more information on how this works, Google provides on their page [1]
> The blinding algorithm employed was first described by Chaum in 19826, 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.
This is an easy way to understand how this works. This actually does not sound like the start-of-the-art for cryptography. In their example, the client has to provide the secret, which, then corresponds to a hash that was encrypted using this secret key along with Zinc's public key. Zinc knows who provided it the blinded token that it signed. On revelation of this secret key, Zinc could immediately determine who is the owner.
Tornado Cash bypasses this leak of information by using a zero knowledge proof involving a Merkle path [2]
> This actually does not sound like the start-of-the-art for cryptography.
I'm wrong. Review the paper Google provided as a source for more information. [1] There are also lectures available online from Ronald Rivest, [2] one of the researchers that helped to invent/discover the RSA cryptosystem. (If you are not familiar with how RSA works)
FTA [1]: "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"
It sounds like the only information Google could produce is: "yes, this traffic came from our VPN, here is a list of the 20,000 users who logged in during this key rotation period"
Yes, this is the concept, and the NCC report correctly identifies a lot of deltas with reality, which also I outlined in my comment above:
* Google or a privileged attacker sitting at either end of the VPN could exfiltrate the user's identity through packet inspection and unencrypted personal identifiers in the user's VPN traffic, both obvious identifiers like plaintext data on the network and less obvious identifiers like specific subdomains or IPs correlated to a specific set of identities. This is a fairly fundamental problem with all "privacy" VPNs - as soon as you've exposed your identity by logging into a service over the VPN link, you're fairly easily unmasked again to a privileged attacker.
* If the authentication and VPN services have timestamped logging, the user's identity leaks through this side channel. At Google scale of course there's still bound to be some mixing, but it's a lot more granular than a key rotation period.
* A privileged attacker could also perform network analysis between the authentication and VPN services as well to achieve the same goal.
Perhaps Google have some lightweight countermeasures against these types of attack (even a random some-milliseconds timing at the client side between receiving a signed blind token and using it to establish the VPN connection would help a tiny bit), but if they do, they weren't outlined in the report.
My takeaway from this is "Google made a fine VPN, but it's nothing ground breaking, and so-called Privacy VPNs are still not a thing." Depending on your threat model a VPN is still a very useful tool, but none of them can truly anonymize you.
> Perhaps Google have some lightweight countermeasures against these types of attack (even a random some-milliseconds timing at the client side between receiving a signed blind token and using it to establish the VPN connection would help a tiny bit), but if they do, they weren't outlined in the report.
The client could pre-generate session tokens days or months in advance. Then, leave their house, head to public wifi, (to avoid traffic correlation on their home network) and even after unblinding the session token, it would not be feasible to determine who paid for VPN.
If Google's VPN used Tornado Cash's protocol, they wouldn't be able to take the proof of having a session key back to Zinc to determine who asked for that to be signed. (if we assume Zinc is malicious) The protocol used looks like it was to provide anonymity with third parties, but not anonymity to the first parties. Google also links to the paper from 1982 that they're referencing. [1]
In case you needed even more information on how this works, Google provides on their page [1]
> The blinding algorithm employed was first described by Chaum in 19826, 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.
This is an easy way to understand how this works. This actually does not sound like the start-of-the-art for cryptography. In their example, the client has to provide the secret, which, then corresponds to a hash that was encrypted using this secret key along with Zinc's public key. Zinc knows who provided it the blinded token that it signed. On revelation of this secret key, Zinc could immediately determine who is the owner.
Tornado Cash bypasses this leak of information by using a zero knowledge proof involving a Merkle path [2]
[1] https://one.google.com/about/vpn/howitworks
[2] https://github.com/tornadocash/tornado-core