AuthenticatedEncryption

KennyPaterson

InformationSecurityGroup

@kennyog;www.isg.rhul.ac.uk/~kp

MotivationforAuthenticatedEncryption

3

AuthenticatedEncryption(AE)

Securitygoals:

ConfidentialityandintegrityofmessagesexchangedbetweenAliceandBob.

Adversarialcapabilities:

Adversarycanarbitrarilydelete,reorder,modify,etc,bitsonthewire.

Adversarycanmountchosenplaintextandchosenciphertextsattacks–formalisedviaencryptionanddecryptionoracles.

Toolswehave:

Encryption(e.g.blockcipherinCBCmode,CTRmode,streamcipher)andMACalgorithms(e.g.HMAC,CBC-MAC).

m1

m2

4

FormalisingSymmetricEncryption

Asymmetricencryptionschemeconsistsofatripleofalgorithms:(KGen,Enc,Dec).

KGen:keygeneration,selectsakeyKuniformlyatrandomfrom{0,1}k.

Enc:encryption,takesasinputkeyK,plaintextm∈{0,1}∗andproducesoutput c∈{0,1}∗.

Dec:decryption,takesasinputkeyK,ciphertextC∈{0,1}∗andproducesoutput m∈{0,1}∗oranerrormessage,denoted┴.

Correctness:werequirethatforallkeysK,andforallplaintextsm,

DecK(EncK(m))=m.

Notes:

•  Encmayberandomised(cf.CBCmode,CTRmode).

•  Inreality,therewillbeamaximumplaintextlengththatcanbeencryptedbyagivenscheme.

•  Nonce-basedandstatefulformalismstofollowlater.

5

AuthenticatedEncryption–InformalDefinition

AsymmetricencryptionschemeissaidtoofferAuthenticatedEncryptionsecurityif:

Achosenplaintextattacker(i.e.anattackerwithaccesstoanencryptionoracle)canlearnnothingaboutplaintextsfromciphertextsexcepttheirlengths.

AND

Anattackerwithaccesstoanencryptionoraclecannotforgeanynewciphertexts.

•  Whatdoesitmean“tolearnnothingaboutplaintextsfromciphertexts”?

•  Howdoweformalise“cannotforgeanynewciphertexts”?

•  Whyisthatpropertyimportantanyway?

Weusesecuritygames,liketheoneintroducedpreviouslyforMACunforgeability.

6

IND-CPAsecurity

•  TheadversaryhasrepeatedaccesstoLeft-or-Right(LoR)encryptionoracle.

•  Ineachquery,theadversarysubmitspairsofequallengthplaintexts(m0,m1)totheoracle.

•  Wecanhavem0=m1,sowegetanencryptionoracle“forfree”.

•  Theadversarygetsbackc,anencryptionofmb,wherebisafixedbutrandombit.

•  Afterallqueriesaremade,theadversaryoutputsitsestimateb’forbitb.

•  Theadversarywinsifitdecidescorrectly.

IND=Indistinguishable

CPA=ChosenPlaintextAttack

7

IND-CPAsecurityinapicture

Adversary Challenger

b←{0,1}

(m0,m1)

c=EncK(mb)c

b’Adversarywinsifb=b’

K←KGen

8

IND-CPAsecurity

Theadversary’sadvantageintheIND-CPAsecuritygameisdefinedtobe:

|Pr(b=b’)-1/2|.

•  Wehave“-1/2”herebecauseadumbadversarycanalwaysguess.

•  AschemeSEissaidtobeIND-CPAsecureiftheadvantageis“small”foranyadversaryusing“reasonable”resources.

•  Conceptsof“small”and“reasonable”canbeformalised,butarebeyondthescopeofthistalk.

•  ItcanbeprovedthatschemeslikeCBC-modeandCTR-modemeetthissecuritydefinitionifusedproperlyandiftheyarebuiltusingagoodblockcipher.

9

Motivatingstrongersecurity

InCBCandCTRmodes,anactiveadversarycanmanipulateciphertextsandlearninformationfromhowthesearedecrypted.

•  ForCTRmode,bitflippinginplaintextistrivialbyperformingbitflippingintheciphertext.

