Decentralized key management oy . Sam Smith

Chapter 9 covered the overall topic of self-sovereign identity (SSI) digital wallets and agents, but the function at the very core of digital wallets—cryptographic key management—is deep enough to merit its own chapter. Although thousands of papers and dozens of books have been written on the subject of key management, for this chapter on decentralized key management we called on Dr. Sam Smith, who is not only one of the ‘most prolific thinkers and authors in SSI (he is the author of Meta-Platforms and Cooperative Network-of-Network Effects in our Landmark Essays section), but he is the inventor of Key Event Receipt Infrastructure (KERI), covered in the final section of this chapter. Sam received his Ph.D. in Electrical and Computer Engineering from Brigham Young University in 1991, spent 10 years at Florida Atlantic University reaching full professor status, then retired to become a full-time entrepreneur and strategic consultant. He has over 100 refereed publications in the areas of machine learning, Al, autonomous vehicle systems, automated reasoning, blockchains, and decentralized systems.

Chapter 9 began with this overarching definition of digital wallets: A digital wallet consists of software (and optionally hardware) that enables the controller of the wallet to generate, store, manage, and protect cryptographic keys, secrets, and other sensitive private data. We followed that by saying that a digital wallet is the nexus of control for every actor in SSI. The essence of that control is key management. As the Wikipedia article on the subject states:! Key management refers to management of cryptographic keys in a cryptosystem. This includes dealing with the generation, exchange, storage, use, crypto-shredding (destruction) and replacement of keys. It includes cryptographic protocol design, key servers, user procedures, and other relevant protocols.* Successful key management is critical to the security of a cryptosystem. It is the more challenging side of cryptography in a sense that it involves aspects of social engineering such as system policy, user training, organizational and departmental interactions, and coordination between all of these elements, in contrast to pure mathematical practices that can be automated. In this chapter we will cover: Why any form of digital key management is hard « Standards and best practices for conventional key management The starting point for key management architectures: roots-of-trust « The special challenges of decentraiized key management « The new tools that verifiable credentials (VCs), decentralized identifiers (DIDs), and self-sovereign identity (SSI) bring to decentralized key management « Key management for ledger-based DID methods « Key management for peer-based DID methods o Fully autonomous decentralized key management with Key Event Receipt Infrastructure (KERI) The final section on KERI is a special feature of this book as it summarizes the technical architecture of KERL, one of the most comprehensive solutions for decentralized cryptographic key management available at the time of publication Why any form of digital key management is hard Peaple new to cryptography and public/private key infrastructure often wonder why all the fuss about keys. Isn't managing digital keys similar to managing physical keys, of which we usually have a small set we personally control on a key ring or fob of some kind? * bitos://en wikipecia,ora/wid/Key_management @Manning PLblcatons Co. e welcome reacer comments about anyehing i the manusciot — other than typos and other simple mistakes. These wil be clean

ed up durng production of the book by copyediors and profreaders.

‘EManring Publications Co. We welcome reacer comments about anything in the manuscrpt — other than y0s and other simple mistakes. These wil b cieaned up d.ring producton of the book by capyediors and proreaders o v nanng-sancb comyforum SpsPlorumiD=s1

While there is clearly an analogy between physical and digital keys, in reality the differences are dramatic. To wit:

« Digital keys can be stolen remotely. Stealing a physical key requires having physical access to where the key is stored or who is carrying it. Digital keys that are not properly protected can be stolen remotely over a network. Even when they are well-guarded, digital keys can still be stolen using side-channel attacks? (but those are very hard to pull off).

« You may not be able to tell if a digital key has been stolen. A stolen physical key is easy to spot (unless the thief can quickly copy and replace it—a real challenge). But if an attacker is able to gain access to a digital key, they can copy it in milliseconds without you ever even knowing.

o Digital locks are much harder to pick. The alternative to stealing a physical key is just breaking the lock. For many real-world assets, like a car or a home, that is entirely feasible. Breaking a digital lock protected with strong encryption is nearly impossible.

The value that digital keys can unlock may be vastly greater than in the physical world. Most assets protected by a physical key—a car, a house, a bank vault—have a value proportional to the strength of the physical security provided for the asset. But with digital assets, a single key could potentially unlock billions of dollars of value in the form of cryptocurrencies, digital fiat currencies, or some other form of digital asset.”

If lost or stolen, digital keys can be irreplaceable. This is the real kicker. It is nearly impossible to protect a physical asset with enough physical security that it cannot be broken given enough time and money. But digital assets can be protected with encryption so strong (even quantum-proof) that in theory it can withstand all the computing power in the universe for the rest of time (or at least the next few millennia). So digital keys can be almost immeasurably more valuable than physical keys. In 2019, the Wall Street Journal estimated that one-fifth of all bitcoin is missing because the private keys have been irretrievably lost.* At the time we wrote these lines this was about $40 billion.*

« With SSI, your digital keys will become the “keys to your digital life". It is hard to say that about your physical keys. Yes, they are important; they unlock your car, your house, your mailbox, your office, and your safe deposit box. But if you lost the whole set, it would only take you a few days or

weeks to replace all of them. If you lost all the keys in a mature SSI digital wallet (and did not have a recovery method), it could put your digital life on hold for months.

2 ittps://en.wikipedia.ora/wiki/Side-channel_attack 2 Anyane protecting high-value digital assets should be using multi-sig because s security scales much faster than the size of the digital asset. For example there are no reported cases of exploiting the Gnosis multi-sig Ethereum wallt despite some of thase wallets holding billons in assets. https://gnosis-safe.io] s/ ws}.com/articles/a-fifth-of-allbitcoinTs-missing-these-crypto-hunters-can-help-1530798731 & The price of bitcoin was around $10.800 on the 15th of September 2020.

@Manning PLbicatons Co. e welcome reacer comments about anyehing i the manuscriot — other than typos and other simple

mistakes. These wil be cleaned up durng production of the book by copyediors and profreaders. o e, nanning-sandbo.com/farum ssparforumiD=1e

