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
