@jack today tweeted a thread about hardware wallets for Bitcoin - I provided a short response to his thread, but I wanted to go through each point in the thread to expand on our thoughts about each specifically.
Square is considering making a hardware wallet for #bitcoin. If we do it, we would build it entirely in the open, from software to hardware design, and in collaboration with the community. We want to kick off this thinking the right way: by sharing some of our guiding principles.
— jack (@jack) June 4, 2021
Fundamentally we believe in getting away from using dedicated hardware for key storage, and we should instead utilised standardised protocols for encryption, allowing for consumers to chose the hardware they want and can afford, instead of being forced down a single path.
1/Bitcoin is for everyone. It’s important to us to build an inclusive product that brings a non-custodial solution to the global market. Much respect to everyone who has gotten us this far. What are the biggest blockers to get a non-custodial solution to the next 100M people?
— jack (@jack) June 4, 2021
What are the biggest blockers? User experience, and cost. Traditional hardware wallets are quite expensive, especially to those users outside of the developed world. And ultimately entrusting users with understanding how wallets work is destined to fail and opens them up to fraudsters exploiting them - try explaining to a non-technical person how an application like MetaMask works and you'll see why the experience needs to be abstracted away.
3/Custody doesn’t have to be all-or-nothing. We can probably simplify custody through “assisted self-custody.” Assisted requires great product design: minimal setup time, relying on existing devices, and end-to-end reliability. How should we be thinking about assisted solutions?
— jack (@jack) June 4, 2021
We've taken the approach with our current wallet software to give entire control to customers, i.e. if they lose their hardware and their recovery phrase, then they lose everything. For some users though they realistically can't be trusted with that kind of process, purely because it's ultra-technical and still prone to failures (e.g. house fires).
Giving alternative recovery mechanisms is entirely possible, but I think it has to end up being tailored to each jurisdiction because of the local nuances for adherance to the law (e.g. recovering a wallet as part of an estate claim on a deceased holder).
To retain custody entirely with the users, I believe multiple recovery mechanisms are needed simultaneously, and strong key storage tools such as Hardware Security Modules should be leveraged.
4/Most people access the internet on mobile. Any solution we build must provide an excellent experience when using mobile, despite its shortcomings and liabilities. An uncompromising focus on mobile interaction is likely to include the most people. What are the dangers here?
— jack (@jack) June 4, 2021
What we've built around using PIV encryption with commodity hardware meets this need perfectly - phones already have USB ports built in, and products like YubiKeys can be used natively already. It's a perfect match.
But not every phone has the same USB port type. And not every USB-based hardware key has a match for every user. So leveraging trusted key storage mechanisms on the phones is probably the superior approach. The PIV standard has a Derived Credentials mechanism for dealing with just this situation - instead of trying to use the same creds in the hardware as on the phone, instead issue a reduced functionality set of keys to reside in the lower-assurance hardware of a phone.
7/Safety is complicated. For any wallet product, we consider safety failures to stem from one of three types of events: availability failures (“sunken gold”), security failures (“pirated gold”), and discretionary actions (“confiscated gold”). What threats are we missing?
— jack (@jack) June 4, 2021
I think you've really covered the 3 core threats, there's not much to add - most threats to the solutions will fall into a subset of security failures (e.g. device compromise, hardware compromise, phishing, key interception, etc.).
Using standardised hardware and algorithms is a great start to hedging against a lot of threats though.
8/Today’s recovery mechanisms burn money. Customers have to protect recovery information from damage, loss, and theft and store secret(s). In practice, this is not yet mainstream-ready. We don’t want more passwords on post-its. What best of class solutions should we consider?
— jack (@jack) June 4, 2021
I think I covered responding to this for the response to tweet #3.
9/Are small displays necessary? Expecting mainstream customers to validate details on a small display is *unlikely* to increase security and *likely* to reduce device reliability, increase device cost, and decrease accessibility. Is the product better if a display isn't required?
— jack (@jack) June 4, 2021
Absolutely not. Displays on the hardware is dumb - the phone/computer can be the display. Keep the hardware passive, not active. YubiKeys are fantastic for this, with the least impact on accessibility.
10/Trust can’t be required. Today, customers depend heavily on the continued function of infrastructure provided by 3rd parties. We want mainstream customers to be able to lean on us when they want to, but we won’t exclude those who don’t. How should we think about this flow?
— jack (@jack) June 4, 2021
Start with keys managed by the service, with an opt-in if you want to let users take ownership of their own key management and own the risk if they get it wrong. Just give a genuine assurance that opting-in will not result in users keys being held somewhere in old backups.
11/Layer 2 is essential for growth. The orders-of-magnitude growth we imagine requires a mix of custodial, off-chain, and second layer solutions that allow people to ‘get off of 0.’ What tech investments can enable seamless, scalable, L2 native support for a hardware wallet?
— jack (@jack) June 4, 2021
Keys are keys, regardless of the network or layer you're working with. The only work that should be done is interfacing those networks with key storage via a standardised protocol (i.e. an AES+PIV encryption process).
12/Cash App integration is obvious for us but only part of the solution. A smooth experience likely depends on a custom-built app but it doesn’t need to be owned by Square. We can imagine apps that work without Square and maybe also without permission from Apple and Google. You?
— jack (@jack) June 4, 2021
That's the point of picking an open standard like PIV - the encryption and management aspects are univeral, and are just integrated with each provider as needed. You don't need long and expensive integration processes for each connected service.
With that, @jessedorogusker, I, and team will listen and continue the conversation. And we’ll set up a dedicated Twitter and github account if we decide to build. We’ll update this thread with that information when we’re ready. Thanks!
— jack (@jack) June 4, 2021
We are going to open source more components soon as our dev team expands - I know our users want to see it, and I want the assurance provided for the security, but when we do we'll let the world know and it'll be on Github.
If you like how this sounds, why not contact me at tim@congruentlabs.co or on Twitter @SataToken - also check out what we're doing around authentication and authorization with the $SATA project (including the future of managing private identities with YubiKeys).
