Architecture

The decision to use a blockchain in the first place has roots in experience of the Keychain founders has developing financial trading infrastructure on Wall Street. A common obstacle to getting third-party software adopted by major financial institutions is the concern over vendor lock-in and vendor risk. A bank does not want to license your product if they have to entrust their entire operational integrity to one vendor, much one smaller than their organization. Blockchain serves the purpose of answering that concern with respect cryptographic public-key certificates; the global network will be in part operated by the company itself.

That said, not all data (and certainly not monetary transactions) need to go on the blockchain. In many cases, it simply suffices to exchange digitally signed receipts of an important data set. For that, we use a distributed-ledger protocol to allow clients to exchange data/assets using off-chain Byzantine agreement between only the parties involved in the transaction. This exchange is grounded in the lower level blockchain public-key infrastructure.

As corporate infrastructure becomes more complex, data needs to be protected at rest and in flight even when it traverses multiple network end points. Keychain uses envelope encryption for protecting data to address this.

Whereas in the past, envelope encryption was used primarily on a session or file basis, Keychain encrypts each each batch of data provided by the developer using envelope encryption. The trade off in this decision is that the aggregate size of cipher text increases (dramatically for some usage patterns). In return for this, the developer gets an unparalleled level of freedom of choice in how to manage the data between its source and destination. In a world where the concept of an "outer network perimeter" no longer applies to the typical corporation — and where the cost of network bandwidth and disk space continue to drop — Keychain believes that we have reached a point where this tradeoff is sound.

Keychain allows users to authenticate counter parties through a one-time process called pairing.

Other blockchain-based identity approaches use the blockchain to support authentication and key discovery by storing mappings between public keys and a digital identifier (or references thereto). Examples of such approaches include Namecoin (the first fork of Bitcoin), Blockstack (formerly Onename), Keybase, and others. This practice is well suited to scenarios where the user has no way to authenticate their counter party themselves. For instance, we you buy a book online, you have no way to verify that the website is really Amazon’s except by trusting a certificate authority’s attestation to the fact. The above blockchain systems provide the same functionality based on a more decentralized infrastructure.

However.

In the scenarios targeted by Keychain (such as the exchange of financial position data between a trust bank and a broker), the involved parties do have an opportunity to validate/authenticate their counter parties. In fact, it is part of business as usual in regulated industries such as finance to onboard your counter party through a processes.

The pairing step fits into onboarding processes regardless of whether it is lightweight and casual or rigorous. Pairing in person is the strongest form of counter party authentication. Pairing can also be done online using a second-factor verification step. With pairing, we avoid storing digital identifiers on the blockchain, increasing privacy and compliance with regulations such as GDPR.

Keychain is designed to support multiple blockchain backends. Keychain’s first iteration supports Bitcoin and its variants.