AuthenticatedEncryptioninSSH

KennyPaterson

InformationSecurityGroup

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

Overview(bothlectures)

•  Securechannelsandtheirproperties•  AEAD(revision)•  AEAD≠securechannel–the[APW09]attackonSSH

•  ThestateofAEADinSSHtoday•  AnewattackonCBC-modeinOpenSSH

•  SecurityanalysisofotherSSHandOpenSSHmodes–CTR,ChaChaPoly,gEtM,AES-GCM.

2

Securechannelsandtheirproperties

Whydoweneedsecurechannels?

•  Securecommunicationsisthemostcommonreal-worldapplicationofcryptographytoday.

•  Securecommunicationssystemsareextremelywidely-deployedinpractice:

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

thousandothermessagingapps•  QUIC,MinimalT,TCPcrypt

44

Securityproperties

•  Confidentiality–privacyfordata•  Integrity–detectionofdatamodification

•  Authenticity–assuranceconcerningthesourceofdata

55

Somelessobvioussecurityproperties

•  Anti-replay•  Detectionthatmessageshavebeenrepeated.

•  Detectionofdeletion•  Detectionthatmessageshavebeendeletedbythe

adversaryordroppedbythenetwork.

•  Detectionofre-0rdering•  Ensuringthattherelativeorderofmessagesineach

directiononthesecurechannelispreserved.•  Possiblyre-orderingtheeventofviolation.

•  Preventionoftraffic-analysis.•  Usingtrafficpaddingandlength-hidingtechniques.

66

Possiblefunctionalityrequirements

•  Speedy•  Low-memory

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

•  Mayhavedifferentalgorithmsfordifferentplatforms.

•  IPR-friendly•  Thisissuehassloweddownadoptionofmany

otherwisegoodalgorithms,e.g.OCB.

•  Easytoimplement•  Withoutintroducinganyside-channels.

77

Additionalrequirements

•  Weneedacleanandwell-definedAPI.

•  Becausetherealityisthatoursecurechannelprotocolwillprobablybeusedblindlybyasecurity-naïvedeveloper.

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

•  They’dliketosimplyreplaceTCPwitha“secureTCP”havingthesameAPI.

•  Ortojusthaveablack-boxfordeliveringmessagessecurely.

88

AdditionalAPI-drivenrequirements

•  Doesthechannelprovideastream-basedfunctionalityoramessage-orientedfunctionality?

•  Doesthechannelacceptmessagesofarbitrarylengthandperformitsownfragmentationandreassembly,oristhereamaximummessagelength?

•  Howiserrorhandlingperformed?Isasingleerrorfatal,leadingtotear-downofchannel,oristhechanneltolerantoferrors?

•  Howaretheseerrorssignalledtothecallingapplication?Howshouldtheprogrammerhandlethem?

•  Doesthesecurechannelitselfhandleretransmissions?Oristhislefttotheapplication?Orisitguaranteedbytheunderlyingnetworktransport?

•  Doesthechannelofferdatacompression?•  Thesearedesignchoicesthatallimpactonsecurity•  Theyarenotwell-reflectedinthesecuritydefinitionsfor

symmetricencryption99

AEAD(Revision)

SecurityforSymmetricEncryption

11

m1

m2

PicturesbyGiorgiaAzzurraMarson

SecurityforSymmetricEncryption

12

m1

m2

K K

KE

Ch

SecurityforSymmetricEncryption

13

c1

c2

K KCh

c1=EncK(m1)

m2=DecK(c2)

m1=DecK(c1)

c2=EncK(m2)

SecurityforSymmetricEncryption–Confidentiality

14

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

15

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

16

c1

c2

K KCh

c1=EncK(m1)

m2=DecK(c2)

m1=DecK(c1)

c2=EncK(m2)

Isthiswhatyouwrote?

SecurityforSymmetricEncryption–Integrity

17

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

18

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

19

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

20

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

21

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

22

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

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

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

24

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)

SecurityforSymmetricEncryption–furthernotions

25

