Create a dedicated threat model for Leios #452
Conversation
| 5. SPOs in different segments create EBs endorsing different conflicting transactions | ||
| 6. Voting nodes must choose between conflicting EBs, potentially causing certification failures | ||
|
|
||
| **Cost**: MEDIUM-HIGH - Requires significant network infrastructure, multiple nodes, and sustained coordination |
There was a problem hiding this comment.
| **Cost**: MEDIUM-HIGH - Requires significant network infrastructure, multiple nodes, and sustained coordination | |
| **Cost**: MEDIUM - Requires significant network infrastructure, multiple nodes, and sustained coordination |
This doesn't require deploying many nodes if they are nodes custom-modified for this attack. The attack would require more nodes if vanilla ones are used.
docs/threat-model.md
Outdated
|
|
||
| **Prerequisites**: | ||
| - Control over significant network infrastructure (BGP routes, ISPs, or direct node connections) | ||
| - Knowledge of top 500 voting nodes' network addresses and topology |
There was a problem hiding this comment.
The Fait Accompli paper considers attacks similar to this and its proofs address the safety of FA in the face of those.
There was a problem hiding this comment.
Can you contribute a reference to this on the system overview, threat or mitigation of this?
|
|
||
| **Assets Affected**: Operational Sustainability | ||
|
|
||
| #### T6: VRF Manipulation |
There was a problem hiding this comment.
We might want to cross-reference the anti-grinding CPS and CIP.
| - Knowledge of transaction dependencies and profitable patterns | ||
|
|
||
| **Attack Vector**: | ||
| 1. Monitor mempool for profitable transaction patterns |
There was a problem hiding this comment.
Is this really different from the situation with Praos?
There was a problem hiding this comment.
No, but that does not make it less of a threat and I wanted to cover a range of threats which had been in discussion lately. What's your suggestion here?
There was a problem hiding this comment.
For this document we don't need to change anything, but when representation Leios we might want to clearly distinguish three categories of threats:
- Exists in Praos and similarly exists in Leios.
- Exists in Praos but more serious in Leios.
- Does not exist in Praos but does exist in Leios.
| **Control Type**: Preventive | ||
| **Implementation**: | ||
| - Parameterize EB opportunities and sizes for adversarial stake assumptions | ||
| - Example: Assume 30% adversarial stake, produce 2 EBs per stage on average |
There was a problem hiding this comment.
We might want to define a "design basis threat" that includes constraints on the stake controllable by each type of adversary.
There was a problem hiding this comment.
What do you mean? A threat that our assumed adversarial stake is wrong?
There was a problem hiding this comment.
I guess I'd like clarity about whether Leios should be robust against a 49% adversary, like Praos is theoretically. Or instead maybe we're aiming for robustness against a weaker adversary, perhaps 30%.
There was a problem hiding this comment.
The vote/certificate assumptions here ("top 500 nodes" etc.) clash with the previously reviewed specification. Is this document proposing a different approach to vote and certificate cryptography? If we we need a detailed specification that the cryptography team can study.
At some point we might want to align terminology between this document and the Notes on Attack Surface in the 2nd Tech report before we move any of this material into the Leios CIP itself.
A lot of the attack vectors are means to get conflicting txs in the EBs, so that resource are wasted. It might be helpful to discuss that in more detail, and centrally, so that individual threat and mitigation sections can reference that.
I scoped the protocol with very broad strokes here, for this needs to change as we zero in on a protocol variant for the CIP. Nonetheless I think sketching cardinalities on how many nodes, voters, transactions etc. we are dealing with is useful for threat modeling. What reviewed specification? Sounds like there is a recommendation; what should I put instead?
Yes, let's do that. Does this mean we move the threat model of tech report 1 and those sections in tech report 2 here or instead expand the thread model part of a tech report? What do you think of a dedicated threat model that details assets, threats and mitigations this way / following this threat modeling process? |
| 1. Attacker maps network topology and identifies cluster boundaries | ||
| 2. Creates conflicting transaction pairs spending identical UTXOs | ||
| 3. Submits Transaction A to Network Segment 1, Transaction B to Network Segment 2 | ||
| 4. Uses network position control (BGP, routing, eclipse techniques) to prevent cross-segment propagation |
There was a problem hiding this comment.
I don't think this is necessary. Even if all EB producers know about both transactions, how would you force them to all pick the same one? With random selection you'd get a 50% probability that both are selected so the expected value would be 1.5 transactions for the price of one. Now you can improve that in various ways, segmenting the network being one of them, but you can also control some stake (to make EBs that you know will conflict) or if you know about the EB schedule you can probably optimize who you send your transactions to. But also, depending on the details of an attack you might not even need to increase the probability of the conflict in the first pace.
There was a problem hiding this comment.
This also means that Control over multiple network positions to segment the peer-to-peer network would not be required.
There was a problem hiding this comment.
I don't think this is necessary.
I think it is a prerequisite in order to get conflicting transactions into the mempools of concurrently producing nodes. One would need to defeat the natural (fair?) tx diffusion happening between nodes. I should make that more clear in the attack vector here.
can also control some stake (to make EBs that you know will conflict)
I'd characterize this as a different attack due to the requirements and attack vector being quite different. This one is really about a network-attacker that does not control stake. Do you feel this would be much different to also T4 or T8 to warrant a dedicated entry? Would this "stake-based deliberate conflict" attack result in different impacts onto assets in the given system than the ones mentioned?
depending on the details of an attack you might not even need to increase the probability of the conflict in the first pace.
The attack here is about creating conflicting views, i.e. one or more transactions conflict between concurrently created blocks.
|
|
||
| **Assets Affected**: Decentralization | ||
|
|
||
| #### T?: Honey Pot Contract |
There was a problem hiding this comment.
@WhatisRT Can you check whether I summarized your attack correctly?
This is a first sketch for a threat model as a dedicated artifact. We have another similar collection of threats here https://github.com/input-output-hk/ouroboros-leios/blob/main/docs/technical-report-1.md#threat-model In this document, we follow an established process of threat modeling by also describing a system overview, assets to protect and go more into detail detail on threats, prerequisites, attack vector, cost and impact. This should be updated with more detail / reference the concrete protocol variant we propose in the CIP and accordingly with assets, threats and mitigations.
This is a first sketch for a threat model as a dedicated artifact. We have another similar collection of threats here
https://github.com/input-output-hk/ouroboros-leios/blob/main/docs/technical-report-1.md#threat-model
In this document, we follow an established process of threat modeling by also describing a system overview, assets to protect and go more into detail detail on threats, prerequisites, attack vector, cost and impact.
This should be updated with more detail / reference the concrete protocol variant we propose in the CIP and accordingly with assets, threats and mitigations.