Indeed, that is specifically what I have in mind. Not just for high-security scenarios. I actually see it simply as best practice. The point of having a Ledger device is pretty blurred to me nowadays. I have to trust them not to share my passphrase at this point, this is where we are. In a model such as the one described by @Lixin, they cannot, technically, gather anything from the device, if I update it through the sd-card method. That’s a fundamental improvement already.
1 Like
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.
2 Likes
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 my knowledge, the most common ledger, the “s plus”, does not do such thing. But my point was that, Ledger Live is able to extract the passphrase. So you can add an additional secret word or something, but if they have the passphrase, that secret word would take no time to bruteforce. That is unless you make it very long and complex, like a 12 words passphrase, but at this point the UX is starting to take a severe hit.
Let me use a maybe better and more precise example of what I would see as best practice for a regular user: connect the hardware wallet management software to your node or a trusted one, and with LittleSnitch or whatever firewall you use, deny all connections aside from that node you have selected. That’s it, already so much more secure. It’s something I could see most people doing as best practice, without getting into tinfoil hat practices.
1 Like
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.)
1 Like
That’s how ywallet can use the Ledger device in air gapped mode. You would have 1 online ywallet with the full viewing key that scans the blockchain and maintains your account balance and notes; 1 offline ywallet creating the proofs; and 1 ledger connected to the airgapped wallet.
When you make a TX, it creates a file or series of QR codes that have all the parameters, such as input amounts, Merkle paths, etc.
You transfer the file or scan the QR codes on your offline ywallet. It can compute the zk proofs but does not have the secret keys to sign the inputs.
That ywallet transfers the tx parameters to the Ledger and uses ZIP 244 for security (and performance, ZIP 244 allows the app to scale up to an unlimited tx complexity). Once the user validates, the signature is returned to the offline wallet, which combines the raw transaction.
Then, the data is sent back to the first ywallet (file / QR codes again) and transmitted via SendRawTransaction to lightwalletd.
To be clear, this workflow is implemented and tested.
3 Likes
This is a different workflow to what @daira described, which is to transfer blockchain updates to the offline wallet, and have the offline wallet do scanning.
Having an online wallet doing scanning and an offline wallet doing proving has minimal benefit, for two reasons:
- Full viewing keys by definition give viewing capability for the private information of the wallet. Thus the online wallet still has to be trusted with the user’s privacy in this workflow.
- In the case of Orchard, the full viewing key is also a capability for creating proofs, so the online and offline wallets have identical capabilities in this regard. (For Sapling there exists a separate proof creation key that is between the spending and viewing keys, but functionally this distinction is not useful due to the aforementioned fact that the viewing key itself confers a privacy trust assumption).
The main benefit you get from this workflow is that the Ledger’s USB connection is to an offline wallet, which is a good benefit! But Keystone uses QR codes for data transmission, so that particular attack vector is not present, and thus the offline wallet is not necessary if you are already trusting the online wallet with your full viewing key. Given that the online-offline-hw pathway is tested, it should be relatively straightforward to collapse that into an online-hw pathway.
2 Likes
I actually had a tool for that, but that means copying hundreds of GB of raw blockchain data to the offline computer.
Edit: the QR code approach doesn’t work if the two devices aren’t near each other, ie if someone is custodian for a friend.
1 Like
If the wallet assumes be the only custodian of these particular funds, then its equivalent to the current spend before sync and there you go, but it’s kind of the same problem again with multiple seed instances. (And we did videos on Ywallet coldwallet and Ledger and they work good)
Our firmware is open source under MIT license. It can be rebuilt and verified. We do rely on some lib from MCU vendor. Because this MCU has some optimization on it, which is the main reason we choose it. I don’t think we can remove those dependencies.
2 Likes
Yes we do support that! And one thing worth mentioning is that Keystone 3 Pro can hold 3 recovery phrase simultaneously and users can access them through different PIN codes.
With that being said, users can have one BIP39 recovery phrase for Bitcoin, Ethereum and other cryptocurrencies. And one special one which is not BIP39 compatible for Zcash.
4 Likes
Check our JS SDK here
https://www.npmjs.com/package/@keystonehq/keystone-sdk
https://dev.keyst.one/docs/integration-guide-basics/install-the-sdk#webextensionreact-native
And Ywallet or Zingo can of course implement this integration through QR and we are more than happy to give whatever tech support they need.
Thanks! We will do our best, for sure.
2 Likes
Awesome! Thanks for the responses!
No it doesn’t. A pruned and/or spam-filtered copy of the chain would be sufficient. If we care only about the offline wallet spending from Orchard notes that remain after spam filtering, for example, then we only need the commitments and nullifiers for those (along with some other data needed to update the commitment tree, but that is relatively small). We don’t need proofs or signatures, and we can use the FlyClient support that was added in Heartwood to verify that we have a plausible chain (I think, and if there’s any problem with that we could fix it).
What matters is that the remaining anonymity set of filtered note commitments, nullifiers, and note ciphertexts (I’m handwaving slightly here) is both large enough, and includes the ones for the user’s notes.
It does: take a video of the animated QR code, send it through Signal or whatever, and play it back. (I believe the protocol has sufficiently few rounds for this to be feasible; you might need videos sent in each direction. It might also work on a video chat, but I’ve had problems getting even non-animated QR codes to scan via a webcam.)
1 Like
To clarify, Zcash does use BIP 39. It’s the derivation from the seed output by BIP 39 that is different.
3 Likes
Ok. Thanks so much for clarification.
1 Like
but how would you know how much filtering is acceptable?
I thought you were against any kind of spam filtering for example.
well, if you send the video file by a digital media, then there is a risk that this channel is compromised .
I am not sure I see the advantage vs using a pbst like file.
I was just looking through KeystoneHQ/keystone3-firmware and couldn’t immediately see where those dependencies are declared. It would be good for that to be documented and linked from the README, so I opened an issue for that:
1 Like