-
Notifications
You must be signed in to change notification settings - Fork 23
Threat Model
More than being a privacy solution, Mobius needs to respect some fundamental requirements in order to be widely used. Namely, it is paramount to make sure that funds stored on the Mixer contract cannot be stolen by a malicious users. Moreover, it would be highly desirable if Mobius could support a set of primitives to give users the possibility to claim their funds back from the Mixer after a given amount of time. In addition to that, atomicity needs to be ensured in the case where payments are split into a set of smaller denominations. An unexpected error should not prevent a recipient to claim a part of his funds only. The withdrawal should be atomic, and failure free.
Being described as a privacy solution, Mobius should make it hard for someone to find out information users of the system don't want to reveal. While "hard" is still to define here, it is important to notice that users of Mobius should not be interested in perfect anonymity. In fact, an attacker would be able to distinguish Mobius users from non-Mobius users, by observing their interactions with the Mixer contract. Thus, the promise of undistinguisability of Mobius users among all Ethereum users is not intended to be respected. Instead, Mobius, provides plausible deniability among a set of users involved in the transaction of the same denominations (the anonymity set is composed of the members of a same ring). We define two pieces of information a user might be interested to hide:
- The link between sender and recipient (ie: "Who is interacting with who ?")
- The amount of a transaction (ie: How much a party is sending/receiving ?)
Mobius stands as a solution to the first question, and hides the link between sender and recipient, while obfuscating their respective identities.
While Mobius should provide a sufficient level of privacy for its users, it would be foolish to state that the levels of security and privacy are absolute. Information systems are constantly subjects to attacks, and we do not see how Mobius would be an exception. Being able to de-anonymize parties could give a malicious actor a competitive advantage among its counterparties. The following sections describe a set of threats Mobius might be subject to.
Cryptanalysis is the art of breaking crypto-systems. As Mobius relies heavily on cryprographic primitives, being able to find flaws in the cryptography used in Mobius, could give an attacker a way to de-anonymize parties of a transfer, or, even worse, stealing funds on the contract. While this threat is serious, we ignore it in the next parts of this document. In fact, Mobius uses well known cryptographic primitives, that rely on mathematical problems that are acknowledged to be hard by the scientific community. Thus, we assume that the cryptography threat is negligible. Carrying out an attack to break Mobius' cryptography would be intractable for any attacker (academics and states included). However, a breach in the underlying cryptography would translate in a breach in Mobius security and privacy (see: Quantum computing section)
The Ethereum blockchain is inherently open. All data stored on the blockchain is accessible by everyone. Smart contracts are not an exception. Thus, even if used in a private network, the Mixer contract, and in a larger extent, all contracts composing Mobius, are accessible by all members of the network. This means that each actor of the network can audit the contracts and exploit potential flaws in the code. By not revealing the vulnerability, a malicious user could carry out a zero-day exploit, and trigger odd behaviors in the contracts, leading to stolen funds or de-anonymizing other users for instance. The well known DAO hack on ethereum is an example of a successful attack on a contract.
Being able to replay Withdraw messages is a concrete example of the contract analysis threat. In fact, there is currently a vulnerability in the LinkableRing.sol contract that allows withdrawals to be replayed. This gives an attacker two possibilities. In the first case, the attacker could crawl through failed transactions and use the data submitted in the withdrawal, namely the ring signature that allows withdrawal of funds, to withdraw from the ring on the legitimate beneficiary's behalf. However, to carry out this attack, the malicious user needs to wait until a honest withdrawal fails (due to an unsufficient amount of gas specified in the transaction for instance). More interestingly, by knowing this breach, and by having a good undertsanding of the Ethereum protocol, the attacker could replay withdrawals in almost every circumstances.
Consider the case where an attacker listens to events and waits for the MixerReady event denoting that a ring has been filled. He then floods the network with transactions as an expected withdraw() call is made which is unable to be processed due to his flood. He then extracts the information from the withdraw() call made by the beneficiary to perform his own withdraw() call at a gas rate that prioritises his call above others and successfully withdraws the funds.
Mobius is vulnerable to a deposit withholding attacks where a participant deliberately withholds depositing into a ring. This results in any funds deposited into a ring being locked and preventing withdrawals. This has the effect of stalling transactions on the network and locking funds into the contract. This attack is also zero cost to the attacker since there is no action and no gas to pay.
Suppose Alice is paying Bob and Mallory is paying Charlie. Both are making payments of 1 ETH. Their payments go through a ring of two with a denomination of 1 ETH. Assuming the off-chain data has been generated and distributed to participants Alice makes a deposit of 1 ETH into the Mobius contract. Mallory does not make a payment into the contract. This means that the MixerReady event is not fired and that it is not possible to withdraw from the contract. Furthermore Alice's funds are locked in the contract.
On a larger scale a network participant in a network who wishes to disrupt the network can simply initiate trades but not deposit funds into rings on the network. Particularly in networks where there is high liquidity and low denomination values this will result in rings remaining unfilled. It would be possible to directly affect the ability to trade on the network by simply not trading.
Mitigations against the attack include a destruction mechanism by which the ring can be destroyed and funds returned to the recipients. It would also be possible to create a "dummy payment" system to fill up rings, although this would require knowledge of the private keys required to deposit and this introduces another attack vector.
The Mobius contract emits a series of events throughout the lifecycle of the contract. These events are emitted to the chain and anyone may listen to the events with no need to pay gas.
The events fired are
- Mixer Deposit
- Mixer Ready
- Mixer Withdrawal
- Mixer Dead
Data emitted is as follows
Mixer Ready:
-
ring_id- a unique hash of the ring -
message- an arbitrary message to be signed by private keys when withdrawing from the ring
Mixer Deposit:
-
ring_id- a unique hash of the ring -
pub_x- the x of a public key depositing into the ring -
token- the token being transfer -
value- the amount being transferred
Mixer Withdrawal:
-
ring_id- a unique hash of the ring -
tag_x- the x of a unique tag of a signature corresponding to a deposit public key -
token- the token being transfer -
value- the amount being transferred
Mixer Dead:
-
ring_id- a unique hash of the ring
It is thus possible to see transaction flows going through rings and ascertain information like the total volume going through the network and the total volume for token types.
A simple computation allows an attacker to get the state of each ring in the Mixer
state_of_rings_of_denomination_X_at_time_t = number_of_observed_deposit_of_value_X_at_time_t / RING_SIZE
There are situations where this can be used to facilitate replay attacks.
For the purposes of this model we assume a private network where network members have a Private IP Address. These addresses are not accessible to the public network. Private IP addresses are addressable within the network.
Probabilistic methods of indirectly discerning the identity of users of the network can be performed via analysis of transactions in the TxPool in tandem with the source node of propagation.
This method is probabilistic if we assume that the network respects a fully connected mesh topology (or that an attacker is able to connect to each nodes of the network). By being connected to each nodes, a malicious node (under the control of a malicious user) that receives a transaction from a peer gives the attacker the possibility to infer that the received transaction is likely to have been created and broadcasted from the receiving node. While, some routes of a network can be congested, this attack, coupled with timing analysis and any other source of information can unveil security breaches to an attacker. As such, as with other probabilistic methods, garnering confidence in discerning actual patterns relies on collection of data and subsequent analysis and pattern recognition en masse with the implied caveat that any result attained is still to a degree of confidence. This attack scenario is plausible either in public network (using public IP addresses), but also in private networks (using private IP addresses), in the case where malicious actors inside the network decide to launch an attack (insider attack).
This information could be used to discern account addresses that can be used to track their transactions. If a node is receiving transactions from other nodes, it immediately knows the address that issued the transaction and the node from which it has come. If, by data analysis of a collected data set over a certain period of time, it is clear that transactions from a certain address appear to be broadcasted from a specific node more often than others, the attacker can discern with some probability that the owner of the node is also the issuer of the transactions from said address. The address can now be deemed as de-anonymised.
See: https://github.com/clearmatics/mobius/wiki/Security-reflections#exploit-of-side-channel-leaks for further details about Side Channels attacks.
See: https://github.com/clearmatics/mobius/wiki/Security-reflections#sybil-attack
In a Private Network an assumption is often given is that gas can be zeroed out or can be given to network participants as part of their membership. Given that gas is an expression of computational power on the network this is a dangerous assumption.
If gas were zeroed an attacker can flood the network with malicious transactions and halt the network. If there is no monetary value attached to gas there is no disincentive to not launch these attacks.
Zeroing the gas is a hard problem to solve as it requires solving the "halting problem", or assuming some trust between parties on the network.
The Ethereum protocol enforces that gas costs are paid by those executing function calls that use computational power. This means that for Mobius a link between the address depositing into the contract and the address withdrawing from the contract is made.
One suggestion is to amend the protocol to allow a contract to pay its own gas. This is dangerous in that there would be zero incentive to not launch an attack on a contract if the contract were to pay its own gas.
A design choice to introduce privacy to the Mobius protocol is the usage of stealth addresses for withdrawals. Given that a withdrawal operation incurs a gas cost a stealth address must be funded in order to complete the withdrawal.
Thus, funding a stealth address creates a link between the withdrawal and another account. If for example the stealth address were funded from the beneficiary account the privacy model would be broken.
For a contract to be able to make token transfers on behalf of a sender he or she must authorize that the contract can make a token value transfer on his or her behalf. For the Mobius contract a sender must call the following before initiating a Mobius transfer.
token.approve([mixerAddress], [amountToApprove], {from: [senderAccount]});
This has the potential to leak information if a primary account is used. If a stealth address is used this introduces an issue whereby the stealth address must be funded in order to authorise the transfer. If the stealth address has insufficient funds this introduces a requirement to fund the stealth address, creating a link between the stealth address and another address.
The view key in Mobius allows the holder to decloak a transaction and see a transaction in the clear. Given that all privacy is removed with the usage of the view key the privacy solution can be entirely compromised through targeting the view key. As such extremely high levels of security should be used for distributing and storing view keys.
An assumption that should be stated is that Mobius as a privacy solution should be assumed to not be Quantum proof. Given that Mobius is bounded by the Discrete Logarithm Problem when Quantum computers become widely available it will be possible to decode Mobius transactions through Blockchain data.