KEY EVENT RECEIPT INFRASTRUCTURE (KERI) DESIGN 12 Samuel M

KEY EVENT RECEIPT INFRASTRUCTURE (KERI) DESIGN 12 Samuel M. Smith Ph.D. v2.59 2021/02/16, original 2019/07/03 Abstract—An identity system based secure overlay for the Internet is presented. This includes a primary root-of-trust in self-certifying identifiers. It presents a formalism for Autonomic Identi- fiers (AIDs) and Autonomic Namespaces (ANs). They are part of an Autonomic Identity System (AIS). This system uses the design principle of minimally sufficient means to provide a candidate trust spanning layer for the internet. Associated with this system is a decentralized key management infrastructure (DKMI). The primary root-of-trust are self-certifying identifiers that are strongly bound at issuance to a cryptographic signing (public, private) key-pair. These are self- contained until/unless control needs to be transferred to a new key-pair. In that event an append only chained key-event log of signed transfer statements provides end verifiable control provenance. This makes intervening operational infrastructure replaceable because the event logs may be served up by any infrastructure including ambient infrastructure. End verifiable logs on ambient infrastructure enables ambient verifiability (verifiable by anyone, anywhere, at anytime). The primary key management operation is key rotation (transference) via a novel key pre-rotation scheme. Two primary trust modalities motivated the design, these are a direct (one-to-one) mode and an indirect (one-to-any) mode. The indirect mode depends on witnessed key event receipt logs (KERL) as a secondary root-of-trust for validating events. This gives rise to the acronym KERI for key event receipt infrastructure. In the direct mode, the identity controller establishes control via verified signatures of the controlling key-pair. The indirect mode extends that trust basis with witnessed key event receipt logs (KERL) for validating events. The security and accountability guarantees of indirect mode are provided by KA2CE or KERI’s Agreement Algorithm for Control Establishment among a set of witnesses. The KA2CE approach may be much more performant and scalable than more complex approach- es that depend on a total ordering distributed consensus ledger. Nevertheless KERI may employ a distributed consensus ledger when other considerations make it the best choice. The KERI approach to DKMI allows more granular composition. Moreover, because KERI is event streamed it enables DKMI that operates in-stride with data events streaming applications such as web 3.0, IoT, and others where performance and scalability are more important. The core KERI engine is identifier independent. This makes KERI a candidate for a universal portable DKMI. Index Terms—Secure Overlay, Trust Spanning Layer, Autonomic Identifier (AID, Autonomic Identity System (AIS), Autonomic Namespace. Decentralized, Key, Management, Infrastructure, Key, Event, Receipts, Pre-rotation, Rotation, Event, Streaming, DKMI, KERI, KERL, KEL, KA2CE, KERI’s Agreement Algorithm for Control Establishment Post-Quantum Security, Self-Sovereign Identity. 1 INTRODUCTION The major motivation for this work is to provide a secure decentralized foundation of trust for the Internet as a trustable spanning layer [7; 24; 41]. A major flaw in the design of the Internet Protocol was that it has no security layer. There is no built-in mechanism for security. Anyone can forge an IP (Internet Protocol) packet. Specifically the IP packet header includes a source 1. https://arxiv.org/abs/1907.02143 2. https://keri.one 1/141 address field to indicate the IP address of the device that sent the packet [79]. Because the source address may be forged, a recipient may not know if the packet was sent by an imposter. This means that security mechanisms for the Internet must be overlaid (bolted-on). OSI Model IP Model Application Application Presentation Authentication Session Transport Transport TCP, UDP Network Network IP Link Link Physical Figure 1.1. OSI vs IP Protocol Stack. IP stack is missing session layer which provides security (authentication). Without built-in security layer, IP security must be provided by bolt-on identity system security overlays. A typical Internet security overlay is based on some form of identity system that leverages the properties of asymmetric public key cryptography (PKI) [115]. The purpose of the overlay is to establish the authenticity of the message payload in an IP Packet. The following diagram shows the basic concept. key-pair identity system mapping identifier Message Verifiable Payload identifier data signature Figure 1.2. Identity System Security Overlay. Authenticity of verifiable packet payload is derived from mapping between an asymmetric key-pair and identifier. Attached digital signature exclusively (non- repudiably) associates verifiable payload to the holder of the private key from the key-pair. The overlay’s security is contingent on the mapping’s security. In general, with such a security overlay, the message payload inside an IP packet includes a unique identifier provided by the identity system that is exclusive to the sender of the packet. The payload is signed with a digital signature generated by the private key of a (public, private) key-pair. This signature is attached to the packet. The identity system provides a directory that links or maps the public key from the (public, private) key pair to the sender identifier. A valid signature verifies that the packet came from the holder of the private key. The mapping between identifier and public key establishes that the message came from the holder. This approach as- sumes that only a valid sender of the packet with payload has access to the private key, i.e. the sender is the exclusive holder or controller of the private key. As a result the recipient of the packet may use the identity system to look-up the corresponding public key given the unique sender identifier in the packet payload and then with that public key, cryptographically verify the signature attached to the payload. Only the holder of the private key may generate such a verifi- 2/141 able payload. Without access to the private key, an imposter may not forge a verifiable payload. This security mechanism ostensibly establishes that the payload in the packet came from the correct source. Ostensibly, because the strength of this establishment depends on the strength of security of the mapping between identifier and key-pair. Indeed, the overlay’s security is contingent on the mapping’s security. In addition, when ordering is important, other contents of the payload such as sequence num- bers may be used to protect against replay of the same payload in a different packet. Notably, se- curely establishing authenticity of the payload via a signature is orthogonal to ensuring that the contents of the payload are confidential via encryption. Encryption is an additional task. Confi- dentiality alone may be insufficient when the payload is from the wrong source. 1.1 Binding The important essential feature of an identity system security overlay is that it binds together controllers, identifiers, and key-pairs. A sender controller is exclusively bound to the public key of a (public, private) key-pair. The public key is exclusively bound to the unique identifier. The sender controller is also exclusively bound to the unique identifier. The strength of such an identity system based security overlay is derived from the security supporting these bindings. Figure 1.3. Identity system as security overlay. Mechanism provides secure bindings between controlling entities, asymmetric key-pairs, and identifiers. To elaborate, typically the associated identity systems are administrative in nature. This means the identifiers sourced from such an identity system are ultimately controlled by the associated administrator (administrative organization) of the identity system. From a security perspective, the most important function of the administrator is to authoritatively and usually exclusively per- mit some other entity to use the identifier. We call the permitted use by an entity of an identifier a binding between the entity and the identifier. The permitted entity we call the controller (or for short the user) In this sense the administrator binds that controller (user) to an identifier. This binding enables the controller to use the identifier to make mappings to resources such as IP ad- dresses. The administrator also binds the public key from a cryptographic (public, private) key- pair to this entity-identifier binding. The controller holds the private key and may prove its permitted use of the identifier by signing a statement (packet) with the private key. By virtue of holding the private key, the controller is bound to the key-pair. When the identifiers are sourced from the administrator then their use is contingent on the administrator’s continuing permission (usually by paying rent). The exclusivity and security of the bindings between controller and identifier and the key-pair and identifier are based on trust in the administrator and by association the ostensibly trustable secure operation of essential computing infra-structure to sustain and manage control over the bindings. By essential we mean necessary to the security function of the overlay. Thus a controller of an identifier sourced from 3/141 such an administrative identity system is merely a renter of the identifier and must also rely on the operational security of the administrator’s essential computing infrastructure. Consequently

Load more