SecureChannels–AreWeThereYet?

KennyPaterson

InformationSecurityGroup

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

Motivation

Whydowestillneedresearchonsecurechannels?

•  Securecommunicationsisstillthemostcommonreal-worldapplicationofcryptographytoday.

•  SSL/TLS,DTLS,IPsec,SSH,OpenVPN,…•  WEP/WPA/WPA2•  GSM/UMTS/4g/LTE•  Cryptocat,OTR,SilentCircle,OpenPGP,iMessage,

Telegram,Signal,andathousandothermessagingapps•  QUIC,MinimalT,TCPcrypt

33

Whydowestillneedresearchonsecurechannels?

•  Securecommunicationsisstillthemostcommonreal-worldapplicationofcryptographytoday.

•  SSL/TLS,DTLS,IPsec,SSH,OpenVPN,…

•  WEP/WPA/WPA2

•  GSM/UMTS/4g/LTE

•  Cryptocat,OTR,SilentCircle,OpenPGP,iMessage,Telegram,Signal,andathousandothermessagingapps

•  QUIC,MinimalT,TCPcrypt

•  Bottomline:itmightbeboring,butwekeepgettingthiswrong,andit’snotclearwe’regettinganybetteratit.

44

Overview

•  Securechannelsandtheirproperties•  AEAD•  AEAD≠securechannel

•  SSHandTLSexamples

•  Buildingbettermodels

•  Closingremarks

5

Securechannelsandtheirproperties

Securityproperties

•  Confidentiality–privacyfordata•  Integrity–detectionofdatamodification

•  Authenticity–assuranceconcerningthesourceofdata

77

Somelessobvioussecurityproperties

•  Anti-replay•  Detectionthatmessageshavebeenrepeated.

•  Detectionofdeletion•  Detectionthatmessageshavebeendeletedbythe

adversaryordroppedbythenetwork.

•  Detectionofre-0rdering•  Ensuringthattherelativeorderofmessagesineach

directiononthesecurechannelispreserved.•  Possiblyre-orderingtheeventofviolation.

•  Preventionoftraffic-analysis.•  Usingtrafficpaddingandlength-hidingtechniques.

88

Possiblefunctionalityrequirements

•  Speedy•  Low-memory

•  On-line/parallelisablecrypto-operations•  Performanceisheavilyhardware-dependent.

•  Mayhavedifferentalgorithmsfordifferentplatforms.

•  IPR-friendly•  Thisissuehassloweddownadoptionofmany

otherwisegoodalgorithms,e.g.OCB.

•  Easytoimplement•  Withoutintroducinganyside-channels.

99

Additionalrequirements

•  Weneedacleanandwell-definedAPI.

•  Becausetherealityisthatoursecurechannelprotocolwillprobablybeusedblindlybyasecurity-naïvedeveloper.

•  Developerswantto“open”and“close”securechannels,andissue“send”and“recv”commands.

•  They’dliketosimplyreplaceTCPwitha“secureTCP”havingthesameAPI.

•  Ortojusthaveablack-boxfordeliveringmessagessecurely.

1010

AdditionalAPI-drivenrequirements

•  Doesthechannelprovideastream-basedfunctionalityoramessage-orientedfunctionality?

•  Doesthechannelacceptmessagesofarbitrarylengthandperformitsownfragmentationandreassembly,oristhereamaximummessagelength?

•  Howiserrorhandlingperformed?Isasingleerrorfatal,leadingtotear-downofchannel,oristhechanneltolerantoferrors?

•  Howaretheseerrorssignalledtothecallingapplication?Howshouldtheprogrammerhandlethem?

•  Doesthesecurechannelitselfhandleretransmissions?Oristhislefttotheapplication?Orisitguaranteedbytheunderlyingnetworktransport?

•  Doesthechannelofferdatacompression?•  Thesearedesignchoicesthatallimpactonsecurity•  Theyarenotwell-reflectedinthebasicsecuritydefinitionsfor

symmetricencryption1111

AEAD

SecurityforSymmetricEncryption

13

m1

m2

PicturesbyGiorgiaAzzurraMarson

SecurityforSymmetricEncryption

14

m1

m2

K K

KE

Ch