•  ModifyctocXORΔtochangetheunderlyingplaintextfromptopXORΔ.

•  CBCmode:cutandpasteattacks,paddingoracleattacks.

•  Orcreatecompletelynewciphertextsfromscratch?

•  ArandomstringofbitsoftherightlengthisavalidciphertextforsomeplaintextforbothCBCandCTRmodes!

10

Motivatingstrongersecurity

•  ThesekindsofattackdonotbreakIND-CPAsecurity,butareclearlyundesirableifwewanttobuildsecurechannels.

•  Amodifiedplaintextmayresultinwrongmessagebeingdeliveredtoanapplication,orunpredictablebehaviouratthereceivingapplication.

•  Wereallywantsomekindofnon-malleableencryption,guaranteeingintegrityaswellasconfidentiality.

•  Twobasicsecuritynotions:integrityofplaintextsandintegrityofciphertexts.

11

INT-CTXTsecurityinapicture

Adversary Challenger

m

c=EncK(m)c

Adversarywinsifc*is“new”andm*≠┴

K←KGen

Try(c*)m*=DecK(c*)

12

IntegrityofCiphertexts–INT-CTXT

•  Attackerhasrepeatedaccesstoanencryptionoracleanda“Try”oracle.

•  Encryptionoracletakesanymasinput,andoutputsEncK(m).

•  Tryoracletakesanyc*asinput(andhasnooutput).

•  Adversary’staskistosubmitc*toitsTryoraclesuchthat:

1.  c*isdistinctfromalltheciphertextscoutputbytheencryptionoracle;and

2.  DecK(c*)decryptstomessagem*≠┴.

•  Henceadversarywinsifitcancreatea“ciphertextforgery”–anewciphertextthatitdidnotgetfromitsencryptionoracle.

•  NB:wedonotinsistthatm*bedifferentfromallthemqueriedtotheencryptionoracle,onlythatc*bedifferentfromalltheoutputsofthatoracle.

13

INT-CTXTsecurity

•  AsymmetricencryptionschemeissaidtoprovideINT-CTXTsecurityifthesuccessprobabilityofanyadversaryusingreasonableresourcesissmall.

•  Again,thiscanbemadeprecise(butnottoday!).

14

INT-PTXTsecurityinapicture

Adversary Challenger

m

c=EncK(m)c

Adversarywinsifm*is“new”andm*≠┴

K←KGen

Try(c*)m*=DecK(c*)

15

INT-PTXTsecurity

•  INT-PTXT:sameasINT-CTXT,butnowadversaryneedstocomeupwithaciphertextc*thatencryptsamessagem*suchthatm*wasneverqueriedtotheencryptionoracle.

•  Informally,INT-PTXTsecuritymeansthattheadversarycan’tforceanewplaintexttobeacceptedbythereceiver.

•  IfaschemeisINT-CTXTsecure,thenitisalsoINT-PTXTsecure.

•  Forasecurechannel,weactuallywantINT-PTXTsecurity,notINT-CTXTsecurity.(Why?)

DefinitionsforAESecurity

RecallthatasymmetricencryptionschemeissaidtoofferAuthenticatedEncryptionsecurityif:

Achosenplaintextattackercanlearnnothingaboutplaintextsfromciphertextsexcepttheirlengths.

ANDAnattackerwithaccesstoanencryptionoraclecannotforgeanynew

ciphertexts.

17

AESecurity

Moreformally,wecannowsaythat:

AE=IND-CPA+INT-CTXT

18

Whataboutchosenciphertextattacks?

•  Wearealsointerestedinsecurityagainstchosenciphertextattacks.

•  Heretheadversaryhasaccesstobothanencryptionoracleandadecryptionoracle.

•  LeadingtotheIND-CCAsecuritynotion,strongerthanIND-CPA.

•  Thisattackmodelmayariseinpractice,ortheattackermayhaveanapproximationtoadecryptionoracle.

•  Anattackermightnotbeabletolearnthefullplaintext,butcouldgetpartialinformationaboutthedecryptionprocess,forexample,errormessages,timinginformation,etc.

