Difference between revisions of "Vulnerabilities"

From Open Transactions
Jump to navigation Jump to search
m (Transaction server might inflate the currency: newline added)
(added note on re-using previous valid instruments.)
Line 37: Line 37:
 
* Bitcoins on the blockchain can be audited by any observer. (This is an advantage that Bitcoin has against physical gold.)<br>
 
* Bitcoins on the blockchain can be audited by any observer. (This is an advantage that Bitcoin has against physical gold.)<br>
 
* 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.)<br>
 
* 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.)<br>
 +
 +
=== 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. All other transactions use this mechanism.  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.

Revision as of 09:13, 17 June 2013

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

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.

Solution: An auditing protocol must be utilized, either by the issuer directly, or by the other members of the voting pool.
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.

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.

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

Solutions:

  • 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. All other transactions use this mechanism. 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.