SecurityforSymmetricEncryption

15

c1

c2

K KCh

c1=EncK(m1)

m2=DecK(c2)

m1=DecK(c1)

c2=EncK(m2)

SecurityforSymmetricEncryption–Confidentiality

16

c1

c2

K KCh

c1=EncK(m1)

m2=DecK(c2)

m1=DecK(c1)

c2=EncK(m2)

EncOracle

learnbin{0,1}fromc*=EncK(mb)

IND-CPA(Goldwasser-Micali,1984;Bellare-Desai-Jokipii-Rogaway,1997).

SecurityforSymmetricEncryption–Confidentiality

17

c1

c2

K KCh

c1=EncK(m1)

m2=DecK(c2)

m1=DecK(c1)

c2=EncK(m2)

EncOracle

learnbin{0,1}fromc*=EncK(mb)

IND-CPA(Goldwasser-Micali,1984;Bellare-Desai-Jokipii-Rogaway,1997).

DecOracle

IND-CCA(Naor-Yung,1990;

Rackoff-Simon,1997).

SecurityforSymmetricEncryption–Integrity

18

c1

c2

K KCh

c1=EncK(m1)

m2=DecK(c2)

m1=DecK(c1)

c2=EncK(m2)

Isthiswhatyouwrote?

SecurityforSymmetricEncryption–Integrity

19

c1

c2

K KCh

c1=EncK(m1)

m2=DecK(c2)

m1=DecK(c1)

c2=EncK(m2)

EncOracle

comeupwithvalidc*

DecOracle

INT-CTXT(Bellare,Rogaway,2000)

SecurityforSymmetricEncryption–Integrity

20

c1

c2

K KCh

c1=EncK(m1)

m2=DecK(c2)

m1=DecK(c1)

c2=EncK(m2)

EncOracle

comeupwithvalidc*foranewm*

DecOracle

INT-CTXT(Bellare,Rogaway,2000)

INT-PTXT(Bellare-Namprempre,2000)

SecurityforSymmetricEncryption–AE

21

c1

c2

K KCh

c1=EncK(m1)

m2=DecK(c2)

m1=DecK(c1)

c2=EncK(m2)

EncOracle DecOracle

INT-CTXT(Bellare,Rogaway,2000)

INT-PTXT(Bellare-Namprempre,2000)

AuthenticatedEncryptionIND-CPA+INT-CTXT

(èIND-CCA)

SecurityforSymmetricEncryption–AEAD

22

c1

c2

K KCh

c1=EncK(AD1,m1)

m2=DecK(AD2,c2)

m1=DecK(AD1,c1)

c2=EncK(AD2,m2)

EncOracle DecOracle

AuthenticatedEncryptionwithAssociatedDataAEsecurityformessagem

IntegrityforassociateddataADStrongbindingbetweencandAD

(Rogaway2002)

Whichcamefirst?

SecurityforSymmetricEncryption–statefulAEAD

23

c1

c2

K KCh

c1=EncK(AD1,m1)

m2=DecK(AD2,c2)m3=DecK(AD3,c3)

m1=DecK(AD1,c1)

c2=EncK(AD2,m2)c3=EncK(AD3,m3)

c3

SecurityforSymmetricEncryption–statefulAEAD

24

c1

c2

K KCh

c1=EncK(AD1,m1)

m2=DecK(AD2,c2)m3=DecK(AD3,c3)

m1=DecK(AD1,c1)

c2=EncK(AD2,m2)c3=EncK(AD3,m3)

c3

EncOracle DecOracle

learnbin{0,1}fromc*=EncK(mb)

IND-sfCCA (Bellare-Kohno-Namprempre,2002)

SecurityforSymmetricEncryption–statefulAEAD

25

c1

c2

K KCh

c1=EncK(AD1,m1)

m2=DecK(AD2,c2)m3=DecK(AD3,c3)

m1=DecK(AD1,c1)

c2=EncK(AD2,m2)c3=EncK(AD3,m3)

c3

EncOracle DecOracle

learnbin{0,1}fromc*=EncK(mb)orcomeupwith

valid/outoforderc*

IND-sfCCA (Bellare-Kohno-Namprempre,2002)

INT-sfCTXT

