Peer-to-Peer Enterprise Blockchain Networking with the Corda Firewall.

Peer-to-Peer Enterprise Blockchain Networking with the Corda Firewall.

We are drawing near our first release of the commercial distribution of the Corda open source blockchain platform. One of the questions we faced when thinking about its production deployments was how to reconcile the peer-to-peer philosophy of blockchain systems with the security arrangements of traditional enterprise networking architectures. This article introduces the Corda firewall — a component that is unique to Corda enterprise architecture which enables corporate Corda nodes to securely operate on public networks with minimal or no changes to security configuration of corporate network firewalls.

Peer-to-Peer Blockchains vs. Enterprise Networking.

Traditional enterprise networks tend to be designed based on the Client-Server model, and following SANS ‘Defence in Depth’ recommendations. This involves creation of several network zones, segregated by firewalls with restrictive rules as to the type and the direction of traffic permitted to flow across. In particular this applies to the internet facing configurations, where only a very limited subset of traffic from the internet is allowed into the internal network, often fortified by Denial of Service (DOS) protection and Intrusion Detection Systems (IDSs). Furthermore, devices on internal networks are usually separated from the internet by routers with Network Address Translation (NAT) functionality, Secure Socket (SOCKS) and other types of proxies, and sometimes also restricted to specific protocols.

By contrast, in any blockchain architecture each node uses point-to-point messaging to communicate with other peer nodes. The somewhat naive default option would be to try to deploy the blockchain node in the Demilitarised Zone (DMZ), with a public IP address. This would resolve the connection issue. However, enterprise-grade blockchain nodes, by definition, process and store highly sensitive information. They also rely on other critical systems for their operation — such as Databases (DBs), Hardware Security Modules (HSMs), and Filesystem (FS) servers. These systems are normally kept highly guarded and deployed internally behind multiple firewalls. Installing a blockchain node in the DMZ directly exposes the node and systems supporting its operation to all the threats on public internet. This violates principles of “defence in depth” approach discussed above.

The alternative would be to deploy blockchain nodes somewhere in the internal segment of the corporate network, e.g. into the mid-tier zone. In this scenario the peer-to-peer nature of node-to-node communication would require every ‘outside’ third-party node in the blockchain network to be able to establish network connection to ‘your’ node through the boundary network firewall (and vice-versa). In TCP/IP terms this would mean that the boundary network firewall would need to allow connectivity on blockchain-specific ports into the internal network from any IP address on the internet. This is likely to be seen as a violation of existing corporate security policies by the CISOs, and thus impede the adoption of blockchain technology in the enterprise.

It appears neither alternative can address the issue and thus enterprise blockchain platforms would seem to be facing an impasse. Most of the current blockchain implementation projects assume direct network connectivity between nodes, this is probably fine for deployments intended to be restricted to a private network infrastructure. However, Corda is built for the vision of the world where anybody can transact seamlessly for any contractual purpose. Blockchain technologies which subscribe to such global vision would necessarily require secure inter-networking capabilities.

In the non-blockchain world the solution for the unrestricted port access required to deliver, for example, a web service is to protect the servers with proactive security systems such as Web Application Firewalls. There was no similar technology available for blockchains — until now!

Corda Firewall

To address these challenges we introduced a firewall component into Corda enterprise architecture that resides within the DMZ, allowing all other components of the node to be relocated into the private environment protected by the traditionally restrictive firewall rules. Corda firewall is designed as a reverse proxy, Figure 1 below depicts its typical deployment within enterprise networking architecture.

While not depicted above, it is assumed that there may also be a SOCKS proxy in the DMZ to support outbound connections.

Corda firewall’s main function is to proxy inbound messages from other third-party nodes to node running behind the DMZ. Its key characteristics are:

• It is not mandatory, i.e. Corda nodes may use, or not use the Corda firewall (e.g. if operating on completely private Corda network); interoperability with older nodes is supported.
• No persisted state data of any kind (no persisted keys, message data, etc), it gets initialised when a node connects to it.
• Designed for high availability (initially via a hot/cold pairing).
• Terminates incoming TLS connection.

All network communications between the Corda enterprise node and the Corda firewall are initiated by the node. In other words, the direction of internal-external connection is from the internal network out into the DMZ, thus there is no need to ‘open’ any additional ingress ports on the network firewall separating the internal and external zones. This means that internal network remains protected from malicious activity from the internet as all internet activity stops at the DMZ boundary. The deployment of a Corda firewall requires ‘open’ network firewall configuration on limited, well defined, egress-initiated ports. This connectivity design also means that there are no restrictions on port map
pings to the Corda enterprise node, and that Corda firewall supports operation through symmetric NAPT routers.

On the ingress side Corda firewall only allows Corda communications from other Corda nodes with valid identity, not any other types of traffic or any other third-parties. Upon initial connection it confirms the network identity using PKI certificates and validates that AMQP packets are well formed. After the protocol break between the DMZ and the trusted zone additional security checks can be applied to ensure that the traffic is not malicious in nature.

Final remarks

Production deployment of blockchain system require many considerations which go beyond the blockchain technology itself. One such consideration is secure network connectivity between nodes in the global blockchain network. Isolated private networks composed of a small number of nodes running Proof-of-Concept blockchain studies could (and evidently do) get by without burdening themselves with this difficult topic. The forthcoming enterprise distribution of Corda has been designed for commercial production use in large-scale inter-organisational networks. Here at R3 we recognised this networking challenge from the start. To enable safe peer-to-peer enteprise networking we created Corda firewall, which not only allows secure operation of Corda nodes from inside the corporate firewall but also provides additional level of security for your blockchain system by validating identity of connecting peers before any messages reach the node.