INF672ProtocolSafetyandVerification

Karthik BhargavanXavierRival

ThomasClausen

http://moodle.polytechnique.fr/enrol/index.php?id=19

1

CourseOutline

• Lecture1 [Today,Sep15]– Introduction,MotivatingExamples

• Lectures2-4 [Sep22,29,Oct6]– NetworkProtocolVerification:Spin

• Lectures5-8 [Oct13,20,27,Nov3]– ProgramVerification:Properties,Tools&Techniques

• Lecture9 [Nov10]– SecurityProtocolVerification:ProVerif

• Lecture10 [Nov17]– Exam

TLS:VerifyingSecurityProperties

SecureChannelsoverInsecureNetworks

• Man-in-the-middleattackersmay– Read datasenttoandreceivedfromservers– Tamper withthecontentsofmessages– Impersonate auseroraserver

WebServer

Internet

WebUser

• Werequireasecure(private,reliable)channel– serversareauthenticated,butclientsmayremainanonymous

• Toachievethis,wemustrelyoncryptography– Aunilaterally-authenticatedkeyexchangeprotocol

TransportLayerSecurity(1994--)• Themostwidelydeployedcryptographicprotocol

– Web,Wi-Fi,VPN,Mail,Chat,VoiceoverIP,…

– SChannel (Windows) NSS (Firefox,Chrome)SecureTransport (iOS,OSX) OpenSSL (Servers,Linux,Android)

• Manystandardizedversionsandprotocolextensions– 1994– Netscape’sSecureSocketsLayer– 1995– SSL3– 1999– TLS1.0(RFC2246,≈SSL3)– 2006– TLS1.1(RFC4346)– 2008– TLS1.2(RFC5246)

• Manyrecentflaws&attacks– GotoFail,HeartBleed,3Shake– Whatcausestheseattacks?

Client C Server S1C has: certC , pkC , skC S has: certS , pkS , skS

ClientHello(cr, [KEX ALG1, KEX ALG2, . . .], [ENC ALG1, ENC ALG2, . . .])ServerHello(sr, sid , KEX ALG, ENC ALG)

ServerCertificate(certS , pkS)

Verify certS is valid for host S 2ServerKeyExchange(kexS)

Verify signature using pkS 1CertificateRequestServerHelloDone

1ClientCertificate(certC , pkC)

Verify certC is valid

ClientKeyExchange(kexC)log1 log1

1CertificateVerify(sign(skC , log1))log2 log2

1Verify signature using pkCCompute ms from kexC , kexS

Compute ms from kexC , kexS

ClientCCS

ClientFinished(verifydata(ms, log2))log3 log3

Verify finished using msServerCCS

ServerFinished(verifydata(ms, log3))

Verify finished using ms

Cache new session:sid ,ms, certC1/anon → certS ,

cr, sr, KEX ALG, ENC ALG

Cache new session:sid ,ms, certC1/anon → certS ,

cr, sr, KEX ALG, ENC ALG

. . .AppDataiAppDataj

. . .CloseNotifyAlert

CloseNotifyAlert

Hello,I’dliketoconnecttoGoogleHi,I’mGoogle

(here’smycertificate)Let’sexchangekeyswithRSA

AuthenticatedKeyExchange

(RSAorDiffie-HellmanorPSKorKerberosor…)

Ok,IhavethekeysLet’sstarttalking Yourkeyslookfine

Sendmedata

EncryptedApplicationDataExchange

(HTTPorSMTP or…)I’mdone.Goodbye. Gotit.Goodbye.

RSAKeyTransportClient Server

rsa-enc(pms,pkS)=[pad|pms]e modpq

pq

Client Server

pms =gxy modp

(gx)y modp=(gy)x modp(gx, gy),hardtofindgxy

log(gx)modp)porellipticcurves

• Pros:Forwardsecurity,surveillanceresistant

pms =gxy modp

