Links and Security Andy Gordon (TulaFale is joint work with Karthik Bhargavan, Cédric Fournet, and Riccardo Pucella) Microsoft Research Links Meeting, Edinburgh April 6, 2005
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Links and Security
Andy Gordon
(TulaFale is joint work with Karthik Bhargavan, Cédric Fournet, and Riccardo
Pucella)
Microsoft ResearchLinks Meeting, Edinburgh
April 6, 2005
2
Security and Web Languages Don’t focus just on web apps at the expense of
web services – latter increasingly important
Research languages (such as Jif, Flow Caml, KLAIM) are source of modestly sized security-related programming tasks
In particular, TulaFale exemplifies some common web services security protocols
Language-based security requires delicate tradeoffs
Many have arisen over the past decade I mention three a new design should address
3
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
By now, serious money in web services eBay, Yahoo, Google, MSN, FlickR, del.icio.us Amazon has >65k devs signed up
XMLXMLRequesReques
tt
Client
Server
XMLXMLResponsRespons
ee
4
<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> <TransferFunds> <recipient>"bob" <amount>"1000"
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
<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> <BogusHeader> <Body Id=2> <TransferFunds> <recipient>"bob" <amount>"1000" <Body> <TransferFunds> <recipient>“Phil" <amount>"5000"
The adversary has intercepted and
rewritten the message
Implementations of WS-Security may be vulnerable to a
range of XML rewriting attacks
The indirect signature of the body, now hidden in BogusHeader, may still
appear valid
Here, without cracking the password, an
adversary can alter the interpretation
of a signed message
One fix is to check for
duplicate Body elements
6
TulaFale : Tool for WS
OK, orNo because…
WSE 1.0 out of the box
What TulaFale does
CLR(IL)
SOAP processin
g
WSE 1.0ProVerifanalyzer
TulaFaleC# code
TulaFalescript
predicatelibrary
intermediate pi-calculus
In work published at FMCO’03 and POPL’04,
we designed and implemented TulaFale, and hand-wrote models
for series of WSE protocols
TulaFale = pi + XML + predicates + assertions
7
Describing Messages
For example, this predicate used in two different modalities to construct and parse
Message 1TulaFale messages
are terms in a many-sorted algebra with
sorts:
TulaFale predicates defined by Horn
clauses with message equalities
8
Deriving a Key
Set of symbolic crypto primitives (including
psha1) defined equationally
9
Checking a Message
TulaFale library includes
predefined predicates for XML
signatures and encryption
10
TulaFale: Pros and Cons Faithful to the XML wire
format, unlike most work on symbolic crypto which ignores the details
Embedding of symbolic crypto within XML allows specs more concise and rigorous than the official WS specs and standards
Automatic verification of secrecy and authentication via ProVerif
Simple, Iota-style type system for XML
Direct execution still ongoing
Would eliminate “semantic gap” between model and code
Bidirectional predicates overrated
Functional style would ease implementation with little loss of expressiveness
11
Three Delicate Tensions Between interoperability and security
Ex: WS policy language very flexible for interoperability, and yet incredibly easy to misconfigure
Want small easy-to-use set of “secure channel” abstractions, plus means for experts to customize
Between source and target semantics Ex: mismatch between Java & JVM led to holes Theoretically speaking, a failure of “full abstraction” Mismatches between Links and JS,JVM,SQL, anyone?
Between static and dynamic verification Ex: Cryptyc checks for security properties via a
dependent type and effect system, entirely statically Ex: Perl tags data from untrusted input channels as
“tainted”, and keep tag until explicitly endorsed Ex: Java has mixture – b/c verifier, stack inspection
The End
Related Documents