The bottom line: control over your digital keys—as well as the rest of the contents of your digital wallet—is probably the single most critical element of SSI architecture.

Standards and best practices for conventional key management

Thankfully digital key management is not new—we have decades of experience deploying it with conventional PKI—and, more recently, with cryptocurrency keys and wallets. Moreover, since key management is fundamental to cybersecurity infrastructure, research bodies like the U.S. National Institute of Standards and Technology (NIST) have published extensive recommendations on the subject. Several of the best known from NIST are:

« NIST Special Publication 800-130: A Framework for Designing Cryptographic Key Management Systems (CKMS)®—a 112 page publication that provides a comprehensive guide to every topic in key management

« NIST Special Publication 800-57: Recommendation for Key Management’—a three-part series that NIST is constantly updating:

o Part 1—General o Part 2—Best Practices for Key Management Organizations o Part 3—Application Specific Key Management Guidance Following are examples of some of the guidelines from section 2 of NIST 800-57 Part 2:*

o Because the compromise of a cryptographic key compromises all of the information and processes protected by that key, it is essential that client nodes be able to trust that keys and/or key components come from a trusted source, and that their confidentiality (if required) and integrity have been protected both in storage and in transit.

o In the case of secret keys, the exposure of a key by any member of a communicating group or on any link between any pair in that group compromises all of the information that was shared by the group using that key. As a result, it is important to avoid using a key from an unauthenticated source, to protect all keys and key components in transit, and to protect stored keys for as long as any information protected under those keys requires protection.

o Cryptographic confidentiality and integrity mechanisms are most commonly used to establish trust anchors that enforce trust policies and practices. A trust anchor is an authoritative entity for which trust is assumed and not derived. For example, in a public key infrastructure (PKI), a trust anchor is an authoritative entity represented by a public key and associated data.”

https://nuipubs.ist.ov/nistpubs/SoeclalPubications/NIST.SP.800-130.pd 7 https://csre.nist.qov/projects/key-mana

gement/key-management-quidelines @ htps:/nlpubs.ist.gov/Mistpuds/SpecialPublcations/NIST.5P.800-57p12r1. pdt © See the next section on trust anchors and root-of-trust. Rellance on administrative root-of-trust s one of the weaknesses of conwentional pudlc key infrastructure. Ths i an area where the NIST guidelines are not current. ‘EManning Pubicatons Co. e welcome eacer comments sbout anyehing i the manusciot — oiher han typos and ther simple mstakes. These wil b ceaned up g producion ofth book by copyedrors an prooireaders it naning-sandbe comiforum.sepsforumiD=as 1

Symmetric keys are often revoked by the use of Compromised Key Lists (CKLs). Certificate Revocation Lists (CRLs) are commonly used to revoke public key certificates, thus revoking the private key corresponding to the public key in the certificate. Regardess of whether symmetric or asymmetric keys are used, a means of revoking keys s required.

Arevoked key notification may include the revocation reason and an indication of when the revocation was requested. The inclusion of the revocation reason can be useful in risk decisions regarding the information that was received or stored using those keys.

« A key may also be suspended from use for a variety of reasons, such as an unknown status of the key or due to the key owner being temporarily unavailable (e.g., the key owner is on extended feave).

Section 2.3.9 of the latest version of NIST 800-57 Part 2 includes this guidance about centralized vs. decentralized key management: A CKMS can be either centralized or decentralized in nature. For a PKI, the public key does not require protection, so decentralized key management can work efficiently for both large-scale and small-scale cases, The management of symmetric keys, particularly for large-scale operations, often employs a centralized structure. Centralized CKMS key-management structures tend to be more structurally rigid than decentralized key-management structures, but the choice of how to establish keys, store and account for them, maintain an association of keys with the information protected under those keys, and dispose of keys that are no longer needed is a decision to be made by an organization’s security management team. As you might expect, many different standards and protocols have been developed for different aspects of key management. For example, section 2.3.10 of NIST 800-57 Part 2 includes a list of 14 Requests for Comments (RFCs) for key management from the Internet Engineering Task Force (IETF).!2 NIST Special Publication 800-152 contains requirements for the design, implementation, or procurement of a CKMS meeting the standards of the U.S. Federal Government.'! The Organization for Structured Information Standards (OASIS) has been developing the Key Management Interoperabilty Protocol (KMIP) since 2010.12 It has become the industry standard for interoperability of centralized key management servers, which are typically deployed by an enterprise to standardize and automate key management across a large number of applications and servic

es. 10 bt jnvipubs.nist gou/istpubs/SpecialPublications/NIST.SP.800-57pt2r1pdf 1 htps://dol.ora/10.6028/NIST 57 800-152 12 hitps://en.wikipedia.ora/wiki/Key Management Interoperability_Protocol @Manning Publcatins Go. e welcome reacer comment sbout anyehing iy the manusciot — other than typos and other simple mstakes. These wil b ceaned up g producion ofth book by copyedrors an prooireaders it naning-sandbe comiforum.sepsforumiD=as 1

The starting point for key management architecture: roots-of-trust

Whether a key management architecture is centralized, federated, or decentralized, it all

begins with a root-of-trust (aka trust root or trust anchor). The root-of-trust is the

starting point in a chain of trust:? because it is the only point in the chain where trust does

not need to be derived (meaning verified by some means). Instead trust is assumed in the

root-of-trust, ie., verifiers simply accept axiomatically that the root-of-trust can be trusted.

In conventional PKI architecture, the root-of-trust is represented by a special digital

certificate called the root certificate.* As the Wikipedia entry for trust anchor'> explains: In X.509 architecture, a root certificate would be the trust anchor from which the whole chain of trust is derived. The trust anchor [certificate] must be in the possession of the trusting party beforehand to make any further certificate path validation possible. Most operating systems provide a built-in list of self-signed root certificates to act as trust anchors for applications. The Firefox web browser also provides its own fist of trust anchors. The end-user of an operating system or web browser is implicitly trusting in the correct operation of that software, and the software manufacturer in turn is delegating trust for certain cryptographic operations to the certificate authorities™® responsible for the root certificates.

