Determine Severity Benchmarks for 3rd edition

[kristovatlas]

We'll put some notes about our discussion of severity benchmarks in this issue.

Severity benchmarks help us determine weight or effectiveness of elements in the threat model by providing more granularity and systematic metrics for obtain weights and effectiveness scores.

They should be

• Unique
• Mostly not overlapping or co-dependent
• Estimable/non-ambiguous
• Invoked at an appropriate level of the threat model

For this edition, I would suggest that we do not list the same benchmark in a node's children, and that we use the same set of benchmarks for all cousin nodes to ensure that we're doing apples-to-apples comparisons.

[kristovatlas]

Some possible benchmarks for consideration:

• Likelihood of attack against average Bitcoin wallet client user (This should characterize the likelihood that the average user will be targeted based on present, historical, and likely future conditions)
• Likelihood that attack has been conducted against the average Bitcoin wallet client user in the past (This should characterize the likelihood that the average user has been targeted based on present and historical conditions)
• Quantity of likely attackers (This should characterize many vs. few likely attackers for a given attacker category or attack, based on present and historical conditions)
• Temporal window of attacks (This should characterize a long vs. short window of opportunity for a given attacker category or attack)
• Estimated cost to attacker to perform attack against enough users to include average user
• Estimated cost to attacker targeting a specific user (This should characterize a small or large cost to the attacker in order to carry out an attack against a specific wallet user. The following guidelines are suggested for a score ranging 0 to 100: Within resources of average first-world consumer ($0 to $1000 USD): 1/100; Within resources of businesses ($1000 to $100,000): 10/100; Within resources of nation state ($100,000+ USD): 100/100)
• Cost to scale attack from targeting one user to targeting many users
• Probability of attack success if unmitigated (This should apply to attacks)
• Payoff to attacker if attack is successful
• Severity of information gained in successful attack (This should reflect the impact on the user if the attack is sucessful in terms of the amount and sensitivity of information obtained by the attacker, and should be applied to the attack category)
• Effectiveness of countermeasure against attack
• Completeness of criterion in determining whether a countermeasure has been implemented

[kristovatlas]

A high-level formula: Weight is information profit.
Information profit = Benefit to attacker - Cost to attacker

We should expect the following results:

• Low resource attackers will not attempt attacks that cost more than their resources
• High resource attackers will always choose the attack with the most information profit

Other security models in the past have used:

Severity = Impact * Likelihood

[dcousens]

• Scales of attack (Blockchain > Neighbourhood > Wallet Application > User)

[kristovatlas]

A few initial notes from myself and @dcousens comparing the Blockchain observer and network observer attacker categories:

Blockchain attacker is:

• passive
• scaling the attack is linear
• low cost (small business resources to do in-shop, various free resources, about $10k to subscribe to analytics)

Network attacker is:

• interactive (to varying degrees)
• generally more targeted in nature
• somewhat cheap to scale to connect to all P2P nodes, but resources to cover non P2P wallet clients are along the lines of ISPs, Telecom providers, govts, etc. very expensive to scale to global level

These qualties can be distilled to these severity benchmarks:

• Cost of attacking an individual
• Cost of scaling attack from one to many

[kristovatlas]

Some assumptions we're using:

• The average user has connected his online identity with at least one bitcoin address publicly
• The average user has a small number of wallets, probably 1
• The average user has a small number of total bitcoin addresses, Jonas Nick estimated this number to be less than 10
• Average user is not using a P2P wallet client. (Our model should account for both types of wallets, however.)

[kristovatlas]

The cost for a Blockchain observer to attack the average user individually: 1 on scale of 1 to 5 (close to free)
Scaling to many users: hundreds of thousands of dollars to create a service to do this. We're ignoring people who subscribe to such services.

The cost for a Network observer to attack an individual: High cost, probably millions of dollars for a network attacker to insert himself into networks to observe particular users of non P2P wallets.
Scaling to many users: Tens or hundreds of millions of dollars against non P2P wallet users.

