Areas of B2B security - IBM Websphere

The four areas of security and their definitions that apply to B2B are:

  • Deployment Security means the placement of hardware within an existing network with access to the Internet.This type includes database servers, file shares, message queue servers,and integration servers.
  • Connection Securitymeans establishing a secure connection between tradingparticipants over a Secure Socket Layer (SSL) connection.
  • Document Securityencompasses signing and encrypting the message prior tosending it to the trading partner.
  • Access Control means providing access to data and configuration information inside the B2B application.

When organizations focus on combining these areas, security policies can be defined to establish a secure baseline so that they can trade with their partners over the Internetwith greater confidence.

Deployment security

To protect B2B applications from unauthorized access, networking and firewall protection must be established. Firewalls work in conjunction with proxy servers, providing the ability to filter protocols, addresses, communication ports, and IP packets.

The security model that can be used is the establishment of a demilitarized zone (DMZ). The DMZ must be configured to restrict only a minimum set of communication ports for it toprocess requests.

The XB60 is a DMZ-deployable appliance and requires a minimum amount of access through the inner firewall. Any sensitive payload data persisted to the Appliance is not accessible by partners and is encrypted on the hard drive.

Connection security

A common method of transferring information security on the Internet is using the Secure Sockets Layer (SSL).It uses encryption that is based on the public and private key model, using authentication with basic or extended handshakes. SSL works by creating a secure connection between communicating applications over HTTP.

The SSL protocol addresses the following security issues:

  • Privacy
  • After the symmetric key is established in the initial handshake,the messages areencrypted using this key.

  • Message integrity
  • Messages contain a message authentication code (MAC) ensuring the messageintegrity.

  • Authentication
  • During the handshake,the client authenticates the server using an asymmetric orpublic key.

SSL works well when securing browser-based applications, such as the administrativeconsole in WebSphere Business Integration Connect, but it can also be useful to augment B2B document transfer.

The disadvantage of using SSL alone is that it only protects the data during the transfer process and does not continue to protect it after it has reached its destination, nor does SSL provide document integrity and nonrepudiation.These items are critical for secure electronic business transactions.

The SSL handshake
An HTTP-based SSL connection is always initiated by the client using a URL starting with https:// instead of with http://. At the beginning of an SSL session, an SSL handshake is performed.This handshake produces the cryptographic parameters of the session.

A simplified overview of how the SSL handshake.

SSL handshake example

SSL handshake example

The steps are:

  1. The client sends a client hello message that lists the cryptographic capabilities of the client. These capabilities are sorted in client preference order, such as the version of SSL, the cipher suites supported by the client, and the data compression methods supported by the client.The message also contains a 28-byte random number.
  2. The server responds with a server hello message that contains the cryptographic method,such as cipher suite,the data compression method selected by the server,the session ID,and another random number.
  3. The server sends its digital certificate. In this example, the server uses X.509 V3 digital certificates with SSL.If the server uses SSL V3, and if the server application,for example, the Web server, requires a digital certificate for client authentication, the server sends a digital certificate request message. In the digital certificate request message, the server sends a list of the types of digital certificates supported and the distinguished names of acceptable certificate authorities
  4. The server sends a server hello done message and waits for a client response.
  5. Upon receipt of the server hello done message, the client Web browser verifies the validity of the server’s digital certificate and checks that the server’s hello parameters are acceptable.If the server requested a client digital certificate, the client sends a digital certificate. If no suitable digital certificate is available, the client sends a no digital certificate alert.This alert is only a warning, but the server application can fail the session if client authentication is mandatory.
  6. The client sends a client key exchange message.This message contains thepre-master secret,a 46-byte random number used in the generation of the symmetric encryption keys and the message authentication code (MAC) keys, encrypted with the public key of the server.If the client sent a digital certificate to the server,the client sends a digital certificate verify message signed with the client’s private key. By verifying the signature of this message,the server can explicitly verify the ownership of the client digital certificate.
  7. The client uses a series of cryptographic operations to convert the pre-master secret into a master secret, from which all key material required for encryption and message authentication is derived. Then, the client sends a change cipher spec message to make the server switch to the newly negotiated cipher suite.The next message sent by the client,the finished message, is the first message encrypted with this cipher method and keys.
  8. The server responds with a change cipher spec and a finished message of its own.
  9. The SSL handshake ends,and the encrypted application data can be sent.

Document security

Document security is normally accomplished through digital certificates,which provide anonline identification credential for specific document exchanges,for example, AS1, AS2, AS3, RosettaNet, or custom document-level encryption requirements. As part of document exchange, digital signatures can be calculated on the electronic document using public key cryptography.Through this process,the digital signature is tied to the document being signed, as well as to the signer,and cannot be reproduced.With the passage of the federal digital signature bill,digitally signed electronic transactions have the same legal weight as transactions signed in ink.

Document security provides the following features:

  • Privacy
  • A document is encrypted by the recipient’s public key.Only the recipient has theappropriate private key to decrypt the message.

  • Authentication
  • The recipient can authenticate the sender of a document by verifying a digitalsignature.

  • Integrity
  • A digital signature of the document provides document integrity.

  • Nonrepudiation
  • Nonrepudiation is provided using digital signatures and encrypting the hash value with the receiver’s private key then sent back to thesender,which provides a digital receipt to the sending party.

In the XB60, business documents are typically signed and encrypted before leaving the security of the sender’s network.Every partner that is set up in the XB60 can,and typically will, have an X.509 certificate used to encrypt documents and validate signatures on documents received from that trading partner.

Access control
The XB60 uses a role-based approach for access control. Users log in by providing their partner name, userid, and password.The login determines individual access privileges. The XB60 browser interface, which is used for administering functions, operates over an SSL connection.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

IBM Websphere Topics