•  cf.paddingoracleattacks,ICMPattackonIPsec,etc.

19

IND-CCAsecurityinapicture

Adversary Challenger

b←{0,1}

(m0,m1)

c*=EncK(mb)c*

b’ Adversarywinsifb=b’

K←KGen

c

┴/m=DecK(c)┴/m

20

AESecurityimpliesIND-CCAsecurity

Informalreasoning:

•  SupposewehaveasuccessfulIND-CCAadversaryagainstanAE-securescheme.

•  Itsdecryptionoracleisonlyanyusetoitifitcancomeupwithanewandvalidciphertextc*notoutputbytheencryptionoracle.

•  Becauseotherwiseitknowstheunderlyingplaintextalready.

•  Butifitcancomeupwithanewciphertextc*,thenithasbrokenINT-CTXTsecurity!

•  Butthiscreatesacontradiction,sinceAEsecurityimpliesINT-CTXTsecurity.

•  Sowecanassumetheadversarynevercomesupwithavalidc*.

•  Thismeanswecanalwaysreplywith“┴”toanydecryptionquery.

•  ThismeanstheIND-CCAadversaryiseffectivelyreducedtobeinganIND-CPAone.

•  ButthiscontradictsAEsecuritytoo,sinceAEsecurityimpliesIND-CPAsecurity.

21

Relationsbetweensecuritynotions

AE:IND-CPA+INT-CTXT

IND-CCA IND-CPA+INT-PTXT

IND-CPA INT-PTXT

22

AEsecurityandbeyond

•  AEsecurityhasemergedasthenaturaltargetsecuritynotionforsymmetricencryption.

•  InpartbecauseAEsecurityimpliesIND-CCAsecurityandINT-PTXTsecurity.

•  Howeverit’snottheendofthestory:•  Inmanyapplicationswewanttointegrityprotectsomedataandprovide

confidentialityfortheremainder–AEwithAssociatedData,AEAD.

•  AEsecuritydoesnotprotectagainstattacksonsecurechannelsbasedonreorderingordeletionofciphertexts.

•  Forthis,weneedstatefulornonce-basedsecuritydefinitions.

Genericcomposition

GenericcompositionforAE

•  WehaveIND-CPAsecureencryptionschemes(e.g.CBCmode,CTRmode)andwehaveSUF-CMAsecureMACschemes.

•  CanwecombinethesetoobtainAEsecurityforsymmetricencryption?

•  ProblemfirstaddressedbyBellare-Namprempre(2000)andKrawczyk(2001).

•  Genericoptions:E&M,MtE,EtM.

•  (Inwhatfollows,KMdenotesaMACkey,andKEanencryptionkey.)

24

GenericcompositionforAE

Encrypt-and-MAC(E&M)

•  computec’←EncKE(m)andτ←TagKM(m)andoutputc=(c’,τ).

•  usedinSSHMAC-then-Encrypt(MtE)

•  computeτ←TagKM(m)andoutputc=EncKE(m||τ).

•  usedinTLSEncrypt-then-MAC(EtM)

•  computec’←EncKE(m)andτ←TagKM(c’)andoutputc=(c’,τ).

•  usedinIPsecESP“enc+auth”

25

SecurityofgenericcompositionforAE

•  Genericoptions:E&M,MtE,EtM.

•  Ofthese,onlyEtMgivesAEsecurityingeneral.

•  AssumingencryptionisIND-CPAsecureandMACisSUF-CMAsecure.

•  Intuition:MACingtheciphertextc’providesciphertextintegrity;IND-CPAsecurityofencryptioncarriesovertothecomposition.

•  Pluspoint:checkMAConciphertext,don’tevendecryptifitfails;notemptationforprogrammerto“usetheplaintextanyway”ifMACfails.

26

SecurityofgenericcompositionforAE

•  ToseewhyE&Mfailstobesecureingeneral:

•  SupposewehaveaSUF-CMAsecureMACscheme,withtaggingalgorithmTagKM(m).

•  ThinkabouttheMACschemewhichoutputsTagKM(m)||m.

•  IsitSUF-CMAsecure?

•  WhataboutthesecurityoftheresultingE&Mscheme?

