Web Services & Security
ir. Paul Brandt, TNO-ICT
Today, Friday January 13
Next week, Friday January 20
Web Services & Security
Web Services
What are Web Services?
Web pages for computers
Reality: heterogeneous systems,
platforms, data
Reality: Processes change, be agile to
cope
Application: provides service
Request-response
Lousely coupled
What's its Significance?
Application Integration
EAI, B2B, Automating Business Processes
Universal Application Connectivity
Universal Application
Connectivity
Easy to access remote resources
Expose business processes over the Web
Interface is standard, published,
discoverable, self-describing
What are the Security
Challenges?
Message oriented
Identities
Message oriented
Web services typically use multi-hop
communication paths
Transport level security (SSL, TLS, IPSEC,
...) only provides Point-2-Point (on-thewire) confidentiality
Messages are decrypted in the servers
(a.o. routing), violating confidentiality
Hence End-2-End, i.e. message based,
confidentiality required
Combined approach is possible
Identities
Web services transport potentially unkown
identies into my platform
Who are they?
Are they authorized?
Assett protection: What critical
information is leaving my platform?
Can it be proved they did these things?
XML-family
XML-family
XML basics
XML Objective
Structured, self describing interface...
... totally independent application,
protocol, vocabulary, operating system &
programming language
Grammar & syntax to build interface
Nothing to do with semantics!!
XML Characteristics
XML stores data within descriptive
element tags: <PartNo>542345</PartNo>
Character-oriented, not binary, hence
human-readable
Extensible Meta Language
Separates content from structure & form
All family members are specified in XML
itself
Example 1:
Simple XML (1/1)
Element: Data enclosed by
named tags:
<element>data</element>
Hierarchical: <Element> can
contain other <Element>’s
<Order>
<LineItem sku="82394" quantity="1">
<ProductName>Birdcage</ProductName>
<Model material="Iron" color="Blue" />
</LineItem>
<Amount Currency="USD">108.50</Amount>
<Customer id="customer" custNum="A2345">
<FirstName>Fred</FirstName>
Start-tag can contain attributes:
attributeName=value
Reserved attributeNames:
“id=” uniquely identifies
individual element
<MiddleInit>L</MiddleInit>
<LastName>Jones</LastName>
<CreditCard>
<CreditCardType>VISA</CreditCardType>
<CreditCardNumber>43343456343566</CreditCardNumber>
<CreditCardExpiration>10/08</CreditCardExpiration>
</CreditCard>
</Customer>
</Order>
Empty element:
no data, single <element/> tag
XML Schema
XML document can be validated against
schema, automatically
Schema defines hierarchical structure
Schema defines data types
Schema defines particular order of
elements
Schema provides for accurate &
consistent data
XML document = instance of defined XML
schema
<Order>
Example 2:
<LineItem sku="82394" quantity="1">
<ProductName>Birdcage</ProductName>
XML Schema (1/1)
<Model material="Iron" color="Blue" />
</LineItem>
<Amount Currency="USD">108.50</Amount>
<Customer id="customer" custNum="A2345">
<FirstName>Fred</FirstName>
<MiddleInit>L</MiddleInit>
<xsd:schema xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<LastName>Jones</LastName>
<CreditCard>
<xsd:element name="Order" type="order"/>
<CCType>VISA</CCType>
<CCNumber> . . </CCNumber>
<CCExpiration>10/08</CCExpiration>
<xsd:complexType name="order">
<xsd:element name="LineItem" type="lineItemType"/>
</CreditCard>
</Customer>
</Order>
<xsd:element name="Amount" type="amountType"/>
<xsd:element name="Customer" type="customerType"/>
</xsd:complexType>
<xsd:complexType name="lineItemType">
<xsd:element name="ProductName" type="xsd:string"/>
<xsd:element name="Model" type="modelType"/>
</xsd:complexType>
. . . etc., until all types correspond to simpleTypes
(integer, string, double, float, date and time)
</xsd:schema>
Namespaces
Problem
Solution: xmlns
Problem
Anyone can define element names
Hence, name collision and conflicts all
along
XML shall keep names separate and
distinct
<xsd:schema xmlns:xsd="http://www.w3.org/1999/XMLSchema">
Solution: xmlns
<xsd:element name="Order" type="order"/>
<xsd:complexType name="order">
XML namespace (1/1)
<xsd:element name="LineItem" type="lineItemType"/>
<xsd:element name="Amount" type="amountType"/>
<xsd:element name="Customer" type="customerType"/>
</xsd:complexType>
<xsd:complexType name="lineItemType">
Namespaces are uniform resource identifiers:
1. Define unique name
2. Prepend that to each & every element name
<xsd:element name="ProductName" type="xsd:string"/>
<xsd:element name="Model" type="modelType"/>
</xsd:complexType>
. . . etc., until all types correspond to simpleTypes
(integer,
string, double, float, date and time)
</xsd:schema>
xmlns:myns=“http://www.myorg.com/foo”
<myns:order>
My unique namespace
Abbreviated namespace:
prefix
Unique element name
Reserved namespace:
“namespace def coming up”
XML Landscape
XML standards belonging to operation
domain
XML standards belonging to XML Family
(Security)
XML standards belonging to XML Family
(general)
XML standards belonging
to operation domain
hrXML - XML for Human Resource
(employment agencies)
X4ML - XML for Merrill Lynch
HL-7v3: XML message format for Health
Care
....
really, really big landscape
XML standards belonging
to XML Family (Security)
 SOAP - Simple Object Access
