# Summa - Attack Vectors

Many of the attacks described here are inspired by [Chalkias, Chatzigiannis, Ji - "Broken Proofs of Solvency in Blockchain Custodial Wallets and Exchanges." (2022)](https://eprint.iacr.org/2022/043.pdf). This post was coauthored with Stenton Mayne.

The attacks are divided in two categories:

- Proof of Address Ownership
- Proof of Liabilties

For each mentioned attack, a description on how this is tackled by Summa is attached.

## 1. Proof of Address Ownership (PoAO) - attacks by the exchange

Common attacks that exchanges can carry out on PoAO protocols:
- **Collusion**: 2 or more exchanges sharing addresses in their PoAO.
- **Friend attack**: exchanges using a friend's address in their PoA. A friend is not another exchange, or it is another exchange that is not performing Proof of Solvency (to distinguish this from collusion).

Note the friend attack can happen in 2 ways:
1. the friend sends funds to the exchange address
2. the friend shares a signature with the exchange

Summa is designed in a way that the addresses of the Exchange are public. On top of that, the Exchange is proving ownership of these addresses by producing a signature of some arbitrary data.

The collusion attack is avoided because anyone can check that one exchange's set of addresses has an empty intersection with any other exchange's. The history of addresses provided for PoAO is available inside the Summa Smart Contract so anyone can check these intersections.

Defending against a friend attack is a trickier.

In the case in which the friend is sending funds to the exchange address, this suspicious operation can be detected by on-chain analysis. The exchange can be asked to justify such operation if needed.

In the case in which the friend is sharing a singature with the exchange, requesting a fresh signature for every round of Proof of Solvency would provide an hedge against this possibility.

## 2.1. Proof of Liabilities (PoL) - attacks by the Exchange

Suppose our PoL is a based on a Merkle Sum Tree.

### 2.1.1. Excluding users from PoL

It is up to each of the users to perform verification on their side for the PoL protocol to work. Over many PoLs the exchange may learn which users perform verification and which don't. They can then safely exclude users who do not perform verification without getting caught.

One way to solve this would be to have the tree live in a public space or with a trusted 3rd party. The exchange would then not know which users perform verification. It doesn't solve the problem entirely because the exchange could still rate the likelihood that a user is performing verification based on how active they are on the exchange; example: dormant users may be a good candidate for excluding from the PoL.

### 2.1.2. Users with negative balances added to the tree

An exchange could lessen their total liability by adding users with negative balances to the tree.

Since the values inside the Merkle Sum Tree are not made available to the public, the solution is to enforce a range check constraint within each inclusion proof. This range check enforces that each balance value within a Node is in a specific bit range. This also avoid the possibility of the accumlated balances overflowing the modulus prime.

In Summa, catching this attack relies again on the users having to perform the verification.

### 2.1.3. Dispute resolution

If the exchange holds the tree and only gives inclusion proofs to authenticated users then its possible that the exchange just refuses to give a certain user their inclusion proof (maybe because they were left out of the tree). The idea is that the user would make a public statement about this, but why would anyone believe that someone claiming to be a user of an exchange is actually one? The process would need some rigor otherwise anyone who is not a user would be able to claim that they are a user and shed a bad light on an honest exchange.

Another user-exchange dilemma occurs if the user's balance is misrepresented in the PoL. How can the user convince the public that their balance is correct and the one given by the PoL is incorrect?

Summa doesn't offer a solution to this up to now. An idea for this would be to have the user balance data signed by the exchange, If the user can present a signed balance logs to the public, then the exchange would have to answer by giving an inclusion proof for that user that matches the balance.

Without the signed sheet nobody needs to believe the user (so one cannot give a bad name to an honest exchange) and without the inclusion proof nobody needs to believe the exchange (so the exchange cannot exclude a user).

An alternate defense would be to have the user use TLSNotary while interacting with the exchange's webpage to produce a proof that they were shown a particular balance at a particular time.

### 2.1.4. Collusion with a large user

An insolvent exchange could cheat by colluding with a large user. For ease of calculation suppose this user holds half the total liabilities, and suppose the exchange only has half of the assets needed to pay back their liabilities. The exchange can promise to this user that they are going to recieve all of their funds back as long as they keep quite. The exchange then produces a PoR and excludes this user from the PoL. Even if all the other exchange's users verify the PoL on their side the exchange will not be caught.

### 2.1.5. Uniqueness of user IDs

If user IDs are not verifiably unique then 2 users that have the same ID and balance can be mapped to the same leaf node in the tree, which decreases the total liabilities. Requiring the same balance _and_ ID does make this attack rare but it's still worth noting as a possibility. A solution to this is using a user ID that uniquely maps to a user, such as a username or an email.