Of course we will do this!
And we can also make a special version with Zcash-theme image on the back of the device. You can check this (our special version for Bitcoin Halving 2024) as a reference -
I am not 100% sure how to realize this but I will consult our friends in the ECC team.
The signatures are over the effecting data of the transaction, which will be passed to and verified by the user on the offline device.
The specific answer depends on what you mean by âfraudulentâ or âtampered withâ. In general, two aspects constrain the online wallet:
There are things that the online wallet is trusted with, however - specifically, privacy. In the extreme, the online wallet can take the private data for the transaction and publish it âout-of-bandâ on Pastebin. More subtly, the online wallet could select bad or malicious randomness to create proofs that arenât correctly zero-knowledge (they would still satisfy correctness and soundness). Without the ability to create proofs on the offline wallet (which is not possible for any of the hardware wallets currently available), this privacy trust assumption is fundamentally necessary, because the device that creates the proofs necessarily sees the private inputs.
But from the perspective of controlling spend authority, the signature digest constrains everything that matters, and the hardware wallet can refuse to produce a signature until it has received sufficient information from the online wallet that it knows what it is signing.
Thanks @nuttycom and @str4d especially for spelling it out. My main concern is ensuring that the user consenting to the transaction presented on the hardware wallet can validate and be confident in what is being processed. I see how this should be addressed, so thank you.
Hell yeah!
Thanks for your application @Lixin.
Chainsafe was recently approved funding to develop a Zcash MetaMask snap. Would this work also allow for a MetaMask snap to easily integrate with the Keystone hardware wallet?
The grant we are applying is adding Zcash support on Keystone.
Then developers from ECC will add Keystone support on Zashi Wallet. This part is done by ECC team which is not included in the grant.
If Chainsafe team adopt the same open QR protocol like Zashi, the Zcash MetaMask Snap can be integrated with Keystone, to make Keystone a signer for that Snap.
I hope I have explained well for the question you asked.
@Lixin Thanks for submitting the grant. Zcash is short on Hardware Wallet support so itâs super strategic that we can count with a neat solution like Keystone.
I see the QR code integration as a good advantage for integrating with wallets that have access to a camera. Connecting to a device via USB or bluetooth is not only risky but also itâs complicated technically because every operating system and platform has its own policies, drivers, SDKs, APIs and many etceteras whereas the QR code seems a way to avoid all of that platform specific stuff.
What would be the trade-offs that your team has evaluated in terms of this approach? Could you point me to the productâs threat model if you have one?
The grant specifies that you would integrate to ECCâs Zashi first (thatâs ok, ledger chose a specific wallet for their first integration as well). What is your estimated effort that other wallets would have to do to integrate as well? do you plan to work on tooling to facilitate that or is that outside the grantâs scope? If so would you be open to collaborate on that?
Probably with liberated key exchange but transaction expiry would hinder signing transactions to be broadcast in the extended future.
Could you please comment on the following binary blob present in your repository?
Hey @pacu Thanks so much for your kind words and your questions!
Here are my answers -
What would be the trade-offs that your team has evaluated in terms of this approach?
Could you point me to the productâs threat model if you have one?
We donât have a documentation for that. Aside from what you mentioned about platform specific stuff, QR wonât suffer from this attack surface - https://www.youtube.com/watch?v=BZnflNZB3bw
What is your estimated effort that other wallets would have to do to integrate as well? do you plan to work on tooling to facilitate that or is that outside the grantâs scope? If so would you be open to collaborate on that?
If anything is still unclear, please let me know.
Keystone can be used â100% offlineâ means:
Thanks for pointing it out.
This is the QR recognition library developed by our MCU vendor and we canât open-source this part (not our code). They did some deep optimization for quicker QR decoding. And this library is audited by us, just for decoding QR, nothing else. But we canât open-source it. Hope you can understand this.
Not to say you can open-source it, yet itâs under your firmware repository and clearly not open-source. Do you believe advertising your firmware as open-source is still fair accordingly? Whatâs the delineation of your firmware and any binary blobs in this discussion? Are there other closed source components?
This is exciting, I also look forward to this and hope itâs funded.
The timeline seems too optimistic, but at this point I would be OK missing deadlines as long as it is delivered.
Zcash uses a custom derivation to turn seed phrases into key material for shielded wallets, does that work with your security architecture?
Thanks for your detailed response @Lixin!
I meant other wallets that are not powered by ECC SDKs like Ywallet or Zingo. Sorry for not being specific enough. 
Does Keystone have a react-native SDK?
100% agree with Conrado here! Excited but also concerned about the optimistic timeline. It would be awesome, yes, but I think it might take a bit longer considering processes, reviews, audits.
Best of Luck!
I think it depends what you mean by âfully offlineâ. According to this post on their support forum, you can do this:
Creating and broadcasting raw transactions (when you are not connected to any network)
To create raw transaction data:
- Create a new transaction with Broadcast set to off.
- Click on Sign.
- Review all details on your Trezor and confirm that they are correct.
- Copy the signed transaction data or save it as a text document. Close the window.
and then send the raw transaction yourself, or via a service that does so. I have not confirmed that this works or what caveats there are (I assume that Trezor Suite needs to have been connected to the network in order to get recent blockchain state, but neednât be connected while it is creating and signing the transaction).
My experience is that updates to Trezor Suite are pretty frequent, but you can install those manually rather than via the auto-update if you want. Of course Trezor and Trezor Suite do not currently support Zcash shielded transactions at all.
I agree that the ability to implement a complete air-gap between the network and the wallet (not just the Keystone device, the full wallet application as well), where you get updates to the blockchain via a file and save the transaction to a file, would be incredibly useful for some high-security scenarios. The implementation of that is kind-of orthogonal to the h/w wallet support, but of course you still need a wallet that supports both in order to be able to do both types of isolation at the same time.
I donât know whether that would fit as a feature for Zashi (which has so far been designed as an on-line wallet), but a great thing about this grant is that, with some feasible wallet-specific work, any librustzcash-based wallet should be able to take advantage of it.
Note that a fully offline wallet like @daira describes cannot run on the Keystone device, because of computational limitations (it cannot create proofs). However, you could indeed have a fully offline wallet on a device that can create proofs, that still uses Keystone for spend authority.
Trezor does the one-time pad thing where the h/w wallet display shows a permuted keypad and you click the corresponding positions on the keypad displayed by Trezor Suite. That should be sufficient to hide the PIN from Trezor Suite, modulo the limitation of it being a numeric PIN. Does Ledger not do that?
And yes, a device with a big touchscreen like Keystone is fundamentally more usable. The one-time pad trick isnât awful but most people only use short PINs. (Even though Trezor Safe 3 does support up to 50-digit PINs apparently; not sure about earlier models. Itâs harder to remember a numeric PIN reliably though. I guess you could write down part of the PIN and remember part of it.)
To fill in a small detail: in the Bitcoin transaction format, and therefore also in the transparent parts of the Zcash transaction format, a transparent input does not explicitly encode its value. It only points to an output from some previous transaction. However, the âeffecting dataâ that is signed does commit to the input values, as of v5 transactions. Zcash started using this approach with ZIP 244, which activated in NU5. A Zcash hardware wallet could just always use v5 transactions, or alternatively it could always use shielded inputs (if it supports that), for which the sum of all shielded input values has always been explicit.
Even without this, the h/w wallet can infer that the total value of inputs plus fee matches the total value of the outputs, by definition. The issue that motivated the change in BIP 341 or ZIP 244 is that the fee is also not explicitly encoded, in either Bitcoin or Zcash. Weâll fix that as well in Zcash at some point, I think in NU7. (It was a candidate change for NU6 but we decided not to do a transaction format change.)
