Securing A WebSphere MQ Infrastructure Services PDF

Securing a WebSphere MQ Infrastructure
Services
Securing a WebSphere MQ
infrastructure
A white paper on modern cryptographic
techniques applied to WebSphere MQ
By Cesare San Martino (Primeur Security Consultant) and David C. Partridge (Primeur Security Services
Technical Director)
www.primeur.com sales@primeur.com
Services
Contents
Introduction ..............................................................................................................................2
Cryptographic techniques .................................................................................................................................... 2
The two basic aims of security ........................................................................................................................... 2
Security services and cryptographic algorithms.............................................................................................. 3
The importance of standards .............................................................................................................................. 4
Symmetric and asymmetric ciphers ................................................................................................................... 4
Hybrid encryption systems .................................................................................................................................. 5
Certification of Public Keys ................................................................................................................................. 6
Certification Authorities ...................................................................................................................................... 6
PKIs, Public Key Infrastructures ......................................................................................................................... 7
Certification infrastructure: 2 diametrically opposed models..................................................................... 7
The cost of security; tactical and strategic cryptography............................................................................. 8
Integrating security in information systems........................................................................10

Link-oriented security and end-to-end security ...........................................................................................10
P2P and E2E in the context of WebSphere MQ ..........................................................................................11
Functional differences between E2E and P2P security in the context of WebSphere MQ................12
Choosing a P2P solution versus an E2E solution; advantages and disadvantages .................................13
Implementing P2P cryptographic security for WebSphere MQ ...............................................................14
Implementing E2E cryptographic security for WebSphere MQ ...............................................................16
Desirable attributes of an MQ End to End Security Solution....................................................................17
Non-repudiation support ...................................................................................................................................17
Support of message brokers..............................................................................................................................19
Audit log .................................................................................................................................................................20
Script driven Central Administration ..............................................................................................................21
Conclusions .............................................................................................................................23
www.primeur.com 1
sales@primeur.com
Services
Introduction
The word security can mean many things. Even narrowing the context to the
world of information technology, Security still has a wide range of meanings,
sometimes totally unrelated. A brief (incomplete!) list of such meanings could
include: Access Control, Intrusion Detection, Single Sign-On, Firewalls,
Cryptography, Certification, Security Auditing and Management, Virus Protection
and Physical Security. In the specific context of WebSphere MQ, to narrow the
discussion even further, it makes sense to talk about security from the three distinct
viewpoints:
Access control
Propagation of contexts
Application of cryptographic techniques (which can be broken down into End-
to-End and link-oriented solutions)
This article will deal specifically with the last point: the application of cryptographic
techniques in the context of a WebSphere MQ network.
Cryptographic techniques
Perhaps the most important element driving the development of modern
cryptographic security techniques is Electronic Commerce. In the realm of E-
Commerce, security is a basic requirement, a sine qua non. Many international
studies recognise lack of security as one of the main factors inhibiting the
development of electronic commerce. Security is an extremely technical area in
which specialists are relatively hard to come by compared to other professionals.
Furthermore, in the IT context, security must be tightly integrated with already
complex architectures, and at many levels.
The two basic aims of security

For centuries, the aim of cryptography was to protect secret information from
prying eyes. Though cryptography has its origins in the military arena, it soon
became an indispensable tool in the commercial world at large. The word
cryptography is still intuitively associated with secrecy. In the real world of
today, and even more so in the future, cryptography takes on a different role.
Encryption techniques address two basic aims:
PRIVACY: The data can be read only by those for whom it is intended.
AUTHENTICITY: The data is authentic; it has not been modified; it really comes
from the sender; the sender is who he/she claims to be.
www.primeur.com 2
sales@primeur.com
Services
Both aspects (especially the second) are and will become increasingly important in
an open society. This is especially true in the global context of the Internet, where
security seeks to preserve, on the one hand, certainty over economic transactions,
and on the other, the rights of the user. In this way cryptography, initially destined
for specialised and limited uses, has become the technical area where it is possible to
guarantee the rights and duties of users and of organisations operating in the global
context.
Security services and cryptographic algorithms

The term security services is used to indicate the functional objectives of security.
Security services are obtained through the use of cryptographic procedures and
algorithms.
This is a brief list of the main services:
PRIVACY: Privacy is the first and most obvious service offered by security.
Only the legitimate target receiver of the communication can understand the
data sent.
INTEGRITY: The data that arrives has not been changed, and is exactly the same
as the data originally sent (also called No Tampering or Tamper Evidence).
AUTHENTICITY: there is often confusion (even in security literature) between

the terms authenticity, authentication and identification. We often speak of the
Authentication of a user when in fact we mean Identification. In the same way,
we talk of authenticity without distinguishing between authenticity of the
message and authenticity of the sender. The following lines will try to clarify
these concepts.
Authenticity consists of verifying both the integrity and the source of a message.
Authenticity is a persistent characteristic of the message.
AUTHENTICATION and IDENTIFICATION: Identification (of a user) is the

process of verifying that users identity. This verification can use three
techniques, in order of increasing security:
Something that the user knows (a password, or passphrase)
Something that the user has (a magnetic card, a smart card )
Something that the user is (fingerprints or other biometric characteristics).
It is common practice to talk about authentication meaning the identification of a

