Web Services Security XML Encryption XML Signature and

Web Services Security XML Encryption, XML Signature and WS-Security 1

Why WS-Security? • Standard signature and encryption techniques can be used to sign and encrypt an XML document. – But these techniques are generally tied to transmission (e. g. , SSL) and don’t protect the document once it arrives. – But document needs to be sent as a whole, and different parts might have different security requirements. • Transmission system can’t be expected to respect these differences • Merchant needs to know customer’s name and address, but not credit card number. 2

Complexity of the Problem • An XML document might contain data describing an entire interaction; however each portion should only be viewed by a particular audience – Personal details of a medical record should not be available to a researcher, doctor should be able to see medical details but not credit card data, some medical details should not be available to administrator. – Different parts of document might have to be signed by different participants – The subsets might intersect, so multiple encryption might be required for certain portions • Should tags be encrypted? – If yes, searching with XPath might be inhibited and security might be compromised (since the plaintext associated with encrypted data can be guessed) 3

WS-Security • A standard set of SOAP extensions that can be used to implement a variety of security models and encryption techniques. – Not itself a protocol – Supports: • Security token (passwords, keys, certificates) transmission • Message integrity • Message encryption – Makes use of other standards: XML Signature, XML Encryption 4

XML Encryption • Example: <payment xmlns=“…”> <name> John Doe </name> <credit. Card type=“visa” limit=“ 5000” > <number> 1234 5678 9012 3456 </number> <issuer> Bank of XY </issuer> <expiration> 04/09 </expi 55 ration> </credit. Card> </payment> 5

XML Encryption • Example: encrypt the credit card element (including tags) – Encrypted element replaces element encrypting an element <payment xmlns=“…”> <name> John Doe </name> <Encrypted. Data Type=“http: //www. w 3. org/2001/04/xmlenc#Element xmlns=“…XML encryption namespace…”> encryption <Encryption. Method Algorithm=“…” /> algorithm <Key. Info xmlns=“…”> <Key. Name> key. ABC </Key. Name> identify key to </Key. Info> receiver <Cipher. Data> <Cipher. Value> AB 12 VY 54321 X …. . </Cipher. Value> </Cipher. Data> encrypted </Encrypted. Data> data </payment> 6

XML Encryption • Type – granularity of encryption – An entire document, or an element (with or without tags) can be encrypted. – Different parts can be encrypted with different keys • Algorithm –algorithm used to encrypt data – Example – DES, RSA • Key. Name – key is known to receiver; just identify it • Cipher. Data – octet stream • The standard provides a number of options that can be used to accommodate a variety of needs 7

XML Encryption – Some Alternatives 1. Symmetrically encrypt data, assume the receiver knows the key and include key name (previous example) 2. Symmetrically encrypt data, include encrypted key in message (encrypted with public key of receiver) (next example) 8

XML Encryption and SOAP • Store encryption key in header, encrypted data is body, an element w/i body, or an attachment • The result of the encryption must be a valid SOAP envelope – Can’t encrypt <s: Envelope>, <s: Header> or <s: Body> elements; only their descendants 9

WS-Security used to attach XML Encryption (2) Encrypted key is stored in header wsse – prefix for WS-Security <s: Header> xenc – prefix for XML Encryption <wsse: Security> ds – prefix for Key. Info element <xenc: Encrypted. Key > <xenc: Encryption. Method Algorithm=“…pub. key algo. to encrypt symmetric key…”/> <ds: Key. Info> <ds: Key. Name> Bill </ds: Key. Name> </ds: Key. Info> Bill’s publ. key optional, <xenc: Cipher. Data> encrypts sym. key receiver <xenc: Cipher. Value>abcd 456…</xenc: Cipher. Value> may know it </xenc: Cipher. Data> encrypted <xenc: Reference. List> symmetric key <xenc: Data. Reference URI=“#Encr. Data” /> </xenc: Reference. List> list of data items </xenc: Encrypted. Key> encrypted with </wsse: Security> symmetric key </s: Header> 10

XML Encryption (2) Encrypted data is stored in body identifies data <s: Body> <xenc: Encrypted. Data Id=“Encr. Data” Type=“http: //www. w 3. org/2001/04/xmlenc#Element /> <xenc: Encryption. Method Algorithm=“…symmetric algo. to encrypt data…” /> <xenc: Cipher. Data> <xenc: Cipher. Value>A 341 BB…</xenc: Cipher. Value> </xenc: Cipher. Data> </xenc: Encrypted. Data> data encrypted </s: Body> with symmetric key 11

XML Signature • An entire document or individual elements can be signed. Allows for the fact that – Different individuals might be responsible for different parts of the message – Some parts of the message should not be changed, others are changeable • The signature is computed in two stages – A digest, using dig_fn 1 , is computed of the data and encapsulated in a <Signed. Info> element – A digest, using dig_fn 2 , is computed of the <Signed. Info> element and signed using the private key of the sender 12

XML Signature <Signature xmlns=“ …XML Signature namespace…”> <Signed. Info> <Canonicalization. Method Algorithm=“ … “/> <Signature. Method Algorithm=“…hash/public key encryption …” /> <Reference URI=“…locate item to be signed …” /> <Digest. Method Algorithm=“ …hash algorithm for item…/> <Digest. Value>xy. T 14 Rst…</Digest. Value> </Reference> digest of </Signed. Info> data <Signature. Value>x. Yzu 2 f. R…. </Signature. Value> </Signature> signature of entire <Signed. Info> element 13

