DIMACS workshop May 5 6 2005 Formal Tools

DIMACS workshop, May 5— 6 2005 Formal Tools for Web Services Security Cédric Fournet Microsoft Research, Cambridge joint work with Karthik Bhargavan, Andy Gordon, Greg O’Shea, Riccardo Pucella, Ricardo Corin MSRC Samoa: Details, papers, tools, pointers at http: //Securing. WS

Our starting point (2003) Two parallel trends over past five years: n Rapid invention and deployment of XML-based crypto protocols for securing web services n n Flexible message formats for interop Enables home-grown protocols New crypto protocols are often wrong, XML or not Sustained and successful effort to develop formalisms and tools to verify crypto protocols n n (Dolev&Yao, BAN, ) FDR, Athena, Isabelle, Pro. Verif, … At MSRC: spi, sjoin, Cryptyc, applied pi calculus, … Timely opportunity to develop tools for validating standards-based XML crypto protocols

Web Services Security n n SOAP level security aims to provide end-to-end, compositional application-level security, independently of transport protocol Fresh standards: n n Security Roadmap WS-Security, May 2004 (Draft: Apr 2002) WS-Trust, WS-Secure. Conversation, WS-Security. Policy, … A grammar for SOAP-based security protocols n n n Automated processing of security headers Informal semantics except for XML syntax Security tokens = wire format for claims and evidence n Keys, certificates, x 509 signatures, Kerberos tickets, …

Securing SOAP Messages Username. Token assumes both parties know Alice’s secret password p

Attacks on SOAP security n Web services vulnerable to same sorts of attacks as conventional websites n n Buffer overruns, denial of service, SQL injection, etc New concerns: flexible, XML-based protocols n n Web services developers can design and deploy their own application-specific security protocols XML message format open to rewriting attacks n n Much like classic active attackers (Needham-Schroeder ’ 78) Opponent can redirect, replay, modify, impersonate New: message processing is driven by a flexible, semi-structured message format Flexibility is usually bad news for security n We have found a range of problems in specs & code, thus motivating our research on theory and tools

A Signed SOAP Message Before. . . Message to bank’s web service says: “Transfer $1000 to Bob, signed Alice”

and After an XML Rewriting Attack Charlie has intercepted and rewritten this message

The Samoa Project: Tools n If misconfigured or mis-implemented, WS-Security protocols vulnerable to XML rewriting attacks n Tula. Fale — shows the absence of such attacks given a description of the protocol n n n Policy generator/analyzer — produces Tula. Fale from declarative XML policy files that drive WSE 2. 0 n n n First analysis tool for XML-based crypto protocols Automatic analysis of hand-written models via applied pi calculus and Bruno Blanchet’s Pro. Verif tool Hence, can directly analyze WSE 2. 0 configurations First source-based formal verification of interoperable implementations of crypto protocols Policy advisor — runs 35+ queries for security errors found in reviews of sample policies

Tula. Fale

Tula. Fale: a language for WS-Sec We designed Tula. Fale, a programming language to model WSE protocols and hand-wrote models for a series of WSE protocols (POPL’ 04, FMCO’ 03) Tula. Fale = pi + XML + predicates + assertions What Tula. Fale does Tula. Fale script predicate library WSE 1. 0 out of the box Tula. Fale C# code intermediate pi-calculus WSE 1. 0 CLR (IL) SOAP processing Pro. Verif Analyzer OK, or [B. Blanchet] No because…

Pi Calculus & Cryptography n Milner, Parrow, Walker (1989) n n Computation is name-passing between parallel processes on named channels. Each name has a mobile scope. Spi calculus: Pi + cryptographic operations (Abadi Gordon 1999) n n n Mobile scopes can represent local keys and fresh nonces Processes represent protocol configurations Contexts represent active attackers n Applied Pi: Pi + equational theory (Abadi Fournet 2001) n There is a generally-useful theory (equivalences, proofs) n Using tools such as Pro. Verif (Blanchet 2001—), we can mix manual and automated proofs of various security properties

Example: A Secure RPC n A typical system model: n n Threat model: an active attacker, in control of network, but knowing none of: n n A single certification authority (CA) issuing X. 509 public-key certificates for services, signed with the CA's private key. Two servers, each equipped with a public key certified by the CA and exporting an arbitrary number of web services Multiple clients, acting on behalf of human users The private key of the CA The private key of any public key certified by the CA The password of any user in the database Security goals: authentication of each message; and correlation of request and response

An intended run of the protocol Server(sx, cert, S) Client(kr, U) begin C 1 (U, S, id 1, t 1, b 1) is. Msg 1(-, U, S, id 1, t 1, b 1) end C 1 (U, S, id 1, t 1, b 1) begin C 2 (U, S, id 1, t 1, b 1, id 2, t 2, b 2) is. Msg 2(-, S, id 1, id 2, t 2, b 2) end C 2 (U, S, id 1, t 1, b 1, id 2, t 2, b 2) Msg 1 includes signature of S, id 1, t 1, b 1 under key derived from username token for U Msg 2 includes signature of id 1, id 2, t 2, b 2 under public key of S

pi+XML+predicates+assertions Tula. Fale predicates defined by Horn clauses with message patterns For example, this predicate is used in two ways, to construct and parse Message 1 Tula. Fale messages are terms in a many-sorted algebra with sorts:

pi+XML+predicates+assertions Tula. Fale library includes predefined predicates for XML signatures and encryption For example, this predicate uses these predicates to check structure of Message 1

pi+XML+predicates+assertions The implicit attacker, running in parallel, can: n Send and receive on the soap channel n Generate arbitrarily many users and services n Initiate arbitrarily many sessions

pi+XML+predicates+assertions By sending a message on init, the attacker can pick any payload and destination Each begin-event marks the intent to send a message Messages are exchanged on a public SOAP channel Each end-event marks the intent to accept a message as valid

Some Tulafale queries We also run basic reachability queries (sanity checks) We verify two correspondence properties from end-events to begin-event with matching contents (including both messages for C 2)

Suppose a client does not sign the message identifier id 1. . . Opponent Client(kr, U) Server(sx, cert, S) begin C 1 (U, S, id 1, t 1, b 1) is. Msg 1(-, U, S, id 1, t 1, b 1) Copy end C 1 (U, S, id 1, t 1, b 1) id 1: =id 2, Replay is. Msg 1(-, U, S, id 2, t 1, b 1) end C 1 (U, S, id 2, t 1, b 1) Pair (id 1, t 1) uniquely identifies the message only if id 1 and t 1 are signed We found and fixed faults like this in preliminary WSE samples

What else might go wrong? Opponent Client(kr, U) is. Msg 1(-, U, S, id 1, t 1, b 1) Call 1 SOAP Fault Call 2, re -using id 1 Server(sx, cert, S) begin C 2 (U, S, id 1, t 1, b 1, id 2, t 2, b 2) is. Msg 2(-, S, id 1, id 2, t 2, b 2) is. Msg 1(-, U, S, id 1, t 1’, b 1’) is. Msg 2(-, S, id 1, id 2, t 2, b 2) end C 2 (U, S, id 1, t 1’, b 1’, id 2, t 2, b 2) If the client doesn’t generate fresh id 1’s, then message correlation (C 2) fails; the tool easily finds this bug

Secure Conversations

A Tula. Fale Summer Case Study n WS-Security provides basic mechanisms to secure SOAP traffic, one message at a time n n If a SOAP interaction consists of multiple, related messages, WS-Security alone may be inefficient, and does not secure session integrity n n Signing and encryption keys derived from long-lived secrets like passwords or private keys Standard idea: establish short-lived session key Recent specs describe this idea at the SOAP-level n n WS-Secure. Conversation defines security contexts, used to secure sessions between two parties WS-Trust defines how security contexts are issued and obtained

A Typical System 1. RST STS Trust 2. RSTR SCT Client SCs SC Secure Conv 3. “Session Exchanges” … Service STS = Security Token Server SC = Security Context RST = Request Security Token SCT = SC Token RSTR = RST Response

Open-Ended Conversations begin Cn n Service Client get SC end Cn begin C’n end C’n for n ¸ 0 n We prove authentication for whole sessions We rely on some combination of manual and automated proofs

Discussion n A first formal analysis of WS-Trust and WS-Secure. Conversation n As is common, these specs: n n n XML syntax and automation very effective, against a demanding, realistic attacker model Approx 1000 lines of script – too large for manual proofs focus on message formats for interoperability are non-committal regarding security, for example, no clear spec of contents of SCs By making modes, data, and goals explicit, we found design and implementation bugs

Policy-Based Security

Security Policies n Clients, services use XML files to pick security mechanisms n Located in same IIS virtual directory n Describe protocols to use for different services n Simple declarative description of deployed protocols n n n No need to look at messy C# code X 509 v 3 We analyze policy files collected from client and servers S Easy to get them wrong Body() n Many policies are insecure n Combination of policies may have unexpected effects Username. Token U Body() Header("To") Header("Message. Id”)

Modelling Security Policies In WSE 2. 0, WS-Security. Policy files drive security; hence, we can generate Tula. Fale directly from implementation files (CCS’ 04) spec L of a secure link What our tools do Generator C(-) Analyzer S(-, -) WSE 2. 0 out of the box C# code policy config C(L) WSE 2. 0 CLR (IL) SOAP processing Static warnings predicate library Tula. Fale script S(C(L), L) Tula. Fale Pro. Verif (pi calculus) OK, or No because…

Security for Any Client Policy? n Theorem: If a service uses a link-generated policy, then irrespective of the client policies, the resulting configuration preserves request authentication and response secrecy n Hence, naïve clients cannot break service authentication n Proof: n n Combination of automated proofs and manual reasoning Hint: Even the weakest send policy preserves secrecy of passwords and signing keys

WSE 2 Policy Advisor (demo)

Summary n Web services security specs encourage extreme flexibility n n We bridge the gap between theoretical pi threat model and XML as used in WS security protocols n n Put effort into real samples & implementations, found bugs Obtained theorems about wire-level protocols Exploited automation for authentication & secrecy properties We develop tools for the automated analysis of security for deployed systems based on crypto protocols n n n Message formats, composable protocols, configurations Specs and implementations are only just emerging Attacks and proofs are subtle: tool support needed Proving protocols secure in isolation is not enough Our tools find attacks, verify configs, generate safe configs Good place to develop formal tools, get positive results n Standard message formats, composition, wide applicability Details, papers, tools, pointers at http: //Securing. WS