The Network observer category has some attacks that pertain to P2P (SPV/full node) victims and some are more network infrastructure-based. We need to make sure that we're not underestimating the risk of the Network observer category against P2P users, nor the risk of the Wallet Provider category against non P2P wallet users.

I need to think about whether we should move or copy any of the attacks in the Network observer category to the Wallet Provider category to make these two easier to weight.

[kristovatlas]

For reference, threat model: https://github.com/OpenBitcoinPrivacyProject/threat-model-scoring-system/blob/reorg-to-scoring-system/obpp3.json

[dcousens]

Blockchain Attacks

I.A

"name": "Link transactions to a single entity based on all of them containing inputs with a common address",

• Related addresses (by association with common address)
• Related transactions (by association with common address)

I.B

"name": "Link outputs in a transaction to a single entity by detecting which output is a change output",

• Co-ownership of addresses (by determination of what is a change output)

I.C

"name": "Link outputs to a single entity based on them all being included as inputs in the same transaction",

• Co-ownership of addresses (through the assumption of 1 transaction signing identity)

I.D

"name": "Link identities by observing that addresses associated with both identities are used as inputs in the same transaction",

• Co-ownership of addresses (by association with the other identity)
• Related addresses (by association with the other identity)
• Related transactions (by association with the other identity)

I.E

"name": "Derive the type of wallet used to create a transaction by observing idiosyncrasies in the manner in which the transaction is composed, such as input/output ordering, output or fee size, number or size of inputs, or script composition",

• Software used (by knowledge of software idiosyncrasies)
• Related transactions (linked by common software)

I.F

"name": "Correlate transactions with out-of-band behaviour by recording the time at which transactions are included in a block",

• Transactions (by association with out-of-band behaviour)
• Related transactions (by association of common broadcast/inclusion time)

[kristovatlas]

I.C and I.D are equivalent from the attacker's perspective and so should have a very similar or same weight.

[dcousens]

@kristovatlas agreed, and I think they should be merged 👍

[kristovatlas]

I.E could be split into a second attack: Link transactions or addresses to a single entity based on a common wallet client fingerprint.

[dcousens]

Addresses may have transactions.
Transactions always have addresses (outputs).

Therefore, leaking related transactions leaks related addresses.
But, leaking addresses doesn't always leak transactions (as they may have 0 transactions!).
And, leaking addresses does leak future transactions.
And, leaking related addresses does leak future related transactions.

[kristovatlas]

I need to think about whether we should move or copy any of the attacks in the Network observer category to the Wallet Provider category to make these two easier to weight.

Going through the Network Observer attacks to make sure that the following two severity benchmarks are not very different values for full nodes vs SPV vs thin client:

The cost for a Network observer to attack one average user in a non-targeted fashion

The cost for a Network observer to scale an attack from from average user to enough users to include the average user with 50% probability or greater

• II.A: Link addresses belonging to a single user by observing information leaked by the wallet in the process of obtaining its relevant blockchain data from the network
  • No problem -- full nodes have full countermeasure (Blockchain data is obtained from a local copy of the blockchain), SPV/thin clients don't
• II.B: Link addresses belonging to a single user by observing source IP address for relevant blockchain data queries
  • No problem -- it's as easy to observe IP address of a full node or SPV node for a Bitcoin P2P peer attacker as it is for a thin client data provider to observe the IP address of a thin client.
• II.C: Link addresses belonging to a single user by observing that multiple transactions enter the network from an origin point likely to belong to a single user
  • No problem -- full node has a countermeasure (A non-zero percentage of transactions broadcast over a network by the wallet client do not originate from the user) that SPV/thin clients don't
• II.D: Link a transaction's input address(es) to a specific IP address by observing the first relay of a broadcasted transaction
  • Same as II.C
• II.E: Reduce the false positive rate of filters by comparing how the filters received from a single client change over time
  • No problem here, except that we should probably list a countermeasure that explicitly covers full nodes. See the issue I just created now: add countermeasure -- do not update blockchain data filters #137
• II.F: Reduce the false positive rate of filters by comparing the transactions sent by a client with the filter they have sent
  • Same as II.E
