Skip to content
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
56 lines (39 sloc) 13.6 KB

Recommendations for Decentralized Key Management Systems

by Michael Lodder

Evernym, Inc.


A decentralized key management system (DKMS) aims to solve how consumers can manage their own keys and certificates without relying on a third-party provider having access or controls over the keys.. This method helps to ensure that no third-party can compromise the integrity and security of the system as a whole. Entities can use the system to safely authenticate each other and validate keys and certificates. Centralized key management systems (CKMS) manage key and certificate creation, signing, and validity. Specific problems arise when these authorities become unavailable, or the data they control becomes corrupted or known. Central authorities often become choice targets for attackers. This document proposes to meet these requirements with a decentralized blockchain ledger for providing an oracle of trust and leave control over all keys with end users. The use of a blockchain permits globally readable identifiers and public data to be shared in a secure manner that is not vulnerable to the man-in-the-middle attack or system wide compromise and permits consumers to be self-sovereign. This leaves consumers with the task of key management and protection. This document covers various ideas for how users may create, recover, backup, and revoke keys and provides recommended suggestions.

1 Introduction

In a typical centralized key management system, a third-party such as a certificate authority, kerberos, or enterprise deployment will maintain control over users keys and certificates. Systems will create keys on user's behalf, protect them from unauthorized use, rotate them as specified by best industry standards, and revoke them in the event of compromise. This simplifies the experience for users by abstracting away key management altogether. Security administrators like this setup as it leaves the difficulty with them. System administrators will typically harden the systems to prevent unauthorized access. Negatively this setup simplifies the target to one location for attackers. Also users may not have any degree of control over their keys and certificates. Instead they must notify their administrators if they suspect compromise or lose their secrets. Personal identifiable information (PII) is usually stored alongside these keys which makes the central authority even more valuable to attackers.

Key management can be a difficult task as it requires knowing what types to use, which crypto systems are more secure, how often they should be changed, how to distribute them to others in a secure manner, how to indicate which of them are no longer trusted, how to recover if they are lost or stolen, and how to protect them. Privacy is also a major concern as any information that can be correlated to them can potentially be used against them. DKMS should preserve privacy, allow endpoints to manage their own secrets, and provide a method for establishing trust for distributing public information in a secure manner. Endpoints can be implemented in the form of decentralized identifiers (DIDs) and any keys used by that DID in DID description objects (DDOs) which provide anonymity for identities and their keys. A DID is a globally unique identifier that is generated cryptographically and self-registered with the identity owner’s choice of a DID-compatible distributed ledger so it requires no central registration authority. Each DID points a DDO, a JSON-LD object containing the associated public key(s) and a pointer to off-ledger agent(s) supporting peer-to-peer interactions with the identity owner. From this baseline, trust between DID-identified peers can be built up in two ways:

  1. Challenge/response messages for real-time verification of public keys.
  2. Exchange of verifiable claims—claims about identity attributes that include digital signatures or other cryptographic proofs from other DID-identified trusted peers whose public keys or proofs can also be verified against the ledger. This decentralized web of trust model leverages the security, immutability, and resiliency properties of distributed ledgers to provide highly scalable key distribution, verification, and recovery, finally making PKI accessible to everyone. However, because it does not depend on any centralized authorities, it also shifts some measure of responsibility for key management directly to each participating identity owner. This demands the decentralized equivalent of the centralized cryptographic key management systems (CKMS) that are the current best practice in most enterprises.

2 Keys

The DKMS architecture proposed here addresses the following points: what keys might be needed and their purpose, where they should be stored and protected, how to recover from loss or compromise, rotate them as needed, and revoke when the key is no longer needed or becomes publicly known. Keys may distributed to other entities but must remain in control by their owners.

2.1 Key Types

Every key should have a specific purpose. The ledger must prove that any changes made to data are only made by those that have been authorized. All unauthorized requests must be ignored or flagged by the system. If anyone else can change the data, the security of the system is compromised. This paper recommends owners use a master private key to authenticate their actions. The master private key thus represents the owner’s identity. To limit master private key exposure, subkeys should be used for all other purposes like securing storage, communication, and delegation. Delegation could be for devices, people, or software used by the owner. If a device is detected to be unauthorized, then actions and messages received from that device can safely be ignored or flagged by systems and the owner can be notified.

2.2 Key Derivation and Safeguarding

As keys are created and used they should be stored based on frequency of use and sensitivity. Keys used more often should carry less risk if lost, require little effort to access, fast to retrieve, and should be used for more specific purposes. An example of a such a key is one used for communicating with a specific endpoint multiple times per day. If this key becomes known, only the channel is compromised until the existing key is replaced. Owners can use a file encrypted by a hardware key, an encrypted wallet like KeePass, an encrypted database like SQLCipher, or operating system keystores. Keys used less often are more sensitive and carry more risk if lost, should require more effort to access, possibly longer retrieve times, and be used for more general purposes. These are called rare keys. A rare key is like the master private key used for authenticating owner actions. If discovered by anyone other than the owner, the consequences are very severe like loss of control over their identity. Rare keys should be stored somewhere that requires secure interactions to access and potentially slower retrieval times. Owners should be able to choose where to store their keys. Physically uncloneable functions (PUF) are a key protection where keys are instead derived from unique physical properties of a system and exist only when powered up. That is, rather than securely storing the private key, the same key can be regenerated over and over again (for the lifetime of the device) on demand. Using an SRAM-based PUF, these are guaranteed to be unique since they utilize the inherent randomness in silicon bit patterns. More common key protections use secure hardware like an HSM, TPM, secure element, smart cards, or a TEE. Another method is to split the key into pieces that are distributed to trusted custodians. After its intended use a rare key should immediately be forgotten.