user (or a process). Authentication based on a password is normally referred to as
weak authentication. In other cases, especially where encryption is part of the
picture, the term strong authentication is used.
Note that authentication or identification of the user is a property that is valid for
the duration of a session, and the procedure will be performed again each time a
new session is opened (this is not true in the case of authenticity).
www.primeur.com 3
sales@primeur.com
Services
PEER ENTITY AUTHENTICATION (PEA): Using this service, two

communicating entities (persons or processes) can be sure of each others
identity.
PEA is a protocol that takes place in real time each time a dialogue is opened or re-
opened between two communicating entities. At the end of the protocol each entity
is sure of the others identity. (Authenticity, on the other hand, is a property of an
object that persists indefinitely, unless the message is changed).
NON-REPUDIATION: Guarantees that a particular transaction took place.

The sender of a message cannot later deny having sent it.
The importance of standards

The identification and implementation of recognised and trusted standards is even
greater in the context of security than in the area of Information Technology in
general. Besides the usual motivating factors behind standards-based solutions
(interoperability, wide market availability, widely available know-how), there is yet
another factor of vital importance when we are dealing with the area of
cryptography:
The secrecy of encrypted text cannot rely on the secrecy of the algorithm used. Quite
the opposite is true the algorithm must be WIDELY known. In practice, it is
mandatory to use STANDARD algorithms. The part that makes the text secret resides
solely in the key: This is known as Kerckhoffs Principle. This basic cryptographic
principle has two driving factors:
It is impossible to keep an algorithm secret for any length of time

A secret algorithm is not a secure algorithm: The only way to
demonstrate the real security of an algorithm is by testing and
continuous resistance to cryptanalytical attacks.
Symmetric and asymmetric ciphers

A complete analysis of the concepts, differences, and features of symmetric and
asymmetric cryptographic systems is beyond the scope of this document. We simply
wish to outline those key points that will have an impact on cryptographic
implementations for WebSphere MQ.
Symmetric ciphers provide the advantage of greater computational speed. On the

other hand, distribution of symmetric keys becomes impractical in any but the most
simple of networks.
www.primeur.com 4
sales@primeur.com
Services
Asymmetric ciphers have two great advantages:
The cryptographic operations dealing with secrecy and authenticity are physically
separated (the private key is used for authenticity; the public for secrecy).
Key management is greatly simplified, since only the public part of the pair is
distributed; the number of distributions increases in a linear fashion, instead of
geometrically, as the number of participants in the secure communication grows.
However, before being able to use asymmetric encryption in practice, two of its
main disadvantages must be overcome:
The computational burden is around three to ten times greater, which means
that it is not practical to process large data volumes or files.
The origin of public keys must be assured and certified. This point, the real
Achilles Heel of public key cryptography according to Phil Zimmermann,
author PGP, raises the problem of key management once more, even if in a
more simple form, which, perhaps, seemed to have been overcome by the
abandoning of the management of shared keys.
The solution to the problems arising from the use of public key cryptography is
normally to be found in the use of hybrid systems.
Hybrid encryption systems

Bearing in mind that symmetric encryption is currently the only type of encryption
suitable for handling larger amounts of data, here is a typical scheme of how two
entities, A and B, can exchange a file securely.
A dynamically generates a symmetric encryption key K (for example, a DES key).

A encrypts K using Bs public key, and encrypts the file using K.
A constructs a message consisting of K and the file, encrypted as described
above, and sends it to B.
B decrypts K using its own private key; then B decrypts the file using K.
{
msg( A B) : { file} ,{K}
K
}
Key_ Pub_ A
www.primeur.com 5
sales@primeur.com
Services
Note that in this example:
The problem of cryptographic performance is resolved by the fact that the

symmetric key is used to protect the file. The asymmetric key is used only to
encrypt the symmetric key, a packet containing only a small number of bytes.
The problem of symmetric key management does not arise: The symmetric key is
generated dynamically at the moment it is needed, and transmitted securely since it
is encrypted. It is valid only for the duration of a single transmission session, thus
increasing security (since it is not reused for further sessions).
The technique allowing the key to be transmitted, with asymmetric protection,

together with the message that it is protecting is known as the Digital Envelope
technique. Standard formats for digital enveloping exist, including S/MIME and
PKCS#7, which guarantee interoperability of cryptographic operations in
heterogeneous systems
Certification of Public Keys

In order for a public key to be used with trust, and in order that its origin can be
guaranteed, the key in question must be certified by a trustworthy entity. In
practice this involves the use of the so-called Digital Certificate (based on the
various versions of the X.509 standard), which is basically the public key to be
certified encrypted with the private key of the certifying entity.
Certification Authorities
The role played by a CA within the trust infrastructure based on asymmetric
cryptography is the guarantor of the identity of each user to all the others. This is
obviously a delicate role that must be undertaken by subjects of proven
trustworthiness and of a level above all the parties, especially in an open context. In
a closed context, a company for example, the CA can be entirely internal, and be
part of an infrastructure dedicated to the internal security of the company itself.
The central element of a trust infrastructure constituted in this way is the public key
of the CA, which must be made known and accessible to everyone. The CA must be
universally worthy of trust. Alternatively, a CA can supply its own public key
attached to a certificate from a higher-level CA.
This is how the so-called CA hierarchies are made up. They may contain varying
levels, at the top of which there must be a CA capable of certifying all the others.
www.primeur.com 6
sales@primeur.com
Services
PKIs, Public Key Infrastructures

