web services security u.wahli, g.g. ochoa, s. cocasse and m. muetschard, websphere version 5.1 web...
TRANSCRIPT
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