C dric fournet http research microsoft com fournet
1 / 48

Cédric Fournet research.microsoft/~fournet - PowerPoint PPT Presentation

  • Uploaded on

Ecole JEUNES CHERCHEURS en PROGRAMMATION Juin 2006. Protocoles cryptographiques & pi calcul (1) Modélisation de protocoles en pi calcul (2) Application: Services web et sécurité. Cédric Fournet http://research.microsoft.com/~fournet. Web Services Security & Protocol Verification.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Cédric Fournet research.microsoft/~fournet' - ross-ross

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
C dric fournet http research microsoft com fournet


Juin 2006

Protocoles cryptographiques & pi calcul

(1) Modélisation de protocoles en pi calcul

(2) Application: Services web et sécurité

Cédric Fournethttp://research.microsoft.com/~fournet

Web services security protocol verification

Web Services Security& Protocol Verification

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

Web services and formal security
Web Services and Formal Security

Two parallel trends:

  • 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

What s a web service





What’s a Web Service?

  • “A web service is a web site intended for use by computer programs instead of human beings.” (Barclay et al)

  • So XML not HTML


  • Service messages in SOAP format:

    • Envelope/Header – addressing, security, and transactional headers

    • Envelope/Body – actual payload

  • Service metadata in WSDL format:

    • For each SOAP endpoint, list of operations

    • For each operation, request and response types


Standards specifications
Standards & Specifications

  • “XML Web Services” refers to SOAP stack of specifications:

    • SOAP – message format

      • Syntax of request, response, fault messages

    • WSDL – service description

      • Interface: function name, parameter and return types

    • UDDI – service discovery

      • Search for service by attributes (like Yellow Pages)

      • Not yet widely used in practice

    • BPEL4WS – service composition

      • Programming language for automating business processes, such as B2B order processing

      • Some sort of merger of IBM WSFL, Microsoft XLANG, and Sun WSCI … so quite complex

A sample soap request
A Sample SOAP Request

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"




<GetOrder xmlns="http://microsoft.com/petshop">





  • Says: “get me status of order 20”

A sample soap request1
A Sample SOAP Request





  • Says: “get me status of order 20”

  • XML not meant to be read by humans, so we’ll omit namespace info, and trailing brackets…

Another soap request
Another SOAP Request









  • Optional headers tell SOAP processorswhat to do with the envelope (automatically)

Web services what s new
Web Services: What’s New?

  • Though their core is roughly XML-encoded RPC – rather old! – what’s new about SOAP web services is the combination of:

    • Standards, Internet-scale, high-level tools

  • Signs of fervour,

    • Wide support, easy to deploy

    • OASIS and W3C

  • yet reasons for caution,

    • Cost of SOAP encoding?

    • Lack of SOAP security?

The 2002 security story
The 2002 Security Story

  • The 2002 best practice was to build secure web services using an SSL transport

  • SSL gives transport- not application-level security

    • Messages secured point-to-point not end-to-end

    • Messages cannot securely be filtered or routed

    • Messages not encrypted in files or databases

  • Party line (Web Services Security Roadmap) security within SOAP envelopes is better

Web services security1
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,…

Securing soap messages
Securing SOAP Messages

UsernameToken assumes both parties know Alice’s secret password p




<UsernameToken Id=1>






<SignatureMethod Algorithm=hmac-sha1>

<Reference URI=#2>





<Reference URI=#1 ValueType=UsernameToken>

<Body Id=2>





<Security> header defined by OASIS WS-Security 2004 includes identity tokens, signatures, encrypted message parts

Each DigestValue is a cryptographic hash of the URI target

Dozens of implementations, including Microsoft Web Services Enhancements (WSE)

hmacsha1(key, SignedInfo) where keypsha1(p+nonce+created)

Attacks on soap security
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 deploytheir 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 for security

    • We have found a range of problems in sample code,thus motivating our research on theory and tools

An xml rewriting attack

From: AliceTo: BookshopAction: “Buy Charlie’s book”

(signed by Alice)

Sent: Monday

From: AliceTo: BankAction: “Pay Charlie $20”

(signed by Alice)

Sent: Tuesday

