eie424 distributed systems and networking programming –part ii

1

EIE424

Distributed Systems and Networking Programming –Part II6. Web Services Security

6. Web Services Security

2

EIE424

Distributed Systems and Networking Programming –Part II6. Web Service Security

References

U.Wahli, G.G. Ochoa, S. Cocasse and M. Muetschard, WebSphere Version 5.1 Web Services Handbook, IBM Redbooks, 2nd Ed, 2004

M. Colan and J. Miller, “Understanding Web Services Security”, http://ibm.com/developerworks/speakers/colan

3

EIE424


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

Bank Teller 2

Network

4

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

EIE424


5

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– 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

EIE424


6

Web server protected by HTTPS

Internet

EIE424


Consider a more complicate Web services-based application: Backend

Application

Web server protected by HTTPS

Backend Application

Web Services Gateway

protected by HTTPS

secure

secure

secure

secure???

Business Partner 1

Business Partner 2

7

EIE424


Even if HTTPS has been used in all Internet connections, the above application still has security and other problems– 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

8

EIE424


Internet

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

Web Services Gateway

protected by HTTPS

secure

secure

secure

Secure

Secure

SOAP message credentials

9

EIE424


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 v1.0 is an OASIS standard as of April 2004 which covers mainly the extension of SOAP messages

10

EIE424


A Brief Review of Core Security Technologies

Common core technologies that are being used for security purpose include– Symmetric encryption– Asymmetric encryption– Hash function and digital signature– XML encryption– XML digital signature

11

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 …

EIE424


Symmetric Encryption

12

EIE424


Secret Key generator

Sender Receiver

Plain text message

Cipher text

message

Plain text message

The same key is used for both encryption

and decryption

13

EIE424


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?

Asymmetric Encryption

14

EIE424


Asymmetric key pair

generator

Sender Receiver

Plain text message

Cipher text

message

Plain text message

Different keys are used for encryption and decryption

15

EIE424


Two common ways of using asymmetric encryption

– 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

16

EIE424


A hybrid approach – Digital Envelope

Asymmetric key pair generator

Sender Receiver

Plain text message

Plain text message

Symmetric key generator Public key

Private key

Digital Envelope

Cipher text

message

17

EIE424


Advantages:– 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, asymmetric encryption, and hash functions

18

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

EIE424


Hash Functions and Digital Signature

19

EIE424


Data Object

Hashing Algorithm

Digest

Private key of transmit entity

Encrypted Digest

Data Object

Send to the receiver

Digital signature

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 huge change in the hash code

20

EIE424


Data Object

Public key of transmit entity

Hashing Algorithm

If the digests match, the

data object is from the right

source

Receive from the sender

21

EIE424


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

22

The XML Encryption standard defines ways to encrypt all or part of an XML document

Encrypted info is replaced with a single <EncryptedData> 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

EIE424


XML Encryption

23

EIE424


An <EncryptedData> element contains the following elements– <EncryptionMethods>

The algorithm used to encrypted the data

– <KeyInfo>Information about the key used to encrypt the data

– <CipherData>Contain the actual encrypted data

W3C XML Encryption specifications were proposed by IBM, Microsoft and Entrust

Currently it is still a W3C recommendation. Details can be found in http://www.w3.org/Encryption

Inside <EncryptedData>

24

EIE424


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– <SignedInfo>

Information about what is signed (such as the algorithm used to generate the digest and the encryption algorithm)

– <SignatureValue>The value of the digital signature itself

– <KeyInfo>The public key used to verify the signature (optional)

