DIMACS workshop, May 5—6 2005 Formal Tools for Web Services Security

DIMACS workshop, May 5—6 2005

Formal Tools for Web Services Security

Cédric FournetMicrosoft 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:

Rapid invention and deployment of XML-basedcrypto protocols for securing web services

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

(Dolev&Yao, BAN,) FDR, Athena, Isabelle, ProVerif, …

At MSRC: spi, sjoin, Cryptyc, applied pi calculus, …

Timely opportunity to develop tools for validating standards-based XML crypto protocols

Web Services Security SOAP level security aims to provide end-to-

end, compositional application-level security, independently of transport protocol

Fresh standards: Security Roadmap WS-Security, May 2004 (Draft: Apr 2002) WS-Trust, WS-SecureConversation,

WS-SecurityPolicy,…

A grammar for SOAP-based security protocols Automated processing of security headers Informal semantics except for XML syntax Security tokens = wire format for claims and

evidence Keys, certificates, x509 signatures, Kerberos tickets,…

<Envelope> <Header> <Security> <UsernameToken Id=1> <Username>“Alice" <Nonce>"mTbzQM84RkFqza+lIes/xw==" <Created>"2004-09-01T13:31:50Z" <Signature> <SignedInfo> <SignatureMethod Algorithm=hmac-sha1> <Reference URI=#2> <DigestValue>"U9sBHidIkVvKA4vZo0gGKxMhA1g=“ <SignatureValue>"8/ohMBZ5JwzYyu+POU/v879R01s=" <KeyInfo> <SecurityTokenReference> <Reference URI=#1 ValueType=UsernameToken> <Body Id=2> <StockQuoteRequest> <symbols> <Symbol>"FABRIKAM" <Symbol>"CONTOSO"

Securing SOAP MessagesUsernameToken

assumes both parties know Alice’s secret

password p

Each DigestValue is a cryptographic

hash of the URI target

hmacsha1(key, SignedInfo) where

keypsha1(p+nonce+created)

<Security> header defined by OASIS

WS-Security 2004 includes identity tokens,

signatures, encrypted message

parts

Dozens of implementations,

including Microsoft Web

Services Enhancements

(WSE)

Attacks on SOAP security Web services vulnerable to same sorts of attacks

as conventional websites Buffer overruns, denial of service, SQL injection, etc

New concerns: flexible, XML-based protocols Web services developers can design and deploy

their own application-specific security protocols XML message format open to rewriting attacks

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 We have found a range of problems in specs & code,

thus motivating our research on theory and tools

A Signed SOAP Message Before...

<Envelope> <Header> <Security> <UsernameToken Id=2> <Username>Alice</> <Nonce>cGxr8w2AnBUzuhLzDYDoVw==</> <Created>2003-02-04T16:49:45Z</> <Signature> <SignedInfo> <Reference URI= #1><DigestValue>Ego0...</> <SignatureValue>vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</> <KeyInfo> <SecurityTokenReference><Reference URI=#2/> <Body Id=1> <TransferFunds> <beneficiary>Bob</> <amount>1000</>

Message to bank’s web service says: “Transfer $1000 to Bob, signed

Alice”

Bank can verify the signature has been computed using key derived from Alice’s

secret password

and After an XML Rewriting Attack

<Envelope> <Header> <Security> <UsernameToken Id=2> <Username>Alice</> <Nonce>cGxr8w2AnBUzuhLzDYDoVw==</> <Created>2003-02-04T16:49:45Z</> <Signature> <SignedInfo> <Reference URI= #1><DigestValue>Ego0...</> <SignatureValue>vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</> <KeyInfo> <SecurityTokenReference><Reference URI=#2/> <BogusHeader> <Body Id=1> <TransferFunds> <beneficiary>Bob</> <amount>1000</> <Body> <TransferFunds> <beneficiary>Charlie</> <amount>5000</>

Although Alice’s password has not been broken, the message now reads “Transfer

$5000 to Charlie, signed Alice”

Charlie has intercepted and rewritten this

message

The indirect signature of the body, now hidden in BogusHeader, may

still appear valid

The Samoa Project: Tools If misconfigured or mis-implemented, WS-Security

protocols vulnerable to XML rewriting attacks

TulaFale — shows the absence of such attacksgiven a description of the protocol

First analysis tool for XML-based crypto protocols Automatic analysis of hand-written models via

applied pi calculus and Bruno Blanchet’s ProVerif tool

Policy generator/analyzer — produces TulaFalefrom declarative XML policy files that drive WSE 2.0

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 securityerrors found in reviews of sample policies

TulaFale

TulaFale: a language for WS-Sec

OK, orNo because…

WSE 1.0 out of the box

What TulaFale does

CLR(IL)

SOAP processin

g

WSE 1.0ProVerif Analyzer

[B. Blanchet]

TulaFaleC# code

TulaFalescript

predicatelibrary

intermediate pi-calculus

We designed TulaFale, a programming

language to model WSE protocols and hand-wrote models for a

series of WSE protocols(POPL’04, FMCO’03)

TulaFale = pi + XML + predicates + assertions

Pi Calculus & Cryptography Milner, Parrow, Walker (1989)

Computation is name-passingbetween parallel processes onnamed channels. Each namehas a mobile scope.

Spi calculus: Pi + cryptographicoperations (Abadi Gordon 1999)

Mobile scopes can representlocal keys and fresh nonces

Processes represent protocol configurations Contexts represent active attackers

Applied Pi: Pi + equational theory (Abadi Fournet 2001) There is a generally-useful theory (equivalences, proofs) Using tools such as ProVerif (Blanchet 2001—), we can

mix manual and automated proofs of various security properties

Example: A Secure RPC A typical system model:

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

Threat model: an active attacker, in control of network, but knowing none of:

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