From: AliceTo: BankAction: “Buy Charlie’s book”

(signed by Alice)

Sent: Wednesday

From: AliceTo: BookshopAction: “Buy Charlie’s book”

(signed by Alice)

An XML Rewriting Attack

Alter and replay envelopesto confuse participants

Alice’s laptop

Alice’s bookshop(Web Service)

Someoneon the net(Charlie?)

Another xml rewriting attack

From: AliceTo: Bookshop“Publish this paper” (encrypted for bookshop)

(signed by Alice)

From: CharlieTo: Bookshop“Publish this paper”

(encrypted for bookshop)

(signed by Charlie)

Another XML Rewriting Attack

Take credit for someone else’s data

Alice’s bookshop(Web Service)

Alice’s laptop

Someoneon the net(Charlie?)

A signed soap message before
A Signed SOAP Message Before...

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




<UsernameToken Id=2>






<Reference URI= #1><DigestValue>Ego0...</>



<SecurityTokenReference><Reference URI=#2/>

<Body Id=1>




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

And after an xml rewriting attack
and After an XML Rewriting Attack

Charlie has intercepted and rewritten this message




<UsernameToken Id=2>






<Reference URI= #1><DigestValue>Ego0...</>



<SecurityTokenReference><Reference URI=#2/>


<Body Id=1>








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

Although Alice’s password has not been broken, the message now reads “Transfer $5000 to Charlie, signed Alice”

A long history of attacks
A Long History of Attacks

We assume that an intruder can interpose a computer on all communication paths, and thus can alter or copy parts of messages, replay messages, or emit false material.While this may seem an extreme view, it is the only safe one when designing authentication protocols.

Needham and Schroeder CACM (1978)




1978: N&S propose authentication protocols for “large networks of computers”

1981: Denning and Sacco find attack found on N&S symmetric key protocol

1983: Dolev and Yao first formalize secrecy properties wrt N&S threat model, using formal algebra

1987: Burrows, Abadi, Needham invent authentication logic; neither sound nor complete, but useful

1994: Hickman (Netscape) invents SSL; holes in v2, but v3 fixes these, very widely deployed

1994: Ylonen invents SSH; holes in first versions, now very widely deployed

1995: Abadi, Anderson, Needham, et al propose various informal “robustness principles”

1995: Lowe finds insider attack on N&S asymmetric protocol; rejuvenates interest in FMs

circa 1999: Several FMs for “D&Y problem”: tradeoff between accuracy and approximation

circa 2004: Many FMs now developed; several deliver both accuracy and automation

The samoa project tools
The Samoa Project: Tools

  • If misconfigured or mis-implemented, WS-Securityprotocols vulnerable to XML rewriting attacks

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

    • An analysis tool for XML-based crypto protocols

    • Automatic analysis of hand-written models viaapplied 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

    • Source-based formal verification of deployedimplementations of crypto protocols

  • Policy advisor — runs 35+ queries for securityerrors found in reviews of sample policies

Tulafale a language for ws sec
TulaFale: a language for WS-Sec

TulaFale = pi + XML + predicates + assertions

We designed TulaFale, a programming language to model WSE protocols and hand-wrote models for a series of WSE protocols(POPL’04, FMCO’03)

What TulaFale does




WSE 1.0out of the box


C# code

intermediate pi-calculus

WSE 1.0



ProVerif Analyzer[B. Blanchet]

OK, orNo because…

SOAP processing

Example a secure rpc
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; but not confidentiality

An intended run of the protocol



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)

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

TulaFale predicates defined by Horn clauses with message patterns

For example, this predicate is usedin two ways, to construct and parse Message 1

TulaFale messages are terms in a many-sorted algebra with sorts:

Pi xml predicates assertions1

TulaFale 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 assertions2

By sending a message on init, the attacker can pick any payload and destination

Each begin-event marksthe intent to send a message

Messages are exchanged on a public SOAP channel

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

Pi xml predicates assertions3

The implicit attacker, running in parallel, can:

  • Send and receive on the soap channel

  • Generate arbitrarily many users and services

  • Initiate arbitrarily many sessions

Some tulafale queries
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)

Tulafale demo