•  LH-(stateful)AE(AD)•  Ontopofeverythingelse,ciphertextsprovidea

modicumofhidingofplaintextlengths.

•  cfvariablelengthpaddinginSSL/TLS.

•  IntroducedbyPaterson-Ristenpart-Shrimpton,2011.

•  IncorporatedintoACCEframeworkforanalysisofTLSbyJager-Kohlar-Schage-Schwenk,2012.

CAESAR

26

•  CAESAR:CompetitionforAuthenticatedEncryption:Security,Applicability,andRobustness.

•  InitiatedbyDanBernstein,supportedbycommitteeofexperts.

•  MaingoalisthedesignofaportfolioofAEschemes.•  CAESARhasinvolveddozensofperson-yearsofeffort

andledtoamajoruptickinresearchactivity.

•  Itseemsthatmostofthecryptographiccommunityhassettledonnonce-basedAE/AEADastheirworkingabstraction.

AEAD≠securechannel–the[APW09]attackonSSH

AEAD≠securechannel

•  Recallourapplicationdeveloper:•  Hewantsadrop-inreplacementforTCPthat’ssecure.

•  Actually,hemightjustwanttosendandreceivesomeatomicmessagesandnotaTCP-likestream.

•  TowhatextentdoesAEADmeettheserequirements?

•  Itdoesn’t…

28

AEAD≠securechannel

There’sasignificantsemanticgapbetweenAEAD’sfunctionalityandrawsecurityguarantees,andallthethingsadeveloperexpectsasecurechanneltoprovide.

29

m1

m2

ChEnc(.,.,.)

Dec(.,.,.)

+

IntroductiontoSSH

30

Secure Shell or SSH is a network protocol that allows data to be exchanged using a secure channel between two networked devices. Used primarily on Linux and Unix based systems to access shell accounts, SSH was designed as a replacement for TELNET and other insecure remote shells, which send information, notably passwords, in plaintext, leaving them open for interception. The encryption used by SSH provides confidentiality and integrity of data over an insecure network, such as the Internet.

– Wikipedia

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

CBCmodeinSSH

32

•  RFC4253mandates3DES-CBCandrecommendsAES-CBC.

•  SSHusesachainedIVinCBCmode:–  IVforcurrentpacketisthelast

ciphertextblockfromthepreviouspacket.

–  EffectivelycreatesasinglestreamofdatafrommultipleSSHpackets.

Ci-1 Ci

Pi-1 Pi

dK dK

Pi-1 Pi

Ci-1 Ci

eK eK

CTRmodeinSSH

33

•  CTRmodeusesblockciphertobuildastreamcipher.

•  CTRmodeforSSHisstandardisedinRFC4344.•  Initialvalueofcounteris

obtainedfromhandshakeprotocol.

•  Counterrunsacrosspackets.•  Packetformatispreservedfrom

CBCcase.•  RFCrecommendsuseofAES-

CTRwith128,192and256-bitkeys,and3DES-CTR.

Ci

eK

Pi

ctr+i

Pi

eK

Ci

ctr+i

SSHBinaryPacketProtocol(RFC4253)

•  IVchainingattack:•  Chosenplaintext,distinguishingattackduetoRogaway,appliedtoSSHin[BKN02].•  NotfullyrealisticforSSHbecauseofformatrequirementsonthefirstblockof

plaintextandbecauseofchosenplaintextrequirement.•  ConstructionwithrandomIVsisIND-sfCCAsecure[BKN02].

34

Encrypt

PRF-MAC

Payload

Ciphertext MAC tag

Sequence Number 4

Packet Length 4

Pad Len 1

Padding ≥4

SSHBinaryPacketProtocol(RFC4253)

•  Howdoesdecryptionwork?•  Recall:receivergetsastreamofbytes,andasingleciphertext

canbefragmentedoverseveralTCPmessages.

35

Encrypt

PRF-MAC

Payload

Ciphertext MAC tag

Sequence Number 4

Packet Length 4

Pad Len 1

Padding ≥4

