Web Services Security ir Paul Brandt TNOICT v

Web Services & Security ir. Paul Brandt, TNO-ICT v. Today, Friday January 13 v. Next week, Friday January 20

Web Services & Security

Web Services

What are Web Services? z. Web pages for computers z. Reality: heterogeneous systems, platforms, data z. Reality: Processes change, be agile to cope z. Application: provides service z. Request-response z. Lousely coupled

What's its Significance? z. Application Integration z. EAI, B 2 B, Automating Business Processes z. Universal Application Connectivity

Universal Application Connectivity z. Easy to access remote resources z. Expose business processes over the Web z. Interface is standard, published, discoverable, self-describing

What are the Security Challenges? z. Message oriented z. Identities

Message oriented z. Web services typically use multi-hop communication paths z. Transport level security (SSL, TLS, IPSEC, . . . ) only provides Point-2 -Point (on-thewire) confidentiality z. Messages are decrypted in the servers (a. o. routing), violating confidentiality z. Hence End-2 -End, i. e. message based, confidentiality required z. Combined approach is possible

Identities z. Web services transport potentially unkown identies into my platform z. Who are they? z. Are they authorized? z. Assett protection: What critical information is leaving my platform? z. Can it be proved they did these things?

XML-family

XML basics

XML Objective z. Structured, self describing interface. . . z. . . totally independent application, protocol, vocabulary, operating system & programming language z. Grammar & syntax to build interface z. Nothing to do with semantics!!

XML Characteristics z. XML stores data within descriptive element tags: <Part. No>54 -2345</Part. No> z. Character-oriented, not binary, hence human-readable z. Extensible Meta Language z. Separates content from structure & form z. All family members are specified in XML itself

Example 1: An Order Simple XML (1/1) Element: Data enclosed by named tags: <element>data</element> Hierarchical: <Element> can contain other <Element>’s <Order> <Line. Item sku="82394" quantity="1"> <Product. Name>Birdcage</Product. Name> <Model material="Iron" color="Blue" /> </Line. Item> <Amount Currency="USD">108. 50</Amount> <Customer id="customer" cust. Num="A 2345"> <First. Name>Fred</First. Name> Start-tag can contain attributes: attribute. Name=value Reserved attribute. Names: “id=” uniquely identifies individual element <Middle. Init>L</Middle. Init> <Last. Name>Jones</Last. Name> <Credit. Card. Type>VISA</Credit. Card. Type> <Credit. Card. Number>43343456343566</Credit. Card. Number> <Credit. Card. Expiration>10/08</Credit. Card. Expiration> </Credit. Card> </Customer> </Order> Empty element: no data, single <element/> tag

XML Schema z. XML document can be validated against schema, automatically z. Schema defines hierarchical structure z. Schema defines data types z. Schema defines particular order of elements z. Schema provides for accurate & consistent data z. XML document = instance of defined XML schema

Example 2: An Order XML Schema (1/1) <Order> <Line. Item sku="82394" quantity="1"> <Product. Name>Birdcage</Product. Name> <Model material="Iron" color="Blue" /> </Line. Item> <Amount Currency="USD">108. 50</Amount> <Customer id="customer" cust. Num="A 2345"> <First. Name>Fred</First. Name> <Middle. Init>L</Middle. Init> <xsd: schema xmlns: xsd="http: //www. w 3. org/1999/XMLSchema"> <Last. Name>Jones</Last. Name> <Credit. Card> <xsd: element name="Order" type="order"/> <CCType>VISA</CCType> <CCNumber>. . </CCNumber> <CCExpiration>10/08</CCExpiration> <xsd: complex. Type name="order"> <xsd: element name="Line. Item" type="line. Item. Type"/> </Credit. Card> </Customer> </Order> <xsd: element name="Amount" type="amount. Type"/> <xsd: element name="Customer" type="customer. Type"/> </xsd: complex. Type> <xsd: complex. Type name="line. Item. Type"> <xsd: element name="Product. Name" type="xsd: string"/> <xsd: element name="Model" type="model. Type"/> </xsd: complex. Type>. . . etc. , until all types correspond to simple. Types (integer, string, double, float, date and time) </xsd: schema>

Namespaces z. Problem z. Solution: xmlns

Problem z. Anyone can define element names z. Hence, name collision and conflicts all along z. XML shall keep names separate and distinct

