Architecture

The decision to use a blockchain in Keychain has roots in the experience of the Keychain founders when 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. Banks do not want to license products if they have to entrust their entire operational integrity to one vendor, especially one much smaller than their organization. Blockchain addresses that concern with respect to cryptographic public-key certificates; the global network will be in part operated by the company itself.

Blockchains allow for easy discoverability of public information, which is core to digital self-sovereign identity. They also generally have not just a much higher tamper-resistence than legacy ledgers and databases, but also the agents involved in malicious scenarios have different motives and abilities, all but preventing malicious attacks on blockchains. Think about who controls the database in a company - the DBAs have read/write access and they have disproportionate power to enact change against a company’s will. This makes the database prone to attack via the weak link of a DBA. Contrast with a public blockchain like Bitcoin, where not only can 1 (or even 100) actors accomplish nothing themselves, they also have no reason to collude with one another to attempt to do so in the first place.

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 both 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 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, when 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 many common and critical scenarios (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 process like KYC.

For instance

The pairing step fits into onboarding processes regardless of whether it is lightweight/casual or rigorous. Keychain provides the pairing capability and workflow, but leaves the exact methodology up to the application. Thus it is compatible with legacy trusted authority systems while at the same time allowing for in-person pairing, the strongest form of counter party authentication. Other implementations could opt for an online pairing with a second-factor verification step.

With pairing, the crux is that digital identifiers are not stored online or on a blockchain by Keychain, nor is it required that an application do so. This increases 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.

As written above, we view the blockchain as a pillar of any DID infrastructure, so it is important to give our clients native ability to interface with robust blockchains that work well within their own ecosystem. For some this may be Bitcoin, others may prefer an EVM blockchain.

Keychain wants to power your digital identity infrastructure everywhere you want to be.

To that end, we have taken great care to make sure Keychain Core can be adopted by any development team, target any device, and be deployed easily.

This includes things like