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:

ChristopherA@LifeWithAlacrity.com