<xsd: schema xmlns: xsd="http: //www. w 3. org/1999/XMLSchema"> Solution: xmlns <xsd: element name="Order" type=" order"/> <xsd: complex. Type name="order"> XML namespace (1/1) <xsd: element name="Line. Item" type="line. Item. Type"/> <xsd: element name="Amount" type=" amount. Type"/> <xsd: element name="Customer" type=" customer. Type"/> </xsd: complex. Type > <xsd: complex. Type name="line. Item. Type"> Namespaces are uniform resource identifiers: 1. Define unique name 2. Prepend that to each & every element name <xsd: element name="Product. Name" type="xsd: string"/> <xsd: element name="Model" type=" model. Type"/> </xsd: complex. Type >. . . etc. , until all types correspond to simple. Types (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 z. XML standards belonging to operation domain z. XML standards belonging to XML Family (Security) z. XML standards belonging to XML Family (general)

XML standards belonging to operation domain zhr. XML - XML for Human Resource (employment agencies) z. X 4 ML - XML for Merrill Lynch z. HL-7 v 3: XML message format for Health Care z. . zreally, really big landscape

XML standards belonging to XML Family (Security) z SOAP - Simple Object Access Protocol z XML-Signature z XML-Encryption z SAML - Security Assertion Markup Language z XACML - e. Xtensible Access Control Markup Language z Xr. ML - e. Xtensible Rights ML z XKMS - XML Key Management Specification z WS-Security z WS-Policy

XML standards belonging to XML Family (general) z. WS-*: Web Service standards z. WSDL - Web Services Description Language z. XSL(T) - e. Xtensible Stylesheet Language (Transformations) z. XPath

XML-Signature

Objective z. Integrity of resource z. Identity of originator z. Non-repudiation of event z. Foundation from Digital Signature

Foundation from Digital Signature z. Greatly expands upon it: z. Uses power and flexibility of XML. . . z. . . as well as key Web technologies (such as URLs). . . zto sign almost any type of resource:

to sign almost any type of resource: z. XML documents z. Parts thereof znon-XML object such as an image zas long as it has an URL

XML-Signature structure

Core z. A set of pointers (references) to things to be signed z. The actual signature z(Optional) The key (or a way to look up the key) for verifying the signature z(Optional) An Object tag for miscellaneous items not included in the first three items

Example Sig 1: Highly Simplified XML Signature (1/1) <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#"> Reference(s) to what is being signed <Signed. Info> <Reference URI="http: //www. foo. com/secure. Document. html" /> </Signed. Info> <Signature. Value>. . . </Signature. Value> <Key. Info>. . . </Key. Info> actual signature bits </Signature> information about the key

3 Types of XML-Signature z. Enveloping Signatures z. Enveloped Signatures z. Detached Signatures

Example Sig 2: Simplified Enveloping Signatures (1/4) <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info> <Reference URI="#111" /> </Signed. Info> <Signature. Value>. . . </Signature. Value> <Key. Info>. . . </Key. Info> <Object> <Signed. Item id="111">Stuff to be signed</ Signed. Item> </Object> </Signature>

Example Sig 2: Simplified Enveloped Signatures (2/4) <Purchase. Order id="po 1"> <SKU>125356</SKU> <Quantity>17</Quantity> <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info> <Reference URI="#po 1" /> </Signed. Info> <Signature. Value>. . . </Signature. Value> <Key. Info>. . . </Key. Info> </Signature> </Purchase. Order>

Example Sig 2: Detached Signatures (3/4) internal resource <Purchase. Order. Document> <Purchase. Order id="po 1"> <SKU>12366</SKU> <Quantity>17</SKU> </Purchase. Order> <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info> <Reference URI="#po 1" /> </Signed. Info> <Signature. Value>. . . </Signature. Value> <Key. Info>. . . </Key. Info> </Signature> </Purchase. Order. Document>

Example Sig 2: Detached Signatures (4/4) external resource <Signature xmlns="http: //www. w 3. org/2000/09/xmldsig#"> <Signed. Info> <Reference URI="http: // www. foo. com/Lion. jpg" /> <Reference URI="http: // www. foo. com/Secure. txt" /> <Reference URI="http: // www. foo. com/Secure. xml" /> </Signed. Info> <Signature. Value>. . . </Signature. Value> <Key. Info>. . . </Key. Info> </Signature>

The Bloody Details

Core element 1/4: <Signed. Info> z 1. Security model z 2. Canonicalization (c 14 n) z 3. Identify resource(s) to be signed

1. Security model z. No new security technologies were invented (Digital Signature) z. But: Digital Signature == Integrity AND Identity z. Hence: Public keys (asymmetrical: RSA, DSA) => integrity & identity z. Keyed Hashed Authentication Code (symmetrical: HMAC) => ONLY integrity, NO identity z<Signature. Method />

2. Canonicalization (c 14 n) z 2. 1. c 14 n normalizes the XML z 2. 2. c 14 n: What does it actually do?

2. 1. c 14 n normalizes the XML zregardless of inconsequential physical differences in the XML. . . z. . . two logically equivalent XML documents. . . z. . . will become physically, bit-to-bit equivalent. z z. This is a critical requirement for digital signatures to work.

2. 2. c 14 n: What does it actually do? z The document is encoded in UTF-8. z Line breaks are normalized to #x. A on input, before parsing. z Attribute values are normalized, as if by a validating processor. z Character and parsed entity references are replaced. z CDATA sections are replaced with their character content. z The XML declaration and Document Type Definition (DTD) are removed. z Empty elements are converted to start -end tag pairs. z Whitespace outside the document element and within start and end tags is normalized. z All whitespace in character content is retained (excluding characters removed during linefeed normalization). z Attribute value delimiters are set to quotation marks (double quotes). z Special characters in attribute values and character content are replaced by character references. z Superfluous namespace declarations are removed from each element. z Default attributes are added to each element. z Lexicographic order is imposed on the namespace declarations and attributes of each element.

3. Identify resource(s) to be signed z. Reference the resource(s) (enveloped/ing/detached) using URI z. Calculate (& include) Digest of referenced resource z(not before Transforms have been applied, such as c 14 n, XSLT, XPath) z<Reference URI ? > +

Core element 2/4: <Signature. Value> z. NOT signature of resource itself! z. Digital signature of the <Signed. Info> block z. Signature Method, Resource Reference & Resource Digest z. Indirect, but water tight signature of resource

Core element 3/4: <Key. Info> ? z 1. Can be omitted completely (assuming the receiver's got it already). z 2. Provide a name to look up the key. z 3. Provide the key in a raw form right in the XML. z 4. Provide the key within a digital certificate. z. Provides a variety of types of keys to support different cryptography standards. z. Know your Keys! Verify!

Know your Keys! Verify! z. Key is Valid (CA) z. Key is not revoked z(asym: ) Represents the individual

Core element 4/4: <Object> * z. Type-attribute: 1 out of three: z"Enveloping Signature: Here's your data" z. A Manifest element z. A Signature. Properties element

Resulting Schema shorthand <Signature> <Signed. Info> <Canonicalization. Method> <Signature. Method> (<Reference URI ? > <Transforms> ? <Digest. Method> <Digest. Value> </Reference>)+ </Signed. Info> <Signature. Value> (<Key. Info (id=)? > (<Key. Name>)? (<Key. Value>)? (<Retrieval. Method>)? (<X 509 Data>)? (<PGPData>)? (<SPKIData>)? (<Mgmt. Data>)? <Key. Info>)? (<Object> (<Manifest (id=)? > <Reference> + </Manifest>) ? (<Signature. Properties> <Signature. Property (id=)? > + </Signature. Properties>) ? </Object> ) * </Signature>

Best practices

1. Transformations z 1. 1. Only what is signed, is secure z (. . . and NOT that what has been removed by Transform, but still present in resource!) z 1. 2. WYSIWYS z (. . . hence: include XSL(T)-stylesheet) z 1. 3. Work on what is signed z (. . . not on resource, but on transformed resource)

2. Security model z 2. 1. Know your Keys! Verify them! z 2. 2. Public key signatures are primarily associated with identity and integrity. z 2. 3. Keyed hashed authentication codes are shared key based, run much faster than public keys, however ONLY provides integrity, not identity z 2. 4. XML-Signature processing does not automatically sign <Object> elements within a <Signature> element: Only <Signed. Info> is signed!

Summary

XML-Encryption

Objective

2. Message oriented z 2. 1. Web services typically use multi-hop communication paths z 2. 2. Transport level security (SSL, TLS, IPSEC, . . . ) only provides Point-2 -Point (on-the-wire) confidentiality z 2. 3. Messages are decrypted in the servers (a. o. routing), violating confidentiality z 2. 4. Hence End-2 -End, i. e. message based, confidentiality required z 2. 5. Combined approach is possible

3. One document, Multiple views z 3. 1. Encrypt different sections z 3. 2. Possibly with distinct keys z 3. 3. Hence: different sections mutually exclusive available for different target audiences

4. Target resource z 4. 1. Internal encryption: Within current document (similar to Enveloping) z 4. 2. External encryption: external resource (similar to Detached) z. . . XML document z. . . any other MIME-type document z. . . as long as it has got a URL

XML-Encryption structure

Example Enc 1: Highly Simplified XML-Encryption (1/1) <My. Doc> <Employee> <SSNo>34569812612</SSNo> <Name>Fred Jones</Name> <Salary>$42. 644</Salary> <Manager>David Mischief</Manager> </Employee> Binary, encrypted content encapsulated by original <SSNo> </My. Doc> encapsulating original <Salary> <My. Doc> <Employee> <SSNo> <Encrypted. Data>kjh. GEuf 7639 Fh*e#j&2 V</Encrypted. Data> </SSNo> <Name>Fred Jones</Name> <Encrypted. Data>j. HFnkeiu. HF 3#9 je. Gi$@kjg*KJGm, j. F</Encrypted. Data> <Manager>David Mischief</Manager> </Employee> </My. Doc>

Core: <Encrypted. Data> element z. Either wraps data within the XML document that is being encrypted z. Or it points to something that has been encrypted z<Encrypted. Data>. . Cipher. Data or Reference. To. Cipher. Data. . </Encrypted. Data> z<Encrypted. Data>-element replaces original content

The Bloody Details

1. <Encrypted. Data>

1. 1. Purpose: z 1. 1. 1. Overall tag, container for XMLEncryption structure z 1. 1. 2. Can be placed anywhere in your XML resource z 1. 1. 3. Represents: one single resource that has been encrypted z 1. 1. 4. Encrypted data either encompassed or detached

1. 2. Attributes for <Encrypted. Data> z 1. 2. 1. Id : one can refer to this <Encrypted. Data> element z 1. 2. 2. Type="Content" or "Element": z 1. 2. 3. MIME Type : z 1. 2. 4. Encoding : z 1. 2. 5. All attributes are optional, in practice Type always included

1. 2. 2. Type="Content" or "Element": z Don't encrypt <element> tag z. . . <SSNo> tag encapsulates <Encrypted. Data> tag z Do encrypt <element> tag z. . . <Encrypted. Data>element encapsulates disappeared <Salary> tag

1. 2. 3. MIME Type : z. To further describe the encrypted item, i. e. GIF image z. Mime. Type='image/gif'

1. 2. 4. Encoding : z. To further describe the encrypted item, i. e. Base-64 character encoding z. Because encrypted data is binary data. . . z. . . encoding describes method to encode binary encrypted data to character data. . . z. . . to be able to insert it in an XML document z. Encoding="http: //www. w 3. org/2000/09/x mldsig#base 64"

1. 3. <Encrypted. Data> & Multiple views: z 1. 3. 1. Define <Encrypted. Data> elements z 1. 3. 2. Each is associated with one single key z 1. 3. 3. Use N keys for N target audiences

2. <Encryption. Method/> ?

3. <Cipher. Data>

4. <Encryption. Properties> ?

5. <Key. Info> ?

5. 1. Encryption key = symmetrical key: (1/4) z 5. 1. 1. Speed 1000 x faster than asymmetrical z 5. 1. 2. Unlimited plain text size of target z 5. 1. 3. Shared key encryption utilizes public key encryption to manage distribution of the shared key securely to the recipient

5. 2. <Key. Info> element structure (2/4) z 5. 2. 1. Identical to XML-Sig <Key. Info> z 5. 2. 2. Additional elements for key transport (<Encrypted. Key>, <Agreement. Method>)

5. 3. Key Transport (3/4) z 5. 3. 1. Leave out the key (assuming both sides already know the secret key). z 5. 3. 2. Provide name or pointer to it (he's got it, but needs to know which one to select: <key. Name> or <Retrieval. Method>) z 5. 3. 3. Include encrypted symmetrical key: z 5. 3. 4. Include hint to generate key:

5. 3. 3. Include encrypted symmetrical key: z. Uses asymmetrical key technology to transport symmetrical encryption key z<Encrypted. Key> element z. Contains encrypted asymmetrical key z. Identical to <Encrypted. Data> structure & syntax z. Can thus be recursive (!) z. Strategy is called "Digital Enveloping"

5. 3. 4. Include hint to generate key: z. Uses "Key Agreement Protocol" to transport information to generate symm. key z. Provide key generation algorithm, nonce, originator & recipient key info etc. z<Agreement. Method> element

5. 4. <Reference. List> (4/4) z 5. 4. 1. Lord of the Keys: "One Key to Rule Them All" z 5. 4. 2. Efficiency: one <Key. Info> block suffices z 5. 4. 3. List of refs. to <Encrypted. Data> elements using this <Key. Info>

Super encryption z<Encrypted. Data> element encrypts other <Encrypted. Data> elements: z. Fully recursive z. Applies to entire <Encrypted. Data> element(s), not its parts

Resulting Schema shorthand <Encrypted. Data Id? Type? Mime. Type? Encoding? > <Encryption. Method/>? <ds: Key. Info> <Encrypted. Key>? <Agreement. Method>? <ds: Key. Name>? <ds: Retrieval. Method>? <ds: *>? </ds: Key. Info>? <Cipher. Data> <Cipher. Value>? <Cipher. Reference URI? >? </Cipher. Data> <Encryption. Properties>? </Encrypted. Data>

Combining XML-Encryption with XML-Signature

Example Enc & Sig 1: Protecting Integrity of <Encrypted. Data>(1/2) Encrypted. Data for SSNo. Ciphered SSNo. Key (1) info belonging to Ciphered SSNo. Encrypted. Data 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 Encrypted. Data for SSNo. Signature of Signed. Info Key (3) info to verify Signature

Example Enc & Sig 1: Protecting Integrity of <Encrypted. Data>(2/2) Reasonable Statement Iff: z. Confident keys are associated with sender & recipient z. AND private keys are not compromised Then: “This document was prepared by David Remy and can only be read by Jothy Rosenberg”

Sf. E: however. . . z <Signature> & <Encrypted. Data> are detached z <Signature> can be removed without being noticed z <Signature> can even be replaced: "Signed by David Copperfield" z Need Policy: If encrypted, then also signed z BTW: what's the order of processing ? ?

Example Enc & Sig 2: Encryption follows Signing (1/3) The original Order <Order> <Line. Item sku="82394" quantity="1"> <Product. Name>Birdcage</Product. Name> </Line. Item> <Customer id="customer" cust. Num="A 2345"> <First. Name>Fred</First. Name> <Middle. Init>L</Middle. Init> <Last. Name>Jones</Last. Name> <Credit. Card. Type>VISA</Credit. Card. Type> <Credit. Card. Number>43343456343566</Credit. Card. Number> <Credit. Card. Expiration>10/08</Credit. Card. Expiration> </Credit. Card> </Customer> </Order>

Example Enc & Sig 2: Encryption follows Signing (2/3) The Order, signed by David Remy <Order> <Line. Item sku="82394" quantity="1"> <Product. Name>Birdcage</Product. Name> </Line. Item> <Customer id="customer" cust. Num="A 2345"> <Name. . . /> <Credit. Card. . . /> <Signature> <Signed. Info> <Canonicalization. Method Algorigthm=". . . " /> <Signature. Method Algorithm=". . . " /> <Reference URI="#customer"> <Transform Algorithm=". . . /#enveloped. Signature" /> <Digest. Method Algorithm=". . . " /> <Digest. Value>. . . </Digest. Value> </Reference> </Signed. Info> <Signature. Value>. . . </Signature. Value> <Key. Info> <X 509 Data> <X 509 Subject. Name>O= My. Company, OU=Engineering, CN=David Remy</X 509 Subject. Name> </X 509 Data> </Key. Info> </Signature> </Customer> </Order>

Example Enc & Sig 2: Encryption follows Signing (3/3) The signed order, <Customer> is element Encrypted <Order> <Line. Item sku="82394" quantity="1"> <Product. Name>Birdcage</Product. Name> </Line. Item> <Encrypted. Data id="encrypted. Data 1" Type="Element"> <Encryption. Method Algorithm=". . . " /> <Cipher. Text> <Cipher. Value>. . . </Cipher. Value> </Cipher. Text> <Key. Info> <Encrypted. Key> <Encryption. Method Algorithm=". . . " /> <Cipher. Text> <Cipher. Value>. . . </Cipher. Value> </Cipher. Text> <Key. Info> <X 509 Data> <X 509 Subject>O=His. Company, OU=Technology, CN=Jothy Rosenberg</X 509 Subject> </X 509 Data> </Key. Info> </Encrypted. Key> </Key. Info> </Encrypted. Data> </Order>

Ef. S: however. . . z ++ Signature, w/t sensitive data, invisible z ++ Clear order of processing z -- Integrity of Encrypted. Data isn’t guaranteed

In conclusion z. Order of processing Sf. E z. Security Model: Sf. E or Ef. S

Order of processing Sf. E z. Problem: What to do 1 st, Decrypt or Validate Signature z. Solution: additional 'Decrypt Transform' for XML-Signature

Security Model: Sf. E or Ef. S z. Depends on context, the specific situation z. Specify a Policy z. Consider multi-layered approach Sf. Ef. S

Summary