verifying security protocol implementaons with refinement ......fosad 2016 summer school aug 29 –...
TRANSCRIPT
-
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