Vulnerabilities

From Open Transactions
Jump to navigation Jump to search

Since it's important to keep all the potential vulnerabilities in the forefront, this page will help us keep track of those.

Transaction server might inflate the currency

Solution: This is prevented through auditing, which must be utilized, either by the issuer directly, or by the other members of the voting pool.

While the transaction server cannot lie on your receipts, it can potentially inflate the currency itself by using dummy accounts.
But the inflated funds cannot be spent without flowing into other accounts, where they will show on an audit.
This crime is also permanently detectable until the funds are removed again from circulation.

If the issuer has directly issued the currency onto the transaction server, then he must also conduct the audit.
Whereas if the currency is BTC, or if the issuer has used colored coins, then the coins should be uploaded into a voting pool so that the transaction server cannot steal them. In this case, the pool members must audit each other.

Transaction server falsifies an account balance, or a transaction amount

Solution: Falsified balances are prevented by the use of triple-signed receipts. (The OT server cannot do this sort of falsification.)

Every receipt is first signed by the client side, and then counter-signed by the server. Since the server cannot forge your signature, it cannot forge any receipt. Moreover, since your account balance itself appears on every receipt, the server cannot change your account balance. And since the receipt also contains a list of all valid transaction numbers for your Nym, neither can previously valid (and validly signed) instruments be used twice.

Transaction server refuses to process your transactions

Solution: Use a different transaction server. If necessary, have your funds re-issued onto a different transaction server, by going through the issuer or the voting pool (whichever is appropriate in your case.)

Vulnerabilities in web browser

An attacker could inject code into a web page and take control of your wallet, or trick you into signing a malicious transaction.

Solutions:

  • The OT API runs on the client side, outside of the browser. For web apps, a Chrome/Firefox plugin can be used to send transaction requests to a local systray application, where the wallet is actually controlled. From here, the systray wallet can pop up a confirmation and a passphrase dialog.
  • A hardware wallet can additionally be used to prevent any attacks from gaining access to your private keys.

Vulnerabilities in C++ code

An attacker could potentially buffer-overflow the C++ code and gain access to execute their own code.

Solutions:

  • Static and dynamic analysis. Some of this has already been done -- more must be done.
  • Security audit of C++ code.
  • Data validation in C++ code.
  • Test scripts for data validation.
  • Penetration testing.

Phishing attacks

An attacker who gains access to your machine might pop up a fake passphrase dialog and trick you into entering your passphrase.

Solutions:

  • On setup, ask the user to select a passphrase image for his passphrase dialog. This way, his password dialog will look different than every other user's passphrase dialog, and an attacker will not be able to impersonate it.
  • A hardware wallet can serve as a 'brick wall' in defense of these attacks.

Attacker might intercept a message and send it twice (Re-play attacks)

Solution: Each message contains a "request number" which must increment with each message. This prevents re-play attacks.

Issuer holding gold might lie about the physical gold

An issuer might create digital units when he doesn't actually have the physical gold to back them up.

Solutions:

  • Users must be picky about issuers.
  • A physical audit of the issuer's physical gold is the only way to make sure he actually has the gold.
  • A basket currency on OT allows each Nym to distribute the risk of a currency across multiple issuers.

Issuer holding Bitcoins might lie about the actual Bitcoins

Solutions:

  • Bitcoins on the blockchain can be audited by any observer. (This is an advantage that Bitcoin has against physical gold.)
  • Store the BTC in a voting pool, so that there is no longer any "issuer" who must be trusted. (Though the pool itself must be trusted.)

Re-using previously valid instruments

If Alice signs a cheque and gives it to Bob, and he deposits it, what's to stop Bob from depositing the same cheque twice? (The signature is still valid...)

Solution: Each cheque must have a transaction number on it, which was previously signed-out by the cheque signer. Once the cheque is deposited, a chequeReceipt is placed in the cheque signer's inbox. The same cheque cannot be deposited twice at this point, because there would then be two chequeReceipts in the same inbox, each carrying the same transaction number. And once the cheque signer accepts the chequeReceipt from his inbox, a new balance agreement is signed, which includes the new balance as well as the new list of "valid transaction numbers" for that Nym. Since this new balance agreement removes the cheque's transaction number from the list of valid numbers for that Nym, any further deposits of the same cheque would be invalid, since it now carries an invalid transaction number (one that is no longer signed-out.)

This makes it possible to prove which instruments are valid, without storing any transaction history other than the last signed receipt. That receipt includes a list of the valid transaction numbers for its Nym. (All transactions inside OT use this same mechanism.)

Gold-based issuer lies about the number of units issued

Solutions:

  • Issue the currency as colored coins.
  • Make the issuer's last-signed receipt publicly available.
  • What if transaction server and issuer collude to lie about number of units? Make audit data publicly available.
  • How about users privacy? Use homomorphic amounts so that audits can be performed without revealing any account balances or transaction amounts.

Gold-based issuer is forced through coersion to not use certain transaction servers

Solutions:

  • Issue the currency first as colored coins, and let users decide when/whether to upload those coins to voting pools, which allow transaction processing but prevent transaction servers from stealing the coins. This way the issuer has no control over which transaction servers are used, and may not even be aware of their existence. He can no longer be coerced not to use them.