Keystone 3 firmware

This is a large firmware release merge (v3.1.0) for the Keystone 3 hardware wallet. The visible changes are mostly a major FreeRTOS kernel upgrade (from v10.x to v11.3.0), build-system improvements, and user-facing feature tweaks such as better IOTA/Cardano transaction parsing and setup reminders. The vendor changelog explicitly says 'Enhanced security policies' and 'Optimized USB functionality,' but no specific vulnerability, CVE, or security bug is described in the commit message or diff. Because the change set is enormous and the actual security-sensitive code differences are not isolated, this commit cannot be confidently classified as a fix for a known exploitable flaw, nor can it be called purely benign. It looks like a routine feature/security hardening release.

This commit only updates a Git submodule pointer in a release-tracking file. The actual code change is a one-line pointer update from one commit hash to another in a file named 'keystone3-firmware-release'. There is no visible security-relevant change in the diff itself, and no description of what the submodule update contains. It appears to be a routine continuous integration or release housekeeping task.

This commit only updates a Git submodule pointer (keystone3-firmware-release) from one commit hash to another. No source code, build scripts, CI configuration, or security-related files are changed in the visible diff. There is no evidence of a security fix or vulnerability.

This is a large firmware release commit (version 3.1.0) for the Keystone 3 hardware wallet. The most significant change visible in the diff is a major upgrade of the FreeRTOS real-time operating system kernel from version 10.x to 11.3.0, combined with enabling the ARM Cortex-M4 Memory Protection Unit (MPU) and adding a new 'MPU sandbox' subsystem. The changelog describes these as 'enhanced security policies' and 'optimized USB functionality,' but the commit itself does not disclose a specific vulnerability or credit an external researcher. Because the patch is enormous (300 files, tens of thousands of changed lines) and only a small portion of the diff is available, it is impossible to tell from this material alone whether the changes fix a known security flaw or simply harden the architecture. The security relevance is therefore plausible but unverified.

This commit is a routine version-bump merge for release v3.0.8. It only updates changelogs, a Git submodule pointer, and a build version number. There is no code change visible in the diff and nothing that suggests a security fix or vulnerability.

This commit only updates a Git submodule pointer (keystone3-firmware-release) from one commit hash to another. There is no code change visible in the diff, no description of what the new release config contains, and no security-related information provided.

This commit simply updates a Git submodule pointer for the project's release repository. There is no visible code change, no description of any security issue, and no indication this is anything other than a routine release-tracking update.

This is a routine firmware release merge (v3.0.4) for the Keystone 3 hardware wallet. The bulk of the changes are UI tweaks, new feature support (Solana CLI, Lace Wallet), and hardening fixes found during an internal 'regular AI review'. The security-relevant hardening includes: rejecting NUL bytes inside Ethereum EIP-712 typed-data messages, validating NUL bytes before converting Rust strings to C strings, adding null/UTF-8 checks when parsing UR payloads, replacing unsafe strcpy/sprintf with bounded versions, and fixing a format-string bug in a debug LCD print function. There is no public disclosure or CVE tied to this commit, and the vendor does not describe it as a security release.

This commit updates the hardware random number generator (TRNG) driver in a cryptocurrency hardware wallet firmware. It adds detection for a physical fault/attack signal from the TRNG and, if triggered, wipes the random data and aborts via an assertion. This is a defensive hardening change that makes it harder for an attacker to feed bad randomness into cryptographic key generation, which could otherwise let them guess or recover private keys.

This commit updates the hardware random number generator (TRNG) driver in a cryptocurrency hardware wallet firmware. It adds detection for a physical tamper/attack signal from the TRNG chip and, if an attack is detected, wipes the random data and aborts. The change appears to be a security hardening fix: the previous driver could keep using random numbers even when the TRNG hardware reported a fault/attack condition.

This firmware update fixes several security and safety issues found during a regular AI-assisted code review. The most important changes are: (1) Zcash wallet data is now encrypted with a key derived from the wallet seed and a fresh random IV, instead of being encrypted with a simple hash of the login password and a fixed seed-derived IV. (2) Ethereum legacy transactions now show a warning when they are not protected against replay attacks. (3) Solana transactions that contain hidden trailing bytes are now rejected before the user can review them. (4) Solana mixed transactions no longer hide unrelated instructions behind a specialized UI; sibling instructions are shown separately. (5) Tron transactions now reject multiple contracts, unsupported contract types, and ignore untrusted token metadata supplied by a host computer. (6) Cosmos delegate/undelegate/redelegate labels were corrected so users see the right addresses. (7) A new paginated message viewer helps users read long Ethereum messages before signing. The commit is described by the vendor as a 'regular AI review and fix' and does not explicitly call itself a security patch, but the changes clearly remove weaknesses that could mislead users or leak sensitive data.

This firmware update fixes several security and safety issues found during an internal AI-assisted review. The most important changes are: (1) Zcash wallet data was being encrypted with a key derived from the user's login password and a fixed, predictable IV; it is now encrypted with a key derived directly from the wallet seed and a fresh random IV. (2) Solana transactions that had hidden extra bytes after the real transaction data are now rejected instead of being accepted. (3) Solana mixed transactions (for example a Jupiter swap bundled with a token-account-close instruction) now show all instructions, not just the main one, so a malicious companion instruction cannot hide from the user. (4) Ethereum legacy transactions that do not use EIP-155 replay protection now show a warning on the device screen. (5) Tron transactions no longer trust token-name/decimal overrides sent by the host app, and they now reject multi-contract or unknown-contract transactions instead of silently ignoring parts of what is being signed. There are also many UI-only improvements for Cosmos, Ethereum and Solana message display.

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 only deletes a planning document from the repository's docs folder. No firmware code, build scripts, or cryptographic logic were changed. The deleted file described a previously completed security-hardening task about removing a weak random-number fallback, but the deletion itself does not alter the product's behavior or security posture.

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 is described as a routine CI (continuous integration) update with only one line changed in a release-related file. No code changes affecting wallet security, cryptography, or user funds are visible, and no security relevance is stated.

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 commit is described as a routine CI (Continuous Integration) update with only one line changed in one file. No diff content is available, and there are no verified references suggesting any security relevance. It appears to be a mundane build or release pipeline tweak.

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.