Ethereum Threat Model
This document details the threat model of the Ion Interoperability Framework. The threat model objective is to identify they key assets of the the framework and analyse the precautions required for the robust and secure function of the Ion framework and development of the continuous execution contracts.
Prior to reading this document please take the time to read Ion framework documentation found at the Ion wiki - Ion Stage 2 Architecture and Specification.
The threat model is compromised of 3 sections:
- System overview and model scope
- Threat structure modelling
- Threat model analysis
Section 1 gives a brief overview of the system and defines the scope of the threat model. Section 2 outlines the key assets which require protection and the surfaces through which attacks could be carried out. Finally, section 3 offers analysis of the overall system and assesses the likelihood of any open attack surfaces from being used.
The Ion layer diagram shows the entire ecosystem required to utilise the Ion framework and is presented below.
In its most basic form the Ion interoperability framework consists of a number of interacting systems, the local blockchain, an external blockchain and a set of off-chain components.
Given two blockchains A and B, where chain A is the local chain and chain B the external chain, the Ion hub, block validation module and event consumption contracts are deployed on chain A. Conversely the event emitting contracts are deployed on the external chain B.
A number of off-chain tools are required to generate a number of Patricia trie proofs and perform RLP encoding of blocks. Despite being a requisite part of the Ion ionteroperability framework, as they perform standardised functions that are implemented in a number of languages there is no mandate to use any specific tool. Indeed users are encouraged to develop their own tools that integrate most readily with their workflow.
This threat model will only cover the in-scope components:
- In Scope
- Ion hub contract
- Block validation module interface
- Event trigger and consumption contract interfaces
- Out of Scope
- Turing-complete blockchain
- Block validation module implementation
- Event trigger and consumption contract implementation
- Off chain tools
The scope of the threat model is limited to the core components of the Ion interoperability framework. The Ion hub contract is where the data key to interoperability between separate chains is persisted.
Individual threat analyses should be completed for specific implementations of the block validation modules and event consumption contracts.
Throughout this document it is assumed that block validation modules and continuous execution contracts are implemented correctly. Additionally it is assumed that the consensus of the interoperating blockchains are not corrupted.
The Ion framework sequence diagram shows the basic flow between interfaces during the deployment and execution of generic Ion event consumption contracts.
For a more detailed description of the architecture and logic flow please see the Ion architecture and specification documents. The generic sequence diagram clearly shows the key assets of the Ion framework which are detailed below.
As previously iterated the generic Ion framework threat model does not account for a malicious or incorrect instance of validation contract. Rather we assume that the blocks received by the Ion hub are validated appropriately.
The key part of the Ion framework that allows the verification of external state transitions are the validated blockheaders stored by the hub contract.
Block header data persisted by the Ion hub is located in two mappings:
m_blockhashesm_blockheaders
The first mapping m_blockhashes is a mapping of the blockhash to a boolean which is used to verify whether a block exists within the Ion hub or not. Second mapping m_blockheaders persists the data associated with blocks required to validate proofs submitted to Ion framework contracts - notably the transaction and receipt trie root hashes. These mappings are important as they are the source of truth for the execution Ion framework contracts.
Both block header mappings are only accessible through the function addBlock(). The addBlock() function is a primary attack surface through which the through which an threat agent could attack the integrity of data persisted by the Ion hub contract.
Potential attack vectors through this surface:
- Corruption of persisted blocks
- Submission of valid but coherent block
- Submission of invalid and incoherent block
Detailed here are the methods used to prevent exploitation of listed attack vectors.
As described previously block are persisted within the Ion block storage hub in two separate mappings m_blockhashes and m_blockheaders. Users should not be able to alter the information persisted within these mappings.
In order to prevent this from occuring the only function that accesses the mappings is addBlock(). When submitting a new block via the addBlock() function it is required that the block hash has not been submitted previously. If the statement require(!m_blockhashes[blockhash]) returns true the transaction will fail. This prevents users from performing any changes to existing blocks through this method.
The continuous execution contracts anticipate that any block queried will only be available if it has been validated by an appropriate validation module. Under certain scenarios, such as a fork in a proof of work chain, a block may be created with valid transactions but is not included in the longest chain of the external blockchain. This block would be "coherent" in the sense that it would hash correctly and appear for all intents and purposes valid. A byzantine user could leverage this block to perform a double spend. Alternatively a byzantine user could create an invalid block that had all the same properties as a valid block.
This attack has two variants:
- The block is submitted directly to
addBlock() - The block is submitted via a validation module
In the first scenario a byzantine user would take a block, and submit it directly to the Ion block store hub bypassing the validation module.
This is prevented through requirement that addBlock() can only be executed successfully if msg.sender is a registered validation module - require(m_validation_modules[msg.sender]). This prevents individuals from submitting blocks at will, however it leads directly to the second variant.
In the second variant of submission of invalid coherent blocks via a registered validation contract. This attack could be performed by registration of a malicious validation module. This attack is not preventable, however blocks stored by the Ion contract should in future be sorted by the validation module address which would segregate blocks so users could specifically request blocks that have been validated by a module they trust.
Users would be able to trust validation module that have been published by developers by compiling the published code and verifying the bytecode matches that persisted on the blockchain.
A byzantine user could attempt to submit a modified block that was by block hash contained on the external blockchain but have edited the contents with fraudulent transactions. This should be prevented by the implementation of the validation contract, however to ensure this the Ion block store contract requires that all blocks submitted via the addBlock() function are submitted as RLP encoded byte arrays which are then hashed to ensure data is coherent. If the blockhash is not identical to that supplied by the validation module the transaction fails.
Threat agents are actors who act maliciously within the system. Three threat agents are detailed below:
- Block validation developers
- Ion framework contract developers
- Byzantine actors
The Ion framework depends on the assumption that blocks submitted to Ion via a validation contract are valid - where valid implies they form part of the blockchain being interoperated with. As the Ion framework is agnostic to the consensus mechanism being used the validation module can be implemented in many different ways it is assumed that validation modules are implemented to a standard that users are happy to accept for their requirements.
Malicious implementation of validation modules by developers is a likely attack surface through which the Ion framework could be corrupted. There is by design no restriction on who can develop and register a new validation module with the Ion block storage hub. This means there is no way to prevent somebody creating their own module which accepts any block.
In order to ensure that validation module developers cannot behave maliciously users should be recommended only to use published modules. The users could then compile the published contract and verify the bytecode produced was identical to that stored on the blockchain on which the module was deployed.
Finally blocks would be stored in a mapping with the address of the deployed validation modules allowing users to specify blocks from validation modules they have audited.
To enable the execution of business logic across two separate blockchains continuous execution contracts need to be developed. These should be developed in pairs as the emission and consumption of events are required to follow the same format.
Developers could act maliciously and create contracts that do not behave as described. This could vary from completely bypassing the Ion hub block store or knowingly referencing invalid blocks.
Specific implementations of the continuous execution contracts should receive their own threat model and analysis.
To allow users to ensure that the users are able to understand the contract with which they are interacting comtinuous execution contracts should be published by developers to audit that the code deployed at the given address is as described.
As blockchain are inherently open platforms they are vunerable to attack by outside actors. Byzantine actors are those trying to use the contracts to their advantage.
In the previous sections a number of threats, attack surfaces and threat agents were identified. Additionally potential security controls were proposed.
- Submission of a block via a malicious implementation of validation module
- Execution of a transaction through malicious implementation of continuous execution contract
Though the threat model of specific implementation of the block validation module is out of scope, the most likely attack to leverage against the Ion interoperability framework comes from a malicious validation module that is registered with Ion. This malicious validation module would be able to add coherent but invalid blocks to the block store.
Impact of the corruption of the block store would be significant as many users could be affected by such an attack.
In order to prevent this we suggest using a registry of validation module, with the implementation open for all to see, allowing users to verify the validation module is implemented as described. Then blocks would be sorted by the address of the validation module. Users would then be able to ensure they were using a module which they felt was implemented to a standard that fits their requirements. However it is not possible to prevent malicious validation modules from being registered without restricting ability to registed modules.
Continuous execution contracts should implement the required interfaces to properly query the Ion block store. However as previously iterated developers are not prevented from implementing malicious contracts.
In comparison to the submission of invalid blocks the impact of malicious implementations of continuous execution contracts would be limited to only the counterparties involved in their execution.
Preventing users from interacting with contracts that do not behave as described should be implemented through an open registry of continuous execution contracts. Users would then be able to verify that the bytecode stored matched that of the compiled solidity code.
A threat model for the generic Ion interoperability framework has been given, showing that agnostic of specific implementation of the validation module and continuous execution contracts the framework is able to perform cross-chain interoperability. Additionally a number of recommendations are made to prevent honest users from being exploited by byzantine users when using the Ion framework.
| Definition | |
|---|---|
| Asset | Property or artifact that requires protection |
| Security Control | A mechanism to protect an asset |
| Threat Agent | Actor that wishes to attack an asset |
| Attack Surface | Mechanism by which a threat agent attacks an asset |
| Threat | The threat definition or outcome |
| Likelihood | Ease of attack, easy to perform is more likely, harder to perform is less likely |
| Impact | Consequences of a successful attack |
| Mitigation | Risk management of attacks |