The reason SSI represents such a sea change in key management is that it starts with a

different set of assumptions about roots-of-trust as illustrated in Figure 10.1.

2 htps: jen.wikipedia.ora/wiki/Chain of trust

1 hps://en.wikipedia.ora/wiki/Root_certifcate

5 htps://en.wikipedia.ora/wiki/Trust_anchor

16 hitps://en.wikipedia.ora/wiki/Certificate_authority

@Manning Publcations Co. e welcome reacer comments sbout anyehing i the manusciot — other than typos and other simple mistakes. These wil be cleaned up durng production of the book by copyediors and profreaders.

Self-certifying YW : BB roots-of-trust \ | 4 | Resistance to Attacks . ss| L Administrative roots-of-trust Decentralization Figure 10.1: SSI starts with different assumptions about a root-of-trust—rather than administrative roots, SSI uses algorithmic or self-certifying roots

« Administrative roots-of-trust are what is used in conventional PKI—namely, certificate authorities (CAs) staffed by humans who follow rigorous procedures (Certification Practice Statements)*’ to ensure the quality and integrity of the digital certificates that they issue. Assumed trust in administrative roots-of-trust is based on the service provider's reputation as attested by industry certifications and accreditations.

o Algorithmic roots-of-trust are based on computer algorithms designed to create secure systems where no single party is in control yet all parties can agree on a shared source of truth. Blockchains, distributed ledgers, and distributed file systems like InterPlanetary File System (IPFS) are all examples of algorithmic roots-of-trust. (See Chapter 5 for a complete description about how different SSI architectures use different algorithmic roots-of-trust.) Although all algorithmic roots-of-trust are based on cryptography, the assumed trust requires more than that—it is based on the reputation of the system as a whole, e.g., the number and size of participants, the history of the project, how long the ledger has been running, whether there have been any security issues, and the prospect (or history) of forking. However as we explain in Chapter 15, there are plenty of disagreements about which of these approaches is most trustworthy.

« Self-certifying roots-of-trust are based solely on secure random number generation and cryptography. In the case of SSI, this means DIDs that can be generated using only a digital wallet. The most secure self-certifying roots-of-trust use special hardware such as a secure enclave or a trusted processing module (TPM)

17 hteps://en.wikipedia.ora/wiki/Certification_Practice_Statement SHanning Pblesions o, We welcom reader comments sbout g n the manuscriot — other than (05 and other simple mitakes. These il be claned U duning podctan of he book by copyeaors and rocresders. it mannin:sancbox comforum sspaorumID=s61

