6. Web Services Security

1
6. Web Services Security
2
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

• 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
Network
Bank Teller 2
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

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

6

• Consider a more complicate Web services-based
  application

Backend Application
Web server protected by HTTPS
Business Partner 1
secure
Web Services Gateway protected by HTTPS
Internet
secure
secure
secure???
Business Partner 2
Web server protected by HTTPS
Backend Application
7

• 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

• 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

credentials
SOAP message
Secure
secure
Web Services Gateway protected by HTTPS
Internet
secure
secure
Secure
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 v1.0 is an OASIS standard as of April
  2004 which covers mainly the extension of SOAP
  messages

10
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
Symmetric Encryption

• 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

12
Sender
Receiver
Cipher text message
The same key is used for both encryption and
decryption
Secret Key generator
13
Asymmetric Encryption

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

14
Sender
Receiver
Cipher text message
Asymmetric key pair generator
Different keys are used for encryption and
decryption
15

• 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
A hybrid approach Digital Envelope
Sender
Receiver
Cipher text message
Digital Envelope
Private key
Asymmetric key pair generator
Symmetric key generator
Public key
17

• Advantages
• Fast, since asymmetric encryption is applied only
  to a key, which is usually not so long in length
• Secure, since we dont 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
Hash Functions and Digital Signature

• To ensure data integrity, an identifier needs to
  be sent with senders 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

19
Data Object
Data Object
Digital signature
Encrypted Digest
Digest
Send to the receiver
Hashing Algorithm
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 huge change in the hash code

20
Hashing Algorithm
Data Object
If the digests match, the data object is from the
right source
Receive from the sender
Public key of transmit entity
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

22
XML Encryption

• The XML Encryption standard defines ways to
  encrypt all or part of an XML document
• Encrypted info is replaced with a single
  ltEncryptedDatagt 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

23
Inside ltEncryptedDatagt

• An ltEncryptedDatagt element contains the following
  elements
• ltEncryptionMethodsgt
• The algorithm used to encrypted the data
• ltKeyInfogt
• Information about the key used to encrypt the
  data
• ltCipherDatagt
• 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/Encrypti
  on

24
XML Digital Signature

• The XML Digital Signature standard defines rules
  for creating a digital signature and storing that
  signature inside an XML document
• The ltSignaturegt element has 3 main parts
• ltSignedInfogt
• Information about what is signed (such as the
  algorithm used to generate the digest and the
  encryption algorithm)
• ltSignatureValuegt
• The value of the digital signature itself
• ltKeyInfogt
• The public key used to verify the signature
  (optional)
• Now a W3C recommendation (http//www.w3.org/Signat
  ure)

25
Basic Syntax of WS-Security

• ltwsseSecuritygt is the container for
  security-related info
• Place in the header means apply to the whole SOAP
  msg

ltS Envelope xmlnsShttp//schemas.xmlsoap.org/s
oap/envelope/gt ltSHeadergt ltwsseSecurity
xmlnswsse"http//schemas.xmlsoap.org/ws/2
003/06/secextgt ltwsseUsernameTokengt
... lt/wsseUsernameTokengt
ltEncryptedKey xmlns"http//www.w3.o
rg/2001/04/enc-enc-enc"gt ...
lt/EncryptedKeygt ltSignature
xmlns"http//www.w3.org/2000/09/xmldsig"gt ...
lt/Signaturegt lt/SHeadergt
Define and use WS-Security namespace
Authentication
Confidentiality, adopt XML Encryption
Integrity, adopt XML Digital Signature
26
Encrypted contents inside the Body can be
included in the ltEncryptedDatagt element
ltSBodygt ... ltEncryptedDatagt
... lt/EncryptedDatagt lt/SBodygt lt/SEnvelopegt

27
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
ltS Envelope xmlnsShttp//schemas.xmlsoap.org/s
oap/envelope/gt ltSHeadergt ltwsseSecurity
xmlnswsse"http//schemas.xmlsoap.org/ws/2
003/06/secext soapenvmustUnderstand1gt
ltwsseUsernameToken wsuIDmyTokengt
ltwsseUsernamegtdanielLunlt/wsseUsernamegt
ltwssePasswordgtpassw0rdlt/wssePasswordgt
lt/wsseUsernameTokengt lt/wsseSecuritygt
lt/SHeadergt ltSBodygt ...
lt/SBodygt lt/SEnvelopegt
The other part of the message can refer to this
UsernameToken with this ID
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