TulaFale Demo

Automatic verification of following reachability and safety properties via TulaFale/ProVerif

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




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

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


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

id1:=id2, Replay

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

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

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

What else might go wrong?




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

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

Call 1



SOAP Fault

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

Call 2, re-using id1



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

What about insider attacks?

Opponent aka O



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

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

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





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

If one or more passwords are compromised, there is an insider attack on message correlation; more extensive changes to the script are needed to model this

A tulafale case study
A TulaFale 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
A Typical System


1. RST









3. “Session Exchanges”


STS = Security Token Server

RST = Request Security Token

RSTR = RST Response

SC = Security Context

SCT = SC Token

Open ended conversations

We prove authentication forwhole sessions

We rely on some combination of manual and automated proofs

Open-Ended Conversations







begin Cn

end Cn

begin C’n

end C’n

for n¸ 0


  • A formal analysis of WS-Trust andWS-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

Security policies
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">













<MessageParts>Body() Header("To") Header("MessageId”)</>

Analyzing policy configurations
Analyzing Policy Configurations

Web Server

User U


Web Service


Client App

U’s pwd

V’s pwd’



U’s pwd








User V


Web Service


Client App

V’s pwd








Automated tools for collecting, parsing policies from IIS Servers, Clients

Config = [Policy1, Policy2, Policy3, Policy4]

Modelling security policies
Modelling Security Policies

What our tools do

spec L of a

secure link

In WSE 2.0, WS-SecurityPolicy files drive security; hence, we can generate TulaFale directly from implementation files(CCS’04)

Generator C(-)

Analyzer S(-,-)

WSE 2.0out of the box

Static warnings

C# code

policy config



TulaFale script


WSE 2.0





(pi calculus)

SOAP processing

OK, orNo because…

Translating policies to predicates
Translating Policies to Predicates

<Policy Id="Msg1">













<MessageParts>Body() Header("To")



Encryption Requirement

Signature Requirement

predicate hasMsg1Policy(msg1:item,U:item,pwd:string,

S:item,skS:bytes,id1:string,req:item) :-

msg1 =












[<Body>b1</> <To>S</> MessageId>id1</>]).

Security for all generated configs
Security for All Generated Configs?

  • Theorem: All policy configurations generated from link specs enforce their security goals

    • For all link specifications L, S(C(L),L) provides request & response authentication, correlation, and secrecy.

    • Hence, at least generated configs can be safely deployed

  • Proof:

    • Non-obvious: there are infinitely-many link specs

    • Use combination of automated proofs and manual reasoning

    • Hint 1: Reduce to 4 base kinds of link-generated policies

    • Hint 2: Prove that configs with all links enabled is secure(programmed unfoldings in the pi calculus)

Security for any client policy
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 preservessecrecy of passwords and signing keys

Security in the field a policy advisor for wse
Security in the field:a Policy Advisor for WSE

  • Advisor guesses intended goals and runs queries that check for:

  • likely errors in configuration file settings

  • conformance to conservative policy schema

  • likely errors in (request,response,fault) mappings

  • likely errors in particular policies

WSE 2.0SP2 out of the box

Our plugin

WSE Policy



policy config



WSE 2.0





SOAP processing


  • 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 applicability

Details, papers, tools, pointers at http://Securing.WS

Related work
Related Work

  • Going in the opposite direction to our policy analyzer, several tools compile formal models to code:

    • Strand spaces: Perrig, Song, Phan (2001), Lukell et al (2003)

    • CAPSL: Muller and Millen (2001)

    • Spi calculus: Lashari (2002), Pozza, Sista, Durante (2004)

    • Apparently, the resulting code cannot yet interoperate with other implementations – an important future target

  • Other Dolev-Yao modelling of web services

    • Type-based analysis of pre-WS-Security web services using Cryptyc: Gordon and Pucella (2002)

    • Model-checking of some example WS-Security specs using FDR, uncovering similar attacks: Kleiner & Roscoe (2004)

  • Other formalizations of XML and web services specs

    • XPath, XSLT, XQuery: Wadler et al (since 1999)

    • WS-RM: Johnson, Langworthy, Lamport, Vogt (2004)