Client(kr,U) Server(sx,cert,S)

isMsg1(-,U,S,id1,t1,b1)

isMsg2(-,S,id1,id2,t2,b2)

begin C1 (U,S,id1,t1,b1)

end C1 (U,S,id1,t1,b1)

begin C2 (U,S,id1,t1,b1,id2,t2,b2)

end C2 (U,S,id1,t1,b1,id2,t2,b2)

An intended run of the protocol

Msg 1 includes signature of S,id1,t1,b1 under key derived from username

token for U

Msg 2 includes signature of

id1,id2,t2,b2 under public key of S

pi+XML+predicates+assertions

For example, this predicate is used

in two ways, to construct and parse Message 1

TulaFale messages are terms in a many-sorted algebra with

sorts:

TulaFale predicates defined by Horn

clauses with message patterns


TulaFale library includes

predefined predicates for XML

signatures and encryption

For example, this predicate uses these predicates to check

structure of Message 1


The implicit attacker, running in parallel, can: Send and receive on the soap channel Generate arbitrarily many users and services Initiate arbitrarily many sessions


By sending a message on init, the attacker can

pick any payload and destination

Each end-event marksthe intent to accept a message as valid

Each begin-event marksthe intent to send a message

Messages are exchanged on a public SOAP channel

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 C2)

OpponentClient(kr,U) Server(sx,cert,S)

isMsg1(-,U,S, id1,t1,b1)

Suppose a client does not sign the message identifier id1...

begin C1 (U,S,id1,t1,b1)


id1:=id2, Replay isMsg1(-,U,S

, id2,t1,b1)


Copy

Pair (id1,t1) uniquely identifies the message only if id1 and t1 are signed

We found and fixed faults like this in preliminary WSE samples

OpponentClient(kr,U) Server(sx,cert,S)

isMsg2(-,S,id1,

id2,t2,b2)

begin C2 (U,S,id1,t1,b1,id2,t2,b2)

end C2 (U,S,id1,t1’,b1’,id2,t2,b2)

If the client doesn’t generate fresh id1’s, then message correlation (C2) fails; the tool easily finds this bug

isMsg1(-,U,S, id1,t1,b1)

isMsg1(-,U,S, id1,t1’,b1’)

isMsg2(-,S,id1,

id2,t2,b2)

SOAP Fault

Call 1

Call 2, re-using

id1

What else might go wrong?

Secure Conversations

A TulaFale Summer Case Study WS-Security provides basic mechanisms to

secure SOAP traffic, one message at a time Signing and encryption keys derived from long-lived

secrets like passwords or private keys

If a SOAP interaction consists of multiple, related messages, WS-Security alone may be inefficient, and does not secure session integrity

Standard idea: establish short-lived session key

Recent specs describe this idea at the SOAP-level

WS-SecureConversation defines security contexts, used to secure sessions between two parties

WS-Trust defines how security contexts are issued and obtained

A Typical System

Client

STS

Service

1. RST

2. RSTR

3. “Session Exchanges”

SCsSCT

…

SC

Trust

SecureConv

STS = Security Token Server

RST = Request Security Token

RSTR = RST Response

SC = Security Context

SCT = SC Token

Open-Ended Conversations

Client Service

begin Cn

end Cn

begin C’n

end C’n

getSC get

SC

for n ¸ 0

We prove authentication forwhole sessions

We rely on some combination of manual and automated proofs

Discussion A first formal analysis of WS-Trust and

WS-SecureConversation XML syntax and automation very effective,

against a demanding, realistic attacker model Approx 1000 lines of script – too large for manual

proofs

As is common, these specs: 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 Clients, services use XML files to pick security

mechanisms Located in same IIS virtual directory Describe protocols to use for different services Simple declarative description of deployed

protocols No need to look at messy C# code We analyze policy files collected from client and

servers Easy to get them wrong

Many policies are insecure Combination of policies may have unexpected

effects

<Policy Id=“Msg1"> <All> <Confidentiality> <TokenInfo> <SecurityToken> <TokenType>X509v3</> <Claims><SubjectName>S</></> <MessageParts>Body()</> <Integrity> <TokenInfo> <SecurityToken> <TokenType>UsernameToken</> <Claims><SubjectName>U</></> <MessageParts>Body() Header("To") Header("MessageId”)</>

Modelling Security Policies

OK, orNo because…

Static warning

s

WSE 2.0 out of the box

What our tools do

CLR(IL)

SOAP processin

g

ProVerif(pi calculus)

TulaFale

C# code TulaFale script S(C(L),L)

predicatelibrary

Analyzer S(-,-)

In WSE 2.0, WS-SecurityPolicy files drive security; hence, we can

generate TulaFale directly from implementation files

(CCS’04)Generator C(-)

policy configC(L)

spec L of asecure link

WSE 2.0

Security for Any Client Policy? Theorem: If a service uses a link-generated policy, then

irrespective of the client policies, the resulting configuration preserves request authentication and response secrecy

Hence, naïve clients cannot break service authentication

Proof: Combination of automated proofs and manual reasoning Hint: Even the weakest send policy preserves

secrecy of passwords and signing keys

WSE2 Policy Advisor(demo)

Summary Web services security specs encourage extreme

flexibility Message formats, composable protocols, configurations Specs and implementations are only just emerging Attacks and proofs are subtle: tool support needed

We bridge the gap between theoretical pi threat modeland XML as used in WS security protocols

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 ofsecurity for deployed systems based on crypto protocols

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 Standard message formats, composition, wide applicabilityDetails, papers, tools, pointers at http://Securing.WS

DIMACS workshop, May 5—6 2005 Formal Tools for Web Services Security

Documents

Transcript of DIMACS workshop, May 5—6 2005 Formal Tools for Web Services Security