Keystone 3 firmware

This commit only adds a new version entry to the changelog files and bumps the firmware version number from 2.2.20 to 2.3.0. It does not change any executable code, cryptographic logic, or security-sensitive behavior. There is no security issue in this commit itself.

This commit is a routine maintenance change titled 'chore: optimize test and lints'. It updates code-coverage thresholds in CI workflows, adds Rust lint configuration for a nightly coverage feature, removes an obsolete nightly Rust feature flag, and adjusts some test data and test cases. There is no indication of a security fix or vulnerability being addressed.

This commit fixes a software crash in the wallet connection screen of the Keystone 3 hardware wallet firmware. The code now checks whether a selected coin/wallet type was found before continuing. Without this check, the device could crash when connecting to a wallet it does not recognize, likely causing a denial of service rather than theft of funds.

This commit only reformats two lines of Rust source code. It does not change what the code does, only how it is visually laid out. There is no security relevance.

This commit fixes how the Keystone hardware wallet handles Bitcoin 'sign message' QR codes. Previously, many malformed or unsupported message formats were reported as 'unsupported transaction,' which could mislead users. The change introduces a clearer 'Invalid Message' error and adds a new Japanese font glyph. It is primarily a user-experience and error-handling improvement, not a fix for a known exploit.

This commit fixes a Bitcoin multisig signing flow in the Keystone 3 hardware wallet firmware. Previously, when a transaction did not need a signature, the code exported the PSBT but did not properly handle the result object; when it did need a signature, it signed but skipped updating the UI status and freeing the result. The patch unifies both branches so the result is always processed and cleaned up. It also wraps some legacy Keystone transaction code in a WEB3_VERSION compile guard, likely preventing it from running on Bitcoin-only firmware builds where it could behave incorrectly.

This commit refactors how the Keystone hardware wallet exports Bitcoin account data (extended public keys) when pairing with BlueWallet and other apps. Previously BlueWallet received only three key types (Native SegWit, SegWit, Legacy). Now it uses the same function as Sparrow/Zeus/UniSat, which also includes the Taproot key type. This is a feature addition, not a vulnerability fix, and does not change how secrets are handled.

This commit fixes a crash in the Keystone hardware wallet firmware when scanning QR codes that contain non-UTF-8 bytes. Previously, the code would panic and abort processing. The fix replaces the strict conversion with a checked conversion that returns a controlled error instead of crashing. It also ensures that when a 'signmessage' QR code contains invalid UTF-8, the device reports an unsupported transaction rather than crashing.

This commit changes two Zcash-related functions in the Keystone hardware wallet firmware so that the wallet seed is no longer treated as a mutable buffer and is no longer explicitly wiped (zeroized) from memory after use. The title says 'fix zcash unwrap,' suggesting the change was made to resolve a Rust panic caused by calling .unwrap() or by a mutability mismatch. Removing zeroize reduces memory cleanup of the secret seed, which could leave sensitive material in memory longer than intended. However, the diff alone does not prove an exploitable vulnerability; it may simply trade one bug for another.

This commit adds a single missing function declaration (PreparePublicKeys) in a Bitcoin UI source file. It is a straightforward build fix with no visible security relevance.

This commit is purely a code-formatting change. It only rewrites two test assertions in a Rust file so they fit on single lines instead of being split across multiple lines. No logic, behavior, or security checks were changed.

This commit only adds and updates unit tests. It does not change any production code. The tests verify that all-zero and all-0xFF seeds are rejected as invalid by several cryptographic modules. There is no security fix or vulnerability introduced here.

This firmware update adds a safety check that refuses to use cryptocurrency seeds made entirely of 0x00 or 0xFF bytes across Cardano, Bitcoin-style (secp256k1), Ed25519, RSA, and Zcash key operations. Such 'trivial' seeds produce predictable or weak private keys that attackers could guess. The patch also moves a memory-clearing call in Ethereum batch signing so the seed is wiped only after all transactions are processed, rather than after the first one. The commit message does not call this a security fix, but the change clearly reduces a key-derivation risk.