Now a W3C recommendation (http://www.w3.org/Signature)

XML Digital Signature

25

<S: Envelope xmlns:S=“http://schemas.xmlsoap.org/soap/envelope/”> <S:Header> <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext”> <wsse:UsernameToken> ... </wsse:UsernameToken> <EncryptedKey xmlns="http://www.w3.org/2001/04/enc-enc-enc#"> ... </EncryptedKey> <Signature xmlns:"http://www.w3.org/2000/09/xmldsig#">

... </Signature> </S:Header>

Basic Syntax of WS-Security

EIE424


Authentication

Confidentiality, adopt XML Encryption

Integrity, adopt XML Digital Signature

Define and use WS-Security namespace

<wsse:Security> is the “container” for security-related info Place in the header means apply to the whole SOAP msg

26

<S:Body> ... <EncryptedData> ... </EncryptedData> </S:Body></S:Envelope>

<S:Body> ... <EncryptedData> ... </EncryptedData> </S:Body></S:Envelope>

Encrypted contents inside the Body can be included in the <EncryptedData> element

EIE424


27

EIE424


WS-Security for Authentication – Security Token

WS-Security defines security tokens, which can contain various requestors’ claims (a declaration made by some entity)– e.g. a username and optional password, an X.506 certificate, or a Kerberos ticket

Basically there are two types of tokens:– UsernameToken and BinarySecurityToken

UsernameToken is the simplest one. Contain a mandatory username and optional password BinarySecurityToken however contains encoded binary data that is suitable for storing X.509 certificate or Kerberos ticket

28

EIE424


<S: Envelope xmlns:S=“http://schemas.xmlsoap.org/soap/envelope/”> <S:Header> <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext” soapenv:mustUnderstand=“1”> <wsse:UsernameToken wsu:ID=“myToken”> <wsse:Username>danielLun</wsse:Username> <wsse:Password>passw0rd</wsse:Password> </wsse:UsernameToken> </wsse:Security> </S:Header> <S:Body> ... </S:Body></S:Envelope>

Requester provides the claim (username and password) to the server for validation. Server must

understand this header or an error should be returned

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

The other part of the message can refer to this UsernameToken with this ID

29

EIE424


<S: Envelope xmlns:S=“http://schemas.xmlsoap.org/soap/envelope/”> <S:Header> <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext” soapenv:mustUnderstand=“1”> <wsse:BinarySecurityToken wsu:ID=“myToken” ValueType=“wsse:Kerberosv5ST” EncodingType=“wsse:Base64Binary> XIFNWZz99UUbalqIEmJZc0 ... </wsse:BinarySecurityToken> </wsse:Security> </S:Header> <S:Body> ... </S:Body></S:Envelope>

Specify that the binary data of Kerberos service ticket

will be encoded using Base64 representation

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

Using Kerberos service ticket

Kerberos ticket or x.509 certificate are also referred as signed security tokens since the data has been

cryptographically signed by a specific authority

30

EIE424


WS-Security for Confidentiality – Using XML Encryption

For WS-Security, there is no intention to create new methods but integrating the existing technologies to achieve security, e.g. XML Encryption <EncryptedKey> element is placed in security header for implementing digital envelope

– <EncryptionMethod> Algorithm for the encryption of the symmetric key– <KeyInfo> Identifier of a public key used for encryption, assume both the client and server understand the meaning of the identifier– <CipherData><CipherValue> Encrypted symmetric key value– <ReferenceList> List of <DataReference> to contents encrypted with this symmetric key

31

EIE424


Asymmetric key pair generator

Sender Receiver

Plain text message

Plain text message

Symmetric key generator Public key

Private key

Digital Envelope

Cipher text

message

32

EIE424


<S: Envelope xmlns:S=“http://schemas.xmlsoap.org/soap/envelope/”> <S:Header> <wsse:Security ...> <EncryptedKey xmlns=“http://www.w3.org/2001/04/xmlenc#”> <EncryptionMethod Algorithm = “http://www.w3.org/2001/04/xmlenc#rsa-1_5”> </EncryptionMethod> <KeyInfo xmlns=“http://www.w3.org/2000/09/xmlsig#”> <wsse:SecurityTokenReference> <wsse:KeyIdentifier>u3AA1M+DMOA1bX/vWJ ... </wsse:KeyIdentifier> </wsse:SecurityTokenReference> </KeyInfo> <CipherData> <CipherValue>cdck0cWh94oF5xBoEm ... </CipherValue> </CipherData> <ReferenceList> <DataReference URI = “#myToken”> </DataReference> </ReferenceList> </EncryptedKey>

Symmetric key is encrypted with RSA-1.5 algorithm using the public key as stated below

The key identifier (not the key itself) of a public key

The encrypted symmetric key

The URI should be referred to when the symmetric key is used by other part of message

33

EIE424


<S:Body> <po xmlns: ...> <wsse:Security ...> <EncryptedData xmlns=“http://www.w3.org/2001/04/xmlenc#” Id=“myToken” Type=“http://www.w3.org/2001/04/xmlenc#Content”> <EncryptionMethod Algorithm = “http://www.w3.org/2001/04/xmlenc#tripledes-cbc”> </EncryptionMethod> <CipherData> <CipherValue>Ew7Zggr8z3 ... </CipherValue> </CipherData> </EncryptedData> <shipTo> <company>The Skateboard Warehouse</company> <street>One Warehouse Park</street> <postalCode>01775</postCode> </shipTo> : </po></S:Body>

Using the symmetric key as mentioned in the header for encrypting this part

The encryption algorithm is triple-DES, a symmetric encryption algorithm

The original data is the credit card info of the customer, but now is replaced by a ciphered code

The less sensitive part is sent to the server without encryption

34

EIE424


WS-Security for Integrity and Non-repudiation – Using XML Digital Signature

Data Object

Hashing Algorithm

Digest

Private key of transmit entity

Encrypted Digest

Data Object

Send to the receiver

Digital signatureDigital signature

35

EIE424


<S: Envelope xmlns:S=“http://schemas.xmlsoap.org/soap/envelope/”> <S:Header> <wsse:Security ...> <wsse:BinarySecurityToken wsu:ID=“myToken” ValueType=“wsse:X509v3” : </wsse:BinarySecurityToken> <Signature xmlns=“http://www.w3.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 myToken ... </Signature> </wsse:Security> </S:Header> <S:Body xmlns:wsu= ... wsu:ID=“body_id”> ... </S:Body></S:Envelope>

• The X.509 certificate contains the public key of the client

• Its private counterpart will be used to encrypt the digest for generating the signature

• The certificate will be sent to server

Namespace for XML Digital Signature which defines the

element <Signature>

36

EIE424


<Signature xmlns=“http://www.w3.org/2000/09/xmldsig#”> <SignedInfo> ... Indicate what is to be signed ... ... A digest of body_id is generated and placed here... ... Define the algorithms used to generate the digest.. : </SignedInfo> <SignatureValue> : ... The actual signature ... ... The digest of <SignedInfo> part will be generated ... and encrypted using the private key as implied ... in <KeyInfo> ... : </SignatureValue> <KeyInfo> : ... Indicate the security token, i.e. myToken in this case, ... which keeps a public key. Its private key counterpart ... will be used for encrypting the digest of <SignedInfo> : </KeyInfo></Signature>

37

EIE424


<KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI=“#myToken”></wsse:Reference> </wsse:SecurityTokenReference> </KeyInfo>

A security token is referring to in <KeyInfo> The URI “myToken” 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

38

EIE424


The target is signed rather indirectly in order to ensure both the target and the <SignedInfo> 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 <SignedInfo> subtree The encrypted digest of the whole <SignedInfo> subtree is then generated and put into <SignatureValue>

<S: Envelope ... > <S:Header> <wsse:Security ...> : <Signature ... > <SignedInfo> : </SignedInfo> <SignatureValue> : </SignatureValue> </Signature> </wsse:Security> </S:Header>

<S:Body...> : </S:Body>

</S:Envelope>

Digest

Encrypted Digest

39

EIE424


Imposer cannot change the target (i.e. Body) unnoticeably since it will not match with the digest in <SignedInfo>

Imposer cannot change the body and the digest in <SignedInfo> together unnoticeably , since it will not match with the digest in <SignatureValue>

Imposer cannot change digest in <SignatureValue> since he does not have the private key

<S: Envelope ... > <S:Header> <wsse:Security ...> : <Signature ... > <SignedInfo> : </SignedInfo> <SignatureValue> : </SignatureValue> </Signature> </wsse:Security> </S:Header>

<S:Body...> : </S:Body>

</S:Envelope>

Digest

Encrypted Digest

40

EIE424


<SignedInfo> <CanonicalizationMethod Algorithm = “http://www.w3.org/2001/10/xml-exc-c14n#”/> <SignatureMethod Algorithm = “http://www.w3.org/2000/09/xmlsig#rsa-sha1”/> <Reference URI=“#body_id”> <Transforms> <Transform Algorithm = “http://w3.org/2001/10/xml-exc-c14n#”/> </Transforms> <DigestMethod Algorithm = “http://www.w3.org/2000/09/xmldsig#sha1”/> <DigestValue>Ojjw8nkT3jJoNN/Axsd ...</DigestValue> </Reference> </SignedInfo>

The <Body> is first transformed using the algorithm EXC-C14N into a canonical form The digest of it is generated using an algorithm SHA1 The digest is stored in <DigestValue> element

41

EIE424


Canonical form XML document

Converting the <SignedInfo> to canonical form before generating its digest can avoid signature mismatch arisen from legitimate alternation of XML header by intermediate servers

Converting the <SignedInfo> to canonical form before generating its digest can avoid signature mismatch arisen from legitimate alternation of XML header by intermediate servers

Two XML documents can be physically different but logically equivalent. E.g. by canonicalization, both<?xml version=“1.0” encoding=“us-ascii”?>

<foo

b=“b”

a=“a”

></foo>

and

<?xml version=“1.0” encoding=“us-ascii”?>

<foo a=“a” b=“b”/>

will be converted into<?xml version=“1.0” encoding=“us-ascii”?>

<foo a=“a” b=“b”></foo>

42

<SignedInfo> <CanonicalizationMethod Algorithm = “http://www.w3.org/2001/10/xml-exc-c14n#”/> <SignatureMethod Algorithm = “http://www.w3.org/2000/09/xmlsig#rsa-sha1”/> <Reference URI=“#body_id”> : </Reference> </SignedInfo>

EIE424


Before generating the digest of <SignedInfo>, it should first be converted into a canonical form using EXC-C14N canonicalization algorithm

The digest of <SignedInfo> is generated using the SHA1 algorithm and encrypted using RSA asymmetric encryption algorithm (hence RSA-SHA1)

43

EIE424


Verification of the Digital SignatureWhen the server receives the signed SOAP message,

it should1. generate the digest of the target (i.e. Body in this case) using the indicated algorithms (EXC-C14N and SHA1)

2. Compare with the one in <SignedInfo>

3. If match, decrypt the signature using the public key given in the security token

4. Extract the <SignedInfo> subtree of the SOAP message

5. Generate the digest of <SignedInfo> using the algorithms indicated (EXC-C14N and SHA1)

6. Compare the generated digest and the one in <SignatureValue>

44

EIE424


WS-Security Implementation in WebSphere

Client WebSphere App Server

Requester App

Provider App

Handler

Request

Response

Deployment Descriptor

Handler

Request

Response

Deployment Descriptor

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

45

EIE424


WebSphere 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– Client’s Request Unit: SOAP request header construction

Security token generation, digital signature generation or content encryption

– Server’s Request Unit: SOAP request header processingValidate security tokens, set up security content, decrypt content or digital signature validation

– Server’s Response Unit: SOAP response header constructionDigital signature generation, content encryption

– Client’s Response Unit: SOAP response header processingDecrypt content and digital signature validation

46

The Roadmap of WS-Security

EIE424


SO

AP

Fou

ndat

ion

Laye

r

WS

-Sec

urity

Lay

erWS-SecureConversation

WS-Federation

WS-Authentication

WS-Policy

WS-Trust

WS-Privacy

Current Standards Specifications in progress

eie424 distributed systems and networking programming –part ii

Documents

security information

security problems

security risks

new security elements

various security measures

existing security technologies

web services handbook

soap messages