Author |
Message
|
timblackledge |
Posted: Mon Mar 21, 2005 10:08 am Post subject: MQ API Exit For Message Encryption |
|
|
 Newbie
Joined: 21 Oct 2004 Posts: 5 Location: Boca Raton FL
|
Is anyone aware of an encryption library that is available that utilizes the MQ API exit available in 5.3? This could be from IBM, third parties, etc. I would prefer buy or borrow rather than build. Trying to avoid having to develop an encryption exit based on the API exit sample. But, I will if I must. The objective is to encrypt a message on the put and decrypt on the get transparent to any applications or products running on top of MQ.
Thanks in advance for your help. _________________ Tim Blackledge
EAI Architect
Certified MQSeries Engineer, Developer and Solutions Expert |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Mar 21, 2005 10:53 am Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
|
Back to top |
|
 |
timblackledge |
Posted: Mon Mar 21, 2005 11:22 am Post subject: MQ API Exit For Message Encryption |
|
|
 Newbie
Joined: 21 Oct 2004 Posts: 5 Location: Boca Raton FL
|
Peter,
Thanks for the post. I looked at the DataSecure product in my research. It does not seem to use the MQ API exit. True? It also is not clear from the doc I could find how "transparent" it is to the "application". In my case, the "application" will be WBI Message Broker. So, the product or library I choose must NOT require that the application be relinked with any new libraries. That is why I was targeting a product that uses the MQ API Exit which would be hooked by the queue manager at the MQPut MQGet execute time. _________________ Tim Blackledge
EAI Architect
Certified MQSeries Engineer, Developer and Solutions Expert |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Mar 21, 2005 11:26 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
WebSphere MQ Extended Security edition comes with Tivoli Access Manager.
I think that includes facilities for encrypting messages on the queue. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
Michael Dag |
Posted: Mon Mar 21, 2005 2:46 pm Post subject: |
|
|
 Jedi Knight
Joined: 13 Jun 2002 Posts: 2607 Location: The Netherlands (Amsterdam)
|
Just curious... what type of application/business requires messages to be encrypted on the queue?
I get encryption of messages in transfer over a network, but what justifies encryption on a queue? _________________ Michael
MQSystems Facebook page |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Mar 21, 2005 3:20 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
MichaelDag wrote: |
Just curious... what type of application/business requires messages to be encrypted on the queue?
I get encryption of messages in transfer over a network, but what justifies encryption on a queue? |
Data that the MQ Admin has no busy knowing.
Like, umm, almost any data shipped via MQ...  _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
clindsey |
Posted: Mon Mar 21, 2005 3:55 pm Post subject: |
|
|
Knight
Joined: 12 Jul 2002 Posts: 586 Location: Dallas, Tx
|
If you encrypt on a put and decrypt on the get using API Exits, I believe an administrator can still browse the message and see the original data. The only data that is really encrypted is the queue data that is backed up to the file system.
Charlie |
|
Back to top |
|
 |
PeterPotkay |
Posted: Mon Mar 21, 2005 4:56 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
If the message is "Hi Peter", but the API exit or the application itself encrypts it to "#$ (*#!&" as it does the MQPUT, then I can't see any way an MQ admin or Sys Admin would be able to figure out what the message is as it sits on the queue. _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
JT |
Posted: Mon Mar 21, 2005 5:48 pm Post subject: |
|
|
Padawan
Joined: 27 Mar 2003 Posts: 1564 Location: Hartford, CT.
|
Quote: |
Just curious... what type of application/business requires messages to be encrypted on the queue?
I get encryption of messages in transfer over a network, but what justifies encryption on a queue? |
For a number of leading U.S. financial institutions, it's the Gramm-Leach-Bliley Act. |
|
Back to top |
|
 |
Michael Dag |
Posted: Tue Mar 22, 2005 12:56 am Post subject: |
|
|
 Jedi Knight
Joined: 13 Jun 2002 Posts: 2607 Location: The Netherlands (Amsterdam)
|
jefflowrey wrote: |
MichaelDag wrote: |
Just curious... what type of application/business requires messages to be encrypted on the queue?
I get encryption of messages in transfer over a network, but what justifies encryption on a queue? |
Data that the MQ Admin has no busy knowing.
Like, umm, almost any data shipped via MQ...  |
that can be handled by a confidentiality clause in your working agreement.
Is there something similar technically for dba's and databases?
Like I said before, I understand the need and justification to encrypt messages while in transport, but who can access data sitting on a queue other then the people who have a 'right' to access this information like system operators/mqadmins etc.
Just playing devils advocate here, I am not opposed to encrypting data in the system, just want to know what ultimately justifies doing this instead of "they asked it" ... _________________ Michael
MQSystems Facebook page |
|
Back to top |
|
 |