A PKI consists of a series of protocols, services and standards that support public
key cryptography applications. The term PKI is rather recent (and fashionable) and
unfortunately does not have one single meaning in all the literature concerning it.
Sometimes, PKI may refer to a hierarchy of trust based on certificates. In other
contexts, the concept includes services such as encryption and digital signature. A
widely acceptable definition could be that a PKI includes services and protocols for
managing public keys, typically through the use of CAs, but not necessarily
cryptographic services carried out with these same keys. Some typical services of a
PKI, in the meaning of this context, would be:
Registration of public keys and issuing a new certificate for a public key
Revocation of certificates and managing CRLs
Distribution of the public keys of registered users
Determining the validity of a certificate and of the operations that it authorises
Services related to certificate requests
Here, the concept of PKI is almost analogous to that of the CA, putting the
emphasis more on services provided than on the authority necessary for rendering
them. Another way of looking at this concept could be this: the CA is the server
part of PKI, which itself however includes all the services necessary for managing
public key encryption.
There is currently no single PKI, despite the efforts at standardisation being

undertaken in various parts of the world.
Certification infrastructure: 2 diametrically opposed models

There are currently two distinct and opposing models for the regulation
relationships between all subjects by performing the role of certification.
The HIERARCHICAL model, adopted by the X.509 standard, outlines a hierarchy

of certification authorities, each of an increasingly higher level. This type of structure
is undoubtedly efficient, but its details must be studied very carefully, since the trust
of the entire structure may depend on a single certification element. It is not
explicitly supported for two CAs (or users) to mutually recognise each other.
Mutual certification must occur through the hierarchy.
The DECENTRALISED model, on the other hand, has been adopted by PGP and
by its many users, with its concept of a Web of Trust. In this model, certification
authorities have no role since each user is free to decide independently who he/she
wishes or does not wish to trust. Each user can, if he/she wishes, act as a CA for all
the other users, signing the public keys of those users that he/she wishes to
guarantee with his/her own private key. This scheme extends out generating a web
of trust, which implements a sort of transitive trust: if A trusts B and B trusts C,
then A can trust C.
www.primeur.com 7
sales@primeur.com
Services
The two models are totally incompatible, and are therefore probably destined to
coexist side by side, but separately: the hierarchical model in corporate or
structured worlds, the decentralised model in the Internet user community, or in
communities of users linked by common interest that are not organised
hierarchically.
The cost of security; tactical and strategic cryptography

A basic guiding principal for all implementations of cryptographic systems is cost: the
cost of a security system must be less than the value of the data that it is protecting.
This principle tells us that it would not make sense to think of implementing security
for subsystems whose data have little or no value. On the other hand there are
subsystems whose value is such that it justifies the use of wide-ranging and complex
applications.
Another important distinction, also cost-related, is that between strategic and

tactical cryptography.
In every cryptographic system a balance must be struck between the robustness of

the system itself (that is, its capacity to resist cryptanalytical attacks) and its ease of
construction and use. In general, the relationship between the two is inversely
proportional. The guiding criterion is time-related: How long must the information
remain secret? How long would it take an intruder to decode it?
Some information has a life lasting minutes (for example, the order that an artillery
officer may give to fire at a certain position; a stock market order to be performed
immediately). These are types of information that have great value for a very limited
period of time; they are therefore suited to the use of cryptographic techniques that
are quick and easy to use, even though they may not be able to resist a crypto-
attack for very long. There are other types of information (for example, the
contents of your share portfolio) that have a much longer life and which require the
use of more robust (and therefore more processing-heavy) cryptographic techniques.
Currently, those ciphers considered secure over a sufficiently long duration (several
decades) are the symmetric ciphers T-DES (112-bit key) and RC4 in its 128-bit
version. Equally secure are 2048-bit asymmetric ciphers.
www.primeur.com 8
sales@primeur.com
Services
For applications with modest time requirements, DES and 512-bit RSA are
sufficiently secure. DES is no longer considered to be very secure. This is illustrated
by the following comment on the success against the latest challenge issued by RSA,
called DES III:
Breaking the previous record of 56 hours, Distributed.Net, a worldwide coalition of

computer enthusiasts, worked with the Electronic Frontier Foundation's (EFF) "Deep
Crack," a specially designed supercomputer, and a worldwide network of nearly
100,000 PCs on the Internet, to win RSA Data Security's DES Challenge III in a record-
breaking 22 hours and 15 minutes. The worldwide computing team deciphered a
secret message encrypted with the United States government's Data Encryption
Standard (DES) algorithm using commonly available technology.
For further details, see: http://www.rsa.com/news/pr/990119-1.html
A timeframe of 22 hours using the combined forces of a network of 100.000 PCs

plus a dedicated supercomputer could hardly be called a small effort. However, the
trend towards ever-increasing computational power makes it feasible that within a
few years a cryptanalyst could break DES with the help of a good desktop. DES
therefore is still applicable for protecting data wth a relatively short lifespan (days)
and applications that are expected to remain in use for some years. If you are
looking at a greater length of time, it is now necessary, as already mentioned, to use
more powerful algorithms.
www.primeur.com 9
sales@primeur.com
Services
Integrating security in information systems
The subjects outlined in the previous paragraphs refer to the cryptographic

