QUEST FOR THE MNEMON SEED THE THREE R’S OF KEY MANAGEMENT: REPRODUCTION, ROTATION, AND RECOVERY DAD
(DECENTRALIZED AUTONOMIC DATA) DERIVED-DID Samuel M. Smith Ph.D.
Interet Identity Workshop 2018.04.04 sam.smith@consensys.net sam.smith@sovrin.org
Background
Decentralized Autonomic Data and the Three R’s of Key Management RWOT Spring 2018 https:flgithub.comWebOfTrustinfofrebooting the-web-of trust-spring2018/blob/master/final-documents] DecentralizedAutonormicDatamd Motivation Data streaming applications:
Analytics and instrumentation for distributed web, internet of
things (10T), or self-sovereign reputation systems. Maintain a provenance chain for data undergoing various processing stages that follows diffuse trust security principles including signed at rest and in motion.
DAD: Decentralized Autonomic Data Provenance for decentralized streaming data applications including transformations Decentralized: governance of the data may not reside with a single party, trust in the data provenance is diffuse, DID based.
Autonomic: self-managing or self-regulating. Self-managing includes cryptographic techniques for maintaining data provenance that make the data self-identifying, self- certifying, and self-securing.
Autonomic implies the use of cryptographic signatures to provide a root of trust
for data integrity and to maintain that trust over transformation of that data
Key management is thus first order property of DAD items.
Reproduction, Rotation, and Recovery
Pre-rotation & Hybrid recovery methods
DID and DDID DID = Decentralized Identifier https://w3c-ccg.github.io/did-spec/ did:method: idstring d1d:dad: X5YaaL L8P Fu7IURLOIRAU2_RFPOALA3YN1AB= d1d:dad: Xq5YaaL 6L4BpFOFu7IUNLOIRaU2_ RXFPOALA3YN1A8=:blue did: dad:XqsYaaL6LASpFOFu7 IURLOTRL2_RXFPOALAIWYALAR Puho-me DDO = DID Document, provides meta-data about DID DAD Streaming = Multiplicity of data items and associated identifiers DID/DDO pair per DAD item may not be practical DDID = Derived DID = Unique DID format identifier derived from one root DID/DDO that provides meta-data for a large number of DDIDs
Example Signed DAD { "id": “"did:dad:Xq5Yqal6L48pfefu7IUhL@IRaU2_RxFPOAL43WYN148=", "data": { "name": "John Smith", "nation": "USA" 1 } Ar\n\r\n u7239aKHgz99FeKBpSkMNyquVER_3rpS_z2034L99sTWrMIIIGQPbVUII1cupobcfIf_KCBSecVRYOFRZAPNAQ==
Minimally Sufficient Means Streaming data applications may impose significant performance demands on the processing of the associated data Desire efficient mechanisms for providing the autonomic properties of DADs Find minimally sufficient means for managing cryptographic integrity Key Reproduction, Rotation, and Recovery Representation and Processing
Reproduction Simple Privacy via unique cryptonym (DDID) per pair-wise interaction context More sophisticated methods such as zero knowledge proofs may not minimally sufficient DDIDS derived via some type of hierarchically deterministic algorithm allow for simple method to generated large numbers public DDIDS without having to store the associated private keys only the root private key did:dad:Xq5Yqal6L48pFefu7IUhLOIRAU2_RXFPOALA3WYN148=2chain=0\1\2 did:dad:Qt27fThWoNZsa88VrTkep6H-4HABE rS4sHONIVIWI6FE=
DDID Management DDID Database {
"did:dad:Qt27fThWoNZsa88VrTkep6H-4HABtr54sHONIVW16FE=": "did:dad:Xq5YqaL6L48pfefu7IUhL@IRaU2_RxFP@AL43wYn148=2chain=0\1\2", }
DDID NameSpacing
416: 620 :Xg5YaL 6L4BpFOFU7TURLOTRAU2_RXFPOALA3uYN148=: blue>chain=o/1 did:dad:Xq5YqaL6L48pfefu7IUhLeIRaU2_RXFPOAL43WYN148=: red?chain=0/1 DDID Sequencing did:dad:Qt27fThWoNZsa88VrTkep6H-4HABtr54SHON1VWL6FE=/10057
Change Detection Prevent replay attacks: sequence number in DDID changed field with monotonically increasing sequence number or date time [ "id": "did:dad:Qt27fThWoNZsa88VrTkep6H-4HABtr54sHON1VW1GFE=/10057", “changed” : "2000-01-01700:00:00+00:00" "data": [ “temp": 56, “time": "12:15:35" } ) Ar\n\r\n u7239aKHgz99FeK8pSkMnyquvEr_3rpS_z2034L99sTWrMIIIGQPbYUII1lcupo6cfIf_KCBSecVRYOFRZAPNAQ==
DDID Generation On the fly DDIDs: Data source is not identified so receiver generates DDID that is later correlated to or claimed by the data source Public Derivation: Client communicates with large number of public services DDID is derived from root private key and public service identifier Client does not need to store DDID but can re-derive on demand
Rotation Rotation = Revoke and Replace Revoke only = Revoke and replace with null key Replace only = security vulnerability In general revocation is special case of rotation
Why Rotate? Public key vulnerable to attack due to time exposure Continued use of private key increases vulnerability to exploit Challenge is rotation after suspected exploit, exposure, or capture of private key. Rotation operation that is signed by exploited private key is problematic. Seek minimally sufficient means. Using another key for rotation adds complexity and in a sense is just displacing the rotation problem without solving it.
Pre-Rotation Likelihood of exploit is a function of exposure to probing or continued monitoring. Narrowly restricting the the opportunity for exploit in time, place and method, such as, one time only, minimizes the vulnerability to exploit. Exploiter has to either predict the one-time event or has to continuously universally monitor all events. Create and declare the next “rotated” key (prerotated key) at the one-time only inception event for the original key. The private key of the pre-rotated key is then stored securely and is not exposed until a rotation event is needed. The rotation event is now another one-time event determined by the key owner Exploit of the original key cannot change the pre-rotated key or spoof a rotation event. Rotation is self-contained
Pre-Rotation Requirements Inception event is one-time only. Contains two public keys signed by original key. Rotation event contains three public keys. Original, Pre-rotated, next pre- rotated. Signed by original and pre-rotated. Private: pair-wise interaction requires recipient maintain log database of inception and rotation events. Can detect any replay attacks or attempts to spoof inception event. Public: redundant, immutable, persistent, time-stamped log database of rotation event history for a given original (inception) key on replicant servers
Inception Event { "507: "did:dad: Q27 FThNONZSaBaVT TkepSH- AL SASHONLVALGFE=" “Changed" : "2008-01-01100:00:00160:00" “ensuer™: "XqSYqaL6L48pfofu7IUNLOIRAVZ_RXFPOALA3MYN1d8-" } APt U72393KHE299 OKBpSKHnyaQuVEr_3rpS_22034L995THHLIIGQPbVULI1cupoSc Lf_KCBSECVRYOFRZAPIAG-= Rotation Event { 44" "dd:dad:QLZ7FThONZSaB8I TkepSH- A PSASHONLVAIGFE=" “changed" : "2000-01-01700:60:00+00:00", “erster™: "QL27FTHHONZSaB8Vr TkepSH- AHASLrSASHONIVHISFE=", “Signer™: "XqSVqaL6L48pf0fu7IUhLOIRAU2_RxFPOALAIWN145-" “ensuer: "dZ7AHLIXD- 10407 HSpREGrOAVKAF ZRTZNIKCOr aY=" I P JCaDAS Uy PGHFE K GVOBKD 0] 34UKZy TIYURGhoNY i REAGHS0287SHyUS-ULfa 1 1bTPURZVPTGI0A-= Ammrin CFTUApINCZ2 JgaCESELIIpAnay QOFAPHULHIG7UKQZ21 172ZPobYFVICEKCABMHOONATO - aJuGxIo2DA-=
Listed Pre-rotation Structure
Rotation Event { "id": "did:dad:Qt27¢THHONZSaB8Vr Tkep6H- GHABLTSASHONLVNIGFE=" , "changed" : "2000-01-01T00:00:00+60:00" , “signer”: 2, '[‘signsrs": "Qt27FThHONZS BBV Tkep6H-4HABLN5ASHONLVNIGFE=", "Xq5YqaL 6L48pFoFu7 IURLEIRAU2_RXFPOAL43WYn1aB=", “dZ74MLZXD~1QH0A73WIPQIGrOAVXGF 12RTZWLKCBraY=" “35yVH2woCpOVPFSDSZ0bU_OxNe2ZgxKjTQI6LL IMnA=" ] } Ar\n\rin AeYbSHOTOPMANACET 05 SDB1AUSQAFNHSUGWLTGPVNIQQOYKBYrPPXAOLC115SHC IDSBKFF FB10tDq8XG1zaCg== Arin\rin 09y JUKHHNIZF 10QDIK 6Vt 6 FPOXEXL 182 _4D-753CCYMUOHANGNVEYar_GHw_25CrHBAAZIAE SmL3thLmuseDW==
Multi-signature Pre-rotation
COSI Collective Signatures Typically the maximum length of a collective signature is about double the length of a non-collective signature and does not increase significantly as more signatures are added to the collective. Collective signatures are a type of Schnorr multi-signature or Schnorr threshold signature. Fork of LibSodium includes CoSI support for Ed255i9 signatures Draft IETF standard for collective signatures Cost https:/ftools.ietf.org/id/draft-ford-cfrg-cosi-00.html) https://github.com/dedis/cothority/wiki/CoSi https://arxiv.org/pdf/1503.08768.pdf http://dedis.cs.yale.edu/dissent/pres/160524-sp-cosi.pdf
DDID Pre-rotation See Paper
Recovery Human memory incompatible with long strings of random numbers. Humans ill equipped for task.
Recovery Methods
Physical
Shift memory burden from recalling key to recalling physical location of physical backup Shift exploit surface from network security to physical security
Good backup method ‘Mnemonic
Shift memory burden to domain that humans are good at Secret Sharing
shift recovery burden to third parties
Requires multi-party interactive infra-structure Hybrid
Minimally sufficient means
Cryptographic Security information-theoretic security: cryptosystem that cannot be broken algorithimically even if the adversary has nearly unlimited computing power including quantum computing. It must be broken by brute force if at all. Brute force means that in order to guarantee success the adversary must search every combination of key or seed. perfect security: special case of information-theoretic security where cipher text provides no information about the key
Practical Perfect Security
Secret Sharing or Secret Splitting:
Simple N of N
Threshold M of N One-time Pad:
Pad = string of random characters used to encode/decode message. Pad is as long as message.
Can be performed manually
Brute Force Cryptographic Strength Systems with perfect security the critically parameter is the number of bits of entropy needed to resist any brute force attack Entropy in bits per Shannon information theory number of bits = log,(number of random possibilities)
Convention is that 128 bits is sufficient =228 possibilities or random choices 1 million super computers each performing 1 quadrillion trials per second will take 8,589,934,592 years for brute force exploit