G52IWS: Web Service Security

1. G52IWS: Web Service Security Chris Greenhalgh 2007-11-10

2. Contents • Technologies of Web Service security • Introduction to cryptography • XML encryption • XML signatures • Other standards See “Developing Java Web Services”, chapter 13 (part)

3. Challenges for web service security • Diverse requirements, from none to business-class security • E.g. involving financial transactions • Should be open and extensible • Should be interoperable and work between different organisations • Should leverage existing standards • Should be Easy to develop and use 

4. Technologies behind web service security • (hopefully) a set of flexible, interoperable security alternatives… • XML Encryption • XML Signature (XML DSIG) • Security Assertions Markup Language (SAML) • XML Access Control Markup Language (XACML) • XML Key Management Services (XKMS) • WS-Security

5. Introduction to cryptography • Cryptography is “the art of secret writing” • E.g. see Bruce Schneider's Applied Cryptography (John Wiley & Sons, 1996) • Four goals of cryptography • Confidentiality • Authentication • Integrity • Non-repudiation

6. Confidentiality • Ensuring that only authorised persons can understand data • Unauthorised persons may know it exists, e.g. intercepting data in transit, but cannot understand it • Achieved through encryption • Use of cryptographic algorithm (cipher) plus secret information (key) to transform plaintext into ciphertext • Reversible only with the correct key

7. Authentication • Ensuring the identity of a party (principal) within some security domain • Based on: • something you know, • something you are, • something you have, • something you can do • E.g. knowing a password or having a (secret) key • Required for effective authorisation, i.e. being allowed/not allowed to do something

8. Integrity • Protected information from unauthorized (or accidental) modification • For messages this usually means making modification evident • rather than strictly being able to prevent, which requires physical barriers, e.g. write-once media • E.g. achieved (in part) through the use of checksums generated by hashing algorithms

9. Non-repudiation • Repudiation = refusing to accept something • Non-repudiation = ensuring that a party cannot repudiate some action • E.g. placing an order, authorising a funds transfer • May be achieved (in part) using digital signatures

10. Cryptography algorithms & other building blocks • One-way hash functions • Symmetric algorithms • Asymmetric algorithms • Digital signatures • Digital certificates

11. One-way hash functions • Computers a fixes-length hash (message digest) for a given message • A slight change in the message results in a change in the hash (c.f. checksum) • One-way = computationally infeasible to work out a message that would produce a given hash • E.g. • MD4 (Message Digest 4, 128 bit hash), MD5, • SHA (Secure Hash Algorithm, 160 bit hash)

12. One-way hash functions (cont.) • Hash can be used in place of the message in certain situations, e.g. • Storing hashes of passwords rather than the passwords themselves • If hashes are stolen the passwords cannot be worked out from them (one-way) • Passwords can still be checked by hashing then checking • Building block for message integrity and digital signatures

13. Symmetric algorithms (symmetric ciphers) • = Encryption where the same key is used both for encryption and decryption, e.g. “Developing Java Web Services”, figure 13.1

14. Symmetric algorithms (cont.) • Computationally infeasible to determine plaintext from (e.g. intercepted) ciphertext • i.e. supports confidentiality • Typically also gives some degree of integrity • changing the ciphertext will result in essentially random changes to the plaintext, so requires some inherent check in the plaintext, e.g. checksum • May also support authentication and non-repudiation (as holder of secret key) but only with a trusted third-party (e.g. in Kerberos)

15. Symmetric algorithms (cont.) • E.g. Data Encryption Standard (DES) • 56 bit key – known susceptible to brute-force attack (e.g. with custom hardware) • 3DES = 3 successive applications of DES with 2 or 3 different (DES) keys – currently believed strong • Also • AES, Blowfish (correction to text)

16. Symmetric algorithms (cont.) • Pros • Relatively simple • Relatively fast • Cons • Group communication must be done as multiple pair-wise communications each with its own key or other group-members will be able to eavesdrop • Message recipient with the key can forge messages (issue for non-repudiation) • Keys must be securely distributed (!)

17. Asymmetric algorithms (asymmetric ciphers) • Use a pair of related keys: one for encryption and the other for decryption, e.g. “Developing Java web Services”, figure 13.2

18. Asymmetric algorithms (cont.) • E.g. RSA (Rivest-Shamir-Adleman) • Pros • One key (the “public” key) can be freely distributed; only the other key (the “private” key) must be secured and only by one party • Hence “public key cryptography” • Bob only ever needs one public key, e.g. in a group setting • Holder(s) of public key cannot forge messages from private key holder • Can be used in reverse – see digital signatures