29
ltS Envelope xmlnsShttp//schemas.xmlsoap.org/s
oap/envelope/gt ltSHeadergt ltwsseSecurity
xmlnswsse"http//schemas.xmlsoap.org/ws/2
003/06/secext soapenvmustUnderstand1gt
ltwsseBinarySecurityToken
wsuIDmyToken ValueTypewsseKerberosv
5ST EncodingTypewsseBase64Binarygt
XIFNWZz99UUbalqIEmJZc0 ...
lt/wsseBinarySecurityTokengt lt/wsseSecuritygt
lt/SHeadergt ltSBodygt ...
lt/SBodygt lt/SEnvelopegt
Using Kerberos service ticket
Specify that the binary data of Kerberos service
ticket will be encoded using Base64
representation
Kerberos ticket or x.509 certificate are also
referred as signed security tokens since the data
has been cryptographically signed by a specific
authority

• 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

30
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
• ltEncryptedKeygt element is placed in security
  header for implementing digital envelope
• ltEncryptionMethodgt Algorithm for the encryption
  of the symmetric key
• ltKeyInfogt Identifier of a public key used for
  encryption, assume both the client and server
  understand the meaning of the identifier
• ltCipherDatagtltCipherValuegt Encrypted symmetric key
  value
• ltReferenceListgt List of ltDataReferencegt to
  contents encrypted with this symmetric key

31
Sender
Receiver
Cipher text message
Digital Envelope
Private key
Asymmetric key pair generator
Symmetric key generator
Public key
32
ltS Envelope xmlnsShttp//schemas.xmlsoap.org/s
oap/envelope/gt ltSHeadergt ltwsseSecurity
...gt ltEncryptedKey xmlnshttp//www.w3.org/
2001/04/xmlencgt ltEncryptionMethod
Algorithm http//www.w3.org/2001/04/x
mlencrsa-1_5gt lt/EncryptionMethodgt
ltKeyInfo xmlnshttp//www.w3.org/2000/09/xmlsig
gt ltwsseSecurityTokenReferencegt
ltwsseKeyIdentifiergtu3AA1MDMOA1bX/vWJ ...
lt/wsseKeyIdentifiergt
lt/wsseSecurityTokenReferencegt
lt/KeyInfogt ltCipherDatagt
ltCipherValuegtcdck0cWh94oF5xBoEm ...
lt/CipherValuegt lt/CipherDatagt
ltReferenceListgt ltDataReference URI
myTokengt lt/DataReferencegt
lt/ReferenceListgt lt/EncryptedKeygt
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
ltSBodygt ltpo xmlns ...gt ltwsseSecurity
...gt ltEncryptedData xmlnshttp//www.w3.org
/2001/04/xmlenc IdmyToken
Typehttp//www.w3.org/2001/04/xmlencContentgt
ltEncryptionMethod Algorithm
http//www.w3.org/2001/04/xmlenctripledes-cbcgt
lt/EncryptionMethodgt ltCipherDatagt
ltCipherValuegtEw7Zggr8z3 ...
lt/CipherValuegt lt/CipherDatagt
lt/EncryptedDatagt ltshipTogt
ltcompanygtThe Skateboard Warehouselt/companygt
ltstreetgtOne Warehouse Parklt/streetgt
ltpostalCodegt01775lt/postCodegt lt/shipTogt
lt/pogt lt/SBodygt
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
WS-Security for Integrity and Non-repudiation
Using XML Digital Signature
Data Object
Data Object
Digital signature
Encrypted Digest
Digest
Send to the receiver
Hashing Algorithm
Private key of transmit entity
35
ltS Envelope xmlnsShttp//schemas.xmlsoap.org/s
oap/envelope/gt ltSHeadergt ltwsseSecurity
...gt ltwsseBinarySecurityToken
wsuIDmyToken ValueTypewsseX509v3
lt/wsseBinarySecurityTokengt
ltSignature xmlnshttp//www.w3.org/2000/09/xml
dsiggt ... 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 ... lt/Signaturegt
lt/wsseSecuritygt lt/SHeadergt ltSBody
xmlnswsu ... wsuIDbody_idgt ...
lt/SBodygt lt/SEnvelopegt
Namespace for XML Digital Signature which defines
the element ltSignaturegt

• 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

36
ltSignature xmlnshttp//www.w3.org/2000/09/xmldsi
ggt ltSignedInfogt ... Indicate what is to
be signed ... ... A digest of body_id is
generated and placed here... ... Define the
algorithms used to generate the digest..
lt/SignedInfogt ltSignatureValuegt
... The actual signature ... ... The
digest of ltSignedInfogt part will be generated
... and encrypted using the private key as
implied ... in ltKeyInfogt ...
lt/SignatureValuegt ltKeyInfogt
... 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
ltSignedInfogt lt/KeyInfogt lt/Signatur
egt
37
ltKeyInfogt ltwsseSecurityTokenReferencegt
ltwsseReference URImyTokengtlt/wsseReferencegt
lt/wsseSecurityTokenReferencegt lt/KeyInfogt

