decentralized public key infrastructure - danube tech · the answer is not to abandon pki, but to...
TRANSCRIPT
DecentralizedPublicKeyInfrastructureAWhitePaperfromRebootingtheWebofTrust
by(alphabeticalbylastname)ChristopherAllen,ArthurBrock,VitalikButerin,JonCallas,DukeDorje,ChristianLundkvist,PavelKravchenko,JudeNelson,Drummond
Reed,MarkusSabadello,GregSlepak,NoahThorp,andHarlanTWood
Abstract
Today’sInternetplacescontrolofonlineidentitiesintothehandsofthird-parties.Emailaddresses,usernames,andwebsitedomainsareborrowedor"rented"throughDNS,X.509,andsocialnetworks.ThisresultsinsevereusabilityandsecuritychallengesInternet-wide.Thispaperdescribesapossiblealternateapproachcalleddecentralizedpublickeyinfrastructure(DPKI),whichreturnscontrolofonlineidentitiestotheentitiestheybelongto.Bydoingso,DPKIaddressesmanyusabilityandsecuritychallengesthatplaguetraditionalpublickeyinfrastructure(PKI).DPKIhasadvantagesateachstageofthePKIlifecycle.ItmakespermissionlessbootstrappingofonlineidentitiespossibleandprovidesforthesimplecreationofstrongerSSLcertificates.Inusage,itcanhelp“Johnny”tofinallyencryptthankstoitsrelegationofpublickeymanagementtosecuredecentralizeddatastores.Finally,itincludesmechanismstorecoverlostorcompromisedidentifiers.
DPKI v1.0.0, 12/23/15 Page 2
1.Introduction—WhyDPKI
SectionContributorsAlphabeticalByLastName:ChristopherAllen,ChristianLundkvist,JudeNelson,DrummondReed,MarkusSabadello,andGregSlepak
TheInternetfacilitatescommunicationsandtransactionsbetweenindividualsworldwide.Thisisconductedthroughtheuseofidentifierssuchasemailaddresses,domains,andusernames.Butwhocontrolstheseidentifiers?Howaretheymanaged?Andhowissecurecommunicationfacilitatedbetweenthem?
Inthemodernday,third-partiessuchasDNSregistrars,ICANN,X.509CertificateAuthorities(CAs),andsocialmediacompaniesareresponsibleforthecreationandmanagementofonlineidentifiersandthesecurecommunicationbetweenthem.Unfortunately,thisdesignhasdemonstratedserioususabilityandsecurityshortcomings.
1.1TheControl&ManagementofOnlineIdentifiers
WhenDNSandX.509PKIXweredesigned,theInternetdidnothaveawaytoagreeuponthestateofaregistry(ordatabase)inareliableanddecentralizedmanner.Therefore,thesesystemsdesignatedtrustedthird-partiestomanageidentifiersandpublickeys.VirtuallyallInternetsoftwarenowreliesontheseauthorities.Becauseofthis,websitedomainsdonotreallybelongtotheorganizationsthatregisterthem(NOTE:Instead,theybelongtothirdpartieslikeICANN,domainregistrars,CertificateAuthorities,andanyonecapableofinfluencing,coercing,orhackingintothem.)and,similarly,usernamesonwebsitesdonotreallybelongtothoseusers.
Thesetrustedthird-parties(sometimesabbreviatedTTP),actascorruptiblecentralpointsoffailure,eachcapableofcompromisingtheintegrityandsecurityoftheentireInternet.BecausecontroloftheseidentifiersisgiventoTTPs,theusabilityofthoseidentifiersisalsocompromised.Theseissueswithcorruptibilityandusabilitycauseadditionalproblems:
• SomecompaniesspendsignificantresourcesfightingsecuritybreachescausedbymisbehavingCAs;
• ManywebsitesstilldonotsupportHTTPS;
• Trulysecureanduserfriendlycommunicationstillremainsoutofreachofformostnetizens.[ref:"WhyJohnnyCan’tEncrypt"http://arxiv.org/abs/1510.08555]
Forallthesereasons,thefoundationalpreceptofDPKIisthatidentitiesbelongtotheentitiestheyrepresent.Thatrequiresdesigningadecentralizedinfrastructurewhereeveryidentityiscontrollednotbyatrustedthird-party,butbyitsprincipalowner.
DPKI v1.0.0, 12/23/15 Page 3
1.2TheSecurityofOnlineCommunication
Onlinecommunicationsaresecuredthroughthesafedeliveryofpublickeys.Thesekeyscorrespondtoidentities.Theentitytheseidentitiesrepresent,calledtheprincipal,usesacorrespondingsecretprivatekeytobothdecryptmessagessenttothem,andtoprovetheysentamessage(bysigningitwiththeprivatekey).
PKIsystemsareresponsibleforthesecuredeliveryofpublickeys.However,thecommonlyusedX.509PKI,PKIX,underminesboththecreationandthesecuredeliveryofthesekeys.
1.2.1TheChallengesofThirdParties:Finding"TheRightKey"
InX.509PKIX,webservicesaresecuredthroughthecreationofthekeyssignedbyCAs.However,thecomplexityofgeneratingandmanagingkeysandcertificatesinPKIXhascausedwebhostingcompaniestomanagethecreationandsigningofthesekeysthemselves,ratherthanleavingittotheirclients.Thiscreatesmajorsecurityconcernsfromtheoutset,asitresultsintheaccumulationofprivatekeysatacentralpointoffailure(thewebhostingcompany),makingitpossibleforanyonewithaccesstothatrepositoryofkeystocompromisethesecurityoftheconnectionstothosewebsitesinawaythatisvirtuallyundetectable.
ThedesignofX.509PKIXalsopermitsanyof~1200CAsaroundtheworldtoimpersonateanywebsite.ThisisfurthercomplicatedbytheriskofcoercionorcompromiseofaCA.Becauseofthesedangers,userscannotbecertainthattheircommunicationsarenotbeingcompromisedbyafraudulentcertificateallowingaMITM(Man-in-the-Middle)attack.Theseattacksareextremelydifficulttodetect;companieslikeGooglethatproducewebbrowserscansometimesrecognizeattacksontheirownwebsites,buttheycannotpreventattacksonarbitrarywebsites.
DPKI v1.0.0, 12/23/15 Page 4
Workaroundshavebeenproposed.HPKPisanIETFstandardthatletswebsitestellvisitorsto"pin"thepublickeytheyreceiveforaperiodoftime(ignoringanyotherkey).However,suchmechanismsaredifficultforwebsiteadministratorstouseandthereforemightnotbeusedmuchinpractice.HPKPisvulnerableto“HostilePinning”,andincaseswherethepinislegitimateitcomeswithariskofbreakingwebsitesifkey(s)needtobelegitimatelyreplaced.Worsestill,someimplementationsofHPKPmakeittrivialforathird-partytooverridearbitrarypinswithoutuserconsent.
1.3TheUsabilityofPKI
Evenifthird-partyauthoritiescouldbetrusted,thecurrentPKIsystemhasmajorusabilityproblems.AgroupfromBrighamYoungUniversityinvestigatedtheusabilityofMailvelope,abrowserextensionthatsupportsGPG-encryptedcommunicationthroughthird-partywebsiteslikeGmail.Theirresearchdemonstrateda90%failurerateinsecurecommunicationattemptsamongtheparticipants.Publickeymanagement,thestudyfound,wasthemainreasonthatuserswereunabletousethesoftwarecorrectly.
EvenTextSecure/Signal—asecuremessagingsystemendorsedbyEdwardSnowdenforitssecurityandeaseofuse—hasusabilityproblemsduetoitsinabilitytosmoothlyhandlepublickeychanges.Ifauserdeletesandreinstallstheapp,theirfriendsarewarnedthattheirpublickey"fingerprint"haschanged.ThisscenarioisindistinguishablefromaMITMattack,andfewusersarelikelytounderstandorbotherverifyingthattheyreceivedthecorrectpublickey.
1.3.1TheDangerofMessageCompromise
AsaresultofconventionalPKI’susabilitychallenges,muchofWebtraffictodayisunsignedandunencrypted.Thisisparticularlyevidentonthemajorsocialnetworks.BecauseofPKI’scomplexity,socialnetworksdonotencrypttheiruser’scommunicationsinanyway,otherthanrelyingonPKIXbysendingthemoverHTTPS.Becausemessagesarenotsigned,thereisnowaytobesurethatauserreallysaidwhattheysaid,orwhetherthetextdisplayedistheresultofadatabasecompromise.Similarly,usercommunicationisstoredinamannerthatanyonewithaccesstothosedatabasescanread—compromisinguserprivacyandburdeningsocialnetworkswithlargeliabilityrisks.
DPKI v1.0.0, 12/23/15 Page 5
2.DPKI’sAnswerToTheWeb’sTrustProblems
SectionContributorsAlphabeticalByLastName:DrummondReed,andGregSlepak
TheanswerisnottoabandonPKI,buttofindanalternative:DPKI,afuturespecificationforadecentralizedpublic-keyinfrastructure.
ThegoalofDPKIistoensurethat,unlikePKIX,nosinglethird-partycancompromisetheintegrityandsecurityofthesystemasaswhole.Trustisdecentralizedthroughtheuseoftechnologiesthatmakeitpossibleforgeographicallyandpoliticallydisparateentitiestoreachconsensusonthestateofashareddatabase.DPKIfocusesprimarilyondecentralizedkey-valuedatastores,calledblockchains,butitisperfectlycapableofsupportingothertechnologiesthatprovidesimilarorsuperiorsecurityproperties.
Third-parties,whoarecalledminers(orvalidators),stillexist,buttheirroleislimitedtoensuringthesecurityandintegrityoftheblockchain(ordecentralizedledger).Thesethird-partiesarefinanciallyincentivizedbyaconsensusprotocoltofollowtherulesoftheprotocol.Deviationfromtheprotocolresultsinfinancialpunishment,whileconsistencywiththeprotocoltypicallyresultsinfinancialreward.Bitcoin,devisedbySatoshiNakamoto,isthefirstsuchsuccessfulprotocol.Itisbasedonproof-of-work,inwhichtheenergyexpenditureof"miners"isusedtosecurethedatabase.
Aprincipalcanbegivendirectcontrolandownershipofagloballyreadableidentifierlikeawebsitedomainbyregisteringtheidentifierinablockchain,justlikeanyothertypeoftransaction.Withinthekey-valuedatastore(NOTE:Inthiscase"key"referstoadatabaselookupstring,notapublicorprivatekey.),theprincipalusestheidentifierasthelookupkey.
Simultaneously,blockchainsallowfortheassignmentofarbitrarydatasuchaspublickeystotheseidentifiersandpermitthosevaluestobegloballyreadableinasecuremannerthatisnotvulnerabletotheMITMattacksthatarepossibleinPKIX.Thisisdonebylinkinganidentifier’slookupvaluetothelatestandmostcorrectpublickeysforthatidentifier.
Inthisdesign,controlofovertheidentifierisreturnedtotheprincipal.Nolongerisittrivialforanyoneentitytounderminethesecurityoftheentiresystemortocompromiseanidentifierthatisnottheirs.ThisishowDPKIisabletoaddressboththesecurityandtheusabilityproblemsthatplagueDNSandX.509PKIX.
Acompletedescriptionofblockchainsandtheirconsensusprotocolsisbeyondthescopeofthispaper.However,§5,"SecurityofIdentifiersandPublic-Keys",discussessomeoftheirsecuritypropertiesandtheAppendix“ThinClientDetails”describeshowthedataintheseblockchainscanbesecurelyaccessedfrommobiledevicesthatdonotthemselveshaveafullcopyoftheblockchain.
DPKI v1.0.0, 12/23/15 Page 6
3.DPKI’sThreatModel
SectionContributorsAlphabeticalByLastName:JudeNelson
LikeconventionalPKIsystems,DPKIassumesthatapersistentactiveadversaryMalconstantlytriestotrickoneprincipalAliceintotrustingthewrongkeyforanotherprincipalBob.ThiscantaketheformofdiscoveringthewrongidentifierforBob(e.g.,findingthewrongaccountattwitter.com)orcachingthewrongkeyoncetheidentifierisknown.
AssumethatMalisacomputationally-boundedadversarywhoiscapableofcompromisingorcompellingcentralizedtrustedPKIpartiestotrickAliceintotrustingthewrongkey.Thishasalreadybeenprovenfeasible,asinthecaseofDigiNotarandincaseswhereinstateactorsforceCAsintheirjurisdictionstosigninvalidkeys.Inaddition,assumethatMaliscapableofalteringorblockingaboundfraction(lessthan100%)ofthemessagesexchangedbetweenAliceandBob.Thisisalsofeasibletoday,andisevidencedbyISP-levelcensorship,byrequestredirection,andbypacket-manglingattacks,whichareexecutedinordertodisruptexistingfile-sharingtechnologieslikeBitTorrent,toblack-holepacketsfromknownTorexitnodes,andtoblockHTTPaccesstopolitically-sensitivematerials.
InlightofMal’spowers,twodesignprinciplesforDPKIbecomeapparent:
1. Ashasalreadybeensuggested,eachprincipalmustbeincompletecontroloftheircurrentidentifier/public-keybinding.Ifonlytheprincipalcanmakechangestotheiridentifier,thenMaliscompelledtoattackeachprincipalshewishestocompromise.ThisisincontrasttotraditionalPKI,whereMalonlyneedstocompromiseoneCAtotrickmanyprincipals.
2. Thesystemmustmakeall-or-nothingforwardprogress:eithereveryprincipalmustwitnesseveryotherprincipal’supdatestotheiridentifier/public-keybindings,orelsenoonemayobserveanyupdates.ThisisrequiredtoprotectagainstMal’spossiblenetwork-levelattacksbyalertingtheentirenetworktoherpresenceifshecensorsupdatestocertainprincipals.Thismakestargetedattacksagainstcertainusersorkey-pairsextremelycostly,becauseitensuresthattheonlywayMalcanattackanyoneistoattackeveryoneatonce.
Asalreadysuggested,DPKIachievesthesedesignprinciplesthroughuseofsecuredecentralizedkey-valuedatastorestohostthebindingsbetweenidentifiersandpublic-keyhashes.See§5,"SecurityofIdentifiersandPublic-Keys"fordetails.
DPKI v1.0.0, 12/23/15 Page 7
4.RegistrationandIdentifiers
SectionContributorsAlphabeticalByLastName:ChristopherAllen,ChristianLundkvist,JudeNelson,DrummondReed,MarkusSabadello,GregSlepak
Asdescribedintheprevioussections,thecoreofDPKIaredecentralizedkey-valuedatastoresthatcanserveasidentifierregistries,allowingaprincipal’spublickeystobecomesecurelyassociatedwiththeiridentifier.Aslongasthisregistrationremainsvalidandtheprincipalisabletomaintaincontroloftheirprivatekey,nothird-partycantakeownershipofthatidentifierwithoutresortingtodirectcoercionoftheprincipal.
DPKIdoesnotspecifywhattypesofidentifiersshouldbeusedandrecognizesthatdifferentapproachesarepossible(e.g.,usernamesorUUIDs),whichmaydifferintermsofease-of-use,permanence,uniqueness,security,andotherproperties.
ForDPKItouseadecentralizedkey-valuestoreitmusthavethefollowingproperties:
• PermissionlessWrites.Anyprincipalcanbroadcastamessageprovidedthatitiswell-formed.Otherpeersinthesystemdonotrequireadmissioncontrol.Thisimpliesadecentralizedconsensusmechanism.
• ForkChoiceRule.Giventwohistoriesofupdates,anyprincipalcandeterminewhichoneisthe"mostsecure"throughinspection.
TheseneedscanbemetthroughblockchainssuchasNamecoin,Ethereum,andpotentiallyevenBitcoin(throughtechnologiessuchasBlockstore).
4.1TheRequirementsofDPKIRegistration
ThewayidentifierregistrationishandledinDPKIisdifferentfromDNS.AlthoughregistrarsmayexistinDPKI,theymustadheretoseveralrequirementsbornoutofDPKI’sgoaltoensurethatidentitiesbelongtotheentitiestheyrepresent:
1. Privatekeysmustbegeneratedinadecentralizedmannerthatensurestheyremainundertheprincipal’scontrol(e.g.,viaopensourceclientsoftwareontheprincipal’sdevice).Thismeansthatregistrationservicesgeneratingkeypairsonaserveronbehalfofprincipalsareexplicitlyprohibited.Todootherwisewouldbetorecreatetheissuesmentionedin§1"Introduction—WhyDPKI".
2. Softwaremustensurethatprincipalsarealwaysincontroloftheiridentifiersandthecorrespondingkeys.Principalscanextendcontroloftheiridentifiertothird-parties(e.g.,forrecoverypurposes),butthismustalwaysbeanexplicit,informeddecisionontheirpart,andneveradefault,implicit,ormisleadingbehaviorofsoftware.Privatekeysmustneverbestoredortransmittedinaninsecuremanner.
DPKI v1.0.0, 12/23/15 Page 8
3. Softwaremustensure,togreatestdegreepossible,thatnomechanismexiststhatwouldallowasingleentitytodepriveaprincipaloftheiridentifierwithouttheirconsent.Thisimplies:
i. Onceanamespaceiscreatedwithinablockchain(e.g.,viaasmartcontractonEthereum),itcannotbedestroyed.Likewise,namespacescannotcontainblacklistingmechanismsthatwouldallowanyonetoinvalidateidentifiersthatdonotbelongtothem.
ii. Therulesforregisteringandrenewingidentifiersmustbetransparent,andtheymustbeexpressedinsimpletermstousersinawaythatwouldbedifficulttooverlookormisunderstand(e.g.,first-come-first-serve,auction).Inparticular,ifregistrationissubjecttoanexpirationpolicy,theprincipalmustbeexplicitlywarnedthatthiscouldresultintheprincipallosingcontroloftheidentifier.
iii. Onceset,namespacerulescannotbealteredtointroduceanynewrestrictionsforrenewingorupdatingidentifiers,sinceotherwiseitwouldbepossibletotakecontrolofidentifiersawayfromprincipalswithouttheirconsent.Likewise,clientsoftwareforrenewingorupdatingidentifierscannotbemodifiedtointroducenewrestrictionsforupdatingorrenewinganidentifier.
iv. Bydefault,softwareformanagingidentifiersmustensurethatallnetworkcommunicationsforcreating,updating,renewing,ordeletingidentifiersissentviaadecentralized,peer-to-peermechanism.This,again,istoensurethatasingleentity(likearegistrar)cannotpreventidentifiersfrombeingupdatedorrenewed.
WerecommendthatDPKIinfrastructurealsostrivetoensuretheexistenceof:
• Atleastoneclassofidentifiersthatdonotexpireonceproperlyregistered.
• Atleastoneclassofneutralregistrationpoliciesavailabletoallmembersofthepublic,aswellastoanyserviceproviderthatwishestoofferregistrationservices.
DPKIshouldnotdiscriminateagainstanypartythatwishestouseit,andregistriesshouldbeconsideredacommons;theirdesignandoperationguidedbyprinciplesofopenness,neutrality,andinclusion(NOTE:Ostrom,Elinor(1990).GoverningtheCommons:TheEvolutionofInstitutionsforCollectiveAction.Cambridge,UK:CambridgeUniversityPress.ISBN9780521405997.orAllen,Christopher(2015).ARevised"Ostrom’sDesignPrinciplesforCollectiveGovernanceoftheCommons"http://www.lifewithalacrity.com/2015/11/a-revised-ostroms-design-principles-for-collective-governance-of-the-commons-.html).
DPKI v1.0.0, 12/23/15 Page 9
4.2TheMechanicsofDPKIRegistration
Registeredidentifiersarelikelytohavetwotypesofkeysassociatedwiththem:thekeypairthat’susedforregisteringandforupdatingthedataassociatedwiththeidentifier,andthepublickeysassociatedwiththeidentifier(subkeys).
Itisrecommendedthatthesubkeysbeusedbytheprincipaltosignmessages.Theycanbestoreddirectlyorindirectlyinthedatastore:
• DirectstoragemeansthatthepublickeyitselfisstoreddirectlyintheDPKIdatastore.Formostblockchains,thisisunlikelysincesomekeysarequitelargeandmostblockchainsmakestoringthemimpossibleorveryexpensive.
• Indirectstoragemeansthatapointer(e.g.aURI)isstoredalongsidewith—oritselfcontaining—thefingerprintforthepublickey.
DPKI v1.0.0, 12/23/15 Page 10
5.SecurityofIdentifiersAndPublicKeys
SectionContributorsAlphabeticalByLastName:VitalikButerin,JudeNelson,andGregSlepak
InDPKI,identifiersaretypicallylookupkeysthatmaptovaluesthatcanonlybemodifiedbytheentity(orentities)withthecorrespondingprivatekey(s).Insuchasystem,theworstthatcanhappenis:
• Anoutdatedvalueforalookupkeyissentinresponsetoalookup.
• Theowneroftheidentifierisnotabletoupdateitsvalueduetocensorship,andtheyloseownershiponcetheidentifierexpires.
Theseproblemsareaddressablethroughtheuseofthinclients(discussedlater)andcensorship-circumventiontools.
Itisalsopossible,althoughextremelyunlikely,thatafalsevalueissentforanidentifier.Thiscanhappen,forexample,ifablockchainthatissecuredbyproof-of-workhasanadversarycapableofoverpoweringthehonestnodesandreversinghistorybeyondthepointofregistration.However,allparticipantsofthesystemwouldbeabletodetectthisattackbecauseitwouldresultintheorphaningofanextremelylongchain.
Thissortofproblemismostlikelytoarisefromacentralizationofablockchain,whichisalargersecurityconcern.
5.1ProtectingAgainstCentralization
Thedegreeofdecentralizationplaysaroleinthesecurityofasystem.Centralizedsystemsarevulnerabletomanipulation,censorship,andcompromise.Theyrepresentasinglepointoffailurethatusersmusttrust.Whencentralizedsystemsgodown,theytakealltheiruserswiththem.
Whileblockchainsmaystartoutdecentralized,theydonotnecessarilyendupthatway.Thisimpliestheneedforasimplemetricthatcantelluswhetherornota"decentralizeddatastore"reallyisstilldecentralized:
Howmanydoorsmustyouknockontocompromisetheusersofasystem?
Wecanroughlydefineametricformeasuringthedecentralizationofmostblockchainsbycountingthefollowingentities(eachofwhomactasinglepointoffailurefortheentiresystemwhencentralized):
• "Devs"—Thenumberofpartieswhohavecontroloverthebehavior(sourcecode)oftheblockchain.
• "Nodes"—Thenumberofblockchainreplicas,measuredbythenumberoffullnodes.
DPKI v1.0.0, 12/23/15 Page 11
• "Validators"—Thenumberofblockchainminers/validator,whoareresponsibleforcreatingnewblocksandauthorizingtransactions.
Sincecompromiseofanyoneofthosegroupsleadstocompromiseofthesystem,wedefinethedecentralizationofablockchainas:
Decentralization(Blockchain)=MIN("Devs",“Nodes”,“Validators”)
Moreinformally,userscaninferthedecentralizationofadatastorebytheQualityofService(QoS)thatitprovides.If,forexample,usersnoticethattheyaresuddenlyunabletoupdatetheiridentifiers,thenthiscouldindicatecensorshipduetocentralization.
5.1.1ADatastoreAgnosticProtocolToProtectAgainstCentralization
IfDPKIweretospecifyaspecificblockchainasits"defactodecentralizeddatastore",itwouldputcentralizationpressuresonthatblockchain.Worse,usingadefactodatastorewouldcouldbreakDPKIiftheblockchainbecameabandonedduetoalackofinterestinthechain.Softwaredevelopers,havingcodedsupportforaspecificblockchain,wouldhavetoexpendsignificantefforttorewritethatsoftwaretomigratetoadifferentblockchain.Meanwhile,therecouldbeserioussecurityconcernsorQoSissues.
Therefore,theuseofanagnosticprotocolforaccessingdecentralizeddatastoresisafundamentalrequirementtoensurethefunctioningandthedecentralizationoftheDPKIasawhole.Agnosticprotocolsmakeiteasierforusersanddeveloperstomigrateshouldadifferentdatastorebetterservestheirneeds.Themereexistenceofthispossibilitycreatesamarketofdecentralizeddatastorescompetingtomeettheneedsofusers.
5.2SecurelyAccessingBlockchainData
Mostenduserdeviceswillnotrunfullnodesbecauseoftheresourcesrequired,sohowdoclientsaccessthechainsecurely?
Onesolutionistodoablockchain-versionofConvergence,whereinasetof"blockchainnotaries"tellusersthestateofaparticularobjectmaintainedbyablockchain,andtheclientsoftwarechecksforunanimousagreementamongasetoftrustednotaries.However,thisroutearguablycompromiseswhatthekeypurposeofblockchaintechnology:removingtheneedfortrustedintermediaries.
Fortunately,thereisanothertechnologicalsolution:thin-clientprotocols.Thinclientsdownloadsmallerportionsoftheblockchain,sufficienttoprovidesecurityguaranteesstrongerthanthoseprovidedbytrustedintermediaries,butsmallenoughtobeusedbyanymoderndevice.Adetailedexampleofhowonepossiblethin-clientprotocolworksisdiscussedintheAppendix"ThinClientDetails".
Forblockchainslackingthinclients,thedefaultshouldbeConvergence-likeunanimousconsensusbasedonarandomsamplingoftrustednodes.Thesenodes
DPKI v1.0.0, 12/23/15 Page 12
shouldallseethesamechain,soifevenoneofthemdisagrees,itisanindicationthatsomethingisamissandtheeventshouldbereported.
Ingeneral,thissuggestsamodulardesign,wheredevicesareabletotalktoanyblockchainandusethemostsecuretechnique(s)availableforthatchain.It’spossiblethatnosingletechniqueprovidesthegreatestsecurity,andinthatsituationtheminimumnumberoftechniquesarecombinedtoprovidethehighestlevelofsecuritythatthedevicecanreasonablysustain.
5.3ProtectingAgainstCensorship
Finally,thesecurityofDPKImustaddresscensorship:whetherthedatastoresareaccessibletoendusers.Ablockchainisn’tusefulifanISPiscensoringit.
Censorshipcircumventiontechnologiessuchasmeshnetworking,proxies,andonionrouting,canbeusedtobypasscensorshipofablockchainnetwork.
Aseparatebutrelatedconcerniscensorshipofthedatathat’sreferencedbyablockchain,suchaswhenahashisstoredinthevalueforanidentifier,andthedatarepresentedbythathashisstoredelsewhere.Inthissituation,thesametechniques(e.g.,onionrouting,proxies)canbeusedinadditiontolookingupthehashovervariousdifferentstoragemechanisms[ref:seeIPFS,Blockstore].
DPKI v1.0.0, 12/23/15 Page 13
6.RecoveringLostIdentifiers-PrivateKeyManagement
SectionContributorsAlphabeticalByLastName:VitalikButerin,ChristianLundkvist,PavelKravchenko,JudeNelson,DukeDorje,ArthurBrock,GregSlepak,NoahThorp,andHarlanTWood
Strong,reliableownershipofidentifierscanmakethoseidentifiershighlyvaluable.Identifierscouldbeusedtoauthenticateausertothedooroftheirhouse,theircar,etc.Theseidentifiersbegintorepresentthe"keystoone’skingdom".Itwouldbecatastrophiciftheseidentifierswerelostorcompromised.AddressingthatproblemisthereforeofparamountimportancetoDPKI’ssuccess.
6.1TwoFormsofLoss
Becauseofitsimportance,useofthemasterkeymustbeminimizedbyanyidentitysystemthat’sbuiltontopofDPKI.Indeed,thisistheapproachalreadytakenbyidentitysystemslikeBlockchainID.Insteadofusingthemasterkeytosignmessages,subkeysarecreatedforeachnewservicethattheidentifierisusedwith.
Thismeanstherearetwotypesofkeysthatcanbelostorcompromised:
• Themasterprivatekey,whichcontrolsthedatathat’sassociatedwiththeidentifier.Losingthiskeycanmeanlossofcontrolofyouronlineidentity.
• Thesubkeys,whicharelinkedtotheidentifierandarestoredaspartoftheidentifier’sdata.
Thesecurityandrecoverypropertiesforthemasterkeyandsubkeysareslightlydifferent.Thefollowingareoverviewsofbothpossibilities;afulltreatmentofthistopicisbeyondthescopeofthispaperandisleftforfuturework.
6.2RecoveryoftheMasterKey
Hewhocontrolsthemasterkeytoanidentifieristheidentifier’smaster.
Therearevariousmechanismsthatcanbeusedtorecoveramasterkeyinadecentralizedsystem.
6.2.1RecombiningShardsoftheMasterKey
Principalscanprotectthemselvesagainstmasterkeylossbydistributingshardsofthemasterkeytotrustedentities.ShamirSecretSharingandThresholdSignaturesaretwotechniquesthatcanbeusedtogenerateandrecombinetheseshards.
Intheeventofloss,theprincipalwouldaskforNshardsofthemasterkeyfromMentities.Nisthenumberofdistinctshardsrequiredforrecovery.UponreceivingtheNshards,themasterkeywouldbesuccessfullyrecovered.
DPKI v1.0.0, 12/23/15 Page 14
Thistechniquedoeslittletoprotectprincipalsintheeventofmasterkeycompromise,however.
6.2.2ProtectingAgainstCompromise
Thedangerofcompromisecomesaboutfromasingleentityhavingthemasterkeyintheirpossessionanypointintime.Wecanaddressthisissuebyensuringthatnosingleentitypossessthemasterkeyatanysinglepointintime.
Forexample,wecanenvisionasystemwhere,uponregistration,usersselectfiveentitiesthattheytrusttoguardtheiridentity.Theseentitiescouldberepresentedbytrustedpersons,organizations,orevendevices.Thoughtheyactlikeauthorities,theyareneverforceduponanyoneandarealwayschosenbytheprincipalthemselves.
Amasterkeyisthengeneratedephemerally,brokenintoshards,senttotheseentities,andimmediatelydestroyed.ThresholdsignatureschemescanbeusedinplaceofShamirSecretSharingsothatamasterkeyneverneedstoberecombinedinitsentiretyonanygivendevice.
6.2.3UsingSmartContracts
Someblockchains,suchasEthereum,supportarbitrarycomputation.Insuchcases,principalscanconstructrecoverymechanismsproportionaltotheirlevelofparanoia.
Asatrivialexample,acompanylikeGooglecouldsecuretheircontroloverablockchain-domainbyusinganamespacewhereasmartcontractisusedtoupdateitsvalue.Thesmartcontractcanbecodedtofunctiononlywhenitreceivesamessagesignedby6outof10entities,orfollowanyotherarbitrarylogic.
DPKI v1.0.0, 12/23/15 Page 15
6.3RecoveryAnd/OrRevocationofSubkeys
Subkeycompromiseorlossislessofaconcernthanlossorcompromiseofamasterkey,becauseverificationistypicallydoneusingthecurrentsetofsubkeysforanidentifier.Ifasubkeyislostorcompromised,themasterkeycansimplybeusedtosecurelygenerateandreplacetheoldsubkey(s)inablockchain.However,dependingonhowtheyareused,oldsubkeysmightstillrequirerecoveryorrevocation.
Asmentionedpreviously,theimportanceofthemasterkeyimpliesthatidentifierswillbeauthenticatedthroughmessagessignedbythesubkeysofanidentifier,andnotmessagessignedbythemasterkey.However,sincethosemessagesaretypicallyassociatedwiththeidentifieritself,theyareineffectbeingsignedbythemasterkey(sincethemasterkeyisdirectlytiedtotheidentifier).Therefore,themasterkeycanstillbeusedtosignanddisseminatemessagesrevokingoneormorehistoricalsubkeys.
Recoveryoflostsubkeyscanbedoneusingtheshardingmechanismsdescribedpreviously.Alternatively,aswiththegroup-basedrecoveryschemesdescribedabove,aprincipalcanchoosetodesignateauthorityovertheiridentifiertoagroup.Thisgroupcouldhavetheabilitytosignnewsubkeysasbelongingtotheidentifier,aswellastheabilitytosignmessagesthatindicateanoldkeywascompromisedandthereforerevoked.
DPKI v1.0.0, 12/23/15 Page 16
7.Conclusion
Inthispaper,wediscussedhowidentityismanagedonlinetodaythroughglobally-readableidentifierslikewebsitedomains.WeidentifiedvarioussecurityandusabilityproblemsintheInternet’stwoprimaryidentitymanagementsystems:DNSandX.509PKIX.Wepinpointedthesourceoftheseproblemstobethecentralizednatureofthesesystems,whichpreventstheentitiesrepresentedbytheseidentifiersfromtrulycontrollingthem,makingitpossibleforthird-partiestocompromisetheirsecurity.
WethenshowedhowthesecurityandusabilityproblemsofDNSandPKIXcanbeaddressedthroughtheuseofdecentralizedkey-valuedatastores,suchasblockchains,tocreateaspecificationforaDecentralizedPublicKeyInfrastructure(DPKI).IndescribingthepropertiesofDPKI,weshowedthatDPKIworksevenonresource-constrainedmobiledevices,andthatitisabletopreservetheintegrityofidentifiersbyprotectingorganizationsfromprivatekeylossorcompromise.
OurfutureworkistodevelopafullspecificationforDPKIthroughanInternetstandardsbodyliketheIETF.
8.References
GovernmentInnovationineID+CitizenEngagementBCIdentityCitizenConsultationResults
Namecoin’sUNOCommitmentsbyDanielKraft
• https://forum.namecoin.info/viewtopic.php?f=5&t=2239
Namecoin’sAnalysisofvariousThinClientModels
• https://github.com/hlandau/ncdocs/blob/master/stateofnamecoin.md#spvutxo-cbc
• https://github.com/hlandau/ncdocs/blob/master/stateofnamecoin.md#spvutxo-cbcuno-nx-cbc
EthereumRelatedDocumentsOnThinClientRelevantMaterial
• https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/
• https://github.com/ethereum/wiki/wiki/Patricia-Tree
DPKI v1.0.0, 12/23/15 Page 17
Appendix:ThinClientDetails
SectionContributorsAlphabeticalByLastName:VitalikButerin,GregSlepak
TypesofInformation
Whatkindofinformationdothinclientswanttoknow?
Thefollowingaresomeexamples:
• Determiningthetimethataparticularrecordwascreatedorfirstseen
• FindingthepublickeycurrentlyassociatedwithanaccountID
• FindingtheIPaddressandotherdatacurrentlyassociatedwithadomainname
• Learningaboutkeyrevocations(withnospecifiedprocessforfindingareplacementkey)
• Determiningthemostrecentversionthatadeveloperhaspublishedforaparticularsoftwarepackage
Moregenerally,wecandecomposethisintothreecategoriesofproblems:
• Provingexistence:provingthataneventofaparticularkindhappenedattimeT
• Provinginexistence:provingthataneventofaparticularkinddidnothappenbetweentimesT_1andT_2
• Provingstate:provingthatthe"state"ofanapplication,whichcanpotentiallybearesultofcomplex“statetransition”rulesfromapplyingmanytransactions,isequaltoXattimeT
Theseareroughlyarrangedinincreasingorderofhardness;provingexistenceistheeasiest,andprovingstateisthehardest.
DegreesofSecurity
Ingeneral,athin-clientprotocolontopofablockchaincanofferthreelevelsofsecurity:
• Maximumsecurity:ifathinclientmakesaquery,andanynoderespondswithavalidreplytothatquery,then(providedwecandetectblockwithholdingattacks)thethinclientcanimmediatelyeitherlearn(i)thecorrectanswertothequery,or(ii)thattheresponsewasinvalidandshouldbeignored.
• 1-of-Ntrustsecurity:ifathinclientmakesaquery,anditisacceptedasasecurityassumptionthatatleastonehonestnodewillrespondcorrectlywithin
DPKI v1.0.0, 12/23/15 Page 18
Tseconds,thenthethinclientcanlearnthecorrectanswerafterTseconds,regardlessofhowmanyoffline/faulty/byzantinenodesthereare.
• N/2-of-Ntrustsecurity:ifathinclientmakesaquery,itmustselectsomesetofnodes(say100)thatittruststorespond,andthenrandomlysample3orsonodesoutofthatlistandrequireaunanimousagreementfortheresponse.Itwilllearnthecorrectansweraslongasall3nodesdonotcollude.Ifanynodeisoffline,itcancontinuetorandomlysearchforanonlinenode,untilit’scheckedsomeupperthresholdofnodes,andhard-failwithanerroronceitreachesthatthreshold.
Asanexampleofhowthesemodelsapply,considerthesimplecaseof"findingthecurrentpublickeyassociatedwithanaccount",assumingthatthereexistsasinglemasterkey(orsetofmasterkeys)thathastherighttorevokeandreplacekeys.SupposethatwehaveablockchainwhereonlytransactionsareplacedinMerkletrees.Then,athinclientsendsarequestaskingthenetworkforaMerkleproofofthemostrecenttransactionthatreplacedthepublickey.Iftheclientreceivesananswer,itknows:
• Withthemaximumsecurityassurancethatthiswasthevalidkeyatsomepointinthepast.Thisisa"proofofexistence"problem.
• With1-of-Ntrustsecurityassurancethatthisisstillthevalidkey.(Theoretically,anewerreplacementtransactioncouldexist,buta100%collusionorcensorshipcouldleadtotheclientneverlearningaboutit.)Thisa"proofofinexistence"problem.
Forprotocolsthathavemorecomplexneeds(eg.implementingcomplexnameregistrarrules),weareforcedtodealwiththemoregeneralizedproblemof"provingstate".Ifweuseasimpleblockchainthatonlykeepstrackoftransactions,clientswouldonlyknowtheanswerwithN/2-of-Ntrustsecurityassurance.However,ifwehaveablockchainwherethestateisinaMerkletree,thentheclientcanlearnabsolutelyanyfactwithmaximumsecurityassurance.
BecausedifferentblockchainshavedifferentlevelsofusageofMerkleproofs,ourproposedsolutionistodevelopanabstractprotocolbywhichdifferentblockchainscanbeused(asnosingleblockchainis100%guaranteednottobefatallyflawed,wewantanabstractmodelsimilartothatusedforencryptionalgorithmchoices),andwhichautomaticallyattemptstoprovidethebestlevelofsecurityavailabledependingontheblockchain’scapabilities.Notarieswouldbeavailableasabackstop,butblockchainpluginswouldexistwhichtheclientcouldinstalltosupportspecificblockchains.Thesepluginswouldintelligentlymakeblockchainqueriesthatwouldprovideasmuchsecurityaspossible,basedonwhethertheblockchainsupportsstrongsecurityassurancesforthespecifickindofproblem(proofofexistence,provingstate,etc)inquestion.
DPKI v1.0.0, 12/23/15 Page 19
ThinClientProtocols
Thin-clientprotocolstypicallyworkintwostages.
First,thethinclientdownloadsonlyaportionofthechain,typicallytheheaderchain.Theheaderchaintypicallycontainsaverysmallamountofinformation(typically80-600bytes)foreachblockcontainingmetadata,suchas(i)proofofworknonces;(ii)therootofacryptographichashtree,suchasaMerkletree,containingdatasuchastransactions;and(iii)possiblythestateoftheapplicationthattheblockchainkeepstrackof.
Second,theclientvalidatestheheaderchainbyusingtheblockchain’sunderlyingconsensusalgorithm(e.g.checkingproofofworkorproofofstakesignatures).Afterward,theclienttreatstheheaderchainas"trusted".Itappliescryptographictechniquesthatusethedataintheheaderchainasa“roothash”,fromwhichitcanverifyclaimsabouttherestofthedatastoredintheblockchain.
FetchingtheHeaderChain
Thefirsttaskforathinclientistodownloadandverifytheheaderchain.Assumingaworkingnetworkconnection,thisiseasy.Forexample,intheproof-of-workcasetheclientasksthenetworkforasmanyblockheadersasitcanprovide,thenetworkrepliesback,andtheclientcheckstomakesurethateachheaderhasvalidproofofworkandthendeterminesthe"longest"chainofvalidblockheaders(where“longest”istakentomean“representsthemostcumulativework”).Moreadvancedprotocolsusingskiplistsexistsothatclientsdonotevenneedtodownloadeveryblockheader,thoughin-depthdiscussionofthisisbeyondthescopeofthispaper.
Themainchallengewiththismechanismissimple:whatifthenetworkconnectioniscompromised?Potentially,aninternetserviceprovidercouldattackauserbycensoringrepliesthattellaclientabouttheofficialchain,andinsteadtelltheuserabouttheirownfork.Withproof-of-workprotocols,onecanstatisticallydetectthisbynoticingareductionintherateofblockproduction;however,moreresearchisneededondeterminingthebestandmostreliablewaytodothis.
VerifyingwithMerkleTrees
Afterathinclienthassuccessfullyreceivedasmallpieceofdatathatis"trusted"itmustbeabletoverifyclaimsabouttherestofthedatainthechain.ThisreliesonMerkletrees.AMerkletreeisahashingalgorithmwherealargenumberof“chunks”ofdataarehashedafewpiecesatatime,andthenthe
DPKI v1.0.0, 12/23/15 Page 20
resultinghashesarethemselvesputintosmallgroupsandhashedandsoonrecursivelyuntiltheprocessresultsinonesinglehash,calledtheroot.Asimpledepictionofthisisshowntotheright.
ThebenefitofthismethodisthatthemembershipofanysinglechunkofdatainthetreecanbeprovenviaaMerklebranch,whichisthesubsetofnodesinthetreewhosevaluesareusedintheprocessofcomputingtheroothash.
Withjustthissetofnodes,athinclientcanverifythataparticularchunkisinthetreehasaparticularproof.Theschemeissecureuptocollisionresistance;inorderforanattackertocheatthescheme,theattackerwouldneedtobreaktheunderlyinghashfunction.TherearemanydifferentkindsofMerkletrees,includingsimplebinarytreesandmoreadvanceddesignssuchasMerklePatriciatreesthatallowforefficientinsertanddeleteoperations,butthebasicprincipleisthesame.
DPKI v1.0.0, 12/23/15 Page 21
AdditionalCredits
LeadPaperEditors:GregSlepak,DrummondReed
AboutRebootingtheWebofTrust
ThispaperwasproducedaspartoftheRebootingtheWebofTrustdesignworkshop.OnNovember3rdand4th2015,over40techvisionariescametogetherinSanFrancisco,Californiatotalkaboutthefutureofdecentralizedtrustontheinternetwiththegoalofwriting3-5whitepapersandspecs.Thisisoneofthem.
WorkshopSponsors:RespectNetwork,PricewaterhouseCoopers,OpenIdentityExchange,andAlacritySoftware
WorkshopProducer:ChristopherAllen
WorkshopFacilitators:ChristopherAllenandBrianWellerwithgraphicfacilitationbySoniaSawhneyandadditionalpapereditorial&layoutbyShannonAppelcline
What’sNext?
ThedesignworkshopandthispaperarejuststartingpointsforRebootingtheWebofTrust.Ifyouhaveanycomments,thoughts,orexpansionsonthispaper,pleasepostthemtoourGitHubissuespage:http://bit.ly/weboftrust-issues.Wearealsoplanningformoregatheringsonthistopicinthenearfuture,withtheobjectbeingtohavesomethingnotablereadyforreleaseonthe25thanniversaryofPGP,inJuly2016.Ifyou’dliketobeinvolvedorwouldliketohelpsponsortheseevents,email: