fix(reset): stop displaying internal entropy - #336
Merged
Conversation
Reconciles this branch with alpha now that the dice-entropy work (#341) has landed there. The two are NOT in tension -- they are complementary, and merging them clarified why: reset_init() keeps dice_entropy and drops display_random. The dice block folds rolls into int_entropy; the display block merely SHOWED that value. Removing the screen leaves dice untouched functionally. The comment above the dice block claimed the displayed entropy was a verifiable post-mix commitment. That was wrong and is corrected here: a host that supplies ext_entropy and reads the screen once computes SHA256(shown || ext) -- the seed pre-image -- and dice change nothing, because the displayed value is already post-mix. So the screen actively undermined the feature it appeared to support. The roll digest is safe by contrast: it hashes the user's own input, not seed material. Also carries #341's awaiting_entropy disarm, which closes the host-controllable-seed hole on aborted resets. deps/python-keepkey -> b44f1b3, which retargets the two tests that asserted the Internal Entropy ButtonRequest. They now send display_random=True and assert the next message is PinMatrixRequest, testing the compatibility claim directly. Verified: ARM device build links (.text 616,620) and 6/6 reset tests pass against an emulator built from this branch, dice test included.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Security invariant
Production firmware must never render or return the 32-byte internal entropy used as seed pre-image material.
Change
Internal EntropyOLED confirmation path from resetdisplay_randomfrom the internal reset APIBefore this change, a host could set
ResetDevice.display_random, supply the external entropy, and reconstructSHA256(internal_entropy || external_entropy)after observing the screen once.Validation
make xunitexecution: firmware 388/388, board 2/2, crypto 4/4, Pallas constant-time 7/7display_randomand noInternal Entropyscreen remainsfirmware.keepkey.bin: 649,748 bytes)firmware.keepkey.bin: 361,076 bytes)Compatibility
The protobuf schema is unchanged. Hosts that still send
display_random=truereceive normal reset behavior without an entropy screen.Hardware check
On an uninitialized test device, send otherwise-identical reset requests with
display_randomfalse and true. Both must follow the same PIN/backup flow, and neither may display entropy bytes.The wider hardening sequence and acceptance gates are tracked in #334.