BitBox02 firmware

This commit simply moves a helper function that looks up a BIP39 word by its index from one source file to another. The function's behavior and the callers' logic are unchanged; it is a code cleanup with no security impact.

This commit updates the Rust compiler toolchain from an unspecified earlier version to Rust 1.92 for the BitBox02 hardware wallet firmware. It also refreshes many vendored third-party Rust libraries (such as libc, hashbrown, getopts) and build tools (cbindgen, bindgen). The stated reason is compatibility with the new toolchain, including a breaking change around panic handling. There is no direct evidence in the commit that this fixes a known security vulnerability, but toolchain and dependency updates can affect security-relevant behavior such as memory safety, panic handling, and type definitions used in cryptographic code.

This commit adds unit tests for two cryptographic helper functions and slightly reorders their internal steps so the output buffer is only written after the HMAC calculation is complete. The change makes it safe for the output buffer to overlap with the input or key buffers, and documents that overlap is allowed. There is no new vulnerability here; it is a defensive hardening and testing improvement.

This commit is a straightforward internal refactoring: it moves the device attestation signing function behind a hardware-abstraction-layer (HAL) interface so the code can be more easily tested. The actual cryptographic operation and the data it uses remain unchanged. There is no indication this fixes or introduces a security vulnerability.

This commit is a large internal refactoring of the BitBox02 firmware. It adds a new secure-chip key-derivation function (KDF) to the hardware abstraction layer (HAL) and threads that HAL through many existing functions so they can use it. The change touches 31 files and many tests, but it does not appear to introduce a new security vulnerability on its own. It is a structural change that prepares the code for using the secure chip's KDF more consistently.

This commit adds a new 'Change Password' feature to the BitBox02 hardware wallet. Instead of resetting the device and restoring from a backup, users can now change their device password directly. The wallet re-encrypts the stored seed with the new password while keeping the same accounts and identity. The change is a normal product feature, not a security fix, but it touches sensitive crypto code that protects the user's funds.

This commit adds two digital signature files for the BitBox02 firmware version 9.24.0. These signatures are used to publicly verify that the released firmware binaries are authentic and have not been tampered with. There is no code change and no indication of a security vulnerability.

This commit is a routine refactoring that rewrites existing C unit tests in Rust. It does not change the actual firmware behavior or fix any security issue. One redundant test was removed, and several internal test-only helpers were added so the Rust tests can call the same underlying C memory functions.

This commit only adds a new automated test to the BitBox02 firmware. It checks that entering the wrong password repeatedly while the device is already locked correctly triggers the lockout mechanism and eventually wipes the seed. There is no change to production code, no new feature, and no fix to an existing bug.

This commit rewrites two internal seed-handling functions from C to Rust as part of an ongoing porting effort. It moves where the encrypted wallet seed is stored and how it is decrypted, but keeps the same encryption design. There is no direct evidence in the commit that this fixes or introduces a security bug; it is primarily a code-rewrite change.

This commit rewrites the code that keeps the BIP-39 seed temporarily encrypted in memory, moving it from C to Rust. It is a refactoring/porting change, not a fix for a known bug or attack. The same encryption approach is preserved, but the change touches sensitive seed-handling code, so it deserves careful review.

This commit is purely a code-style change. It tells the project's automatic formatter (clang-format) to indent preprocessor directives like #if, #include, and #error, and then applies that new rule across many source files. No program logic, security checks, or behavior were changed.

This commit is a routine code refactor, not a security fix. It moves the source of random numbers behind a new 'hardware abstraction layer' (HAL) interface so the same code can use a fake predictable random generator during automated tests and the real secure random generator on the actual BitBox02 device. The only production behavior change is that Taproot/Schnorr signing now fetches its auxiliary randomness through this new interface instead of calling the device's random function directly. The real-device implementation still uses the same secure random function as before, so security properties are unchanged.

