You have a number of options depending of the level of MQ you are running,
and whether you need to have the messages encrypted on the queues as well as
while traversing the channels.

If you're only concerned to protect data flowing over the channel:

a) If running MQ 5.3, and the free SSL implementation of channel security is
adequate to meet your needs, then you can go this route.   Your choice of
algorithms may be constrained depending on the platform, and it doesn't e.g.
compress data b4 doing crypto - which may pay off in throughput on the
channel.   Not as function rich as option b) nor as flexible, but it is
free.

b) If not running MQ 5.3 or you want additional capabilities look at
something like our Data Secure for WebSphere MQ (DSMQ) product which uses MQ
channel exits to provide the following services:

        1) Peer Entity Authentication according to X.509 standard as channel
starts,
                setting of MCA User of srvrconn channel instance based on credentials
                of the client for all platforms (not just 390),
                session keys set up for message or send/receive exits.
        2) Data Authentication (none, MD5 or SHA-1 HMAC)
        3) Data Encryption (none, RC4, DES, 3DES)
        4) Data Compression (before data auth and encryption if chosen)

which we refer to as the Peer to Peer (P2P) component of the DSMQ product.
This option has been chosen by many financial organisations around the
world.    Other vendors are also active in this space.

If you also require that data in the MQ queues (and logs) be protected
without requiring modifications to your applications, then you will need to
purchase a product that does this.   The End to End (E2E) component of our
DSMQ product provides this capability without requiring you to modify
applications.   Messages may be compressed (or not), digitally signed or
signed and encrypted for specific recipient(s).    This is available for MQ
2.1, 5.2 and 5.3 on 390, and for 5.3 on distributed platforms.

Tivoli also has a product in this area (AMBI).   FWIW, in my opinion, it is
far too complex and has far too much in the way of pre-requisites and
administrative overhead by comparison with DSMQ, but as I was the product
architect and designer for DSMQ E2E, I would be biased I guess!   Oh yes,
TAMBI costs more too unless you've got some huge corporate discount :-).

Regards,
David C. Partridge
Technical Products Director
Primeur Security Services
Tel: +44 (0)1926 511058
Mobile: +44 (0)7713 880197
-----Original Message-----
From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of
LEONARDO VALENTINO CRUZ
Sent: 12 July 2004 12:49
To: [EMAIL PROTECTED]
Subject: encryption messages


--- Recebido de   POINFOR.UX90825 351.21.3117492             04-07-12
      --------

  -> [EMAIL PROTECTED]


Hi all,

An auditors want to do encryption of messages that across channel of
MQseries.

Scenario:
 Aix encrypt messages, and send by channel to MQSeries of the OS/390

 MqSeries in OS/390 with CICS decrypt messages, and process

 and encrypt the response and send by sender channel to AIX

 Aix decrypt messages and receive a message.

????????


Anyone help ?

thanks

Leonardo Cruz
Sistemas CICS/MQSeries
[EMAIL PROTECTED]
Av. da Liberdade, 222 - 9º Piso
1250-148 Lisboa
351 21 311 7492
BBVA Portugal
DISCLAIMER
 This message is intended exclusively for the named person. It may
 contain confidential, proprietary or legally privileged information. No
 confidentiality or privilege is waived or lost by any mistransmission.
 If you receive this message in error, please immediately delete it and
 all copies of it from your system, destroy any hard copies of it and
 notify the sender. You must not, directly or indirectly, use, disclose,
 distribute, print, or copy any part of this message if you are not the
 intended recipient.  Any views expressed in this message are those of
 the individual sender, except where the message states otherwise and the
 sender is authorized to state them to be the views of 'BBVA'. Please
 note that internet e-mail neither guarantees the confidentiality nor the
 proper receipt of the message sent. If the addressee of this message
 does not consent to the use of internet e-mail, please communicate it to
 us immediately.

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://vm.akh-wien.ac.at/MQSeries.archive

Reply via email to