to generate and key pairs and store private keys. Assumed trust in self-certifying roots-of-trust is based on the specifications, testing, certification, and reputation of the hardware and software. The reasons these distinctions are so important is summarized in Table 10.1: Table 10.1: Summary of the differences between the three root-of-rust types Administrative Algorithmic Self-certifying Property root-of-trust root-of-trust | root-of-trust Centralized / single point o failure Yes (> (> Requires human e involvement in validation Yes No No Requires the involvement of external parties Yes Yes NO In short, the paradigm shift to SSI and decentralized key management is the shift from administrative roots-of-trust—which are inherently centralized and subject to human fallibility—to algorithmic and self-certifying roots-of-trust which can be partially or fully automated and decentralized. In fact the only difference between algorithmic and self- certifying roots-of-trust is the role of any third party at all (to be discussed later in this chapter). The special challenges of decentralized key management While decades of work have gone into centralized key management practices, decentralized key management is a much newer topic. It barely existed until the first version of Decentralized Identifiers (DIDs—see Chapter 8) was published as a community specification in December 2016. Since DIDs are both decentralized and cryptographically verifiable, they demanded a decentralized solution for managing the assaciated public/private keys. The growing interest in DIDs led the U.S. Department of Homeland Security (DHS) in 2017 to award a research contract on decentralized key management to SSI vendor Evernym.!® As the announcement summarized: Through a project titled “Applicability of Blockchain Technology to Privacy Respecting Identity Management,” Evernym is developing a DKMS—a cryptographic key management approach used with biockehain and other distributed-ledger technologies—to boost online authentication and verification. Within a DKMS, the 12 https://www.dhs,gov/science-and-technology/news/2017/07/20/ news-release-dhs-st-awards-749k-evernym- decentraizeorkey SRanrng Pokhcatons Co. W velcom resce commets abou ayiting inthe manuscrist — er tha 505 and sihr simple takes. These i o ceaned b G proGucon of th ook y copyeators a1 rosreades

initial “root-of-trust” for all participants is a distributed ledger that supports a decentralized identifier—a new form of root identity record. @Manning Pubicatons Co. We welcom reacer commens bout anything i the mansciot — other than typos and other simple mstakes. These wil b ceaned up g producion ofth book by copyedrors an prooireaders o e, manring-sandbo com/forum fspaPforumiD=e1

DKMS stands for “decentralized key management system” (in contrast to CKMS, “cryptographic key management system”). In the two-year research project, Evernym assembled a group of cryptographic engineers and key management experts to produce a document called DKMS Design and Architecture that was published as part of the Hyperledger Indy project at the Linux Foundation.*® The introduction states: DKMS (Decentralized Key Management System) is a new approach to cryptographic key management intended for use with blockchain and distributed ledger technologies (DLTs) where there are no centralized authorities. DKMS inverts a core assumption of conventional PKI (public key infrastructure) architecture, namely that public key certificates will be issued by centralized or federated certificate authorities (Chs). As stated in section 1.3 of this document, DKMS is designed to provide the following major benefits:

1. No single point of failure. Since DKMS uses either algorithmic or self-certifying roots-of-trust, there is no reliance on a central CA or other registration authority whose failure can jeopardize large swaths of users.

2. Interoperability. DKMS will enable any two identity owners and their applications to perform key exchange and create encrypted P2P connections without reliance on proprietary software, service providers, or federations.

3. Portability. With DKMS, users can avoid being locked into any specific implementation of a DKMS-compatible wallet, agent, or agency. Users should—with the appropriate security safeguards—be able to use the DKMS protocol itself to move the contents of their wallet (though not necessarily the actual cryptographic keys) between compliant DKMS implementations.

4. Resilient trust infrastructure. DKMS incorporates all the advantages of distributed ledger technology for decentralized access to cryptographically verifiable data. It then adds on top of it a distributed web of trust where any peer can exchange keys, form connections, and issue/accept verifiable credentials from any other peer.”

5. Key recovery. Rather than app-specific or domain-specific key recovery solutions, with DKMS robust key should be built 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 keys across trusted DKMS connections and agents.?!

1 htp:/oitdy/akms-vé. 2 The DKMS Design and Architecture document was published befo

re the invention of KERI, however it s compatible with KERL' fully decentralized key management architecture. See the final sections of this chapter. 21 See Chapter 9 for more about the role of SSI igital wallets and agents in key recovery. ©Manning Publcatons Co. e welcom reacer comments about anyehing i the manuscrot — othet ihan typos and other simple mstakes. These wil b ceaned up g producion ofth book by copyedrors an prooireaders o e, manring-sandbo com/forum fspaPforumiD=e1

To provide these benefits, however, DKMS needs to address the following challenges:

1. There cannot be any “higher authority” to fall back on. It is surprising how much simpler you can make a system if you know you can ultimately fall back on a centralized authority. But with DKMS, there is no "password reset” option. If there was some outside authority to whom you can turn to to replace your keys, then that authority can always take away your keys—or their systems can be compromised to break into your keys. So a DKMS system must be designed to be failsafe for the key holders from the start.

2. DKMS cannot come from a single company—or even a single consortia. It must be based entirely on open standards that any open source project or commercial vendor can implement—muich like the W3C Verifiable Credentials (VC) and Decentralized Identifier (DID) standards that are already foundational for SSI. This eliminates the proprietary approaches of some of the popular secure chat products today, e.g., Apple iMessage and Facebook Messenger.

3. DKMS cannot dictate a single cryptographic algorithm or ciphersuite? that everyone must use. Many problems can be solved by everyone agreeing on the same cryptography. But there are simply too many options—and the field is advancing too fast—for DKMS to lock into a single type of cryptography. DKMS must be able to accommodate the evolutionary advancement of cryptographic algorithms and protocols.

4. DKMS key and wallet data must be portable across different technical implementations from different vendors. As it is often said in SSI circles: ™If it's not portable, it's not self-sovereign.” Furthermore, portability must be proven against formal interoperability testing, not just marketing slogans.

5. DKMS cannot assume any specialized knowledge or skills on behalf of end- users. DKMS-enabled digital wallets and agents must be as easy—or easier—to use as modern browsers and email clients. Most of all, they cannot require end-users to understand anything at all about cryptography, blockchains, or SSI—or even the concept of public/private keys. It just needs to work—AND be secure.

Some developers reading these requirements might throw up their hands and say it cannot be done. However a growing community of architects, cryptographers, and usability experts are intent not just on doing it, but on baking the solution deep into the infrastructure of the Internet so it is available to everyone, just as email and the Web are today

.

The new tools VCs, DIDs, and SSI bring to decentralized key management SS1 depends on decentralized key management but it also brings new tools to the table to enable it. In this section we will list the specific contributions from VCs (Chapter 7), DIDs (Chapter 8), and digital wallets and agents (Chapter 9). 22 hitos: fen.wikipedia.orawiki/Cipher suite

@Manning Publcations Co. e welcome reacer comments about anyehing i the manusciot — other than typos and other simple

mistakes. These wil be cleaned up durng production of the book by copyediors and profreaders. o e, nanning-sandbo.com/farum ssparforumiD=1e

1: Separating identity verification from public key verification

1n addition to decentralized roots-of-trust, the primary innovation enabling DKMS is the ability of DIDs to separate the verification of the public key of a DID controller from verification of other identity attributes such as the controller’s legal name, URL, address, government ID number, and so on. With conventional PKI, these two steps are bound together in the issuance of an X.509 digital certificate by a certificate authority (CA). This is shown in Figure 10.2 (taken from the in-depth explanation of how DIDs work in Chapter 8). @ - @ ‘ | Controls Publishes e =g Digital certificate Figure 10.2: How conventional PKI-based digital certificates bind together identification of an entity with verification of the entity’s public key With SSI, a DID is generated from a public/private key pair itself using either an algorithmic root-of-trust or a self-certifying root-of-trust. This means the DID controller can always provide proof-of-control of their DID by using their own private key to digitally sign their own DID document as shown in Figure 10.3 (also taken from Chapter 8). @ Publishes o ‘ T TS Controls Publishes | ) A2 Updated DID document anring Pubcaions Co. W velcom resce commets sbut syifing inthe manuscrist — er tha 505 and sihr simpla takes. Thes vl o chanea op oG Poductonof e 5ook o Sopyeators and ol cosrs o - sancho ooy, paYorumiD=851

Figure 10.3: DIDs enable identity controllers to prove their own public keys without the use of an intermediary by digital signing their own DID documents If the DID method uses a self-certifying root-of-trust, the key generation and rotation operations may take place entirely under the aegis of the DID controller—in their own digital wallet or some other key generation and signing system they control. If the DID method uses an algorithmic root-of-trust, a second step is needed: a transaction with an external verifiable data registry (VDR) such as a blockchain. However in both cases these steps can be performed automatically by the DID controller's agent without human intervention. By eliminating the need for a “human in the loop”, there are two other major benefits: 1) the cost of these steps can drop to nearly zero, and 2) the scale at which DIDs can be generated and used increases dramatically. The combination removes any barrier to DID controllers having as many DIDs as they need.?

2: Using VCs for proof of identity

1f DIDs and DID documents can handle the challenge of key verification, that leaves VCs to do what they do best: convey third-party attestions of the real-world identity attributes of the DID controller. This is what a verifier needs to establish real-world business or social trust. Furthermore, by separating identity verification from public key verification, the number and diversity of issuers for identity verification attributes should grow much larger. This gives both DID controllers and verifiers a wider range of choices and lowers the cost for everyone.

3: Automatic key rotation

Another core key management problem that DIDs help solve—as explained in depth in Chapter 8—is automated key rotation. Because the DID is itself an immutable identifier, all DID methods (except a special category called “static”) define how the DID controller can change the public/private key pair(s) associated with the DID by publishing an update to the associated DID document. The specifics of how this is done varies with different DID methods, but they all follow the same principle, which is that the DID controller can accomplish key rotation without the need to rely on any external administrator.

4: Automatic encrypted backup with both offline and social recovery methods

The fact that SSI digital wallets cannot appeal to a higher authority to “reset the password” or “replace the keys” means that backup and recovery must be built directly into the infras

tructure. This can be accomplished by building backup and recovery functions directly into digital wallets and agents as described in Chapter 9, or by leveraging special key recovery capabilities designed into specific DID methods—or both. See the final section of 2 See Chapter 8 on DIDs for more about how random number generation and cryptographic algorithms enable an almost infinite number of public/private key pairs and DIDs to be created without collusion—this is the essence of what enables decentralization ‘EManning Pubications Co. e welcome reacer comment about anyehing i the manusciot — other than typos and other simple mstakes. These wil b ceaned up g producion ofth book by copyedrors an prooireaders o e, manring-sandbo com/forum fspaPforumiD=e1

this chapter for the sophisticated decentralized key recovery architecture built into KERI

5: Digital guardianship

With centralized key management systems, key servers operated by corporations or governments can serve a wide population of users with different levels of capabilities. With decentralized key management, a solution needs to cover individuals who lack the physical, mental, or economic capability to operate their own devices and manage their own keys. This critical aspect of SSI infrastructure is referred to as digital guardianship, a topic covered in more detail in Chapter 11 on SSI Governance Frameworks. Tronically, from a high level, digital guardians can look very much like centralized key management systems. Under the hood, however, they are very different. Guardians typically host individual cloud wallets for each person depending on them, called the dependent. Guardians are usually issued guardianship credentials by an official authority to authorize their guardianship role; they in turn issue delegation credentials to staff persons or contractors to authorize their actions. Lastly, digital guardians usually operate under a governance framework that places strict legal requirements on their roles as information fiduciaries.2 Since any person or organization can operate as a digital guardian—and digital guardianship uses the same open standards and Infrastructure as the rest of SSI—it extends the ability to control and manage digital keys to those who otherwise could not do it on their own. Key management with ledger-based DID methods (algorithmic roots-of-trust) All DID methods rely on a root-of-trust as shown in Figure 10.1—a starting point for proving the chain of trust based on a public/private key pair. Although the key pair itself is usually generated in secure hardware using a long random number, most DID methods do not rely on this root-of-trust alone (i.e., they are not self-certifying). They require a second step: using the private key to digitally sign a transaction in a distributed ledger or blockchain to “record” the DID and the initial associated public key. Once that record is created, the ledger becomes the algorithmic root-of-trust for the DID. ‘This means verifiers must check with the ledger in order to verify the current public key and any other contents of the DID document associated with the DID. In other words, verifiers must trust: 1. The consensus algorithm and the operation of the particular ledger, |.e., its abil

ity to withstand a 51% attack? or any other form of corruption o attack. 2. The security of the resolver used to access records on the ledger.

74 See Information Fiduciaries and the First Amendment. itps://lawreview aw.ucdavis edu/issues/ 49/ Lecture/ 9-4_Ballin.odf 25 See nitps://tools et ora/ntmi/r£c4086 for how to do this securely 26 https:/Jwwusinvestopedia.com/terms/1/51-attack.asp.

@Manning Publcatons Co. e welcome reace" comments about anyehng i the manusciot — other than typos and other simple

mistakes. These wil be cleaned up durng production of the book by copyediors and profreaders. it naneing-sandbo comforum.sspsorum D=8

1. The genesis records used by the resolver (or the verifier) to verify resolution results. Given the success of large, well-established public blockchains like Bitcoin and Ethereum, together with the well-known mechanisms for verifying lookups from those ledgers, these are widely considered to be strong algorithmic roots-of-trust. In addition, for many DIDs, it is desirable for them to be publicly resolvable and verifiable. Thus it is no surprise that, as of August 2020, 95% of the 63 DID methods registered in the W3C DID Specification Registry use DID methods based on an algorithmic root-of-trust, i.e., some type of public ledger.?”

But ledger-based DID methods also have several downsides:

1. Dependency on another party or network. Although the ultimate root-of-trust is still the key pair used to generate the DID and update the DID document on the ledger, a ledger-based DID method requires a DID controller to depend on a distributed ledger and its associated governance mechanisms to be trustworthy. To the extent a DID controller can count on the ledger to be incorruptible and always available, that risk may be small, but it is still non-zero. For example, all distributed ledgers are subject to 51% attacks, forking, or changes in their governance or regulatory status.

2. Non-portability (“ledger-lock"). Ledger-based DIDs are "locked” to a specific ledger and cannot be moved if problems develop with the ledger or its governance— or if the DID controller desires to use other DID methods.

3. Potential conflicts with the GDPR “right-to-be-forgotten”. While not an issue with DIDs meant for use by organizations (or things), DIDs and public keys for personal use are considered “personal data” under the EU General Data Protection Regulation (GDPR) and thus subject to the right of erasure, popularly known as “the right to be forgotten”. This can be a serious issue for immutable public ledgers. Because these ledgers co-mingle transactions from all users, transactions for a given DID may not be removable without destroying the integrity of the ledger for all the other users.”

Key management with peer-based DID methods (self-certifying roots-of-trust) Once DIDs and DKMS started to catch on, it was not long until some security architects realized that, while ledger-based DIDs have many advantages, the use of a ledger is not technically required to gain the benefits of DIDs. Given that the ultimate root of trust is the long random number upon which a public/privat

e key pair is based—and that this root-of- trust exists only i the DID controller’s digital wallet—these architects saw that for many scenarios, DIDs and DID documents that were seff-certifying could be generated entirely 27 https:/wic-cca.sithub.io/did-method-resistry/ 22 For an in-depth discussion of this problem, see the Sovrin Foundation white paper Innovation eets Comaliance; Data Privacy Regulation and Disributed Ledger Technology. htos://sovrin.ora/data-protection

‘EManning Publcatins Co. e Welcome eacer comments sbout amyEing in the manuscrot - other ran typos and other simple

mstakes. These wil b ceaned up g producion ofth book by copyedrors an prooireaders o e, manring-sandbo com/forum fspaPforumiD=e1

within a digital wallet and exchanged directly—peer-to-peer.2

This led to the development of the did:peer: method defined by the Peer DID Method

Specification, ™ first published by Daniel Hardman in 2018. As of August 2020, this

specification had 15 contributing authors and had moved to the Identifier and Discovery

Working Group at the Decentralized Identity Foundation for further standardization.*: To

quote from the Overview. Most documentation about decentralized identifiers (DIDs) describes them as identifiers that are rooted in a public source of truth like a blockchain, @ database, a distributed filesystem, or similar. This publicness lets arbitrary parties resolve the DIDs to an endpoint and keys. It is an important feature for many use cases. However, the vast majority of relationships between people, organizations, and things have simpler requirements. When Alice (Corp|Device) and Bob want to interact, there are exactly and only 2 parties in the world who should care: Alice and Bob. Instead of arbitrary parties needing to resolve their DIDs, only Alice and Bob do. Peer DIDs are perfect in these cases. In many ways, peer DIDs are to public, blockchain-based DIDs what Ethereum Plasma or state channels are to on-chain smart contracts — or what Bitcoin's Lightning Network is to on-chain cryptopayments. They move the bulk of interactions off-chain, but offer options to connect back to a chain-based ecosystem as needed. Peer DIDs create the conditions for people, organizations and things to have full control of their end of the digital relationships they sustain.

The specification goes on to list these benefits of peer DIDs:

o They have no transaction costs, making them essentially free to create, store, and maintain.

o They scale and perform entirely as a function of participants, not with any central system’s capacity.

« Because they are not persisted in any central system, there is no trove to protect.

« Because only the parties to a given relationship know them, concerns about personal data and privacy regulations due to third-party data controllers or processors are much reduced.

o Because they are not beholden to any particular blockchain, they have minimal political or technical baggage.

o They can be mapped into the namespaces of other DID ecosystems, allowing a peer DID to have predictable meaning in 1 or more other blockchains (see Grafting). This creates an interoperability bridge and solves a problem with blockchain forks fighting

over the ownership of a DID.

29 Sef-certifying identifers (SCIDs) will be explained further in the following section. 20 https://identity.foundation/peer-did-method-spec/index.ntml 2L hitps: fidentity.foundation/working-aroups/identifers-discovery htm £Manning Publcations Co. e welcome reacer comments about anyehing i the manusciot — other than typos and other simple mistakes. These wil be cleaned up durng production of the book by copyediors and profreaders. o e, nanning-sandbo.com/farum ssparforumiD=1e

o Because they avoid a dependence on a central source of truth, peer DIDs free themselves of the often-online requirement that typifies most other DID methods, and are thus well suited to use cases that need a decentralized peer-oriented architecture. Peer DIDs can be created and maintained for an entire lifecycle without any reliance on the internet, with no degradation of trust. They thus align closely with the ethos and the architectural mindset of the local-first™? and offline-first> software movements.

Key rotation and key recovery with peer DIDs are a matter of each peer, as the controller of their own peer DID, communicating updates to their peer DID document to the other peer. This Is the purpose of the peer DID protocol defined in section 4 of the Peer DID Method Specification. It defines the standard four DID CRUD (create, read, update and deactivate) operations peers must perform:

1. Create / register peer DIDs and DID documents with each other.

2. Read /resolve peer DIDs.

3. Update peer DID documents for key rotation, service endpoint migration, or other changes.

4. Deactivate a peer DID to end a peer relationship.

Peer DIDs bypass the need for an algorithmic root-of-trust because they are based directly on the self-certifying root-of-trust used to generate the initial key pair without having to rely on a network. Since any well-designed SSI digital wallet can provide this function—and protect the resulting private key—peer DIDs eliminate the need for any external dependencies. They are fully "portable” and can be as decentralized and scalable as the Internet itself (if not more so0).> This design also favors censorship resistance, an attribute highly valued by many in the decentralized technology community. The only downside is that peer DIDs are not publicly discoverable and resolvable. But what if there was a DID method that relied only on a self-certifying root-of-trust, yet provided the best of both worlds: publicly discoverable/resolvable DIDs and peer DIDs? 22 nttpss/ . Inkandswitch.com/local-first html 2 httpi//offinefirst.ora/ 3 The Intemet's TCP/IP protocol still elies on federated identifirs (IP addresses) and routing tables that ultimately have @ centralized root managed by ICANN, Peer DIDs have no central oot ‘EMenning Pubications Co. e welcore reacer comments sbout anyehing It the manuscrot — oiner than typos and other simple mstakes. These wil b ceaned up g producion ofth book by copyedrors an prooireaders o e, manring-sand

bo com/forum fspaPforumiD=e1

Fully autonomous decentralized key management with Key Event Receipt Infrastructure (KERI) As Figure 10.1 illustrates, the ideal root-of-trust from a security point of view—superior to both administrative and algorithmic—is a self-certifying root-of-trust that does not have to rely on a network. Properly implemented, it is both the most decentralized and the most resistant to attack. Every DID controller’s wallet can serve as their own self-certifying root- of-trust, and these wallets can live anywhere on the network—ideally on edge devices, where they are hardest to attack remotely. The Peer DID method (discussed in the previous section) applies this architecture by using a simple type of self-certifying identifier (SCID). A SCID is derived from a public/private key pair using one or more applications of cryptographic one-way functions.”* The SCID is now bound to that key pair, and only the holder of the private key can prove control of the SCID

Many other blockchains use this same technique—for example this is how a Bitcoin user proves control of a Bitcoin address. The difference is that SCIDs do not require a blockchain—or any other infrastructure—to verify the binding with the public key. Anyone with the SCID and the public key can verify the binding using cryptography alone. This is what is meant by self-certifying. The next step is to make the entire DID method self-certifying, i.e., not just the initial SCID, but all key rotations after that. That was the inspiration for Key Event Receipt Infrastructure (KERI). In KERI architecture, the history of all uses or changes to the public/private key pair can be compiled to enable universal self-certifying proofs of the binding between the SCID and the associated public/private key pairs. With KERT architecture, the SCID is agnostic about where it is registered or discovered—it is completely portable and can form the root of a namespace for other SCIDs from the same controller. As far as we know, KERI is the first identifier and key management system to propose completely autonomous, portable, cryptographically verifiable identifiers that can be as public or private as required. While this might sound similar to the original vision for Pretty Good Privacy (PGP), PGP key sharing infrastructure needed to be manually set up and maintained by humans via key signing parties.®* Key rotation was a manual, laborious (and error-prone) process as well.” With KERI, we can finally—25 years later—achieve Phil Zimmerman

n’s vision by leveraging the distributed computing infrastructure and blockchain-inspired cryptographic engineering. 5 See Chapter 6 35 See the following sections for details of how this works. 37 hitpss/Jen.wikipedia.org/wiki/Pretty_Good_Privacy 38 hutps:/jen wikipedia.org/wiki/Key_signing_party 9 hitpss/ e vice.comjen_us/article/wwbwajeven-thesinventor-of-pgp-doesnt-use-pgp

@Manning Pubications Co. e welcome reacer comments sbout anyehing i the manusciot — other than typos and other simple

mstakes. These wil b ceaned up g producion ofth book by copyedrors an prooireaders o e, manring-sandbo com/forum fspaPforumiD=e1

KERI aims to be the first decentralized key management architecture that can be adapted to any underlying digital wallet or key management server and can be interoperable across all of them. A DID method based on KERI inherits all these features. So from the standpoint of SSI, KERI is positioned to deliver the greatest degree of self-sovereignty of all of the options for DIDs and DKMS, including anything rooted on shared ledgers. In this section we will explain the basics of KERI architecture by way of summarizing its seven major benefits. For the full technical details, please refer to the KERI technical paper.©®

1: Self-certifying identifiers as a root-of-trust

As explained above, the starting point for KERI architecture is self-certifying identifiers (SCIDs). The KERI technical paper defines a SCID as:

A self-certifying identifier cryptographically binds an identifier to a key-pair. SCIDs were introduced in Chapter 8 on DIDs because they are the subclass of DIDs that depend exclusively on a self-certifying root-of-trust—they do not require either an administrative o an algorithmic root-of-trust. The basic concept s illustrated in this diagram from Chapter 8: @ = @ Controls Publishes Generates fl

Figure 10.4: Self-certifying identifiers (SCIDs) generate the identifier for the controller directly from the public/private key pair without the need for any external administrator or algorithmic root-of-trust The identifier is self-certifying because, given the associated public key, anyone can instantly verify that the identifier was generated from the public/private key pair using a one-way function such as a hash function. The diagram on the left side of Figure 10.5 (from the KERI technical paper) shows how the controller starts the process by instructing the digital wallet to generate a large random number (using a secure source of entropy as “ KERIis defined in a 138 page techical white paper that is being standardized by the Igentifer and Discovery. Working Group at the Decentralized Igentity Foundation

‘EHaning PLBlcations Co. We walcome reader comments sbalt anyihing i the manuscript — cthe tha typos and oher simple

istakes. These wll b cleaned up during producion o th book by Copyediors and prosieaders. D aning-sancha.comforum spartorumip=a

described in IETF RFC 4086).* Then the digital wallet generates a cryptographic key pair. Finally, the digital wallet derives the identifier (SCID) from the key pair. The result is a SCID whose binding with the public key can be verified instantly using cryptography alone—no need for a ledger, administrator, or any other external source of truth. entropy controller cntres contoler / idenity \ controller system ot siong | 2557, (stong generates derives veries overlay Key-pair <~ binding |+~ identifier key-pair_j<—~{ strong j—=| identifer selfertiying Self-Certtying dentifer Issuance Figure 10.5: The process for generating a SCID (left) and the resulting bindings between the controller, the cryptographic key pair, and the SCID (right) SCIDs are 100% portable identifiers2 because the controller can “take them anywhere” and prove control without a verifier needing to trust anything but the cryptography and the Security of the controller’s digital wallet. Because all other capabilities in KERI depend on the integrity and strength of SCIDs, the KERI technical paper defines several specific subtypes of SCIDs (basic, self-addressing, multi-sign self-addressing, delegated self-addressing, and self-signing) together with their syntactic structure, derivation code, inception statements, and generation algorithms inside a self-certifying root-of-trust.

2: Self-certitying key event logs

KERI takes its name not from the SCIDs at the heart of the architecture, but from how it handles one of the hardest problems in decentralized key management: key rotation and recovery. This approach is summarized in this sentence from page 29 of the KERI technical paper: [KERI] leverages the fact that only the controller of the private key may create and order events that perform verifiable operations on the keys. As fong as one complete verifiable copy of the event history is preserved, the provenance of control authority 1 Sog hitps:/tools.ietora/ 4088 for haw to do this securely. 2 peer DIDs are a subclass of SCIDs that share this same benefit of full portability. 3 See pages 8 - 20 of the KERI technical paper. hanting PLbtcatans Co o welcome resee conens sbout syiting inthe manuscrist — er tha 505 ond sihr simpla takes. Thes vl o chanes op oG Poducton o e 5ook o Sopveators and o cosrs o - sancho ooy, paYorumiD=851

may be established. ‘EManring Publications Co. We welcome reader comments about anything inthe manuscrpt — other than yp0s and other simple mistakes. These wil be cleaned up d.ring producton of the book by copyediors and prooireaders DitoifAsens manning:sandbox,comiforum.JspRTorumID=AGL

With KERI, every rotation to the key pair associated with a SCID generates a new key event. The KERI protocol dictates the exact structure of a key event message. Every key event message includes a sequence number. Every key event message except the very first one (the inception event) also includes a digest (hash) of the previous key event message. The controller then digitally signs the new key event message with the new private key, producing a key event receipt. The result is an ordered sequence (“chain”) of key event receipts called a key event log that anyone can verify in much the same way they verify the sequence of transactions on a blockchain—but without needing an algorithmic root-of-trust. Figure 10.6 from page 40 of the KERT technical paper illustrates a sequence of key event messages in a key event log: Key Event Message version prefix | sn | digest | ilk | configuration | signatures Key Event Message version prefix | sn | digest | ilk | configuration | signatures | Key Event Message version prefix | sn | digest | ilk | configuration | signatures Figure 10.6: Each key event message in a key event log (except the first one) includes a sequence number and a digest of the previous key event message, creating a tamper-proof ordered sequence similar to a blockchain but without needing an algorithmic root-of-trust

3: Witnesses for key event logs

One of KERI's primary innovations is that other parties besides the controller can also digitally sign key event messages. These parties are called witnesses because they are “witnessing” the controller's digital signature on a key event message just like they would witness a person’s physical signature on a paper document (as s often legally required for high-value documents like wills or mortgages). As shown in Figure 10.7, the KERI protocol standardizes how witnesses can receive key event messages from the controller and, if the witness can verify the key event message, the witness can then add their own signature to create their own independent copy of the @Manning Pubicatons Co. We welcom reacer commens bout anything i the mansciot — other than typos and other simple mstakes. These wil b ceaned up g producion ofth book by copyedrors an prooireaders o e, manring-sandbo com/forum fspaPforumiD=e1

key event log, Allkey events signed by Allkey events signed by Controller Controller and Witness Controller Witness Key Event Log Key Event Log : Key event message : Inception Event Inception Event : : Rotation Event Rotation Event ) ) Rotation Event Rotation Event ) . Rotation Event Rotation Event b Key event message o Rotation Event Rotation Event Figure 10.7: Witnesses increase the trustworthiness of a KERI key event log by: a) adding their own digital signature to each event, and b) maintaining their own independent copy of the log Each witness becomes a secondary root-of-trust to the controller's primary self-certifying root-of-trust. To the extent a witness is trusted by a verifier to serve as an independent source of truth about key event messages, each additional witness increases the trustworthiness of the key event log. Again, this works just like human witnesses to the “wet ink” signing of a physical document. If you have the signature of one witness attesting when and where they saw the signer sign the document, that's good. If you have the signature of four witnesses saying when and where they saw the signer sign the document, that's better.

