Add QR code scanning between software wallet & cold signer (hardware wallet)

[Lixin]

Hi Magicians.

I am Lixin from Keystone hardware wallet. As a user, we are not satisfied with the current signing solution for DeFi (Ledger + MetaMask). We came up with a new solution for it.

PoC

We forked MetaMask and created a PoC for QR code signing between our hardware wallet Keystone and the browser extension.

Motivation

• USB connectivity could break from time to time. QR code causes much less compatibility issues. Much better experience not only for users but also for developers.
• With QR code, users can easily turn their old mobile phone into a offline signing device turning on airplane mode with app like Airgap. (Note: another great QR based hww is Ngrave and they share the same opinion with us.)
• With big screen & ABI encoding, complex DeFi transactions can be fully verified on the cold signer (hardware wallet) otherwise the user is blindly trusting the software wallet which can be compromised much more easily compared to the cold signer (hardware wallet). GridPlus is fixing this vulnerability too and they are awesome.

Importance of Composable Wallets

Personally I really agree with Andrew Hong’s view about wallets.

• Cold signer (hardware wallet) should be specialized on “Security Layer” in the ecosystem.
• Cold signer (hardware wallet) should be as compatible as possible with other software wallets.
• ABI encoding is an essential part for cold signer (hardware wallet).

Next Steps

1. We are talking with MetaMask, xDeFi and GasNow for integration.
2. We will raise an EIP for the standard of QR code protocol between cold signer (hardware wallet) and software wallet. More details will be posted within this week or next.
3. Adding more ABIs to our product (firmware update is needed).

Please throw me any questions/concerns you have. All ears here

[matt]

As a user, we are not satisfied with the current signing solution for DeFi (Ledger + MetaMask). We came up with a new solution for it.

IMO, the QR flow is interesting and maybe easier for some users than connecting over USB, but it doesn’t solve what happened to the Nexus Mutual founder.

What does solve that is supporting ABIs in hardware wallets.

I’m curious how you guys go about adding ABIs? Does your team review ABIs for popular applications and then bundle them with your firmware? Do you allow your users to use their own ABIs? Why don’t other hardware wallets have this functionality?

[dstreit]

+1 For making it easier to sign from an air-gapped wallet, with much better understanding of what I’m signing.

Have you checked out Parity Signer?

[Lixin]

100% agree.
With QR code, every piece of information getting in&out of the device is auditable/verifiable.

Keystone

re Parity Signer -
Yes we know it. It’s a great tool but it seems like it’s not actively maintaining (correct me if I am wrong).

For making a offline mobile phone into a cold signer, airgap.it is actively working on that. And they will align their QR protocol with us so we can be compatible with the same software wallets and ETH community will have much more options.

[Lixin]

Thanks for those questions.

Yes. QR code only solves the problem of USB’s bad connectivity.

To solve the Nexus Mutual founder’s problem, these are needed:

• Big screen for easily verifying complex DeFi transactions.
• Embed ABIs into hardware wallet

And yes we are working on this.

From the video in the tweet you can see we embedded the ABI of Uniswap V2 and shows the details of the unsigned swap transactions. You can also check the screen shot below (we even highlighted the swap destination address if it’s not consistent with your from address).

Does your team review ABIs for popular applications and then bundle them with your firmware?

KeystoneHQ/Keystone-cold-app

These are the ABIs we have added. And we are adding more.

Do you allow your users to use their own ABIs?
This is doable and we are researching for a proper solution for it. It needs some time because this may involve some security issues.

Why don’t other hardware wallets have this functionality?
Just my 2 gwei -

1. Most hwws are “stateless” design. They minimize what to store on the device. This design is kind of out-dated as blockchain develops really fast. To fully verify more and more complex transactions you have to store something more than just seed or private keys.
2. As I mentioned above, storing ABIs is not enough. UX wise, big screen is a must. It doesn’t make too much sense by just adding ABIs. This might be the reason why they are not doing this.

[Aaron]

Hi the ethereum magicians, I am Aaron from Keystone Team.
These days we are working with Metamask for the integration. The integration PR has been merged. (Introduce QR based signer into MetaMask by aaronisme · Pull Request #12065 · MetaMask/metamask-extension · GitHub).
We would like to propose the new ERC idea for the QR code data transmission protocol.

see here: EIP-Draft: QR Code data transmission protocol for the Ethereum wallets by aaronisme · Pull Request #4527 · ethereum/EIPs · GitHub

[Lixin]

The integration between Keystone hardware wallet with MetaMask will be the first implementation of this drafted EIP.

The integration will be release on Dec 10th, 2021.

Here is a quick demo for the workflow - Using MeaMask with Keystone Hardware Wallet - 100% Air-gapped Signing with QR Code - YouTube

Currently airgap.it and Ngrave are both following this EIP to be compatible with MetaMask.

[d10r]

Thanks for this EIP! I have a question:
Would this support the use of private keys? I have a bunch of keystore files and private keys which I’d love to airgap, but so far haven’t found a way to do so because afaik no HW wallet supports private key import. The usual recommendation is to move funds over to a new, mnemonic based, account. But for old accounts with a lot of different tokens accumulated, some of which deposited in protocols, that can easily translate to xxxx $ worth of tx fees.

My limited understanding of BIP32 and this EIP suggests it may not work with private keys either.
Is that the case? If so, is there a good reason for not supporting the use of private keys? Could the EIP be changed / extended to have that supported too?