This commit is a straightforward refactoring: it moves an existing anti-klepto protocol unit test from C to Rust. No production firmware code is changed, and no security vulnerability is introduced or fixed. The same cryptographic checks are still performed, just in a different test language.

This commit is a code reorganization: it moves the BIP39 seed derivation and root fingerprint storage from one Rust module to another. The same logic is preserved, including a safety check that derives the seed twice to detect memory corruption. There is no visible security fix or vulnerability being introduced.

This commit is a simple internal code reorganization: a function that converts a seed into a BIP39 recovery phrase is moved from one Rust module to another, with all callers updated. The actual behavior of the function is unchanged, and no security bug is introduced or fixed.

This commit is a code cleanup and refactoring change. It moves test-only helper functions (used to simulate an unlocked device during automated tests) from one internal Rust module to another, closer to where they are actually used. It also moves a BIP39 mnemonic-to-seed conversion function into a more appropriate module. There is no change to the actual device firmware behavior, user-facing functionality, or security logic.

This commit is a routine internal code reorganization in the BitBox02 firmware. It moves two existing keystore functions—used to unlock and copy the BIP39 seed—into a higher-level Rust wrapper module, and renames the original low-level functions with an underscore prefix so the compiler flags any remaining direct callers. The change does not alter the cryptographic behavior, add new user-facing features, or fix a known security bug. It is preparation for a future native Rust implementation.

This commit only rewrites comments in the factory setup code to explain why two bootloader flags are set the way they are. No code behavior is changed, so it has no security impact on its own.

This commit deliberately runs the wallet-unlock calculation twice instead of once, purely to keep the on-screen unlock animation from finishing too quickly after a performance improvement. The second run is used as a consistency check: if the two results don't match, the device reports a memory error. The change is framed as a user-experience fix that happens to add a safety double-check, not as a response to a known security bug.

This commit is a large internal refactoring of the BitBox02 firmware's BIP39 wallet-unlocking code. It converts the slow PBKDF2 key-stretching loop from a blocking (synchronous) operation into an asynchronous one, so the device can briefly pause each round to handle other tasks such as USB messages and screen animations. The commit also vendors the futures-core, futures-lite, and pin-project-lite Rust crates so the firmware can use async/await. The change is explicitly described by the authors as not yet fully functional on its own; a follow-up commit is needed to make the unlock animation work with the new async model. There is no direct evidence in the commit that this fixes or introduces a security vulnerability; it is primarily an architectural/performance change.

This commit updates the BitBox02 firmware's vendored copy of a Rust library (rust-bip39) used to turn a recovery phrase into a cryptographic seed. The main change is adding an async (cooperative multitasking) version of the seed-derivation function so the device can briefly pause between heavy PBKDF2 rounds instead of blocking the main loop. It also moves the dependency from a personal fork to the BitBoxSwiss organization fork and adjusts a transitive dependency version. There is no direct security fix or vulnerability patch visible in this commit; it is a dependency/vendor refresh and async API addition.

This commit is a hardening improvement, not a fix for an active vulnerability. It reduces how often the BitBox02 hardware wallet talks to its secure chip (the Optiga) when checking a password. Previously, an extra secure-chip call was made to fetch and compare the seed; now the device compares a locally retained hash instead. This lowers the chance of hitting the secure chip's throttling/lockout counter during normal use, which could otherwise make the device temporarily unusable or even require reset. The change does not introduce a known exploit path.

This commit is a routine code cleanup: it changes many Rust source files to import a small async helper module from a shared utility crate (`util::bb02_async`) instead of from the local crate (`crate::bb02_async`). There is no change to program logic, no bug fix, and no security-relevant behavior.

This commit adds the ability to include OP_RETURN outputs when signing Bitcoin transactions on a BitBox02 hardware wallet. OP_RETURN is a special Bitcoin output type used to embed small pieces of data (like text or hashes) on the blockchain. The device now shows the user the data being embedded and asks for confirmation before signing. The commit also enforces that OP_RETURN outputs must carry zero Bitcoin value, so no money can accidentally be burned into them.