Interchain Accounts Architecture Review

[andrey-kuprianov]

Surfaced from @informalsystems audit of ICS27 InterchainAccounts at hash 01560bd

Interchain Accounts (ICA), as defined by ICS-27 specification and implementation, is a Cosmos module that allows a controller chain to open an interchain account on the host chain, and to submit transactions from the controller chain to be executed on the host chain on the behalf of the created interchain account. In this document we describe the implicit assumptions on which the the ICA module rests, as well as raise some important concerns to be discussed and addressed.

Among the main requirements for ICA the following can be listed:

• Exactly once execution of ICA transactions
• Ordered execution of ICA transactions
• Correctness: a transaction executed on the host chain should have been submitted before on the controller chain
• Isolation: Any two distinct pairs of ICA controller and host should not influence each others operation

Notation

❗   Important concerns
⚠️   Implicit assumption
📖   Data relationships
🛡️   Access control

Usage

There are two main user flows for ICA: registering an interchain account, and sending an interchain transaction, as depicted on the pictures below.

⚠️ Interchain Accounts module can be used only via the not yet existing Authentication module, which will be responsible for controlling access to ICA, and providing customer use cases. Insofar ICA provides two entry points (InitIniterchainAccout and TrySendTx)that are not exposed to the user; the ICA module is thus not yet usable in its current form.

❗ The requirements and the API between the authentication and the ICA modules are not clearly specified. It is only mentioned that ICA employs ICS-30 Middleware to notify the Authentication module about success or failure of the submitted interchain transactions. The ordering guarantees wrt. submitted transactions in case of channel closing/reopening are not clear.

 

In the registering flow, a user initiates the process via Authentication module (1.), the latter calls InitIniterchainAccout function from ICA module (2.), the ICA modules on the controller and the host chains establish a new channel (3.), and the ICA host module creates an interchain account (4.). The created interchain account is returned to the user during the channel establishment mechanism and via the authentication module; this process (5.) is depicted as a single step in the diagram for simplicity. The dotted parts of the diagram are nit yet implemented in the current version.

 

In the sending flow, a user submits an interchain transaction to the authentication module (1.), which transmits it to the ICA module using TrySendTx function (2.), the transaction is forwarded from the controller to the host chain (3.), the interchain account associated with the controller-host channel is retrieved (4.), and the transaction is executed on the behalf of the retrieved interchain account (5.).

Chains

Any given chain can act both as a host and as a controller in multiple ICA relationships.

❗ This is important to keep in mind, in order not to mix the controller and host roles (and data!). E.g., before Splitting ICA into controller/host submodules it was possible for a controller-host relationship between chains A and B to influence the controller-host relationship between chains B and C.

Connections

Connection semantics is specified in ICS-03. To establish an ICA relationship, there should be an IBC connection between the controller and the host chains.

⚠️ Connections between ICA chains should never close. Nowhere written, but very important; see more on that in the section on ports and clients.

❗ Closing is not envisaged for IBC connections. Nevertheless, a connection may become unusable, in case of the associated LightClient expires. See more on this in the section on clients.

❗ There can be multiple connections between any two pair of chains. Care should be taken to ensure that user-level semantics of executing transactions (in particular ordering) is maintained when multiple connections exist between a controller and a host chain.

Ports

Ports are unique identifiers, that are used to create channels for packet transfers between IBC chains. Port allocation procedure is described in ICS-05.

• ICA module acting as a host binds to the port interchain-account
• ICA module acting as controller binds to the port ics27-1.{controller-connection-id}.{host-connection-id}.{owner-account-address} (we call this format PortID below).

❗ It should be noted that according to ICS-05 the ports are allocated at a first-come-first-serve basis, which opens the theoretical possibility of DOS attacks, when some other module binds a port that ICA intends to use.

⚠️ The current approach to deal with the above issue is to assume all Cosmos modules on a chain are trustworthy.

📖 PortID is used as a key in mappings:

• On the controller side:
  • to retrieve the active channel
• On the host side:
  • to retrieve the active channel
  • to retrieve the associated interchain account

🛡️ PortID is checked both by ICA controller and host when establishing the new ICA channel: connection ids in the PortID should match connection ids of the actual connection used.

🛡️ PortID is used by ICA host when executing a transaction from the controller chain: there should be an interchain account associated with the port from which the packet comes.

⚠️ The assumption of never-closing connections plays a very important role: if some connection becomes unusable, the corresponding PortID becomes invalid, and, thus, corresponding interchain account becomes inaccessible.