• A security token is referring to in ltKeyInfogt
• 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

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

ltS Envelope ... gt ltSHeadergt
ltwsseSecurity ...gt ltSignature
... gt ltSignedInfogt
lt/SignedInfogt ltSignatureValuegt
lt/SignatureValuegt
lt/Signaturegt lt/wsseSecuritygt lt/SHeadergt
ltSBody...gt lt/SBodygt lt/SEnvelopegt
Encrypted Digest
Digest
39

• Imposer cannot change the target (i.e. Body)
  unnoticeably since it will not match with the
  digest in ltSignedInfogt
• Imposer cannot change the body and the digest in
  ltSignedInfogt together unnoticeably , since it
  will not match with the digest in
  ltSignatureValuegt
• Imposer cannot change digest in ltSignatureValuegt
  since he does not have the private key

ltS Envelope ... gt ltSHeadergt
ltwsseSecurity ...gt ltSignature
... gt ltSignedInfogt
lt/SignedInfogt ltSignatureValuegt
lt/SignatureValuegt
lt/Signaturegt lt/wsseSecuritygt lt/SHeadergt
ltSBody...gt lt/SBodygt lt/SEnvelopegt
Encrypted Digest
Digest
40
ltSignedInfogt ltCanonicalizationMethod
Algorithm http//www.w3.org/2001/10/xml-
exc-c14n/gt ltSignatureMethod Algorithm
http//www.w3.org/2000/09/xmlsigrsa-sha1/gt
ltReference URIbody_idgt ltTransformsgt
ltTransform Algorithm
http//w3.org/2001/10/xml-exc-c14n/gt
lt/Transformsgt ltDigestMethod Algorithm
http//www.w3.org/2000/09/xmldsigsha1/gt
ltDigestValuegtOjjw8nkT3jJoNN/Axsd
...lt/DigestValuegt lt/Referencegt lt/SignedInfogt

• The ltBodygt 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 ltDigestValuegt element

41
Canonical form XML document

• Two XML documents can be physically different but
  logically equivalent. E.g. by canonicalization,
  both
• lt?xml version1.0 encodingus-ascii?gt
• ltfoo
• bb
• aa
• gtlt/foogt
• and
• lt?xml version1.0 encodingus-ascii?gt
• ltfoo aa bb/gt
• will be converted into
• lt?xml version1.0 encodingus-ascii?gt
• ltfoo aa bbgtlt/foogt

Converting the ltSignedInfogt to canonical form
before generating its digest can avoid signature
mismatch arisen from legitimate alternation of
XML header by intermediate servers
42
ltSignedInfogt ltCanonicalizationMethod
Algorithm http//www.w3.org/2001/10/xml-
exc-c14n/gt ltSignatureMethod Algorithm
http//www.w3.org/2000/09/xmlsigrsa-sha1/gt
ltReference URIbody_idgt
lt/Referencegt lt/SignedInfogt

• Before generating the digest of ltSignedInfogt, it
  should first be converted into a canonical form
  using EXC-C14N canonicalization algorithm
• The digest of ltSignedInfogt is generated using the
  SHA1 algorithm and encrypted using RSA asymmetric
  encryption algorithm (hence RSA-SHA1)

43
Verification of the Digital Signature

• When the server receives the signed SOAP message,
• it should
• generate the digest of the target (i.e. Body in
  this case) using the indicated algorithms
  (EXC-C14N and SHA1)
• Compare with the one in ltSignedInfogt
• If match, decrypt the signature using the public
  key given in the security token
• Extract the ltSignedInfogt subtree of the SOAP
  message
• Generate the digest of ltSignedInfogt using the
  algorithms indicated (EXC-C14N and SHA1)
• Compare the generated digest and the one in
  ltSignatureValuegt

44
WS-Security Implementation in WebSphere
Handler
Handler
Provider App
Request
Request
Requester App
Response
Response
Deployment Descriptor
Deployment Descriptor
Client
WebSphere 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

45

• 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
• Clients Request Unit SOAP request header
  construction
• Security token generation, digital signature
  generation or content encryption
• Servers Request Unit SOAP request header
  processing
• Validate security tokens, set up security
  content, decrypt content or digital signature
  validation
• Servers Response Unit SOAP response header
  construction
• Digital signature generation, content encryption
• Clients Response Unit SOAP response header
  processing
• Decrypt content and digital signature validation

46
The Roadmap of WS-Security
SOAP Foundation Layer
WS-Security Layer
WS-SecureConversation
WS-Federation
WS-Authentication
WS-Policy
WS-Trust
WS-Privacy
Current Standards
Specifications in progress