Protocol
 XML-Signature
 XML-Encryption
 SAML - Security Assertion
Markup Language
 XACML - eXtensible Access
Control Markup Language
 XrML - eXtensible Rights ML
 XKMS - XML Key Management
Specification
 WS-Security
 WS-Policy
XML standards belonging
to XML Family (general)
WS-*: Web Service standards
WSDL - Web Services Description
Language
XSL(T) - eXtensible Stylesheet Language
(Transformations)
XPath
XML-Signature
XML-Signature
Objective
Integrity of resource
Identity of originator
Non-repudiation of event
Foundation from Digital Signature
Foundation from Digital
Signature
Greatly expands upon it:
Uses power and flexibility of XML ...
... as well as key Web technologies (such
as URLs) ...
to sign almost any type of resource:
to sign almost any type of
resource:
XML documents
Parts thereof
non-XML object such as an image
as long as it has an URL
XML-Signature structure
Core
A set of pointers (references) to things to
be signed
The actual signature
(Optional) The key (or a way to look up
the key) for verifying the signature
(Optional) An Object tag for
miscellaneous items not included in the
first three items
Example Sig1:
Highly Simplified XML Signature (1/1)
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
Reference(s)
to what is
being signed
<SignedInfo>
<Reference URI="http://www.foo.com/secureDocument.html" />
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo>... </KeyInfo>
actual signature
bits
</Signature>
information
about the key
3 Types of XML-Signature
Enveloping Signatures
Enveloped Signatures
Detached Signatures
Example Sig2:
Simplified Enveloping Signatures (1/4)
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<Reference URI="#111" />
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo>...</KeyInfo>
<Object>
<SignedItem id="111">Stuff to be signed</SignedItem>
</Object>
</Signature>
Example Sig2:
Simplified Enveloped Signatures (2/4)
<PurchaseOrder id="po1">
<SKU>125356</SKU>
<Quantity>17</Quantity>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<Reference URI="#po1" />
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo>...</KeyInfo>
</Signature>
</PurchaseOrder>
Example Sig2:
Detached Signatures (3/4)
internal resource
<PurchaseOrderDocument>
<PurchaseOrder id="po1">
<SKU>12366</SKU>
<Quantity>17</SKU>
</PurchaseOrder>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<Reference URI="#po1" />
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo>...</KeyInfo>
</Signature>
</PurchaseOrderDocument>
Example Sig2:
Detached Signatures (4/4)
external resource
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<Reference URI="http://www.foo.com/Lion.jpg" />
<Reference URI="http://www.foo.com/Secure.txt" />
<Reference URI="http://www.foo.com/Secure.xml" />
</SignedInfo>
<SignatureValue>...</SignatureValue>
<KeyInfo>...</KeyInfo>
</Signature>
The Bloody Details
Core element 1/4:
<SignedInfo>
1. Security model
2. Canonicalization (c14n)
3. Identify resource(s) to be signed
1. Security model
No new security technologies were
invented (Digital Signature)
But: Digital Signature == Integrity AND
Identity
Hence: Public keys (asymmetrical: RSA,
DSA) => integrity & identity
Keyed Hashed Authentication Code
(symmetrical: HMAC) => ONLY integrity,
NO identity
<SignatureMethod />
2. Canonicalization (c14n)
2.1. c14n normalizes the XML
2.2. c14n: What does it actually do?
2.1. c14n normalizes the
XML
regardless of inconsequential physical
differences in the XML ...
... two logically equivalent XML
documents ...
... will become physically, bit-to-bit
equivalent.