27

SecurityofgenericcompositionforAE

ToseewhyMtEcanfailtobesecureismoresubtle.

Example

ConsidertheMtEencryptionschemeinwhichMACisprovidedbyHMACandtheencryptionschemeisprovidedbyCBC-modeusingsimplifiedTLSpadding.

GoodMAC(SUF-CMA)andgoodencryptionscheme(IND-CPA)!

•  KGen:selectatrandomtwokeys,KM,KE.

•  Encryption:c=CBC-EncKE(TLS-PAD(m||TagKM(m))).

•  Decryption:???28

SecurityofMtEgenericcompositionforAE

•  Encryption:c=CBC-EncKE(TLS-PAD(m||TagKM(m))).

•  Decryption:1.  PerformCBC-modedecryption.

2.  Performdepadding–possibilityofpaddingerror.

3.  PerformMACverification–possibilityofMACverificationerror.

Iftheerrorsatsteps2and3aredistinguishable,thenwecancarryoutapaddingoracleattack!

•  Paddingerror->paddingbad.

•  MACverificationerror->paddinggood!

Thisattackisaspecialcaseofachosen-ciphertextattack,whichshouldbepreventedbyAEsecurity(recallAEsecurityimpliesIND-CCAsecurity).

29

SecurityofMtEgenericcompositionforAE

•  We’vejustseenanexampleofaschemeconstructedfromcomponentsthatarebothgood(IND-CPAsecureencryptionscheme,SUF-CMAsecureMAC)butforwhichtheMtEcompositionfailstobesecure.

•  TheexampleiscloselyrelatedtotheconstructionthatisusedinTLS.

•  SpecificwaysofinstantiatingMtEcanbemadesecure,butit’sunsafeingeneralandmustbeavoidedwhereverpossible.

30

AEAD

32

AuthenticatedEncryptionwithAssociatedData(AEAD)

Inpracticalapplications,weoftenrequireconfidentialityandintegrityforsomedatafieldsandonlyintegrityforothers.

Example:ESPintransportandtunnelmodesinIPsec

Inner

IPheader

Tunnelmode:

Outer

IPheader

Payload

(e.g.TCP,UDP,ICMP)

ESP

trlr

ESPhdrSPI,seq#

MACscope

Encryptionscope

Payload

(e.g.TCP,UDP,ICMP)ESPhdrSPI,seq#

Transportmode:

Original

IPheaderESP

trlr

ESP

auth

Encryptionscope

MACscope

ESP

auth

33

AuthenticatedEncryptionwithAssociatedData(AEAD)

AnAEADschemeconsistsofatripleofalgorithms:(KGen,Enc,Dec).

KGen:keygeneration,selectsakeyKuniformlyatrandomfrom{0,1}k.

Enc:encryption,takesasinputkeyK,associateddataAD∈{0,1}∗,plaintextm∈{0,1}∗,andproducesoutputc∈{0,1}∗.

Dec:decryption,takesasinputkeyK,associateddataAD∈{0,1}∗,ciphertextc∈{0,1}∗,andproducesoutputm∈{0,1}∗oranerrormessage,denoted┴.

Correctness:werequirethatforallkeysK,forallassociateddatastringsAD,andforallplaintextsm:

DecK(AD,EncK(AD,m))=m.

AEADsecurity(informal):

IND-CPAsecurityformessagesm,integrityforcombinationofassociateddataADandciphertextc.

Nonce-basedAEAD

Nonce-basedAEAD

Nonce-basedAEAD=AEADwithnonces!

Motivation:

•  AEADschemesaswehavedescribedthemsofarmustconsumerandomnessinEncalgorithmtoachieveAEsecurity

•  (IND-CPAsecurityrequiresrandomisedencyption–why?)

•  Guaranteeinggoodsourcesofrandomnessishard.

•  It’sdangeroustohandthisresponsibilitytotheprogrammer,byaskinghimtosupplytherequiredrandomness(e.g.IVforCBCmode).

•  ItisarguablyeasiertoensurethattheprogrammeralwayspassesanewnoncevalueasoneoftheinputstotheEncalgorithm(alongwithmessagemandassociateddataAD).

