On replacing hardware wallets
If you read my last article on the state of hardware wallets on Bitcoin SV you should have an understanding of what hardware wallets are actually usable for on Bitcoin SV (BSV).
There were two key take-aways:
- Hardware wallets are mainly useful for cold storage, and have to be operated carefully to ensure that they do not break when they encounter transactions based on the original protocol which BSV has restored in it’s Genesis upgrade.
- Hardware wallet manufacturers do not currently support BSV, and even if they did, it is questionable that the hardware wallets could be used for much more.
The goal of this article is to explore what we might do with a mobile application, in place of the custom hardware device.
Before coming up with a replacement for hardware wallets, let’s define the requirements we have of the replacement.
Verifying the payment is going to the right place
One of the nice features of hardware wallets is the ability to compare the address you see on your computer with the address the hardware wallet asks you to confirm that you want to send funds to.
Unfortunately I suspect many users copy the address from perhaps a web browser to ElectrumSV, initiate the payment and then compare the address in ElectrumSV to the address in the hardware wallet. This is unsafe. There is known malware that can intercept the copy and paste and alter the address before it is arrives in ElectrumSV. The slightly better approach is to compare the address on the hardware wallet to the one in the place you copied it from. In either case, it is possible that if someone has already obtained access to your computer they can probably do a lot better in redirecting your funds.
In the case of a Paymail address, which behind the scenes provides output scripts to pay to, the situation is not much better. Even if comparing the addresses you seem to get from the Paymail service on the device, there may not be any addresses. And this is a general problem, not just limited to Paymail. It’s what restoring the original protocol allows, moving beyond addresses.
Any new solution needs to provide a way of verifying the payment is going to the parties it is supposed to go to, and not by comparing the random looking sets of numbers and letters that addresses effectively are.
One of the things that hardware wallets solve is that they keep your signing keys air-gapped from the computer you are making the payment on. When you have the hardware wallet in your hand and you are pressing it’s awkward little buttons to approve the payment, the chance anything else can access the keys the hardware wallet is using to sign is extremely small.
Software wallets like ElectrumSV and even mobile wallets do not have this protection. At some point they need to get the signing keys into memory to sign with them. In an ideal world there would be a secure Trusted Execution Environment (TEE) where the signing can be done, where the keys are never exposed to other applications. But this TEE has to have support inside it for both deriving keys and signing transactions. Unfortunately, accessing the TEE on a device to run your own code is not possible and if there is secure signing functionality provided it likely does not support the secp256k1 curve Craig chose for Bitcoin. An exception are some Samsung Android phones which have special functionality to do this, but are not suitable for our use because they only understand Bitcoin Core transactions.
A decent article on the subject of software wallets and the problems they have securing the keys was written by Ledger. I recommend you read it if you want to understand the nuances of this problem. One of the conclusions the Ledger team came to was that if the device could access the internet, if it were compromised, the keys could be sent to the attacker. For this reason a secure signing device should not be capable of going online and related precautions should be taken including not “rooting” the device.
Building a theoretical replacement
This is not intended to be guaranteed practical, but rather offer a starting point that may or may not be viable.
Unless an identity is linked to the real world, it is arguably worthless. This likely means that you want a trustworthy service to vouch for an identity, and you want to know that for them to do so there should be solid KYC processes employed.
One way to do this is to make use of the existing certificate system that web HTTPS certificates are based on. Let’s say there’s a company named SOMECOMPANY and they obtain a document signing certificate from Digicert. They also allow customers to sign up, KYC and get data signed and linked to their real world identity. Alice’s wallet accesses SOMECOMPANY and gets her identity public key signed by them. In much the same way that you can open the properties of an ElectrumSV release and see that it was signed by “Bitcoin Association for BSV”, you can see that a standard document stating it is an identity public key and it belongs to Alice is signed by SOMECOMPANY.
Better than addresses
Now when Bob is paying Alice, Alice gives him the necessary information out of which Bob’s wallet extracts the following to provide to the offline mobile application:
- Her signed identity key.
- Alice’s payment details including output scripts and key derivations.
- His own change payment details including output scripts and key derivations.
- The chain of certificates where necessary.
Bob’s wallet would need to understand the script templates it receives in order to be sure that it is verifying all of Alice’s keys within them. And it would want to do the derivations from the identity key for each of Alice’s key, and check the derived keys against the ones in the output scripts.
Bob’s mobile application would show:
- Identity verified by SOMECOMPANY (with green checkmark to show their certificate checked out).
- A list of the recipients (assuming that he may not just be paying Alice) with a green checkmark beside each to show their keys all check out, and that SOMECOMPANY vouched for them.
Now Bob does not need to compare addresses, he can know work out if he trusts SOMECOMPANY and know who he is paying to.
In theory this solves a lot of the problems with existing hardware wallets and provides a solution that should be doable now and not waiting on third party services or future technology to be developed.
- It would support the original Bitcoin protocol restored in the BSV Genesis upgrade.
- It would replace address comparison with something much more user friendly.
There are of course nuances that are not addressed here, because this isn’t intended to be a comprehensive solution:
- Is it necessary to update the root certificates on the mobile application, how often and how best to do this?
- It is likely necessary to upload new script templates to the device, so that it can handle new types of script outputs and be sure it is checking all keys. These can likely be signed on behalf of the application developer using SOMECOMPANY.
Remember this is written just as a thought experiment, it is not guaranteed to be viable. There are possibly unsolvable problems with it.