Highlights

Consortia are implementing workarounds to provide the perimeter security

Currently Corda Network’s governance is dominated by European companies

A hot topic in enterprise blockchain is interoperability between consortia. One example is insurance and trade finance consortia which need to interact both with each other as well as the trade networks where they provide services. As these networks interoperate, they start to resemble semi-public blockchain networks, with a layer of Know Your Customer (KYC) at the entrance.

While this level of integration offers enormous opportunity, we found there are challenges relating to security and governance. We spoke to the CTOs of three major consortia, HQLAX, the Letter of Credit Blockchain, and RiskStream. There’s an area where we found enterprise security teams are resistant to the modern solutions offered by R3’s enterprise blockchain Corda.

For those unfamiliar with the consortia, HQLAX has a joint venture with Deutsche Börse for collateral optimization. The Letter of Credit blockchain (formerly named Voltron) has eight global bank members including HSBC and Standard Chartered. And RiskStream (formerly RiskBlock) has almost 50 major insurer participants.

James Carlyle, R3’s Chief Information Officer, compares the Corda Network to the internet. Soon he expects its existence to fade into the background much like we take the internet for granted. We agree. Despite the issues explored, it’s worth recognizing that these are merely teething problems which probably won’t be remembered in a year.

“We think of the Corda Network as an internet of Corda nodes. But of course, there are sufficient safeguards in place to ensure that all of the traffic on top of it is appropriately encrypted,” said Carlyle.

Although encryption is critical, that’s not the sole concern for R3’s clients.

The interoperability challenges

With the Corda Network’s map of servers, it’s possible to piece together which firms are part of various consortia and applications.

To address this in the early stages of a project, R3 created the concept of a Corda Network SubZone, where only the consortia participants can see each other. It’s a half-way house between an entirely private network and the full Corda Network, with a path to migration.

Nonetheless, the real interoperability benefits come when the consortia are on the main Corda Network.

Visibility is perhaps the lesser concern, the bigger challenge relates to access. Large enterprises have traditional ways of restricting access by third parties, whereas the Corda Firewall approach is more modern and similar to Google’s methodology. As a result, the consortia are independently implementing workarounds to get closer to the traditional approach. This is explored below.

A second issue is that the Corda Network is currently both technically and governance wise very European centric. That’s likely because for now the majority of Corda members are based in Europe. We believe the Euro-centricity of the Corda Network is something that will quickly change, but currently, there are both appearance and practical issues.

However, the biggest issue by far relates to access.

Gatekeepers and access solutions

In some ways, the Corda Network is not dissimilar to a country club which might have different groups such as golfers and tennis club members who usually stick to separate areas but might share a clubhouse.

There are different ways you could control access to a country club. For example, members might have an entrance pass which they need to show to gain access. Alternatively, the security guard at the gate could ask for your ID and check it against a list of names.

In the internet world, one of the oldest identifiers is the IP address of a server.

The Corda Network uses cryptographic certificates which is similar to having an entry pass which is checked by the Corda Firewall. And historically, major enterprises use IP whitelists for allowing network access. Based on feedback, it seems the current desired solution is to have both.

So it’s like country club members having an entry pass, but there’s additionally a check against a whitelist when the golfers want to play on the tennis courts.

Referring to whitelists, R3’s Carlyle commented: “it’s a conservative approach by some banks and some security teams within banks because their primary goal is to protect customers’ assets. I think it’s also fair to say that they don’t always do it for applications. They don’t do it for email servers, for example.”

However, he continued: “I think probably it’s still the minority that are thinking of doing it.”

We spoke to the CTOs of three consortia on three continents, and all of them said their members required whitelists.

CTOs are in agreement

“Banks are much more comfortable with whitelisting for fairly obvious reasons. It gives you sort of an immediate protection,” said HQLAX‘s CTO Raoul Bhoedjang. “But it’s not a complete solution.”

“There is the Corda firewall [using cryptographic certificates] which aims to address that. But it’s fully internet exposed, so you need to get very comfortable with that.”

RiskStream’s CTO Patrick Millar looked at it from the perspective of the chief information security officer (CISO) at a large enterprise assessing a new technology which is not yet widely deployed: “Why should we open up our firewall to you? Look at the huge, potentially multibillion-dollar damage that could get done if this proved to be a weakness in our security.”

Despite the requirement for IP whitelists, the CTOs are quite skeptical about them initially. CryptoBLK is the technology partner for the Letter of Credit blockchain (formerly Voltron). Andrew Hon, CryptoBLK’s Founder & CTO, said: “If we use IP whitelisting it kind of limits the power of this DLT application.”

