Security Architectures Issues Zero-Trust Trust Domains Roots-of-trust models: EUID ARF 1.4 and KERI & RERI
670} https://keri.one https://github.com/WebOfTrust Samuel M. Smith Ph.D. sam@keri.one
Resources Documentation: ‘https://keri.onefkeri-resources/ KERI/ACDC Community: (meetings, open source code Apache2, specification drafts) https://github.com/WebOfTrust/keri TolP: (meetings, specifications OWF License) https:/ftrustoverip.org| https:/jwiki.trustoverip.org/display/HOME/ACDC+(Authentic+Chained+Data+Container)s Task+ Force https:/jwiki.trustoverip.org/display/HOME/Trust+Spanning+Protocol+Task+Force GLEIF: https:/jwww.gleif.orglen/lei-solutions/gleifs-digital strategy-for-the-lei/introducing-the-verifiable-lei-vlei healthKERI: https:/fhealthkeri.com/ ) ~ TRUST ) " h | hl :RI A KERI & WEE B @orecrusr hgalthK=
Armor Preventing wounds especially fatal wounds (B 0y .l ¥, Jrl bk g R\ 7 - B a2 P AL ;K I “\’A'fi” =Y> s Bl o By A<y J P i ~ g&. 2 s % ‘V i ,; i o flL{ Tf ' (31 e )T ‘ S ; I§ ll ) { H I i i A g Each component protects a vital area from injury. Remove even one component and the adversary will target that area to the exclusion of all else.
Hard Problems & Solutions Moving Data Across Trust Domains. Trust Spanning Protocol (TSP)(SPAC) No Shared Secrets Authentic Chained Data Container (ACDC) No passwords Key Event Receipt Infrastructure (KERI) No shared encryption keys Composable Event Streaming Representation (CESR) No bearer tokens GLEIF vLEI No shared private keys Key Management (rotation) True Zero-Trust = Sign Everything Global Portability At-Scale it micire it s Pl oo s o 8 - O 8 - O 8 - O 8
Universal Secure Attribution Problem Establish authorship of data, documents, credentials, entitlements, ... = Verifiable secure attribution of any communication to its source = Authentic data provenance by anyone to anyone from anyone Solve data provenance to solve security [ controlling key(s) ‘ —— secure [ identifier ]fl authorship D e — attribution
Identity (-ifier) System Security Overlay Establish authenticity of IP packet’s message payload. o Authenticatable Message Verifiable Payload {identmer }- { identiy system mapping |+ - key-pair \ The overlay’s security is contingent on the mapping’s security.
Trust Basis of a Trust Domain | controller 4 \/ wucu;)!—l'uh . bindng 19€NGY g \ system ’ ¥ :cet:‘gtyy \/\ \ | validator [ Key-pair |« binding ——~| identifier |
Administrative Trust Basis DNS/CA, OIDC IP | controller | generates N/ sourceofuh |
/ database
stong .
binding — h
/ assigns. manages validator key-pair | | identifier | administrator | root-of-trust in non-verifiable operational infrastructure with opaque governance
Algorithmic Trust Basis Shared distributed ledgers
_ controller |,
£ N registers source-oHtruth generates / \ ] shared ledger |+
\ / v e veifies ~ strong N strong A \
binding “e'l“es binding . \ . / registers \ manages _ validator |
| keypair — :‘:‘;‘""%7% identifier | algorithm | root-of-trust in verifiable operational infrastructure with shared governance
Autonomic Trust Basis Cryptographic proofs via verifiable data structures N manages _ 1 controller | ~ N prows source-of-tuth generales /‘ ‘\ | key eventlog |*~ Y 4 veriies strong strong \ binding cerives binding N & B / o \ B validator | Key-pair |« 5209 ——=| identiier root-of-trust in verifiable cryptographic proofs of infrastructure with no shared governance
The Internet Protocol (IP) is bro-ken because it has no security (trust) layer. o Pre Agplication Application = | TR u0p Instead ... We use bolt-on identity system security overlays. (DNS-CA...)
Spanning Layer (Gwors) (Four) (50 ) e AT \ s / T (RSP, (@) o)\ / Tungenrd | \ HTPETP SR>/ [ ) (7] [ (W) VAT S D & N\ Pyl g s achivergvebooso sotsshimnn i otecurer rcrapesion
Solution: Waist and Neck - NN =" = - _ e P _ /et | s — HITP FIP SMTPRTP — ‘ I N / Now ' .’:;"
Organizational Identity Zero-trust architecture Autonomic (cryptographic) decentralized root-of-trust (per organization) Protocol not Platform Delegable Authority Multi-sig DPKI Authentic Chained Data Containers
The Legal Entity Identifier - the LEI e Legal Entity Identifier - the B 4 = The LEl is a life-long code owned by the respective legal entity. = It points to the associated eson reference data. R « The LEl is an ISO standard S 2 1S0 17442 =l -
The LEl as a Verifiable Credential — the vLEI Trust Chain SLE + Every verifiable LEI (VLEI) is created by an issuer * The issuer cryptographically signs the GLEIF credential with its private key « An issuer is the organization or entity L' Qualified vLEI Issuers that asserts information about a L. subject to which a credential is issued Legal Entities « The vLEI Issuer is an organization L . qualified by GLEIF as part of a trusted Persons Representing network of partners Legal Entities + GLEIF issues vLEls to Qualified vLEI Issuers as attestation of trust. + GLEIF s the Root of Trust
PKI Then and Now
Who uses a password manager?
Who uses an authenticator app?
Who uses password-less login? Then: Managing private keys impossible for users, federated identity. Now: Mobile Devices with MFA & secure boot, password-less login. Then: Weak Crypto Now: Strong crypto: ECC signing & ECC asymmetric encryption. Then: Perimeter security, no persistence of control over identifiers. Now: decentralized zero-trust architecture for identity (KERI).
Flaw of PKI (DNS/CA) controlling key(s) | identifier “*m;‘" — data Conventional PKI uses signed assertions (x509 certs) made by trusted entities to bind key state (public, private) key pairs to identifiers. Use of private keys for either signing or decryption exposes them to side-channel attack. Over-time, exposure makes private keys weak. Thus, from time-to-time one must therefore revoke and replace, i.e. rotate the controlling private keys for a given identifier Conventional PKI must re-establish the root-of-trust with each rotation thereby making it vulnerable to attack This breaks the chain-of-trust-of-control over the identifier
What is KERI? (Key Event Receipt Infrastructure) Decentralized Key Management Infrastructure (DKMI) Decentralized Public Key Infrastructure (DPKI) KERI fixes the security flaw (authenticity) in PKI (Public Key Infrastructure): That flaw is key rotation. In conventional PKI there is no cryptographic binding between one set of keys and the next. KERI solves the key rotation problem for control over an identifier via pre-rotation which binds the next key-state to the prior key-state. With KERI, key state is cryptographically verifiably bound to a class of self-certifying identifiers that use portable verifiable data structures called key event logs (KELS) to provide duplicity evident proof of the controlling key state. With KERI every statement associated with a KERI identifier may be non-repudiably and securely attributed to the controller of the identifier via a signature made with keys given by cryptographically verifiable key state. KERI solves the secure attribution problem with zero trust.
End Verifiability End-to-End Verifiability o Middie »_ data data ) »; ~ Migde [ Middle = ) ~ data — data data o - ., ” N N End L 4 Middle ‘s data ——~ Middle » ——taia— 3 End data k) g - L] / * data data ~of Middie — S piddle - 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 It’s much easier to protect one’s private keys than to protect everyone else’s internet infrastructure
Zero-Trust Architectures & Computing
Never trust, always verify. Perimeter-less security model. Data is signed and/or encrypted both in motion and at rest. No such thing as true zero-trust. All architectures lie on the zero-trust spectrum given by:
the ratio of trusted surface to verifiable surface. End goal = all data has end-to-end verifiable authenticity (provenance)
Identity (-ifier) System Security Overlay \ identifier )« >\\demity system mapping J key-pair ) persistent mapping via verifiable data structure of key state changes Establish authenticity of IP packet’s message payload. Message Authenticatible Message Verifiable Payload — Key State Proof| identifier data signature N The overlay’s security is contingent on the mapping’s security.
Key State Proof is Recursive Application of Overlay i identifier ]< = identity system mapping < >: key-pair \ Persistent mapping via verifiable data structure of key state changes Key State Proof Authenticatible Message Verifiable Payload - - \ identifier | key state data signature Authenticatible Message Verifiable Payload
Autonomic Identifiers (AIDs): (type of self-certifying identifier) Issuance and Binding entropy i B captures. controller | . p P controler L\ e sirong | i / \ \emes - / identity . y e/ \ ™ oysar | S gonter pa _ S ey < L J [ key-pair "™ S [ entifer \ =L / [ KEYPAIr |/ anages | 1dentfer N p < \ [ strong strong | 4 | \ g o N o y key event log | [key event log autonomic, self-managing Autonomic Identifier Issuance Tetrad cryptographic root-of-trust with verifiable persistent control
Cryptographic Root-of-Trust: Self-Certifying Identifier (SCID) + Key Event Log = Autonomic Identifier (AID) D -, . s - own oy - Gaesen - ke ¢ | oo —, $ 41| e oot > s Pty > Goewn | Pty S o ¥ Do | bcsentigst. + o St S P Green Py | e Gt Key Event Log Incepion Satement Exabishme Inception Data Subsequence Derivation | Public Keys | Configuraton | Signatures ncepton Event | Rotation Event Rotation Event | Rotation Event EXq5YqaLeL4BpEOfuTIURLOTRAT2 RXFROAL43uYn148 did:un:EXq5YqaLéL48pLOfuTIUNLOIRAUZ RxFPOALA3WYn148/path/to/ resource Jname=securefreally