BitBox02 firmware

This commit adds unit tests for a Bluetooth/serial framing function and slightly relaxes four buffer-size checks from '<' to '<='. The change is described as 'off by one in the safe conservative direction', meaning the old checks rejected a perfectly-sized buffer as too small. The patch does not fix a memory corruption bug; it removes a false-positive assertion that could have caused a harmless device reset when a caller supplied an exactly-sized buffer. No security vulnerability is disclosed or demonstrated.

This commit is a code cleanup that moves multisig account storage operations behind a hardware-abstraction layer so tests can use a fake memory instead of real device memory. It does not appear to fix or introduce a security vulnerability. A few test files were updated to use the new fake memory, and one small bug was fixed where a test created a fresh fake device after registering an account, which would have made the test fail to find the registered account.

This commit rewrites a small piece of firmware logic from C to Rust. The logic decides whether the BitBox02 Nova hardware wallet should use Bluetooth or USB for communication. There is no obvious security bug introduced by the change; it appears to be a routine language port with matching behavior and added unit tests.

This commit updates the BitBox02 firmware's vendored copy of the Rust 'miniscript' library to version 13.0.0, along with its dependency 'hex-conservative'. The stated reason is to reduce firmware size by about 30 KB. The change is a routine dependency refresh; the commit message and diff do not describe any security bug being fixed, and no independent security advisory is supplied.

This commit is a routine release packaging update. It adds the signed build reproducibility assertions for BitBox02 firmware version 9.25.0 (both the multi-coin and Bitcoin-only variants) and updates the helper script and documentation to handle a new naming scheme where the product name is included in the assertion filename. There is no code change to the firmware itself and no security vulnerability is introduced or fixed.

This commit only fixes the formatting of license headers in automatically generated Python type-stub files. It moves the SPDX license notice from a standalone comment line into the generated docstring block. There is no change to program logic, no security fix, and no vulnerability.

This commit only updates the CHANGELOG.md file to mark the release of firmware version 9.25.0. It does not change any source code, cryptographic routines, Bluetooth behavior, or password handling. The changelog mentions a password-stretching improvement and a Bluetooth bug fix, but those changes were made in earlier commits; this commit merely documents them.

This is an automated dependency update by Dependabot that bumps the Rust 'lru' crate from version 0.16.1 to 0.16.3 inside a graphical simulator test component. The change only modifies a test-only lockfile and does not touch the actual BitBox02 firmware code. There is no indication in the commit that this fixes a security issue, and the supplied references do not mention any security relevance.

This commit simply moves a set of helper functions for handling strings from one Rust module to another. The actual code is copied unchanged, and all existing callers are updated to use the new location. There is no security fix or behavior change.

This commit adds automatic cleanup calls for several 32-byte temporary buffers that hold sensitive values like password hashes, HMAC keys, and password secrets in the Optiga secure-element integration code. Previously these buffers were zero-initialized at declaration but not always explicitly erased before the function returned or after an early error path. The change reduces the chance that leftover cryptographic material remains in stack memory, which could lower the risk of information leakage if an attacker later reads process memory or a core dump. It is a defensive hardening patch rather than a fix for an actively exploitable bug.

This commit adds a new read-only field to the BitBox02's device information API that tells the connected app which password-stretching algorithm the device uses. It does not change how passwords are stretched or how they are verified; it only exposes existing internal information to the host. There is no indication this is a security fix or that it introduces a vulnerability.

This commit changes how the BitBox02 hardware wallet handles the password-stretching algorithm used to protect the wallet seed. When a user unlocks the device, if the seed was encrypted with an older, weaker stretching method, it is now automatically re-encrypted with the newer, stronger method. The change is a defensive upgrade, not a fix for an active attack, and it only affects the unlock flow after the correct password is entered.

This commit is a small internal optimization in the BitBox02 hardware wallet firmware. When a user creates or restores a password, the device previously performed two separate operations on the secure chip (Optiga/ATECC): one to initialize the new password and another to stretch it. The commit combines these into a single step, reducing the number of secure chip 'events' (internal counter operations). There is no direct security vulnerability being fixed; it is a performance and resource-usage improvement.

This commit adds a new password-stretching algorithm (V1) for BitBox02 devices that use the Optiga secure chip. It changes how the device turns a user's password into an encryption key, adding extra secure-chip-backed hashing steps and enforcing that newly created passwords use the new algorithm. Old V0 passwords can still be unlocked for backward compatibility. There is no direct evidence in the commit of a security vulnerability being fixed; it reads as a planned feature/upgrade.

This commit is a simple code cleanup: it renames a constant from KDF_NUM_ITERATIONS to KDF_NUM_ITERATIONS_V0 and updates the comment to clarify that the low number of iterations (2) applies only to an older password-stretching algorithm (V0). No behavior changes, no security fix, no vulnerability patch.