ProtectingTLSfromLegacyCrypto
Karthikeyan Bhargavan+many,manyothers.(INRIA,MicrosoftResearch,LORIA,IMDEA,Univ ofPennsylvania,Univ ofMichigan,JHU)
http://mitls.org
Popularcryptographicprotocolsevolve
Agility:gracefultransitionfromoldtonew
Whatcangowrong?
• Downgradeattacks thatexploitobsoletelegacycrypto
• FREAK Export-grade512-bitRSA [Mar’15]• LOGJAM Export-grade512-bit DH [May’15]• SLOTH RSA-MD5signatures [Jan’16]
• TLSwassupposedtopreventdowngradeattacks• Whatwentwrong? HowdowefixitinTLS1.3?
2016?TLS1.3
OpenSSL,SecureTransport,NSS,SChannel,GnuTLS,JSSE,PolarSSL,…manybugs,attacks,patcheseveryyear
mostlyforsmallsimplifiedmodelsofTLS
Client Server
Protocolversions
Keyexchanges
Authenticationmodes
AuthenticatedEncryptionSchemes
100sofpossibleprotocolcombinations!
TLS_RSA_WITH_AES_128_CBC_SHA
RSAKeyTransport• RSA-PKCS#1v1.5encryption• [1998]Bleichenbacher
attackandfixes• [2013]Cryptoproof
forTLS-RSA• [2016]DROWNattack:
downgradetoSSLv2
AES-CBC+HMAC• MAC-Encode-EncryptScheme• [2002]Vaudenay attack• [2011]Cryptoprooffor
TLSMEE-CBC• [2013]Lucky13attack• [2014]PoodleattackonSSLv3• [2016]Verifiedimplementation
TextbookcryptoproofsnotapplicabletoTLS
Theoreticalattacksnotalwaysexploitable
Mostcryptoproofsareforsingleconstructs
Manyattacksappearonlyincomposition
Toomanycompositionstoprovebyhand• Weneedautomatedverificationtoolsthatcananalyzebothprotocolsandimplementations
AverifiedreferenceimplementationofTLS
Specificationandverificationusingtypes
Ajointeffortbyalargeresearchteam
TripleHandshakeAttacks [S&P2014]• Breakingclientauthenticationbycomposing threedifferenthandshakemodes
StateMachineAttacks(e.g.FREAK) [S&P2015]• BugsinthecompositestatemachinesimplementedbymainstreamTLSlibraries
Logjam [CCS2015]• DHgroupdowngradeusingDHE_EXPORTSLOTH [NDSS2016]
DowngradeAttacksonAgileKeyExchange
AnonymousDiffie-Hellman(DHanon)
Man-in-the-MiddleattackonDHanon
ActiveNetworkAttackerorMaliciousPeer
SIGMA:AuthenticatedDH
PKI
Sign-and-MACthetranscript:preventsmostMitM attacks
SIGMAwithGroupNegotiation
Why? backwardscompatibility,
exportregulations,…
DHGroupNegotiation
Export-Grade512-bitDHEinTLSTLS1.0supporteddeliberatelyweakenedcipherstocomplywithexportregulationsin1990s
EXPORTdeprecatedin2000butstillsupportedbyTLSin2015• 8.4%ofTop1MwebsitesinMarch2015• BrowsersonlysupportDHE,notDHE_EXPORTbutwillaccept512-bitDHgroupsforDHE
• Protocolflaw:Server’sDHEandDHE_EXPORTkey-sharesandsignatures lookthesametoaTLSclient
Logjam:MitM GroupDowngradeAttack
Computediscretelogson512-bitDHgroupsinreal-time
RemoveStrongGroups
Client/ServerImpersonation
DowngradeProtectioninTLS1.2
• InTLS1.2,bothclientandserverMACthefulltranscripttopreventtampering:
mac(k,[G2048,G512]|G512 |m1 |m2)• Butit’stoolate,wealreadyusedG512 tocomputek
k =kdf(gxy modp512)so,theattackercancomputek andforgetheMAC
TheTLS1.2downgradeprotectionmechanismitselfdependsondowngradeable parameters!• Wecanbreakitifwecancomputethediscretelogwhiletheconnectionisstilllive
Logjam
MostTLSserversusewell-known512-bitgroups• 92%ofDHE_EXPORTserversuseoneoftwogroups• 1-2weeksofprecomputationpergroup(CADO-NFS)• 90secondstocomputediscretelogforeachkey• Practitionersseeminglyunawareofthisoptimization!
Logjam
TheTLStranscriptMACdoesnotpreventDiffie-Hellmangroupdowngrades• MustdisableallweakDHgroupsandellipticcurves• Browsersmovingto1024-bitminimumgroupsize• Breaking768-bitand1024-bitgroupswillhavea
catastrophicimpactonTLS,SSH,andIPsec
Couldwedobetterbyrelyingontranscriptsignaturesfordowngradeprotection?
DowngradeProtectionviaSignaturesIKEv1:bothAandBsigntheofferedgroups• sign(skB,hash([G2048,G512]|m1 |m2))• noagreementonchosengroup!
IKEv2:eachpartysignsitsownmessages• sign(skA,hash([G2048,G512]|m1))• sign(skB,hash(G512 |m2))• noagreementonofferedgroups!
SSH-2andTLS1.3:signthefulltranscript• sign(k,hash([G2048,G512]|G512 |m1 |m2))• PreventsLogjam(butwhataboutotherdowngrades?)
SIGMAwithGenericNegotiation
Version/Group/CipherParameters
SignedTranscript
DowngradeProtectionviaSignatures
• Signthefulltranscript– sign(skB,hash(m1 |m2))– Example:TLS1.3,SSH-2,TLS1.2clientauth
• Howweakcanthehash functionbe?– doweneedcollisionresistance?– doweonlyneed2nd preimage resistance?– IsitstillsafetouseMD5,SHA-1inTLS,IKE,SSH?– Disagreement:cryptographersvs.practitioners
(seeSchneier vs.Hoffman,RFC4270)
SLOTH:TranscriptCollisionAttacks
ServerImpersonation
ClientImpersonation
ParameterDowngrade
Man-in-the-Middle:networkattacker/maliciousserver
ComputingaTranscriptCollision
hash(m1 |m’2) =hash(m’1 |m2)
• Weneedtocomputeacollision,notapreimage– Attackercontrolspartsofbothtranscripts– Ifweknowtheblackbits, canwecomputethered bits?– Thiscansometimesbesetupasagenericcollision
• Ifwe’relucky,wecansetupashortcut collision– Common-prefix:collisionafterasharedtranscriptprefix– Chosen-prefix:collisionafterattacker-controlledprefixes
PrimeronHashCollisionComplexity
• MD5:knownattackcomplexities– MD5secondpreimage 2128hashes– MD5 genericcollision: 264hashes (birthday)– MD5chosen-prefixcollision: 239hashes (1hour)– MD5 common-prefixcollision: 216hashes (seconds)
• SHA1:estimatedattackcomplexities– SHA1secondpreimage 2160hashes– SHA1 genericcollision: 280 hashes (birthday)– SHA1chosen-prefixcollision: 277 hashes (?)– SHA1 common-prefixcollision: 261 hashes (?)
hashhash
ComputingTranscriptCollisions
len1gx
paramsA
len1’gx’
params’A
len2gy
paramsB
len2’gy’
params’B
A BMitM
m1 m1’
m2m2’
GenericTranscriptCollisions
len1gx
nonceA
len1’gx’
nonce1len2gstatic
nonceA
len2’gy’
nonce1
A BMitMhash hash
len2’gy’
nonce2
len1’gx’
nonce2
len1’gx’
nonceNlen2’gy’
nonceN
Predictable:StaticDHkey,nofreshnonce
Tryrandomnoncesuntilcollision
N=2|hash|/2MD5:264SHA-1:280
HMAC/96:248
Chosen-PrefixTranscriptCollisions
len1gx
blobAlen2gy
blobB
A BMitM
Knownlength,ephemeralDHkey,arbitraryBLOB
m1
m2
len1gx
blobA
len2gy
blobB
len2’gy’
C1
A BMitM
len1’gx’
00000000
0000000000000000
C2len2gy
blobB
hash hash
blobA’
blobB’
FindChosen-PrefixCollisionC1,C2
m1 m1’
m2m2’
Merkle-Damgardhashextension
N=2CPC(hash)MD5:239SHA-1:277
DowngradingandAttackingTLS1.2TLS1.2upgradedthehashfunctionsusedinTLS• TLS1.1hard-codedtheuseofMD5||SHA-1• TLS1.2usesSHA-256forallhandshakeconstructions• Allowsnegotiationofhashfunctions:SHA-256/384/512
TLS1.2addedsupportforMD5-basedsignatures!• EveniftheclientandserverpreferRSA-SHA256,
theconnectioncanbedowngradedtoRSA-MD5!
TranscriptcollisionsbreakTLS1.2clientsignatures• Chosenprefixcollisionexploitingflexiblemessageformats• Demo:Takes1hour/connectionona48-coreworkstation• Notverypractical:connectionmustbeliveduringattack
AttackingTLSServerAuth
• TLS1.2serversignaturesarehardertobreak– Irony:theweaknessthatenablesLogjamblocksSLOTH– Needs2Xpriorconnections+2128-Xhashes/connection– Notpracticalforacademics,asfarasweknow
• TLS1.3serversignaturesispotentiallyvulnerable– New:MD5,SHA-1sigsnowexplicitlyforbiddeninTLS1.3
OtherHashConstructionsinTLS
• Whenusedastranscripthashfunctionsmanyconstructionsarenotcollisionresistant– MD5(x)|SHA1(x)notmuchbetterthanSHA1
– HMAC-MD5(k,x)notmuchbetterthanMD5
– HMAC-SHA256(k,MD5(x))notmuchbetterthanMD5
– TruncatedHMAC-SHA256(k,x)toNbitsnotmuchbetterthanaNbithashfunction
OtherSLOTHVulnerabilities
ReducedsecurityforTLS1.*,IKEv1,IKEv2,SSH• ImpersonationattackonTLSchannelbindings• Exploitsdowngrades+transcriptcollisions• Protocolflaws,notimplementationbugs• Onlymitigationistodisableweakhashfunctions
LogjamandSLOTH:LessonsLearnedLegacycryptocanremainhiddenforalongtime• FindingDHE_EXPORT,RSA-MD5enabledwassurprising
Importanttodemonstrateconcreteattacks,notjusttheoreticalweaknesses• Concreteattackscanhelpmotivatenewcryptanalyticoptimizations,andjustifyimplicitproofassumptions
TLS1.2doesnotpreventsomedowngrades• Needforaformalmodelofdowngraderesilienceandanewprotocolthatprovablyachievesit
DowngradeResilienceinKeyExchangeProtocols
AKEswithParameterNegotiation
• Let’sconsidertwopartyprotocols(I R)• Keyexchangeinputs:– configI &configR: supportedversions,ciphers,etc.– credsI &credsR: long-termprivatekeys
• Keyexchangeoutputs:– uid: uniquesessionidentifier– k: sessionkey–mode: negotiatedversion,cipher, etc.
AgileAKESecurityGoals• Partneringatmostonehonestpartnerexistswithsameuid
• Agreementifmynegotiatedmodeusesonlystrongalgorithms,thenmypartnerandIagreeonkandmode
• Confidentialityifmynegotiatedmodeusesonlystrongalgorithms,thekeykisonlyknowntomeandmypartner
• Authenticityifmyintendedpeerisauthenticatedandhonest,andmynegotiatedmodeusesonlystrongalgorithms,thenatleastonepartnerwithsameuid exists
AgileAgreementvs.Downgrades
• Agreementifmynegotiatedmodeusesonlystrongalgorithms,thenmypartnerandIagreeonkandmode
• Agreementdoesnotguaranteethattheprotocolwillnegotiateastrongmode– So,itdoesnotforbiddowngradeattacks– Topreventdowngrades,allalgorithmsintheintersection ofconfigI &configRmustbestrong
–WhatifconfigI &configR includealegacyalgorithm?
ANewDowngradeResilienceGoal• IdealNegotiation: Nego(configI,configR)Informally,themodethatwouldhavebeennegotiatedintheabsenceofanattacker
• DowngradeResilienceTheprotocolshouldnegotiatetheidealmodeeveninthepresenceoftheattacker
mode=Nego(configI,configR)
(DetailsinIEEES&P2016,see:mitls.org)
TestingtheDefinition
• IKEv1doesnotpreventdowngrades– KnownDHgroup,ciphersuite downgrades
• IKEv2doesnotpreventdowngrades– NewattackonEAPmode
• ZRTPdoesnotpreventdowngrades– Newattackonpre-sharedmode
• SSHv2isdowngraderesilientifSHA-1notused– Strongeragreementtheoremthanpreviouswork
Strongerkeyexchanges,feweroptions• ECDHEandDHEbydefault,noRSAkeytransport• StrongDHgroups(>2047bits)andECcurves(>255bits)• OnlyAEADciphers(AES-GCM),noCBC,noRC4
Faster:lowerlatencywith1round-trip• 0-roundtripmodealsoavailable
Cryptoproofsbuiltside-by-sidewithstandardization• Activeparticipationbyalargegroupofresearchers• Proofsinmultiplesymbolicandcomputationalmodels• VerifiedimplementationinmiTLS (ongoingwork)
TLS1.3NegotiationSub-Protocol
1:GroupNegotiationwithRetry
• Servercanaskclienttoretrywithanothergroup–WhatifattackersendsabogusRetry?
• Idea:ThetranscripthashesbothhellosandretrytopreventtamperingofRetrymessages.
2:FullTranscriptSignatures
• ClientandServerbothsignfull transcript– OnlySHA-256ornewerhashalgorithmsallowed– Downgraderesiliencecanrelyonlyonsignatures– Logjam-likeattacksareprevented!
3:PreventingVersionDowngrade• ClientsandserverswillsupportTLS1.2foralongtime– TLSversionsevolveslowlyontheweb:TLS1.0isstillthemostwidelydeployedversion
• AnattackermaydowngradeTLS1.3toTLS1.2andthenreuseknowndowngradeattacks!– TLS1.3clientsandserverswillstillbevulnerabletoLogjam
• Idea:theserverincludesmaximumsupportedversioninservernonce(64upperbits)– servernonceissignedinallversionsTLS1.0-1.3– onlyprotectssignatureciphersuites,notRSAencryption
TLS1.3isDowngradeResilient• Weprovedowngraderesilienceforthenegotiationsub-protocolofTLS1.3 [S&P2016]
• FREAK Export-grade512-bitRSA [Mar’15]• LOGJAM Export-grade512-bit DH [May’15]• SLOTH RSA-MD5signatures [Jan’16]
• TLSwassupposedtopreventdowngradeattacks• Whatwentwrong? HowdowefixitinTLS1.3?
FinalThoughts
• Legacycryptoisstrangelyhardtogetridof,butwehavetokeeptryingtokillbrokenprimitives
• Weneednewdowngraderesilientprotocols
• Inpriorversions,TLSsufferedalargetimelagbetweenstandardizationandproofsofsecurity
• WithTLS1.3,researchersareclosingthisgap
• Moredetails,papers,demosareat:http://mitls.org