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