INT-sfPTXT(Brzuska-Smart-Warinschi-Watson,2013)

StatefulAEAD

SecurityforSymmetricEncryption–nonce-basedAEAD

26

c1

c2

K KCh

c1=EncK(N1,AD1,m1)

m2=DecK(N2,AD2,c2)

m1=DecK(N1,AD1,c1)

c2=EncK(N2,AD2,m2)

EncOracle DecOracle

Nonce-basedAuthenticatedEncryptionwithAssociatedDataAsperAEAD,butwithadditionalinputNtoEncandDecalgorithms

AdversarymayarbitrarilyspecifyN,but“norepeats”ruleEncandDeccannowbestatelessanddeterministic

(Rogaway2004)

CAESAR

27

•  CAESAR:CompetitionforAuthenticatedEncryption:Security,Applicability,andRobustness.

•  InitiatedbyDanBernstein,supportedbycommitteeofexperts.

•  MaingoalisthedesignofaportfolioofAEschemes.•  CAESARhasinvolveddozensofperson-yearsofeffort

andledtoamajoruptickinresearchactivity.

•  Itseemsthatmostofthecryptographiccommunityhassettledonnonce-basedAEADastheirdesigntarget.

AEAD≠securechannel

AEAD≠securechannel

•  Recallourapplicationdeveloper:•  Hewantsadrop-inreplacementforTCPthat’ssecure.

•  Actually,hemightjustwanttosendandreceivesomeatomicmessagesandnotaTCP-likestream.

•  TowhatextentdoesAEADmeettheserequirements?

•  Itdoesn’t…

29

AEAD≠securechannel

There’sasignificantsemanticgapbetweenAEAD’sfunctionalityandrawsecurityguarantees,andthethingsadeveloperexpectsa

securechanneltoprovide.

30

m1

m2

ChEnc(.,.,.)

Dec(.,.,.)

+

Firstexample:SSHBinaryPacketProtocol(RFC4253)

•  Encode-then-E&Mconstruction,statefulbecauseofinclusionof4-bytesequencenumber.

•  Packetlengthfieldmeasuresthesizeofthepacket:|PadLen|+|Payload|+|Padding|.•  Encrypted,sosequenceofencryptedpacketslookslikealongstringofrandombytes.

•  EncryptionoptionsinRFC4253:CBCmode;RC4.•  AES-CTRdefinedinRFC4344.31

Encrypt

PRF-MAC

Payload

Ciphertext MAC tag

Sequence Number 4

Packet Length 4

Pad Len 1

Padding ≥4

Firstexample:SSHBinaryPacketProtocol(RFC4253)

•  Howdoesdecryptionwork?•  Recall:receivergetsastreamofbytes,andasingleciphertextcanbefragmented

overseveralTCPmessages.

32

Encrypt

PRF-MAC

Payload

Ciphertext MAC tag

Sequence Number 4

Packet Length 4

Pad Len 1

Padding ≥4

BreakingCBCmodeinSSH[APW09]

33

Ci-1* Ci

*

Pi*

dK

Targetciphertextblockfromstream

Targetplaintextinattack

BreakingCBCmodeinSSH[APW09]

34

IV Ci*

P0’

dK

•  Thereceiverwilltreatthefirst32bitsofthecalculatedplaintextblockasthepacketlengthfieldforthenewpacket.

•  Here: P0’=IV⊕dK(Ci*)whereIVisknown.

Targetciphertextblockfromstream

Lengthfield

BreakingCBCmodeinSSH[APW09]

35

IV Ci*

P0’

dK

R R

P2’

dK dK

P1’

Theattackerthenfeedsrandomblockstothereceiver–  Oneblockatatime,waitingtoseewhathappensattheserver

wheneachnewblockisprocessed–  ThisispossiblebecauseSSHrunsoverTCPandtriestodoonline

processingofincomingblocks

BreakingCBCmodeinSSH[APW09]

36

IV Ci*

P0’

dK

•  Onceenoughdatahasarrived,thereceiverwillreceivewhatitthinksistheMACtag–  TheMACcheckwillfailwithoverwhelmingprobability–  Consequentlytheconnectionisterminated(withanerrormessage)