principles of security generally, divorced from the specific context in which they are
to be used. In reality, it is impossible to overlook the interaction with the
technological context. When security functionality is inserted in a complex
information system, it is impossible to ignore that systems architecture.
Furthermore, the context in which the cryptographic implementations are interfaced
with the information system has FUNCTIONAL implications for the system. In
practice, specific cryptographic services can be implemented in one context and not
in others, and the use of of the same techniques has different functional results
acording to the context in which they are employed.
Link-oriented security and end-to-end security

A useful basic distinction is the difference between link-oriented measures and end-
to-end measures.
With link-oriented measures, the aim is to protect the communication channel and
to establish, as it were, a secure communication tube. This is also known as Point-
to-Point security, abbreviated as P2P.
Link oriented measures therefore provide security for information crossing an

individual link between two network nodes, independently of the source and final
destination of the information. In a network using this type of approach, encryption
is performed independently for each link. If a link is successfully attacked, the loss
of privacy is not propagated to the rest of the network. Since information is
encrypted on the link and not on the nodes, the nodes themselves must be secure.
This is the case, for example, with the IPSec or PPTP protocols, which operate at
the packet transport level in an IP network. In a different way, the same
considerations hold true for those products that use the exits of Middleware
products such as WebSphere MQ, even though in this case the level is above that of
the network. However, in both cases, the higher levels, and highest of all the
application level, remain unaware of the underlying processes, which are transparent
to them.
Link-oriented measures see the network as a series of nodes connected with links,
each of which can be protected independently. End-to-end measures (E2E for short),
on the other hand, see the network solely as a means for transporting information
reliably from source to destination. Violation of an intermediate node does not
compromise security. Therefore in E2E measures, what you wish to ensure is that
security reaches the desired level, typically that of the application. In this way the
application is no longer transparent to security. Instead, it explicitly commands the
security functionality, thus providing greater guarantees.
www.primeur.com 10
sales@primeur.com
Services
In link-oriented measures, it is assumed that the risk is completely on the

communication channel external to the company.
With E2E measures higher level entities are being secured, typically the application
or the application user.
P2P and E2E in the context of WebSphere MQ

In the WebSphere MQ context, a link-oriented solution will be a WebSphere MQ
channel solution. Typically, exits will be used that are provided by WebSphere MQ
itself at this level (Security exit, Message exit and Send/Receive exit). These exits
allow us to apply security to data flowing over the MQ channel.
An E2E solution, on the other hand, will typically intervene at an application level
and will concern this level or the higher level of the actual user.
If the application requires the user to enter his or her own private key (or to insert
his or her own smart card) the level of security will be extended to the highest
possible level, that of the user. It is possible also to get the application to implement
its own process signature, a situation typical of batch processing, for example.
The following diagram summarises the situation in the context of WebSphere MQ.
This diagram illustrates how the main architectural difference lies in the fact that in
the E2E solution messages are already protected in the queues, whereas for P2P
solutions the messages are unencrypted in the queues.
www.primeur.com 11
sales@primeur.com
Services
In the example are summarized different solutions that can be provided by Primeur:
Data Secure for WebSphere MQ Link (P2P): a link-oriented solution for

WebSphere MQ channels
Data Secure for WebSphere MQ E2E: an application transparent End-to-End
solution for WebSphere MQ
Data Secure Toolkit (DSTK): an End-to-End solution that requires code changes
A final note: in the E2E context the agent (the principal, in security speak) of the
secure communication is the end user or the application process; in the P2P context,
technically, it is the communication channel, even if, in fact, for the sake of
convenience this is often identified with the node in question. This last distinction
has obviously no effect in the not infrequent case where there is a single channel
corresponding to a node.
Functional differences between E2E and P2P security in the context of WebSphere MQ
We have already mentioned the functional implications arising from the choice of
where to apply cryptographic services in interfacing the system. This section explains
this statement in the context of WebSphere MQ. The applicability and the meaning
of the main cryptographic services in the two different contexts are presented
schematically below.
Service/Context P2P E2E

PEA Appropriate and can be implemented. Cannot be implemented. Since
Since PEA is a protocol, P2P is the correct the users and applications leave
context for this functionality. The entity the communications to
that is authenticated is the channel (node). WebSphere MQ, it does not
This authentication is valid for the entire make sense to talk about PEA
secure session. Should the channel fail PEA at this level.
must be performed again.
Confidentiality Appropriate and can be implemented. Appropriate and can be
Messages in the queue are not encrypted. implemented. Messages in the
queues are encrypted.
Integrity Appropriate and can be implemented. You Appropriate and can be
are assured that messages are not implemented. You are assured
counterfeited on the channel. that messages are not
counterfeited on queues or
channels.
Authentication Appropriate and can be implemented. The Appropriate and can be
authentic origin of the message is the implemented. The authentic
original point of transmission (the sender origin of the message is the
channel or node) originating user or application
process.
Non-repudiation Not appropriate, but can be implemented. Appropriate and can be
Non-repudiation is meaningful at the implemented. The originating
application level. It does not mean much user or application process
to say that a communication process cannot deny having sent the
cannot deny having sent a message. message.
www.primeur.com 12
sales@primeur.com
Services
As a final consideration on the above table we should note that it makes sense to
use cryptographic techniques in both contexts. In this case, P2P is required only for
the PEA process, while all other processes are left up to the E2E context. This
combination guarantees the maximum level of functionality that can be implemented.
Choosing a P2P solution versus an E2E solution; advantages and disadvantages