BreakingCBCmodeinSSH[APW09]

36

IV Ci*

P0’

dK

•  Thereceiverwilltreatthefirst32bitsofthecalculatedplaintextblockasthepacketlengthfieldforthenewpacket.

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

Targetciphertextblockfromstream

Lengthfield

BreakingCBCmodeinSSH[APW09]

37

IV Ci*

P0’

dK

R R

P2’

dK dK

P1’

Theattackerthenfeedsrandomblockstothereceiver–  Oneblockatatime,waitingtoseewhathappensattheserver

wheneachnewblockisprocessed–  ThisispossiblebecauseSSHrunsoverTCPandtriestodoonline

processingofincomingblocks

BreakingCBCmodeinSSH[APW09]

38

IV Ci*

P0’

dK

•  Onceenoughdatahasarrived,thereceiverwillreceivewhatitthinksistheMACtag–  TheMACcheckwillfailwithoverwhelmingprobability–  Consequentlytheconnectionisterminated(withanerrormessage)

•  Howmuchdatais“enough”sothatthereceiverdecidestochecktheMAC?

•  Answer:whateverisspecifiedinthelengthfield:

R R

P2’

dK dK

P1’

MAC tag

BreakingCBCmodeinSSH[APW09]

39

IV Ci*

P0’

dK

Ci-1* Ci

*

Pi*

dK

•  KnowingIVand32bitsofP0’,theattackercannowrecover

32bitsofthetargetplaintextblockPi*:

Pi*=Ci-1

*⊕dK(Ci*)=Ci-1

*⊕IV⊕P0’

Furtherdetails

•  Theattackasdescribedrequirestheinjectionofcirca231bytesofciphertext(expectedvalueoflengthfield).

•  Itrecovers32bitsofplaintextwithprobability1.

•  AndleadstoanSSHconnectionteardown(onMACfailure).

•  TheattackworkswithrandomIVstoo,breakingtheschemethatwasprovensecurein[BKN02].

•  Somethingwentwrongsomewhere!

40

Furtherdetails–Lengthchecking

•  RFC4253requiresimplementationstocheckthatlengthfieldis“reasonable”.

•  Detailsareimplementation-specific.

•  Backin2009,theleadingimplementationwasOpenSSH,thenatversion5.1.

•  AccordingtoSSHwebpage,80%ofserversontheInternetwereusingOpenSSHaroundthattime.

41

Furtherdetails–LengthcheckinginOpenSSH

•  OpenSSH5.1performstwolengthchecksonthelengthfield(LF)whendecryptingthefirstciphertextblock:

•  Check1:5≤LF≤218.

•  Check2:totallength(4+LF)isamultipleoftheblocksize:

LF+4modBL=0.

•  Eachcheckproducesadifferenterrormessageonthenetwork,distinguishablebyattacker.

•  Ifbothcheckspass,thenOpenSSHwaitsformorebytes,thenperformsMACcheck,resultinginathirdkindoferrormessage.

42

Furtherdetails–LengthcheckinginOpenSSH

•  Check1(5≤LF≤218)passeswithprobabilityapprox.2-14.

•  Ifitpasses,thenwithhighprobability,14MSBsofLFare“0”.•  Pass/faildetectableviaerrormessage.

•  Henceattackwithsuccessprob.2-14recovering14bitsofconfirmedplaintext.

•  Check2(LF+4modBL=0)passeswithprobability1/BL,typically2-3or2-4.•  Ifitpasses,thensome(3or4)LSBsofLFarerevealed.

•  Pass/faildetectableviaerrormessage/connectionenteringwaitstate.

•  Ifwaitstateisentered,thentheattackproceedsasbefore.

•  Overall,theattackonOpenSSH5.1recovers32bitsofplaintextwithprob.2-18(forBL=16)andrequiresinjectionofatmost218bytesofdata.

43

Doestheattackmatter?

•  Ontheonehand,theattackhaslowsuccessrate,onlyrecovers32bitsofplaintext,andcausestheSSHconnectiontoabort.

