Kaleido Asserted Identities: From Off-chain to On-chain with Trust

Enterprise blockchain applications require a robust identities solution. The requirements around identities come from multiple angles. The on-chain identities, in the form of node keys and user accounts, must be securely linked to the organization that they are associated with. This is critical to verify authenticity and trace accountability in every activity that the network is involved in:

• when a validating node proposes a block, the signature is undeniably linked to the organization that owns the node
• when a validating node votes on a proposed block, the votes cast for or against the proposal is undeniably linked to the organization that owns the node
• when a smart contract gets deployed, endorsements from the network participants in the form of digital signatures can be collected, verified for their authenticity and organization affiliation, and undeniably linked to the organizations giving the endorsement
• when a transaction is submitted, the sender’s identity can be verified for their authenticity and organization affiliation, and undeniably linked to the organization
• When proofs and signatures generated via offline cryptography and key management systems (KMS) are stored on-chain as data, the signer’s identity can be verified

Introducing Kaleido Asserted Identities (KAI). By taking advantage of the Public Key Infrastructure (PKI), that is deeply rooted in proven cryptography and has been in use in practically all enterprises big and small, KAI provides the critical linkage between the off-chain world where there are existing trusted relationships, and the on-chain world. With KAI, blockchain networks can utilize trusted identities anchored in PKI.

Let’s take a closer look at how this is achieved. Kaleido defines a resource called “Identity Proof” (on the Kaleido API it’s called idproofs) which lives under an organization resource. An identity proof is an x.509 certificate chain, starting with a leaf certificate specially generated for the Kaleido organization, such as “Best Beer Company” and ends with a Certificate Authority demonstrating the root of the trust. This certificate chain is the key for a Kaleido user to demonstrate to the rest of the consortium participants that the account belongs to the organization it claims to be part of. On the flip side, any participant of a consortium can inspect the Identity Proof presented by another account, to convince themselves that the account holder can officially represent the organization it claims to be part of, that it’s not a random entity trying to fake the organizational identity.

Let’s use a hypothetical example to demonstrate why this trust system works. We have an honest user Alice from Best Beer Company (BBC), another honest user Bob from Another Beer Company (ABC), and a malicious user Eve from an otherwise honest business Cowboy Bottling Company (CBC). Alice started a consortium and invited ABC and CBC to join by sending them email invitations through Kaleido. While signing up to Kaleido, Eve set the organization name to “Another Beer Company” to deliberately confuse it with Bob’s organization name. If Alice is not careful she could be tricked into thinking Eve’s account represents ABC and assign authorities that should belong to Bob’s account.

The KAI design would make it very difficult for Eve to fool Alice or Bob. When a new organization joins a consortium, the user is given an opportunity to upload the Identity Proof. Alice and Bob would go to their respective IT department and ask for an official x.509 certificate to be issued using the company’s official Certificate Authority. Then they would build a certificate file in PEM format to contain the full certificate chain starting with the newly issued certificate, then the company’s intermediate CA (some companies may not have intermediate CA’s), the company’s root CA, and finally a reputable public CA such as Symantec. The certificate chain will be saved under the Kaleido accounts owned by Alice and Bob to serve as the proof that they each are truly part of the organization they claim to represent.

Bob's Certificate:
 Subject: CN=zzpjx8nwin-pf6j1d3clv--Another Beer Company
 Issuer: CN=Another Beer Company
       |
       | (signed by)
       |
       Intermediate CA:
         Subject: CN=Another Beer Company
         Issuer: CN=Symantec

To summarize the basic principles:

• Kaleido creates a unique proof for the owner of an organization to sign
• The owner signs this, using the well established internet system of trust – Public Key Infrastructure (PKI)
• The PKI trust chain is visible for everyone in the consortium to validate

Can Eve defeat this mechanism? Well let’s think about it. It seems simply presenting a certificate with a proper chain of signers is not sufficient. This is because certificates are public documents that are meant to be downloadable by anyone to view. Eve can simply wait for Alice or Bob to upload theirs, and download it via Kaleido and upload it for her own account. We must have a way to bind the certificate to each account.

This is solved with the well-known technique in the crypto world for preventing replay attacks, of using a “nonce”. It’s a one-time-use value that must be part of the digital signature to ensure possession of the private key. When Kaleido prompts for an Identity Proof, it places a special requirement on the certificate: that it must have the Common Name field set to a special string that starts with envId-nonce, where envId is the Kaleido environment ID, and nonce is uniquely generated for this account’s Identity Proof. With this mechanism, Eve may attempt to upload the certificate chain “borrowed” from Alice or Bob, but because the nonce will not match the one generated for her account, the upload will fail.

As such, Eve’s attempt to steal legitimate certificates would fail. But she is a tenacious hacker so she wouldn’t give up so easily. What if she uses her company’s CA to issue a certificate that meets the requirement on the Common Name? This will certainly allow her to successfully upload the certificate chain as Identity Proof. However, when her membership shows up as part of a Kaleido environment, the other participants namely Alice and Bob can clearly see a certificate chain that does not look right:

Eve's Certificate:
 Subject: CN=zzpjx8nwin-kj351e4ckw--Another Beer Company
 Issuer: CN=Cowboy Bottling Company
       |
       | (signed by)
       |
       Intermediate CA:
         Subject: CN=Cowboy Bottling Company
         Issuer: CN=DigiCert

As seen above, the issuers of the certificate is CBC, but the claimed organization is ABC. This clearly is not a trustable Identity Proof. Alice and Bob can easily detect the problem and decide on the ramifications such as asking Eve to replace with a legitimate certificate or evicting Eve from the consortium.

Blockchain is often dubbed the “internet of trust” because of its emphasis on immutability and accountability with cryptographic techniques. But if such trust is not properly anchored in trusted relationships in the real world, then the whole promise will fall apart. The engineers at Kaleido understands this deeply. With the KAI system, participants in Kaleido-based blockchain networks can operate with confidence. This design is the foundation of the trust relationship in the on-chain world. In a future blog piece, we will introduce how Kaleido’s Identity Registry utilizes KAI to attest to on-chain claims of organizational associations.