Security Concerns 2020/01/14. Discussion W3C DID WG Samuel M. Smith Ph.D. https://github.com/SmithSamuelM/Papers sam@samuelsmith.org
Background References
———
hitps:fipdos.csail.mit.edu/~kaminskylsfs http.ps
http:lfvww.sigops.orglew historyhaaslpapersimazieres.ps
httpsi/jpdos.csail.mit.edu/~ericp/docsfs thesis.ps Smith, 5. M., “Key Event Receipt Infrastructure (KERI) Design and Build”, arXiv, 2019/07/03
vl s Laurie, B., “Certificate Transparency: Public, verifieable, append-only logs,” ACMQueue, vol. Vol 12, Issue 9, 2014/09/08
https:/jqueue.acm.org/detail.cfm?id=2668154
‘hitp:/fwww.certificate-transparency.org/home
Identifier Authority Must First Establish Control Authority over an Identifier URI URL = scheme: [//authority]path[?query] [#fragment] authority = [userinfo@lhost[:port] DID "did:" method-name ":" method-specific-id Use Public/Private Key Pair (Certificate) to Verify Control Authority over an Identifier DNS Certificate Authority Infrastructure DID Method Authority Infrastructure
Identifier Authority Infrastructure DNS Certificate Authority Infrastructure DID Method Authority Infrastructure Multiple Certificate Providers Multiple Method Providers Common Standard Protocol Method Specific Protocols Trust Infrastructure of Each Provider Trust Infrastructure of Each Provider Secure Code Delivery Distributed Ledger Infrastructure of Common Standard Libraries Trust DID Resolver Infrastructure Simple implementation Method Specific Code In Resolver Secure Code Delivery of Multiple Method Specific Libraries Complex implementation
Different Validation Vulnerability Spaces
Trust on intervening infrastructure Zero-trust on intervening infrastructure Secure remote code execution End-verifiable attestations (logs)
Trusted execution environment Secure local code execution
Distributed consensus ledger End user may verify via crypto signatures Enduser may verify Integrity and source-of-truth of attestations OS code integrity Application code integrity
Certificate Transparency Problem
“The solution the computer world has relied on for many years is to introduce into the system trusted third parties (CAs) that vouch for the binding between the domain name and the private key. The problem is that we've managed to bless several hundred of these supposedly trusted parties, any of which can vouch for any domain name. Every now and then, one of them gets it wrong, sometimes spectacularly.”
Pinning inadequate
Notaries inadequate
DNSSec inadequate
All require trust in 3rd party compute infrastructure that is inherently vulnerable
Certificate Transparency: (related EFF SSL Observatory)
Public end-verifiable append-only event log with consistency and inclusion proofs
End-verifiable duplicity detection = Ambient verifiability of duplicity
Event log is third party infrastructure but it is not trusted because it is verifiable.
Sparse Merkle Trees for revocation of certificates
Certificate Transparency Solution Public end-verifiable append-only event log with consistency and inclusion proofs End-verifiable duplicity detection = ambient verifiability of duplicity Event log is third party infrastructure but it is not trusted because logs are verifiable. Sparse Merkle trees for revocation of certificates (related EFF SSL Observatory) e — LR . - . @ o Gl . | e -[@) o] gBEE 5840 2 [ gy $099Sues sosssuoe /! /.\ ! /'\ !’ Gssssugs sssedese Leat hasn -’ - ’ F ! ! ! !! .J s s . L LL ' TTTE Fgure 1 Figure 2
End-Verifiable Consistent Event Logs for DIDs KERI & Sidetree First seen wins Ambient duplicity detection
Decentralized Control Authority Asymmetric PKI: Public-Private Key Pairs for Digital Signatures CSPRNG Cryptographic Strength Pseudo Random Number Generator Collision Resistant Random Seed (Entropy) Available to Anyone Seed -> Private Key -> One Way Function -> Public Key Authority comes from collision resistance (entropy) Controller of private key is the only one who can make verifiable signed attestations associated with the public key (identifier) Inherently decentralized via singular sovereignty over random seed
Derived Self-Certifying Content Addressable Identifiers Content Hash:
Seed -> Private Key -> One-way Function (sign scheme) -> Public Key -> +Content -> One- way Function (hash scheme) -> Derived Identifier
Seed -> Private Key -> One-way Function (sign scheme) -> Public Key -> [ +Content -> One- way Function (hash scheme) -> Derived Identifier ...
Security Concepts Roots-of-Trust (primary and secondary) Sources-of-Truth Loci-of-Control
“BEST” DECENTRALIZED SECURITY End Verifiability Ambient Verifiability = Anyone can verify, anywhere, at any time. Ambient Duplicity Detection = Consistent Attribution
EXPLOIT MANAGEMENT Control exploit always eventually exhibits as duplicitous behavior: i.e. inconsistent control statements Duplicity detection provides exploit detection and containment. Duplicity detection via immutable logs of control statements is scalable and performant End verifiability removes trust on intervening infra-structure Control exploit potential mitigated via best practices for key management
Cryptographic Root-of-Trust Trust who said it not what was said Consistent attribution is the root-of-trust (integral non-repudiable statements) Duplicity detection I trust that controller of private key made a set of statements Build trust in what was said via consistently attributable (who) histories of consistent statements (what). (i.e. reputation)
Loci-of-Control Who controls What Control over Identifier Control over Operations on Identifier Control over Support Infrastructure to establish and maintain control over identifier
Source-of-Truth The Controller is the source-of-truth for control over the Identifier Only the the controller my make verifiably authoritative control statements: Sequencing (of authoritative statements) Dependency (of authoritative statements) Authoritative Statements: Transfer of control (non-revokable) Delegation of control (revokable) Authorizations: Additional roots-of-trust and sources-of-truth
Autonomic Identifier Unified Sovereignty (control) over Root-of-trust Source-of-truth Loci-of-control
Identifier Features Ephemeral (Non-Rotatable) vs. Persistent (Rotatable) Public vs Private Offline vs Online Establishment
Control Establishment Hierarchy
Background
AUTONOMIC IDENTIFIER (AID) AND AUTONOMIC NAMESPACE (AN) auto nomos self rule (autonomic, autonomous) Self-Governing, Self-Sovereign, Self-Controlling Self-Certifying,Self-Authorizing, Self-Managing, Self-Administering Cryptographically Verifiable Identifier Derivation Prefixed with AID
Related Works
Smith, S. M., “Key Event Receipt Infrastructure (KERI) Design and Build”, arXiv, 2019/07/03. https://arxiv.org/abs/1907.02143
Smith, S. M., “Open Reputation Framework,” vol. Version 1.2, 2015/05/13. https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/open-reputation-low-level-whitepaper.pdf
Smith, S. M. and Khovratovich, D., “Identity System Essentials,” 2016/03/29 https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/Identity-System-Essentials.pdf
Smith, S. M., “Decentralized Autonomic Data (DAD) and the three R’s of Key Management,” Rebooting the Web of
Trust RWOT 6, Spring 2018 https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/DecentralizedAutonomicData.pdf
Conway, S., Hughes, A., Ma, M. et al., “A DID for Everything,” Rebooting the Web of Trust RWOT 7, 2018/09/26 https://github,com/SmithSamuelM/Papers/blob/master/whitepapers/A_DID_for_everything.pdf
Shae, M., Smith, S. M. and Stocker, C., “Decentralized Identity as a Meta-platform: How Cooperation Beats
Aggregation,” Rebooting the Web of Trust, vol. RWOT 9, 2019/11/19 https:/lgithub.com/SmithSamuelM/Papers/blob/master/whitepapers/CooperationBeatsAggregation.pdf
Self-Certifying Identifier/Namespace
Decentralized Cryptographic Root-of-Trust Use public key in identifier or as prefix in namespace Signed statements that include self-certifying identifier Self-Certifying namespace End Verifiable to Primary Root-of-Trust Other roots of trust may add to but not replace self-certification All decentralized infrastructure has self-certifying identifiers as primary root-of-trust Decentralized key management is therefore essential to protecting infrastructure Enables provenanced chain of transformations with verifiable control over transformations. Authoritative control via signing not encryption keys.
Human Basis of Trust I know you or I know of you therefore I trust you On the internet | can’t really know who you are. therefore | can’t trust you
KEY MANAGEMENT Rotation = Revoke and Replace = Full Transfer of Control Reproduction = Creation, Derivation Recovery