•  Ontheotherhand,anattackercanapplytheattacktomanyconnections,boostinghisoverallsuccessrate.

•  Canalsoiteratetheattackagainstclientsthatperformauto-reconnects.

•  ThinkaboutwhatkindsofdataSSHmightbeprotecting.•  SSHwasmeanttobebullet-proof;theattackshoweditwasnot.

•  ItlefttheprovablesecurityoftheSSHBPPunresolved.44

Countermeasurestotheattack

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

•  DropbearimplementedCTRandrelegatedCBCmodeinversion0.53.

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

weresubsequentlyaddedtoOpenSSH.

•  PatchCBC-mode?•  OpenSSH5.2alsointroducedapatchtostopthespecificattack

onCBCmode.

45

TheOpenSSHpatch

•  Basicidea:hidetheerrorsfromtheadversary.•  Ifthelengthchecksfail,donotsendanerrormessage,but

waituntil218byteshavearrived,thenchecktheMAC.

•  Ifthelengthcheckspass,buttheMACcheckeventuallyfails,thenwaituntil218byteshavearrived,thenchecktheMAC.

•  Noerrormessageiseversentuntil218bytesofciphertexthavearrived.

•  CannolongercountbytestoseehowmanyarerequiredtotriggerMACfailure.

46

TheorylessonfromtheSSHattack

•  Modelusedforsecurityproofin[BKN02]wasinadequate.•  Itassumedlengthwasknownandatomicprocessingof

ciphertexts.

•  ButfragmentedadversarialdeliveryofciphertextoverTCPispossible.

•  Implementationshavetodecryptfirstblocktofindouthowlongplaintextismeanttobe,andactonitbeforeperforminganyauthentication.

•  That’snotreflectedinanyoftheAE/AEADsecuritymodels!

•  Andthere’snoCAESARrequirementthatlookslikethis!

47

TheStateofAEADinSSHToday

ThestateofAEADinSSHtoday

•  In[ADHP16],weperformedameasurementstudyofSSHdeployment.

•  WeconductedtwoIPv4addressspacescansinNov/Dec2015andJan2016usingZGrab/ZMap.

•  GrabbingbannersandSSHservers’preferredciphers.•  ActualcipherusedinagivenSSHconnectiondependsonclient

andserverpreferences.

•  Roughly224serversfoundineachscan.

•  Nmapfingerprintingsuggestsmostlyembeddedrouters,firewalls.

49

ThestateofAEADinSSHtoday:SSHversions

50

MostlyOpenSSHanddropbear;others

lessthan5%.

ThestateofAEADinSSHtoday:SSHversions

51

Dropbearat56-58%.886kolderthenversion0.53,sovulnerabletovariantof2009CBC-

modeattack!

ThestateofAEADinSSHtoday:SSHversions

52

OpenSSHat37-39%.130-166kolderthenversion5.2andprefer

CBCmode,sovulnerableto2009

attack!

ThestateofAEADinSSHtoday:SSHversions

•  DropbearnowdominatesOpenSSH.•  Butmaybeswitchingbackagain:ComcastcableIPaddress

rangedroppedfrom2M+devicesrunningDropbear(Feb2016)to83k(May2016).

•  Longtailofoldsoftwareversions.•  MostpopularversionofOpenSSHisversion5.3,releasedOct

2009(currentversionis7.2).

•  DeterminedbymajorLinuxdistros?

•  SignificantpercentageofDropbearandOpenSSHserversarepotentiallystillvulnerabletothe2009attack.•  8.4%forDropbear.

53

ThestateofAEADinSSHtoday:preferredalgorithms

54

OpenSSH preferred algorithms

•  Lotsofdiversity,surprisingamountof“genericEtM”(gEtM).

•  CTRdominates,followedbyCBC.

•  ChaCha20-Poly1305ontherise?(becamedefaultinOpenSSH6.9).

•  SmallamountofGCM.

ThestateofAEADinSSHtoday:preferredalgorithms

55

Dropbear preferred algorithms