35

36

Nonce-basedAEAD

Anonce-basedAEADschemeconsistsofatripleofalgorithms:(KGen,Enc,Dec).

KGen:keygeneration,selectsakeyKuniformlyatrandomfrom{0,1}k.

Enc:encryption,takesasinputkeyK,nonceN∈{0,1}n,associateddata AD∈{0,1}∗,plaintextm∈{0,1}∗,andproducesoutputc∈{0,1}∗.

Dec:decryption,takesasinputkeyK,nonceN∈{0,1}n,associateddata AD∈{0,1}∗,ciphertextc∈{0,1}∗,andproducesoutputm∈{0,1}∗oranerrormessage,denoted┴.

Correctness:werequirethatforallkeysK,forallnoncesN,forallassociateddatastringsAD,andforallplaintextsm:

DecK(N,AD,EncK(N,AD,m))=m.

37

Securityfornonce-basedAEAD

Nonce-basedAEADsecurity(informal):

IND-CPAsecurityformessagesm,integrityforcombinationofassociateddataADandciphertextc,foradversariesthatneverrepeatthe

nonceinencryptionqueries.

•  IntheIND-CPAsecuritygame,theadversarynowgetstospecifyapair(m0,m1),alongwithADandNinencryptionqueries.

•  AdversaryneverrepeatsN.

•  IntheINT-CTXTgame,adversarynowgetstospecifym,ADandNinencryptionqueries.

•  AdversaryneverrepeatsN.

•  Ideaofnoncerestriction:applicationwillensureanadversarycanneveraccessencryption/decryptionfunctionalitieswitharepeatednonce.

38

Usingnonce-basedAEAD

Enc:encryption,takesasinputkeyK,nonceN∈{0,1}n,associateddataAD∈{0,1}∗,plaintextm∈{0,1}∗,andproducesoutputc∈{0,1}∗.Dec:decryption,takesasinputkeyK,nonceN∈{0,1}n,associateddataAD∈{0,1}∗,ciphertextc∈{0,1}∗,andproducesoutputm∈{0,1}∗oranerrormessage,denoted┴.Notes:•  Fordecryptionto“undo”encryption,thesamevalueoftheassociateddataAD

needstobeused.•  Buttheciphertextcdoesnot“contain”AD.•  Inapplications,ADmayneedtobesentalongwithc,orbereconstructedatthe

receiver.•  Fordecryptionto“undo”encryption,thesamenoncevalueNneedstobeused.•  Again,Nisnotincludedintheciphertextc.•  Inapplications,then,senderandreceivertypicallymaintainasynchronized

countertoensuretheybothusethesameNwhenencryptinganddecrypting.

39

Usingnonce-basedAEAD

•  AsendsBasequenceofmessagesm0,m1,m2,…usingnonce-basedAEAD.

•  Ausesanincrementingcounterforthenonces;Busesthesamecountervalueswhendecrypting.

•  Whathappensiftheadversarydeletesaciphertext?

•  Whathappensiftheadversaryreorderstheciphertexts,deliveringc2beforec1,say?

•  Inbothcases,receiverwillusethewrongcounterduringdecryption,sodecryptionwillfail,producinganerrormessage;adversarylearnsnothing,andsocan’tarrangeundetectabledeletionorforceamessagetobedelivered“outoforder”.

c0=EncK(N=0,AD0,m0)

c1=EncK(N=1,AD1,m1)

c2

c2=EncK(N=2,AD2,m2)

c1

c0

m0=DecK(N=0,AD0,c0)

m1=DecK(N=1,AD1,c1)

m2=DecK(N=2,AD2,c2)

FurtherConstructions

41

AEADconstructions

SofarwehaveonlyseengenericconstructionsforAEschemes.

•  EtMistheonlyonethatissafetouse.

•  EtMextendstotheAEADsetting:

c’←EncKE(m);τ’←TagKM(AD||c’)andc=(c’,τ’).

•  NBthisisonlysecureifthelengthofADisfixedorotherwiseknowntobothEncandDecalgorithms.

•  EtMalsoextendstothenonce-basedsettingif“E”isanonce-basedencryptionscheme.

