Web Services Security

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

W3C

Security?

Bank Data Center

Bank Teller 1

Bank Teller 2

Network

Major Risks

• 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

Security Measures HTTPS/SSL

• provides “protocol-level” or “transport-level” security • Most popular• Facilitate identification, basic authentication, encryption, and built-

in integrity check• Provide point-to-point security across one connection

• Removes all the above security risks

Security? A more complicated application.

Web server protected by HTTPS

Internet

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

Security? A more complicated application. (2)• 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 sent by 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

end-to-end security

InternetWeb Services Gateway

protected by HTTPS

secure

secure

secure

Secure

Secure

SOAP message credentials

WS-Security

• standard set of SOAP extensions that can be used when building secure Web services

• defines how to use and build upon existing security technologies (e.g. PKI, Kerberos, SSL, XML encryption, XML Digital Signature, etc.) for Web services

• formalized in April 2002• WS-Security v1.1 is an OASIS standard as of 2006

• covers mainly the extension of SOAP messages

Core Security Technologies

• Symmetric encryption• Asymmetric encryption• Hash function and digital signature• XML encryption• XML digital signature

10

Secret Key generator

Sender Receiver

Plain text message

Cipher text

message

Plain text message

The same key is used for both encryption

and decryption

Symmetric

Symmetric

• Encryption – convert the data concerned into another form based on a key.

• 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 …

Asymmetric key pair

generator

Sender Receiver

Plain text message

Cipher text

message

Plain text message

Different keys are used for encryption and decryption

Asymmetric

Asymmetric

• different keys will be used for encryption and decryption• Usually one key is made known to public, the other key is kept secret• Advantage – solves the problem of distributing the key• Drawback – slower than symmetric algorithm• The most common algorithm, RSA, • Based on the intractability of the factorization of large integers –

what are the two factors of the number 8876044532898802067?

Using Asymmetric Encryption

• Sender: public key. Receiver: private keyTo 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 keyIf a recipient successfully decrypts a message encrypted with our public key, they know this message is sent by meHence can be used for identifying the originator of the message

Asymmetric key pair generator

Sender Receiver

Plain text message

Plain text message

Symmetric key generator Public key

Private key

Digital Envelope

Cipher text

message

Hybrid

Hybrid

• Advantages:• Fast, asymmetric encryption applied only to a (usually not so long in length) key• Secure, we don’t need to send the symmetric key thru the network to the

sender or receiver

• SSL 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

Hash Functions and Digital Signature• 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

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

Data Object

Hashing Algorithm

Digest

Private key of transmit entity

Encrypted Digest

Data Object

Send to the receiver

Digital signature

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

Digest

Digest

• 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

• 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

XML Encryption

• Standard that 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

<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

• Details in http://www.w3.org/Encryption

XML Digital Signature

• Standard that defines rules for creating a digital signature and storing that signature inside an XML document

• <Signature> element has 3 main parts• <SignedInfo> Information about what is signed (e.g. 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)

• Details in http://www.w3.org/Singnature

Basic Syntax of WS-SecurityPl

ace i

n th

e hea

der

mea

ns ap

ply t

o who

le

SOAP

msg

Define and use WS-Security namespace

Authentication

Confidentiality, adopt XML Encryption

Integrity, adopt XML Digital Signature

<EncryptedData> element

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

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

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• Basic types of tokens:

• UsernameToken - a mandatory username and optional password• BinarySecurityToken - encoded binary data that is suitable for storing X.509

certificate or Kerberos ticket

Sending tokens

<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

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

28

Asymmetric key pair generator

Sender Receiver

Plain text message

Plain text message

Symmetric key generator Public key

Private key

Digital Envelope

Cipher text

message

<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

30

<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

Data Object

Hashing Algorithm

Digest

Private key of transmit entity

Encrypted Digest

Data Object

Send to the receiver

Digital signatureDigital signature

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

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

The Roadmap of WS-Security

34

SO

AP

Fou

ndat

ion

Laye

r

WS

-Sec

urity

Lay

er

WS-SecureConversation

WS-Federation

WS-Authentication

WS-Policy

WS-Trust

WS-Privacy

Current Standards Specifications in progress