Security proofs in the symbolic model web services security, manual and automated proofs Karthikeyan Bhargavan INRIA karthikeyan.bhargavan@inria.fr http://prosecco.inria.fr/personal/karthik September 2013 Karthikeyan Bhargavan (INRIA) Security proofs in the symbolic model September 2013 1 / 30
Recap: Applied Pi Calculus A language for specifying cryptographic protocols [Abadi, Fournet ’00] Builds on pi calculus [Milner ’92], spi calculus [Abadi, Gordon ’99] Protocol roles encoded as concurrent processes that communicate by sending messages over public and private channels Names represent channels, keys, nonces Equational theories on messages specify cryptographic functions Term rewriting systems are a way of specifying equational theories Convergent term rewriting systems provide algorithms for equality Structural congruence defines behaviorally identical processes Internal reduction enables interaction between protocol processes Labeled reduction enables interaction with the attacker environment Karthikeyan Bhargavan (INRIA) Security proofs in the symbolic model September 2013 2 / 30
Recap: Term Syntax N : an infinite (countable) set of names a , b , c , . . . X : an infinite (countable) set of variables x , y , z , . . . F : a finite signature of function symbols f , g , h , . . . Includes constructors and destructors F = F C [ F D Terms represent messages that may be sent between processes M , N , O , . . . ::= Terms a name x variable f ( M 1 , . . . , M n ) function application T ( Σ ) : terms constructed from the symbols in Σ Σ contains names, variables, and functions Karthikeyan Bhargavan (INRIA) Security proofs in the symbolic model September 2013 3 / 30
Recap: Process Syntax Processes : P , Q , R , . . . P , Q , R ::= Processes 0 null process new a . P fresh name generation in ( c , x ) . P message input (continue as P) out ( c , M ) . P message output (continue as P) if M = N then P else Q conditional P k Q parallel composition ! P replication Extended Processes : A , B , C , . . . A , B , C ::= Extended processes P process new a . A fresh name generation A k B parallel composition { M / x } active substitution Karthikeyan Bhargavan (INRIA) Security proofs in the symbolic model September 2013 4 / 30
Recap: Security Goals Notation: Structural congruence P ⌘ Q , A ⌘ B ⌧ ⌧ ∗ Internal reduction P ! Q , transitive closure P � ! Q ~ l l Labeled reduction A ! B , transitive closure A � ! B Frames � represent attacker knowledge � = new ~ a . � where � is a substitution of the form: � = { M 1 / x 1 , M 2 / x 2 , . . . , M n / x n } � ( A ) : the frame of A , replace every plain process P in A by 0 Example: � ( new a . ( P k { M / x } k Q )) ⌘ new a . { M / x } Deduction � ` M enables an attacker to derive terms from a frame Secrecy goals in terms of what the attacker can deduce ~ l a is secret in A if for all A � ! B , � ( B ) 6` a A syntactic notion of secrecy, weaker than indistinguishability and computational secrecy. Karthikeyan Bhargavan (INRIA) Security proofs in the symbolic model September 2013 5 / 30
Recap: Finding Invariants A method to prove syntactic secrecy Find an invariant on the shape of the extended process as it evolves ~ l For all B such that A � ! B , B must have the shape I Example: B ⌘ new ~ a . { senc ( M , a i ) / x } k P for some M , i , P such that M , P do not mention a i Show that the frame of this invariant establishes your secrecy goal The attacker cannot deduce a secret from the frame of I � ( I ) = new ~ a . { senc ( M , a i ) / x } The attacker cannot deduce the secrets a k or M from this frame Karthikeyan Bhargavan (INRIA) Security proofs in the symbolic model September 2013 6 / 30
Today Case study: Web Services Security Introduction and motivation Writing a WS-Security protocol in the applied pi calculus Proving its security by demonstrating invariants Towards automated proof of protocol models Deducibility constraint systems for bounded protocol sessions Decision procedure for secrecy Undecidability result for unbounded protocol sessions (Next lecture and later in the course: tackling undecidability) Karthikeyan Bhargavan (INRIA) Security proofs in the symbolic model September 2013 7 / 30
APIs for Cloud-based Web Services APIs Karthikeyan Bhargavan (INRIA) Security proofs in the symbolic model September 2013 8 / 30
APIs for Cloud-based Web Services APIs Karthikeyan Bhargavan (INRIA) Security proofs in the symbolic model September 2013 9 / 30
Web Services Security Specifications and Implementations • A series of new specifications seeks to standardize cryptographic mechanisms for use with web services – WS-Security: message signatures, encryption – WS-Trust: token issuance, key establishment – WS-SecureConversation: secure sessions – WS-SecurityPolicy: specifying policies • Web services developers can combine these mechanisms to build a custom security protocol – in Java: Apache WSS4J, IBM Websphere – in C#: Microsoft Windows Communication Foundation Web Services Enhancements
WS-Security • SOAP Envelope/Header/Security header includes: – Timestamp • To help prevent replay attacks – Tokens identifying principals and keys • Username token: name and password • X509: name and public-key • Others including Kerberos tickets, and session keys – Signatures • Syntax given by XML-DSIG standard • Bind together list of message elements, with key derived from a security token – Encrypted Keys • Syntax given by XML-ENC standard • Various message elements may be encrypted
Password-based Authentication C S : account C , HMAC-SHA1( pwd C , accoun t C ) S C : balance C • Assume C has a username “C” & password pwd C at S • Request Authentication At S , only accepts an account C after checking pwd C • C MACs account C using the shared password • S checks the MAC on symbol before responding (HMAC-SHA1 = Keyed Hash, Message Authentication Code)
Example 1: Password-based Auth UsernameToken assumes both ¡parties ¡know ¡adg’s ¡ <Envelope> secret password p <Header> <Security> <UsernameToken Id=1> <Username>“C" Each DigestValue <Nonce>"mTbzQM84RkFqza+lIes/xw==" <Created>"2004-09-01T13:31:50Z" is the sha1 hash of <Signature> the URI target <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> hmacsha1 ( key , SignedInfo ) where <BalanceRequest> key psha1 ( p + nonce + created ) <AccountNumber> accoun t C </>
Example 2: Signing Multiple Elements To prevent <Envelope> redirections, <Header> <Action Id=1> "http://stockservice.contoso.com/wse/samples/2003/06/StockQuoteRequest" need to sign To <MessageID Id=2> "uuid:abc4946b-112f-4a26-b923-4ffc948c15ef" <ReplyTo Id=3> <Address> "http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous" and Action <To Id=4> "http://localhost/UsernameSignCodeService/UsernameSigningService.asmx" <Security mustUnderstand="1"> <Timestamp Id=5> <Created> "2004-09-01T13:31:50Z" <Expires> "2004-09-01T13:32:50Z" To prevent replays, <UsernameToken Id=7> <Username> "adg" need to sign <Nonce> "mTbzQM84RkFqza+lIes/xw==" <Created> "2004-09-01T13:31:50Z" Timestamp and <Signature> MessageId <SignedInfo> <CanonicalizationMethod Algorithm=exc-c14n> <SignatureMethod Algorithm=hmac-sha1> <Reference URI=#1> ... <Reference URI=#2> ... <Reference URI=#3> ... <Reference URI=#4> ... <Reference URI=#5> ... <Reference URI=#6> ... Actually, to prevent various <SignatureValue> "8/ohMBZ5JwzYyu+POU/v879R01s=" XML ¡rewriting ¡attacks, ¡it’s ¡ <KeyInfo> <SecurityTokenReference> necessary to co-sign other <Reference URI=#7 ValueType=UsernameToken> <Body Id=6> message parts with the body <BalanceRequest> <AccountNumber> accoun t C </>
Example 3: X.509 Mutual Auth Two-step encryption Response signature includes request signature • Assume C and S have key-pairs: ( sk C , pk C ) and ( sk S , pk S ) (Assume they have exchanged X.509 public-key certificates) • Secrecy of messages – freshly encrypted under pk S and pk C • Request and Response Authentication • Request-Response Correlation – signature of request counter-signed in response
Example 3: Request Message (symbolic) A symbolic representation of an X.509 cert issued by “Root” ¡to ¡“C” Encrypting fresh symmetric ¡“key” ¡ ¡ Encrypting symbol under ¡“key” ¡ ¡
Attacks on WS-Security Protocols
Recommend
More recommend
