TolP
Trust Spanning-layer Protocol (TSP)
Proposal A Secure Identifier Overlay for the Internet
Samuel M. Smith Ph.D. sam@keri.one https://keri.one 2023/02/08
Identity (-ifier) System Security Overlay Establish authenticity of IP packet’s message payload. Authenticatable Message Verifiable Payload i identifier }H\ identity system mapping <—>| key-pair | The overlay’s security is contingent on the mapping’s security.
Identity (-ifier) System Security Overlay persistent (transferable) mapping = verifiable data structure of key state changes [ identifier ‘4—» identity system mapping \<—>\/ key-pair ] Establish authenticity of IP packet’s message payload. Authenticatible Message Verifiable Payload Ldentifier data signature Message Authenticatible Message Verifiable Payload - identifier data signature )
What is an overlay?
Definition: something laid over something else; covering; a layer, or decoration of something applied
Network Overlay (Gartner): s gartner.comjenfsformation technologylglossaryfoverlay An overlay is an installation of a networking component that is noninvasive to the wired infrastructure. Overlays generally employ tunneling techniques that connect end-point functionality to a central controller offering a variety of data, management, and control plane functions.
Security Overlay (NIST): psiseis ovigiossayemisecurty.conol overisy Afully specified set of security controls, control enhancements, and supplemental guidance derived from tailoring a security baseline to fit the user’s specific environment and mission.
Identity System Security Overlay (KERI): nussiigthus.conysmitSamusipspersbiobimssterhiepsperskea) e 2xswebt Provides a trust basis that binds controllers, identifiers, and key pairs. Provides persistent control over autonomic identifiers via the cryptographically verifiable provenance of each identifier’s controlling key state. Provides verifiable control over supporting infrastructure, including other key pairs, that may be used to securely facilitate the authenticity, confidentiality, & privacy of interactions between controllers.
Why an overlay? «Efficiently imbue primitives (identifiers) in a statement with a given overlay’s property(s) either singularly or in combination with other overlays. «Modular flexible application to complex expressions. «High expressive power. Example: Uncertainty Overlays in Automated Reasoning (making computers think like people) Three main types of uncertainty (each with its own overlay): imprecision, likelihood, and ambiguity. ireecss e v ot vty ! | | ] Loads for ships Contextual Ambiguity The load is heavy is highly likely Loads for dumptrucks [—— Loads for wheelbarrows [r—— \ (R Loads for a plate of food | . o Loads for wheelbarrows when pushed by a construction worker The load is too heavy is more-or-less likely ¢ Loads for wheelbarrows when pushed by two power lifters I st ety Loads for wheelbarrows when filed with gravel ingrecn qanifer vty | imrscsion s vty oot sty | J | | i Loads for wheelbarrows when filled with periite Most loads are very heavy is somewhat likely Loads for old rusty wheelbarrows with a flat tire
Authenticity Overlay Example In the yard, Ned the neighbor, Bob the builder, and Cam the construction worker who is pushing a wheelbarrow. The load is heavy is ? likely given Ned said it. The load i heavy is ? likely given Bob said it. The load is heavy is ? likely given Cam said it. The load is heavy is ? likely given anyone, including those not in the yard, could have said it. The usefulness of any information in any decision process is dependent on the authoritativeness of its source. If one can’t securely attribute the source one can’t ascertain the usefulness of the information. The first property of received information that must be established by any decision maker is authenticity before any further processing can proceed.
Authority Overlay Example In the yard, Ned the neighbor, Bob the builder, and Cam the construction worker who is pushing a wheelbarrow. The load is too heavy said Ned to Bob The load is too heavy said Bob to Cam The load is too heavy said Cam to Bob Ned said to Bob, the load is too heavy and then Bob said to Cam, | concur with what Ned said. The response of a party to a command (authorization) depends on the authority of the commanding party with respect to the commanded party which requires authentication of the commander by the commanded. The load is too heavy said Cam to Ned The load is too heavy said Bob to Ned The load is too heavy said Bob to some unknown entity. The effectiveness of a command is dependent on the authentication of the commanded by the commander.
Identity (-ifier) System Security Overlay persistent (transferable) mapping = verifiable data structure of key state changes [ identifier ‘4—» identity system mapping \<—>\/ key-pair ] Establish authenticity of IP packet’s message payload. Authenticatible Message Verifiable Payload Ldentifier data signature Message Authenticatible Message Verifiable Payload - identifier data signature )
Autonomic Identifier (AID) (Persistent): oy 15SUaNCe and Binding 4 captures conroller | | « ~ ( stron (‘stron | contoller JY\ | Strong | stong | 7 \ D / identity \ generates / \ - verfies ( " system ) 2 / \ N key-pair =0 identifer . N X ) keypair | T s 1 | identier | \ overay / ~/ "\ o) (g N | \ i N N key event log } key event log autoromic, sef-managing Autonomic Identifer Issuance Tetrad cryptographic root-of-trust & verifiable persistent control
Key State Proof is Recursive Application of Overlay persistent (transferable) mapping = verifiable data structure of key state changes ‘j identifier J«—» identity system mapping <—>\ key-pair \ Key State Proof Authenticatible Message Verifiable Payload key state signature Authenticatible Message Verifiable Payload identifier | key state data signature
Wither Destination in Authentication Overlay what counts as a destination identifier is contextual and may be entirely implicit Aubonticathl ossags
erfatie Paosd T el versionprotoco | packet by |packet D] ideniter | sn keys | icenter | igontfler | ientfer | dota | delogator || signature Autentaie essage Vertab Payload verson | pratoco | packetype | packet 0| ideter | sn | priorpacketiD | dota | signature | indexed signature | indesed signaturs | “ubertcatbi Nessage erftle Payiad vrsion | proocolpackat D sswor | Issuee | dela || signaturo |
Confidentiality Overlay Duality
A confidentiality overlay is the dual of an authenticity overlay
Authenticity: Asymmetric key pair for signing, private key signs, any public key verifies
Only the key pair controller can sign with the private key, any recipient can verify with the public key. Confidentiality: Asymmetric key pair for en-de-cryption, public key encrypts, private key decrypts
Only the key pair controller can decrypt with the private key, any sender can encrypt with the public key Any identifier can have a key state that includes both an asymmetric signing key pair and an asymmetric decryption key pair. Either the key pairs can be the same, or the decryption key pair can be derived from the signing key pair
Thus an efficient approach is that only one key state, the signing key state, needs to be maintained. (with caveats) Given the identifier and the security overlay’s mapping to look up key state, any other party:
Can verify with the signing public key that a message was non-repudiably sourced by the controller of the identifier (authenticity) (any-end-verifiable non-repudiable)
Can encrypt a message using the encryption public key to ensure that only the controller of the identifier can view it (confidentiality) (only-end-viewable restricted)
End Verifiability End-to-End Verifiability of Authenticity | Middle = data o ; ! Middle - [ Middie . - @ e 8 i End L. o Middle »——csta——{ Middlp p——ea — 3 End | - e L e o saa at “( Middle - & de Middle} If the edges are secure, the security of the middle doesn’t matter. Ambient Verifiability: any-data, any-where, any-time by any-body Zero-Trust-Computing Its much easier to protect one’s private keys than to protect all internet infrastructure
End Viewability Only-at-End Viewability via Confidentiality Middle = P e Middle - - { Midde - - - - - | End I :i Middle / cata | Middle )» w3 EM J L &= — s Middls} If the edges are secure, the security of the middle doesn’t matter. End only Viewability: one-data, one-where, one-time by one-body Zero-Trust-Computing Its much easier to protect one’s private keys than to protect all internet infrastructure
Confidentiality Overlay Dependency The encryption key state mapping can leverage the same persistent control mechanism as the signing key state mapping. Indeed, the encryption key state must be securely attributable to the intended identifier for confidentiality to work. In this strong sense, the confidentiality overlay depends on the authenticity overlay. Encryption Key State Confidentiality Overlay identifier «—~| identity system mapping <> key-pair 1 Secured By Recursive Controlling (Signing) Key State Authenticity Overlay { identifier «—~| identity system mapping |« | key-pair J
Confidentiality Overlay Elements Confidential Message Rossiced Pojo identer | cr‘phsr-dataj Strong Confidentiality Features: 3 party model: 1st party is sender, 2nd party is intended receiver, 3rd party unintended receiver 3rd party non-viewability 2nd party partition-ability by 1st party Detectable leakage (2nd party to 3rd party) Detectable collusion (2nd party to 2nd party) 15t party non-view-ability 15t party non-collude-ability by 2nd party (1st party to 1st party or 1st party to 3rd party)
Layering Confidentiality & Authenticatability Overlays [ RestictedPayioad | Verifiable Payload dst identifier | cipher-data sr identifier data
Setups matter! Order of layering is setup dependent, including the setups of any trusted intermediaries
The presence or absence (explicit vs. implicit) of src and dst identifiers in a message is setup dependent
The hard problem of setups for persistent identifiers is to avoid repeating non-scalable manual setups like OOBA in order to ensure persistent control (solved by pre-rotated provenanced key state on cryptographic root-of-trust)
] ™o () || s (D | i e ][ ] D
T T ] et e [
Confidentiality Overlay Example In the yard, Ned the neighbor, Bob the builder, and Cam the construction worker who is pushing a wheelbarrow. Ned whispered to Bob, the load is too heavy and then Bob said to Cam the load is too heavy. versus Ned said to Bob, the load is too heavy and then Bob said to Cam, | concur with what Ned said. versus Cam whispered to Bob, the load is too heavy and then Bob said to Cam the load is too heavy. versus Cam said to Bob, the load is too heavy and then Bob said nothing. Confidentiality enables a source of information to control the viewability of its information. Control over confidentiality requires that a source can securely partition information meant for a given destination from other potential destinations which may require some level of authentication of the given destination prior to sending the information (setup context).
Overlay: Trust Domain and Trust Basis An identifier system security overlay controls the authenticity, confidentiality, & privacy of an interaction through recursive application of authenticity, confidential and privacy overlays (expanded consolidating definition). Its trust basis binds controllers, identifiers, and key-pairs Its trust domain is the ecosystem of interactions that relies on its trust basis Each trust basis has one or more roots-of-trust A root-of-trust is some component or process of the system upon which other components or processes are reliant. It has trustworthy security properties that provide a foundation of trust for components of a system. A primary root-of-trust is irreplaceable A secondary root-of-trust is replaceable. The application of an identifier system security overlay is to map its trust basis to its trust domain of interactions
Overlay: Protocol Abstraction vs. Concrete Interaction Overlay as a protocol abstraction where protocol determines type of overlay
hence types of trust basis, trust domain, roots-of-trust, and interactions, ... VErISus ... Overlay as a concrete application of a specific identifier’s trust basis. Concrete instantiation of any of the abstract types is per identifier not per identifier type! Any interaction is concretized by a given message or set of messages wherein each message may involve multiple identifiers, each with a different controller and hence a different concrete trust basis. The type of a given trust basis determines the type of its trust domain. ‘What happens when a given concrete interaction as overlaid message(s) mixes identifiers from trust bases of different types and hence trust domains of different types? Is an ITDP even sensible in such a scenario?
Trust Domain Appraisability Trusted computing group uses the term appraisal to refer to the process of evaluating roots-of-trust for their security properties with regards the security policy of what is acceptable data secured by that root-of-trust (see also IETF RATS). Generalizing, an appraisable trust-basis of some party to an interaction can be evaluated by any other relying party to that interaction with respect to the relying party’s data acceptance policy. How difficult is the appraisal of a given trust basis? Some types of trust bases may have well-known easily appraisable characteristics that better facilitate trust transitivity in any given interaction relying on that trust basis versus other types of trust bases. Maximal trust transitivity happens in an interaction when the trust bases of all parties are mutually appraisable with the same degree of trustability and at relative low appraisal cost.
Types of Trust Bases vttt st ity hpan n e hth st bsesof ot re sl appraiabl with e same s of ey s oo o e s Should we be fostering interoperability in interactions between poorly appraisable trust bases that either hide the security weaknesses o it sty 10 s ot common et Analogy: Once non-repudiable digital signatures (using PKI) were invented, best practices deprecated HMACs for signing. it ot o t have ned sgreementwher o partes e gtal Sgnatures, ansome e HMACS? Administrative Algorithmic Autonomic DNS/CA Shared Distributed Ledger Cryptographically Verifiable . Duplicity Hiding. Duplicity Evident Opaque Non-monotonic (revisable) Monotonic (non-revisable) Impractically High Appraisal Cost Non-portable Portable Shared Control Non-Shared Control Algorithmic Strength Cryptographic Strength More or Less Zero Trust Fully Zero Trust Relatively high appraisal cost Relatively low appraisal cost
Zero-Trust Architecture: Data Protection Never Trust, Always Verify Perimeter-less Security Model (necessary but not sufficient) Zero-Trust Spectrum = ratio of trusted surface to verifiable surface Trade-space axes of verifiable trust are authenticity, confidentiality, privacy All protected data must have end-verifiable non-repudiable authenticity to its source (signing) All protected data may have end-only viewable confidentiality to its destination (encrypting) All protected data may have sufficient privacy amongst the parties to that data (correlating) Data is signed and/or encrypted both in motion and at rest (overlays should support both) at rest means the storage mechanism is a party to the conversation at rest is an attack surface that in motion can’t protect against party identifiers may be explicit or implicit w.r.t protected data
Self-ldentity Graph /7 777‘\, ] ) /m TN N4 ] P ) 1 o] e \ - T B / \ \ \ i CF/ 0V ND Nl N /o S e A "”'}/ R O T TN J | \ S A w5 ) REgS AA /A N X v \T/ \'1' J o e ) ) m { ’T‘ T ety = denifers s Axries \ ) N " J Lo u identifiers = cryptonyms + aliases ¥ < / N Attributes = data + proofs m m D [ ‘\,// [ bt et S —
vy [ by Arelationship s a paiingof two cryptonymos identifers, one each froma diferent A it o] | o] e | controllr S . relationships are not communicaton chanmels . TR T _ coyptonymis a cryptographicllyderved pseudonym with a et 128 bt of entropy n 0 o o]~ [ b | -5, the driation | contoler nwler | AID is a cryptonym thatis also securely attributable to a key pair o, [T (T | 67 o diferent ryptonyms are by themselves uncorrelaed nan information-theoretc H i o] | [0 ey e kKo o by ok s o famation ok o ot e M T % i contextisasetof events. Two contexts are disjoint with respect to a cryptonym when T 5]z teteyptonmappearsinen ormorc evens none set bu does not sppearinany event L 4,3% 0 B ntheotherser § E O & & 21 apartitionis aset of contexts with mutually disjoint relationships. ‘. %X K = partitioned contexts may be correlatable due to other information associated with a each H 1 Context butthe parttioned eltionships by hemselves provide no coreltable = e information.¢. patitioned reationships are b themselves ot corelatable [1H X AR 212 portitionedrelationships enable both secure attribution and secure confidentalty Iy \fi@ Sy 518 Aayptonym natis common toa comext provids aperect omelatabl featre within i @) %3 ¥ thatcontext I T nesecreottibuabity of an AID together with s perfec coreatabilty withn coniext T e o % enable secure reputational trust (good or bad) in that AID within that context / ot ‘ oty v Partitioned Relationships using, ORIs (One Relationship Identifiers) balance the concerns | oot 6.4 - 0, ot | ofstrang authenticit an sirong confidentilty witin context withsuffcienty strongs s o | o] | privacy across contexts.