A Semantics for Web Services Security

Document Sample
A Semantics for Web Services Security Powered By Docstoc
					                      Cassis, March 8th 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:
      Rapid invention and deployment of XML-based
       crypto 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?
                          ―A web service is a web site
                           intended for use by computer
                           programs instead of human
                           beings.‖ (Barclay et al)
                          So XML not HTML         Client
   Service messages in SOAP format:
       Envelope/Header – addressing, security,   Response
        and transactional headers                             Server
       Envelope/Body – actual payload

   Service metadata in WSDL format:
       For each SOAP endpoint, list of operations
       For each operation, request and response types
   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 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

        Optional headers tell SOAP processors
         what to do with the envelope (automatically)
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,
   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
                                                        UsernameToken assumes
                  <Envelope>                             both parties know Alice’s
                      <Header>                              secret password p
                         <UsernameToken Id=1>
  <Security> header
   defined by OASIS        <Nonce>"mTbzQM84RkFqza+lIes/xw=="
 WS-Security 2004                                              Each DigestValue is a
                           <Created>"2004-09-01T13:31:50Z"      cryptographic hash of
    includes identity    <Signature>
  tokens, signatures,                                               the URI target
  encrypted message          <SignatureMethod Algorithm=hmac-sha1>
          parts              <Reference URI=#2>
      Dozens of              <SecurityTokenReference>
 implementations,             <Reference URI=#1 ValueType=UsernameToken>