Channels

Channel semantics is defined in ICS-04. A separate ordered ICA channel between a controller and a host chain is established for each Interchain account upon its creation. The channel serves the two purposes:

• to transmit ICA packets from controller to host chain; the packets contain transactions to be executed on the host chain.
• as a control mechanism, pre-conditioning certain actions. E.g. an attempt to create an interchain account for the second time will be rejected, because an active channel already exists for the particular owner, and thus a port id.

❗ ICA channel may be closed. There are two possibilities, as outlined in ICS-04:

• a separate closing handshake can be undertaken by any of the modules owning one of channel ends.
• if any packet times out, this will close the ordered channel (and ICA channels are ordered).

❗ A channel may also become not closed, but unusable, in case of the associated LightClient expires. See more on this in the section on clients.

Packets

Packet semantics is defined in ICS-04. Packets are used to transmit ICA transactions from the controller to the host chain. A controller chain should specify the interchain account as a signer for the transmitted transactions.

🛡️ ICA host checks that all submitted transactions have the interchain account associated with the PortID over which the transaction is received as the transaction signer. In case of controller chain misbehavior this should limit the possible damage to the created interchain account.

❗ The precise semantics of executing transactions on the host chain is not completely clear. In particular, a transaction is submitted to the message router/handler of the ICA module. While the above check does take place, care should be exercised to prevent executing a transaction on behalf of the ICA module, and not on behalf of the interchain account, as intended.

❗ No actual signing with a private key takes place for an ICA transaction. As discussed with the ICA developers, transactions received from controller chains are considered signed "programmatically", i.e. it is trusted that the signer of the transaction is what it is claimed for; the actual authentication is provided via the IBC semantics and protocols. Still, it is not completely clear that the absence of actual signing with the private key can't be abused when receiving transactions from a foreign chain.

❗ When submitting an ICA packet, its timeout is set to maximum uint64. This effectively prevents a packet from timing out, and the ordered channel from being ordered because of that. We have raised the issue of whether this timeout could be lowered, as a packet which is not being either relayed or timed out doesn't give the application using ICA any chance to react. After a discussion with ICA developers we are convinced that in the current version of ICA it is indeed better to use the maximum timeout, to avoid closing ICA channels, as channel closing/reopening poses a number of other risks:

• unclear how the application logic should react on timed out packets
• application-level ordering requirement can easily become violated in case of some packets timeout, but later packets go over another channel.

The correct solution, as discussed with the ICA developers, seems to be the introduction into IBC of a channel type that can never be closed, similar to IBC connections.

Clients

IBC client semantics is defined in ICS-02. Neither ICA specification nor implementation mentions clients. Clients provide the major mechanism for the verification of the state updated on a foreign blockchain.

⚠️ It is implicitly assumed that the LightClient with which ICA connections and channels are associated never stops functioning.

❗ What's important for ICA is that a client can "expire", i.e. if it is not updated for the duration of a trusting period it can't be updated any further. In that case all connections and channels associated with the client become unusable. The situation can be repaired only via a special governance proposal. While an unlikely scenario, we have observed this happening on real chains. We recommend ICA developers to consider this possibility explicitly, and to envisage mitigation mechanisms.

Conclusion

In the course of evaluating ICA specification and implementation we have found the implementation to be well-structured and of a good code quality. To the best of our judgment, we have found that the ICA implementation does enforce the desired requirements.

For the future evolution of ICA we recommend to make explicit the listed ⚠️ implicit assumptions, and to discuss/address the ❗ important concerns raised above. At the present time, none of them seem to pose a significant security risk, especially because the ICA functionality is not exposed to the users until the introduction of the ICA Authentication module.

In the next stages of ICA development, besides addressing ⚠️ and ❗ issues, we recommend the following:

• In the ICA specification focus more on the abstract presentation of what the module is supposed to do, not on how it is done.
• Specify explicitly the requirements from the point of view of an ICA user, and how the interaction of the ICA module with the ICA Authentication module guarantee those. There should be a clear specification of the ICA/ICA Auth API and the requirements it should satisfy.
• Current tests focus exclusively on the case of two chains (controller and host). It is definitely not enough to guarantee the isolation requirement: different combinations of at least three chains should be tested (like controller 1 - host - controller 2).
• To avoid specifying a multitude of test scenarios manually, we recommend to apply model-based testing, which should be able to cover exhaustively a certain space of combinations of various chains, their parameters, and action sequences.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned