New Zcash Ledger App + Integration

We propose a fully independent Zcash Ledger app (not based on Ledger’s BTC app) that will support both unshielded and shielded addresses. Zondax will also provide libraries to facilitate further integration with third-party desktop and web wallets.

Background

Support for z-addresses in hardware wallets has proven to be a difficult evasive task. Back in 2018, ZIP 305 described best practices for Sapling support in hardware wallet, however, almost 2 years later the situation seems unchanged and z-addresses are still not supported in Ledger devices.

At Zcon1, str4d presented an early proof-of-concept by running some RedJubJub primitives in Ledger Nano S. Unfortunately, due to memory/stack limitations the immediate applicability of this example code was limited. Nevertheless, Zcash no_std RedJubJub implementation largely facilitated this, and str4d work was a significant step forward.

At the end of 2019, Zondax entered a consulting agreement with the Zcash foundation to complete a feasibility analysis. Main focus was to optimize memory usage, estimate stack usage upper bounds and determine the feasibility of a successful implementation. Zondax also explored a mixed C/Rust implementation, a memory-optimized new implementation and possible issues due to non-constant-time operations in cortex-m0.

In the recent months, Zondax reached out the ZecWallet to discuss cooperation opportunities with respect to desktop wallet integration work. Zondax and Zecwallet have planned to cooperate on integrating the Ledger app resulting from this grant into Zecwallet.

Requirements Summary

• New Zcash independent app ( Not directly based on Ledger’s BTC app )

  • The code will be designed for both Ledger Nano S and X.
  • Bluetooth for Nano X will be initially not supported

• Ledger required features (minimum required to publish in Ledger Live store)

  • Get app version via API
  • UI: Show addresses in the device screen
  • UI: Review transaction fields before signing
  • Sign transaction with user verification
  • Web or desktop wallet integration

• Addresses

  • BIP32/44 derivation
  • Support for both shielded and unshielded addresses.
  • Shielded addresses will be preferred by default
  • ZIP32 support (not included in this grant). ZIP32 requires modifications to Ledger’s closed source. While this could be eventually possible, our recommendation is to start with key derivation based on BIP32/44. This unfortunately will result in non-portable mnemonics between Ledger devices and other ZIP32-exclusive Zcash wallets.

• Transaction format

  • Based on sapling v4 spec

• Signature schemes

  • secp256k1
  • RedJubJub as described in https://github.com/zcash/zcash/issues/3038

• Integration library

  • A Rust library (+ bindings) will provide methods for each APDU/API supported by the app.
  • Support for HID transport

Planned Milestones and Deliverables

Milestone M1. Prototype / Research

- Basic APDU functionality and specs
- Basic project structure and continuous integration
- Initial RedJubJub support (address generation)
- Address Generation / HD support based on BIP32/44
- Secp256k1 signatures
- Basic user interface. On-screen review of transactions is not yet supported

Milestone payment: 35343 USD

Milestone M2. Early Integration Release

-Initial transaction content review 
-Improved RedJubJub implementation and support
-Sapling v4 transaction deserialization
-Reference Rust library + integrations test and examples

Milestone payment: 35343 USD Note: During M2, we expect to start cooperating with Zecwallet on the desktop wallet integration.

Milestone M3. Feature complete

- Complete sapling support
- Complete tx review in UI (for shielded and unshielded addresses)
- Complete integration tests (libraries)

Milestone payment: 35343 USD

Milestone M4. Ledger Review - App Store Release

- Preparation and coordination of the submission
- Guide ZFND on how to initiate a submission
- Adjustments resulting from Ledger’s review process

Price: 4650 USD Delivery: Approval is subject to Ledger's review queue. Zondax will do its best effort to promptly respond to any feedback.

Notes

• We plan to reuse existing Zcash Rust components (redjubjub, etc.) when possible to allow for a seamless upgrade path and future improvements. We will submit PRs upstream, in case we determine that we need changes that are specific to our implementation.

• It is arguable that compilers (LLVM, etc.) may introduce risks with respect to side channel attacks, etc. We have already analysed and considered these issues. Zondax will do its best effort to minimize vulnerabilities, however, we recommend ZFND to run an independent third-party audit on our deliverables.

• Deliverables will include source code, unit and integration tests, continuous integration, etc. All deliverables will be licensed under Apache 2.0.