The first basic criteria for choosing one over the other must be functional. At this
point, the following questions must be asked:
From which types of attackers do I wish to protect myself? Only external? Also
internal?
What assumptions can be made on the security of sites involved? Is this security
high enough?
Is non-repudiation required? Is it necessary to be able to answer any challenges
with proof that a particular document originated with and was sent by a specific
physical person or application process?
The answers to the above questions will be the essential deciding factor in choosing
one solution or the other.
In general, being able to respect the functional requirements, channel solutions are
for economic and ease-of-management reasons. The following table outlines the
reasons.
www.primeur.com 13
sales@primeur.com
Services
Service/Context P2P E2E

Participants in the Channels or nodes Users or application processes
communication
Key managers Site administrators, therefore Users: if you wish to guarantee non-
suitably skilled persons. repudiation the managers must be the
users themselves, usually not highly
skilled.
Application processes: application
specialists
Number of Equal or proportional to the Significantly greater than the number of
participants number of nodes. nodes.
Implementation Low to very low. Deployment of Low to medium if a transparent
costs a channel solution can be solution such as DSMQ E2E is
quantified as a few hours for each applicable: DSMQ E2E can be
node involved. implemented in as little as a few hours
If code changes are required (such as
using a cryptographic toolkit) then the
cost would range from high or very
high. There may be cases where this is
completely impossible (if the source of
the package is not available)
Management costs Same as for E2E (except for key Same as for P2P, (except for key
management, which is greater in management, which is greater in the
the E2E context on account of the E2E context on account of the greater
greater number and lower skill number and lower skill level of
level of participants). participants).
Implementing P2P cryptographic security for WebSphere MQ

WebSphere MQ provides a relevant set of channel exits that can be used to
implement link-oriented security solutions.
The Security Exit is used once per session. It is therefore particularly useful for
implementing the PEA protocol.
The Message Exit is used once for each message crossing the channel. It is therefore
the ideal exit for implementing cryptographic services such as data encryption and
authentication.
The Send/Receive exit is a lower level exit where it is possible to handle the
individual physical blocks into which a message is broken down before being sent.
This is also useful for cryptographic operations on data. Compared with the message
exit, however, it poses performance problems, since the cryptographic functions are
more efficient if they operate on larger portions of data. It is, however, the only
practical solution where you wish to secure a Client Server relationship, since the
WebSphere MQ Client does not have a message exit, only a S/R exit.
Furthermore both S/R and message exits are suitable (with the aforementioned S/R
limitations) for performing compression operations.
www.primeur.com 14
sales@primeur.com
Services
If you also wish to perform compression, you must pay attention to the order in
which the operations are carried out. Compression must be carried out BEFORE
encryption, and therefore decryption will take place before decompression. The
following are the reasons for this:
By nature encryption tends to flatten the peaks in the statistical distribution of

characters in the text. On the other hand, all modern compression algorithms
(Huffmann, LZW and their variants) use the differing frequencies of the various
characters in order to recode the data, optimising the space they take up. Applying
compression to an encrypted text therefore does not normally provide any benefit,
since the encryption step will have already caused an evening out of the frequencies
for each character.
However, applying encryption to a compressed text provides cryptographic benefits:

Since encryption is performed on a text whose characters are now distributed
statistically more evenly, it makes the job of the cryptanalyst trying to perform a
frequency analysis attack even more difficult.
In brief, a P2P security implementation for WebSphere MQ should provide the

following functionality:
At the moment that the session is established the Security Exit is invoked. In this
exit a module is called that performs mutual authentication according to one of
the supported standards, such as X.509 or Kerberos.
A by-product of the PEA phase is the generation of a first session key that the
participants exchange, protecting it with asymmetric techniques.
During the normal exchange of messages the message exit is invoked where the
message is first (optionally) compressed and then encrypted using the session
key.
After each message is exchanged (or after a certain configurable, but not
indefinite, number of messages have been exchanged) the two nodes recalculate
a new session key with which to continue the secure communication.
Together with the ciphertext of the message, a message authentication code is

also calculated. This can be a H MAC, the symmetric equivalent of a digital
signature that guarantees integrity services. The use of the H MAC improves
performance noticeably, since it is based on symmetric techniques.
In the case of exceptions, the channel must be closed, since these exceptions
could indicate an attack in progress.
www.primeur.com 15
sales@primeur.com
Services
The system must guarantee the highest level of flexibility of configuration: the
proposed functions (PEA, Encryption, Compression, and Integrity) must be
freely configurable on each of the links. Moreover, the system must guarantee a
minimal but reasonable choice of cryptographic standards and key-lengths, and
this choice must also be freely configurable. An implementation is recommended
that supports a choice among at least the following algorithms:
Symmetric encryption: DES, T-DES (with 2 or 3 keys), RC4 up to 128 bit
Asymmetric encryption: RSA configurable from 512 to 2048 bit.
Hash: SHA-1, MD5.
The system manager must be free to configure a link for example using only
PEA, another with weak encryption, and yet another with strong encryption.
Given the computational load of cryptographic systems, such flexibility is
imperative.
Implementing E2E cryptographic security for WebSphere MQ