19. Asymmetric algorithms (cont.) • Cons • Relatively slow (computationally intensive) • Requires relatively long keys for security (e.g. 1024+ bits) • So… • Often used in combination with secret key cryptography • Asymmetric cipher(s) used to distribute symmetric cipher (secret) keys and/or with message digests • Symmetric ciphers used for bulk data encyrption for performance • E.g. Diffie-Hellman-Merkle key exchange

20. Digital signatures • Relies on “reverse” public key encryption: “Developing Java Web Services”, figure 13.3

21. Digital signatures (cont.) • Asymmetrically encrypting plaintext with the private key can be decrypted by anyone using the public key • I.e. provides evidence that the holder of the private key generated the message • i.e. supports non-repudiation and authentication • Uses message digest • For efficiency – less (fixed size) data to encrypt with slow asymmetric cipher • Leaves the message directly readable

22. Digital signatures (cont.) • Depends on one-way character of digest algorithm • Or intermediary could replace the message with their own bogus message having the same hash • Supports integrity through temper-evidence • hashes would not match if message or signature was changed • E.g. using RSA or DSA (Digital Signature Algorithm)

23. Digital certificates • Describes a binding between • a key (esp. public key) • Information about the key owner • Information about the key issuer • Information about the certificate issuer • E.g. how does Alice know that a particular public key is actually Bob’s?

24. Digital certificates (cont.) • Alice gets Bob’s digital certificate and checks that • It associates a public key with an identity which she knows to be “Bob” • It is valid • e.g. well-formed, in date, signed and not tempered with • It has not been revoked • i.e. declared no longer valid, e.g. because Bob reports that it has been copied from his secure system • She trusts the certificate issuer’s assertion that this is Bob’s key • She can then use the public key

25. Digital certificates (cont.) • Note: typically she will need a certificate for the issuer’s public key to check the signature on Bob’s certificate… • Typically implies a certificate authority hierarchy rooted in one or more explicitly trusted root certificates • e.g. VeriSign, pre-installed with your OS/browser/email client • Alternatively she may obtain the certificate by some means that allows her to trust it directly • E.g. direct physical exchange with Bob • see PGP web of trust

26. XML Encryption • W3C recommendation, December 2002 • http://www.w3.org/TR/xmlenc-core/ • Defines a process for encrypting (any) data and for representing the result in XML • Basis for confidentiality in web services

27. Relationship to SSL/TLS • SSL (Secure Socket Layer)/ TLS (Transport Layer Security) • provides application-to-application encryption over TCP, e.g. in HTTPS • Only encrypts data in transit • Encrypts all data on the connection • Relatively easy to configure using standard HTTPS support • Includes options for authentication

28. Relationship to SSL/TLS (cont.) • XML encryption • Allows only some of the data to be encrypted (e.g. body vs. header) • Allows data to remain encrypted within the application and/or when stored (not just on the network) • Allows establishment of multi-party secure sessions • Separate from authentication (see XML Signature and WS-Security)

29. Use case examples: “Developing Java Web Services”, figure 13.4: eavesdroppers (and perhaps also Sue Co.) have no access to bank details “Developing Java Web Services”, figure 13.5: Bank has not access to detailed order information (which might be confidential)

30. Example: plaintext <?xml version="1.0" encoding="UTF-8" ?> <Transfer_Details> <Accounts> <Source> <Holder_Name> John Smith </Holder_Name> <Number> 1234352 56783341 90234532 </Number> </Source> <Target> … </Target> </Accounts> <Transfer_Amount Currency="USD"> 3000 </Transfer_Amount> </Transfer_Details> “Developing Java Web Services”, listing 13. 1

31. Example: XML encrypted <Accounts> “Developing Java Web Services”, Figure 13.9

32. XML Encryption XML syntax <EncryptedData Id? Type? MimeType? Encoding?> <EncryptionMethod/>? <ds:KeyInfo> <EncryptedKey>? <AgreementMethod>? <ds:KeyName>? <ds:RetrievalMethod>? <ds:*>? </ds:KeyInfo>? <CipherData> <CipherValue>? <CipherReference URI?>? </CipherData> <EncryptionProperties>? </EncryptedData>

33. <EncryptedData> element • Top-level/root element containing encrypted information • Current version namespace: • http://www.w3.org/2001/04/xmlenc# • Attributes: • Id – local name, optional • Type – type information, optional, e.g. “Element” or “Content” for in-line XML element or content • MimeType – MIME type of encoded data, optional