•  Example:CBC-modewithIV=EK(N)-usekeytoderive“random”IVblockfromnonce.

•  ManyotherAEADschemesareavailable;wewilllookatjusttwo,CCMandGCM.

CCM

CCM=CounterwithCBCMAC.

•  Basically,aninstantiationofMtEwithM=CBC-MACandE=CTRmode,usinga128-bitblockcipher,e.g.AES.

Modifications:

•  Usesamekeyfor“M”and“E”components.(Badideaingeneral,OKhere.)

•  ApplyCBC-MACtothestring:h=N||len(m)64||m||len(AD)64||AD||padding.

•  Here,“||”meansconcatenate,len(X)64meansthe64-bitencodingofthelengthofstringX.

•  InitialcountervalueforCTRmodeist=N||064,whereNisthe(64-bit)nonce.

42

CTRmodeencryption

CBCMAC

CCM

CCM=CounterwithCBCMAC.

•  CCMisquiteslow:itneedsonepassoverassociateddataADinCBC-MACandtwopassesoverthemessagem,oneinCBC-MACandoneinCTR-modeencryption.

•  CCMonlyusesblockcipherin“forwarddirection”,i.e.only“E”andno“D”.

•  CCMispatent-free.

•  CCMisusedinWPA2,thesuccessortoWEPandWPA/TKIP.

•  CCMisstandardisedforuseinIPsecandTLS1.2.

•  CCMisspecifiedinfullinRFC3610(https://tools.ietf.org/html/rfc3610).

•  CCMhasasasecurityproofbasedonblockcipherbeingapseudo-randompermutation.

•  Noknownattacks(whenimplementedproperly!)

43

GCM

GCM=GaloisCounterMode.

•  Basically,aninstantiationofEtMwithE=CTRmodeusinga128-bitblockcipher,e.g.AES,andM=aWegman-CarterMAC.

•  NoncesNcanbeofarbitrarylength,specialprocessingfor96-bitcaseforspeed.

•  FasterthanCCM:speedupcomesfromuseoffastMACalgorithmbuiltfromuniversalhashfunctionfamilycalledGHASH.

•  GCMonlyusesblockcipherin“forwarddirection”,i.e.only“E”andno“D”.

•  ADandmcanbeprocessedinblock-wisefashion,nobufferingrequired.

•  GCMispatent-free.

•  GCMisstandardisedforuseinIPsecandTLS1.2,nowwidelyusedinTLS.

•  GCMisspecifiedinfullinNISTSpecialPublicationSP800-38D(2007).

•  GCMhasasecurityproofbasedonblockcipherbeingapseudo-randompermutation.

•  Noknownattacksofsignificance(whenimplementedproperly!)

44

GCM(for96-bitnonces)

45

AD

N||1031

Encryptionmaskforuniversalhash

CTRmodeencryption

UniversalhashfunctiononAD||c||len(AD)64||len(c)64.

OtherthingsyoushouldprobablyknowaboutAE

•  Othermodesareseeinggrowingadoption,e.g.OCB.

•  RecentSHA-3winnerKECCAKcanbeadaptedtoproduceanAEscheme!

•  Thewholeareawasmiredinpatentsonearlyalgorithmdesignsbutthesituationisgraduallyimproving.

•  Don’trelyonwikipediafordiscussionofthesecurityofgenericcomposition(itsaysMtEisOK;it’snotingeneral)!

•  CAESARcompetitionon-going(http://competitions.cr.yp.to/caesar.html),generatinglotsofnewresearchactivityandsomecontroversy.

•  SeealsotheAEzoohttps://aezoo.compute.dtu.dk/doku.php

46

GoingStillFurther

AEAD≠securechannel

•  Thinkabouttheapplicationdeveloper:•  She/hewantsadrop-inreplacementforTCPthat’ssecure.

•  Actually,she/hemightjustwanttosendandreceivesomeatomicmessagesandnotaTCP-likestream.

•  TowhatextentdoesAEADmeetthisrequirement?

•  Itdoesn’t…

48

AEAD≠securechannel

There’sasignificantsemanticgapbetweenAEAD’sfunctionalityandrawsecurityguarantees,andallthethingsadeveloperexpectsasecurechanneltoprovide.

49

m1

m2

ChEnc(.,.,.)

Dec(.,.,.)

+

Example:cookiecutters

Bhargavan,Delignat-Lavaud,Fournet,Pironti,Strub2014:cookiecutterattackon“HTTPoverSSL/TLS”.

•  AttackerforcespartoftheHTTPheader(e.g.,cookie)tobecutoff.

•  Partialmessage/headerarrivesandmightbemisinterpreted.

50

c=Enc(Set-Cookie: SID=[AuthenticationToken]; secure)Ch

Set-Cookie: SID=[AuthenticationToken]

Cookiecutters

Whydoesn’tthisviolatetheprovenintegrityofSSL/TLSencryption?

6.2.1. Fragmentation

The record layer fragments information blocks into TLSPlaintext records [...]. Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType MAY be coalesced into a single TLSPlaintext record, or a single message MAY be fragmented across several records).

RFC5246TLSv1.251

Cookiecutters

Whydoesn’tthisviolatetheprovenintegrityofSSL/TLSencryption?

6.2.1. Fragmentation

The record layer fragments information blocks into TLSPlaintext records [...]. Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType MAY be coalesced into a single TLSPlaintext record, or a single message MAY be fragmented across several records).

