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

Enforce the sorted-keys precondition for by-key map reads

Public commit record

What the developer wrote

Authored by Salvatore Ingala

85/100 · Strong
Enforce the sorted-keys precondition for by-key map reads

Reading a value out of a merkleized map by key is only sound once the
keys tree has been verified to be lexicographically sorted, and hence
that the keys are unique; otherwise a malicious client could equivocate
on the value committed to by a given key. So far this was a documented
convention, whose enforcement was expected from the callers

Instead, here we track the invariant in the commitment itself, via a new
private _keys_are_sorted member of merkleized_map_commitment_t.
call_get_merkleized_map[_with_callback] and the new
call_check_merkleized_map_sorted set this field on success.

All the readers by key, like call_get_merkleized_map_value,
call_get_merkleized_map_value, and the streaming versions) will now fail
explicitly if the _keys_are_sorted sentinel is not set.

The member is documented as private and named with a conventional _;
callers must neither read nor set it.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit hardens a Ledger Bitcoin app security check. Previously, reading a value from a special data structure (a 'merkleized map') by key required the caller to first verify that all keys were sorted and unique; that was only a documented rule, not enforced. A malicious host could potentially trick the app into reading the wrong value for a key if the rule was skipped. The patch now tracks a 'keys are sorted' flag inside the map commitment itself and makes all by-key readers fail (via an internal assertion) if that flag is not set. It also adds a helper to validate maps that come directly from the APDU command (like the PSBT global map).

Recommended action

Review all call sites that populate `merkleized_map_commitment_t` outside the two validated paths (`call_get_merkleized_map*` and `call_check_merkleized_map_sorted`) to ensure `_keys_are_sorted` is never set directly. Confirm that `LEDGER_ASSERT` behavior on the target Ledger OS is acceptable for a security precondition (ideally replace or supplement with a runtime error return in production). Run unit tests and fuzz the dispatcher mock to verify by-key readers fail when the flag is unset.

Security signals we found

01

Defense-in-depth invariant enforcement

02

Precondition for by-key merkleized map reads now asserted

03

Potential equivocation / wrong-value-read mitigated if callers skipped sortedness check

04

New API helper `call_check_merkleized_map_sorted` for APDU-direct map commitments

05

Use of `LEDGER_ASSERT` (debug/fault behavior) rather than runtime error return

Risk score

Why this scored 76/100

Our methodology →
Potential impact 22/30
Exploitability 18/25
Stealth signal 12/15
Affected reach 12/15
Confidence 8/10
Evidence quality 4/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.