rsa-sign(hash(cr |sr |p|g|gy),skS)

TLSSecurityGoals

• Confidentiality:– IfaclientC sendssecretdataD toserverS,

thenDisnotleakedtotheadversary• AuthenticationandIntegrity:

– WhenCreceivesDoveraconnection withS,itmustbethatSsentDoverthisconnection

– Concretely,anattackercannotimpersonateanhonestHTTPSwebsiteorstealitsusers’passwords

• Network/Adversaryassumptions(threatmodel):– Theadversaryfullycontrolsthenetworkand

allotherclientsandservers– WeassumethatCandSarehonest,thatis,

theirlong-termcredentialsareunknowntotheadversary– Theprobabilityoftheadversarybreakinga

cryptographicprimitiveorguessingasecretisnegligible

WhatcangowrongwithTLS?

• Implementationbugs– Parsingmessagesincorrectly [HeartBleed]– Forgettingcryptographicchecks [GotoFail]– Confusingthesequenceofmessages [SKIP,FREAK]

• Cryptographicweaknesses– RC4,RSA-PKCS1.5,MAC-Then-Encrypt– Theoreticalattacksmaynotbeimmediatelyexploitable,buttheyalwaysgetyouintheend [BREACH,CRIME]

• Incorrectprotocolcomposition– ConfusingDHEwithECDHE [CrossProtocol]– SessionResumptionandRenegotiation [3Shake]

FINDINGIMPLEMENTATIONBUGS

RSA(EC)DHE

RSA+DHE+ECDHE+SessionResumption+ClientAuthentication

StatemachineforcommonWebconfigurations

+Fixed_DH+DH_anon+PSK+SRP+Kerberos+*_EXPORT+…

ThesearetheonesimplementedinOpenSSL

DoimplementationsconformtotheTLSstatemachine?

Let’sbuiltatestframework

StatemachineforcommonWebconfigurations

UnexpectedstatetransitionsinOpenSSL,NSS,Java,SecureTransport,…• Requiredmessagesareallowedtobeskipped

• Unexpectedmessagesareallowedtobereceived

• CVEsformanylibrariesHowcomeallthesebugs?• Inindependentcodebases,sittinginthereforyears

• Aretheyexploitable?

UnexpectedstatetransitionsinOpenSSL,NSS,Java,SecureTransport,…• Requiredmessagesareallowedtobeskipped

• Unexpectedmessagesareallowedtobereceived

• CVEsformanylibrariesHowcomeallthesebugs?• Inindependentcodebases,sittinginthereforyears

• Aretheyexploitable?

1. SKIP [CVE-2014-6593]HowtoimpersonatearbitraryserverstoaJavaTLSclient

2. FREAK [CVE-2015-0204,…]HowtodowngradeandbreakRSAconnectionsfromSafari/IE/Chrome

3. LOGJAM [CVE-2015-4000]HowtodowngradeandbreakDHEconnectionsfromanyTLSclient

SKIPpingNetworkattackerimpersonatesapi.paypal.com toaJSSEclient1. SendPayPal’scert2. SKIPServerKeyExchange

(bypassserversignature)3. SKIPServerHelloDone4. SKIPServerCCS

(bypassencryption)5. SendServerFinished

usinguninitializedMACkey(bypasshandshakeintegrity)

6. SendApplicationData(unencrypted)asS.com

SKIP• Anetworkattackercanimpersonate

anyserver(Paypal,Amazon,Google)toanyJavaTLSclient(builtwithJSSE)

• AffectsallversionsofJavauntilJan2015CPU(CVE-2014-6593)

• CCSskippingbugalsofoundincyassl(wolfSSL),monoTLS,GNUclasspath

FREAK• TLS-RSAkeytransport:

rsa-enc(pms,pkS)=[pad|pms]e modpq

• Ifpq canbefactoredintopandq,anattackercanbreakprivatekey

• 512-bitkeysfirstfactoredin1999• 768-bitkeysfirstfactoredin2009

