Скачать презентацию G 52 IWS Web Service Security Chris Greenhalgh Скачать презентацию G 52 IWS Web Service Security Chris Greenhalgh

9eb53be30eb94a980a2d37c5254789f0.ppt

  • Количество слайдов: 62

G 52 IWS: Web Service Security Chris Greenhalgh 2007 -11 -10 1 G 52 IWS: Web Service Security Chris Greenhalgh 2007 -11 -10 1

Contents • • • Technologies of Web Service security Introduction to cryptography XML encryption 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 – 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… 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. 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 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 • 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 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 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 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 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 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 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) 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 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 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 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 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 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 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 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 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) – 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 – 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 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. 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 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 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 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

John" src="http://present5.com/presentation/9eb53be30eb94a980a2d37c5254789f0/image-30.jpg" alt="Example: plaintext John" /> Example: plaintext John Smith 1234352 56783341 90234532 3000 “Developing Java Web Services”, listing 13. 1 30

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

XML Encryption XML syntax <Encrypted. Data Id? Type? Mime. Type? Encoding? > <Encryption. Method/>? XML Encryption XML syntax ? ? ? ? ? ? ? ? ? ? 32

<Encrypted. Data> element • Top-level/root element containing encrypted information • Current version namespace: – 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. 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 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 – – 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: element (cont. ) • If present then typically contains one of: – element – contains the key but itself encoded by some further method/key – element – identifies the key by (some) name – element – identifies some way to locate/retrieve the key, e. g. from a separate document – 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 – element • Contains or references the actual ciphertext via one of – element – contains base 64 encoded ciphertext – element – gives the URL of the ciphertext • and optionally a sequence of 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 Example: XML encrypted 38 “Developing Java Web Services”, Figure 13. 9

XML Signature • W 3 C recommendation, Feb. 2002 – http: //www. w 3. 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 Types of XML signature (1) • Enveloped – over the XML content that contains the signature as an element – e. g. signs . . . . . . “Developing Java Web Services” listing 13. 4 40

Types of XML signature (2) • Enveloping – XML signature contains the signed content Types of XML signature (2) • Enveloping – XML signature contains the signed content – E. g. . . . . . . signs identifies “Developing Java Web Services” listing 13. 5 41

Types of XML signature (3) • Detached – signature references the signed content as Types of XML signature (3) • Detached – signature references the signed content as an external document – E. g. signs. . . . . . signs http: //www. . . “Developing Java Web Services” listing 13. 6 42

XML Signature syntax <Signature ID? > <Signed. Info> <Canonicalization. Method/> <Signature. Method/> (<Reference URI? XML Signature syntax ( ()? )+ ()? ()* 43

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

<Signed. Info> element • Information about what has been signed and how • Child element • Information about what has been signed and how • Child elements: – - 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 – - URI identifying signature algorithm used 45

<Signed. Info> element (cont. ) – <Reference> - one or more references to the element (cont. ) – - one or more references to the content that has been signed • Like XML Encyption gives the URL of the signed document/element, required • And optionally a sequence of 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 (), required • Gives the (unencrypted) digest value that has been signed (), required 46

<Signature. Value> element • Base 64 encoded signature value 47 element • Base 64 encoded signature value 47

<Key. Info> element • Information about the key(s) used to generate the XML signature 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 element (cont. ) • May contain: – Key (), – Key name (), – certificates (e. g. , ), – References to key or certificate () – in-band key distribution or key agreement data (e. g. for Diffie-Helman) 49

Validation & Trust • Receiver may delegate Key. Info checking to a trust engine 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. element • Included information – Content for Enveloping signature – 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 of in Enveloping signature 51

http: //www. w 3. org/TR/xmldsig-core/ Section 2. 1: Q Original document (detached signature) Document http: //www. w 3. org/TR/xmldsig-core/ Section 2. 1: Q Original document (detached signature) Document [s 01] (to sign) [s 02] [s 03] [s 04] [s 05] [s 06] [s 07] [s 08] [s 09] j 6 lwx 3 rv. EPO 0 v. Kt. Mup 4 Nbe. Vu 8 nk= [s 11] [s 12] [s 13] MC 0 CFFr. VLt. Rlk=. . . Signature [s 14] [s 15 a] [s 15 b] DSA Public [s 15 c]

. . .

. . . . . . . . . key value [s 15 d] (no certificate) [s 15 e] [s 16] 52 [s 17]

Validation & Trust (2) • In the previous example: – Validation = • does 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 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 – 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 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 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. 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 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 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 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 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 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