This is a critical requirement for digital
signatures to work.
2.2. c14n: What does it
actually do?
 The document is encoded in UTF-8.
 Line breaks are normalized to #xA on
input, before parsing.
 Attribute values are normalized, as if
by a validating processor.
 Character and parsed entity references
are replaced.
 CDATA sections are replaced with their
character content.
 The XML declaration and Document
Type Definition (DTD) are removed.
 Empty elements are converted to
start-end tag pairs.
 Whitespace outside the document
element and within start and end tags
is normalized.
 All whitespace in character content is
retained (excluding characters
removed during linefeed
normalization).
 Attribute value delimiters are set to
quotation marks (double quotes).
 Special characters in attribute values
and character content are replaced by
character references.
 Superfluous namespace declarations
are removed from each element.
 Default attributes are added to each
element.
 Lexicographic order is imposed on the
namespace declarations and
attributes of each element.
3. Identify resource(s) to
be signed
Reference the resource(s) (enveloped/ing/detached) using URI
Calculate (& include) Digest of referenced
resource
(not before Transforms have been
applied, such as c14n, XSLT, XPath)
<Reference URI ? > +
<Reference URI ? > +
<Transforms> ?
<DigestMethod>
<DigestValue>
Core element 2/4:
<SignatureValue>
NOT signature of resource itself!
Digital signature of the <SignedInfo>
block
Signature Method, Resource Reference &
Resource Digest
Indirect, but water tight signature of
resource
Core element 3/4:
<KeyInfo> ?
1. Can be omitted completely (assuming
the receiver's got it already).
2. Provide a name to look up the key.
3. Provide the key in a raw form right in
the XML.
4. Provide the key within a digital
certificate.
Provides a variety of types of keys to
support different cryptography standards.
Know your Keys! Verify!
Know your Keys! Verify!
Key is Valid (CA)
Key is not revoked
(asym:) Represents the individual
Core element 4/4: <Object>
*
Type-attribute: 1 out of three:
"Enveloping Signature: Here's your data"
A Manifest element
A SignatureProperties element
Resulting Schema
shorthand
<Signature>
<SignedInfo>
<CanonicalizationMethod>
<SignatureMethod>
(<Reference URI ? >
<Transforms> ?
<DigestMethod>
<DigestValue>
</Reference>)+
</SignedInfo>
<SignatureValue>
(<KeyInfo (id=)?>
(<KeyName>)?
(<KeyValue>)?
(<RetrievalMethod>)?
(<X509Data>)?
(<PGPData>)?
(<SPKIData>)?
(<MgmtData>)?
<KeyInfo>)?
(<Object>
(<Manifest (id=)?>
<Reference> +
</Manifest>) ?
(<SignatureProperties>
<SignatureProperty (id=)?> +
</SignatureProperties>) ?
</Object> ) *
</Signature>
Best practices
1. Transformations
1.1. Only what is signed, is secure

(... and NOT that what has been
removed by Transform, but still present in
resource!)
1.2. WYSIWYS

(... hence: include XSL(T)-stylesheet)
1.3. Work on what is signed

(... not on resource, but on
transformed resource)
2. Security model
2.1. Know your Keys! Verify them!
2.2. Public key signatures are primarily
associated with identity and integrity.
2.3. Keyed hashed authentication codes are
shared key based, run much faster than public
keys, however ONLY provides integrity, not
identity
2.4. XML-Signature processing does not
automatically sign <Object> elements within a
<Signature> element: Only <SignedInfo> is
signed!
Summary
XML-Encryption
XML-Encryption
Objective
2. Message oriented
2.1. Web services typically use multi-hop
communication paths
2.2. Transport level security (SSL, TLS, IPSEC,
...) only provides Point-2-Point (on-the-wire)
confidentiality
2.3. Messages are decrypted in the servers
(a.o. routing), violating confidentiality
2.4. Hence End-2-End, i.e. message based,
confidentiality required
2.5. Combined approach is possible
3. One document, Multiple
views
3.1. Encrypt different sections
3.2. Possibly with distinct keys
3.3. Hence: different sections mutually
exclusive available for different target
audiences
4. Target resource
4.1. Internal encryption: Within current
document (similar to Enveloping)
4.2. External encryption: external
resource (similar to Detached)
... XML document
... any other MIME-type document
... as long as it has got a URL
XML-Encryption structure
Example Enc1:
Highly Simplified XML-Encryption (1/1)
<MyDoc>
<Employee>
<SSNo>34569812612</SSNo>
<Name>Fred Jones</Name>
<Salary>$42.644</Salary>
<Manager>David Mischief</Manager>
</Employee>
Binary, encrypted
content
encapsulated by
original <SSNo>
</MyDoc>
encapsulating
original <Salary>
<MyDoc>
<Employee>
<SSNo>
<EncryptedData>kjhGEuf7639Fh*e#j&2V</EncryptedData>
</SSNo>
<Name>Fred Jones</Name>
<EncryptedData>jHFnkeiuHF3#9jeGi$@kjg*KJGm,jF</EncryptedData>
<Manager>David Mischief</Manager>
</Employee>
</MyDoc>
Core: <EncryptedData>
element
Either wraps data within the XML
document that is being encrypted
Or it points to something that has been
encrypted
<EncryptedData> ..CipherData or
ReferenceToCipherData..
</EncryptedData>
<EncryptedData>-element replaces
original content
The Bloody Details
1. <EncryptedData>
1.1. Purpose:
1.1.1. Overall tag, container for XMLEncryption structure
1.1.2. Can be placed anywhere in your
XML resource
1.1.3. Represents: one single resource
that has been encrypted
1.1.4. Encrypted data either
encompassed or detached
1.2. Attributes for
<EncryptedData>
1.2.1. Id : one can refer to this
<EncryptedData> element
1.2.2. Type="Content" or "Element":
1.2.3. MIME Type :
1.2.4. Encoding :
1.2.5. All attributes are optional, in
practice Type always included
1.2.2. Type="Content" or
"Element":
Don't encrypt
<element> tag
... <SSNo> tag
encapsulates
<EncryptedData> tag
Do encrypt
<element> tag
... <EncryptedData>element encapsulates
disappeared
<Salary> tag
1.2.3. MIME Type :
To further describe the encrypted item,
i.e. GIF image
MimeType='image/gif'
1.2.4. Encoding :
To further describe the encrypted item,
i.e. Base-64 character encoding
Because encrypted data is binary data...
... encoding describes method to encode
binary encrypted data to character data ...
... to be able to insert it in an XML
document
Encoding="http://www.w3.org/2000/09/x
mldsig#base64"
1.3. <EncryptedData> &
Multiple views:
1.3.1. Define <EncryptedData> elements
1.3.2. Each is associated with one single
key
1.3.3. Use N keys for N target audiences
2. <EncryptionMethod/> ?
3. <CipherData>
4. <EncryptionProperties>
?
5. <KeyInfo> ?
5.1. Encryption key =
symmetrical key: (1/4)
5.1.1. Speed 1000x faster than
asymmetrical
5.1.2. Unlimited plain text size of target
5.1.3. Shared key encryption utilizes
public key encryption to manage
distribution of the shared key securely to
the recipient
5.2. <KeyInfo> element
structure (2/4)
5.2.1. Identical to XML-Sig <KeyInfo>
5.2.2. Additional elements for key
transport (<EncryptedKey>,
<AgreementMethod>)
5.3. Key Transport (3/4)
5.3.1. Leave out the key (assuming both
sides already know the secret key).
5.3.2. Provide name or pointer to it (he's
got it, but needs to know which one to
select: <keyName> or
<RetrievalMethod>)
5.3.3. Include encrypted symmetrical
key:
5.3.4. Include hint to generate key:
5.3.3. Include encrypted
symmetrical key:
Uses asymmetrical key technology to
transport symmetrical encryption key
<EncryptedKey> element
Contains encrypted asymmetrical key
Identical to <EncryptedData> structure &
syntax
Can thus be recursive (!)
Strategy is called "Digital Enveloping"
5.3.4. Include hint to
generate key:
Uses "Key Agreement Protocol" to
transport information to generate symm.
key
Provide key generation algorithm, nonce,
originator & recipient key info etc.
<AgreementMethod> element
5.4. <ReferenceList> (4/4)
5.4.1. Lord of the
Keys: "One Key to
Rule Them All"
5.4.2. Efficiency: one
<KeyInfo> block
suffices
5.4.3. List of refs. to
<EncryptedData>
elements using this
<KeyInfo>
Super encryption
<EncryptedData> element encrypts other
<EncryptedData> elements:
Fully recursive
Applies to entire <EncryptedData>
element(s), not its parts
Resulting Schema
shorthand
<EncryptedData Id? Type? MimeType? Encoding?>
<EncryptionMethod/>?
<ds:KeyInfo>
<EncryptedKey>?
<AgreementMethod>?
<ds:KeyName>?
<ds:RetrievalMethod>?
<ds:*>?
</ds:KeyInfo>?
<CipherData>
<CipherValue>?
<CipherReference URI?>?
</CipherData>
<EncryptionProperties>?
</EncryptedData>
Combining XML-Encryption
with XML-Signature
Example Enc & Sig 1:
Protecting Integrity of <EncryptedData>(1/2)
EncryptedData for SSNo.
Ciphered SSNo.
Key (1) info belonging to
Ciphered SSNo.
EncryptedData for Key
Encrypted Key to decrypt
Ciphered SSNo.
Key (2) info belonging to
Encrypted Key
Signed info refers to Encrypted
Data for SSNo.
Digest of EncryptedData for
SSNo.
Signature of SignedInfo
Key (3) info to verify Signature
Example Enc & Sig 1:
Protecting Integrity of <EncryptedData>(2/2)
Reasonable Statement
Iff:
Confident keys are associated with sender & recipient
AND private keys are not compromised
Then:
“This document was prepared by David Remy and can only
be read by Jothy Rosenberg”
SfE: however...
 <Signature> &
<EncryptedData> are
detached
 <Signature> can be
removed without being
noticed
 <Signature> can even be
replaced: "Signed by
David Copperfield"
 Need Policy: If encrypted,
then also signed
 BTW: what's the order of
processing ??
Example Enc & Sig 2:
Encryption follows Signing (1/3)
The original Order
<Order>
<LineItem sku="82394" quantity="1">
<ProductName>Birdcage</ProductName>
</LineItem>
<Customer id="customer" custNum="A2345">
<FirstName>Fred</FirstName>
<MiddleInit>L</MiddleInit>
<LastName>Jones</LastName>
<CreditCard>
<CreditCardType>VISA</CreditCardType>
<CreditCardNumber>43343456343566</CreditCardNumber>
<CreditCardExpiration>10/08</CreditCardExpiration>
</CreditCard>
</Customer>
</Order>
Example Enc & Sig 2:
Encryption follows Signing (2/3)
The Order, signed by David Remy
<Order>
<LineItem sku="82394" quantity="1">
<ProductName>Birdcage</ProductName>
</LineItem>
<Customer id="customer" custNum="A2345">
<Name . . . />
<CreditCard . . . />
<Signature>
<SignedInfo>
<CanonicalizationMethod Algorigthm=". . ." />
<SignatureMethod Algorithm=". . ." />
<Reference URI="#customer">
<Transform Algorithm=".../#envelopedSignature" />
<DigestMethod Algorithm=". . ." />
<DigestValue>. . .</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>. . . </SignatureValue>
<KeyInfo>
<X509Data>
<X509SubjectName>O=MyCompany,OU=Engineering,CN=David Remy</X509SubjectName>
</X509Data>
</KeyInfo>
</Signature>
</Customer>
</Order>
Example Enc & Sig 2:
Encryption follows Signing (3/3)
The signed order,
<Customer> is element Encrypted
<Order>
<LineItem sku="82394" quantity="1">
<ProductName>Birdcage</ProductName>
</LineItem>
<EncryptedData id="encryptedData1" Type="Element">
<EncryptionMethod Algorithm=". . ." />
<CipherText>
<CipherValue>. . . </CipherValue>
</CipherText>
<KeyInfo>
<EncryptedKey>
<EncryptionMethod Algorithm=". . ." />
<CipherText>
<CipherValue>. . .</CipherValue>
</CipherText>
<KeyInfo>
<X509Data>
<X509Subject>O=HisCompany,OU=Technology,CN=Jothy Rosenberg</X509Subject>
</X509Data>
</KeyInfo>
</EncryptedKey>
</KeyInfo>
</EncryptedData>
</Order>
EfS: however...
++ Signature, w/t
sensitive data,
invisible
++ Clear order of
processing
-- Integrity of
EncryptedData isn’t
guaranteed
In conclusion
Order of processing SfE
Security Model: SfE or EfS
Order of processing SfE
Problem: What to do 1st, Decrypt or
Validate Signature
Solution: additional 'Decrypt Transform'
for XML-Signature
Security Model: SfE or EfS
Depends on context, the specific situation
Specify a Policy
Consider multi-layered approach SfEfS
Summary