Keystone 3 firmware

This commit only changes two version numbers in a header file: the build number goes from 0 to 1, and the beta flag goes from 1 to 4. It does not modify any executable code, fix any behavior, or address any security issue. It is a routine release bookkeeping change.

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 update fixes how a Keystone hardware wallet calculates the on-screen totals for Zcash transactions. Previously, the firmware used plain addition that could silently overflow or accept impossible totals (for example, showing more change than was sent, or more money leaving the wallet than entered it). Such a malformed transaction could make the user approve a transfer that does not match reality. The patch now rejects those cases before anything is shown for signing.

This commit changes the factory-reset/wipe routine in a Keystone hardware wallet's startup self-check. It replaces one wipe step with a call to wipe the secure element (SE_WipeAll) and moves the 'ErasePublicInfo' step to occur after account destruction and flash erasure, right before the device reboots. The stated goal is to fix a problem where losing power during a wipe could leave sensitive data partially intact. The change is defensive, but because it is a partial patch and the commit message is terse, we cannot fully verify that the new ordering eliminates all power-loss recovery risks.

This commit fixes a page-number overlap in the secure-element storage layout and updates a user-facing help string. Previously, the RSA hash page was defined as page 36, which was also used for account status. The change gives the RSA hash its own dedicated pages (39-41) so the two purposes no longer share the same storage page. The string change makes it clearer that entering another wallet's PIN/password is part of resetting a forgotten passcode, and that failure wipes the device. The commit itself does not show an attack path, but it removes a condition that could have caused data corruption or misinterpretation of wallet state.

This commit is a routine feature patch for the Keystone 3 hardware wallet. It resumes adding the device's firmware version into Zcash wallet connection data, and it fixes two simulator-only bugs: a keyboard crash when a text box is destroyed and a timing mismatch in how background tasks are run during desktop testing. There is no direct evidence in the commit that these changes fix an active security vulnerability, and the commit message describes them as ordinary development work.

This commit only rewrites a code comment in the Zcash PCZT validation logic. It clarifies why the code checks that certain cryptographic keys are not reused across Orchard and Ironwood 'pools.' The actual validation behavior does not change, but the new comment suggests the previous mental model—worrying about cross-pool signature copying—was slightly off. The change itself is documentation-only, so it does not fix or introduce a runtime vulnerability.

This commit is a small code cleanup in the Zcash part of the Keystone hardware wallet firmware. It changes how the code checks for duplicate 'rk' values across Orchard and Ironwood shielded transaction actions. The old code used chained iterators and cloned them repeatedly; the new code collects the actions into a vector first and then uses nested loops. The behavior appears unchanged: it still rejects duplicate rk values with the same error message. There is no direct evidence in the commit that this fixes a security bug.

This commit only changes on-screen text shown during the 'Prove Device Ownership' step of a password reset. The new wording warns the user that entering the wrong PIN/password too many times will wipe the device. It does not change any security logic, attempt limits, or wipe behavior—only the user-facing warning message.

This update fixes a flaw in how the Keystone hardware wallet checks Zcash private transaction proposals (PCZTs). If the same random verification key ('rk') appeared in two different spending actions—either two Orchard actions or one Orchard and one Ironwood action—the device would not notice. Because both action types sign the same overall transaction digest, a valid signature for one action could be copied and reused for the other, potentially letting an attacker authorize a spend they should not. The fix makes the wallet reject any PCZT that reuses such a key across actions.

This commit only removes two unreleased changelog entries from a markdown file. No source code, firmware logic, or security behavior was changed. It is a documentation cleanup and has no security relevance on its own.

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 changes how the Keystone hardware wallet summarizes Zcash batch transactions that include both ordinary payments and migration (Orchard-to-Ironwood) self-transfers. Previously, if a batch had more than one ordinary transaction alongside migrations, the wallet showed every transaction in full. Now, it still shows each ordinary transaction in full but compacts all migrations into a single summary page. The change is described as a fix for handling 'split transactions' alongside migrations, but the commit message and diff do not explain any security vulnerability.

This commit is a performance improvement for Zcash batch signing on the Keystone 3 hardware wallet. It avoids re-checking the same transaction data twice by caching a 'signability decision' from the review step and reusing it during signing. The change also adds integrity checks so the cached decision can only be used with the exact normalized transaction bytes and wallet context it was created for. The CHANGELOG frames it as an improvement and a bug fix for stalled signing when QR generation fails, not as a security fix.

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 updates the firmware's Zcash batch signing result to use a new typed encoding for the firmware version field. It is a routine dependency bump and code adjustment to match a changed SDK API. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a correctness or compatibility change.

This commit only changes a code comment to make it clearer where a particular 3-byte version format is used. No actual code behavior was changed, so it cannot introduce or fix a security issue on its own.

This commit only updates comments and documentation to make clear which firmware version number is sent over the wire for Zcash signing. It does not change any code behavior, so it is not a security fix and does not introduce a vulnerability.

This commit adds the firmware version number to Zcash batch signing responses. It is a feature/documentation change, not a security fix or vulnerability. The version was already included in single-transaction responses; now it is also included in batch responses so wallets can identify which firmware version produced the signatures.

This commit only changes the firmware version numbers in a header file (from 12.4.9 beta 2 to 12.5.0 beta 1). It does not modify any executable code, fix any bug, or change any security behavior. There is no security relevance visible in the diff.

This commit is a performance and user-experience improvement for Zcash batch transactions on the Keystone 3 hardware wallet. It speeds up processing of multiple Zcash PCZTs by caching decoded viewing keys and spend-authorization keys across the batch, instead of re-deriving them for every transaction. It also adds a loading hint telling users that batch processing may take a few minutes. There is no direct evidence in the commit of a security vulnerability being fixed; the changes appear to be a refactor with added tests and UI feedback.

This commit adds a safety check for Zcash batch transactions on Keystone hardware wallets. Before fully parsing a batch of PCZT (Zcash transaction) data, the firmware now reads the declared number of items and rejects it if it exceeds 50. This prevents the parser from trying to allocate memory for an absurdly large number of items based solely on attacker-controlled input, which could cause memory exhaustion or a crash.

This commit refactors how Keystone's Zcash batch signing feature handles large batches. It replaces an older message envelope with a new format that uses the upstream Zcash PCZT batch signer, adds a 512 KiB total size cap, raises the maximum PCZT count from 35 to 50, and returns only compact signatures instead of full signed PCZT data. It also updates several Zcash Rust dependencies from a fork to upstream releases and tightens some digest helpers to handle missing optional fields safely. The changes are framed as a feature improvement and hardening, not as a fix for a known active vulnerability.

This commit only changes a code comment in a Zcash-related Rust file. It does not modify any actual program logic, function behavior, or memory-management code. The new comment explains more clearly that certain memory must be freed through a specific C-style free function rather than Rust's normal cleanup, and warns that leaving the function early after partial conversion would leak memory. There is no code change to fix or introduce a leak.

This commit rewrites how a Zcash wallet's firmware summarizes batches of migration transactions on its screen. Previously, the code assumed the first message in a batch was an ordinary transaction and all later messages were migration-style transfers, then folded only those later messages into a compact summary. The new code inspects every message individually and decides by its actual contents whether it can be compacted. This makes the review order-independent and avoids mis-classifying a batch when the first message is actually a migration or when there are multiple ordinary transactions. The change is a defensive refactor rather than a clear-cut vulnerability patch, but the old design could have led to misleading on-device transaction summaries if a batch were presented in an unexpected order.