Keystone 3 firmware

This commit removes a weak, predictable random-number generator that was bundled as a backup inside the firmware's SLIP-39 code. Previously, if the device's proper hardware random source was accidentally left out of a build, the firmware could silently fall back to the weak generator, which would make wallet backup seeds predictable. Now the weak generator is gone for hardware builds, so a missing proper random source causes the build to fail instead of silently producing insecure seeds. The simulator still keeps a simple software-only stub for testing.

This commit fixes a bug in the Keystone 3 hardware wallet's Zcash shielded transaction signing. Previously, when a user reviewed and approved a transaction for one account, the device could accidentally authorize a spend from a different account controlled by the same seed. The patch now checks that every shielded spend belongs to the account the user actually selected, and rejects the transaction if any spend comes from another account. This prevents an attacker or buggy wallet software from tricking the user into signing a spend from an account they did not review.

This commit fixes a bug in the Keystone hardware wallet's Zcash signing code. When signing a batch of Zcash transactions that include 'dummy' placeholder spends (zero-value decoy actions used for privacy), the signer could get stuck or fail because it tried to re-sign a dummy spend whose signature had already been finalized and then stripped for transport. The fix tells the signer to skip these finalized zero-value dummy spends, allowing the real spend to be signed normally. The changelog frames it as a fix for batch signing with finalized zero-value dummy spends.

This commit is a simple rename of an internal function from `sign_pczt_to_pczt` to `sign_and_redact_pczt` in the Zcash Rust code. No behavior, logic, or security properties changed; it only makes the function name more descriptive. There is no security issue here.

This is a large firmware commit for the Keystone 3 hardware wallet that restructures how the secure element (SE) chip is used. It introduces a generation-aware backend so the firmware can support two different SE configurations (gen-1, the current fielded design, and gen-2, a new production design) in one binary. The patch moves legacy gen-1 key derivation into its own file, adds a gen-2 backend with a different key-derivation scheme, adds lifecycle status pages so interrupted wallet create/change-PIN/delete operations can be safely resumed or erased at boot, and adds UI flows for weak-passcode warnings and a 'forget password' ownership-proof step. It also gates the legacy page-8 wipe to gen-1 only so it cannot accidentally erase gen-2 data. The commit is described by its authors as scaffolding with no runtime change for current gen-1 devices, but it does add substantial new crypto and state-machine code.

This commit fixes a crash in the Keystone hardware wallet when signing certain advanced Zcash transactions. The previous code used a heavy upstream signing helper that needed too much memory, causing the device to reset during an Orchard-to-Ironwood migration. The patch replaces it with a leaner, in-house signer and adds the new v6/Ironwood hash logic needed to keep signatures valid. It also rejects v6 transactions containing Sapling spends because the lean signer does not yet support that specific hash domain.

This commit adds a new Zcash batch-signing feature for shielded transactions and fixes a UI bug where Zcash signing could freeze if the response QR code could not be generated. The changes introduce new Rust code to validate, parse, and sign batches of Zcash PCZT messages, plus new C UI screens to review and approve those batches. It also tightens error handling so that QR/USB generation failures are reported instead of leaving the device stuck. There is no direct evidence in the commit of an exploitable vulnerability, but the size and complexity of the new signing path means it should be reviewed carefully.

This commit updates the user interface and internal checks for generating wallet seed phrases using dice rolls as a source of randomness. It enforces a minimum number of dice rolls depending on the desired seed strength: at least 50 rolls for 12-word (BIP39) or 20-word (SLIP39) seeds, and at least 100 rolls for 24-word (BIP39) or 33-word (SLIP39) seeds. Previously, the firmware only required 50 rolls regardless of seed length. The change is a security hardening measure to ensure that higher-strength seeds receive enough physical entropy, but it is a partial patch because the dice-roll input itself is not fully validated and the entropy extraction method is not visible in this diff.

This commit removes support for the 'Leap' wallet from the Keystone 3 firmware. It deletes the Leap wallet icon and asset, removes Leap-related text strings from Chinese, Japanese, and Korean font files, and updates the Rust dependency versions for the UR (Uniform Resources) parsing libraries used by the firmware. There is no indication of a security fix or vulnerability being patched.

This commit changes how the Keystone hardware wallet enables Zcash for SLIP 39 wallets. Previously, Zcash was completely disabled for all SLIP 39 wallets. Now it is allowed when the SLIP 39 shares are 33 words long (256-bit entropy), but still disabled for 20-word shares (128-bit entropy). The change is driven by a cryptographic requirement: Zcash's security analysis assumes the wallet seed has at least 256 bits of entropy. The patch also fixes a small UI bug where the 'manage' option for Zcash was missing entirely for non-BIP39 mnemonics, instead of being shown as disabled.

This commit adds a new way for the Keystone hardware wallet to handle Tron (TRX) transactions sent as plain JSON sign requests, alongside the older Keystone-specific format. It introduces code that parses JSON, derives the sender address from the seed, checks it matches the 'from' field, and signs. The change is a feature addition, not a clearly labeled security fix. There are no obvious catastrophic bugs in the diff, but the new path adds complexity and a few places where input validation could be tightened.

This commit adds support for the Core Wallet in the Keystone 3 firmware. It mainly expands the number of Avalanche X/P-chain derivation paths from one to ten, updates the Rust SDK dependency, and changes how signing requests extract derivation paths and fingerprints. There is no explicit security fix or vulnerability disclosure in the commit message or diff. The changes are feature-oriented, but they touch sensitive code paths (transaction signing, HD path handling, and master-fingerprint checks), so they warrant careful review.