•  LessdiversitythanOpenSSH.

•  CTRdominates,followedatalongdistancebyCBC.

•  No“exotic”options.

ANewAttackonCBCmodeinOpenSSH

TheOpenSSHpatch

•  Version5.2+CBCmodepreferredbyroughly20kOpenSSHservers.

•  RecalltheOpenSSHpatch,inversion5.2andup:•  Ifthelengthchecksfail,donotsendanerrormessage,butwait

until218byteshavearrived,thenchecktheMAC.

•  Ifthelengthcheckspass,buttheMACcheckeventuallyfails,thenwaituntil218byteshavearrived,thenchecktheMAC.

•  OneMACcheckisdoneiflengthchecksfail:on218bytes.

•  TwoMACchecksaredoneiflengthcheckspass:oneonroughlyLFbytes,theotheron218bytes.

57

AttackingtheOpenSSHpatch[ADHP16]

•  ThisleadstoatimingattackonCBCmodeinOpenSSH5.2andup:1. InjecttargetciphertextblockCi

*.2. Thensend218bytesasquicklyaspossibletoserver.

3. TimethearrivaloftheMACfailuremessage.

•  FastarrivalindicatesthatlengthchecksfailedandoneMACcomputation.

•  SlowarrivalindicatesthatthelengthcheckspassedandtwoMACcomputations.

•  Thisleaks18bitsofinformationaboutthelengthfield,andhence18bitsaboutthetargetblock.

58

AttackingtheOpenSSHpatch[ADHP16]

•  Sizeoftimingdifference:•  AMACcomputationonroughly217bytes(theexpectedvalueofLF).

•  ForHMAC-SHA1,thisrequires211hashcompressionfunctionevaluations.

•  cf.Lucky13timingdifference:asinglehashcompressionfunction!

•  Remoteattackercaneasilydetectdifference.

•  Successprobabilityoftheattack:•  Needtopassbothlengthchecks,so2-18.

•  Canincreasesuccessrategivenpartialplaintextknowledgeintargetblock.

•  (Idea:waitfortherightIVbeforemountingtheattack;moresevereattackforrandom,explicitIVversion.)

59

AttackingtheOpenSSHpatch[ADHP16]

•  Increasenumberofplaintextbitsrecoveredbyusingfiner-grainedtiminginformation.•  BecausethetimingdelayisproportionaltothevalueofLF.

•  Iftiminggranularity=1compressionfunctionevaluation,thenwecanrecoverupto30bitsofplaintextfromtargetblock.

•  Challenging,butnotimpossibleinco-residentattackerscenario.

•  Possiblecountermeasuretotheattack:ifMACfails,thencomputesecondMACon218–LFbytesinsteadofonall218bytes.

•  StillleavesresidualtimingdifferencebecauseoffinedetailsofHMAC.

•  Reallyneedconstanttimeimplementationofdecryptionalgorithmtoeliminatethisclassofattack.

60

Disclosureoftheattack

•  WenotifiedtheOpenSSHteamoftheattackon5thMay2016.

•  TheyareconsideringaddingcountermeasuresforthenextreleaseofOpenSSH(7.3).

•  “…wedonotfeelthatanemergencyreleaseisnecessary,northattheattackremainsecretaheadofsucharelease.”

•  OpenSSHhassteadilybeendeprecatingoldalgorithmsandmodes.

•  CBCmodewasalreadydisabledbydefaultinOpenSSH6.7(butcanbere-enabled).

•  ButOpenSSHcannotforcepeopletostopusingoldversionsofthesoftware.

61

SecurityanalysisofotherSSHandOpenSSHmodes–CTR,gEtM,AES-GCM,ChaCha20Poly1305

Securityanalysisofotherencryptionmodes

•  The[APW09]attacksexploitstheattacker’sabilitytodeliverciphertextfragmentsandthe“cut-and-paste”propertiesofCBC-mode:

•  Decryptionoftargetblockinwrongpositionismeaningfullyrelatedtoitsdecryptionintrueposition:

63

IV Ci*

P0’

dK

Ci-1* Ci

*

Pi*

dK

Securityanalysisofotherencryptionmodes

•  ThecutandpastepropertydoesnotholdforCTRmode.

•  InsertingCi*inthestreamresultsinunrelatedplaintext:

P0’=Ci

*⊕eK(ctr0)=Pi*⊕eK(ctri)⊕eK(ctr0)

•  ButisCTRmodesecureagainstanadversarywhocandeliverciphertextinafragmentedfashion?

•  Classicalsecuritymodelsforsymmetricencryptioncannottellustheanswer.

•  AndwhatabouttheothermodesthathavebeenaddedtoOpenSSHsince2009?•  gEtM,AES-GCM,ChaCha20Poly1305.

64

SecurityanalysisofCTRmodeinSSH

•  [PW10]developedabespokesecuritymodelforCTRmodeinSSHandproveditsecure(assumingblockcipherisaPRP).

•  Themodelallowstheattackertodeliverciphertextstodecryptionoracleinabyte-by-bytefashion.

•  DecryptionoracleintendedtoaccuratelymodelOpenSSH’sCTRmodeimplementation.

•  Sanitycheckingoflengthfield,withrelatederrormessages,MACfailures,etc.

•  Complexpseudo-codedescriptionsofalgorithmsandoracles.

65

SecurityanalysisofotherOpenSSHencryptionmodes

•  [BDPS12]developedageneralframeworkforstudying“SymmetricEncryptionschemessupportingfragmenteddecryption”.

•  TheIND-CFAmodelallowstheattackertodeliverciphertexttoadecryptionoracleinasymbol-by-symbolfashionandobserveanyerrors/messageoutputs.

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

66

SecurityanalysisofotherOpenSSHencryptionmodes

•  [ADHP16]usedtheframeworkof[BDPS12]tostudygEtM,AES-GCM,andChaCha20-Poly1305inOpenSSH.

•  gEtMandAES-GCM:•  DerivedfromAEADschemeswithAD=lengthfield(nowunencrypted).

•  Hencesanitycheckingoflengthfieldcannotrevealanythingusefultoadversary.

•  IssueinOpenSSHcodeforgEtM:becauseofsharedpathwithlegacyE&Mcode,theMACiscomputedoncetheciphertexthasarrivedbutisnotcomparedtoreceivedMACuntilafterdecryption.

•  Henceanyerrorsarisingduringdecryptionstepwillbesignalledtoattacker.

•  Notasecuritythreatforanycurrentlyspecifiedencryptionschemes.

•  Both(fixed)gEtMandAES-GCMareprovablysecure.

67

ChaCha20-Poly1305inOpenSSH

68

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

SecurityanalysisofChaCha20-Poly1305inOpenSSH

•  ChaCha20-Poly1305inOpenSSH:•  64-bytekeyissplitintotwohalves,K1,K2.

•  K1usedtoencryptSSHlengthfieldusingChaCha20.

•  K2usedtoencrypteverythingelse,alsousingChaCha20.

•  Poly1305MACkeyisobtainedas:

ChaCha20(K2,IV=SQN||0630,M=0256).

•  MACappliedtobothciphertextcomponents.

•  Analysismorecomplexbecauseofencryptedlengthfield.

•  Ideaisthatusingseparatekeysforencryptinglengthfieldandthereststopsattacks.

•  CTRmodeanalysisshowsthistobeunnecessary.

69

Closingremarks

Closingremarks

•  Simplesecuritymodelsforsymmetricencryptionversuscomplexsecuritypropertiesdesiredofsecurechannels.

•  Infact,ourmodelsforsecurechannelsarestillevolving...

•  Thereismuchyettobedonehere,butcommunity’sfocusiscurrentlymostlyonAEAD.

•  Keytake-aways:

•  Takecryptographer’sabstractionswithapinchofsalt.

•  Thinktop-down,andonlybottom-up(fromAPItocrypto,notthereverse).

71

Closingremarks

72