Whether a transparent solution that requires no application modification is adopted,
or it is chosen to modify the application to provide End-to-End security, the
processing logic that will typically be applied is as follows:
Sending Side:
Compression call (optional)
Cryptographic call
Message PUT
Receiving Side:
Message GET
Decryption
Decompression (if necessary)
In the past it was difficult to implement a transparent solution to provide End-To-

End security for WebSphere MQ applications, as there were no appropriate exits at
the MQI level that could be used. This typically meant that applications needed to be
modified to provide End-to-End security services, and this was difficult and expensive
to implement or even impossible in the case where source code was not available.
Now, however, WebSphere MQ 5.3 has provided an API exit on the distributed
platforms that allows the implementation of a transparent solution to provide End-
to-End security without needing to modify applications. On the OS/390 (z/OS)
platform, it is still complex to implement, but has proven possible to use library
front-ending for batch applications (using STEPLIB), while for CICS applications, it is
possible to use the CICS API Crossing Exit.
This means that it is now possible to deliver an End-to-End security solution for
WebSphere MQ that is application transparent (i.e. does not require any application
code changes).
www.primeur.com 16
sales@primeur.com
Services
To implement E2E solutions, it is absolutely recommended to use so-called digital

signature functionality together with the most accepted standards for this purpose:
PKCS#7 and S/MIME. In particular, PKCS#7 guarantees a greater level of
interoperability should the OS/390 platform be part of the secure exchange.
Several cryptographical tools are available commercially, with which these functions
can be implemented. In general, all the modern tools allow a digital signature to be
implemented with a single high-level call. This single call in turn results in several
internal cryptographic calls. In the most complete case of encryption and signature,
these operations are:
Generation of a symmetric session key

Generation of a message digest of the data
Encryption of the message digest using the senders private key, thus creating a
digital signature
Encryption of the data with the symmetric key
Encryption of the symmetric key with the public key of the target recipient
Enveloping of the data obtained in one of the standard Digital Envelopes
To the above are added the operations of acccess to the private key (usually
contained in a cryptographic token) and retrieval of the correspondents public
key (from their certificate).
The use of standard cryptographic tools guarantees that all the operations outlined
above can be performed with a single call.
Desirable attributes of an MQ End to End Security Solution

The techniques described above allow an end to end data security solution to be
delivered for WebSphere MQ that provides the services of message integrity and
proof of origin (by using a digital signature) and if so wished message privacy by
means of data encryption.
On their own however, these techniques may not provide an adequate solution for
meeting regulatory requirements for after the event non-repudiation, the provision
of audit trails, or to support the use of a message broker.
Non-repudiation support
In situations where messages are being exchanged between parties who do not
necessarily trust one another, it can be useful for the recipient of a message to be
able to prove at a later date that the other party sent a particular message. By using
a digital signature on the message the identity of the sender and the authenticity of
the message can be confirmed, and therefore the sender of the message is unable to
deny (or repudiate) the sending of that message.
www.primeur.com 17
sales@primeur.com
Services
If the recipient of a digitally signed or a digitally signed and enveloped (encrypted)

message wishes to use the digital signature for this purpose, then they need to
archive the message in its signed or signed and enveloped (encrypted) form. If this is
done, should a dispute arise at a later date, the recipient can retrieve the message
from the archive and check the signature again. This is not the only requirement for
ensuring that messages cannot be repudiated, but it is a necessary one.
There are a number of other requirements for the process of non-repudiation. The
most important are:
A suitable legal framework exists to allow the use of digital signatures for this
purpose. This may take the form a contract, or be part of national or supra-
national legislation.
If necessary, the communicating parties have agreed to the use of digital
signatures for this purpose.
If required by the legal framework (this is normally the case), the certificates
used for checking the signature should include key usage of non-repudiation.
Non-repudiation is normally only necessary when receiving signed or signed and

encrypted messages from another organisation as might occur in a Business to
Business or Business to Consumer message exchange. It is not typically required for
messages moving within the organisation where the digital signature is used purely
for the purposes of authenticating the message sender and that the message has not
been tampered with while in transit.
Because only some messages need to be archived for non-repudiation purposes, it is

not appropriate to archive all signed or signed and enveloped message that are
received. Typically the requirement will be to archive messages retrieved from a
specific queue or queues.
Each customer will typically have unique requirements for message archival: Some
will want to archive messages to an external database, while others will wish to
write these messages to some other form of external storage. For this reason, it is
appropriate to write archive messages to an MQSeries queue (QLOCAL, QALIAS,
or QREMOTE) whose name is part of the product configuration. For example: We
might wish to archive all signed or signed and enveloped messages read from the
queue MYAPP.QUEUE. In this case we would modify the product configuration to
specify an archive queue name of MYAPP.ARCHIVE.QUEUE.
If this is done, then once the signature on the message has been successfully
validated, and if appropriate it has been confirmed that the message sender was
authorised, the message as it was read from the queue would be written to the
archive queue. Put in another way, the message written to the archive queue would
include the DSMD header and the payload will still be in the form of a PKCS#7
Signed or Signed and Enveloped data object or objects.
www.primeur.com 18
sales@primeur.com
Services
The message would then be written to the archive queue using

