1 / 62

G52IWS: Web Service Security

G52IWS: Web Service Security. Chris Greenhalgh 2007-11-10. Contents. Technologies of Web Service security Introduction to cryptography XML encryption XML signatures Other standards. See “Developing Java Web Services”, chapter 13 (part). Challenges for web service security.

esherri
Télécharger la présentation

G52IWS: Web Service Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related