attacksinageneralway).Adenitionspecieswhatitmeansfortheprotocolunder - PDF document

attacksinageneralway).Adenitionspecieswhatitmeansfortheprotocolunderconsiderationtobesecureinthemodel.Assoonasthemodelanddenitionaredetermined,thesecurityofmanyprotocolscanbeformallyprovenorrefuted.Whileprovidingacertainlevelofassurance,asecurityproofisnotthepanacea.Inparticular:Provingsecuritytheoremsandverifyingtheproofsaredauntingtasks,andoftenpronetoerrorsthemselves;Itispossiblethatthemodelfailstocapturecertainattacks,orthedenitionisinadequateforsomesecurityrequirements;Theproofsaresometimesmisinterpreted.Forinstance,anasymptoticproofofsecuritymightbeoflimitedsignicanceinpractice,whereconcreteproofsofsecurityareneeded[10].AprimeexampleofthersttwoitemsisapparentintheworkofKrawczyk[11]:HeputsforwardageneralmodelforAKEprotocols,aswellasasecuritydenition.Basedonthismodel/denition,anecientAKEprotocolcalledMQV[12,13]isanalyzed,andseveralsecurity awsaredetected.MQVisthenupdatedintoanimprovedversion,calledHMQV.Finally,thesecurityofHMQVisprovenformally.However,Menezes[14]pointsouttoafewmistakesintheproof,aswellasthefailureofthemodeltocaptureseveralpracticalattacks.Subsequently,Krawczykaddedanappendixtothefullversionofhispaper[11],discussinghowtoevadesuch aws.HismodelhassincebeenadefactostandardindesigningprovablysecureAKEprotocols(seeSection1.2forasurvey).Thebottomlineisthatonemustbecarefulwhileproposinganewsecuritymodelordenition,andshouldtakeeverypossiblemeasuretowritesoundsecurityproofs.Thatsaid,aprovablysecureAKEprotocoliscertainlypreferablethanonewhichisdesignedandanalyzedinanadhocmanner,duetothedelicatenatureoftheseprotocols,asdiscussedabove.Forthisreason,researchersstartedtoproposemodelsanddenitionsforAKEprotocolsindierentsettings,forwhichadhocprotocolsalreadyexisted.Someofthesesettingsareasfollows:Two-partysetting,three-partysetting,public-keysetting,groupkeyexchange,andpassword-basedAKE.WesurveythesesettingsinSection1.2.Inthispaper,weputforwardamodelanddenitionforaclassofAKEprotocols,whichwerepreviouslydesignedadhoc,andthenprovethesecurityofourproposedprotocol.Informally,thisclasscontainslightweightAKEprotocolswhichprovideforwardsecurity.Bylightweight,wemeantheprotocolswhichdonotuseheavyoperationssuchasmodularexponentiation.Forwardsecurity,alsocalledperfectforwardsecrecy(PFS),isanimportantpropertyofAKEprotocols.ItwasrstdenedbyGunther[15],usedfamouslyintheStation-to-Stationprotocol(STS)[16],andformalizedby[11,17{19].Thisconceptisdenedinformallybelow:InformalDenition.AnAKEprotocolissaidtobeforwardsecureif,evenifthelong-termkeys(LTKs)arerevealedtotheadversary,theephemeralkeysgeneratedpriortotheexposureoftheLTKsremainprotectedfromtheadversary.Most(ifnotall)provably-secureAKEprotocolssatisfyingtheforwardsecuritypropertyuseavariantoftheDie-Hellman(DH)protocol[20],whichrequirestheheavymodularexponentiations.Ontheotherhand,forwardsecureandlightweightAKEprotocolsareoftendesignedadhoc.ThebasicideaofsuchprotocolsisnottouseDH,buttomodifytheLTKsregularly.Unfortunately,adhocprotocolsareoftenpronetoattacks.Afamous\ultralightweight"AKEprotocol,calledSASI[21],providesagoodexample.SASIattemptstoprovideforwardsecuritywithoutdependingonDH,butisfoundtobe awedbyseveralresearchers[22{24].Whileproveninsecure,SASI(andsimilarprotocols)followaremarkableapproachtoforwardsecurity:TheyupdatetheLTKsregularlyandirreversibly.IftheadversarygetsholdofanupdatedLTKKnew,shewillbeunabletoinferthepreviousLTKKold,asdoingsorequiresinvertingtheone-wayfunction.SincetheephemeralkeysdependessentiallyonKold,itmustbeimpossiblefortheadversarytoobtaintheephemeralkeysfromKnew.WewillusethetermKey-EvolvingSchemes(KES)forprotocolswhich2 WedesignanAKEprotocol,andrigorouslyproveitssecuritywithinthemodelandaccordingtotheabovedenition.TheprotocolisaptlynamedFORSAKES,becauseitisaFor wardS ecureAKE basedonKES .(RecallthatAKEstandsforAuthenticatedKeyExchange,andKESstandsforKey-EvolvingScheme.)FORSAKESisdesignedintherandomoraclemodel(Section2)withoutanyassumptions.MostAKEprotocolsdependonsomecryptographicassumption,eveniftheyusetherandomoraclemodel.Forinstance,[11,18,30]areprovensecureintherandomoraclemodel,butusesomeformoftheDie-Hellmanassumptionaswell(e.g.,DecisionalDie-HellmanorGapDie-Hellman).SinceweprovethesecurityofFORSAKESwithoutanyassumptions,itisunconditionallysecureintherandomoraclemodel.Inotherwords,thereisnorestrictionontherunningtimeofthead-versary,andthesecurityproofholdsevenforinnitelypowerfuladversaries.(Whiletheadversarycanhaveinniterunningtime,sheisnotfreetomakeasmanyqueryasshelikestothesystemortherandomoracle.Seetheproofsformoreinformation.)Weusetherandomoraclemodelonlytosimplifytheproofs.However,sincewedonotusethefacilitiesprovidedbytherandomoraclemodel(suchasviewingorprogrammingtheadversary'squeries),itispossibletoreplacetherandomoraclewithapseudorandomfunction[31],toachieveasecureAKEprotocolinthestandardmodel.SeeSection6formoreinformation.Whilethereareecientandprovablysecurepseudorandomfunction[32],usingtherandomoracleheuristicandreplacingallinstancesoftherandomoraclewithahashfunctionsuchasSHA-1yieldsamorepracticalprotocol.InthecaseofFORSAKES,wecanobtainaprotocolwhichusesnothingbuthashfunctions,whichisparticularlysuitableforconstraineddevicessuchassmartcardsortokens.SeeSection6formoreinformation.1.2RelatedWorkEarlypapersonsecureauthenticationwereeitheradhoc,oradoptedthezero-knowledgemodelofFeige,Fiat,andShamir[33],whichwassuitableonlyforsmart-cardidentication.Inthispaper,wearenotconcernedwithsuchapproach.Acomprehensiveaccountofpapersonzero-knowledgeidenticationcanbefoundin[34,Section2.2].FormalizationofamodelanddenitionforbothentityauthenticationandAKEprotocolsstartedwiththeseminalworkofBellareandRogaway[35].Theyrecognizedthateachpartycantakepartinmultipleinstancesoftheprotocol(eachofwhichwascalledasession),andmodeledeachsessionasanoracle,towhichtheadversarycouldmakethreetypesofqueries:send,reveal,andtest.Asendqueryallowedtheadversarytodeliveraspecicmessagetosomesessionofherchoice,andobservetheresult.Arevealquerygavetheadversarythesessionkeyofaspecicsession.Atestquery ippedacoin,andbasedontheresult,gavetheadversaryeitherarandomvalueorthesessionkeyofthetargetsession.Thegoaloftheadversarywastodistinguishwhethersheisgiventherandomvalue,ortheactualsessionkey.Theideasof[35]werenotableisseveralways:(1)TheydenedthesecurityofAKEprotocolsbasedonadistinguishabilitygame.(2)Theydenedanotionofsessionfreshness.Iftheadversarymakesarevealquerytothetargetsessionbeforeorafterthetestquery,shecanobtainthesessionkey,anddistinguishwhethersheisgivenarandomvalueortheactualsessionkey.Therefore,arevealedsessionisnolongerfresh.Thisisalsothecaseifthe\partnersession"ofthetargetsessionisrevealed.Therefore,therewasaneedtodenepartnership.(3)Theydenedpartnershipviatheconceptofmatchingconversations.Itsimplymeansthattwosessionsarepartnersifeverymessagethatonesendsisreceivedbytheother,andviceversa(exceptpossiblythelastmessage,whichcanalwaysbedeletedbytheadversary,withoutbeingdetectedbythesender).Noticethat[35]modeledthetwo-partyauthentication/AKEbasedonsymmetrickeys.Thepresentpaperusesasimilarmodel.Furthermore,[35]usesrandomoraclesintheirproofs,similartotheproofs4 fortheInternetprotocols,wheretheprotocoldesignercannotguaranteethattheprotocolsexecutedconcurrentlywithhisprotocolareallsecure.ItwaslatershownthattheUC-denitionofAKEprotocolsis awed[46],andthe awwascorrectedaccordingly.Amodelforpassword-basedAKEprotocolsintheUCframeworkwaslaterproposed[47,48]aswell.Inhisfamouspaper,Krawczyk[11]proposedanimprovementtotheCKmodel,whichbecameknownastheCK+model.Inthismodel,theadversarywasallowedtorevealpartyorsessioninformationviathreedierenttypesofqueries:state-revealqueries,session-keyqueries,andpartycorruptionqueries.Thesetypesofqueriesprovidetheadversarywithagreat exibility.LaMacchia,Lauter,andMityagin[30]spottedseveralweaknessesintheCKandCK+models.Specically,theCKmodeldoesnotspecifythepreciseresultofthestate-revealqueries:\Animportantpointhereiswhatinformationisincludedinthelocalstateofasession;thisistobespeciedbyeachKEprotocol"[19].Furthermore,thesecuritydenitioninbothmodelsdoesnotallowanadversarytousehisfullpotential.Therefore,LaMacchiaetal.putforwardanewsecuritymodel/denition,calledtheextendedCK(eCK).TheeCKmodelreplacedthestate-revealqueryofCK/CK+withanEphemeralKeyRevealquery.ThelatterqueryisspecictoDie-Hellmanprotocols,andallowstheadversarytorevealtheprivateexponentinagmodp owoftheDie-Hellmanprotocol.ThesecuritydenitionofLaMacchiaetal.consideredasessionfresh,ifeitherthelong-termkeyortheprivateexponentofthatsessionisrevealed,butnotboth(andthesameshouldholdforthepartnersession).Thisdenitiongreatlyincreasedthepoweroftheadversary,andfortwoyearsitwasassumedtobethestrongestAKEmodel/denition.However,Cremers[49]showedthatthestate-revealqueryofCK/CK+isstrongerthantheEphemeralKeyRevealqueryofeCK,andthereforethemodelsareincomparable.Cremersusedthevaguenessinthedenitionofthestate-revealquerytorevealtheintermediateresultsofDie-HellmancomputationsintheNAXOSprotocolofLaMacchiaetal.,thusshowingthatNAXOSisinsecureintheCK/CK+model.In2010,Sarretal.[50]triedtoamplifytheeCKmodel,byproposinganothermodelinwhichtheadversarycouldrevealtheintermediateresults.TheirmodelconsideredanimplementationapproachwheretheprivateexponentsoftheDie-Hellmanprotocolwerecomputedduringtheidletimeofamachine(i.e.,beforetheprotocol),andwerestoredintheRAM,whichisconsideredaninsecurestorage.TheycalledtheirmodelstrengthenedeCK(seCK).Oneyearlater,YoneyamaandZhao[51]showeda awinthesecurityproofsofSarretal.[50],andconcludedthatachievingsecureprotocolsintheseCKmodelisveryhard,ifnotimpossible.TheabovesurveyshowsthedelicatenatureofproposingsecuritymodelsanddenitionsforAKEprotocols.Thereaderinterestedinfurthercomparisonofthesemodelsanddenitionscanconsult[9,49,52{54].1.3OrganizationTherestofthispaperisorganizedasfollows:Section2denestheconceptsandnotationusedthroughoutthispaper.Section3presentstheFORSAKESprotocol.InSection4,weputforwardournewsecuritymodelanddenitionforAKEprotocolswithasymmetrickey-evolvingscheme.Section5providesarigorousproofofthesecurityofFORSAKESaccordingtothemodel/denitionpresentedinSection4.Section6discussestheissuesregardingtheimplementationofFORSAKESinpractice.Finally,Section7concludesthepaper,andexplainsthefuturework.Thispaperhasanappendix,AppendixA,whereweprovethesecurityofamessageauthenticationcode(MAC)basedonrandomoracles.ThisproofisincorporatedinthesecurityproofofFORSAKES,inSection5.6 2PreliminariesForc2N,let[c]denotethesetf1;2;:::;cg.ForanitesetS,thenotione RSmeansthattheelementeispickedfromSrandomly.Let�nk
denotethenumberofk-subsetsofann-set.Byconvention,�nk
=0ifk�n.Otherwise,�nk
=n! k!(n�k)!.Weusen2Nasthesecurityparameter,meaningthattheresources(time,space,etc.)availabletoallpartiesandalgorithmsaremeasuredinn.Asiscustomaryincryptography,nwillbeprovidedtothealgorithmsinunarynotation1n(i.e.,1isrepeatedntimes).Thisisbecausetheresourcesareactuallyaccountedbasedonthelengthoftheinput.Throughoutthepaper,weusefourfunctions`;r;k;K:N!N,where`(n)isthelengthofentityidentiersinthesystem,r(n)isanupperboundonthenumberofrandombitsusedbyeachentity,k(n)isthelengthofephemeralkeys,andK(n)isthelengthoflong-termkeys.Weassumethattheexistsapolynomialp:N!N,suchthatn`(n);r(n);k(n);K(n)p(n)foralln2N.Whenthecontextisclear,wemaydroptheparametern.Forinstance,wemaysimplywriterinsteadofr(n).Letf0;1gdenotethesetofallnitebinarystrings,andf0;1gndenotethesetofallbinarystringsoflengthn.Thelengthofastringx2f0;1gisdenotedbyjxj.Thespecialsymbol2f0;1gdenotestheemptystring,i.e.,jj=0.Fortwostringsx;y2f0;1g,letxjjydenotetheconcatenationofxandy.Theresultoftheconcatenationofwithanystringisthestringitself.Anotherspecialsymbolis.Itiscalledthewildcardsymbol,andmatchesasinglebit.Forinstance,theresultofthecomparison10=1010istrue.Wemayoccasionallyassign0toaBooleanvaluetodenotethatitislogicallyfalse.Similarly,1istobeinterpretedaslogicaltrue.Afunctionf:N!Riscallednegligibleifitvanishesfasterthantheinverseofanypositivepolynomial.Thatis,f(n)n�cforallcandallsucientlylargen2N.Weusetherandom-oraclemodel(ROM)[55],whereallparties,includingtheadversary,haveaccesstoarandomfunctionO:f0;1g!f0;1gk(n).OnceOisqueriedonsomevaluex2f0;1gforthersttime,arandomk(n)-bitvalueyischosenandreturned.Noticethatyisindependentofxandtheidentityoftheentitymakingthequery.Fromthispointon,Owillreturnyifitisqueriedagainonx.ItisinstrumentaltothinkofOasanidealhashfunction,havingpropertiessuchasone-waynessandcollisionresistance.TheROMwillgreatlysimplifythesecurityproofs,butasdiscussedinSection6,wecanreplaceOwithpseudorandomfunctions.Convention.Inwritingthepseudocodes,wewillassumeminimalevaluation:Inconditionalstate-ment,theconjunctsordisjunctsareevaluatedfromlefttoright.Assoonasthevalidityofthestatementiseitherprovenorrefuted,theremainingconjunctsordisjunctsareignored.Forinstance,considerthestatementif(aandb):Assumingaisfalse,thevalueofbisignored.Theminimalevaluationallowsustowriteshorterpseudocodes.Forinstance,intheaboveexample,thevariableofbmaybeundenedunlessaistrue.Ifwehadnotusedtheminimalevaluationconvention,weshouldhavewrittentwoseparateifstatements:Therstoneevaluateda,andonlyifitweretrue,thevalueofbwasevaluated.3TheFORSAKESProtocolTobetterunderstandthetheoreticalfoundationsoftheAKEsecuritymodelanddenitionpresentedinthenextsection,letusrstdescribetheFORSAKESprotocol,whichismorepracticallyoriented.Protocol1illustratesFORSAKESonahighlevel.7 Algorithm1.Initiator'shandlingofsessioninitiation. pidcx idy;//PartnerID,setbythecaller. IncomingMessage:None(0)1:c c+1;2:sidcx rndcxjjr;//`'isawildcard3:rolecx `I';4:Tcx T;5:skcx ikcx ;6:acccx ;//Sessionfateisundecidedyet.7:stcx sidcxjjrolecxjjpidcxjjTcxjjskcxjjikcxjjacccx;8:Msg1 1jjidxjjpidcxjjTcxjjrndcx;9:returnMsg1 itisimportanttoprotectthesessionkeyproperly.ThenextsectionshowsthatthesecurityofanAKEprotocolisdenedbasedontheproperprotectionofthesessionkey.ikiz2f0;1gk:Thesecondpartoftheephemeralkey,knownastheintegritykey.Oncecomputed,thiskeyprotectstheintegrityofFORSAKESmessages.acciz2f;0;1g:Theacceptancedecisionofthesession.Inthebeginning,theacceptanceisundecided().Whenthesessiondecidesitacceptance,accizwillbeeitherfalse(0)ortrue(1).Next,wewillexplainhoweachmessageofFORSAKESishandledbythecorrespondingparty.SessionInitiation.Theinitiatordoesnotreceiveanymessagefromanotherparty.However,theinitiatorsessionissupposedlycalledbysome\higher-levelapplication,"whichcanbethoughtasthezerothmessageoftheprotocol.Thecallerdeterminestheidentierofthedesiredpartner.LetusassumethattheIDoftheinitiatorisidx,andtheIDofthepartner(i.e.,theresponder)isidy.Thealgorithmusedbytheinitiatortohandlesessioninitiation,andgenerationoftherstprotocolmessage,isdescribedbyAlgorithm1.TheinitiatorrstsetsthesessionpartnerIDtoidy,andthenincreasesthesessioncounterc.Next,thesessionIDissettorndcxjjr.Recallthatrndcxisthecurrentsession'srandomness,whilerisawildcardstringoflengthr.Thereasonofusingawildcardstringbecomesclearwhenwediscusshowtheinitiatorhandlesthesecondmessage.Inthenextstep,theinitiatorsetsthesessiontimestagetoT,theephemeralkeysaresettoempty,andtheacceptancestateissettoundecided().Finally,thesessionstateandMsg1areset.Noticethatthesessionstateincludeseveryotherstatevariable:stcx sidcxjjrolecxjjpidcxjjTcxjjskcxjjikcxjjacccx:Itwillbetheonlyvariablethateachsessionstores.Thatis,therewillbenoneedtostoreothervariables,suchassidcx,separately.However,wewillkeepusingothervariableslater,whenthesessionreceivesthesecondmessage.Here,itisimplicitlyassumedthatsessionstateisinterpretedbythepartytoitsconstituentparts.Letusexplaintheconstructionoftherstprotocolmessageaswell:Msg1 1jjidxjjpidcxjjTcxjjrndcx:(1)Noticethatthemessagebeginswith1,indicatingthatthisistherstmessageoftheprotocol.Ithelpsthereceiver|whomayhaveparticipatedinmultipleconcurrentsessions|todistinguishtheincomingmessage.Itcanpreventtypingattacks[4,5],wheretheadversaryusesthesyntacticalsimilarityofprotocolmessagestoreorderthemandmountanattack.9 Algorithm3.Initiator'shandlingofthesecondmessage. IncomingMessage:m=Msg2z }| {2jjidsjjidrjjTsjjsidjjAuth21:if�sidix6=sidforalli2[c]
2:return;//Nosessionmatcheswithm.3:if�sidix=sidformorethanonei2[c]
4:stix forallsuchi's;5:return;//Uniquematchisrequired.6:leti2[c]betheuniquevaluesuchthatsidix=sid;7:if�ids6=pidiyoridr6=idxorTs6=TorTs6=Tixorroleix6=`I'oraccix6=
8:stix ;9:return;10:letKTxybetheLTKsharedbetweenidxandpidix;11:sidix sid;//Nomorewildcards.12:skix O(KTxyjj0jjsidix);13:ikix O(KTxyjj1jjsidix);14:if�Auth26=O(ikixjjMsg2)
15:stix skix ikix ;16:return;17:accix 1;18:stix sidixjjroleixjjpidixjjTixjjskixjjikixjjaccix;19:Msg3 3jjidxjjpidixjjTixjjsidix;20:Auth3 O(ikixjjMsg3);21:returnMsg3jjAuth3 ItisnowpossibletocomputetheephemeralkeysbasedonthecurrentLTK,aswellasthenoncesofbothsessions(notethatthesessionIDistheconcatenationofnonces):skdy O(KTyxjj0jjsiddy)ikdy O(KTyxjj1jjsiddy):Aftersettingtheephemeralkeys,theacceptancestateofthesessionissettoundecided(),andthesessionstateisconstructed.Then,thesecondmessageisgeneratedwithasimilarsyntaxtotherstmessage.Therearetwodierences,though:(1)ThesecondmessageincludesthesessionIDratherthanasinglenonce;and(2)Thesecondmessageisauthenticatedusingtheintegritykey.Theconstructionofthemessageandtheauthenticatorisasfollows:Msg2 2jjidyjjidxjjTdyjjsiddyAuth2 O(ikdyjjMsg2):Finally,therespondersendsMsg2jjAuth2totheinitiator.HandlingtheSecondMessage.Afterverifyingthemessagesyntax,theinitiatorexecutesAlgo-rithm3tohandlethesecondmessage.ItisrstveriedwhetherthereexistsasessionwhoseidentiermatchesthesessionIDincludedintheincomingmessage.Itisherethatwildcardmatchingisim-portant:NoticethattheinitiatoronlyknowstherstpartofthesessionID,andthesecondpartischosenbytheresponder.Ifnomatchisfound,theincomingmessageisrejected(viareturn).Next,itisveriedthatexactlyonematchexists.IftherearetwoormoresessionswhoseID'smatchesthesidontheincomingmessage,allsuchsessionswillbedeletedbysettingthemtoempty11 Next,sixmorevericationsareperformed:(1)TheIDofthesendermatchestheIDofthesessionpartner,(2)theIDofthereceivermatchestheIDofthecurrentparty,(3)thetimestageofthesendermatchesthecurrenttimestage,(4)thecurrenttimestagematchesthesessiontimestage,(5)theroleofthecurrentsessionis`R',meaningthatitanticipatedthethirdprotocolmessage,and(6)thesessiondidnotacceptorrejectpreviously.Ifanyoftheseconditionsdoesnothold,thesessionstateissecurelywiped,andtheincomingmessageisrejected(viareturn).Asanalverication,theintegritykeyisusedtoverifyAuth3onMsg3.Ifthevericationfails,thesessionstateissecurelywiped,andtheincomingmessageisrejected(viareturn).Ultimately,thereceiveraccepts,andupdatesthesessionstate.ThisstepconcludesthedescriptionofFORSAKES,butmanypracticalissuesarelefttobediscussedinSection6.4SecurityModel&DenitionNowthatwesawapracticalAKEprotocol(FORSAKES),itwillbeeasiertounderstandthesecuritymodelanddenitionforgeneralAKEprotocols.Inwhatfollows,werstmodelapowerfuladversaryinSection4.1.Theadversarycanarbitrarilycreatenewparties,sharealong-termkeybetweenanypairofparties,deliverarbitrarymessagestothematanytime,receivetheresponseaswellasinformationabouttheirinternalstate,getaccesstothelong-termandsessionkeys,andsoon.Inthenextstep,wedenewhatitmeansforanAKEprotocoltobesecureinthemodel.Tothisend,wedeneagamebetweentheadversary,andahypotheticalentitycalledthechallenger.Thegameprovidestheadversarywithalltheabilitiesspeciedinthemodel.Thegoaloftheadversaryistodistinguishanysessionkeyofherchoice,fromarandomvalueprovidedbythechallenger.Thesecuritydenitionisaspermissiveontheadversaryaspossible.Inotherwords,wedeemtheadversarysuccessfulifshesucceedsinanynon-obviousway.Examplesofobviouswinningstrategiesarewhentheadversaryrevealsthesessionkeyofthetargetsession,orasessionpartneredtothetargetsession.Section4.2formalizestheseobviousstrategies,bydeningwhatitmeansforasessiontobepartneredtoanothersession,andhowafreshsessionisdened.TheactualdenitionofsecureAKEprotocolsisdescribedinSection4.3.4.1AModelforKeyExchangeProtocolsAsinthepreviouswork,weputtheadversaryin\thecenteroftheuniverse."Nomessageisdeliveredwithoutthepermissionoftheadversary.Theadversarycaneavesdropon,forge,redirect,replicate,change,delete,anddelaymessages.Moreover,theadversaryisfreetoobtaintheinternalstateofeachsession,orevenacquirethelong-termkeyofanypairofparties.Aninnovationinourmodelistheabilityoftheadversarytodynamicallycreateanetworkofinterconnectedparties.Inotherwords,theadversarycanfreelyregisternewpartiesinthesystem,andaskthesystemtosharealong-termkeybetweenanypairofregisteredpartiesinthesystem.ClockModel.Intwo-partyprotocols,everypairofpartieswishingtoshareasessionkeymayneedtohavesynchronizedclocks.ItisrarelyaproblemifthesharedclockbetweenAandBdiersfromthatofBandC.However,incorporatingdierentsharedclocksbetweenvariouspairsofpartiesmayresultinunnecessaryclutterinthemodel.Wethereforeassumeallpartiesinthesystemshareauniversalclock.Thesystemstartsintimestage1,whichisincrementedeveryseconds.ThevalueofthetimestageisstoredbythevariableT.4.1.1Adversarial&CommunicationModelTheinteractionsbetweentheadversaryandtheprotocolentitiescanbemodeledasathoughtex-periment.Thethoughtexperiment(orthegame)isplayedbetweenahypotheticalchallengerCand13 Table3.Session-specicvariablesstoredbyC. VariableDescription pidsxTheordinalidentierofthepartytowhomthesession(x;s)ispartnered. rndsxTherandomnessusedinthesession(x;s). rolesxTheroleofthesession(x;s),whichiseither`I'(initiator)or`R'(responder). sksxThesessionkeyofthesession(x;s). skTimesxThetimestageinwhichthesessionkeyofthesession(x;s)isset. accsxTheacceptancestateofthesession(x;s).Itisifthedecisionisyettobemade,0ifithasrejected,and1ifithasaccepted. statesxThestateofthesession(x;s).Weassumethatthisvariableencodes,amongotherinformation,thevalueofsidsx,pidsx,sksx,andaccsx. exposedsxABooleanvariable,indicatingwhethertheadversaryhasexposedthesession(x;s). Algorithm6.TheRegister()function. 1:Register()2:N N+1;3:idN Rf0;1g`(n);4:ID ID[f(idN;N)g;5:sessN PN ?;6:returnidN; time-independentupdate:UpdateLTK(T;KTxy)def=O(KTxy).ImmediatelyafterthenewkeyKT+1xyiscomputed,theoldkeyKTxyiswipedsecurely(SeeRemark2).AfterallLTKsareupdated,CstartsanewtimestagebyincreasingT,andnotiestheadversarybycallingNotify(A).ThepseudocodeoftheTimeEvent()functionisdescribedinAlgorithm5. Algorithm5.TheTimeEvent()function. 1:TimeEvent()2:for�x 1toN
3:for�y2Px
4:KT+1xy UpdateLTK(T;KTxy);5:KTxy ;//securewipeoftheLTK6:T T+1;7:Notify(A); ITheRegister()function.Theadversarycallsthisfunctiontointroduceanewpartyintothesystem.Uponreceivingthisquery,CincrementsN,andgeneratesarandom`(n)-bitidentieridN.Thepair(idN;N)isaddedtothesetID,andthesetofsessionsonN(sessN)andthesetofpartieswhoshareanLTKwithN(PN)aresettoempty.Finally,idNisreturnedtotheadversary.NoticethattheadversarycankeeptrackofNandIDbyherself,andthereforeCdoesnotbothertoreturnthesevalues.ThepseudocodeoftheRegister()functionisdescribedinAlgorithm6.15 ITheShareLTK(x;y)function.TheadversarycallsthisfunctiontoshareanLTKbetweenthepartieswhoseordinalidentiersarexandy.Thechallengerrstchecksifeitherxoryisnonexistent,whethertheyareidentical,andwhethertheyhavealreadysharedakey.Ifeitheroftheseconditionshold,theadversarylosesthegame.Otherwise,arandomK(n)-bitkeyissharedbetweenxandy,andtheywillbeaddedtothepartnersetofeachother.Noticethatbysymmetry,KTxy=KTyx.Finally,therevealtimeofbothkeysissettoinnity.ThepseudocodeoftheShareLTK(x;y)functionisdescribedinAlgorithm7. Algorithm7.TheShareLTK(x;y)function. 1:ShareLTK(x2N;y2N)2:if�x�Nory�Norx=yory2Px
3:output0andabort;4:KTyx KTxy Rf0;1gK(n);5:Px Px[fygandPy Py[fxg;6:revealTimexy revealTimeyx +1; ITheSend(x;s;y;m)function.Theadversarycallsthisfunctiontosendamessagemto(x;s),claimingthismessagecomesfrompartyy.Tostarttheprotocolontheinitiatorside,theadversarysendsazeromessage(m=0).Itisimplicitlyassumethatm=0isnotavalidprotocolmessage(whichisthecaseforvirtuallyallprotocols),andthereforeitisnotmisinterpretedbythereceivingparty.Ifpartyxorydonotexistinthesystem,orifydoesnothaveanLTKwithx,theadversarylosesthegame.Next,thechallengercheckswhetherthesession(x;s)exists,andifnot,initializes(orchanges)thefollowingvariables:sessx:Thesessionsisaddedtothisset.skTimesx:Itissetto0,whichmeansthatthesessionkeyisnotgeneratedyet.rndsx:Therandomnessofthecurrentsessionispickedrandomlyfromf0;1gr(n).rolesx:Iftheincomingmessageis0,thesessionroleissetto`I'.Otherwise,itissetto`R'.exposedsx:Itissettofalse(0),asthesessionisnotexposedyet.LetdenotetheAKEprotocolexecutedbyasingleparty.Torun(x;s)ontheincomingmessagem(allegedlyfromy),thechallengerfeedswiththefollowingpiecesofinformation:thelong-termkey(KTxy);thecurrenttimestage(T);thecurrentsessionstate(statesx);thesessionrandomness(rndsx);theidentiersofthecurrentpartyanditssessionpartner(idxandidy);andtheincomingmessage(m).Theoutputofistheoutgoingmessage(m0),andtheupdatedsessionstate(statesx),andtheupdatedrandomness(rndsx):(m0;statesx;rndsx) (KTxy;T;statesx;rndsx;idx;idy;m):ThereasonwhytherandomnessgetsupdatesisexplainedinthedescriptionoftheExposeSSfunction(seebelow).16 Algorithm9.TheExposeSS(x;s)function. 1:ExposeSS(x2N;s2N)2:if�x�Nors=2sessx
3:output0andabort;4:exposedsx 1;5:return(statesx;rndsx); ITheRevealLTK(x;y)function.Theadversarycallsthisfunctiontoreceivethelong-termkeybe-tweenpartiesxandy.Ifeitherpartyisnon-existent,ortheydonothaveanLTK,theadversarylosesthegame.Otherwise,thevariablesrevealTimexyandrevealTimeyxaresettoT,andKTxyisreturned.ThepseudocodeoftheRevealLTK(x;y)functionisdescribedinAlgorithm10. Algorithm10.TheRevealLTK(x;y)function. 1:RevealLTK(x2N;y2N)2:if�x�Nory�Nory=2Px
3:output0andabort;4:revealTimexy revealTimeyx T;5:returnKTxy; Inmostpapers,theadversaryisgivenaccesstoaCorrupt()query,whichreturnsalllong-termkeysstoredonasingleparty.RevealLTK()isamore exiblequery,sincetheadversarycanpicktheexactLTKshewantstoobtain.Moreover,sincetheadversaryknowsthesetPxofpartiestowhomxsharesanLTK,3shecaneectivelycorruptxbyrunningRevealLTK()onxandeverypartyinPx.GeneralAssumptions.WeassumethatandfIDsatisfythefollowingrulesforalls;x2N:Ifdetectsanerror,itreturnsanemptystringasthestateandtheoutgoingmessage.Oninputanemptystring,fIDoutputsthefollowtuple:(sidsx;pidsx;sksx;accsx)=(;�1;;0).NoteespeciallythatthepartnerIDissetto�1(invalidparty),andtheacceptancedecisionissetto0(false).Ifmisthelastmessageoftheprotocol,outputstheemptymessagem0=astheoutgoingmessage.Ifdoesnotdetectanerror,thefollowingassumptionsarealsotrue:pidsxissetassoonas(x;s)receivestherstmessage,andwillnotchangetoanyothervalueduringthelifetimeof(x;s).NeithersksxnorsidsxwillchangeafterskTimesxissettoTinline16.4.2SessionPartnershipandFreshnessBeforedeningwhatitmeansforanAKEprotocoltobesecure,weneedtodenetwocentralnotions:Sessionpartnership,andsessionfreshness.Ournotionofsessionpartnership,presentedinDenition1,isadoptedfrom[18].Denition1(SessionPartnership).Twosessions(x;s)and(y;t)arecalledpartnersifthefollowingconditionshold: 3ThisisbecausethepartiesshareanLTKifandonlyiftheadversaryusestheShareLTK()query.18 sessiontotriviallydeducethesessionkey.Forinstance,iftheadversaryexposesasessionafterthesessionkeyisestablished,thenshealreadyknowsthesessionkey.Thesameholdsiftheadversaryexposesthepartnersessionofasession.Therefore,itisimportanttoproperlydenethepartnersession,aswejustdid.InSection4.3,wewilldenethesecurityofAKEprotocolsasfollows:Wewillallowtheadversarytotargetanyfreshsession,andreceiveeitherthesessionkeyorarandomkey.Hergoalwillthenbetodistinguishthetwocases.Consequently,itisimportanttodenetheconceptoffreshsessionsaslooselyaspossible,sothatwhenaprotocolisprovedsecureinourmodel,itresistavarietyofattacks.OurdenitionoffreshnessispresentedinDenition2.Denition2(Freshness).Asession(x;s)iscalledfreshifthefollowingconditionshold(here,y=pidsx):1.skTimesxrevealTimexy;2.exposedsx=0;3.Lett FindPartnerSession(x;s).Ift6=�1,thenskTimetyrevealTimeyxandexposedty=0.Therstconditionisaforwardsecurityrequirement:IftheLTKisrevealedinatimestagelaterthantheoneinwhichthesessionkeyisestablished,thenthesessionkeyshouldremainprotected.NoticethattheinitialvaluesforskTimesxandrevealTimexyare0and+1,respectively.Therefore,condition1holdsevenifthesessionkeyisyettobeestablished,ortheLTKisnotrevealed.Thesecondconditionveriesthatthesessionisnotexposed.Finally,thethirdconditionexaminesthecasewhenthesessionhasapartner:Inthiscase,thepartnersessionshouldsatisfythersttwoconditionsabove.Cusesthefunctionfresh(x;s)inAlgorithm12tondwhetherthesession(x;s)isfresh,accordingtoDenition2. Algorithm12.Thefresh(x;s)function. 1:fresh(x2N;s2N)2:if�skTimesxrevealTimexyorexposedsx=1
3:return0;4:y pidsx;5:t FindPartnerSession(x;s);6:if�t6=�1
7:if�exposedty=1orskTimetyrevealTimeyx
8:return0;9:return1; 4.3AKESecurityDenitionUpuntilnow,wedenedageneralmodelforinteractionbetweenthepartiesandtheadversary.Giventhismodel,itisstraightforwardtogivethedenitionofwhatitmeansforanauthenticatedkeyexchange(AKE)protocoltobesecure.WerstneedtoaugmentthechallengerCwithtwomorequeries.WedenotetheaugmentedchallengerbyD.ThenewqueriesaretheTestquery,andtheGuessquery.Contrarytopreviousqueries,theadversarycanmaketheTestandGuessqueriesonlyonce.Moreover,theGuessqueryisthelastqueryinthesystem,afterwhichDannounceswhethertheadversarywins,andabortsthegame.InaTestquery,theadversaryspeciesatargetsession,whichmustbeafreshonecontainingasessionkey.Next,D ipsacoin,anddependingontheresult,answerswitheitherthesessionkey,orarandomvalue.Theadversarycontinuesthegamebymakingarbitraryqueries(exceptTestandGuess,20 DenotebyhD;Ai(n)thesingle-bitoutputofthechallengerD,whentheprotocolis,theadversaryisA,andthesecurityparameterisn.WeassumethatDoutputs0ifAhaltsbeforeDreturnsanyvalue.DenetheAKE-advantageofAbythefollowingequation:AdvakeA;D;(n)def=PrhD;Ai(n)=1�1 2;(2)wheretheprobabilityistakenovertherandomcoinsofDandA.WecannowdenethesecurityofAKEprotocols.Denition3(SecureAKE).AnAKEprotocoliscalled(n;T(n);(n))-secureif:maxAAdvakeA;D;(n) (n);(3)wherethemaximumistakenoverallprobabilisticalgorithmswhosesumofrunningtimeandcodesizeisatmostT(n).WecallasecureAKEifitis(n;T(n);(n))-secureforallpositivepolynomialsT(
)and1=(
),andallsucientlylargen.Thelastsentencerequiresclarication.First,if1=(
)isapolynomial,then(
)isaninversepolynomial.Therefore,therequirementbasicallystatesthatanyadversarywhoserunningtimeisapolynomialmusthaveanadvantageinwinningthegamewhichissmallerthantheinverseofanypolynomial(i.e.,theadvantagemustbenegligible).5ProvingtheAKESecurityofFORSAKESInthissection,weprovideproofsofAKEsecurityfortheFORSAKESprotocol.Theproofisquiteinvolved;therefore,itisdividedintoseveralparts.Therstpart,presentedinSection5.1,isinfactageneralproof,andisnotspecictoFORSAKES.Itshowsthatiftheadversarycreates(polynomially)morethantwopartiesinthesystem,herAKE-advantagedoesnotchangebymorethanapolynomial.Section5.2presentsseverallemmasaboutFORSAKESinamultipartysetting.Finally,Section5.3usestheaforementionedproofstoestablishthesecurityofFORSAKESinatwo-partysetting.5.1ReducingaMulti-PartySettingtoaTwo-PartySettingLetqregdef=qreg(n)andqltkdef=qltk(n)denoteupperboundsonthenumberofRegisterandShareLTKqueriesthattheadversarymakestoD.Furthermore,letqdef=q(n)beanupperboundonthetotalnumberofqueriesthattheadversarymakestoD.Theorem1statesthattheadversarycanachieveessentiallythesameAKE-advantage(uptoapolynomial),ifsheregistersexactlytwopartiesinthesystem,ratherthanpolynomiallymany.Theorem1.LetbeanyAKEprotocol(notnecessarilysecure).Foralln2Nandany(qreg;qltk){adversaryAagainstwhichrunsintimeatmostT(n),thereexistsa(2;1){adversarySwhichrunsintimeatmostTS(n)=TA(n)+q(n)
poly(n),suchthat:AdvakeS;D;(n)AdvakeA;D;(n) (qreg(n))2:Theproofessentiallyresultsfromthreefactsinthemodeling:1.Thelong-termkeys(KTxy)aregeneratedindependentlyfromeachother;2.Therandomnessofsessions(rndsx)aregeneratedindependentlyfromeachother;3.Thesessionstates(statesx)arestoredandupdatedindependentlyfromeachother.22 ISend(x;s;y;m),lines18–26.ThesimulatorSrstcheckswhetherfx;yg=f;g.Ifthisisthecase,Awantstosendamessagebetweentwospecialparties.Thisishandledbymakingthepropermapping(xtopxandytopy),andforwardingthequerytoD.Afterreceivingtheanswer(m0;sidsx;pidsx;skTimesx;accsx)fromD,thesimulatormodiespidsx.Itisbecauseinthereturnedvalue,pidsx=py;whereaspyshouldbemappedbacktoy.Thisisconsistentwiththecommentonline14ofAlgorithm8.Iffx;yg6=f;g,thenAwantstosendamessagebetweentwonon-specialparties,orbetweenaspecialandanon-specialparty.Inthiscase,Algorithm8isexecuted,andtheresult(m0;sidsx;pidsx;skTimesx;accsx)isreceived.Ineithercase,thetuple(m0;sidsx;pidsx;skTimesx;accsx)isreturnedtoA.Thistupleisgeneratedbyrunningtheprotocol,andthenextractingtheinformationfromstatesxviathefunctionfID(seelines13{16ofAlgorithm8).Noticethattheinputstoaredistributedidenticallyregardlessofwhetherfx;yg=f;gornot:Thelong-termkeyandthesessionrandomnessarealwaysuniformlyrandom,andthesessionstatestatesxisinitiallyempty.ThetimestageTisincrementedindependently,andtherestoftheinputsto(i.e.,idx,idy,andm)aredeterminedbytheadversary.Therefore,fromtheviewpointofA,theoutputofSendisidenticallydistributedregardlessofwhetherfx;yg=f;gornot,andSsimulatesthisqueryperfectly.IExposeSS(x;s),lines27–35.Thesimulatorrstndsthepartnerofthesession(x;s)bylettingy pidsx.Ifbothpartnersarethespecialparties,theExposeSSqueryisforwardedtoD(makingpropermappings),andtheresultsarereturnedtoA.Otherwise,Algorithm9isexecuted,andtheresultsarereturnedtoA.Inbothcases,thereturnedvalueisoftheform(statesx;rndsx).Asexplainedabove(whiledescribingthewayaSendqueryistreated),thesevaluesareidenticallydistributedregardlessofwhetherAisdealingwithspecialpartiesornot.Therefore,Ssimulatesthisqueryperfectly.IRevealLTK(x;y),lines36–42.Ifthisqueryismadeforthekeysharedbetweenthespecialpar-ties,Dwillrespondthequery(Smakespropermappingsbeforehand).Otherwise,Algorithm10isexecuted.Inbothcases,along-termkeyisreturned,whichisdistributedrandomly,andisconsistentwiththerestofA'sview.Therefore,Ssimulatesthisqueryperfectly.ITest(x;s),lines43–49.ThisistheonlyquerywhereSmayfailtosimulatetheviewofA.Thesimulatorrstndsthepartnerofthetestsession(x;s)bylettingy pidsx.Ifthepartnersofthetestsessionarethespecialparties,thequeryisforwardedtoD(makingpropermappings),andtheresultisreturnedtoA.Otherwise,thesimulatorfails.ThisfailureisnotbecauseScannotcontinuethesimulation;rather,continuingthesimulationispointless.ThisisbecauseSshouldmakeatmosttworegisterqueriestoD,andthenattempttodistinguisharandomvaluefromthesessionkeyofoneofthesessionsbetweenthesetwoparties,usingAasaguide.IfApicksatestsessionwhosepartnersarenotthespecialparties,thenScannotattainitsgoal,andfailsasaresult.SinceSperfectlysimulatesthewholeexperimentuptoaTestquery,Ahasnowayofdistinguishingspecialandnon-specialparties.Therefore,asAhasregisteredatmostqregpartiesbeforeaTestquery,thereareatmost�qreg2
q2regpairsofpartiesinthesystem.Consequently,theprobabilitythatbothpartnersofthetestsessionarespecialpartiesisatleast1=q2reg.Asaresult,theprobabilitythatthesimulationdoesnotfailisatleast1=q2reg.Noticethatifthisisthecase,theviewoftheadversaryAissimulatedperfectly.25 PropertiesofFORSAKESmessages.LetMbethesetofnonemptymessageswhichthead-versaryreceivesfromparties.InFORSAKES,therstmessageisnotequippedwithanintegritymechanism(suchasaMAC),anditcanbeforgedeasily.However,thesecondandthirdmessagesareauthenticated.AssumetheadversaryissuesaSend(x;s;y;m)query,wheremisthesecondorthirdprotocolmessage(i.e.,itisprexedwitheither`2'or`3').Lemma1andLemma2(inthenextsection)considertwoseparatecases,dependingonwhethermbelongstoMornot.Lemma1.Letm2MbethesecondorthirdmessageofFORSAKES,deliveredviaSend(x;s;y;m).Assumethatafterthedelivery,accsx=1.Then,theprobabilityofthefollowingeventsis0(assuminganon-collidingexecution):1.mwasgeneratedbyanypartyotherthany;2.mwasdestinedatanysessionotherthan(x;s).Thelemmaholdsevenifalllong-termandsessionkeysinthesystemareknowntotheadversary.Proof.First,noticethatsincethemessagemisgeneratedbysomepartyinthesystem,itisnotimportantwhichkeysareknowntotheadversary;shemerelytakesthedelivery.Anysecond-or-thirdFORSAKESmessagem2Misauthenticated.Sincemincludestheidentiersofthesenderandreceiverrespectively,(x;s)rejectsmifthesenderisanypartyotherthany.Consequently,accsx=1showsthatthesendermusthavebeeny,andcase(1)isruledout.ThesecondandthethirdmessagesofFORSAKEScarrythesessionidentier.Sincetheexecutionisassumedtobenon-colliding,itisimpossiblethatthemessagehavebeendestinedatanysessionotherthan(x;s),andaccsx=1.Therefore,case(2)isruledoutaswell.Remark3.Lemma1shows,inparticular,thatparallelsessionattacks[6]areimpossibleagainstFORSAKES.CThenextsectionconsidersthecasem=2M,andconcludestheproofoftheAKEsecurityofFORSAKES.5.3ProofofAKE-SecurityofFORSAKESinaTwo-PartySettingInSection5.1,weprovedthatanyecientadversaryAagainstanAKEprotocolinamulti-partysystemcanbereducedtoaanecientadversarySagainstanAKEprotocolinatwo-partysystem,suchthattherunningtimesandadvantagesofAandSareidenticaluptoapolynomial.Therefore,thissectionrestrictstheadversariestothoseregisteringatmosttwoparties.Wealsoassumethattheadversaryagainstatwo-partysystemdoesnotmake\foolish"actionswhichresultinimmediatelossofthegame.Severalofsuchassumptionsaredetailedbelow:AnyadversaryregisteringlessthantwopartieshasanAKEadvantageof0,sincetherewillbenotestsessiontoattack.Therefore,weassumethattheadversaryregistersexactlytwoparties.Letxandydenotetheordinalidentiersofthetworegisteredparties,inarbitraryorder.Thatis,fx;yg=f1;2g.Iftheadversarydoesnotshareanylong-termkeysbetweenxandy,orshetriestosharemorethanonelong-termkeysbetweenthem,shewillhaveanAKEadvantageof0.Therefore,weassumethattheadversaryregistersexactlyonelong-termkeyKTxy=KTyxbetweenxandy.Let(X;S)denotethetestsession,and(Y;S)bethesessionpartneredtoit(thelatterdoesnotnecessarilyexist).Iftheadversaryexposes(X;S)or(Y;S),thenshewillhaveanAKEadvantageof0.Therefore,weassumethattheadversarydoesnotmakethequeriesExposeSS(X;S)orExposeSS(Y;S).27 Algorithm16.ThealgorithmwhichFO;ROK;TOK;VOK(1n)usestohandle(i.e.,protocolFORSAKES).Weas-sumethattheinputiswellformed,anddonotcheckforsyntacticalissues.Notethatinthisexperiment,FonlyusestheTOKandVOKoracles. Function(�;T;statesx;rndsx;idx;idy;m) 1:m0 st ; Casem=0:2:sidsx rndsxjjr;//`*'isawildcard3:m0 1jjidxjjidyjjTjjrndsx;4:st sidsxjj`I'jjidyjjTjj0kjj0kjj; Casem=1jjidsjjidrjjTjjns:5:if�ids6=idyoridr6=idx
6:return(m0;st);7:sidsx nsjjrndy;8:Msg2 2jjidxjjidyjjTjjsidsx;9:Auth2 TOK(Msg2;1jjsidsx);10:m0 Msg2jjAuth2;11:st sidsxjj`R'jjidyjjTjj0kjj0kjj; Casem=Msg2z }| {2jjidsjjidrjjTjjsidjjAuth2:12:if�ids6=idyoridr6=idxorsid6=sidsx
13:return(m0;st);14:sidsx sid;//Nomorewildcards.15:if�:VOK(Msg2;1jjsidsx;Auth2)
16:return(m0;st);17:if�m=2Mandfresh(x;s)
18:output(Msg2;1jjsidsx;Auth2)andabort;19:Msg3 3jjidxjjidyjjTjjsidsx;20:Auth3 TOK(Msg3;1jjsidsx);21:m0 Msg3jjAuth3;22:st sidsxjj`I'jjidyjjTjj0kjj0kjj1; Casem=Msg3z }| {3jjidsjjidrjjTjjsidjjAuth3:23:if�ids6=idyoridr6=idxorsid6=sidsx
24:return(m0;st);25:if�:VOK(Msg3;1jjsidsx;Auth3)
26:return(m0;st);27:if�m=2Mandfresh(x;s)
28:output(Msg3;1jjsidsx;Auth3)andabort;29:m0 ;30:st sidsxjj`R'jjidyjjTjj0kjj0kjj1; 31:return(m0;st); Iftheadversaryrevealseitherthelong-termkeysKTxyorKTyxbeforeoratthesametimestagethatthetestsessiongeneratesthesessionkey,shewillhaveanAKEadvantageof0.Therefore,weassumethattheadversaryeitherdoesnotmakeRevealLTK(x;y)orRevealLTK(y;x)query,ormakeseitherofthesequeriesinatimestageafterthesessionkeyofthetestsessionisgenerated.Lemma2pertaintothecasem=2M,wheretheadversaryAsuccessfullyforgesasecond-or-thirdmessageofFORSAKES.Itisthe\dual"ofLemma1intheprevioussection,whichconsideredthecasem2M.Onahighlevel,Lemma2convertsanadversarywhosuccessfullydeliversasecond-or-thirdmessagem=2M(withoutbeingdetected),toanadversarywhoforgesamessageauthenticationcode.Fordiscussionsrelatedtotheconstructionandsecurityofarandom-oraclebasedMAC,seeAppendixA.Letqro(n)denoteanupperboundonthenumberofthequerieswhichtheadversarymakestotherandomoracle.Lemma2.LetAbeanadversaryagainstFORSAKES,whosucceedswithprobabilityA(n)indeliv-eringasecond-or-thirdmessagem=2Minanon-collidingexecution,toafreshsession(x;s),after28 qsndqueriesatTOK,andqsndqueriesatVOK.Thisisbecauseeachmessagesentmayneedatagverication,andataggeneration.Wenowpertaintotherunning-timeanalysisofF.NoticethatFanswerseachqueryofAwithatmostapolynomialoverhead.Therefore,therunningtimeTF(n)ofFisTA(n)+q(n)
poly(n).ItisnoweasytoprovethatFORSAKESisasecureAKEprotocol,becausewejustprovedthattheadversaryhasverylittlechanceofdeliveringmessagesatthewrongdestination,orforgingmessages.Theorem2(MainTheorem).Inthetwo-partysetting,FORSAKESisasecureAKEprotocol,asperDenition3.Proof.Denethefollowingevents:E1:Twopartiesreceivethesameidentier.E2:Thesystemiscolliding.E3:Theadversarysuccessfullydeliversasecond-or-thirdmessagem2M,withafakesourceoratawrongdestination.E4:Theadversarysuccessfullyforgesasecond-or-thirdmessagem=2M,whosedestinationsessionisfresh.Thefactsandlemmasinthisandprevioussectionsprovedthattheprobabilitythateitherofoftheseeventshappenisexponentiallysmallinn.Therefore,letusconditiontheprobabilitiesontheevent E1^ E2^ E3^ E4.Basedontheconditioningabove,theadversaryhasthreechoices:1.Faithfullydeliveramessage;2.Delaythedeliveryofamessagebeyondatimestage;3.Deleteamessage.InFORSAKES,option(2)causesthedestinationsessiontoreject,andoption(3)preventsthegen-erationofthesessionkeyatthedestinationsession.Therefore,theadversaryisleftwithoption(1).However,ifshedeliversmessagesfaithfully,andtargetsafreshsessionusingtheTestquery,shewillreceivearandomandindependentvaluekey,regardlessoftheinternalcointossofTest.Therefore,theadvantageofAinguessingthevalueofthecoinis0.ThefollowingcorollaryisimmediatebycombiningTheorem2withTheorem1.Corollary3.FORSAKESisasecureAKEprotocol,regardlessofthenumberofpartiesinthesystem.6FORSAKESinPractice6.1ReplacingtheRandomOracleOneofthemostimportantissuesregardingFORSAKESisitsuseoftherandomoraclemodel.Asin[35],wenotethattherandomoraclewasmerelyatoolusedintheproofs,anditcanbereplacedwithpseudorandomfunctions[31].Thisisbecausewedidnotuseanyoftherandomoraclefacilities,suchastheabilitytointerceptthequeriesorprogramtheresponse.Thereareecientpseudorandomfunctionssuchas[32],whichcanbeusedinpracticeifprovablesecurityisdesired.However,ifevenfasterimplementationsarenecessary,wesuggesttheuseofencryptionfunctionssuchasAES,orhashfunctionssuchasSHA-1.See[35,Section6]formoreinformation.ItisalsopossibletousealgorithmssuchasPBKDF2(Password-BasedKeyDerivationFunction2),proposedbyRFC2898.30 [36]SimonBlake-WilsonandAlfredMenezes.EntityAuthenticationandAuthenticatedKeyTransportPro-tocols:EmployingAsymmetricTechniques.InProceedingsofthe5thInternationalWorkshoponSecurityProtocols(SPW'97),pages137{158,Paris,France,1998.Springer.[37]MihirBellareandPhillipRogaway.ProvablySecureSessionKeyDistribution:TheThreePartyCase.InProceedingsofthe27thAnnualACMSymposiumonTheoryofComputing(STOC'95),pages57{66,LasVegas,Nevada,USA,1995.ACM.[38]Kim-KwangRaymondChoo,ColinBoyd,YvonneHitchcock,andGregMaitland.OnSessionIdentiersinProvablySecureProtocols:TheBellare{RogawayThree-PartyKeyDistributionProtocolRevisited.InSecurityinCommunicationNetworks(SCN2004),pages351{366,Amal,Italy,2005.Springer.[39]VictorShoupandAviRubin.SessionKeyDistributionUsingSmartCards.InAdvancesinCryptology|EUROCRYPT'96,pages321{331,Saragossa,Spain,1996.Springer.[40]MihirBellare,RanCanetti,andHugoKrawczyk.AModularApproachtotheDesignandAnalysisofAuthenticationandKeyExchangeProtocols(ExtendedAbstract).InProceedingsofthe30thAnnualACMSymposiumonTheoryofComputing(STOC'98),pages419{428,Dallas,Texas,USA,1998.ACM.[41]VictorShoup.OnFormalModelsforSecureKeyExchange.Technicalreport,IBMZurichResearchLab,1999.Version4isavailableathttp://eprint.iacr.org/1999/012.[42]ChristinaBrzuska,MarcFischlin,BogdanWarinschi,andStephenCWilliams.ComposabilityofBellare-RogawayKeyExchangeProtocols.InProceedingsofthe18thACMConferenceonComputerandCom-municationsSecurity(CCS2011),pages51{62,Chicago,Illinois,USA,2011.ACM.[43]ChristinaBrzuska,MarcFischlin,NigelPSmart,BogdanWarinschi,andStephenCWilliams.LessisMore:RelaxedyetComposableSecurityNotionsforKeyExchange.InternationalJournalofInformationSecurity,12(4):267{297,2013.[44]RanCanettiandHugoKrawczyk.UniversallyComposableNotionsofKeyExchangeandSecureChannels(ExtendedAbstract).InAdvancesinCryptology|EUROCRYPT'02,pages337{351,Amsterdam,TheNetherlands,2002.Springer.Fullversionisavailableathttp://eprint.iacr.org/2002/059.[45]RanCanetti.UniversallyComposableSecurity:ANewParadigmforCryptographicProtocols(ExtendedAbstract).InProceedingsofthe42ndAnnualIEEESymposiumonFoundationsofComputerScience(FOCS'01),page136,Washington,DC,USA,2001.IEEEComputerSociety.See[58]forthefullversion.[46]DennisHofheinz,JornMuller-Quade,andRainerSteinwandt.Initiator-ResilientUniversallyCompos-ableKeyExchange.InProceedingsofthe8thEuropeanSymposiumonResearchinComputerSecurity(ESORICS2003),pages61{84,Gjvik,Norway,2003.Springer.[47]RanCanetti,ShaiHalevi,JonathanKatz,YehudaLindell,andPhilMacKenzie.UniversallyComposablePassword-BasedKeyExchange.InAdvancesinCryptology|EUROCRYPT2005,pages404{421,Aarhus,Denmark,2005.Springer.Fullversionisavailablefromhttp://eprint.iacr.org/2005/196.[48]JanCamenisch,AnnaLysyanskaya,andGregoryNeven.PracticalYetUniversallyComposableTwo-ServerPassword-AuthenticatedSecretSharing.InProceedingsofthe19thACMConferenceonComputerandCommunicationsSecurity(CCS2012),pages525{536,Raleigh,NC,USA,2012.ACM.[49]CasJ.Cremers.Session-stateRevealIsStrongerThanEphemeralKeyReveal:AttackingtheNAXOSAu-thenticatedKeyExchangeProtocol.InProceedingsofthe7thInternationalConferenceonAppliedCryp-tographyandNetworkSecurity(ACNS'09),pages20{33,Paris-Rocquencourt,France,2009.Springer.[50]AugustinP.Sarr,PhilippeElbaz-Vincent,andJean-ClaudeBajard.ANewSecurityModelforAuthenti-catedKeyAgreement.InProceedingsofthe7thInternationalConferenceonSecurityandCryptographyforNetworks(SCN'10),pages219{234,Amal,Italy,2010.Springer.[51]KazukiYoneyamaandYunleiZhao.TaxonomicalSecurityConsiderationofAuthenticatedKeyExchangeResilienttoIntermediateComputationLeakage.InProceedingsofthe5thInternationalConferenceonProvableSecurity(ProvSec2011),pages348{365,Xi'an,China,2011.Springer.[52]Kim-KwangRaymondChoo,ColinBoyd,andYvonneHitchcock.ExaminingIndistinguishability-BasedProofModelsforKeyEstablishmentProtocols.InAdvancesinCryptology|ASIACRYPT'05,pages585{604,Chennai,India,2005.Springer.34 Construction1(RO-MAC).Letadef=a(n)andbdef=b(n)betwopolynomials,andO:f0;1g!f0;1gabearandomoracle.TheRO-MACisobtainedfromOasfollows:Gen(1n)picksarandomkeyKfromf0;1gb.ThetagofamessagemisO(Kjjm).Finally,Verif(K;m;t)outputs1ifandonlyift=O(Kjjm).CItiseasytoshowthatRO-MACisasecureMAC,butwedonotprovethisfacthere.Thisisbecausethesecurityofourprotocol(FORSAKES)doesnotdependonthesecurityofRO-MAC.Rather,FORSAKESdependsonamoreelaborateMAC,whichwewillconstructandproveitssecuritynext.ThenewconstructioniscalledRO-Multi-MAC.Inthisconstruction,thereisasinglepre-sharedkeyK,whichisusedtogenerateMACkeysusedtoformMACs.Construction2providesamoreformaldescriptionofRO-Multi-MAC.Construction2(RO-Multi-MAC).Leta,b,andObeasinConstruction1.TheRO-Multi-MACisobtainedfromOasfollows:Gen(1n)picksarandomkeyKfromf0;1gb.ThetagsarenotobtainedfromKdirectly.Rather,anypartywhoknowsKcanqueryO(Kjj
)atpointsofhischoice(x's),toobtainoneormoreMACkeys(kx's).ThetagofamessagemunderavalidMACkeykxisapair(x;t=O(kxjjm)).Finally,Verif(K;m;x;t)outputs1ifandonlyift=O(O(Kjjx)jjm).CBelow,wewillprovethatRO-Multi-MACisstronglysecure.Thatis,wegivetheadversaryabilitiesbeyondwhatisrequiredinaMAC-Forgeexperiment,andshowthatRO-Multi-MACissecureevenagainstsuchstrongadversaries.InanormalMAC-Forgeexperiment,theadversaryobtainstagsonmessagesofherchoice.Wewouldliketoextendherabilities,andallowhertorevealanynumberofMACkeys(k's).ShewinstheexperimentifandonlyifthetagisavalidMACunderanyoftheunrevealedk's,andshehasnotpreviouslyobtainedatagforthemessage.Furthermore,theadversaryisgivenaccesstoaVOKoracle,andshecancheckforthevalidityofatagformessagesofherchoice.AnexperimentdesignedtocapturethesecurityofRO-Multi-MAC.LetuseformalizethesecurityofRO-Multi-MAC,bydesigninganewexperimentcalledMulti-MAC-Forge.Inthisexperiment,theadversaryFisgivenaccesstofouroracles:1.TherandomoracleO:AnordinaryrandomoracleO:f0;1g!f0;1ga.2.TherevealoracleROK:Oninputx,revealstheMACkeykx=O(Kjjx).Thisoraclealsoaddsxtothesetrev.Thesetisusedwhentheexperimentwantstoverifytheoutputoftheadversary:Sheisnotallowedtooutputthetagforamessageunderarevealedkey.3.Thetag-generationoracleTOK:Oninput(m;x),returnstheMACtofmunderkx,bycomput-ingkx O(Kjjx)andt O(kxjjm).Thisoraclealsoaddsthepair(m;x)tothesetAsked.Thesetisusedwhentheexperimentwantstoverifytheoutputoftheadversary:Sheisnotallowedtooutputthetagforamessageforwhichshehasalreadyobtainedatag.4.ThevericationoracleVOK:Oninput(m;x;t),computesthevalidtagformunderthekeykx O(Kjjx),andreturnstrueifandonlyifthetagequalst.Remark5.Wewillassume,withoutlossofgenerality,thatFnevermakesthesamequerytwicetoanyofheroracles.Moreover,ifsheobtainsatagforsomemessage,shewillnotverifythetag.C36 FORSAKES:AForward-SecureAuthenticatedKeyExchangeProtocolBasedonSymmetricKey-EvolvingSchemesMohammadSadeqDoustiandRasoolJaliliData&NetworkSecurityLab,DepartmentofComputerEngineering,SharifUniversityofTechnology,Tehran,IranMarch1,2014Thispapersuggestsamodelandade\fnitionforforward-secureauthenticatedkeyexchange(AKE)protocols,whichcanbesatis\fedwithoutdependingontheDie-Hellmanassumption.Thebasicideaistousekey-evolvingschemes(KES),wherethelong-termkeysofthesystemgetupdatedregularlyandirreversibly.Protocolsconformingtoourmodelcanbehighlyecient,sincetheydonotrequiretheresource-intensivemodularexponentiationsoftheDie-Hellmanprotocol.Wealsointroduceaprotocol,calledFORSAKES,andproverigorouslythatitisaforward-secureAKEprotocolinourmodel.FORSAKESisaveryecientprotocol,andcanbeimplementedbymerelyusinghashfunctions.Keywords.AuthenticatedKeyExchangeProtocol,ForwardSecurity,KeyEvolvingSchemes,ProvableSecurity,SecurityModel.1Introductionsecurechannelsisaprominentprobleminsecurenetworks.Transmittingcon\fdentialdata,orensuringitsintegrityoverapublicchannelisimpossiblewithoutsecurechannels.Whilecommunicatingpartiescanutilizetheirlong-termkeys(LTKs)forcon\fdentialityorintegrity,itisgenerallyconsideredabadpractice.Thestandardapproachisto\frstexchangeephemeralkeys,andthenusethesekeystoestablishsecurechannels.Onthesurface,designingecientandsecureauthenticatedkey-exchange(AKE)protocolsdoesnotseemtobeacomplicatedtask.However,thehistoryshowsotherwise.Oneoftheearliestkeyexchangeprotocols,theNeedham{Schroederprotocol[],wassoonfoundtohaveasubtle\raw[].AnotherexampleistheOtway{Rees[]protocol,whichisshowntobesusceptibletotypingattacksattacks4,5Inanotherwork,Birdetal.al.6]formulatedanattackcalledparallelsessionattack,andshowedthatseveralprotocolswerevulnerabletoit.Inparticular,theattackwassuccessfullymountedonseveralproposedISO-9798protocols.Itisinterestingtoknowthat,afterover20years,theISO-9798familyofprotocolsisstillopentosomeattacks[].AsurveyofattacksagainstentityauthenticationandAKEprotocolscanbefoundin[OneofthemainreasonsfortheexistenceofsuchattacksistheconcurrentnatureofAKEprotocols.ThedesignersofvulnerableAKEprotocolsoftenfailtoaccountforallpossiblescenarioswhichcanhappeninaconcurrentsetting.Amoreimportantreason,identi\fedbycryptographersafterawhile,wasthelackofapropermodelandde\fnitionforAKEprotocols.modelspeci\festheresources(time,space,etc.)availabletoeachpartyandtheadversary,thewaytheycommunicate,andthespecialabilitiesattheadversary'sdisposal(capturingallpossible FORSAKES:AForward-SecureAuthenticatedKeyExchangeProtocolBasedonSymmetricKey-EvolvingSchemesMohammadSadeqDoustiandRasoolJaliliData&NetworkSecurityLab,DepartmentofComputerEngineering,SharifUniversityofTechnology,Tehran,IranMarch1,2014Thispapersuggestsamodelandade\fnitionforforward-secureauthenticatedkeyexchange(AKE)protocols,whichcanbesatis\fedwithoutdependingontheDie-Hellmanassumption.Thebasicideaistousekey-evolvingschemes(KES),wherethelong-termkeysofthesystemgetupdatedregularlyandirreversibly.Protocolsconformingtoourmodelcanbehighlyecient,sincetheydonotrequiretheresource-intensivemodularexponentiationsoftheDie-Hellmanprotocol.Wealsointroduceaprotocol,calledFORSAKES,andproverigorouslythatitisaforward-secureAKEprotocolinourmodel.FORSAKESisaveryecientprotocol,andcanbeimplementedbymerelyusinghashfunctions.Keywords.AuthenticatedKeyExchangeProtocol,ForwardSecurity,KeyEvolvingSchemes,ProvableSecurity,SecurityModel.1Introductionsecurechannelsisaprominentprobleminsecurenetworks.Transmittingcon\fdentialdata,orensuringitsintegrityoverapublicchannelisimpossiblewithoutsecurechannels.Whilecommunicatingpartiescanutilizetheirlong-termkeys(LTKs)forcon\fdentialityorintegrity,itisgenerallyconsideredabadpractice.Thestandardapproachisto\frstexchangeephemeralkeys,andthenusethesekeystoestablishsecurechannels.Onthesurface,designingecientandsecureauthenticatedkey-exchange(AKE)protocolsdoesnotseemtobeacomplicatedtask.However,thehistoryshowsotherwise.Oneoftheearliestkeyexchangeprotocols,theNeedham{Schroederprotocol[],wassoonfoundtohaveasubtle\raw[].AnotherexampleistheOtway{Rees[]protocol,whichisshowntobesusceptibletotypingattacksattacks4,5Inanotherwork,Birdetal.al.6]formulatedanattackcalledparallelsessionattack,andshowedthatseveralprotocolswerevulnerabletoit.Inparticular,theattackwassuccessfullymountedonseveralproposedISO-9798protocols.Itisinterestingtoknowthat,afterover20years,theISO-9798familyofprotocolsisstillopentosomeattacks[].AsurveyofattacksagainstentityauthenticationandAKEprotocolscanbefoundin[OneofthemainreasonsfortheexistenceofsuchattacksistheconcurrentnatureofAKEprotocols.ThedesignersofvulnerableAKEprotocolsoftenfailtoaccountforallpossiblescenarioswhichcanhappeninaconcurrentsetting.Amoreimportantreason,identi\fedbycryptographersafterawhile,wasthelackofapropermodelandde\fnitionforAKEprotocols.modelspeci\festheresources(time,space,etc.)availabletoeachpartyandtheadversary,thewaytheycommunicate,andthespecialabilitiesattheadversary'sdisposal(capturingallpossible FORSAKES:AForward-SecureAuthenticatedKeyExchangeProtocolBasedonSymmetricKey-EvolvingSchemesMohammadSadeqDoustiandRasoolJaliliData&NetworkSecurityLab,DepartmentofComputerEngineering,SharifUniversityofTechnology,Tehran,IranMarch1,2014Thispapersuggestsamodelandade\fnitionforforward-secureauthenticatedkeyexchange(AKE)protocols,whichcanbesatis\fedwithoutdependingontheDie-Hellmanassumption.Thebasicideaistousekey-evolvingschemes(KES),wherethelong-termkeysofthesystemgetupdatedregularlyandirreversibly.Protocolsconformingtoourmodelcanbehighlyecient,sincetheydonotrequiretheresource-intensivemodularexponentiationsoftheDie-Hellmanprotocol.Wealsointroduceaprotocol,calledFORSAKES,andproverigorouslythatitisaforward-secureAKEprotocolinourmodel.FORSAKESisaveryecientprotocol,andcanbeimplementedbymerelyusinghashfunctions.Keywords.AuthenticatedKeyExchangeProtocol,ForwardSecurity,KeyEvolvingSchemes,ProvableSecurity,SecurityModel.1Introductionsecurechannelsisaprominentprobleminsecurenetworks.Transmittingcon\fdentialdata,orensuringitsintegrityoverapublicchannelisimpossiblewithoutsecurechannels.Whilecommunicatingpartiescanutilizetheirlong-termkeys(LTKs)forcon\fdentialityorintegrity,itisgenerallyconsideredabadpractice.Thestandardapproachisto\frstexchangeephemeralkeys,andthenusethesekeystoestablishsecurechannels.Onthesurface,designingecientandsecureauthenticatedkey-exchange(AKE)protocolsdoesnotseemtobeacomplicatedtask.However,thehistoryshowsotherwise.Oneoftheearliestkeyexchangeprotocols,theNeedham{Schroederprotocol[],wassoonfoundtohaveasubtle\raw[].AnotherexampleistheOtway{Rees[]protocol,whichisshowntobesusceptibletotypingattacksattacks4,5Inanotherwork,Birdetal.al.6]formulatedanattackcalledparallelsessionattack,andshowedthatseveralprotocolswerevulnerabletoit.Inparticular,theattackwassuccessfullymountedonseveralproposedISO-9798protocols.Itisinterestingtoknowthat,afterover20years,theISO-9798familyofprotocolsisstillopentosomeattacks[].AsurveyofattacksagainstentityauthenticationandAKEprotocolscanbefoundin[OneofthemainreasonsfortheexistenceofsuchattacksistheconcurrentnatureofAKEprotocols.ThedesignersofvulnerableAKEprotocolsoftenfailtoaccountforallpossiblescenarioswhichcanhappeninaconcurrentsetting.Amoreimportantreason,identi\fedbycryptographersafterawhile,wasthelackofapropermodelandde\fnitionforAKEprotocols.modelspeci\festheresources(time,space,etc.)availabletoeachpartyandtheadversary,thewaytheycommunicate,andthespecialabilitiesattheadversary'sdisposal(capturingallpossible