CORDA Security Enhancement Series: Improving Security & Flexibility on a Private Corda Node with Layer 3 Governance

How Corda Networks Operate - Overview

Corda networks are peer to peer, private networks for distributed ledger business transactions. These networks are accessible by deploying one’s own Corda node with an X509 certificate signed by a Corda network operator. With the signed certificate, one can propose and sign transactions with any party that is also a member of the same Corda network, subject to the business rules of the network governing the particular transaction (e.g. Consensus protocol for transaction, Smart Contract terms, compliance with Notary ratification/validation, etc.. As the network is non-gossipy, one does not see or store everyone else’s transactions, but does receive all transactions where it is an involved party.

Challenges with Corda / Peer-to-Peer Networks

When deploying a technology like Corda (where peer-to-peer communication is a core component), one may be concerned about what external parties will be calling in to one’s node. This concern could be due to technical reasons, such as vulnerabilities in the TLS implementation; or social reasons, such as trustworthiness of other parties in the network.

With Corda being non-gossipy, one does not need to be able to communicate with all nodes/ IP addresses on the Corda network; only the nodes of the business entities that: a) one is authorized to transact with, per the business and network rules, b) one wants to transact with, and c) Corda core services such as Notaries, network maps, Oracles, etc....

Corda nodes are deployed on the Internet with publicly exposed AMQP endpoints. This protocol offers outstanding accessibility to a world of entities with whom to do transactions: anyone that is a member of the same compatibility zone. However, one may not be interested or forbidden from doing business with some members of the compatibility zone due to governance rules, OFAC, network compliance/business rules, etc...

Subzones - Limiting Connections in Your Own Network

To mitigate what could be considered a risk, some organizations join smaller Corda networks, subzones, or segregated networks on the public Corda network (tCN). One is able to limit whom one is able to do transactions with by joining a segregated network, or subzone. The issue with these is that one is not able to execute transactions with those outside of the segregated network. These can have benefits including defining compatibility, consensus, and membership requirements. There are also limiting factors: 1) First and foremost, one can only perform transactions (and specific transaction types) with other specifically approved parties in the segregated network, and 2) in order to execute transactions not on the same segregated network, one may have to move to a new network, or convince the other party to move to your network.

Transferring Between Subzones

In order for this move to occur, one may need to have all transactions signed a second time by a notary.
Impact of Notary/Notarizations for a Node TRANSFERRING Networks

  • Impact 1 (BIGGEST/SLOWEST) - Originating Network and Target Network both have Notaries
    If the originating network and the target network both have notaries, then a reconciliation will need to be done to bring the transactions to the new network (the Notarized transactions will have to be validated, reconciled, and re-notarized by the Target network Notary).

  • Impact 2 (MODERATE) - Target Network Has a Notary
    If the original network does not notarize transactions, but the destination network does, then transactions will need to be validated per the Notary rules on the Target network;

  • Impact 3 (MINIMAL) - Target Network Does Not Have a Notary
    If the target network does not have a notary, then no additional validation or reconciliation will need to occur.

Recommended Security Approach - Layer 3 Governance1

In an effort to maintain a balance between flexibility, utility, and security by allowing an established Corda node o have access to the most diverse transaction partners, and prevent having to move between public Corda networks while controlling how public the peer-to-peer interface is exposed, we are proposing a layered security approach, beginning with Layer 3 Governance. By utilizing the Corda network map service as the starting point for building an IP address whitelist of endpoints that the business entity is approved to have Corda transactions with, our Layer 3 governance approach provides more granular and extensible access to specific parties outside of a SubZone that a Corda node can interact with (while by default, refusing all other connection attempts or inquiries). This approach gives the business approval authority over who to engage in a transaction with, with the end result being a subset of IP addresses from the network map service as an allow list for a firewall rule set between the Internet and the business entity’s Corda node.

Managing the Corda Network Map

Corda provides a network map service API that nodes use to find each other. This is a directory service where a node can send a signed record of its name, IP address(es) and port. Nodes can request the entire list of nodes in the compatibility zone (network), or a specific node by X500 name. The network map service will occasionally trim the list of nodes that no longer exist.

A Corda node will use this network map to set up a TLS protected AMQP connection to another node to send a transaction proposal.

Introducing and Implementing an IP Whitelist

IP whitelists allow approved and specific types of traffic from IP addresses identified outside the corporate firewall to a service with an associated IP address. Typically, IP whitelists require coordination with networking and/or security teams on both sides when setting up a new service. This results in IP whitelists that are very small, static, and brittle. The risk with these hand coded whitelists is that if either party moves the service to a different IP, the service will be disrupted. If there are not sufficient change control processes, the whitelist rule could be removed, also breaking the service.

With Corda, there is a unique opportunity to have a robust and dynamic IP whitelist protecting a service. The network map, while built as a directory of where to connect with other Corda nodes, it is also a list of where to expect connections from for one’s own Corda node. If a node is not a member of the network, it will not have an entry in the network map, as it will not be able to sign a record with an approved certificate chain. One can set up a firewall policy to allow connections only from this list. This whitelist should be generated in an automated way to reduce the risk of errors in creation.


Layer 3 Governance

The IP whitelist generated from the network map can be reduced further if desired. If one wants to do transactions with parties only in the US, one can filter by X500 name to only parties in the US. If one wants to do transactions with a smaller approved list of parties, then filter the list down to only their X500 names.

Regardless of how the list is filtered, deployment of the IP whitelist should be done automatically. The whitelist will need to adapt as IP addresses change from nodes being added and removed from the network. This automation prevents the brittleness that hand coded IP whitelists demonstrate.

In the case that a Corda node changes IP addresses, and a transaction proposal is blocked because the whitelist has not refreshed, the sender will continue to retry sending the transaction, resulting in no lost messages.

In conclusion, with the network map and an automated whitelist, one is able to achieve layer 3 governance of the parties one does transactions with in a robust way. We will be updating the Corda Security Enhancement Series regularly. We are excited about the opportunities with Corda, and will be sharing them with the community.2

1. Our proposal of using an IP whitelist for governance is a broad stroke governance solution. Alternatively, one can allow all IP traffic and then be selective about what X500 names one allows transactions from.

2. Some corner cases we are considering blogging about: 1) Two nodes have the same IP address and same port. Who to trust? 2) Two nodes have the same IP address and different port, do you add port filtering?