This commit adds support for the Core Wallet in the Keystone 3 firmware. It mainly expands the number of Avalanche (AVAX) X/P-chain account paths from one to ten, updates the Rust signing code to accept multiple derivation paths from the wallet instead of hardcoding a single one, and bumps the Rust UR registry library version. There is no explicit security fix or vulnerability patch visible in the diff; it reads as a feature/integration change.

This commit removes the special 'TON-only wallet' feature from the Keystone 3 firmware. It deletes code that let users create or import a TON-native 24-word seed phrase separate from the normal BIP39 wallet. After this change, TON is handled like other coins using a standard BIP39-derived key. There is no security bug being fixed here; it is a feature-removal cleanup.

This firmware update for the Keystone 3 hardware wallet is billed as a security improvement. The most important change is a complete rewrite of the bootloader/firmware update path: it now uses SHA-256 and a signed/length-prefixed 'bootupdate' envelope instead of the older MD5-based verification, and removes an old USB mass-storage auto-reboot behavior that could let a plugged-in host trigger a reboot just by copying a file. The patch also hardens the USB stack against malformed endpoint numbers and oversized control transfers, enables on-chip flash encryption for the external QSPI flash, and improves I2C and random-number error handling. However, the diff is very large and mixes many unrelated features (new wallet icons, X Layer chain support, UI tweaks), so it is hard to be certain every corner case is fixed.

This commit is a large firmware update for the Keystone 3 hardware wallet, primarily adding a bootloader update mechanism and hardening the USB stack. It introduces a way to overwrite the device's bootloader from a specially formatted region of flash memory, enables hardware-level flash encryption for production builds, and adds many bounds checks and validation routines to the USB device driver to prevent malformed host requests from crashing or confusing the device. The commit also removes the MD5 checksum code entirely and improves I2C and secure-element error handling.

This is a one-line build-configuration fix for the Keystone hardware wallet's Zcash signing code. Previously, transparent Zcash transaction signing was only enabled when the 'multi_coins' feature was active. The change also enables it when the 'cypherpunk' feature is active. Without this fix, Zcash transparent signing simply fails to compile or run in cypherpunk-only builds. There is no direct evidence in the commit of a security vulnerability; it appears to be a missing-feature bug.

This is a one-line build-configuration fix for the Keystone hardware wallet's Zcash transparent transaction signing. Previously, the code that signs the transparent (non-shielded) part of a Zcash PCZT transaction was only compiled when the 'multi_coins' feature was enabled. The change also enables that signing code when the 'cypherpunk' feature is enabled. Without this fix, a device built with only the 'cypherpunk' feature could produce an incomplete or invalid Zcash transaction signature, likely causing the transaction to be rejected by the network rather than stealing funds.

This commit adds support for a new wallet partner called Gero Wallet in the Keystone 3 firmware. It is a routine feature addition: a new icon, a new entry in wallet lists, a tutorial link, and recognition of the wallet's origin name when handling key-derivation requests. There is no indication of a security fix or vulnerability.

This commit fixes a product limitation: Keystone 3 hardware wallets using a SLIP39-style recovery phrase could not connect to the Keystone mobile app for Zcash. The patch removes Zcash from the list of coins shared when a SLIP39 wallet is used, and it makes the underlying Rust code accept a missing Zcash seed fingerprint. There is no direct evidence this is a security vulnerability; it appears to be a compatibility/functional bug fix.

This commit fixes a build-configuration bug that could prevent creating or saving public key information when using a SLIP39 passphrase. The old code accidentally skipped the normal key-derivation path for certain crypto types in non-Bitcoin-only builds, which could leave required public key data unset and cause account setup to fail. The patch restructures the conditional compilation so each build variant (Cypherpunk, Web3, Bitcoin-only) follows the correct derivation branch.

This commit is a large refactor of how the Keystone 3 firmware handles Zcash transactions. It splits the code into two build flavors: a 'multi-coins' build that supports only transparent (public) Zcash addresses using a normal xpub, and a 'cypherpunk' build that also supports shielded Orchard addresses using a unified full viewing key (UFVK). The change reorganizes feature flags, renames functions, and adjusts how Zcash account data is cached when wallets are created or unlocked. There is no explicit security fix or vulnerability disclosure in the commit message, and the diff itself is mostly structural. A few small items stand out as worth checking: a typo in a feature-guard macro (CYBERPUNK_VERSION vs CYPHERPUNK_VERSION) could leave the cypherpunk UI path disabled, and a debug printf was left in production key-handling code. On its own, this commit does not appear to introduce a clear exploitable vulnerability, but it is a partial refactor and the new multi-coins transparent-only path is simpler and exposes less shielded-key material than before.

This commit adds support for the Zcash (ZEC) cryptocurrency to the Keystone 3 hardware wallet firmware. It introduces address generation, derivation path handling, UI elements, and wallet connection data for Zcash. There is no indication of a security fix or vulnerability being patched.

This commit is a work-in-progress 'temp commit' that refactors Zcash support in the Keystone 3 firmware. It moves Zcash UI code from a 'cypherpunk' build variant into the standard multi-coin build, splits a combined Zcash UFVK/seed-fingerprint getter into separate functions, adds a new Zcash seed fingerprint parameter to the Keystone Connect wallet QR/UR generation, and enables the 'zcash' feature in the Rust multi-coins build. There is no clear security fix or vulnerability being patched; it appears to be feature plumbing and code reorganisation.

This commit adds support for Litecoin (LTC) native SegWit addresses (the 'ltc1...' format) to the Keystone 3 hardware wallet firmware. It is a feature addition: it lets users generate and display a new type of LTC address and export the corresponding public key. There is no indication in the commit that it fixes a security bug or vulnerability.