4: Pre-rotation as simple, safe, scalable protection against key compromise

The challenge all key management systems must answer is not just how to rotate keys, but how to protect against the compromise of a private key—via any of the myriad ways that can happen: o Lost or stolen device « Security flaw in the self-certifying root-of-trust (digital wallet) « Side-channel attack® on the self-certifying root-of-trust « Social engineering attack on the controller “ hitps: Jen wikipedia_ora/wiki/Side-channel_attack ‘SHaning Publcations Co. We welcome reader comments sbaut anyihing i the manuscript — ot thantyp0s and oer simple mstakes. These wil b ceaned up g producion ofth book by copyedrors an prooireaders o e, manring-sandbo com/forum fspaPforumiD=e1

• Extortion attack on the controller (“rubber-hose cryptanalysis”)** Private key compromise Is even more dangerous in decentralized key management because there is no “higher authority” than the controller of the keys. So losing control of a private key is tantamount to handing over control of all DIDs or SCIDs that depend on that private key. For this reason, KERI builds protection against compromised private keys right into the heart of the architecture using a technique called pre-rotation. In short, starting with the inception event and continuing in every key rotation event, the controller publishes not only the new public key but a cryptographic commitment® to the next public key (called the pre-rotated public key). This commitment is in the form of a digest (cryptographic hash function—see Chapter 6) of the pre-rotated public key. This digest is included in the key event message establishing the new current public key as shown in Figure 10.8. Establishment Event Message Key Event Data Public Key Config Other Config | Signing Config

