Guard against malicious sentinels

[metalicjames]

In the current UHS-based data model, sentinels validate the transaction-local invariants of a full transaction, before converting the transaction to a compact representation which is the data structure processed by the backend (2PC or Atomizer). Since the data required to validate the full transaction is lost after being converted to a compact transaction, it would be trivial for a compromised sentinel to submit an invalid transaction for processing. This would allow the adversary to spend any UHS ID, and mint arbitrary UHS IDs representing any value (that an honest sentinel would later accept as a valid output). This is possible because the upstream component from the sentinels (shards in the atomizer architecture, coordinators in 2PC) blindly accepts compact transactions (deleting input UHS IDs, and creating output UHD IDs) and has no knowledge of the pre-image data. The current implementation does not restrict the origin of compact transactions either, so any entity with internal network access can send compact transactions directly to backend components, bypassing the sentinels.

It would be desirable to protect against up to n sentinels being compromised. n should be configurable based on the threat model and number of nodes in the system. As long as <=n sentinels are malicious, it should be impossible to settle an invalid transaction. Furthermore, upstream components should only accept compact transactions for processing from known sentinels.

[davebryson]

@metalicjames @HalosGhost This is an interesting challenge. How do reach consensus on the state of the sentinels without maintaining some kind of shared state?

Thinking out loud here...my initial reaction is a simpler approach with redundant validation:

• Add secure, authenticated communication between the core services (ssl, noise protocol...). This helps with the 'origin' issue
• Sentinel does initial validation to immediately drop any bad Txs - but it does not compact the Tx
• Something (another service) sitting close (behind the same walls) to the coordinator does a secondary validation and then compacts the Tx to the coordinator. Any failed validation here marks the sentinel as "bad" and ignores it until the problem is resolved. This implies that this other service maintains some form of state on the sentinels it's connected to.

Of course now I just need to compromise the secondary validator...

[HalosGhost]

@davebryson there are a couple of interesting things to consider there. I think your final note rings true for me (that moving compaction to a secondary validator is just shifting the burden rather than solving the problem). Additionally, that idea distills to having two sentinels validate the transaction rather than allowing it to be a configurable threshold (as James's PR supports). It also has the additional negative that, right now, the only component in the system that sees the values in a transaction are sentinels; if compaction is moved out of the sentinel, then there's at least one other role inside the network that gets to see more information about a transaction which is a weakening of the system's privacy guarantees.

As for disallowing connections from a sentinel that has forwarded a bad tx, there's some additional trouble there:

1. you'd need some way to reliably identify the sentinel (e.g., have sentinels sign txs before forwarding them—much like James's PR—and maintain a list of blessed keys; however, doing that may require replicating updates to that list of blessed keys throughout the system),
2. you'd want some way to avoid the potential for an attacker to convince you that a sentinel is malicious even if it isn't (because that would become a vector for denial-of-service attacks)

Secure communication between the components is probably not a terrible idea regardless (as a defense-in-depth measure for an attacker who has managed to get inside the privileged network even if they haven't compromised one of the machines actually participating in the network); however, it alone is not enough to address the compromise of a sentinel (once a sentinel is compromised, malicious communication to the next component in the system could still happen over the secure channel).

[davebryson]

@HalosGhost Some form of BFT consensus among the sentinels sounds like a viable solution. But this will certainly impact performance.

[HalosGhost]

Mmm, that's absolutely true. BFT could offer an answer to a much stronger threat-model than the one posed in #80. In particular, BFT would allow not just tamper-detection, but tamper-prevention for up to f simultaneous compromises/failures (as long as there are 3f+1 nodes operating).

What's more, it could probably be leveraged beyond just the sentinels. However, you're right that it would likely have a pretty significant performance impact—that doesn't mean, though, that we shouldn't explore it as a solution. And, if you wanted to implement that as a proposed solution, that would be interesting to review.

[davebryson]

Here's an interesting approach they may have some applicability to the problem:

FastPay allows a set of distributed authorities, some of which are Byzantine, to maintain a high-integrity and availability settlement system for pre-funded payments. It can be used to settle payments in a native unit of value (crypto-currency), or as a financial side-infrastructure to support retail payments in fiat currencies. FastPay is based on Byzantine Consistent Broadcast as its core primitive, foregoing the expenses of full atomic commit channels (consensus). The resulting system has low-latency for both confirmation and payment finality. Remarkably, each authority can be sharded across many machines to allow unbounded horizontal scalability. Our experiments demonstrate intra-continental confirmation latency of less than 100ms, making FastPay applicable to point of sale payments. In laboratory environments, we achieve over 80,000 transactions per second with 20 authorities---surpassing the requirements of current retail card payment networks, while significantly increasing their robustness.

https://arxiv.org/abs/2003.11506

FastPay is using an account based model. Byzantine Consistent Broadcast may be worth investigating in the context of the Sentinels and UTXO model

[HalosGhost]

closed via #87