•  Howmuchdatais“enough”sothatthereceiverdecidestochecktheMAC?

•  Answer:whateverisspecifiedinthelengthfield:

R R

P2’

dK dK

P1’

MAC tag

BreakingCBCmodeinSSH[APW09]

37

IV Ci*

P0’

dK

Ci-1* Ci

*

Pi*

dK

•  KnowingIVand32bitsofP0’,theattackercannowrecover

32bitsofthetargetplaintextblockPi*:

Pi*=Ci-1

*⊕dK(Ci*)=Ci-1

*⊕IV⊕P0’

•  Attackisslightlydifferentinpractice:implementation-specificlengthchecks.

SecurityModellingImplications?

•  TheattackworkswithrandomIVstoo,invalidatingthesecurityproofin[BKN02].

•  ThestatefulAEnotionsusedin[BKN02]wereforatomicciphertextprocessing.

•  ButSSHpermitsfragmenteddeliveryofciphertexts.

• Oops!

38

Countermeasurestotheattack

•  AbandonCBC-mode?•  Alternativesavailableatthattime:CTR,RC4.

•  DropbearimplementedCTRandrelegatedCBCmodeinversion0.53.

•  PatchCBC-mode?•  VersionspriortoOpenSSH5.1affected.

•  OpenSSH5.2alsointroducedapatchtostopthespecificattackonCBCmode.

•  Developnewmodes?•  ModesbasedonGenericEtM,AES-GCM,ChaCha20-Poly1305were

subsequentlyaddedtoOpenSSH.

•  Modeproliferation!

39

AEADinSSHtoday?

•  In[ADHP16],weperformameasurementstudyofSSHdeployment.

•  WeconductedtwoIPv4addressspacescansinNov/Dec2015andJan2016usingZGrab/ZMap.

•  GrabbingbannersandSSHservers’preferredciphers.•  ActualcipherusedinagivenSSHconnectiondependsonclient

andserverpreferences.

•  Roughly224serversfoundineachscan.

•  Nmapfingerprintingsuggestsmostlyembeddedrouters,firewalls.

40

ThestateofAEADinSSHtoday:SSHversions

41

ThestateofAEADinSSHtoday:SSHversions

42

Dropbearat56-58%.886,000olderthanversion0.53,so

vulnerabletovariantof2009CBC-modeattack!

ThestateofAEADinSSHtoday:SSHversions

43

OpenSSHat37-39%.130,000-166,000olderthanversion5.2andpreferCBCmode,sovulnerableto2009

attack!

TheOpenSSHpatch

• OpenSSHpatch,inversion5.2andup:•  Ifthelengthchecksfail,donotsendanerrormessage,but

waituntil218byteshavearrived,thenchecktheMAC.

•  Ifthelengthcheckspass,buttheMACcheckeventuallyfails,thenwaituntil218byteshavearrived,thenchecktheMAC.

•  OneMACcheckisdoneiflengthchecksfail:on218bytes.

•  TwoMACchecksaredoneiflengthcheckspass:oneonroughlyLFbytes,theotheron218bytes.

44

AttackingtheOpenSSHpatch[ADHP16]

•  ThisleadstoatimingattackonCBCmodeinOpenSSH5.2andup,recoveringupto30bitsofplaintextfromtargetblock[ADHP16].

•  Sizeoftimingdifference:

•  AMACcomputationonroughly217bytes(theexpectedvalueofLF).

•  About2000timesbiggerthantheLucky13timingdifference!

•  Affectsroughly20,000OpenSSHservers.

45

Disclosureoftheattack

•  WenotifiedtheOpenSSHteamoftheattackon5thMay2016.

•  TheyareconsideringaddingcountermeasuresforthenextreleaseofOpenSSH(7.3).

•  “…wedonotfeelthatanemergencyreleaseisnecessary,northattheattackremainsecretaheadofsucharelease.”

•  OpenSSHhassteadilybeendeprecatingoldalgorithmsandmodes.

•  CBCmodewasalreadydisabledbydefaultinOpenSSH6.7(butcanbere-enabled).

•  ButOpenSSHcannotforcepeopletostopusingoldversionsofthesoftware.

•  Thelegacyproblem–notuniquetoSSH.