clindsey |
Posted: Tue Mar 22, 2005 6:08 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002 Posts: 586 Location: Dallas, Tx
|
Quote: |
If the message is "Hi Peter", but the API exit or the application itself encrypts it to "#$ (*#!&" as it does the MQPUT, then I can't see any way an MQ admin or Sys Admin would be able to figure out what the message is as it sits on the queue.
|
Peter,
The MQPUT exit would write the messages as "#$ (*#!&". Then a subsequent MQGET exit would convert "#$ (*#!&" to "Hi Peter" before it delivered it to the user's buffer. So, anyone who had authority to browse or get the message from the queue would see "Hi Peter".
Of course, the MQGET exit could provide filtering where it made checks on the user or the application running the code and only decrypt when proper authorization was in place.
Charlie |
|
Back to top |
|
 |
timblackledge |
Posted: Tue Mar 22, 2005 6:22 am Post subject: What drove my question |
|
|
 Newbie
Joined: 21 Oct 2004 Posts: 5 Location: Boca Raton FL
|
Both Visa and Mastercard have requirements for stored cc data. This is in addition to the requirement to encrypt across data links. The following is an excerpt from a publicly available document "Payment Card Industry Data Security Standard" at :
http://www.usa.visa.com/download/business/accepting_visa/ops_risk_management/cisp_PCI_Data_Security_Standard.pdf?it=r4|/business/accepting_visa/ops_risk_management/cisp_merchants%2Ehtml|PCI%20Data%20Security%20%20Standard
"3.4 Render sensitive cardholder data unreadable anywhere it is stored (including data on portable
media, backup media, in logs, and data received from or stored by wireless networks) by using
any of the following approaches:
One-way hashes (hashed indexes), such as SHA-1
Truncation
Index tokens and PADs, with the PADs being securely stored
Strong cryptography, such as Triple-DES 128-bit or AES 256-bit with associated key
management processes and procedures.
The MINIMUM account information that needs to be rendered unreadable is the payment card
account number."
Thanks for the help. _________________ Tim Blackledge
EAI Architect
Certified MQSeries Engineer, Developer and Solutions Expert |
|
Back to top |
|
 |
PeterPotkay |
Posted: Tue Mar 22, 2005 4:24 pm Post subject: |
|
|
 Poobah
Joined: 15 May 2001 Posts: 7722
|
Thanks Charlie, yes if the API exit ran for every MQGET by every application, than that would be pretty useless.
Not an MQ API Exit expert, but hopefully it could be configured to kick off only when App ABC did the MQGET? And not for any other app? _________________ Peter Potkay
Keep Calm and MQ On |
|
Back to top |
|
 |
malammik |
Posted: Tue Mar 22, 2005 6:41 pm Post subject: |
|
|
 Partisan
Joined: 27 Jan 2005 Posts: 397 Location: Philadelphia, PA
|
The way API exits work will allow applications not wanting to use the exit, not use it. In order to invoke an API that is utilizing an exit, separate naming convention had been put in place. So generally, if your api is calling MQPUT to do the put, but if it wanted to utilize a put with the exit, it would call MQ_PUT_EXIT(&exitparams, &exitcontext, all other parameters for standard mq put in the same order). The question that arises now, is what if you have many different put exits that you would like to use? My guess is that you would have to have a generic exit and pass exit type in your exitparams, to let the generic exit know what type of exit(s) your application is interested in. _________________ Mikhail Malamud
http://www.netflexity.com
http://groups.google.com/group/qflex |
|
Back to top |
|
 |
clindsey |
Posted: Tue Mar 22, 2005 7:01 pm Post subject: |
|
|
Knight
Joined: 12 Jul 2002 Posts: 586 Location: Dallas, Tx
|
Quote: |
The way API exits work will allow applications not wanting to use the exit, not use it.
|
Mikhail, IMHO I would disagree with this. I believe it is the other way around. An application cannot prevent the exit from getting called. But, the exit can control if or how an application uses it. It can be coded to not be registered for some apps at all. If it is registered, then when it gets called, it can query the app name and decide whether or not to take any actions. Also, each before and after API exit is independent, so MQPUT behavior may be different than MQGET behavior if desired.
Charlie |
|
Back to top |
|
 |
|