How to turn our smartphones into everyday hardware wallets
TL;DR: Cryptocurrencies and blockchain based services have to be easy and safe to use to get adopted by the masses — printing and storing paper wallets is just not going to cut it. Utilizing Shamir’s Secret Sharing and isolation from Android, Zippie aims to make cryptocurrency and decentralized technologies mainstream by turning our smartphones into easy to use everyday hardware wallets which we control.
We all have been there. Trying to store our private keys somewhere safe so that hackers can not steal our precious cryptocurrencies, only to realize that we would rather eat a brick than pick up our hardware wallets or USB sticks from the basement and connect them to our computers every time we want to make a transaction.
Using a custody service such as an exchange to store our crypto is not an option. The whole point of decentralization is to give power back to people so that we can manage our own digital life: money, data and identity.
Despite the fact that no one has cracked the private key dilemma and found the perfect balance between making cryptocurrency transactions both easy and safe (as in, you control your own private key in a trusted manner), we want to give it a go.
Split the key, decentralize the risk
At Zippie, our aim is to bring blockchain based services to the masses by making them accessible and easy to use for everyone, while respecting the core purposes of decentralization.
And what could be an easier entry point to blockchain for billions of people than their smartphones?
Initially, Zippie turns our smartphones into hardware wallets suitable for everyday use. Zippie software creates an isolated compartment to Android devices which is both easy to use, and fully controlled by the user.
To achieve this, we utilize Shamir’s Secret Sharing to decentralize private key management. Shamir’s Secret Sharing allows us to split a secret into N pieces such that M out of N pieces are needed to reconstruct the secret.
For simplicity’s sake, when we talk about your key in the following, we actually do mean your mnemonic, which can through an algorithm be deterministically derived into infinite amounts of private keys.
Similarly, it is understood in this post that a private key has an easily generated corresponding public key; and that if you have the private key, you can decrypt data encrypted against the corresponding public key and vice versa.
Every device that is enrolled into a Zippie identity stores three pieces of data:
- a device private key
- a device authentication private key, this and the above ideally stored in the device’s security chip
- a piece of your key (one piece out of two; two pieces required to reassemble key), encrypted against the device public key
As you can see, an enrolled Zippie device does not store the whole key.
However, when the device needs to get brief access to your key in order to perform signing of transactions, what does then happen?
The other part of your key, encrypted against your device public key, is stored in a online service (initially hosted by Zippie but anybody could run one with same API). This online service has four basic purposes:
- If you cryptographically prove that you’re the holder of a device authentication private key, it will give you the other part of your key
- If you cryptographically prove that you’re the holder of a device revoke private key, it will make it impossible for the device authentication private key to access the other part of your key again; a bit like how you would block your credit card
- Make it possible to store the other part of your key and specify which public keys that can perform authentication and which can request revocation
- It’ll do its best to fully delete the other part of the key when requested
As you probably note, there is no revocation key stored on the device. Before we dive further into this; here’s a bit of background information about mnemonics and the algorithm used for deriving the keys.
In general, what happens is that your mnemonic is cooked down into a seed that is then processed in a way that makes you able to generate the same private keys and public keys when providing the same ‘derivation path’.
Using the same mnemonic, you can generate multiple seeds by essentially providing an additional element of data — so you can imagine that without this additional element you generate keys that you use for small daily payments; but by using a password as the additional element, the keys generated would be the ones that hold your life savings. Or you could have a third ‘duress’ password that generates keys that hold rights to some money that you would be fine giving to criminals or government while under duress.
So, what do you do when your Zippie device is lost or stolen?
Similar to how you’d do it with a Google Account or Apple ID, you’d be able to use another of your devices that’s already logged in and disable the device in question — effectively forcing it to ‘log out’ the other device and make it unable to access your data.
As the mnemonic is a common element of the devices that can successfully authenticate with their particular device authentication key, get, decrypt and combine the two pieces of the mnemonic, it seems like a good place to start.
This means that if you have access to your key on a device, you can basically generate the device revocation private key by providing the mnemonic and an additional data element (the name of the device); and send off the revocation request to the online service.
How do you then recover if you have no other logged in device?
We are actively using IPFS in the Zippie solution. Making a long story short, IPFS enables that you can retrieve a particular piece of data by providing the hash of the data; making a content-addressed network in practice.
Our current idea is that in the device box, we provide an NFC tag, in the shape of a key fob, that we suggest to the Zippie user to put for example on their key chain.
What will be written to the NFC tag has to fit in roughly 144 bytes — the cheapest NFC chip available. It turns out that:
https://gateway.ipfs.io/ipfs/QmSOME_IPFS_HASH#32_BYTES_ENCODED
fits exactly in 144 bytes.
When the user scans the NFC tag on a new device, the device will fetch the IPFS_HASH in question (mirrored by services of the users’ choice).
The IPFS_HASH page would be a full browser experience with an embedded encrypted blob in it, that is decryptable with the 256-bit key provided past the # in the URL. This means that the host of the IPFS_HASH page cannot access the contents of the encrypted blob.
What the blob contains is roughly the same as what would be stored on a Zippie device, but accessing the private keys for authentication and decryption requires passing through multi-factor authentication (facial recognition, e-mail authentication, etc.) which hands you pieces of the private keys when successful. Requiring this means that merely possessing the NFC tag data is not enough. After that, you can access your full Zippie identity and revoke a device’s access.
We’re also investigating means to store a virtual ‘key fob’ in existing cloud services, such as your e-mail or cloud storage.
Even Android cannot access your wallet
Coming from a Nokia and Jolla/Sailfish OS background, we are rather familiar with mobile operating systems and smartphones in general. Knowing how data-hungry operating systems such as Android can be, we feel that making a simple wallet app is not enough to keep your transactions and private data only between you and the receiver. The wallet has to be rooted deeper in your smartphone.
When using Zippie, you can imagine that your smartphone has an isolated container which only you have full control over — even the phone’s OS such as Android cannot access it without your permission. At the same time, accessing this container is as easy as any other app or widget on your phone.
Curious how that all works? Watch out for our next tech blog posts.
In the meanwhile, join the discussion in our Telegram and be the first to get notified about our soon-to-start token sale.