2.3 Key Recovery

There multiple methods for creating and managing keys. Depending on the method used affects how to recover keys. Key derivation functions (KDF), pseudo random number generators (PRNG), and Bitcoin’s BIP0032 are all examples of key creation using a seed value with a derivation function. Standard tools typically use a random seed that is by a PRNG to create a key. If all keys are created from a single seed then only the seed may need to be safeguarded as every other key can be recreated if necessary. This method simplifies recovery as only one value would be necessary to begin. The master private key should be used for this purpose. If KDFs or PRNGs are used, a passphrase, biometric input, or social data from multiple users combined with random salt should be used as the input to create the seed. Alternately a QR code or words from a list such as the PGP word list can be used. In either case, the input must not be stored anywhere connected to the Internet. Most users will opt for something online because of the ease of use. It is recommended to split the keys into pieces and distribute them to trusted custodians chosen by the owner. When recovery is needed, custodians can be contacted and the key is recovered once enough pieces have been received. Shamir Secret Sharing could be used to generate the pieces and recombine them or secure multiparty computation.

2.4 Key Revocation

A crucial requirement for all key systems is that keys can be revoked. There must be a revocation solution for verifiers to check which keys should no longer be trusted and allowing owners to list their revoked keys. It is not good enough to simply forget a key because it cannot be known if the key has been compromised. To prevent these from exploding in size and slowing over time, a cryptographic accumulator may be used for verifying non-inclusion. Accumulators allow for quick checks of non-inclusion and updates. Accumulator updates are only needed when keys are revoked and not when they are created. Control over who can update the lists must be enforced so no one but the owner can revoke keys. Existing solutions do not always allow owners to control their keys in this way.

2.5 Key Rotation

Keys should be changed as often as possible to limit tampering. As much as possible keys should have an expiration for to the following reasons:

  • Technology advances. When better methods become available such as stronger encryption keys, existing keys become weak. Expiration helps to enforce moving to better technology and methods.
  • Compromise mitigation. Keys are changed often to prevent attackers from using them even if they are able to learn them. As keys are invalidated, attackers lose the ability to use them, which is really good if attackers acquired the key without the knowledge of the owner. Expiration helps to enforce key rotation.
  • Need changes. Key owners may only use certain secrets while performing a specific task. The task may end after a certain date and all secrets tied to that task should also. Expiration helps to enforce this limited period.

3 System Architecture

A decentralized key management system may be implemented using a blockchain ledger as a method for sharing public data in a secure manner but any decentralized secure system could work. The role of third parties participating on blockchain is limited to ensuring the security and integrity of the system. Owners are responsible for data they write to the ledger. The ledger serves as solely an oracle of trust i.e. users should be able to trust the data that is written there but the ledger has no authority by itself. Alice can write her public key to the ledger along with an endpoint where she can be reached. Bob can do the same with his public key and can contact Alice and authenticate her using her public key on the ledger. To prevent an intruder or eavesdropper from overwriting either of their public keys, the ledger protocol should limit updates to Alice’s to only Alice and the same for Bob using their respective master private keys. Users may use any method of authenticating their actions but key signatures are relatively easy to do and validate. If Alice wants to rotate her keys, she can write the new one to the ledger. Then Bob just needs to reference the ledger for the latest version. Users can delegate authority to third parties to perform actions on their behalf like a butler answering the door for their employer or a lawyer or real estate agent or software agent. Owners may create a certificate or key for delegatable entities or delegates may have their keys signed by the owner. This can be verified using the ledger. Owners can remove these authorizations by updating a revocation list on the ledger or replacing their verification keys on the ledger. Users may limit interactions with others solely to approved devices such as smartphones or tablets while government employees may only allow hardened laptops or desktop machines.

4 Conclusion

A DKMS architecture and DPKI provides the following major benefits:

  1. No single point of failure. With DKMS, there is no central CA or other registration authority whose failure can jeopardize large swaths of users.
  2. Interoperability. DKMS will enable any two apps and identity owners to perform key exchange and create encrypted P2P connections without reliance on proprietary software or service providers.
  3. Resilience. DKMS incorporates all the advantages of distributed ledger technology for decentralized access to cryptographically verifiable data, and then builds on top of it a distributed web of trust where any peer can exchange keys, form connections, and issue/accept verifiable claims from any other peer.
  4. Key recovery. Rather than app-specific or domain-specific key recovery solutions, DKMS can build robust key recovery directly into the infrastructure, including agent-automated encrypted backup, DKMS key escrow services, and social recovery of keys, for example by backing up or sharding across trusted DKMS connections.
You can’t perform that action at this time.