AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 45 Bitcoin

hal: add random, factory_randomness, drop random_32_bytes

Public commit record

What the developer wrote

Authored by Marko Bencun

55/100 · Thin
hal: add random, factory_randomness, drop random_32_bytes
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Names security-relevant behavior explicitly! No meaningful explanatory body
The short version

What changed, and why it matters

This commit changes how the BitBox02 hardware wallet generates random numbers used to create secret keys and encrypt stored data. Previously, the firmware used a single 32-byte random value from the microcontroller. After this change, it mixes three sources: the microcontroller's random generator, the secure chip's random generator, and a fixed 32-byte 'factory randomness' value stored in a special flash memory location. The commit also adds a factory script to write that fixed value into devices during production. The change is a defensive hardening measure, not a fix for an active bug, but it introduces a new dependency: if the factory randomness is not actually random or is reused across devices, it could weaken security instead of strengthening it.

Recommended action

Verify that the factory randomness value is generated with a cryptographically secure random source per device and never logged, committed, or reused. Audit the J-Link production workflow to ensure the 32-byte value is written before firmware runs and that the flash region is read-only or protected after programming. Complete the BitBox03 `todo!()` implementations before release. Review whether the fixed flash address collides with any existing bootloader or firmware layout.

Security signals we found

01

New factory randomness storage at fixed flash address (0xdfe0) programmed via J-Link script

02

Random generation now mixes three entropy sources (MCU, secure chip, factory) and hashes them

03

Secure chip random function exposed through Rust HAL with error propagation

04

Removal of single-source `random_32_bytes()` API

05

Test vectors updated to reflect new deterministic output of mixed randomness

06

BitBox03 implementation left as `todo!()` (incomplete)

Risk score

Why this scored 45/100

Our methodology →
Potential impact 12/30
Exploitability 8/25
Stealth signal 6/15
Affected reach 10/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.