Keystone 3 firmware

This commit adds safety checks to the bootloader update code in a cryptocurrency hardware wallet. Before the change, the firmware could trust attacker-controlled length values read from a staged update image, potentially allowing a malicious or malformed update to copy too much data, loop too many times, or write past a fixed-size buffer. The patch validates the boot image length and caps the per-loop copy size, which reduces the risk of memory corruption or unauthorized flash writes during a boot update.

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 is a one-line build fix that changes a padding length constant from 1 to 2 in a file used only for Bitcoin-only firmware builds. There is no indication in the commit of any security issue, vulnerability, or functional bug. It appears intended solely to resolve a compilation or linker error.

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 adds a safety check for the Keystone 3 hardware wallet's Zcash account setup. If the stored Zcash public key information is missing or not a valid hex string, the wallet now regenerates it. This prevents the wallet from trying to use corrupted or incomplete Zcash key data, which could cause errors or display wrong addresses. It is a defensive fix, not a clear exploit patch.

This commit changes the default backup seed phrase length for the standard firmware from 33 words to 20 words. SLIP39 seed phrases can use different word counts, and 20 words still provides substantial entropy. There is no direct evidence in the commit or supplied references that this change fixes a security vulnerability; it appears to be a product/usability change.

This firmware update fixes two categories of bugs in a cryptocurrency hardware wallet's background task system and web-authentication code display. First, it adds a flag so the background task knows whether it allocated a memory buffer itself (and must free it) or was given a pointer by the caller (which it must not free). Before this fix, the task could free memory it did not own, leading to crashes or corrupted memory. Second, it hardens the web-authentication code calculation by checking whether memory allocation succeeded, clearing the private RSA key from memory after use, and correctly freeing the generated auth code string. It also removes two lines that incorrectly set freed pointers to NULL inside a cleanup function. The changes are defensive and reduce the risk of memory corruption and sensitive key material lingering in RAM, but the commit message frames them as generic fixes rather than as a security advisory.

This commit fixes a small but meaningful bug in the Keystone 3 hardware wallet's account information output. Previously, when showing details for Monero (XMR), the 'manage' field was completely left out if the wallet's mnemonic type was not BIP 39. Now it is always included and set to false in that case. The change makes the JSON response predictable and consistent, which can help companion apps or users avoid misinterpreting whether the coin can be managed. It is a defensive fix rather than an obvious exploit, but omitting a boolean field could lead a connected app to make unsafe assumptions.

This commit changes the default Shamir backup share length from 20 words to 33 words and adds on-screen explanations about which cryptocurrencies each option supports. It is a usability and compatibility improvement, not a security fix or vulnerability. The code also tightens a few display routines so the word count is shown correctly regardless of the selected value.

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 is a straightforward build fix for a firmware configuration file. It adds conditional preprocessor definitions so that different product build variants (Web3, BTC-only, Cypherpunk) each define a required constant, LEGACY_USB_PAD_LEN, with values of either 1 or 2. Without this change, some build configurations would fail because the constant was missing. There is no security-relevant change in behavior visible in the diff.

This is a one-line build fix that changes a default padding length constant from 1 to 2 in a legacy USB web-update feature. There is no indication of a security problem, and the change itself does not introduce or fix any vulnerability visible in the diff.

This commit is a routine build-system cleanup. It moves a Sui blockchain dependency from being declared in one specific app file to being declared once at the workspace level, and then references it from the app and C-binding crates. It also reformats some Zcash feature flags onto single lines. There is no visible security fix or vulnerability being patched.

This appears to be a routine CI (Continuous Integration) configuration update with no visible security relevance. Only one file was changed with a single-line addition and deletion. The actual code diff is unavailable, so no security-relevant content can be assessed.

This commit fixes a firmware crash that could occur when a wallet created with only a TON (The Open Network) mnemonic was upgraded to the 'cypherpunk' firmware version. The crash happened because two code paths that handle public key/account setup did not recognize TON-only wallets and tried to perform operations that are invalid for them. The fix adds explicit TON checks so those paths return early instead of crashing.

This commit only changes a Git submodule pointer (a reference to another repository's version) back to match the upstream master branch. There is no code change visible, no security fix, and no security-relevant behavior described.

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.