G 52 IWS: Web Service Security Chris Greenhalgh 2007 -11 -10 1
Contents • • • Technologies of Web Service security Introduction to cryptography XML encryption XML signatures Other standards See “Developing Java Web Services”, chapter 13 (part) 2
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 3
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 4
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 5
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 6
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 7
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 8
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 9
Cryptography algorithms & other building blocks • • • One-way hash functions Symmetric algorithms Asymmetric algorithms Digital signatures Digital certificates 10
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. – MD 4 (Message Digest 4, 128 bit hash), MD 5, – SHA (Secure Hash Algorithm, 160 bit hash) 11
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 12
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 13
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 nonrepudiation (as holder of secret key) but only with a trusted third-party (e. g. in Kerberos) 14
Symmetric algorithms (cont. ) • E. g. Data Encryption Standard (DES) – 56 bit key – known susceptible to brute-force attack (e. g. with custom hardware) – 3 DES = 3 successive applications of DES with 2 or 3 different (DES) keys – currently believed strong • Also – AES, Blowfish (correction to text) 15
Symmetric algorithms (cont. ) • Pros – Relatively simple – Relatively fast • Cons – Group communication must be done as multiple pairwise 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 (!) 16
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 17
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 18
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 19
Digital signatures • Relies on “reverse” public key encryption: “Developing Java Web Services”, figure 13. 3 20
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 21
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) 22
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? 23
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 24
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. Veri. Sign, 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 25
XML Encryption • W 3 C recommendation, December 2002 – http: //www. w 3. org/TR/xmlenc-core/ • Defines a process for encrypting (any) data and for representing the result in XML • Basis for confidentiality in web services 26
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 27
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) 28
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) 29
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 30
Example: XML encrypted <Accounts> 31 “Developing Java Web Services”, Figure 13. 9
XML Encryption XML syntax <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> 32
<Encrypted. Data> element • Top-level/root element containing encrypted information • Current version namespace: – http: //www. w 3. 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 – Mime. Type – MIME type of encoded data, optional 33
<Encryption. Method> element • Identifies the encryption method used 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 – key. Size, other algorithm-specific parameters – optional 34
<ds: Key. Info> element • Defined by XML Signature – Namespace http: //www. w 3. org/2000/09/xmldsig# • Gives information about the key to use • Optional - Key may determined from – <ds: Key. Info> – From separate key which in turn identifies this Encoded. Data or – Application context 35
<ds: Key. Info> element (cont. ) • If present then typically contains one of: – <Encrypted. Key> element – contains the key but itself encoded by some further method/key – <ds: Key. Name> element – identifies the key by (some) name – <ds: Retrieval. Method> element – identifies some way to locate/retrieve the key, e. g. from a separate document – <Agreement. Method> element – identifies an algorithm by which a shared key may be determined 36
<Cipher. Data> element • Contains or references the actual ciphertext via one of – <Cipher. Value> element – contains base 64 encoded ciphertext – <Cipher. Reference> element – gives the URL of the ciphertext • and optionally a sequence of <ds: Transform> elements, specifying e. g. an XPath query, base 64 encoding to be performed on the document to obtain the ciphertext 37
Example: XML encrypted <Accounts> 38 “Developing Java Web Services”, Figure 13. 9
XML Signature • W 3 C recommendation, Feb. 2002 – http: //www. w 3. org/TR/xmldsig-core/ – Namespace xmlns="http: //www. w 3. 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, nonrepudiation and integrity 39
Types of XML signature (1) • Enveloped – over the XML content that contains the signature as an element – e. g. <doc Id="doc 0"> <elem/> signs <Signature>. . . <Reference URI="doc 0"/>. . . </Signature> </doc> “Developing Java Web Services” listing 13. 4 40
Types of XML signature (2) • Enveloping – XML signature contains the signed content – E. g. <Signature> . . . <Reference URI = "#ID 0"/>. . . signs identifies <Object Id="ID 0"> <doc/> <elem/> </doc> </Object> </Signature> “Developing Java Web Services” listing 13. 5 41
Types of XML signature (3) • Detached – signature references the signed content as an external document – E. g. <doc> <Signature> signs. . . <Reference URI="#el 1"/> <Reference URI=. . . "http: //www. . "/> </Signature>. . . <elem ID="el 1"> … </elem> </Signature> </doc> signs http: //www. . . “Developing Java Web Services” listing 13. 6 42
XML Signature syntax <Signature ID? > <Signed. Info> <Canonicalization. Method/> <Signature. Method/> (<Reference URI? > (<Transforms>)? <Digest. Method> <Digest. Value> </Reference>)+ </Signed. Info> <Signature. Value> (<Key. Info>)? (<Object ID? >)* </Signature> 43
<Signature> element • Parent element of a XML Signature • Attributes – Id – local identifier for signature, optional • Child Elements: – <Signed. Info> - information about what has been signed – <Signature. Value> - the signature itself – <Key. Info> - information about the key used, optional – <Object> - included information, e. g. content for Enveloping signature, optional 44
<Signed. Info> element • Information about what has been signed and how • Child elements: – <Canonicalization. Method> - 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 – <Signature. Method> - URI identifying signature algorithm used 45
<Signed. Info> element (cont. ) – <Reference> - one or more references to the content that has been signed • Like XML Encyption <Cipher. Reference> gives the URL of the signed document/element, required • And optionally a sequence of <ds: Transform> elements, specifying e. g. an XPath query, base 64 encoding to be performed on the document to obtain the text to be signed • Specifies the digest method applied to the resulting text (<Digest. Method>), required • Gives the (unencrypted) digest value that has been signed (<Digest. Value>), required 46
<Signature. Value> element • Base 64 encoded signature value 47
<Key. Info> 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 48
<Key. Info> element (cont. ) • May contain: – Key (<Key. Value>), – Key name (<Key. Name>), – certificates (e. g. <X 509 Data>, <PGPData>), – References to key or certificate (<Retrieval. Method>) – in-band key distribution or key agreement data (e. g. <Mgmt. Info> for Diffie-Helman) 49
Validation & Trust • Receiver may delegate Key. Info checking to a trust engine before accepting as acceptable for signature validation: “Developing Java Web Service”, figure 13. 11 50
<Object> element • Included information – Content for Enveloping signature – <Signature. Properties> e. g. date of signing – optional • Attributes – Encoding – identify encoding used, e. g. base 64 – Mime. Type – MIME type of data, optional – ID – local identity, e. g. for use in <Reference> of <Signed. Info> in Enveloping signature 51
http: //www. w 3. org/TR/xmldsig-core/ Section 2. 1: Q Original document (detached signature) Document [s 01] <Signature Id="My. First. Signature“ Digest xmlns="http: //www. w 3. org/2000/09/xmldsig#"> (to sign) [s 02] <Signed. Info> [s 03] <Canonicalization. Method Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315"/> [s 04] <Signature. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#dsa-sha 1"/> [s 05] <Reference URI="http: //www. w 3. org/TR/2000/REC-xhtml 1 -20000126/"> [s 06] <Transforms> [s 07] <Transform Algorithm="http: //www. w 3. org/TR/2001/REC-xml-c 14 n-20010315"/> [s 08] </Transforms> [s 09] <Digest. Method Algorithm="http: //www. w 3. org/2000/09/xmldsig#sha 1"/ [s 10] <Digest. Value>j 6 lwx 3 rv. EPO 0 v. Kt. Mup 4 Nbe. Vu 8 nk=</Digest. Value> [s 11] </Reference> [s 12] </Signed. Info> [s 13] <Signature. Value>MC 0 CFFr. VLt. Rlk=. . . </Signature. Value> Signature [s 14] <Key. Info> [s 15 a] <Key. Value> [s 15 b] <DSAKey. Value> DSA Public [s 15 c] <P>. . . </P><Q>. . . </Q><G>. . . </G><Y>. . . </Y> key value [s 15 d] </DSAKey. Value> (no certificate) [s 15 e] </Key. Value> [s 16] </Key. Info> 52 [s 17] </Signature>
Validation & Trust (2) • In the previous example: – Validation = • does the application of the specific transforms, canonicalisation and digest function to the specified document yield the same digest value • And does the decryption of the signature value using the identified (public or secret) key match this – Of course, a secret key would not be present by value ; -) – Trust = • Do we accept the identified (public or secret) key for the purposes of accepting this signature, – e. g. are we confident that it is the public key of a party whose signature we would accept and that it has not been compromised 53
Other standards: XML Key Management Specification (XKMS) • Defines services for: – Obtaining and registering private keys – Revoking private keys • e. g. if believed compromised – Recovering lost private keys – Locating public keys • E. g. from <ds: Key. Name> – Validating information linked to public keys • E. g. identity of the owner of a public key in some security domain 54
XML Key Registration Services Specification (X-KRSS) XKMS XML Key Information Services Specification (X-KISS) Trusted Trust service (!) “Developing Java Web Services”, figure 13. 15 55
Other standards: Security Assertions Markup Language (SAML) • OASIS standard • Allows standardised exchange of securityrelated information between organisations • E. g. – Single sign-on – Back-office transactions 56
SAML scenario examples Single Sign-on Back-office transaction 57 “Developing Java Web Services”, figure 13. 17 & 13. 18
Single sign-on example interactions Common reference Note: 1. Who is the user? 2. Do I trust you to make this assertion? “Developing Java Web Services”, figure 13. 21 58
Other standards: XML Access Control Markup Language (XACML) • OASIS standard • Specifies authorisation and entitlement (e. g. access control) policies – For XML documents • or things that can be referenced like XML documents – In XML 59
XACML (cont. ) • Policies are expressed as tuples: – Object – thing acted on – Subject – party requesting/performing action – Action – what is being done – Condition – additional constraints, checks or actions • May be based on information communicated using SAML 60
Other standards: WS-Security • OASIS standard – WS-Security 1. 1, Feb 2006 • Specifies enhancements to SOAP messaging for – Integrity, based on XML Signature – Confidentiality, based on XML Encryption – Associating security tokens with messages (e. g. for authenication) 61
Conclusions • Security is very important – At least where businesses & money are involved • It is also surprisingly difficult & complicated – E. g. often there is a trade-off between security and end-user ease-of-use • Company security is multi-faceted, but typically physical and network-based (e. g. firewall) • However web services are inter-organisational! – Hence extensive use of cryptography & protocols 62
Скачать презентацию G 52 IWS Web Service Security Chris Greenhalgh
9eb53be30eb94a980a2d37c5254789f0.ppt