header | current key(s) ' next key(s) digest details signers signatures Figure 10.8: KERI uses pre-rotation of key pairs to protect against compromise of private keys Pre-rotation enables the controller to have pre-established an entirely new and different public/private key pair for the next key rotation event. This means that an attacker who compromises the current private key will not have any ability to “take over” the SCID by rotating to a new public key because the next public key has already been committed to. Indeed, the only way the attacker can take over the SCID is to steal the pre-rotated private key. But a number factors make this extremely difficult:

1. The attacker does not even know what the pre-rotated public key is because all that has been published s its digest.

2. The pre-rotated key pair does not need to be exposed in any signing operations until the next key rotation event.

3. The pre-rotated key pair can be safely stored offline (“air-gapped”) under very high security because it is not needed until it is placed into active service after the next key rotation event.

4. Each pre-rotated key pair can be used to safely generate the next one prior

5 Although the origin of this term s tongue-in-cheek, this attack vector i deadly serious because in most eryptosystems, the human user is the weakest lik. See hitps://en wikipedia.ora/wiki/Rubber-hose_cryptanalysis

hitps://en.wikipedia.org/wiki/Commit

ment scheme @Manning Publcatons Co. e welcome reacer comments about anyehing i the manusciot — other than typos and other simple mistakes. These wil be cleaned up durng production of the book by copyediors and profreaders.