Difference between revisions of "Vulnerabilities"

From Open Transactions
Jump to navigation Jump to search
m (Transaction server might inflate the currency)
m (Transaction server might inflate the currency)
Line 4: Line 4:
  
 
'''Solution:''' An [[Auditing|auditing protocol]] must be utilized, either by the issuer directly, or by the other members of the voting pool.<br>
 
'''Solution:''' An [[Auditing|auditing protocol]] must be utilized, either by the issuer directly, or by the other members of the voting pool.<br>
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.
+
If the issuer has directly issued the currency onto the transaction server, then he must also conduct the audit.<br>
 +
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 ===
 
=== Vulnerabilities in C++ code ===

Revision as of 09:02, 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

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.)