Google powered Ethereum wallets

Wallets, wallets everywhere, and not a one can think — Photo by Julius Drost on Unsplash

Here at Hut34, it’s a core piece of our mission to drive adoption of crypto. currencies whenever and wherever possible. In discussing our creation of a data marketplace, and a ecosystem where bots and A.I. can connect, route, resolve and monetise their data, the very first hurdle you hit is the requirement for each participant to have a valid ethereum address.

This may seem trivial to some, but in practice it’s an unnecessarily high bar — the whole process is just harder than it should be.

We wanted to change that, and that’s the driving force behind our creation of a Google powered Etheruem wallet.

When we say ‘Google powered’ we’re referring to a synergy of key Google technologies which allow an end user to create addresses, and send ETH and tokens (and by extension sign any transactions) — all without having to install software, or understand keystores, private keys and other important, but complex, crypto first principles.

This post is a quick introduction to the four planks of Google tech. we’ve harnessed to deliver this product, and you can also check out the entire presentation in the video link below.

The concept of abstracting address private key management to third party systems such as Google is a big one, and we recognise that. Your feedback is strongly encouraged! — What do you think of this solution?, what are your estimates of the trade offs made between personal autonomy and security / accessibility? — We don’t claim to have all the answers on this, but really want to stimulate a conversation, join us at to learn more.

The Security Model

Usually the first question raised when we discuss our wallet relates to security — actually usually the first 28 questions relate to security! This is somewhat of a ‘worlds colliding’ moment, where the cultures and tech involved in powerful centralised technology such as the Google Cloud Platform can be seen as entirely independent of the values and tech involved in ‘blockchain’ projects such as token economies on the Ethereum blockchain.

In the future, we’ll speak further about why we don’t believe these paradigms to be in tension with each other, and how important it is for good teams and good practices to build bridges between these worlds, but for now we’ll stick to the detail on how we’ve ensured the best possibly personal security within our wallet model;

Stage 1 of 4— OAuth

OAuth is a wonderful, powerful thing.

The first stage of our wallet process is to require users to follow Google’s OAuth flow to create their wallet. Essentially this is us tying the use of a Google identity to a spot on Google Cloud Platform where we are going to store some data. Only a valid OAuth token matching that identity will be able to access this data, which in plain English means only a successful Google login is going to get you started in the wallet creation process.

Stage 2 of 4— Hidden app data in Users’ Google Drive

Once a user has created their wallet using a successful Google OAuth login, they’re prompted to give narrow permissions to our application to “View and manage its own configuration data in your Google Drive” — this is important because we’re going to encrypt and store a keystore password in this area. This important data is only accessible within the user’s own Google Drive storage.

Stage 3 of 4— the Google Cloud Platform

Once a user has completed their OAuth flow, and given us the appropriate, narrow, permissions to create their wallets, we provide the user with two choices;

Option 1 is to provide a password, in which case we use the magnificent ethers.js library to create their Ethereum address in their own browser (similar ‘client side’ technology to MyCrypto for example).

Option 2 is for a ‘passwordless’ account managed solely through their Google credentials, in which case the keystore is created server side (using web3j) with a randomised password, about which more in a moment.

In both cases, we store the data on the Google Cloud Platform, where it can be accessed given a valid OAuth token. We can be highly confident this data will remain available to our application.

Google Cloud Platform is jolly clever, and generally as reliable as Google. That’s pretty reliable.

Stage 4 of 4 — Google Key Management Services

We’ve learned that the keystore will be stored on Google Cloud Platform, and require a valid OAuth token, and we’ve learned that for users who opt not to define their own password, we’re going to use hidden application data within a users Google Drive to store an encrypted version of the password for the keystore.

The final piece of the puzzle then is how to encrypt and decrypt the password for users to select this option for the keystore. Google’s KMS gives us the answer — we use Key Management Services to manage all aspects of the encrpytion and decryption.

Rather nicely, this brings many advantages for management of individual keys, an audit trail etc. etc. — Enterprise has been aware of the benefits of such processes for some time, but they have yet to penetrate the crypto world (in general terms).

Risk Management / Disaster planning

In the development of the wallet, we took advice from Google Partner Engineers to understand the risks better around our selection of Google tech. — in fact the use of KMS was specifically recommended as part of this process. The headline takeout from these discussions is that the wallet security is really most strongly tied to the security of the users’ Google account. Fortunately there are good resources available to help users understand their Google account security and improve it where possible;

In terms of ‘black hat’ access to this user data, and therefore users’ ETH accounts, it would require the simultaneous compromise of three discrete and highly secure Google systems — the OAuth flow, the Cloud Platform, and the Key Management System.

It’s our opinion that such an attack is highly unlikely. It’s actually significantly less likely than the compromise of one Google product alone, such as the Chrome browser. Were Chrome to be compromised, all traffic within that browser to such tools as would potentially be at risk — this is not a material risk in our view.

In Conclusion

We humbly submit that bridges between the crypto. world, and enterprise tech in general are vital in driving adoption at scale, and we humbly offer this wallet product as an example of the ‘incremental decentralisation’ we believe will offer the best path to better tech and a better planet.

The wallet is live in Beta now , with plenty of further enhancements in the hoist, but please do take it for a spin here;

You can also review the entire codebase here;

If you can’t get enough of the whole idea, you can also see our initial presentation below, and watch a short demo of the wallet in action;

Peter from Hut34 talking at Ernst and Young about our clever new Google powered wallet