-
Notifications
You must be signed in to change notification settings - Fork 4
All Tokens contract validation features
Here I want to describe currently discovered Komodo token security risks and validation feature to prevent those risks.
Token is a value that represents real world assets. Tokens are not mined like coins but issued by asset owners and may be transferred or sold to other users.
So what is technically a Komodo blockchain token?
Komodo token is actually value calculated from a number of token utxos. A token utxo has some value and the token eval code (EVAL_TOKENS) cryptocondition in the scriptPubKey. A token is also identified with a tokenid which is the txid of the first token transaction (tokenbase). For every other token tx (that is not tokenbase) the tokenid is stored in the tx opreturn vout. Such opreturn vout is present in every token tx.
Tokenbase tx also has basic token parameters (name, description and issuer pubkey).
Tokens cc contract is reponsible for validation of token tx. This validation is triggered when a token tx, with token eval code in its vins, is added to blockchain.
When a token is created the owner actually converts his normal coins to tokens (with rate 1 satoshi == 1 token).
Tokens may be used with other cc contracts, for this such a contract eval code (for instance, EVAL_ASSETS) is also added to token vouts, which provides that this contract validation is triggered for token tx, too.
With this token architecture there might be several security risks for tokens when attacker might try to cheat or bypass token or other contract's validation code for stealing or adding token value or disrupting tokens in any other way.
The validation code must provide token value balanced, preventing stealing or injecting.
As token cc validation is triggered when tx vin has the token eval code, an attacker might try to create a fake tx with right token vouts and opret, but with no token vins, bypassing the cc token validation. As we do not prevent creation of such txns we should identify and skip them. To identify such txns, we check each tx added to chain and all token txns which this tx is spending (vin tx). This check ensures that this tx and its each token vintx are correct token txns, that is its token value is balanced. This also prevents token value leakage when someone might convert token value to normal coins. Additional info is here 'Fake tokens' problem description
This is actually a token leakage problem. if we can easy find token eval code vins and calculate their value on vin txns, but differentiate cryptocondition vouts are not so easy because they are hashed. So we need a way to select token vouts from other vouts in the same tx. For this, destination pubkeys are added in token opreturn. With this pubkeys the token vouts can be recreated and picked out by Token cc contract validation code. More info is here Token vouts validation in token transactions
Some attack could try to create a token and put a false originator pubkey in its params. Users who trust in token pubkey issuer might get into deceiption. To prevent this Tokens cc contract validation code has 2 checks:
it checks token vouts with the originator pubkey in tokenbase params to pick up only the vouts sent to the token issuer. This allows to follow a common way of selecting token vouts with pubkeys. For example, So this would allow not to select vouts with other eval code as token vouts, should such vouts be added to the creation tx for some reasons by applications.
it also checks tokenbase normal vins that at least some of token value is sent from originator's pubkey normal inputs (it would mean that the originator pubkey really created the tokenbase tx)
Other contracts supposed to use tokens also may be cheated if someone tries to send value to their vouts not from token vins. So it might not actually tokens sent to a contract while it expects tokens. To prevent this, for a validated tx the contract should check its vin with cpTokens->ismyvin() function. If vintx has token vins, it is a correct token because such vin would be validated by Tokens cc contract validation func. But if the contract did not do this it still would not be a big problem because it would not be possible to get value as tokens from these vouts.
Info about token migration and issues related witj this is here Token migration issues