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 firmware update adds support for Solana's new V1 transaction format and changes how oversized or malformed transaction details are displayed. The code introduces a dedicated parser for V1 messages with strict size and structure checks, and it prevents malformed V1 messages from being silently treated as ordinary text messages. It also paginates long transaction detail screens so users can scroll through large transactions instead of the UI breaking or truncating.

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 is a routine build-system and code-formatting fix. It resets cached CMake build options so each build starts from known defaults, makes cbindgen header-generation failures visible instead of silently ignored, runs Rust formatting, and adds a missing import for tests. There is no indication of a security vulnerability being fixed.

This commit adds a hard cap on how many files the device will list from its SD card when loading multi-signature Bitcoin wallet data. It also tightens up null-pointer and length checks while scanning directories. The likely goal is to prevent a malicious or accidentally overstuffed SD card from crashing the wallet or causing memory corruption when it reads a huge directory listing.

This commit tightens which old-style Bitcoin-like transactions the Keystone hardware wallet will accept. It now rejects raw protobuf Bitcoin (BTC) and Dogecoin (DOGE) legacy UTXO transactions, allowing only Bitcoin Cash (BCH), Dash (DASH), and Litecoin (LTC) to keep using that older path. Bitcoin must now go through the newer PSBT route. The change is framed as a deprecation/hardening fix rather than a response to a known exploit.

This commit disables the older, raw-protobuf signing path for Bitcoin and Dogecoin transactions in the Keystone 3 hardware wallet firmware. It keeps the legacy path active only for Bitcoin Cash (BCH), Dash (DASH), and Litecoin (LTC). The change is described as a deprecation and hardening measure, not as a fix for a specific reported vulnerability. The patch adds rejection checks at multiple entry points (parsing, checking, signing, and QR-code type detection) so that unsupported legacy UTXO transactions fail with a clear error message instead of being processed.

This firmware update is a routine 'regular review fix' that hardens how the Keystone 3 hardware wallet checks and displays several cryptocurrency transactions before signing. The most important security changes are: (1) the sign button is now disabled until transaction parsing succeeds, so a malformed transaction cannot be accidentally approved; (2) Arweave/AO data-item transactions are rejected during the pre-check if their tag metadata is malformed; (3) Avalanche transactions are fully re-parsed in the pre-check, so tampered fields such as a changed output asset ID are caught; (4) Bitcoin-like fee warnings now use network-specific thresholds, so normal Dogecoin/Litecoin fees no longer trigger misleading 'large fee' alerts; and (5) Cosmos no longer shows a duplicated 'Max Fee' line, and Solana Squads proposal memos are displayed on the correct instruction. Most other changes are UI layout and cleanup.

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 for the Keystone 3 hardware wallet fixes several security and safety issues found during an internal AI-assisted review. The most important changes are: (1) the signing slider is now disabled until a transaction is fully parsed, so a malformed transaction cannot be accidentally approved; (2) Arweave data-item transactions are checked for tampered tag counts before they reach the confirmation screen; (3) Avalanche transactions are fully re-parsed during the safety check so a modified transaction is rejected; (4) Bitcoin-like fee warnings now use network-specific thresholds, so Dogecoin/Litecoin users are not falsely warned or misled by Bitcoin defaults; and (5) Cosmos no longer shows a duplicated/confusing 'Max Fee' field, and Solana Squads multi-sig memos are attached to the correct instruction. Most other changes are UI clean-up.

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 replaces the on-screen keyboard shuffle and a word-list randomizer so they use the device's true random-number generator (TRNG) instead of LVGL's weaker pseudo-random function. The change is defensive: it removes a source of predictable randomness that could, in theory, make shuffled PIN layouts or recovery-phrase ordering easier to guess or reproduce.

This commit swaps out the LVGL graphics library's pseudo-random number generator for the device's hardware true random number generator (TRNG) in two places: shuffling the on-screen numeric keypad and shuffling recovery-word lists. The old code used lv_rand, which is not designed for cryptographic security and may be predictable. Using a predictable shuffle could let an attacker who can see or guess the random sequence reduce the number of possible keypad layouts or word orders they must try, weakening protections for PIN entry or seed-phrase backup verification. The patch itself is a clear improvement, but it is small and we cannot verify from the diff alone whether the TRNG driver is correctly implemented or whether other sensitive code still uses lv_rand.

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 hardens how Keystone 3 handles Solana signing requests. Previously, the device partly trusted an external 'sign type' flag from the wallet app to decide whether a QR code contained a transaction or a plain message. The patch now inspects the actual bytes: if they look like a complete transaction it is treated as a transaction; if they start like a transaction but have extra hidden bytes it is rejected; otherwise it is treated as a message. It also adds a warning banner when a Solana message cannot be fully parsed, so the user knows they are 'blind signing'. A small UI fix also makes the camera scanner resume correctly after an error instead of getting stuck.

This commit improves how Keystone 3's Solana app recognizes and displays certain transaction types. It adds support for the Solana Compute Budget program so those instructions are no longer labeled as 'Unknown,' and it adds parsing for Solana off-chain message signing so those messages are shown as human-readable text instead of being mistaken for raw transactions. The UI now shows unknown program addresses separately after the main transaction overview, and USB error messages can display more specific failure text. The commit title says it addresses 'Solana review findings,' but the commit message itself does not explicitly call these security fixes.

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.