RFC5246TLSv1.252

Cookiecutters

•  SoSSL/TLScan(andwill)fragmentwhensending.

•  ComparetoSSHthathastodealwithfragmentswhenreceiving.

•  Bothprotocolsprovideastreaminginterfacetoapplications,notamessage-orientedone.

53

Set-Cookie: SID=[AuthToken]; secure

ChSet-Cookie: SID = …

Set-Cookie: SID=[AuthToken]

2TLSrecords

Cookiecutters

•  It’suptothecallingapplicationtodealwithmessageboundariesifitwantstouseSSL/TLSforatomicmessagedelivery.

•  CookiecutterattackreliesonabuggybrowserthatdoesnotcheckforcorrectHTTPmessagetermination.

•  Thishappensinpractice,presumablybecausedevelopersdonotunderstandtheinterfaceprovidedbySSL/TLS.

54

Set-Cookie: SID=[AuthToken]; secure

ChSet-Cookie: SID = …

Set-Cookie: SID=[AuthToken]

FromAEADtosecurechannels

FromAEADtosecurechannels

•  SSL/TLSisnotaloneinpresentingastreaminginterfacetoapplications.

•  AlsoSSH“tunnelmode”,QUIC.•  Whatsecuritycanwehopeforfromsuchachannel?•  Boldyreva-Degabriele-Paterson-Stam(2012)alreadytreatedthecasewherethereceiverhandlesfragmentedciphertexts(butthesenderdoesnotproducethem).

•  ModeltunedtotreatmentofSSHencryption.

•  InFischlin-Günther-Marson-Paterson(2015),weprovidedasystematicstudyofthecasewherebothsenderandreceivermayfragment,asinTLS.

56

Streamingsecurechannels(FGMP15)

•  DefiningCCAandintegritynotionsinthefullstreamingsettingisnon-trivial!

•  Hardpartistodefinewhenadversary’sdecryptionqueriesdeviatefromsentstream,andfromwhichpointontosuppressdecryptionoracleoutputs.

• WedevelopstreaminganaloguesofIND-CPA,IND-CCA,INT-PTXTandINT-CTXT.

• Werecoverananalogueoftheclassicrelation:

IND-CPA+INT-CTXTèIND-CCA

57

Closingremarks

Closingremarks

• We’veseentheevolutionfromsimplesecuritymodelsforsymmetricencryptiontomoresophisticatedsecuritynotionsforsecurechannels.

•  YettherelevantpartofthecryptographycommunityismostlyfocussedonAEADandCAESER.

•  Keytake-away:thinktop-down,notbottom-up(fromAPItocrypto,notthereverse).

•  You’vealmostarrivedattheresearchfrontier!

•  Andtherearelotsofinterestingproblemslefttosolve!

59

Closingremarks

60