BitBox02 firmware

This commit is a code refactoring that moves the device attestation signing function from C code into Rust code. It converts the function to be asynchronous (async/await) and rewrites the parsing of the secure chip's DER-encoded signature in Rust. There is no direct evidence in the commit that this fixes a security vulnerability; it appears to be a normal portability and maintainability improvement. The change does add safety checks for signature length and zeroizes sensitive buffers after use, which are good defensive practices.

This commit rewrites how the BitBox02 hardware wallet fetches random numbers from its secure chip. Previously, the secure chip's random generator was called in a blocking (synchronous) way. The change makes it asynchronous, so the firmware can do other work while waiting. It also removes an older, simpler random interface and now mixes the secure-chip randomness with the microcontroller's own randomness before using it for sensitive key material. The commit itself is a defensive refactor; it does not appear to fix a known exploit, but it removes a synchronous call that could stall the device and strengthens how random values are combined when creating password-stretching secrets.

This commit only adds two new digital signature files for an already-released firmware version (9.26.1). These signatures are used by independent builders to publicly attest that they reproduced the official firmware exactly from source code. No code, no firmware binary, and no behavior of the device changed. There is nothing here that could affect security of the BitBox02 itself.

This commit is purely a code-style and build-maintenance change. It makes the Rust code generated from protocol-buffer definitions be formatted by rustfmt automatically and included in style checks. No security-sensitive behavior is changed.

This commit is a build-system and code-organization refactor. It moves the automatically generated Rust protobuf message definitions from inside the main bitbox02-rust crate into a new, separate bitbox-proto crate. It also switches the generation flow from CMake to Cargo, adds a CI check to ensure the committed generated files stay in sync with the .proto source files, and avoids touching timestamps when regeneration produces identical output. There is no change to the actual device firmware logic or to how messages are parsed and validated.

This commit is a simple internal cleanup: it takes two places in the firmware that were doing the same 'wait until the secure chip is no longer busy' loop and makes them share one copy of that loop. There is no change in behavior, no new feature, and no indication of a security fix.

This commit only adds a comment explaining that a function behaves like Python's HMAC-SHA256. No code behavior changed, and there is no security issue.

This commit tightens Rust type signatures for functions that talk to the secure chip (Optiga). Instead of accepting arbitrary-length byte slices and then checking lengths at runtime, the functions now require fixed-size arrays. This is a defensive hardening change: it moves some length checks from runtime to compile time, reducing the chance of a length mismatch bug being exploited. There is no direct evidence in the commit that an exploitable vulnerability existed before this change.

This commit is a large refactoring that moves the password-stretching and secure-chip password operations from C into Rust for the BitBox02 firmware. It does not add new user-facing features or change the cryptographic algorithm; it reimplements the same OPTIGA secure-chip flows (HMAC verification, symmetric encryption, key generation, counter resets) in Rust with async wrappers. The old C implementation and its unit tests are removed, and equivalent Rust unit tests with deterministic fakes are added. There is no indication in the commit that this fixes a known security vulnerability.

This commit only reformats the Rust documentation comments for unsafe functions so they use the standard '# Safety' heading. No actual code logic, memory handling, or behavior changed. It is a documentation cleanup with no security impact.

This commit is a straightforward code cleanup: it changes the return type of password-stretching functions from a variable-length byte list to a fixed 32-byte array, because the result is always exactly 32 bytes. The change makes the code clearer and lets the compiler enforce the size, but it does not fix any security bug or change behavior.

This commit only changes the graphical simulator used for testing the BitBox02 firmware. It adds a one-second artificial delay to the simulated secure chip's key-stretching function so that developers can visually test the unlock animation. It does not affect the real hardware firmware or any user-facing security behavior.

This commit is a user-interface polish change for the BitBox02 hardware wallet. It replaces a generic 'waiting' spinner with the first frame of the unlock animation while the device is busy stretching the user's password. There is no security vulnerability or fix here—only a visual improvement to make the device look smoother during unlock.

