Keystone 3 firmware

This commit fixes a bug in the firmware's simulator (a software stand-in used for testing, not the real hardware wallet). When checking a stored account password/PIN, the simulator was accidentally returning 'success' even when the password did not match. That caused the wallet to wrongly think every new PIN was already in use, blocking users from creating a second or later account in simulator builds. The fix makes the simulator return a password-error code on mismatch, matching how the real device behaves. It is a functional bug fix in test-only code, not a security vulnerability in the real wallet.

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 upgrades the Rust compiler toolchain from one nightly version to a newer one and adjusts code to keep the project building and tests passing. It does not fix a known security bug or change how user funds are protected. Most of the file changes are new unit tests and small formatting fixes needed for the newer compiler.

This patch changes when a Zcash batch signing screen frees a sensitive internal data structure. Instead of destroying the data immediately when the page is cleared, it now schedules the cleanup to run after the signing operation has finished. The comment in the code says this prevents the destructor from 'overtaking' the signing task, which suggests the old code could have freed memory while signing still needed it. That kind of use-after-free or premature-free bug can corrupt data or crash the device during a transaction, and in security-sensitive signing code it could theoretically affect signature correctness or leak secrets.

This commit fixes a potential memory/resource issue in the Zcash batch signing flow on the Keystone 3 hardware wallet. Before opening the signature view, the code now explicitly frees (destroys) the on-screen review widgets. Without this cleanup, the device could run low on memory or leave stale UI objects around while trying to display the signing screen, which might cause a crash or unexpected behavior during a transaction.

This commit fixes a bug in the Keystone 3 hardware wallet's Zcash support: when a user changed their login password, the encrypted Zcash 'unified full viewing key' (UFVK) was not re-encrypted with the new password. That meant the stored UFVK could only be decrypted with the old password, which could lock the user out of Zcash functions or, in some edge cases, leave sensitive key material protected by a stale credential. The patch adds a routine to re-derive and re-encrypt the UFVK whenever the password changes, and also repairs stale ciphertext automatically at the next login.

This firmware update changes how Keystone hardware wallets handle Zcash batch signing. Previously, the device might have accepted a transaction request that already contained spend authorization signatures. Now it rejects such requests. The concern is that an attacker could craft a Zcash batch transaction containing signatures from another source and trick the device into including them in its final response, potentially making the device vouch for transactions the user did not actually review and authorize. The patch adds an explicit check to block any incoming Orchard or Ironwood spend authorization signatures in batch mode.

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 removes a duplicate entry in a list of internal software signal names used by the device's user interface. The duplicate would have caused the firmware to fail compilation, so the change is a straightforward build fix with no security relevance.

This commit simply switches a software dependency from a temporary community fork back to the project's own official upstream repository. The code being used is the same feature (Zcash batch registry support); it has just been merged into the official repo. There is no indication of a security problem, fix, or vulnerability.

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 Zcash-related Rust libraries inside the Keystone 3 firmware to newer versions. It also makes small code changes so the firmware keeps compiling with the new library APIs, removes some old tests that no longer work with the new wire format, and adjusts how transaction hashes are computed. The commit itself is described by its author as not building in isolation; the remaining matching changes are in the next commit. There is no direct evidence in the commit that this fixes or introduces a security vulnerability.

This commit fixes several bugs in the firmware of the Keystone 3 hardware wallet, mainly around how Arweave (AR) cryptocurrency keys and RSA prime numbers are handled. It replaces direct array indexing with safer lookups, adds checks for missing or corrupted data, stores a hash of sensitive RSA primes in a secure chip, and erases that data when an account is deleted. The changes reduce the chance that a malformed or out-of-range value could cause the device to read the wrong key, crash, or leave sensitive key material behind after deletion.

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 firmware update changes how the Keystone hardware wallet stores and checks device passwords. Previously, the device kept a separate password hash page in its secure element (SE) storage. After this update, password verification is done by trying to decrypt the actual account secret using the password, and the old password hash pages are wiped. The change also removes hard assertions on SE operations so that failures return error codes instead of crashing, and it maps a specific secure-element authentication failure to a wrong-password error. The version number is bumped from 12.4.6 to 12.5.0.

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.