| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQ / encryption / thoughts |
« View previous topic :: View next topic » |
| Author |
Message
|
| RogerLacroix |
 Posted: Fri Aug 20, 2010 3:37 pm Post subject: MQ / encryption / thoughts |
 |
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
All,
This is a propeller-hat security discussion as it applies to MQ, so it may not be everyone's cup of tea. 
I love programming but by no means am I a security expect. I have learned my lessons the hard way (i.e. MQISD and XTEA) over the last few years, so I would rather ask first, build second, than bang my head against the wall in a year.
As you may have noticed, I recently started a beta for MQ Message Encryption (MQME) product. The point of the product is to encrypt data at rest in the queue using AES. My thoughts were that a client would secure the queue manager with MQAUSX, use setmqaut to set permissions and use MQME for those queues with sensitive data.
From a security high-level:
- Authentication handled by MQAUSX
- Authorization handled by MQ's OAM (setmqaut / dspmqaut)
- Encryption handled by MQME
During the MQME encryption process, it puts its own propriety structure / signature on each message such that before MQME decrypts a message, it verifies that the encrypted message was generated by MQME (and not by some hacker somehow injecting a message into the queue file).
Jump forward: Today, I received an email from a beta tester saying "Our security group requires a digital signature on the messages."
I swear, most MQAdmin like my stuff but its their company's security groups that give me all kinds of grief. 
After a lot of research basically I find the same comment across the web as what Wikipedia has:
| Wikipedia wrote: |
| A digital signature is a mathematical scheme for demonstrating the authenticity of a digital message or document. A valid digital signature gives a recipient reason to believe that the message was created by a known sender, and that it was not altered in transit. |
The $10,000 questions is: If MQME is not providing End-To-End encryption, just encryption of data at rest in the queue, then does MQME need create and assign a digital signature for each message?? (and do the verification of the message on the decryption process).
If so, why?
And if I have to go down the digital signature path, then what algorithm should I use? MD5, SHA-1 or SHA-2. Wikipedia says that MD5 and SHA-1 should not be used. Any thoughts?
Anybody with security knowledge want to comment / discussion this? Please.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Aug 20, 2010 5:14 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
The clients I've talked with, those having been beaten with Sox-ley documentation, wanted nothing less than their messages resting in queues be secured SSL/PKI/CA-like.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Aug 21, 2010 5:44 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Roger, It looks like for the paranoid purposes you hear a simple MD5 or SHA1 hashing is not enough.
The reason is simple: anybody could intercept the message, change it, and drop and recreate the hash (signature) and the receiver would not be the wiser.
This is why the hash / signature needs to be done 2 fold. It usually involves a public / private key pair on top of the MD5 or SHA1 hash.
This way you assure non repudiation. If the message got changed, it is not likely that you can recreate the hash without the sender's private key. The verification is done with the sender's public key.
Note that this works as well for a message in clear as for an encrypted message. You might want to consider encapsulating the message in a secure object. (see SSL stuff for that) (guarded objects, signed objects, encrypted objects, sealed objects etc...)
See ref for sealed objects in http://java.sun.com/developer/technicalArticles/ALT/serialization/
Have fun 
_________________
MQ & Broker admin
Last edited by fjb_saper on Sat Aug 21, 2010 6:09 am; edited 3 times in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Aug 21, 2010 5:48 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
I would have referred to this as "lawsuit avoidance," but paranoia works, too.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Sat Aug 21, 2010 1:10 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
Hi,
Wow, did you guys ever take a hard-left out to left field. 
Please don't take my comments the worng way, as I'm just being blunt.
| bruce2359 wrote: |
| The clients I've talked with, those having been beaten with Sox-ley documentation, wanted nothing less than their messages resting in queues be secured SSL/PKI/CA-like. |
Humm.. SSL is the framework which includes ciphers like AES (Advanced Encryption Standard). PKI is the infrastructure which includes SSL and CA.
Hence, AES which MQME is using, is a SOX compliant cipher. My question was only related to added the digital signature to the encrypted message.
| fjb_saper wrote: |
| Roger, It looks like for the paranoid purposes you hear a simple MD5 or SHA1 hashing is not enough. |
No. I said I read it on Wiki and not that the client was complaining about it.
| fjb_saper wrote: |
| The reason is simple: anybody could intercept the message, change it, and drop and recreate the hash (signature) and the receiver would not be the wiser. |
What? MQME is an API Exit that is running in the client application's address space. An API Exit is invoked when the application does a get/put to/from a queue and it sits between the application and the queue file. How in the world is anything being intercepted?
If you were talking about messages hoping between queues / queue managers then that is not what I am referring to.
| fjb_saper wrote: |
| This way you assure non repudiation. If the message got changed, it is not likely that you can recreate the hash without the sender's private key. The verification is done with the sender's public key. |
If MQME is guarding the queue file and the message is encrypted, please explain how a message could possibly get changed while it is in the queue file?
For those who do not know, MQ employs its own hash to make sure that the data (messages) in the queue file have not being tampered with.
| fjb_saper wrote: |
| You might want to consider encapsulating the message in a secure object. (see SSL stuff for that) (guarded objects, signed objects, encrypted objects, sealed objects etc...) |
Say what? That IS what MQME is doing.
I am glad that people want to discuss security but carefully and fully read my original posting.
To summarize:
- MQME is an API Exit that encrypts messages using AES (128, 192 or 256-bit)
- An API Exit resides in the application's address space and in the case of MQME is invoked for MQPUT and MQGET API calls.
- MQME is not providing End-To-End encryption, just encryption of the message data WHILE it sits in the queue.
The question I wanted answer, based on the criteria listed above, is:
| RogerLacroix wrote: |
| If MQME is not providing End-To-End encryption, just encryption of data at rest in the queue, then does MQME need create and assign a digital signature for each message?? (and do the verification of the message on the decryption process). |
And
| RogerLacroix wrote: |
| If so, why? |
The 'why' is very important.
Here is a good analogy:
- Bruce is the client application (putting app)
- FJB is another application (getting app)
- My pocket is the queue (aka queue file)
- I am MQME
Hence, Bruce gives me a piece of paper (aka message). I take the paper, put it in an envelope, sealed it (aka encrypted) and put the envelope in my pocket.
Now FJB requests the piece of paper, I (MQME) first verifies that FJB is authorized to receive the paper, and if so, I remove the paper from the envelope (decrypt) and hand it to FJB.
So, can anyone answer my question, do I need a digital signature based on the above. I do not want to hear about SSL/PKI or End-To-End stuff (repudiation). I only want to know (1) if I need a digital signature for the message (i.e. between MQME and the queue file) and (2) if so, why.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Aug 21, 2010 1:53 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9399
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Wow, did you guys ever take a hard-left out to left field. |
It happens.
| Quote: |
| My question was only related to added the digital signature to the encrypted message. |
Sorry. My reply was more about the marketing issue - what the customer wanted - and not so much a technical one. I didn't ask them what they would settle for if IBM or the industry couldn't provide what SSL/PKI/CA offers for MQ channels.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Aug 22, 2010 12:40 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| RogerLacroix wrote: |
| fjb_saper wrote: |
| The reason is simple: anybody could intercept the message, change it, and drop and recreate the hash (signature) and the receiver would not be the wiser. |
What? MQME is an API Exit that is running in the client application's address space. An API Exit is invoked when the application does a get/put to/from a queue and it sits between the application and the queue file. How in the world is anything being intercepted?
If you were talking about messages hoping between queues / queue managers then that is not what I am referring to.
|
I was thinking here about a "man in the middle" type of attack.
However I believe SOX is more worried about a man at the source type.
Like someone in the enterprise sending a document without being the "authorized" source...
| RogerLacroix wrote: |
| fjb_saper wrote: |
| This way you assure non repudiation. If the message got changed, it is not likely that you can recreate the hash without the sender's private key. The verification is done with the sender's public key. |
If MQME is guarding the queue file and the message is encrypted, please explain how a message could possibly get changed while it is in the queue file?
For those who do not know, MQ employs its own hash to make sure that the data (messages) in the queue file have not being tampered with. |
Read, decrypted, changed, encrypted and put. All this before it is consumed by the target app.
| RogerLacroix wrote: |
| fjb_saper wrote: |
| You might want to consider encapsulating the message in a secure object. (see SSL stuff for that) (guarded objects, signed objects, encrypted objects, sealed objects etc...) |
Say what? That IS what MQME is doing.
|
Then I don't understand your worries as you should already have a signed message if you're dealing in sealed objects...
| RogerLacroix wrote: |
I am glad that people want to discuss security but carefully and fully read my original posting.
To summarize:
- MQME is an API Exit that encrypts messages using AES (128, 192 or 256-bit)
- An API Exit resides in the application's address space and in the case of MQME is invoked for MQPUT and MQGET API calls.
- MQME is not providing End-To-End encryption, just encryption of the message data WHILE it sits in the queue.
The question I wanted answer, based on the criteria listed above, is:
| RogerLacroix wrote: |
| If MQME is not providing End-To-End encryption, just encryption of data at rest in the queue, then does MQME need create and assign a digital signature for each message?? (and do the verification of the message on the decryption process). |
And
| RogerLacroix wrote: |
| If so, why? |
The 'why' is very important.
Here is a good analogy:
- Bruce is the client application (putting app)
- FJB is another application (getting app)
- My pocket is the queue (aka queue file)
- I am MQME
Hence, Bruce gives me a piece of paper (aka message). I take the paper, put it in an envelope, sealed it (aka encrypted) and put the envelope in my pocket.
Now FJB requests the piece of paper, I (MQME) first verifies that FJB is authorized to receive the paper, and if so, I remove the paper from the envelope (decrypt) and hand it to FJB.
So, can anyone answer my question, do I need a digital signature based on the above. I do not want to hear about SSL/PKI or End-To-End stuff (repudiation). I only want to know (1) if I need a digital signature for the message (i.e. between MQME and the queue file) and (2) if so, why.
Regards,
Roger Lacroix
Capitalware Inc. |
You did not specify whether the encryption was also signing the message b efore putting it to the queue. Nor did you specify if there was a separation between message and signature...
encapsulation: signed object <= sealed object <= guarded object...
That level should satisfy any SOX requirement.
Note that depending on level of paranoia the order between signed object and sealed object is interchangeable.
Typically you might use 2 different keys: One for signing (individual level) and one for encryption (enterprise level)...
Indeed if you use an enterprise level key for encryption there is no guarantee as to who sent the message... This is why SOX would require the message to be signed as the signature would define who in the enterprise sent it...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Sun Aug 29, 2010 7:53 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
Hi,
| fjb_saper wrote: |
| Like someone in the enterprise sending a document without being the "authorized" source... |
| RogerLacroix wrote: |
| - Authentication handled by MQAUSX |
| fjb_saper wrote: |
| You did not specify whether the encryption was also signing the message b efore putting it to the queue. |
That was my question.
| RogerLacroix wrote: |
| If MQME is not providing End-To-End encryption, just encryption of data at rest in the queue, then does MQME need create and assign a digital sign$ature for each message?? |
| fjb_saper wrote: |
| Nor did you specify if there was a separation between message and signature... |
Good idea. I did not know about this requirement.
I am going to make adding a digital signature optional in MQME. I have decided to use SHA-2 for creating the digital signature.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Aug 29, 2010 8:05 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
And please remember that the signature should be done with the private key of the sender, not with the encryption key.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Sun Aug 29, 2010 8:22 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
Hi,
| fjb_saper wrote: |
| And please remember that the signature should be done with the private key of the sender, not with the encryption key. |
As noted above, MQME is not providing End-To-End encryption but encryption for "data at rest" but I know what you are referring to with the signature being guarded/encrypted.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Aug 29, 2010 12:11 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| RogerLacroix wrote: |
Hi,
| fjb_saper wrote: |
| And please remember that the signature should be done with the private key of the sender, not with the encryption key. |
As noted above, MQME is not providing End-To-End encryption but encryption for "data at rest" but I know what you are referring to with the signature being guarded/encrypted.
Regards,
Roger Lacroix
Capitalware Inc. |
Exactly...
In Java tearms you are providing encryption only when at rest.
The message may or may not be signed, depending on the set up of the sender. What you have on the queue is a sealed object...
So what you need to provide is:
- a configurable client with encapsulation that can produce a normal message or a signed message depending on configuration (key database...).
- The next step is for a message exit to seal (encrypt) the message before it hits the queue.
- On read the mirror message exit will need to decrypt the message (unseal)
- The receiver client will need to be configurable with a key database and needs to be able to verify the signed message, if a signature exists and there is a matching key. Public key information should then be printed so that the viewer can know who signed the message..., or receive message + signature intact in case the signature cannot be verified (missing key or key chain, or incomplete key chain)
I know, quite easy to talk about but much more difficult to implement...
Most aptly described in java here http://www.javaworld.com/javaworld/jw-11-2000/jw-1117-howto.html
Note that java6 offers the XML digital signature API. JSR105 and ECC cryptography (Elliptic Curve Ciphers)
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Sun Aug 29, 2010 5:38 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
Hi,
Yes from a 10,000 foot view your flow is correct but you are thinking from an application point of view.
An API Exit (MQME is an API Exit) is hidden and is invoked "during" (within) an MQGET and/or MQPUT API call. There is no 'returning the signature' or 'did the signature verify correctly' API calls for the application to check.
On an MQGET call:
- if the user is authorized, the message is verified, decrypted returned to the application via MQ. Soon I will add support for a digital signature processing.
- if the user is not authorized, then MQME returns the following string to the calling application: "Message protected by MQ Message Encryption.". Originally, I had it returning the encrypted message but I thought some company's security guru would say that an encrypted message is a security risk. So, I changed it to the above string.
The 2nd best feature of MQME, is that you can lock out mqm / QMQM / MUSR_MQADMIN UserIDs from viewing the message content (decrypting the message). If an MQAdmin (or anyone else) opens a MQME protected queue and attempts to read the messages, they will not get an error but the message content will be "Message protected by MQ Message Encryption.".  
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Aug 29, 2010 6:46 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
Do you also roll back an unsuccessful decryption attempt? i.e. can't take the message off the queue because you don't have the decryption key...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Sun Aug 29, 2010 7:20 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3253
Location: London, ON Canada
|
Hi,
| fjb_saper wrote: |
| Do you also roll back an unsuccessful decryption attempt? |
That's not exactly how things work in an API Exit. If MQME (API Exit) has an issue, missing PassPhrase, invalid MQME structure, invalid digital signature (future code), etc... then MQME returns MQXCC_FAILED to MQ. MQ then returns a reason code of 2374 to the application. There is no roll back because the MQ API call never completed.
Remember, an API Exit functions at a different layer. See if this makes sense: an API Exit functions within MQ itself but runs in the address space of the application performing the MQ API call. Clear as mud!
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Aug 30, 2010 10:03 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20696
Location: LI,NY
|
| RogerLacroix wrote: |
Hi,
| fjb_saper wrote: |
| Do you also roll back an unsuccessful decryption attempt? |
That's not exactly how things work in an API Exit. If MQME (API Exit) has an issue, missing PassPhrase, invalid MQME structure, invalid digital signature (future code), etc... then MQME returns MQXCC_FAILED to MQ. MQ then returns a reason code of 2374 to the application. There is no roll back because the MQ API call never completed.
Remember, an API Exit functions at a different layer. See if this makes sense: an API Exit functions within MQ itself but runs in the address space of the application performing the MQ API call. Clear as mud!
Regards,
Roger Lacroix
Capitalware Inc. |
Thanks that's enough for my peace of mind...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
