@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.
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.
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.
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.
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.
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.
I think I covered responding to this for the response to tweet #3.
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.
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.
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).
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.
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 firstname.lastname@example.org 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).