This commit fixes a bug in the Bitcoin PSBT (Partially Signed Bitcoin Transaction) handling code of the Keystone 3 hardware wallet firmware. The bug involved passing the wrong size for the master fingerprint (mfp) buffer to several Rust/C FFI functions. In C, `sizeof(mfp)` where `mfp` is a function parameter of type `uint8_t*` gives the size of a pointer (typically 4 or 8 bytes), not the actual 4-byte array length. The fix adds an explicit `mfpLen` parameter so the correct length (4 bytes) is passed. The commit title 'psbt crash' suggests this mismatch caused crashes when parsing or signing PSBTs. A separate cleanup refactors how public key arrays are prepared to avoid stack-use-after-scope issues.

This commit fixes how the Keystone hardware wallet selects the Cardano (ADA) key derivation algorithm when a passphrase is used. Previously, the selected derivation style was stored in a global variable that was not reset between wallet sessions. If a user switched between a standard wallet and a passphrase-protected wallet, the device could continue using the wrong derivation path, producing Cardano public keys and addresses that do not match the user's expected wallet. This could make funds appear missing or, in rare cases, lead to sending or receiving to an unintended address family. The patch resets the derivation choice when memory is freed and re-initializes it from the current account type when the key-derivation screen is opened.

This commit fixes a build error in the 'cyperpunk' firmware variant by replacing a likely-undefined variable `len` with `seedLen` in two function calls that handle Zcash cryptographic key derivation. The change appears to be a straightforward compile fix rather than a security patch, but the use of the wrong variable could theoretically have led to reading an incorrect seed length if `len` had a different meaning or value.

This commit cleans up two places where TON (The Open Network) checksums were being converted to hex strings by hand-written loops, replacing them with a single helper function `ByteArrayToHexStr`. It also adds a debug print statement showing whether the TON and BIP39 mnemonic comparisons succeeded during the 'forget TON' flow. The title 'fix ton forget' suggests the change is meant to fix a bug in the process of forgetting/removing a TON wallet, but the diff itself does not show an obvious security vulnerability or a clear behavioral fix beyond code simplification and extra logging.

This commit changes how Cardano public keys are derived for SLIP39 wallets. It switches from a mutable, zeroed-out copy of the wallet seed to a non-mutable, non-zeroed copy. The change removes a safety feature that normally wipes the seed from memory after use, which could leave sensitive seed material in memory longer than intended. However, the commit message only says 'fix ada slip39 address' and gives no security explanation, so the exact risk is unclear from the diff alone.

This commit replaces a custom secure-wipe function with a standard one in code that handles secret key material during password-based key derivation. The change is likely a defensive hardening fix, but the diff alone does not prove an exploitable vulnerability existed.

This commit fixes a logic bug in the Keystone hardware wallet's SLIP39 backup phrase handling. The original code used 'OR' instead of 'AND' when checking word counts, which made the validation always fail for valid 20-word and 33-word SLIP39 phrases. This would have shown users an incorrect error notice and blocked legitimate wallet recovery or setup operations. It is a bug fix that improves reliability, but it does not appear to allow theft of funds on its own.

This commit simply removes four unused helper functions for handling JSON data from a utility file. There is no change to active behavior, no bug fix, and no security-relevant change.

This firmware update fixes a bug in how the Keystone 3 hardware wallet handles TON (The Open Network) wallet setup. The changes remove several safety checks and replace safer string/buffer functions with less safe ones, while also restructuring how TON entropy and seed generation errors are handled. The commit title says it fixes a TON wallet bug, but the diff itself mostly removes defensive coding patterns rather than adding them. Without more context, it is unclear whether the change fully resolves the underlying issue or introduces new risks.

This commit removes a function that filled public key info for all cryptocurrency chains and adds a null-password check in the RSA key-reading path. The stated goal is to fix a crash. The crash likely happened because RSA key generation/reading ran while the password cache was empty, causing GetAccountSeed to dereference a null password. Removing the broad chain-info filler may also prevent crashes from partially initialized state during wallet setup or account switching.

This commit fixes a mismatch in how the firmware stores a recovery phrase (mnemonic) in memory. Previously, the code allocated memory based on the actual phrase length but then copied the phrase using a fixed maximum size. The change makes both steps use the same, correct length. This is a defensive fix that prevents potential memory corruption or undefined behavior when handling the secret recovery phrase.

This commit changes a password-length check from 'greater than' to 'greater than or equal to' the minimum allowed length. In the original code, a password exactly equal to the minimum length would trigger an assertion failure, which could crash the firmware or block wallet operations. The fix allows passwords of exactly the minimum length to be accepted. This is a correctness fix for an input-validation boundary condition, but the commit message gives no indication it was treated as a security issue by the vendor.