including Microsoft <Body Id=2>
    Web Services       <StockQuoteRequest>               hmacsha1(key, SignedInfo)
   Enhancements          <symbols>                                   where
        (WSE)              <Symbol>"FABRIKAM"           keypsha1(p+nonce+created)
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 for security
        We have found a range of problems in sample code,
         thus motivating our research on theory and tools
           An XML Rewriting Attack
          Alter and replay envelopes
            to confuse participants                   Sent: Monday
                                                      From: Alice Sent: Tuesday
                                                      To: Bank     From: Alice
                                                  Sent: Wednesday  Charlie $20”
                                                      Action: “Pay To: Bank
          From: Alice                             From: Aliceby Alice)
                                                      (signed      Action: “Buy Charlie’s book”
          To: Bookshop                            To: Bookshop
                                                                   (signed by Alice)
          Action: “Buy Charlie’s book”            Action: “Buy Charlie’s book”
          (signed by Alice)                       (signed by Alice)

Alice’s laptop                                                                Alice’s bookshop
                                                                              (Web Service)

                                         on the net
     A Signed SOAP Message Before...
                                 Message to bank’s web
<Envelope>                    service says: ―Transfer $1000
                                  to Bob, signed Alice‖
      <UsernameToken Id=2>
        <Username>Alice</>                              Bank can verify the
        <Created>2003-02-04T16:49:45Z</>                signature has been
      <Signature>                                       computed using key
        <SignedInfo>                                    derived from Alice’s
          <Reference URI= #1><DigestValue>Ego0...</>
                                                          secret password
          <SecurityTokenReference><Reference URI=#2/>
  <Body Id=1>
     and After an XML Rewriting Attack
                          Charlie has intercepted and
<Envelope>                  rewritten this message
      <UsernameToken Id=2>
                                                 The indirect signature of the
        <Nonce>cGxr8w2AnBUzuhLzDYDoVw==</>           body, now hidden in
        <Created>2003-02-04T16:49:45Z</>          BogusHeader, may still
      <Signature>                                        appear valid
          <Reference URI= #1><DigestValue>Ego0...</>
          <SecurityTokenReference><Reference URI=#2/>
      <Body Id=1>
        <TransferFunds>                     Although Alice’s password
          <beneficiary>Bob</>               has not been broken, the
                                               message now reads
    <TransferFunds>                        ―Transfer $5000 to Charlie,
      <beneficiary>Charlie</>                     signed Alice‖
            A Long History of Attacks
                                               We assume that an intruder can interpose
                                               a computer on all communication paths,
      A                          B             and thus can alter or copy parts of
                                               messages, replay messages, or emit false
                                               While this may seem an extreme view, it
                                               is the only safe one when designing
                                               authentication protocols.
                   C                                      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
Pi Calculus & Cryptography
   Milner, Parrow, Walker (1989)
        Computation is name-passing
         between parallel processes on
         named channels. Each name
         has a mobile scope.
   Spi calculus: Pi + cryptographic
    operations (Abadi Gordon 1999)
        Mobile scopes can represent
         local 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 for various security properties
The Samoa Project, Briefly
   If misconfigured or mis-implemented, WS-Security
    protocols vulnerable to XML rewriting attacks

   TulaFale — shows the absence of such attacks
    given 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 TulaFale
    from 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 security
    errors found in reviews of sample policies
    TulaFale: a language for WS-Sec
 We designed TulaFale, a                TulaFale =
programming language to      pi + XML + predicates + assertions
model WSE protocols and
                                      What TulaFale does
hand-wrote models for a
 series of WSE protocols
                                   TulaFale       predicate
   (POPL’04, FMCO’03)
                                    script         library
   WSE 1.0 out of the box
         C# code

                                   intermediate pi-calculus

              WSE 1.0
       CLR                      ProVerif Analyzer    OK, or
                  SOAP            [B. Blanchet]
       (IL)                                       No because…
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
An intended run of the protocol

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

       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                        Msg 2 includes signature
  S,id1,t1,b1 under key derived                        of id1,id2,t2,b2 under
   from username token for U                               public key of S

         TulaFale predicates
       defined by Horn clauses      For example, this
        with message patterns       predicate is used
                                      in two ways,
                                    to construct and
                                    parse Message 1

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

                 TulaFale library
              includes predefined
               predicates for XML
                 signatures and

                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 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
TulaFale Demo
Automatic verification of following reachability and
safety properties via TulaFale/ProVerif
Suppose a client does not sign the message identifier id1...

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

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

                     isMsg1(-,U,S,     Copy
                                                         end C1 (U,S,id1,t1,b1)

                                  Replay        isMsg1(-,U,S,

                                                        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?

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

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

 Call 2,                   id1,t1’,b1’)
   id1                    isMsg2(-,S,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
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
     A Typical System
                           1. RST
                               2. RSTR
            Client                                               SCs
 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
 Client                Service
                                          We prove
                                           authentication for
           get                             whole sessions
begin Cn
                                 SC       We rely on some
                                           combination of manual
                       end Cn              and automated proofs
                       begin C’n

end C’n
           for n ¸ 0
   A first formal analysis of WS-Trust and
       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
    <Policy Id=―Msg1">
      Describe protocols to use for different services
      Simple declarative description of deployed protocols
             <SecurityToken>
              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
           <MessageParts>Body() Header("To") Header("MessageId‖)</>
       Analyzing Policy Configurations
                                               Web Server
                 User U
                                           Web Service
                  Client App                    S
          U’s pwd
            cert Security                   Security
                     Layer                    Layer
        Policy1.xml                                  Policy2.xml

                                                      U’s pwd
                                                      V’s pwd’
                 User V
                                            Regular     cert
                                           Web Service key
                   Client App                  T
           V’s pwd                          Security
             cert Security
                      Layer                          Policy3.xml

Automated tools for collecting, parsing policies from IIS Servers, Clients
             Config = [Policy1, Policy2, Policy3, Policy4]
    Modelling Security Policies
                                                          What our tools do
In WSE 2.0, WS-SecurityPolicy        spec L of a
files drive security; hence, we      secure link
can generate TulaFale directly
   from implementation files
            (CCS’04)              Generator C(-)
                                                     Analyzer S(-,-)
  WSE 2.0 out of the box                                              Static
              policy config            predicate          TulaFale script
C# code
                   C(L)                 library              S(C(L),L)

           WSE 2.0                             TulaFale
    CLR         SOAP                 ProVerif         OK, or
    (IL)      processing           (pi calculus)   No because…
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?
   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
Policy Advisor Demo
   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 model
    and 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 of
    security 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