RiskStream’s Millar concurred. He points to modern solutions such as Google’s BeyondCorp zero-trust network approach which flips the security model to enforce access controls at the user and device level as opposed to the network’s perimeter. IP whitelisting is very much about securing the perimeter, whereas Corda’s Firewall uses the Google approach. Referring to the whitelists, Millar said: “It puts this layer of rigidity over the top of what should be a very flexible network.” He went as far as referring to IP whitelisting as “last generation security.”

And HQLAX‘s Bhoedjang was blunt about managing whitelists: “It’s very tedious and error-prone.”

The question is whether it’s practical at all to have the whitelists. “It’s not a big deal if you only have three or four participants on a network that uses point-to-point communications, but it is a big deal if you have 10, 20, 30 or more, because then you’re dealing with hundreds of updates across the network because it’s what they call an N squared problem,” said RiskStream’s Millar. Again, all the CTO’s agreed that it’s a more significant challenge as the networks expand.

Hence, the alliances are exploring potential workarounds.

Finding a middle ground

Consortia have what’s referred to as a Business Network Operator (BNO) node. That server was mentioned as potentially having a role in the solution by two of the CTO’s in different ways. “The BNO will provide IP information and dynamically generate a special file for the participants to download and interact with their (conventional) firewall to provide IP whitelisting on the fly,” said CryptoBLK’s Hon, referring to a methodology they plan to test.

This solution is one kind of middle ground. HQLAX are also considering using the BNO but potentially leveraging X500 addresses rather than IP addresses. “It’s not as conservative as IP-based blocking, but it gives you a kind of base defense, and you can do it outside of your application which is nice,” said the HQLAX CTO.

And the IP address whitelisting may only be an interim requirement. “Once the design used by Corda is better appreciated, then the IP whitelist constraint will be relaxed by the member companies,” said RiskStream’s Millar. R3’s Carlyle also suspects that firms will “become more pragmatic as the networks grow and the effectiveness of Corda Firewall becomes apparent.”

The issue raises an interesting consortium governance conundrum. What if some participants are comfortable without IP whitelisting or being on the Corda Network, and others are not? CryptoBLK’s Hon said in their case all the banks had to agree. They spent considerable time explaining the issues, and it took several weeks for all eight banks to agree to join the Corda Network.

HQLAX has also chosen to be part of the Corda Network. But RiskStream members have not yet agreed to join, although a decision will be made soon.

And for U.S. based RiskStream and Hong Kong-based CryptBLK there are additional geographic issues which both mentioned without prompting.

The Euro-centricity of the Corda Network

The Corda Network has a governance board which comprises nine members plus two seats for R3. Eight of the initial nine board members represent European companies with the ninth from Japan’s SMBC. None are from North America.

A second more practical issue is that all the Corda Network notary servers are currently based in Europe, which potentially could result in performance (latency or delay) issues, although CryptoBLK said that tests from Asia were acceptable.

While these appear to be two separate issues, they are not. The board mainly has oversight over technical issues, but without a board representative, who will lobby for a North American notary node? That said, it sounds as if R3 would add a U.S. notary if customers asked for it, given they plan to set up an Asian node based on client requests.

R3’s Carlyle pointed to a well-considered governance model mapped out for the Corda Network. Firstly, the current board is a transition board. Future boards will be elected from this coming April. “We couldn’t have a meaningful election with a tiny electorate,” explained Carlyle. So the transition board was selected based on “three directors nominated by the first three substantial business networks that are in preproduction testing or production.”

The three board represented networks are insurance consortium B3i, and trade finance networks Marco Polo and the Letter of Credit Blockchain. An outsider observation that struck us when the board was announced: this is both of the main trade finance networks, but only one of the two major insurance networks. We initially thought this was a faux pas. However, RiskStream has not yet committed to the Corda Network. Hence its members could not be considered for the board.

So the selection is based on the transition board criteria. But it’s optically awkward, especially when combined with a lack of other U.S. board members and no U.S. notary node.

However, R3’s Carlyle rightly pointed out that this is an interim issue with the transition board. “We think we’ve got diversity covered in the steady-state,” he said. Future boards won’t have more than three directors from one industry, a maximum of three representatives from a continent, and only three from very large organizations. Carlyle also said the governance could be changed based on what is learned.

But we won’t be surprised if the governance continues to be tricky, because it’s hard to keep everyone happy. For example, the degree of diversity envisaged might clash with the make up of the members who actively and heavily use the Corda Network.

Stepping back, it’s important to recognize that the CTOs are all keen on the Corda Network and the interoperability benefits that it brings.

RiskStream’s Millar commented: “kudos to R3 for being very responsive and working with us very closely to get everything resolved as it comes up.” Another sentiment expressed by all three CTOs.