34. <EncryptionMethod> element • Identifies the encryption method used and any additional information (e.g. keys) • Optional – if not present the recipient must already know the method/keys by other means • Attributes: • Algorithm – URI identifying algorithm used, required • keySize, other algorithm-specific parameters – optional

35. <ds:KeyInfo> element • Defined by XML Signature • Namespace http://www.w3.org/2000/09/xmldsig# • Gives information about the key to use • Optional - Key may determined from • <ds:KeyInfo> • From separate key which in turn identifies this EncodedData or • Application context

36. <ds:KeyInfo> element (cont.) • If present then typically contains one of: • <EncryptedKey> element – contains the key but itself encoded by some further method/key • <ds:KeyName> element – identifies the key by (some) name • <ds:RetrievalMethod> element – identifies some way to locate/retrieve the key, e.g. from a separate document • <AgreementMethod> element – identifies an algorithm by which a shared key may be determined

37. <CipherData> element • Contains or references the actual ciphertext via one of • <CipherValue> element – contains base64 encoded ciphertext • <CipherReference> element – gives the URL of the ciphertext • and optionally a sequence of <ds:Transform> elements, specifying e.g. an XPath query, base64 encoding to be performed on the document to obtain the ciphertext

38. Example: XML encrypted <Accounts> “Developing Java Web Services”, Figure 13.9

39. XML Signature • W3C recommendation, Feb. 2002 • http://www.w3.org/TR/xmldsig-core/ • Namespace xmlns="http://www.w3.org/2000/09/xmldsig#" • Provides a mechanism for applying digital signatures to XML documents (and other resources) and encoding those signatures as XML • Basis for message-based authentication, non-repudiation and integrity

40. Types of XML signature (1) • Enveloped – over the XML content that contains the signature as an element • e.g. <doc Id="doc0"> <elem/> <Signature> ... <Reference URI="doc0"/> ... </Signature> </doc> signs “Developing Java Web Services” listing 13.4

41. Types of XML signature (2) • Enveloping – XML signature contains the signed content • E.g. <Signature> ... <Reference URI = "#ID0"/> ... <Object Id="ID0"> <doc/> <elem/> </doc> </Object> </Signature> signs identifies “Developing Java Web Services” listing 13.5

42. Types of XML signature (3) • Detached – signature references the signed content as an external document • E.g. <doc> <Signature> ... <Reference URI="#el1"/> ... </Signature> <elem ID="el1"> … </elem> </doc> <Signature> ... <Reference URI= "http://www...."/> ... </Signature> signs signs http://www... “Developing Java Web Services” listing 13.6

43. XML Signature syntax <Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI? > (<Transforms>)? <DigestMethod> <DigestValue> </Reference>)+ </SignedInfo> <SignatureValue> (<KeyInfo>)? (<Object ID?>)* </Signature>

44. <Signature> element • Parent element of a XML Signature • Attributes • Id – local identifier for signature, optional • Child Elements: • <SignedInfo> - information about what has been signed • <SignatureValue> - the signature itself • <KeyInfo> - information about the key used, optional • <Object> - included information, e.g. content for Enveloping signature, optional

45. <SignedInfo> element • Information about what has been signed and how • Child elements: • <CanonicalizationMethod> - URI identifying the Algorithm used to canonicalise the signed XML • i.e. convert it to a unique form among all possible equivalent forms, e.g. use of entity refs, presence of comments • <SignatureMethod> - URI identifying signature algorithm used

46. <SignedInfo> element (cont.) • <Reference> - one or more references to the content that has been signed • Like XML Encyption <CipherReference> gives the URL of the signed document/element, required • And optionally a sequence of <ds:Transform> elements, specifying e.g. an XPath query, base64 encoding to be performed on the document to obtain the text to be signed • Specifies the digest method applied to the resulting text (<DigestMethod>), required • Gives the (unencrypted) digest value that has been signed (<DigestValue>), required

47. <SignatureValue> element • Base64 encoded signature value

48. <KeyInfo> element • Information about the key(s) used to generate the XML signature • Required to verify the signature • Also used in XML Encryption, above • Optional – key information may be determined in other ways

49. <KeyInfo> element (cont.) • May contain: • Key (<KeyValue>), • Key name (<KeyName>), • certificates (e.g. <X509Data>, <PGPData>), • References to key or certificate (<RetrievalMethod>) • in-band key distribution or key agreement data (e.g. <MgmtInfo> for Diffie-Helman)

50. Validation & Trust • Receiver may delegate KeyInfo checking to a trust engine before accepting as acceptable for signature validation: “Developing Java Web Service”, figure 13.11