46

Secondexample:cookiecutters

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

•  AttackerforcespartoftheHTTPheader(e.g.,cookie)tobecutoff.•  Partialmessage/headerarrivesandmightbemisinterpreted.

47

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).

RFC5246(TLSv1.2)48

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).

RFC5246(TLSv1.2)49

Cookiecutters

•  SoSSL/TLScan(andwill)fragmentwhensending.•  ComparetoSSHthathastodealwithfragmentsonlywhenreceiving.

•  Bothprotocolsprovideastreaminginterfacetoapplications,notamessage-orientedone.

50

Set-Cookie: SID=[AuthToken]; secure

ChSet-Cookie: SID = …

Set-Cookie: SID=[AuthToken]

2TLSrecords

Cookiecutters

•  It’suptothecallingapplicationtodealwithmessageboundariesifitwantstouseSSL/TLSforatomicmessagedelivery.

•  CookiecutterattackreliesonabuggybrowserthatdoesnotcheckforcorrectHTTPmessagetermination.

•  Thishappensinpractice–itseemsthatdevelopersdonotunderstandtheinterfaceprovidedbySSL/TLS?

51

Set-Cookie: SID=[AuthToken]; secure

ChSet-Cookie: SID = …

Set-Cookie: SID=[AuthToken]

BuildingBetterModels

Motivation:AEADinOpenSSHtoday

53

OpenSSH preferred algorithms

•  Lotsofdiversity,surprisingamountof“genericEtM”(gEtM).

•  CTRdominates,followedbyCBC.

•  ChaCha20-Poly1305ontherise?(becamedefaultinOpenSSH6.9).

•  SmallamountofGCM.

AnalysisofSSH-CTR

•  [PW10]developedabespokesecuritymodelforCTRmodeinSSHandproveditsecure(assumingblockcipherisaPRP).

•  Themodelallowstheattackertodeliverciphertextstodecryptionoracleinabyte-by-bytefashion.

•  AccuratelymodelsOpenSSH’sCTRmodeimplementation.

•  Sanitycheckingoflengthfield,withrelatederrormessages,MACfailures,etc.

•  Complexpseudo-codedescriptionsofalgorithmsandoracles.

54

SymmetricEncryptionSupportingFragmentedDecryption

•  [BDPS12]developedageneralframeworkforstudying“SymmetricEncryptionschemessupportingfragmenteddecryption”likeSSH.

•  TheirIND-CFAmodelallowstheattackertodeliverciphertexttoadecryptionoracleinasymbol-by-symbolfashionandobserveanyerrors/messageoutputs.

•  [BDPS12]alsoidentifiedadditionalsecuritypropertiesthatSSHattemptstoprovide:•  BoundaryHiding(BH)andDenial-of-Serviceresistance.

55

DevelopingandUsingtheModels

•  [FGMP15]developedaframeworkforstudyingStreamingSecureChannelslikeTLS,whichpermitfragmentationbothinsendingandreceiving.•  cf.workonTLSmentionedbyCedricFournetthismorning.

•  Cryptographic-game-basedratherthantype-based.

•  [ADHP16]usestheframeworkof[BDPS12]tostudygEtM,AES-GCM,andChaCha20-Poly1305inOpenSSH.•  Identifiesabuginthe[BDPS12]securitymodel.

•  Provessecurityofallmodes.

•  FindsanerroringEtM:MACcomputedbeforedecryptionbutnotcheckeduntilafterdecryption!

56

ChaCha20-Poly1305inOpenSSH

57

Payload

MAC tag

SQN 4

Packet Length 4

Pad Len 1

Padding ≥4

C1 C2

K1IV = SQN||064 ChaCha20 ChaCha20

K2IV = SQN||0631

ChaCha20 K2

IV = SQN||0630

0256

KpolyPoly1305

Closingremarks

Closingremarks

•  Simplesecuritymodelsforsymmetricencryptionversuscomplexsecuritypropertiesdesiredofsecurechannels.

•  Thereisstillarichresearchseamtominehere.

“Nowthisisnottheend.Itisnoteventhebeginningoftheend.Butitis,perhaps,theendofthebeginning.”

59

Closingremarks

60