FOSAD2016SummerSchoolAug29–Sep32016
VerifyingSecurityProtocolImplementaAonswithRefinementTypesThemiTLScasestudyAlfredoPironA–[email protected]
TransportLayerSecurity(1995—)Themostwidelydeployedcryptographicprotocol?
HTTPS,802.1x(EAP),FTPS,VPN,mail,VoIP,…
19yearsofaXacks,fixes,andextensions
1995–Netscape’sSecureSocketsLayer1995–SSL21996–SSL31999–TLS1.0(RFC2246,≈SSL3)2006–TLS1.1(RFC4346)2008–TLS1.2(RFC5246)
ManyimplementaAons• SChannel,OpenSSL,NSS,
GnuTLS,JSSE,PolarSSL,…• SeveralsecuritypatcheseveryyearManypapers• Well-understood,detailedspecs• Securitytheorems…mostlyforsmallsimplemodelsofTLS
SAllhottopicinpracAceandtheory• Atleast11researchpapersinthelast3years
– Ofwhich5describingaXacks• Severalflawsfoundinthelast2years
– Protocollogic(e.g.AlertaXack,TripleHandshake,Logjam)– ImplementaAonspecific(e.g.gotofail;Heartbleed;CCSinjecAon;ClientHellofragmentaAon,FREAK)
– Cryptography(RC4,3DES)
WhatcansAllpossiblygowrong?
ProtocolLogice.g.ambiguousmessages• causeserverstoaXribute
secretstowrongclients
Cryptographye.g.nofreshIV• writeappletto
realizeadapAveaXack(BEAST)
WeakAlgorithmsMD5,PKCS1,RC4,…
ImplementaAonErrorsmanycriAcalbugs
TLSDESIGN
InfrastructurecerAficatemanagement
ApplicaAonprotocolconfiguraAon
TLSinF#&F7:miTLSDevelopandverifyareferenceimplementaAonofSSL3.0—TLS1.2
1. Standardcompliance:closelyfollowtheRFCs– concretemessageformats– supportformulApleciphersuites,sessionsandconnecAons,
re-handshakesandresumpAons,alerts,messagefragmentaAon,…– interopwithotherimplementaAonssuchaswebbrowsersandservers
2. Verifiedsecurity:codeisstructuredtoenablemodularverificaAon,fromitsmainAPIdowntoconcreteassumpAonsonitsbasecryptography(e.g.RSA)– formalcomputaAonalsecuritytheorems
fora7000-linefuncAonality(automaAonrequired)
3. ExperimentalplaMorm:FlexTLS– fortesAngcornercases,tryingoutaXacks,analysingnewextensionsand
patches,…
TLSSecurityGoals,Informally
TCP
ApplicaAon
data
TLSCrypto
• Goals– PlaintextconfidenAality– Server(andclient)authenAcaAon– Streamintegrity
• GivenaTLSconnecAonwith– HonestparAes– Strongcryptoalgorithms– Recentprotocolversionsandextensions
Challenges
• Cryptographicagility– Ciphersuites,protocolversions– Someareweakerthanothers– ProvesecurityforthenegoAatedparameters
• Complexstatemachines– MulApleepochs:iniAalhandshake;resumpAon;renegoAaAon– FragmentaAon– Specifyandprovesecurityinvariants
TCP FirstHandshake Data Rehandshake Data Alert
Epoch0 Epoch1 Epoch2
VerificaAonApproach:ModularRefinementType-Checking
TLSProtocolStructure
• ChangeCipherSpec:signalingnewkeys
• Alert:errorsandwarnings
reliabletransportprotocol(e.g.TCP)
Record
Handshake&CCS
ApplicaAon
Alert
• Record:privatereliableconnecAon• Handshake:ciphersuitenegoAaAon,
keyexchange
BetweenTCPandApplicaAon
DHGroup
DH
CRE
PRF
RSA
Cert
Sig
SessionDB
StAE
LHAE
Enc
MAC
Record
Dispatch
TCP
UntypedAdversary
Encode
LHAEPlain
StPlain
TLSFragment
AlertDatastream
Handshake(andCCS)
TLSInfoTLSConstants
Handshake/CCS
TLSRecord
AppData
Base Bytes
UntypedAPIAdversary
RPC
RPCPlainApplicaAon
TLSAPI
AlertProtocol
AppDataProtocol
Nonce
TLS
CoreCrypto
RSAKey
Auth
AuthPlain
Extensions
1
2
3 4
5
67
Range
8
9Error
ModularArchitectureformiTLS
F7:refinementtypecheckingforF#[BFG’11]
• WeprograminF#• WespecifyinF7• Weverifymodules
againstinterfaces:F7typechecks&callsZ3,anSMTsolver,oneachlogicalproofobligaAon
RPC.fs7
RPC.fs
RPC.fsi
Type(F7)
Prove(Z3)
Compile(F#)
Erasetypes
AE.fs7
Lib.fs7TLS.fs7
RefinementTypes[BFG’11]
• AvalueMoftypex:T{C(x)}issuchthat– MhastypeT– FormulaC(M)holds
• DependentfuncAons
typenat=x:int{x>=0}valcreateBytes=l:nat->x:bytes{Length(x)=l}
PrecondiAonl>=0
PostcondiAon
• Weusethesetypesto– SpecifycryptographicassumpAons– VerifyprotocolcodebypropagaAngtheseassumpAons
Type-BasedCryptographicVerificaAon
Example:aFlawedRPC
moduleRPC
definition!k,na,msg.Msg(k,na,msg)ó Request(na,msg)\/Response(na,msg)
letclient_sendreq=letclient_recvres=//precondition: …ifVERIFYk(na,res)mac//Request(na,req)then//wehaveResponse(…)orRequest(…)…sendMACk(na,req)assertResponse(…)//willnottypecheck
Na, Req, MACKa(Na, Req)
Client Gateway
Na, f(Req), MACKa(Na, f(Req))
Example:apossibleFix
moduleRPC
definition!k,na,msg.Msg(k,tag,na,msg)ó(tag=0/\Request(na,msg))\/(tag=1/\Response(na,msg))
letclient_sendreq=letclient_recvres=//precondition: …ifVERIFYk(1,na,res)mac//Request(na,req)then//wehaveResponse(…)…sendMACk(0,na,req)assertResponse(…)//willtypecheck
Na, Req, MACKa(0, Na, Req)
Client Gateway
Na, f(Req), MACKa(1, Na, f(Req))
DHGroup
DH
CRE
PRF
RSA
Cert
Sig
SessionDB
StAE
LHAE
Enc
MAC
Record
Dispatch
TCP
UntypedAdversary
Encode
LHAEPlain
StPlain
TLSFragment
AlertDatastream
Handshake(andCCS)
TLSInfoTLSConstants
Handshake/CCS
TLSRecord
AppData
Base Bytes
UntypedAPIAdversary
RPC
RPCPlainApplicaAon
TLSAPI
AlertProtocol
AppDataProtocol
Nonce
TLS
CoreCrypto
RSAKey
Auth
AuthPlain
Extensions
1
2
3 4
5
67
Range
8
9Error
ModularArchitectureformiTLS
protocoladversarytypedagainstRPCinterface
ComputaAonalSafetyforAE[FKS’11]concretesystem
RPCprotocol
AE
sampleprotocoltypedagainstidealAEinterface
Idealfilter
errorcorrecAonmakingDECfailonforgeriesIdealAE
AE
Anyp.p.t.adversary
RPCprotocol
Anyp.p.t.adversary
F#interfaceF#interface
idealsystem
secureRPC
concretealgorithmassumedINT-CTXTcomputaAonally
safetoo,withoverwhelmingprobability
perfectlysafebytyping
INT-CT
XT
adversary
PlaintextModules
• EncrypAonisparameterizedbyamodulethatabstractlydefinesplaintexts,withinterface
modulePlaintext
valsize:inttypeplain typerepr=b:bytes{Length(b)=size}
valcoerce:repr->plain//turningbytesintosecretsvalleak:plain->repr//breakingsecrecy!
valrequest:unit->plainvalrespond:plain->plain//sampleprotocolcode
IfweremovetheleakfuncAon,wegetsecrecybytyping
PlainmayalsoimplementanyprotocolfuncAonthatoperatesonsecrets
IfweremovethecoercefuncAon,wegetintegritybytyping
IdealInterfaceforAuthenAcatedEncrypAon
• RelyingonbasiccryptographicassumpAons(IND-CPA,INT-CTXT)itsidealimplementaAonneveraccessesplaintexts!Formally,idealAEistypedusinganabstractplaintype
ENCkp encryptsinsteadzerostocandlogs(k,c,p)DECkc returnsSome(p)when(k,c,p)isinthelog,orNone
moduleAEopenPlaintext
typekeytypecipher=b:bytes{Length(b)=size+16}
valGEN:unit->keyvalENC:key->plain->ciphervalDEC:key->cipher->plainopAon
TowardsTLS:addingTypeIndexes
• WithinTLS,wekeeptrackofmanykeys,fordifferentalgorithms&sessions
• WeusefineridealfuncAonaliAesthatprovidecondiAonalsecurityonlyfor“good”keys– generatedbyalgorithmsassumedcomputaAonallystrong;and– forsessionsbetweenhonestparAcipants
(notthosewiththeadversary)
moduleAEopenPlaintype(;algorithm,sessionID)key(…)valGEN:a:algorithm->s:sessionID->(;a,s)keyvalLEAK:a:algorithm->s:sessionID{Weak(a)orCorrupt(s)}->(;a,s)key->bytesvalCOERCE:a:algorithm->s:sessionID{Weak(a)orCorrupt(s)}->bytes->(;a,s)key
Thetypeofthekeygeneratedforthisalgorithmusedonlyforthissession
Type-BasedStateMachineVerificaAon
DHGroup
DH
CRE
PRF
RSA
Cert
Sig
SessionDB
StAE
LHAE
Enc
MAC
Record
Dispatch
TCP
UntypedAdversary
Encode
LHAEPlain
StPlain
TLSFragment
AlertDatastream
Handshake(andCCS)
TLSInfoTLSConstants
Handshake/CCS
TLSRecord
AppData
Base Bytes
UntypedAPIAdversary
RPC
RPCPlainApplicaAon
TLSAPI
AlertProtocol
AppDataProtocol
Nonce
TLS
CoreCrypto
RSAKey
Auth
AuthPlain
Extensions
1
2
3 4
5
67
Range
8
9Error
ModularArchitectureformiTLS
Epochs:RefreshingKeys
• Exampleinvariants– ApplicaAondataisonlysentoracceptedinOpenstate– AlertsreceivedinOpenstateareauthenAc
• FragmentaAonhandling– Integrityissues(OpenSSLClientHellobug;AlertaXack)
TCP FirstHandshake Data Rehandshake Data Alert
Epoch0 Epoch1 Epoch2
Init Handshaking Open Close
AnaXackonAlerts
Client Attacker Server
Alert Fragment
[a0]
Handshake Handshake
Data Data Genuine alert [c0;c1] [a0;c0]
TCP FirstHandshake Data Alert
HandshakeandapplicaAondataareagreedupon.Whataboutalerts?
TypecheckingepochtransiAons
type(;e:epoch)state={handshake:(;e)Handshake.stateapplication:(;e)Application.statealert:(;e)Alert.state}
matchrecvwith|CCS(e’)->state={
handshake=Handshake.moveEpoche’application=Application.moveEpoche’alert=state.alert//Willnottypecheck}
Handshaking Open
TheTLSAPIHowapplica
TheAPIProblem
• WhatapplicaAonswant:socketreplacement– connect(),listen(),accept(),read(),write(),close()
• Whatwecanprove:
APIExample:SSL_read
• Returnvalue0:ReadoperaAonwasnotsuccessful.Thereasonmayeitherbe:– acleanshutdownduetoaclose_no
TheTripleHandshakeaXack
UserAuthenAcaAonoverTLS
• CommonPaXern– Outer:server-authenAcatedTLS– Inner:userauthenAcaAonprotocol
• Manyexamples– SASL,GSSAPI,PEAP,…– RenegoAaAonwithclientcerAficate
• Commonconcerns– Howtobindinnerauthen
APIExample:RenegoAaAon• “IfpeerrequestsarenegoAaAon,itwillbeperformed
transparentlyduringtheSSL_read()operaAon.”
• “AsatanyAmeare-negoAaAonispossible,acalltoSSL_write()canalsocausereadoperaAons!”
OpenSSL Manual
Bycomparison,inmiTLS:• ApplicaAondataindexedbyepoch
– Nosecuritycontextconfusion• Awritecanneverread
– NobufferingofapplicaAondata;havetoreadoenenough
• PMS:randomlychosenbyclient;RSA-encrypted• MS=PRF(PMS,ClientNonce,ServerNonce)
Background:TLSRSAHandshake
Client Server
client nonce, supported ciphers, extensions
server nonce, certificate, cipher, ses
sion
key exchange, change cipher, finished (verify_data)
change cipher, finished (verify_data)
TripleHandshakeAXack:(Phase1of3)
• IntheRSAhandshake,McanensurethatthemastersecretsonbothconnecAonsisthesame– Mre-encryptsC’spremastersecretunderS’spublickey– Usessameclientandserverrandomsonbothhandshakes
• McanalsodothiswithDHEhandshakes– Itchoosesa“bad”
Diffie-Hellmangroup
• Impact:ThemastersecretisnotagoodchannelidenAfier• Breaks:CompoundauthenAcaAon(reenables2002aXack)
Detailedmessagetraces:hXps://mitls.org/pages/aXacks/3SHAKE
TripleHandshakeAXack:(Pahse2of3)
• IfCresumesitssessiononanewconnecAon,McanforwardtheabbreviatedhandshaketoS– Worksbecausemastersecrets,
ciphersuites,sessionIDthesame– BothnewconnecAonswill
havethesamehandshakelogandsameverify_data
– OnbothconnecAons,sametls-unique=server_verify_data
• Impact:tls-uniqueisnotagoodidenAfieraerresumpAon• Breaks:ChannelBindinginSASL(SCRAM,GS2)
TripleHandshakeAXack:(Phase3of3)
• IfCrenegoAateswithclientcerAficate;McanforwardtherenegoAaAonhandshaketoS– WorksbecauserenegoAaAon
indicaAonisthesameRI=client_verify_data+server_verify_data
• Impact:RenegoAaAonIndicaAonisnotagoodchannelidenAfieraersessionresumpAon
• Breaks:RenegoAaAonIndicaAon(reenablesRex’saXack)
Countermeasures
• ForrenegoAaAon,implementaAoncheckswillbeenough– AlwaysvalidateservercerAficateduringrenegoAaAon– ManyTLSclientssAllneedtodothis
• Fortls-unique,compoundauth,noeasyfixes– Don’trelyontls-uniqueaerresumpAon– EnsurethatclientsonlypresentusercredenAalstotrustedservers
• Rootproblem:MastersecretsgeneratedindifferentTLSsecuritycontextscanbethesame– E.g.mastersecretdoesnotdependonservercerAficate
IfwemakethemastersecretagoodsessionidenAfier,tls-uniqueandrenegoAaAonindicaAonwillbefixedforfree!
Fix:ExtendedMasterSecret
• Computeasessionhashforfullhandshakessession_hash = Hash(handshake_messages)– AllmessagesuptoandincludingClientKeyExchange
(sincemaster_secretwillbeneededinSSL3.0CerAficateVerify)
• AddsessionhashtomastersecretderivaAon:master_secret = PRF(pre_master_secret, "extended master secret”, session_hash) [0..47]; • RFC7627:TLSSessionHashandExtendedMasterSecret
Extension
WhyTripleHandshakeWasn’tDiscoveredEarlier
• Giesenetal.,CCS’13OntheSecurityofTLSRenegoAaAon– Doesn’tmodelresumpAon
• Krawczyketal.,CRYPTO’13.OntheSecurityoftheTLSProtocol:ASystemaAcAnalysis– Doesn’tmodelresumpAonorrenegoAaAon
• Bhargavanetal.,IEEES&P’13ImplemenAngTLSwithVerifiedCryptographicSecurity– ModelsresumpAonandrenegoAaAon– AXackfallsoutsidethescopeoftheauthenAcaAonguaranteesfor
resumpAon
• Bhargavanetal.,CRYPTO’14ProvingtheTLSHandshakeSecure(asitis)– DiscussionoftheaXack;noformalproofofthefix
ExpectedsecurityfromtunneledTLSsessions
• InbareTLS,eachsessionisactuallyindependent• YetrenegoAaAonistunneled
– NoforwardingofupcomingaXackerdata– NoblessingofpreviousaXackerdata(!)[Ray’09]– FixedbyrenegoAaAonindicaAonextension
• ResumpAonoveranewTCPconnecAon– Nobindingtotheoriginalsessioncontext
…
…
TakingSideChannelsintoAccount
ConfidenAalitywithTLS
• ExpectedconfidenAality– Emailcontent– Usernameandpassword(idenAty)
IdenAfyingWebUsers
• Eachprofilepicturehasadifferentsize
• TLSdoesnotprotectmessagelength
• TheaXackerlearnstheusernamePrivate
Public
2
1
n=931Googleusers m/n–idenAfiability
m Gmailprofilepicture Gmail+XRef
1 292(31.36%) 789(84.75%)
2 232(24.92%) 112(12.03%)
3 180(19.33%) 30(3.22%)
4-6 227(24.39%) –
Searchingforacountermeasure
“[Padding]LengthslongerthannecessarymightbedesirabletofrustrateaMacksonaprotocolthatarebasedonanalysisofthelengthsofexchangedmessages”
MAC
fragment
fragment
padMACfragment
encryptedrecord
• Whynotrandompadding?• NoprotecAonagainstrepeatedsampling
– InpracAce,shortestmessageleakslength
Searchingforacountermeasure
“[Padding]LengthslongerthannecessarymightbedesirabletofrustrateaMacksonaprotocolthatarebasedonanalysisofthelengthsofexchangedmessages”
MAC
fragment
fragment
padMACfragment
encryptedrecord
Rangeis(1,1000)
Length-Hiding:fromCryptotoAPI
valENC:key->r:range->p:(;r)plain->c:cipher{InRange(r,c)}
LH-AE
valsplitRange:r:range->(r0:range*r1:range){r=Sum(r0,r1)/\Frag(r0)}
valsplit:r0:range->r1:range->p:(;Sum(r0,r1))plain->(p0:(;r0)plain*p1:(;r1)plain)
FragmentaAonandpadding
valwrite:c:cn->r:range->p:(;r)plain->(;c,p)ioresult_o
ToplevelAPI
FlexTLSRapidprototypingofTLSscenarios
GoalsandMoAvaAon
• RapidprototypingofTLSscenarios• Arbitraryreordering,fragmentaAonandtamperingofprotocol
messages• High-levelmessagingAPI,withsensibledefaultvalues• EasymanagementofconcurrentsessionsandconnecAons• QuickextensionstomiTLS;incrementalverificaAon• GreatertoolimpactandadopAon
Example–EarlyCCSaXackClient
C
Attacker
M
Server
S
ClientHello
ServerHello
CCS
CCS
Secrets:msweak, keysweak
Secrets:msweak, keysweak
CertificateCertificate (SNMC=0)
ServerHelloDoneServerHelloDone (SNMC=1)
Secrets:msstrong, keysweak
Secrets:msweak, keysweak
ClientKeyExchange ClientKeyExchange (SNMS=0)
Secrets:msstrong, keysweak
CCS
ClientFinished (SNCM=0) ClientFinished (SNMS=1)
CCSCCS (SNMC=2)
ServerFinished (SNSM=0)ServerFinished (SNMC=0)
Data (SNCM=n) Data (SNMS=n+1)
Data (SNSM=n)Data (SNMC=n)
Example–TLS1.3Client
C
Server
S
ClientHello
ClientKeyShare
ServerHello
ServerKeyShare
CCS
Certificate
CertificateVerify
ServerFinished
CCS
ClientFinished
DataData
FlexTLSarchitecture
EncMAC
TCP
TLSFragment
HandshakeMessages
TLSConstants
Handshake
TLS Record
PlatformBytesCoreCrypto
Extensions
Alert
miTLS SubsetFlexTLS
Connection
Constants
Base
State
Types Secrets
Record
Alert
CCS
AppData
Handshake
ClientHello
CertificateVerify
ServerHello
Finished
…CertSig
FlexTLSongoingandfuturework
• SystemaActesAngofexisAngimplementaAonstatemachines– AutomaAcgeneraAonofdeviaAngscenarios
• EarlycontribuAontotheIETFTLSWG– TLS1.3prototypeuncoveredparsingissuesandpotenAalsecurityproblems
– Incontrastwithtypicalresearchthatfocuseseffortsonestablishedstandards
• Furtherideas– UnittesAng– ImplementaAonfingerprinAng– AutomaAcaXackreconstrucAonfromProVerifcounterexamples– IncrementalverificaAonofnewprotocolfeaturesandversions
Conclusion
What’snext?
• Supportmoreciphersuites(ECDHE)andversions(TLS1.3)
• Verifylinearusageofstates
• RelaxcryptoassumpAons
• Reducetrustedcodebase
• Accountforsidechannels(e.g.Aming)
Discussion
• miTLS:averifiedreferenceimplementaAonofTLS– hXp://www.mitls.org– 7Klinesofcode;3Klinesoftypedinterfaces– VerifiedunderprecisecryptographicassumpAons
• CodedesignedanddevelopedforverificaAon– HowtosupportexisAngcode,“asprogrammerwouldwriteit”?
• AdopAon:drop-in.NETstreamreplacement– SAllreportsonlyfromenthusiasts– LackofengineeringsupportinarAfactandverificaAontools– VerificaAon“greenlight”slowsdownnewfeaturedevelopment