MQPMO_SET_ALL_CONTEXT, so that all the information from the original
message descriptor would be preserved. For this reason, the user running the
application reading the messages would require appropriate authority to use set all
context on the archive queue.
The archive messages would be MQPUT to the archive queue with the same
syncpoint options that the user application was using to get the messages from the
application queue. The archive function would not issue any commits or rollbacks.
The messages may then be read from the archive queue by the same (or another)
application and saved to a database for non-repudiation purposes (where the
signature is re-validated after the event in the event of a dispute).
Support of message brokers

The archive facility described above allows solutions to be developed for message
brokers where it is wished for the broker to inspect the clear text message and
yet route the original signed (or signed and encrypted) message through to the final
destination. It also allows more complex solutions to be developed where the
original (protected) message is archived along with the plain text, and also to
transform the message and record the clear text and protected content that has
been sent on to the final processing node.
MQMD
Info
Df09@24
724jl89#
Df09@24
724jl89#
Clear text
DB
Archive Df09@24
724jl89#
Df09@24
724jl89#
Application or
Message Broker
Df09@24
Clear text (WBIMB?) Output
724jl89#
E2E
Input
www.primeur.com 19
sales@primeur.com
Services
Audit log
Regulatory requirements, internal practices, or similar often require that an audit log
be kept of processing applied to data. This might only require that exception
conditions be logged, or that all processing be logged. It might be required for all
messages processed on all queues, or just for some queues.
For this reason, we believe that an End-to-End security product to WebSphere MQ

should have the capability to be configured on either a global basis or a queue by
queue basis to write an audit log of its activities. This audit log may record either all
E2E related processing, or just those E2E actions that resulted in an error condition.
The audit records could be written in a platform specific manner (such as for
example using SMF records on z/OS), or a platform neutral manner using a format
such as XML written to a flat file. We believe that a platform neutral solution such
as XML provides a portable solution which has the advantage that it can be read by
people without requiring any special processing, and also by programmes. An
example of an XML formatted audit record for a successful MQGET operation
might look like:
<E2EAuditRec>
<Timestamp>2005041415113269</Timestamp>
<location>
<hostname>giove.primeur.com</hostname>
<pid>0x162050</pid>
<tid>0x796009</tid>
<qmgr>DS</qmgr>
<userid>sriccio</userid>
<hconn>0x20212BD8</hconn>
</location>
<object>
<ObjectName>Q1</ObjectName>
<ObjectQMgrName>DS</ObjectQMgrName>
</object>
<data>
<operation>MQGET</operation>
<syncpoint>NO</syncpoint>
<result>
<mqcc>0</mqcc>
<mqrc>0</mqrc>
</result>
<policy>processedData</policy>
<mqmd>
<msgid>414D5120445354312020202020202020425CD0652002E30E</msgid>
<correlid>000000000000000000000000000000000000000000000000</correlid>
<putdate>20050414</putdate>
<puttime>15112477</puttime>
<expiry>0xFFFFFFFF</expiry>
<format />
<persistence>NO</persistence>
<putapplname />
<accountingtoken>03323138000000000000000000000000000000000000000000000000000000
06</accountingtoken>
<useridentifier>gala</useridentifier>
</mqmd>
<putaction>
<compression>none</compression>
<qop>PUTOptions.QOP_ENCRYPT_AND_SIGN</qop>
</putaction>
<authsenders />
<sender>CN=Helios, O=Primeur; C=GB</sender>
<archive>
<provider>EXTARC V1.0</provider>
www.primeur.com 20
sales@primeur.com
Services
<archivequeue>Q1.ARCH</archivequeue>
<archiveresult>0</archiveresult>
</archive>
</data>
</E2EAuditRec>
Script driven Central Administration

A Graphical User Interface (GUI) approach to administration of an End-to-End
security system might appear very attractive, and is very useful for creating local
configurations for test systems. Unfortunately such a tool typically does not actually
address the real concerns that corporate customers have for configuration
management in the broad sense:
Organisations that rely upon their MQ infrastructure for the continuance of their
business need to have the ability to create configurations ahead of the time that they
are to be deployed, to store them in a change management system or source code
control system such as (for example) CVS, and to deploy those configurations during
a change control window.
For this reason it is considered desirable to be able to create the configuration for
an End to End security solution for a set of related queue managers (a domain) at a
central location. The configuration for a domain is created in the form of scripts
which can be held in the form of flat files and be stored in the change control
system of the customers choice.
Once the organisation has moved to the centrally administered model, it should be
possible to disable the use of local (GUI based) configuration tools.
Clearly the language chosen for the implementation of these scripts should be one
for which an interpreter is widely available on all the relevant platforms. If the
platforms involved were just UNIX systems, then the obvious candidates for the
implementation would be scripting languages such as Perl, Python, or Tcl as these
are widely known and understood, and available for all UNIX systems.
Unfortunately, given the wide range of platforms on which WebSphere MQ runs,
these do not appear at first glance to be suitable, as these languages are not typically
available on (for example) z/OS.
There is a suitable candidate in the form of Java: The Java interpreter can be found
on almost any platform, but Java of itself is not a scripting language but a
programming language. Python, on the other hand, is a suitable scripting language.
What is needed is a scripting language implemented in Java: Jython is an
implementation of the Python scripting language that is written in 100% Pure Java.
This leverages the broad platform availability of Java and adds the speed of
development of the Python scripting language without requiring a native Python
interpreter.
www.primeur.com 21
sales@primeur.com
Services
These configuration scripts control the security processing of messages in the MQ

