Web Services & Security

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

2. Web Services & Security

3. Web Services

4. 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

5. What's its Significance? • Application Integration • EAI, B2B, Automating Business Processes • Universal Application Connectivity

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

7. What are the Security Challenges? • Message oriented • Identities

8. Message oriented • Web services typically use multi-hop communication paths • Transport level security (SSL, TLS, IPSEC, ...) only provides Point-2-Point (on-the-wire) 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

9. 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?

10. XML-family

11. XML-family

12. XML basics

13. 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!!

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

15. Example 1: Simple XML (1/1) Element: Data enclosed by named tags: <element>data</element> An Order 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> <MiddleInit>L</MiddleInit> <LastName>Jones</LastName> <CreditCard> <CreditCardType>VISA</CreditCardType> <CreditCardNumber>43343456343566</CreditCardNumber> <CreditCardExpiration>10/08</CreditCardExpiration> </CreditCard> </Customer> </Order> Start-tag can contain attributes: attributeName=value Reserved attributeNames: “id=” uniquely identifies individual element Empty element: no data, single <element/> tag

16. 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

17. Example 2: XML Schema (1/1) <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> <MiddleInit>L</MiddleInit> <LastName>Jones</LastName> <CreditCard> <CCType>VISA</CCType> <CCNumber> . . </CCNumber> <CCExpiration>10/08</CCExpiration> </CreditCard> </Customer> </Order> An Order <xsd:schema xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <xsd:element name="Order" type="order"/> <xsd:complexType name="order"> <xsd:element name="LineItem" type="lineItemType"/> <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>

18. Namespaces • Problem • Solution: xmlns

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

20. Solution: xmlns XML namespace (1/1) <xsd:schema xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <xsd:element name="Order" type="order"/> <xsd:complexType name="order"> <xsd:element name="LineItem" type="lineItemType"/> <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 are uniform resource identifiers: • Define unique name • Prepend that to each & every element name xmlns:myns=“http://www.myorg.com/foo” <myns:order> My unique namespace Abbreviated namespace: prefix Unique element name Reserved namespace: “namespace def coming up”

21. XML Landscape • XML standards belonging to operation domain • XML standards belonging to XML Family (Security) • XML standards belonging to XML Family (general)

22. 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

23. 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 (Security)

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

25. XML-Signature

26. XML-Signature

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

28. 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:

29. 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

30. XML-Signature structure

31. 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

32. Example Sig1:Highly Simplified XML Signature (1/1) Reference(s) to what is being signed <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <Reference URI="http://www.foo.com/secureDocument.html" /> </SignedInfo> <SignatureValue>...</SignatureValue> <KeyInfo>... </KeyInfo> </Signature> actual signature bits information about the key

33. 3 Types of XML-Signature • Enveloping Signatures • Enveloped Signatures • Detached Signatures

34. 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>

35. 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>

36. 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>

37. 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>

38. The Bloody Details

39. Core element 1/4: <SignedInfo> • 1. Security model • 2. Canonicalization (c14n) • 3. Identify resource(s) to be signed

40. 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 />

41. 2. Canonicalization (c14n) • 2.1. c14n normalizes the XML • 2.2. c14n: What does it actually do?

42. 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.

43. 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. 2.2. c14n: What does it actually do?

44. 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 ? > +

45. <Reference URI ? > + • <Transforms> ? • <DigestMethod> • <DigestValue>

46. 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

47. 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!

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

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

50. 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>