This commit fixes a simulator-only bug where the graphical BitBox02 simulator was accidentally using real device randomness instead of the fixed test value used by other simulators/test builds. The change makes the graphical simulator use the same predictable 'factory randomness' as the C unit-testing simulator. This is a test/simulator hardening fix, not a fix for the real hardware wallet firmware.

This commit only changes test code. It removes an old test helper called mock_memory() and updates unit tests to use a newer testing framework (HAL, or Hardware Abstraction Layer). There is no change to the actual firmware that runs on the BitBox02 device, so it cannot affect real users or introduce a security vulnerability in shipped code.

This commit adds release artifacts for BitBox02 firmware version 9.26.1: two signed text files stating the expected firmware hash for the Multi and Bitcoin-only editions, their detached signatures, and a helper Python script that automates creating such assertion files in the future. There is no change to the actual firmware code, no bug fix, and no security patch.

This commit caches the secure chip's serial number in memory during setup so it doesn't have to be read from the chip every time it's needed later. The change also makes a key-authorization function fail if the serial number hasn't been cached yet. This is a hardening improvement rather than a fix for an active vulnerability: it reduces how often the firmware talks to the secure chip for the serial number and ensures the value is available before use.

This commit fixes a race condition in the BitBox02 hardware wallet's Rust-based timer code. The old code used a Rust borrow-checker helper (RefCell) to share state between normal code and a hardware timer interrupt. RefCell is not safe across interrupts, so if the timer fired while the code was checking the timer, both sides could try to modify the same data at once, leading to unpredictable failures or panics. The fix replaces the shared state with proper atomic variables and an atomic waker, which are designed for interrupt-safe concurrency.

This commit is a routine housekeeping change in the Rust build configuration. It moves the 'critical-section' library from being declared separately in two sub-crates to a single shared workspace dependency. There is no change to the actual firmware code, behavior, or security logic.

This commit fixes a crash in the software simulator used for testing the BitBox02 hardware wallet. The simulator was trying to read a special memory address that only exists on the physical device, causing it to crash. The fix makes the simulator return a placeholder value of all zeros instead. This only affects test tooling, not real devices or user funds.

This is a tiny one-line fix for the software simulator used in development and automated testing. A previous change accidentally made the simulator's 'reboot' command spin in a busy loop instead of doing nothing, which caused simulator tests in a related Go project to hang. The patch simply skips the reboot call when the 'c-unit-testing' simulator feature is enabled. It does not affect real BitBox02 hardware or end-user security.

This commit only bumps the firmware version number from v9.26.0 to v9.26.1 and adds a one-line changelog entry saying 'Fix a payment request validation issue.' The actual code fix is not present in this commit, so we cannot directly assess what the bug was, how severe it is, or how it could be exploited. The changelog wording suggests a security or correctness issue in how payment requests are checked before being approved on the BitBox02 hardware wallet, which could in principle trick a user into authorizing an unintended payment. However, without the patch that fixes the issue, this is mostly speculation.

This commit only changes Rust compiler settings used when running automated tests. It disables link-time optimization, increases parallel compilation units, and turns off optimization to make tests run faster. There is no change to the actual firmware code, no security fix, and no security-relevant behavior change.

This commit rewrites how the BitBox02 hardware wallet performs a key-derivation operation inside its secure chip (OPTIGA). Previously the operation was synchronous and wrapped in C; now it is asynchronous and called from Rust through the existing async command bridge. The change touches many files because every caller of the KDF/keystore functions had to be updated to `await` the result. The diff itself is a large refactoring with no obvious security bug, but it introduces new async machinery around a sensitive cryptographic operation, so it warrants careful review for memory-safety and concurrency issues.

This is a small internal code cleanup in the BitBox02 firmware. It changes a helper function that computes SHA-256 hashes so that it returns a fixed 32-byte array instead of a variable-length vector. The only effects are removing an unnecessary type conversion and making the code clearer. There is no security bug being fixed here.