Canonicalization Method • Problem: blank spaces, tabs, line delimiters etc. do not affect the semantics of an XML element, but two different semantically identical elements will have different digests and hence different signatures • Solution: put element into a canonical form before digesting it 14

Transforms 15

Two-Stage Signature Computation • Signature is over <Signed. Info> element (not over the data directly) – Change to data produces change to its <Digest. Value> which produces change to signature of <Signed. Info> • Double digesting does not effect integrity of signature – Technique used to do the signing (but not the signature itself) is signed. • Defends against an attack in which intruder attempts to substitute weaker signature algorithm 16

Key. Info Element • Problem: Suppose the public key corresponding to the private key used to sign <Signed. Info> is not known to the receiver. <Signed. Info> <Canonicalization. Method Algorithm=“ … “/> <Signature. Method Algorithm=“…hash/public key encryption …” /> …. . other children … produced by algorithm </Signed. Info> using a private key <Signature. Value> …. </Signature. Value> <Key. Info> …. </Key. Info> identifies the private key: - a name - a certificate - a corresponding public key 17

Key. Info Element • Problem: Since <Key. Info> is not contained in <Signed. Info> it is not bound by signature to <Signed. Info> – Intruder might substitute a different <Key. Info> element • Solution: use multiple <Reference> elements 18

Multiple Reference Elements <s: Envelope> part of WS<s: Header> Security both Body and <wsse: Security> Key. Info are signed <ds: Signature> <ds: Signed. Info> …. <ds: Reference URI=“#mess”> … </ds: Reference> <ds: Reference URI=“#K”> … </ds: Reference> </ds: Signed. Info> <ds: Signature. Value> … </ds: Signature. Value> <ds: Key. Info Id=“K”> … </ds: Key. Info> </ds: Signature> each Reference </wsse: Security> element contains </s: Header> digest of item <s: Body Id=“mess”> referred to …. </s: Body> </s: Envelope> 19

WS-Security • Defines Security header block as a mechanism for attaching security-related information to a SOAP message and organizing it in a standard way. – Uses the concept of a security token: • Asserts a claim by the sender of security-related information – username, PW, Kerberos ticket, key – Provides a mechanism for referring to security related information that is not in message – Tokens are children of Security header block – Leverages XML Encryption and XML Signature 20

Security Tokens 1. Username token element <Username. Token Id=“…”> <Username> …. </Username> <Password> …. </Password> </Username. Token> 2. Binary security token – an element that carries binary security information <Binary. Security. Token Value. Type=“…. ” -- type of token (e. g. , certificate, ticket) Encoding. Type=“…. ” > -- encoding format Nmg. T 446 C 7…. -- token </Binary. Securuty. Token> 21

Security Tokens 3. Security token reference – a mechanism for referencing tokens not contained in the message <Security. Token. Reference Id=“…” > <Reference URI=“…” /> </Security. Token. Reference> 4. <Key. Info> (part of XML Signature) provides an alternate (more general) mechanism for transmitting information of this type. It can be inserted as a child of Security header block 22

Example WS-Security <s: Header> <wsse: Security> <wsse: Binary. Security. Token Value. Type=“…certificate…” Id=“X 509 Token”> x. Dee 45 Ts. YU…. </wsse: Binary. Security. Token> XML <ds: Signature> token Signature <ds: Signed. Info> <ds: Canonicalization. Method ……/> <ds: Signature. Method …. . /> <ds: Reference URI=“#B”> -- body is signed <ds: Digest. Method …. /> <ds: Digest. Value …. /> </ds: Reference> </ds: Signed. Info> <ds: Signature. Value> afd. Sk. K… </ds: Signature. Value> -- signature <ds: Key. Info> <wsse: Security. Token. Reference> <wsse: Reference URI=“#X 509 Token”/> </wsse: Security. Token. Reference> </ds: Key. Info> </ds: Signature> information about </wsse: Security> key used in the </s: Header> signature is found <s: Body Id=“B”> …. body…. </s: Body> here 23

Security Token 5. Signature – An XML Signature element can be a child of a Security header block • There can be multiple signatures referencing different (perhaps overlapping) components of the message • Example: • • Client signs order. Id header block and body of message and sends to order processing dept Order processing dept adds a shipping. Id header block and signs it and the order. Id header block and sends to billing … 24

Encryption in WS-Security • WS-Security uses XML Encryption in a standard way to encrypt portions of a message Reference. List used as a <s: Header> stand-alone header block; <wsse: Security> lists encrypted items <xenc: Reference. List> <xenc: Data. Reference URI=“#body. Id” /> </xenc: Reference. List> <wsse: Security> </s: Header> <s: Body> each Encrypted. Data <xenc: Encrypted. Data Id=“body. Id” > element in Reference. List <ds: Key. Info> provides its own key info <ds: Key. Name> xyz </ds: Key. Name> </ds: Key. Info> <xenc: Cipher. Data> <xenc: Cipher. Value> … </xenc: Cipher. Value> </xenc: Cipher. Data> xyz is the name associated with the </xenc: Encrypted. Data> symmetric key used to encrypt data 25 </s: Body>