Potential sign-with-your-key security vulnerability

[bladyjoker]

Users can make COOP Publishers sign and submit a mint-fact-statement-tx transaction with their keys.

BPI relies on a PABConfig configuration file to learn about where the wallet directory is. COOP uses several wallets, namely GOD, AA, AUTH, CERT_RDMR, and FEE, and if the user request a new mint-fact-statement-tx with a Submitter public keys hash set to of any of the above mentioned wallets, BPI will gladly sign and submit such transactions.

For convenience and testing, we used Plutip's local cluster and set the default flag values in coop-pab-cli to reflect a single PABConfig, and by extension a single wallet directory that contains ALL the wallets used by the COOP operator.

For production it's CRITICAL that the Authenticator wallets are kept ALONE in a separate directory, while other wallets can be bundled together as they are not used when servicing Submitter requests.

[GeorgeFlerovsky]

Furthermore, in production, it's CRITICAL that the $AA tokens be held on hardware wallets. These hardware wallets should be used to mint $AUTH tokens and distribute them to the Authenticator wallets that the backend service uses to publish fact statements.

BPI should not control the $AA tokens in production. It should only manage the Authenticator wallets and be periodically topped up with more $AUTH tokens from manual mints by the $AA-controlling hardware wallets.

[GeorgeFlerovsky]

The current state of the repository is not ready for production use until this issue is resolved.