Websphere - About Websphere ssl part ii

3/82
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
Bank Teller 2
Network

4/82
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/82
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/82
6
Web server protected
by HTTPS
Internet
 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/82
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/82
8
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/82
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/82
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/82
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 …
Symmetric Encryption

12/82
12
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/82
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?
Asymmetric Encryption

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

15/82
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/82
16
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/82
17
 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/82
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
Hash Functions and Digital Signature

19/82
19
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/82
20
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/82
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/82
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
XML Encryption

23/82
23
 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/82
24
 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/82
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
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/82
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

27/82
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/82
28
<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/82
29
<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/82
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
 <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/82
31
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/82
32
<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/82
33
<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/82
34
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/82
35
<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/82
36
<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/82
37
<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/82
38
 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/82
39
 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/82
40
<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/82
41
<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>
 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)

42/82
42
Verification of the Digital Signature
When the server receives the signed SOAP message,
it should
1. 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>

43/82
43
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

44/82
44
 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 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
– Client’s Response Unit: SOAP response header processing
Decrypt content and digital signature validation

45/82
45
The Roadmap of WS-Security
SOAPFoundat
WS-SecurityLaye
WS-SecureConversation
WS-Federation
WS-Authentication
WS-Policy
WS-Trust
WS-Privacy
Current
Standards
Specifications in progress

46/82
ThankThank You !!!You !!!
For More Information click below link:
Follow Us on:
http://vibranttechnologies.co.in/websphere-classes-in-mumbai.html

Websphere - About Websphere ssl part ii

More Related Content

What's hot (20)

Viewers also liked (17)

Similar to Websphere - About Websphere ssl part ii (20)

More from Vibrant Technologies & Computers (20)

Recently uploaded (20)

Websphere - About Websphere ssl part ii