• Browsersnowrequire>=1024-bitkeys(soonmovingto>=2048bits)

TLS1.0supportedweakenedcipherstocomplywithexportregulationsin1990s

EXPORTdeprecatedin2000

• CanbetriggeredbysendinganunexpectedServerKeyExchange

FREAK

Aman-in-the-middleattackercan:• impersonateserversthatsupportRSA_EXPORT,• atbuggyclientsthatallowServerKeyExchange inRSA

Step1:FindavulnerableTLSserver

Onethatsupportsoneof:TLS_RSA_EXPORT_WITH_RC4_40_MD5

TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5TLS_RSA_EXPORT_WITH_DES40_CBC_SHA

About25%ofHTTPSserversaffectedSee:www.freakattack.com

Step2:Factorits512-bitephemeralRSApublickey

• CADO-NFS(INRIACaramel):http://cado-nfs.gforge.inria.fr/

• Factoring-as-a-service(NHeninger):https://www.cis.upenn.edu/~nadiah/projects/faas/

7-11hourslater….

Step3:Finda(buggy)TLSclientthatiswillingtorollbackRSAtoRSA_EXPORT

SafarionOSXandiOS (SecureTransport

Step4:Runaman-in-the-middleTLSproxytoimpersonatetheserver

RequiresanetworkattackerwhocantamperwithDNSoramaliciousaccesspointoracompromisedTCPproxy

Wesimulatethisbyeditingtheclientmachine’s/etc/hosts file

Many,ManyBugsDidwefindallthebugs?• Testingcannotcoverallpathsinanunbounded-stateprotocol

• Attacksrelyoncomplexcombinationsofcryptographicweaknessesandcodingbugs

Canweprovethecodeinstead?• Asecuritytheoremthatnoattacksexist(againstawelldefinedthreatmodel)?

FINDINGPROTOCOLPROBLEMS

TripleHandshakeAttack[3Shake]• Anewprotocol-levelattackonTLS– Maliciousserverscanimpersonateuserattrustedservers– Reliesoncryptographicweaknessesinkeyexchange– Exploitsthecompositionof3differentmodesofTLS– Revealsunsafeimplementationsinmainstreambrowsers– Affectsbankingwebsites,Wi-Fi,VPN,GIT,Chatservers

Client C Server S1C has: certC , pkC , skC S has: certS , pkS , skS

ClientHello(cr, [KEX ALG1, KEX ALG2, . . .], [ENC ALG1, ENC ALG2, . . .])ServerHello(sr, sid , KEX ALG, ENC ALG)

ServerCertificate(certS , pkS)

Verify certS is valid for host S 2ServerKeyExchange(kexS)

Verify signature using pkS 1CertificateRequestServerHelloDone

1ClientCertificate(certC , pkC)

Verify certC is valid

ClientKeyExchange(kexC)log1 log1

1CertificateVerify(sign(skC , log1))log2 log2

1Verify signature using pkCCompute ms from kexC , kexS

Compute ms from kexC , kexS

ClientCCS

ClientFinished(verifydata(ms, log2))log3 log3

Verify finished using msServerCCS

ServerFinished(verifydata(ms, log3))

Verify finished using ms

Cache new session:sid ,ms, certC1/anon → certS ,

cr, sr, KEX ALG, ENC ALG

Cache new session:sid ,ms, certC1/anon → certS ,

cr, sr, KEX ALG, ENC ALG

. . .AppDataiAppDataj

. . .CloseNotifyAlert

CloseNotifyAlert

ApplicationDataExchange

TLSHandshake

[ProvedsecureinCRYPTO’13]

TLSRenegotiationAttack[2009]MartinRex’sVersion(Compoundauthenticationfailure)

SconfusesdatasentbyCandM

C connectstoM

C renegotiates(withacertificate)

M connectstoS

M sendsitsowndatatoS,thenforwardsC’srenegotiaton

SasksMforacertificate

MasksCforacertificate

C sendsdata

TLSRenegotiationFix[2009]

Cryptographicallybindthetwohandshakes

Bindingwon’tmatch!

SrefusestorenegotiateProvedSecureinCCS’13

3ShakeAttack[2014]

• Threehandshakes– C connectstoM– CresumessessiononanewconnectionwithM

– CrenegotiateswithM• McanimpersonateCatanyotherserverS– ReliesoncryptographicweaknessesinTLS’sRSAandDHEexchanges

– Bypassesrenegotiationfix

3ShakeImpact

• SecurityupdatesandCVEs– Chromium[Chome,Opera,Android]– SChannel [InternetExplorer],SecureTransport [iOS,OSX,Safari]– BugBountiesfromChromium,Firefox,HackerOne

• NewfixesproposedforTLSprotocol– UndergoingstandardizationatIETF– WillbecomemandatoryforallTLSimplementations– Papers,demos:Seehttp://secure-resumption.com

• AttackexistssinceSSL3.0(1998)– Whydidnobodyfindit?– Three(different)statemachinesdifficulttoanalyzebyhand;

Caseanalysisrequiresautomatedmethods– Thedesiredcompoundauthenticationpropertyissubtle;

Easiertoreasonaboutinaformalsetting

FormalAnalysesofTLS

• LonghistoryofformalmethodsforTLS– Theoremproving:

InductiveanalysisoftheInternetprotocolTLS,LCPaulson,ACMTISSEC’99

– Specializedcryptographicproving(ProVerif):CryptographicallyverifiedimplementationsforTLS,KBhargavan,CFournet,RCorin,EZalinescu,CCS’08

– Modelchecking:ASPIER:AnAutomatedFrameworkforVerifyingSecurityProtocolImplementations,SChaki,ADatta,IEEECSF’09

– Typechecking:ImplementingTLSwithverifiedcryptographicsecurityKBhargavan,CFournet,MKohlweiss,APironti,P-YStrub

3ShakeinProVerif

ClientProcess:InitialRSAHandshake

ClientProcess:ResumptionHandshake

ClientProcess:RenegotiationHandshake

CryptoModel:RSAEncryption

ProVerifautomatically

findsthe3Shakeattackcodedasareachability

query

ProofsforProtocolImplementations

• ReferenceimplementationofTLS1.2inF#– 5000linesofcode,2500linesoflogicalspecification– Automatedproofsbytypechecking withF7

• CollaborationbetweenMicrosoftResearchandINRIA• Supportsmajorprotocolversions,ciphersuites

• PapersinIEEES&P(Oakland)2013,CRYPTO2014• Moredetails,sourcecode:http://mitls.org

Links• PROSECCO:http://prosecco.inria.fr

• miTLS:http://mitls.org• 3Shake:http://secure-resumption.com

• F#:http://fsharp.org• F7:http://research.microsoft.com/f7• F*:http://research.microsoft.com/fstar

46

VERIFYINGWITHPROVERIF

ProVerif QuerySyntax

• Isglobalvariablexsecret?queryattacker(x)

• Isreceivedmessagemauthentic?querym:bitstring;Recv(m)==>Sent(m)

• Whatifthesender’skeyiscompromised?querysk:skey,m:bitstring;Recv(pk(sk),m)==>(Sent(pk(sk),m)||attacker(sk))

Download:http://prosecco.inria.fr/personal/karthik/Lecture-8-Materials.zip

• DesignandmodelasecureRPCprotocolfor:– A->B:x– B->A:f(x) (wherefissomesecretfunction)

• Securitygoals:– Secrecyofx,f(x)– Requestauthentication:ifBreceivesarequesty,itwassentbyA

– Responseauthentication:ifAreceivesaresponsez toitsrequesty,thenz wascomputedbyBasf(y)

• Initially:A,Bknoweachother’spublickeys