EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Services Security 1
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security References l l 2 U. Wahli, G. G. Ochoa, S. Cocasse and M. Muetschard, Web. Sphere Version 5. 1 Web Services Handbook, IBM Redbooks, 2 nd Ed, 2004 M. Colan and J. Miller, “Understanding Web Services Security”, http: //ibm. com/developerworks/speakers/colan
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security l l Web services security is one of the most important Web services issues Consider the following simple Web services-based application: Bank Data Center Bank Teller 1 3 Bank Teller 2 Network
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security l If no security measure has been applied, the three major risk factors are: – Unauthorized transactions (Authorization) Teller 2 in fact is an imposer sending a SOAP message to the data center to request money withdrawal – Readable messages in clear text (Confidentiality) The account number and balance in the SOAP packet is read by the imposer on the network and he later uses them to withdraw money from that account – SOAP message susceptible to modification (Integrity) The SOAP message is intercepted and modified by the imposer. Money is deposited to another account 4
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security l l With the advance of Internet technology, various security measures have been imposed to protect Web communications The most popular one is HTTPS/SSL which provides “protocol-level” or “transport-level” security – – l 5 Facilitate identification, basic authentication, encryption, and built-in integrity check Provide point-to-point security across one connection The above security risks can be removed by using HTTPS/SSL
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security l Consider a more complicate Web services-based application: Backend Web server protected by HTTPS Business Partner 1 secure Web Services Gateway protected by HTTPS Internet secure Business Partner 2 6 Application Web server protected by HTTPS Backend Application secure? ? ?
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security l Even if HTTPS has been used in all Internet connections, the above application still has security and other problems – – 7 HTTPS provides point-to-point security only. Hence the security after the Web server is not guaranteed (need end-to-end security) Business Partner 1 can deny the messages it sent to Business Partner 2 since there is no proof about the originator of the messages (need non-repudiation) There is no record of all transactions so there is no way to look for security problems after the fact (need auditing) Since all incoming and outgoing messages need to encrypt, demand much CPU time from all servers
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security l l A message level security measure is required to provide not only point-to-point security but end-to-end security Can be achieved by embedding security information in the SOAP message itself SOAP message credentials secure Web Services Gateway protected by HTTPS Internet secure Secure 8 Secure
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security l l l 9 To ensure interoperability, a standard to define new security elements in SOAP messages is needed WS-Security specification covers a standard set of SOAP extensions that can be used when building secure Web services It defines how to use and build upon existing security technologies (e. g. PKI, Kerberos, SSL, XML encryption, XML Digital Signature, etc. ) for Web services WS-Security specification was formalized in April 2002 More specifications have been added and consolidated by the OASIS consortium, a non-profit organization that drives the development of e-business standards WS-Security v 1. 0 is an OASIS standard as of April 2004 which covers mainly the extension of SOAP messages
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security A Brief Review of Core Security Technologies l Common core technologies that are being used for security purpose include – – – 10 Symmetric encryption Asymmetric encryption Hash function and digital signature XML encryption XML digital signature
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security Symmetric Encryption l l l 11 l Encryption – convert the data concerned into another form based on a key. Without the key, the data cannot be converted back to the original form Symmetric – the same algorithm and key are used for both encryption and decryption (except for a slight rearrangement of the key) Advantage – fast (compare with asymmetric algorithms) Drawback – both encryption and decryption keys must remain secret Interesting problem – how do you send your key to your partner securely? Common symmetric encryption algorithms, DES, AES …
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security Sender Plain text message The same key is used for both encryption and decryption 12 Receiver Cipher text message Secret Key generator Plain text message
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security Asymmetric Encryption l l l 13 Asymmetric Encryption – different keys will be used for encryption and decryption Usually one key is made known to public, the other key is kept secret Advantage – solve the problem of distributing the key Drawback – slower than symmetric algorithm The most common asymmetric encryption algorithm, RSA, which is named after the three inventors, R. Rivest, A. Shamir and L. Adleman Its security is based on the intractability of the factorization of large integers – what are the two factors of the number 8876044532898802067?
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security Sender Plain text message Receiver Cipher text message Asymmetric key pair generator 14 Different keys are used for encryption and decryption Plain text message
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security l Two common ways of using asymmetric encryption – – 15 Sender: public key. Receiver: private key To ensure the encrypted message (using the public key) can only be seen by a particular receiver (decrypted using the private key) Sender: private key. Sender: public key If a recipient successfully decrypts a message encrypted with our public key, they know this message is sent by me Hence can be used for identifying the originator of the message
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security A hybrid approach – Digital Envelope Sender Receiver Cipher text message Plain text message Digital Envelope Private key 16 Symmetric key generator Public key Asymmetric key pair generator
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security l Advantages: – – l l 17 Fast, since asymmetric encryption is applied only to a key, which is usually not so long in length Secure, since we don’t need to send the symmetric key thru the network to the sender or receiver SSL is an example that uses the above hybrid approach Most of the security issues are solved with protocols based on combinations of symmetric encryption, and hash functions
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security Hash Functions and Digital Signature l l l 18 l To ensure data integrity, an identifier needs to be sent with sender’s data to proof that the data have not been changed during transmission To achieve non-repudiation, the identifier should further proof the source who generates the identifier Based on the digital signature technique, a hash, or “digest" of the transmitted data is extracted and encrypted by a private key The receiver extracts the encrypted digest and decrypted by a public key The receiver uses the same algorithm to generate the digest of the data object & compare with the encrypted one If they match, the data object is from the right source
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security Data Object Digital signature Digest Hashing Algorithm Encrypted Digest Data Object Send to the receiver Private key of transmit entity Two important properties of the digest: • Given an input stream and its hash code, it is practically impossible to find a second stream with the same hash code • A small change to the original input stream produces a 19 huge change in the hash code
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security Data Object Hashing Algorithm Receive from the sender Public key of transmit entity 20 If the digests match, the data object is from the right source
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security l l l 21 Data integrity is ensured because if an attacker modifies the data object, the digests will not match If an attacker tries to modify the data object as well as the digest, he will still fail because the attacker does not know the private key Non-repudiation is achieved because if the receiver can decrypt the digest, the digest must be sent from the right source In the above case, the data object is not encrypted. Anybody can read it If the data object itself is considered as confidential, data encipherment can be applied to further encrypt the data object
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security XML Encryption l l 22 The XML Encryption standard defines ways to encrypt all or part of an XML document Encrypted info is replaced with a single <Encrypted. Data> element Allow encrypting different parts of the same document with different keys Allow encrypting the whole document, a single element, or just the text of an element
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security Inside <Encrypted. Data> l An <Encrypted. Data> element contains the following elements – <Encryption. Methods> The algorithm used to encrypted the data – <Key. Info> Information about the key used to encrypt the data – <Cipher. Data> Contain the actual encrypted data l l 23 W 3 C XML Encryption specifications were proposed by IBM, Microsoft and Entrust Currently it is still a W 3 C recommendation. Details can be found in http: //www. w 3. org/Encryption
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security XML Digital Signature l l The XML Digital Signature standard defines rules for creating a digital signature and storing that signature inside an XML document The <Signature> element has 3 main parts – <Signed. Info> Information about what is signed (such as the algorithm used to generate the digest and the encryption algorithm) – <Signature. Value> The value of the digital signature itself – <Key. Info> The public key used to verify the signature (optional) l 24 Now a W 3 C recommendation (http: //www. w 3. org/Signature)
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security Basic Syntax of WS-Security l <wsse: Security> is the “container” for security-related info l Place in the header means apply to the whole SOAP msg <S: Envelope xmlns: S=“http: //schemas. xmlsoap. org/soap/envelope/”> <S: Header> Define and use WS-Security namespace <wsse: Security xmlns: wsse="http: //schemas. xmlsoap. org/ws/2003/06/secext”> <wsse: Username. Token>. . . Authentication </wsse: Username. Token> <Encrypted. Key xmlns="http: //www. w 3. org/2001/04/enc-enc#">. . . Confidentiality, adopt XML Encryption </Encrypted. Key> <Signature xmlns: "http: //www. w 3. org/2000/09/xmldsig#">. . . Integrity, adopt XML Digital Signature </Signature> 25 </S: Header>
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security Encrypted contents inside the Body can be included in the <Encrypted. Data> element <S: Body>. . . <Encrypted. Data>. . . </Encrypted. Data> </S: Body> </S: Envelope> 26
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security WS-Security for Authentication – Security Token l WS-Security defines security tokens, which can contain various requestors’ claims (a declaration made by some entity) – l Basically there are two types of tokens: – l l 27 e. g. a username and optional password, an X. 506 certificate, or a Kerberos ticket Username. Token and Binary. Security. Token Username. Token is the simplest one. Contain a mandatory username and optional password Binary. Security. Token however contains encoded binary data that is suitable for storing X. 509 certificate or Kerberos ticket
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security <S: Envelope xmlns: S=“http: //schemas. xmlsoap. org/soap/envelope/”> The other part of the message can refer to this <S: Header> <wsse: Security Username. Token with this ID xmlns: wsse="http: //schemas. xmlsoap. org/ws/2003/06/secext” soapenv: must. Understand=“ 1”> <wsse: Username. Token wsu: ID=“my. Token”> <wsse: Username>daniel. Lun</wsse: Username> <wsse: Password>passw 0 rd</wsse: Password> </wsse: Username. Token> </wsse: Security> </S: Header> Requester provides the claim (username and <S: Body> password) to the server for validation. Server must. . . understand this header or an error should be returned </S: Body> </S: Envelope> l 28 l Sending username and password in this way is obviously not secure. Need to be used with WS-Security encryption to hide away both username and password
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security <S: Envelope xmlns: S=“http: //schemas. xmlsoap. org/soap/envelope/”> <S: Header> Using Kerberos service ticket <wsse: Security xmlns: wsse="http: //schemas. xmlsoap. org/ws/2003/06/secext” soapenv: must. Understand=“ 1”> <wsse: Binary. Security. Token wsu: ID=“my. Token” Value. Type=“wsse: Kerberosv 5 ST” Encoding. Type=“wsse: Base 64 Binary> Specify that the binary data XIFNWZz 99 UUbalq. IEm. JZc 0. . . of Kerberos service ticket </wsse: Binary. Security. Token> will be encoded using </wsse: Security> Base 64 representation </S: Header> <S: Body> Kerberos ticket or x. 509 certificate are also referred as. . . signed security tokens since the data has been </S: Body> cryptographically signed by a specific authority </S: Envelope> l 29 Since any third party can take the ticket or certificate and include in their application, the ticket or certificate alone cannot serve as proof of possession
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security WS-Security for Confidentiality – Using XML Encryption l l For WS-Security, there is no intention to create new methods but integrating the existing technologies to achieve security, e. g. XML Encryption <Encrypted. Key> element is placed in security header for implementing digital envelope – – 30 <Encryption. Method> Algorithm for the encryption of the symmetric key <Key. Info> Identifier of a public key used for encryption, assume both the client and server understand the meaning of the identifier <Cipher. Data><Cipher. Value> Encrypted symmetric key value <Reference. List> List of <Data. Reference> to contents encrypted with this symmetric key
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security Sender Receiver Cipher text message Plain text message Digital Envelope Private key Symmetric key generator 31 Public key Asymmetric key pair generator
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security <S: Envelope xmlns: S=“http: //schemas. xmlsoap. org/soap/envelope/”> <S: Header> Symmetric key is encrypted with RSA-1. 5 <wsse: Security. . . > algorithm using the public key as stated below <Encrypted. Key xmlns=“http: //www. w 3. org/2001/04/xmlenc#”> <Encryption. Method Algorithm = “http: //www. w 3. org/2001/04/xmlenc#rsa-1_5”> </Encryption. Method> <Key. Info xmlns=“http: //www. w 3. org/2000/09/xmlsig#”> <wsse: Security. Token. Reference> <wsse: Key. Identifier>u 3 AA 1 M+DMOA 1 b. X/v. WJ. . . </wsse: Key. Identifier> </wsse: Security. Token. Reference> The key identifier (not the key itself) of a public key </Key. Info> <Cipher. Data> <Cipher. Value>cdck 0 c. Wh 94 o. F 5 x. Bo. Em. . . </Cipher. Value> </Cipher. Data> The encrypted symmetric key <Reference. List> <Data. Reference URI = “#my. Token”> </Data. Reference> The URI should be referred to when the </Reference. List> symmetric key is used by other part of message 32 </Encrypted. Key>
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security <S: Body> Using the symmetric key as mentioned in the <po xmlns: . . . > header for encrypting this part <wsse: Security. . . > <Encrypted. Data xmlns=“http: //www. w 3. org/2001/04/xmlenc#” Id=“my. Token” Type=“http: //www. w 3. org/2001/04/xmlenc#Content”> <Encryption. Method Algorithm = “http: //www. w 3. org/2001/04/xmlenc#tripledes-cbc”> </Encryption. Method> The encryption algorithm is triple-DES, a <Cipher. Data> symmetric encryption algorithm <Cipher. Value>Ew 7 Zggr 8 z 3. . . </Cipher. Value> </Cipher. Data> The original data is the credit card info of the </Encrypted. Data> customer, but now is replaced by a ciphered code <ship. To> <company>The Skateboard Warehouse</company> <street>One Warehouse Park</street> <postal. Code>01775</post. Code> </ship. To> : The less sensitive part is sent to the server without </po> encryption 33 </S: Body>
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security WS-Security for Integrity and Nonrepudiation – Using XML Digital Signature Data Object Digital signature Digest Hashing Algorithm 34 Encrypted Digest Private key of transmit entity Data Object Send to the receiver
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security <S: Envelope xmlns: S=“http: //schemas. xmlsoap. org/soap/envelope/”> <S: Header> <wsse: Security. . . > <wsse: Binary. Security. Token wsu: ID=“my. Token” Value. Type=“wsse: X 509 v 3” Namespace for XML Digital : Signature which defines the </wsse: Binary. Security. Token> element <Signature> <Signature xmlns=“http: //www. w 3. org/2000/09/xmldsig#”>. . . XML Digital Signature of body_id is placed here. . . It is encrypted with a private key of which its. . . public key counterpart is indicated in my. Token. . . </Signature> </wsse: Security> • The X. 509 certificate contains the </S: Header> public key of the client <S: Body xmlns: wsu=. . . • Its private counterpart will be used to wsu: ID=“body_id”>. . . encrypt the digest for generating the </S: Body> signature </S: Envelope> 35 • The certificate will be sent to server
EIE 424 <Signature xmlns=“http: //www. w 3. org/2000/09/xmldsig#”> Distributed Systems and Networking Programming –Part II <Signed. Info> 6. Web Service Security. . . Indicate what is to be signed. . . A digest of body_id is generated and placed here. . . Define the algorithms used to generate the digest. . : </Signed. Info> <Signature. Value> : . . . The actual signature. . . The digest of <Signed. Info> part will be generated. . . and encrypted using the private key as implied. . . in <Key. Info>. . . : </Signature. Value> <Key. Info> : . . . Indicate the security token, i. e. my. Token in this case, . . . which keeps a public key. Its private key counterpart. . . will be used for encrypting the digest of <Signed. Info> : </Key. Info> </Signature> 36
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security <Key. Info> <wsse: Security. Token. Reference> <wsse: Reference URI=“#my. Token”></wsse: Reference> </wsse: Security. Token. Reference> </Key. Info> l l 37 A security token is referring to in <Key. Info> The URI “my. Token” indicates that the X. 509 certificate defined at the beginning of SOAP message will be used X. 509 certificate contains much information about its owner, one of them is the public key Its private key counterpart will be used to encrypt the digest
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security l l The target is signed rather indirectly in order to ensure both the target and the <Signed. Info> subtree will not be altered unnoticeably by the imposer A digest of the target (i. e. the Body in this case) is generated and put into the <Signed. Info> subtree The encrypted digest of the whole <Signed. Info> subtree is then generated and put into 38 <Signature. Value> l <S: Envelope. . . > <S: Header> <wsse: Security. . . > : Encrypted <Signature. . . > Digest <Signed. Info> : </Signed. Info> <Signature. Value> : </Signature. Value> </Signature> </wsse: Security> </S: Header> <S: Body. . . > : </S: Body> </S: Envelope> Digest
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security l l <S: Envelope. . . > Imposer cannot change the <S: Header> target (i. e. Body) <wsse: Security. . . > unnoticeably since it will not : Encrypted <Signature. . . > match with the digest in Digest <Signed. Info> Imposer cannot change the body and the digest in <Signed. Info> together unnoticeably , since it will not match with the digest in <Signature. Value> Imposer cannot change digest in <Signature. Value> since he does not have the 39 private key l : </Signed. Info> <Signature. Value> : </Signature. Value> </Signature> </wsse: Security> </S: Header> <S: Body. . . > : </S: Body> </S: Envelope> Digest
EIE 424 Distributed Systems and Networking Programming –Part II <Signed. Info> 6. Web Service Security <Canonicalization. Method Algorithm = “http: //www. w 3. org/2001/10/xml-exc-c 14 n#”/> <Signature. Method Algorithm = “http: //www. w 3. org/2000/09/xmlsig#rsa-sha 1”/> <Reference URI=“#body_id”> <Transforms> <Transform Algorithm = “http: //w 3. org/2001/10/xml-exc-c 14 n#”/> </Transforms> <Digest. Method Algorithm = “http: //www. w 3. org/2000/09/xmldsig#sha 1”/> <Digest. Value>Ojjw 8 nk. T 3 j. Jo. NN/Axsd. . . </Digest. Value> </Reference> </Signed. Info> l l 40 l The <Body> is first transformed using the algorithm EXC-C 14 N into a canonical form The digest of it is generated using an algorithm SHA 1 The digest is stored in <Digest. Value> element
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security Canonical form XML document l Two XML documents can be physically different but logically equivalent. E. g. by canonicalization, both <? xml version=“ 1. 0” encoding=“us-ascii”? > <foo Converting the <Signed. Info> to canonical b=“b” form before generating its digest can avoid signature mismatch arisen from legitimate a=“a” alternation of XML header by intermediate ></foo> servers and <? xml version=“ 1. 0” encoding=“us-ascii”? > <foo a=“a” b=“b”/> will be converted into 41 <? xml version=“ 1. 0” encoding=“us-ascii”? > <foo a=“a” b=“b”></foo>
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security <Signed. Info> <Canonicalization. Method Algorithm = “http: //www. w 3. org/2001/10/xml-exc-c 14 n#”/> <Signature. Method Algorithm = “http: //www. w 3. org/2000/09/xmlsig#rsa-sha 1”/> <Reference URI=“#body_id”> : </Reference> </Signed. Info> l l 42 Before generating the digest of <Signed. Info>, it should first be converted into a canonical form using EXC-C 14 N canonicalization algorithm The digest of <Signed. Info> is generated using the SHA 1 algorithm and encrypted using RSA asymmetric encryption algorithm (hence RSASHA 1)
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security Verification of the Digital Signature When the server receives the signed SOAP message, it should 1. 2. 3. 4. 5. 6. 43 generate the digest of the target (i. e. Body in this case) using the indicated algorithms (EXC-C 14 N and SHA 1) Compare with the one in <Signed. Info> If match, decrypt the signature using the public key given in the security token Extract the <Signed. Info> subtree of the SOAP message Generate the digest of <Signed. Info> using the algorithms indicated (EXC-C 14 N and SHA 1) Compare the generated digest and the one in <Signature. Value>
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security WS-Security Implementation in Web. Sphere Request Response Handler Requester App Handler Deployment Descriptor Client l l l 44 Provider App Web. Sphere App Server The security functions required in the handlers are defined in the respective Deployment Descriptor No need to add or change any code in the Java source Allow a security manager to control and change all security options without interfering with developer tasks
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security l l Web. Sphere Studio makes it easy to add WS-Security to a Web service Security Handler module can be added to contains the code for Web Service Security functions – – Server’s Request Unit: SOAP request header processing Validate security tokens, set up security content, decrypt content or digital signature validation – Server’s Response Unit: SOAP response header construction Digital signature generation, content encryption – 45 Client’s Request Unit: SOAP request header construction Security token generation, digital signature generation or content encryption Client’s Response Unit: SOAP response header processing Decrypt content and digital signature validation
EIE 424 Distributed Systems and Networking Programming –Part II 6. Web Service Security 46 WS-Security Layer SOAP Foundation Layer The Roadmap of WS-Security Current Standards WS-Secure. Conversation WS-Federation WS-Authentication WS-Policy WS-Trust WS-Privacy Specifications in progress
Скачать презентацию EIE 424 Distributed Systems and Networking Programming Part
a1c4844b671cf003fd5c2e6e42d2d1f0.ppt