• II.G: Link different identities based on a bloom/prefix filter or other query that matches blockchain data associated with multiple identities
  • Same as II.E
• II.H Link different identities by observing that the same IP address is sending outgoing transactions associated with multiple identities
  • TODO
• II.I Temporally link transactions to a known IP address via side channel attacks based on wallet behavior
  • TODO
• II.J Derive the type of wallet used to create a transaction by passively observing idiosyncrasies in the interactive behaviour of the wallet
  • TODO
• II.K Correlate activity of a specific wallet across different connection sessions by observing idiosyncratic client wallet behavior which acts as a unique fingerprint
  • TODO
• II.L Correlate an IP address to a likely transaction participant by monitoring for queries (to a block explorer, etc.) about specific recent transactions
  • TODO
• II.M Perform a transport-level MITM attack on a connection between the wallet and a source of server to obtain PII and/or insert malicious code into the communication between wallet and server
  • TODO
• II.N Identify an entity as a likely transaction participant by observing out-of-band notifications subsequent to a transaction generated by any participant and/or their wallet provider
  • TODO
• II.O Determine the change output of a transaction by observing different versions of it broadcast as part of an RBF process
  • TODO
• II.P Correlate transactions with out-of-band behavior by recording the time at which transactions enter the network
  • TODO

WIP

[kristovatlas]

Need to reorg network attacks:

1 and 2 should be combined.

3 and 12 should be combined with a new attack, which is the tx version of 1 & 2 which deals with addresses. Need to create new countermeasures/criteria to discriminate.

3 is about clustering based on common IP address, whereas 4 can lead to more investigation about the particular IP address.

Daniel suggests eliminating 6 (F): By using a bloom filter, the attacker can just look at the blockchain to infer relationships between address, they don't need to see a transaction broadcast from you.

[dcousens]

Network Observer Attack 5 of 16

name: Reduce the false positive rate of filters by comparing how the filters received from a single client change over time

Related Addresses, or
Related Transactions (depending on what is used) (by comparing filters for commonality of matching data)

[kristovatlas]

2 valid criteria:
-different tor connections to multiple or same peer
-using different peers for different activities, e.g. 1 for broadcasting and 1 for querying.

The second is less robust b/c it's based on the probability that the peers aren't colluding.

[kristovatlas]

for I.D and II.G the info leaked is: related identities

[kristovatlas]

Tonight myself, @crwatkins, and @dcousens discussed re-organization of network attacks. We discussed proposed changes in the above comments and some offline work we've been doing. A few notes:

• Attack II.B in the working draft can be generalized to include other kinds of non-transaction identity data, including not just IP address but also time zone, bandwidth/latency capabilities, cookies, etc.

OBPPV3/CM30: Avoid communicating state-based information to other entities which could be used to uniquely identify the client

Note that Core's applying timelock to transactions based on current height may violate this countermeasure -- food for thought.

a comment about a criterion in the Hjson doc:

comment: "Stateful information includes a unique browser fingerprint, HTTP cookies, HTTP headers, etc." }{

• ^ We should add api keys to the list of examples here.

• Network attacks 3 and 4 should be combined; 4 is a subset of 3. 3 will be reworded to make it clear that we're focusing specifically on the "first hop" aspect; attack 4's description should be the reference point for the new description for 3.

• Note that 3’s compromised data should be a low-confidence clustering of addresses because the majority of users are not broadcasting transactions directly to the Bitcoin P2P network, but instead recruiting a wallet provider to do so — this means the attacker can link the broadcast first hop with high probability to the wallet provider, but not to the individual user using the first hop IP address.

• 5 looks good in our working draft;

• removal of 6 and moving its countermeasure to another existing attack is ACK’d.

• Removal of 11 and moving its countermeasure to other attacks as appropriate is ACK’d.

• 1 and 2 should still have copy attacks added that apply to tx's rather than addresses.

Once we’re happy with our working draft in a Google Drive doc, I’ll make a PR to the working copy on GitHub and try to explain all the changes in commit messages.