systems, so it is appropriate that:
1. The MQ infrastructure should be used to for the actual deployment of a

configuration from the central location to the managed system.
2. It should be possible to configure the deployment system so that the
messages used for deployment will be digitally signed. This will allow the remote
system to which the configuration is being deployed to check that the configuration
messages were sent by an authorised party, and that the configuration has not
been tampered in transit.
The configuration manager tool should be a command line tool which can handle:
Creation of and deletion of domain configurations from the central repository

queue
Allow a domain configuration to be deployed to some or all of the queue
managers in the domain
Allow a configuration to be un-deployed or backed out on an individual queue
manager within the administrative domain
The scripting language needs to allow for basic configuration settings for how E2E
processing should be performed on individual queue managers and queues within the
domain. It should also allow for defining higher level constructs based on common
MQ usage patterns such as the Request-Reply pattern, as this will simplify the
administrators task.
www.primeur.com 22
sales@primeur.com
Services
Conclusions
As WebSphere MQ is becoming more and more the backbone of many e-commerce

solutions, the need to secure WebSphere MQ messages on the queues (using for
example DSMQ E2E), and also to secure WebSphere MQ channels (using for
example DSMQ P2P) will grow accordingly.
In studying and deploying a security solution for WebSphere MQ one needs to be

aware both of the security technology as well as of the WebSphere MQ related
technology and architecture.
First of all one, obviously needs to define the specific security objectives one is
aiming at.
Secondly, but not less importantly, one needs to take into account that deploying a
security solution implies designing a combined security/WebSphere MQ architecture;
the functional behaviour of the whole system will depend not only on the chosen
specific security functions but also largely on the implemented architecture.
www.primeur.com 23
sales@primeur.com

Securing A WebSphere MQ Infrastructure Services PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Securing A WebSphere MQ Infrastructure Services PDF

Загружено:

Авторское право:

Доступные форматы

Securing a WebSphere MQ Infrastructure

Integrating security in information systems........................................................................10

The two basic aims of security

Encryption techniques address two basic aims:

Security services and cryptographic algorithms

This is a brief list of the main services:

AUTHENTICITY: there is often confusion (even in security literature) between

AUTHENTICATION and IDENTIFICATION: Identification (of a user) is the

It is common practice to talk about authentication meaning the identification of a

PEER ENTITY AUTHENTICATION (PEA): Using this service, two

NON-REPUDIATION: Guarantees that a particular transaction took place.

The importance of standards

It is impossible to keep an algorithm secret for any length of time

Symmetric and asymmetric ciphers

Symmetric ciphers provide the advantage of greater computational speed. On the

Asymmetric ciphers have two great advantages:

Hybrid encryption systems

A dynamically generates a symmetric encryption key K (for example, a DES key).

Note that in this example:

The problem of cryptographic performance is resolved by the fact that the

The technique allowing the key to be transmitted, with asymmetric protection,

Certification of Public Keys

PKIs, Public Key Infrastructures

There is currently no single PKI, despite the efforts at standardisation being

Certification infrastructure: 2 diametrically opposed models

The HIERARCHICAL model, adopted by the X.509 standard, outlines a hierarchy

The cost of security; tactical and strategic cryptography

Another important distinction, also cost-related, is that between strategic and

In every cryptographic system a balance must be struck between the robustness of

Breaking the previous record of 56 hours, Distributed.Net, a worldwide coalition of

For further details, see: http://www.rsa.com/news/pr/990119-1.html

A timeframe of 22 hours using the combined forces of a network of 100.000 PCs

Integrating security in information systems

The subjects outlined in the previous paragraphs refer to the cryptographic

Link-oriented security and end-to-end security

Link oriented measures therefore provide security for information crossing an

In link-oriented measures, it is assumed that the risk is completely on the

P2P and E2E in the context of WebSphere MQ

Data Secure for WebSphere MQ Link (P2P): a link-oriented solution for

Service/Context P2P E2E

Choosing a P2P solution versus an E2E solution; advantages and disadvantages

Service/Context P2P E2E

Implementing P2P cryptographic security for WebSphere MQ

By nature encryption tends to flatten the peaks in the statistical distribution of

However, applying encryption to a compressed text provides cryptographic benefits:

In brief, a P2P security implementation for WebSphere MQ should provide the

Together with the ciphertext of the message, a message authentication code is

Implementing E2E cryptographic security for WebSphere MQ

In the past it was difficult to implement a transparent solution to provide End-To-

To implement E2E solutions, it is absolutely recommended to use so-called digital

Generation of a symmetric session key

Desirable attributes of an MQ End to End Security Solution

If the recipient of a digitally signed or a digitally signed and enveloped (encrypted)

Non-repudiation is normally only necessary when receiving signed or signed and

Because only some messages need to be archived for non-repudiation purposes, it is

The message would then be written to the archive queue using

Support of message brokers

For this reason, we believe that an End-to-End security product to WebSphere MQ

Script driven Central Administration

These configuration scripts control the security processing of messages in the MQ

1. The MQ infrastructure should be used to for the actual deployment of a

Creation of and deletion of domain configurations from the central repository

As WebSphere MQ is becoming more and more the backbone of many e-commerce