ME-01 Untrusted Address Book Could Lead to Unavailability

[xoloki]

The library receives as part of its configuration sensitive information including maps linking
key_id values and key_ids to public keys that are not validated. This is a very sensitive
point, as an attacker controlling this address book could gain complete control over the
signing process. Moreover, the config object is missing the coordinator’ s public key, so it
appears there is no way to specify this at signer creation (e.g., you will need to manually set
the variable).

[xoloki]

The library must receive the address book from somewhere, and even if it is signed the library would have to receive the signing public key as well. stacks-signer uses contracts to provide some semblance of verification of this critical data. sbtc-signer simply puts the relevant data into the config, then parses it and passes it to the library.

As for the Coordinator public key, it is not possible to specify this at signer creation because in all applications it rotates over time. sbtc-signer for example has a new coordinator for every bitcoin anchor block. stacks-signer never found an adequate solution to this, eventually resorting to building a bft-paxos library so it could have a consistent view of who is the coordinator in an adversarial context.