Adding Minimal Tamper Detection

[HalosGhost]

Question

What are the methods and trade-offs of improving the system's ability to detect an attacker inflating (or deflating) the monetary supply?

Benefit

Tamper-detection is a stepping stone toward tamper-prevention (which is an important area of CBDC research). The system as-implemented now has no method of detecting if any machine has been compromised or if a bug has caused incorrect data to be written in the UHS (specifically, an attacker compromising a single machine is able to undetectably alter the monetary supply). For example, a shard can insert a malicious UTXO in its state and continue system operations as normal. This inflates supply, yet we don’t have any detection or prevention mechanisms against this. There are several ways to potentially improve the system's ability to detect such an attack, but the trade-offs are unclear (performance degradation seems possible, at least). Knowing the trade-offs, inherent or not, in various methods of tamper-detection may inform practical endeavors and potentially reveal other avenues to explore.

Proposed Solution

As the system currently offers no detection ability, the first identified threat model to address is to allow the system to detect tampering (even if after-the-fact) in the face of a strong attacker achieving total compromise of any single machine. (In this proposal, we don't consider weaker attack models where the attacker only has access to a single node’s storage layer or cryptographic keys, etc., nor do we consider the case where a problem in a component would cause multiple nodes to be compromised, like a bug in LevelDB.) This threat model only focuses on detecting the alteration of the monetary supply after such a compromise occurs. This is weaker than protecting against multi-machine compromise, but it is a first step towards a more hardened system. Other threat models and solutions should be explored further in other proposals.

There are a variety of methods to explore which would enable solving for the above threat model. Of the ideas generated, the options below stand out as avenues to explore first (though they are not necessarily the best options and need to be evaluated against the multiple goals our system has).

Guarding against a sentinel compromise:

• Guard against malicious sentinels #84

Guarding against shard/atomizer/coordinator compromise:

• Enable supply auditing by storing values in the UHS #100
• Enable supply auditing by storing cryptographic commitments #101
• Add an automated tool to run a supply audit

Possible Difficulties

There are already trade-offs between storing values in the UHS and leveraging more cryptographic techniques: in particular, storing values in the UHS, though perhaps the simplest solution, goes against one of the purposes of using the UHS in the first place (blinding values from the transaction processor), and cannot meet the threat model if the compromise takes place during an audit; however, leveraging cryptographic techniques (e.g., Pedersen commitments, range proofs, etc.) may come with significant performance decreases (though it preserves the spirit of privacy that the system currently possesses).

Prior Work

• Pedersen, Torben P.. “Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing.” CRYPTO (1991).
• Bünz, Benedikt et al. “Bulletproofs: Short Proofs for Confidential Transactions and More.” 2018 IEEE Symposium on Security and Privacy (SP) (2018): 315-334.
• Narula, Neha et al. “zkLedger: Privacy-Preserving Auditing for Distributed Ledgers.” IACR Cryptol. ePrint Arch. (2018).
• Tamassia, Roberto. “Authenticated Data Structures.” ESA (2003).

Code of Conduct

• I agree to follow this project's Code of Conduct