OSC-2026-0026 · github.com/proto-at-block/bitkey
info clean-run claude-fable-5 2026-08-04 signed: nostr
- Repository
- github.com/proto-at-block/bitkey
- Commit
- cf16705543d0c66ff982635733d380944cc2677d
- Scope path
- firmware/lib/wallet/src/seed.c
- Model
- claude-fable-5
- Harness
- claude-code
- Prompts
- prompts/entropy-rng-audit-v1.md
- Independent runs
- 1
- Transcript sha256
- ef714936ab57f0ce310e9c9aa0d58b8719cd2e3bbbdabc9a8b4f75acb4bff5ad
- Auditor
- TheIcarusWings (theicaruswings)
- Signature
- nostr-schnorr · npub19tzp8lf3klmqj3dz9mz0qnuvjp7uyy9993gmljmyaxs8phztj7wsnujvq5
Scope. The master-seed entropy path in the device firmware at HEAD cf167055: seed creation in firmware/lib/wallet/src/seed.c, the crypto_random implementation in firmware/lib/crypto/src/efr32/secure_rng.c, failure handling, and seed-at-rest handling. EXPLICITLY NOT ESTABLISHED: the seed length - seed_t's definition could not be retrieved from a blobless clone, so no claim is made about entropy sizing. Also not examined: the Secure Engine's own RNG quality, key management, biometrics, the bootloader, signing paths, and the server-side components of the Bitkey system.
Findings
info OSC-2026-0026-F1 unreviewed
No weakness found in scope. Seed entropy comes from the Silicon Labs Secure Engine (sl_se_get_random) rather than the application MCU, with no software PRNG anywhere in the path and no fallback to one, so the Coldcard failure class cannot arise. Failure handling is the strictest in this series: crypto_random returns false on ANY error including a failed command-context init, and the caller wraps it in ASSERT, so a failure halts the device rather than proceeding with buffer contents - compare Trezor which raises (OSC-2026-0025), Keystone3 which continues with two remaining sources (OSC-2026-0005), and Coldcard which silently produced a weak seed. The seed is encrypted at rest under the WKEK via wkek_encrypt_and_store rather than written in clear, and generation only occurs when no seed could be decrypted, so a working device does not silently re-roll. Observation (not a defect): this is a SINGLE entropy source, unlike Trezor's XOR of MCU plus secure elements or Keystone3's three-source HKDF chain - if that secure element's RNG were biased, nothing else contributes. A legitimate design position given a certified part and fail-closed handling, but a materially different trust assumption worth stating. Second observation: the seed LENGTH was not verified (seed_t unresolved in a blobless clone), so this record makes no claim about entropy sizing.