Protecting Message Data by Implementing MQ AMS End to End Message Security
Introduction:
Key Concepts MQ AMS augments IBM MQ security by providing data protection of messages. Three “Qualities of Protection” (QOP) are provided:
Integrity (signed)
IBM MQ messages are signed when put on a queue and the signature embedded into the message is verified when the message is retrieved. The signature identifies the sender of the message and ensures that the content of the message has not been changed.
MQ AMS uses PKCS #7 data-envelope to envelop a message in a digital signature.
Privacy (sealed)
IBM MQ messages are signed as above but the content of the message is also encrypted. The key used to encrypt messages is itself encrypted for each potential recipient so that the messages can be retrieved by one or more recipients.
MQ AMS uses PKCS #7 data-envelope to envelop a message in a digital signature.
Confidentiality (encrypted only)
IBM MQ messages are encrypted end-to-end using a symmetric key and are not digitally signed. This reduces the amount of asymmetric key operations by half and improves performance.
Optionally the encryption keys can be reused for multiple messages going to the same recipient. The second and subsequent messages incur no asymmetric key operations which keeps performance similar to plaintext/unprotected message throughput.
Data protection is provided by various interceptors relying on configuration files, PKI keystores and certificates. This is in addition to the standard protection available for IBM MQ objects using the IBM MQ Object Authority Manager (OAM) or SAF (via a product such as IBM’s RACF) on z/OS. The diagram below depicts the overall architecture:
Interceptors MQ AMS implements security by intercepting IBM MQ API calls. The following APIs are supported:
• Message Queue Interface (MQI)
• Java Message Service (JMS)
• IBM MQ Java Service (JMS)
• IBM MQ Java Classes Three interceptors are provided:
• IBM MQ server interceptor To protect messages put or get by applications using the mqm library and using the interprocess communication (IPC), also called bindings mode. This interceptor will also protect messages for Java applications (either using the MQ Java API or JMS) connecting in MQ bindings mode.
• IBM MQ C client interceptor To protect messages put or get by applications using the mqm client library and therefore connecting using a (non-Java) MQ client connection.
• IBM MQ Java interceptor (JMS and MQ Java) To protect messages put or get by Java applications (MQ Java API or JMS) using either client connections or bindings mode. Note that if you use this interceptor for applications using Java bindings mode, you should consider disabling the server interceptor to avoid signing/encrypting messages twice. Public Key Infrastructure (PKI) and Certificates MQ AMS uses Public Key Infrastructure (PKI) identities to represent users or applications. The identities are used to sign and encrypt messages. An identity is represented by the distinguished name (DN) of a personal X.509 (v2/v3) certificate associated with the signed and/or encrypted message. To authenticate this authority, the user or application must have access to a keystore containing a public certificate and an associated private key. A mechanism is provided to map the OS identity of the user or application to the specific keystore file. Object Authority Manager (OAM) MQ AMS provides message security. It does not provide authorization services for IBM MQ objects. The task to authorize access to IBM MQ resources (queue manager, queues and other objects) remains the responsibility of the IBM MQ Object Authority Manager (OAM) or RACF (or other SAF) on z/OS. When an interceptor intercepts the MQ API calls from an application, it delegates the authorization request to the IBM MQ authority service. Error Handling MQ AMS defines an error handling queue (SYSTEM.PROTECTION.ERROR.QUEUE) to manage messages that contain errors or messages that cannot be decrypted. If a received message does not meet the security requirements for the queue it is on, then the message is moved to the error handling queue. The following is a non-exclusive list of possible reasons why a message might be sent to the error handling queue:
• Quality of protection mismatch
• Decryption error
• PDMQ header error
• Size mismatch
• Encryption algorithm strength mismatch
• Unknown error The system error handling queue can optionally be defined as an alias queue pointing to another queue.
The Objective of this lab is to demonstrate the simultaneous implementation of IBM® MQ Security features like OAM, SSL, AMS & CHLAUTH in an Integrated Test Case Scenario which can be taken as a template for Large Scale Implementation at Enterprise Level. The specific configuration of Advanced Message Security (AMS) feature is required to meet the regulatory requirement of PCI DSS (Payment Card Industry Data Security Standard) which mandates business critial information like Credit / Debit Cards & other important Bank transactions to be secured & encrypted.
The above diagram depicts our Test Case Scenario at High Level As per the above diagram, Application user Alice puts a messages through SSL/TLS enabled Client Connection Channel into an AMS enabled Cluster Queue Alias (AMS_A) defined under TEST1 Qmgr. This Q Alias points to AMS enabled Cluster Local Queue (AMS_E) defined under TEST2 Qmgr through a secure Cluster Channel. Once the business critical message(s) reaches Q Local (AMS_E), it will be encrypted using pre- defined AMS rules set at the Queue Level. Only authorized Application user Bob should be able to retrieve the the data from the Queue (AMS_E). Going by this configuration, even ‘mqm’ or ‘root’ user does Not have the default authority to read / browse the message from Queue (AMS_E) without setting explicit AMS security rules! Hence, highly sensitive Customer data like Credit / Debit Card information is secured from the point it originates from Application user Alice till it is consumed by Application user Bob from the other end of the secure MQ network. From Implementation Perspective, we have created & configured the following components: 1. Created a MQ Cluster called ‘POC’ having 3 Qmgrs TEST(1,2,3) where TEST(1,2) are Full Repository (FR) Qmgrs & TEST3 is the Partial Repository(PR) Qmgr. 2. Created an Internal Certificate Authority (CA) for signing Certificate Requests for MQ Clients & Cluster Qmgrs. 3. Configured SSL/TLS at Cluster Channels using in-house Certificate Authority (CA) 4. Created a dedicated Queue Manager CCDT for Administration & Maintenance of Client Connection Channel file (CCDT) called AMQCLCHL.TAB. 5. Configured MQ Clients (Alice & Bob) connectivity with Qmgrs using CCDT. 6. Configured Channel Authentication (CHLAUTH) rules to Allow / Block incoming requests from MQ Client users Alice & Bob. 7. Created & Configured have 2 AMS enabled Cluster Queues AMS_A (QA) defined under TEST1 & AMS_E (QL) define under TEST2 Qmgrs respectively. 8. AMS Keystores are created using Self-Signed Certificates of Alice & Bob. With these Security Configurations in place, this Test Case demonstrate a comprehensive security solution by making use of most of the built-in IBM MQ Security features like OAM, SSL/TLS, CHLAUTH & AMS to achieve End to End Message Security Solution which includes Authentication, Authorization, Encryption & Digital Signature. Thus, MQ messages are secured while in transit through SSL/TLS enabled MQ Channels as well as while sitting in the AMS enabled Local Queue before being processed by receiving Application. Step-by-step 1. MQ Configuration Items
This entire article on IBM MQ Security Solution can be broken down into 4 Major parts: 1. Creation & Configuration of MQ Cluster with SSL/TLS Enabled Channels. 2. Configuration of SSL/TLS enabled MQ Client Connectivity with Cluster Queue Managers using CCDT file AMQCLCHL.TAB. 3. Setting up the CHLAUTH rules at Channel Level for enhanced Security. 4. Implementation of AMS Security Rules at Queue Level. #################################### Internal Certificate Authority (CA): /home/mqm/CA TEST1 Qmgr’s SSL Keystore: /var/mqm/qmgrs/TEST1/ssl TEST2 Qmgr’s SSL Keystore: /var/mqm/qmgrs/TEST2/ssl TEST3 Qmgr’s SSL Keystore: /var/mqm/qmgrs/TEST3/ssl Alice’s home directory: /home/alice/ Alice’s SSL Keystore: /home/alice/keystore Bob’s home directory: /home/bob Bob’s SSL Keystore: /home/bob/keystore CCDT File: /home/CCDT/AMQCLCHL.TAB ==> Centralized Location to be used by both Alice & Bob CCDT File Administration: /var/mqm/qmgrs/CCDT/@ipcc/AMQCLCHL.TAB ##################################################### 2. Define Queue Managers
This is the first part of the exercise wherein we are going to create 3 Qmgrs & define the Listener Process for each. Create TEST1 Qmgr ################# crtmqm TEST1 Strmqm TEST1 Runmqsc TEST1 DEFINE LISTENER(TEST1.LISTENER) TRPTYPE(TCP) PORT(1417) CONTROL(QMGR) end Create TEST2 Qmgr ################# crtmqm TEST2 DEFINE LISTENER(TEST2.LISTENER) TRPTYPE(TCP) PORT(1415) CONTROL(QMGR) Create TEST3 Qmgr ################# crtmqm TEST3 DEFINE LISTENER(TEST3.LISTENER) TRPTYPE(TCP) PORT(1416) CONTROL(QMGR)
Checkpoint Test:
You can Stop / Start the Queue Managers and listeners via the commands or through the MQ Explorer; verify if the Listener Programs are running using the command: ps -ef | grep runmqlsr Observation:
3. Create a MQ Cluster
In this Section, we are going to create a Cluster called POC & make 3 Qmgrs part of the Cluster. Configured TEST1 & TEST2 as the Full Repository (FR) & TEST3 as the Partial Repository (PR) Qmgrs. The two FR Qmgrs should be fully interconnected using explicitly defined Cluster Sender/Receiver Channel pairs.On the other hand, the PR Qmgr must be fully interconnected with any one of the FR Qmgr (In this Case, TEST1 Qmgr). runmqsc TEST1(FR) ################# ALTER QMGR REPOS(POC) DEFINE CHANNEL(TO.TEST1) CHLTYPE(CLUSRCVR) CONNAME(‘127.0.0.1(1417)’) CLUSTER(POC) DEFINE CHANNEL(TO.TEST2) CHLTYPE(CLUSSDR) CONNAME(‘127.0.0.1(1415)’) CLUSTER(POC) DEFINE QA(AMS_A) TARGET(AMS_E) CLUSTER(POC)
runmqsc TEST2(FR) ################# ALTER QMGR REPOS(POC) DEFINE CHANNEL(TO.TEST2) CHLTYPE(CLUSRCVR) CONNAME(‘127.0.0.1(1415)’) CLUSTER(POC) DEFINE CHANNEL(TO.TEST1) CHLTYPE(CLUSSDR) CONNAME(‘127.0.0.1(1414)’) CLUSTER(POC) DEFINE QL(AMS_E) CLUSTER(POC)
runmqsc TEST3(PR) ################# DEFINE CHANNEL(TO.TEST3) CHLTYPE(CLUSRCVR) CONNAME(‘127.0.0.1(1416)’) CLUSTER(POC) DEFINE CHANNEL(TO.TEST1) CHLTYPE(CLUSSDR) CONNAME(‘127.0.0.1(1417)’) CLUSTER(POC) *** Explicitly defined Cluster Sender Channel to FR Qmgr TEST1 *** Note: Created a Clustered QAlias (AMS_A) under TEST1 Queue Manager whose target Q is Clustered Local Q (AMS_E) defined under TEST2 Qmgr. Checkpoint Test: Verify if the Cluster Sender/Receiver Channels are running. Put a sample test message into the Alias Q (AMS_A) & see if the message is getting collected into the Local Q (AMS_E) using the MQ utility programs amqsput & amqsget.
4. Create Certificate Authority (CA)
In this Step, we are going to create the CA’s Keystore, generate & extract the Self-Signed Public Certificate (ssl_ca.cer) which acts as the Root CA for distribution among the 3 Queue Managers as well as to Applications users Alice & Bob in later Steps. (Create CA using ‘mqm’ ID) Create the keystore for CA (/home/mqm/CA) ####################################### 1. Sudo runmqckm -keydb -create -db SSL_CA -pw Passw0rd -type cms -expire 365 - stash Create Self Signed CA Certificate ############################# 2. Sudo runmqckm -cert -create -db SSL_CA.kdb -pw Passw0rd -label ssl_ca -dn “CN=SSL CA,O=IBM,C=China” -expire 365
List Certificate under CA’s Keystore ################################ 3. Sudo runmqckm -cert -list -db SSL_CA.kdb -pw Passw0rd
Extract Public (Self Signed) CA Certificate ###################################### 4. Sudo runmqckm -cert -extract -db SSL_CA.kdb -pw Passw0rd -label ssl_ca -target ssl_ca.cer -format ascii
Observation:
5. Secure MQ Cluster using SSL
Creation of Keystores, CSR files & Digitally Signed by Internal CA for 3 Qmgrs TEST(1,2.3) In the subsequent Steps mentioned below, we are going to create the Keystores for all 3 Queue Manager (TEST1,2,3), generate the CSR (Certificate Request) files & get it signed by CA. Once these 3 steps are completed, we will Add the Root CA Certificate (ssl_ca.cer) into the Queue Manager’s keystore along with Receiving the CA Signed certificates (e.g: test1.cer) into respective Qmgr’s key-repositories. After that, we have to alter the SSLKEYR parameter of the QMGRs to point to correct keystores. Then define the secure Cluster Receiver channel & select any TLS Cipher Spec algorithm. Note: At this point, we are NOT Defining the SSL enabled Cluster Sender Channel.
Create the keystore for TEST1 Qmgr (/var/mqm/qmgrs/TEST1/ssl) ####################################################### 1. runmqckm -keydb -create -db TEST1 -pw Passw0rd -type cms -expire 365 -stash
Create a Certificate Request for TEST1 ################################### 2. runmqckm -certreq -create -db TEST1.kdb -pw Passw0rd -label ibmwebspheremqtest1 -dn “CN=TEST1 Queue Manager,O=IBM,C=India” -file test1.req
Sign TEST1’s Certificate using CA (/home/mqm/CA) ########################################## 3. runmqckm -cert -sign -file test1.req -db SSL_CA.kdb -pw Passw0rd -label ssl_ca - target test1.cer -format ascii -expire 364
ADD CA’s Public certificate into TEST1’s Keystore ########################################### 4. runmqckm -cert -add -db TEST1.kdb -pw Passw0rd -label ssl_ca -file ssl_ca.cer - format ascii -trust enable
RECEIVE the CA Signed Certificate into TEST1’s Keystore ################################################## 5. runmqckm -cert -receive -db TEST1.kdb -pw Passw0rd -file test1.cer -format ascii
List Certificate under TEST1’s Keystore #################################### 6. runmqckm -cert -list -db TEST1.kdb -pw Passw0rd
Alter SSLKEYR parameter in TEST1 Qmgr ################################## 7. ALTER QMGR SSLKEYR(‘/var/mqm/qmgrs/TEST1/ssl/TEST1’)
• Only Define a SSL Enabled Cluster Receiver Channel ** ############################################ 8. DEFINE CHANNEL(TO.TEST1.S) CHLTYPE(CLUSRCVR) CLUSTER(POC) TRPTYPE(TCP) CONNAME(‘127.0.0.1(1417)’) SSLCIPH(TLS_RSA_WITH_AES_128_CBC_SHA) • Refresh SSL Security ################## 9. REFRESH SECURITY TYPE(SSL)
Verify the Status of Cluster Channels ################################ 10. DISPLAY CLUSQMGR(TEST1) STATUS SSLCIPH
Checkpoint Test: You should see the NON SSL Cluster Channels are Running & newly defined SSL Channel status is INACTIVE state.
** We will define the SSL enabled Cluster Sender channels in Section 5.11** Note: While generating the Certificate request or CSR in Step 5.2, Cert Label should be ibmwebspheremq
*** Repeat Steps 5.1 – 5.10 for the other 2 Qmgrs (TEST2,3) ***
11. Under TEST1 Qmgr, define the SSL Enabled Cluster Sender Channel to TEST2 Qmgr (FR) As per Cluster design rules, 2 FR Qmgrs (TEST1 ,2) should be fully interconnected using manually defined Cluster Sender/Receiver Channel pairs. Since we have already defined the SSL enabled Cluster Receiver Channel (Section 5 Step 8), we are now creating the SSL enabled Cluster Sender Channel in this Step. Once defined, the SSL enabled Cluster Sender Channel will start running automatically. This sequence of creating SSL enabled Cluster channels is essential for its proper functioning, otherwise the Channels may fail to start. runmqsc TEST1 ############# DEFINE CHANNEL(TO.TEST2.S) CHLTYPE(CLUSSDR) CLUSTER(POC) TRPTYPE(TCP) CONNAME(‘127.0.0.1(1415)’) SSLCIPH(‘TLS_RSA_WITH_AES_128_CBC_SHA’)
Check Cluster Channel Status ########################## DIS CHS(*) SSLPEER SSLCERTI AMQ8417: Display Channel Status details. CHANNEL(TO.TEST2.S) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1415)) CURRENT RQMNAME(TEST2) SSLCERTI(CN=SSL CA,O=IBM,C=China) SSLPEER(SERIALNUMBER=58:BD:76:43,CN=TEST2 Queue Manager,O=IBM,C=India) STATUS(RUNNING) SUBSTATE(MQGET) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
Checkpoint Test: SSL Cluster Channels should be running along with Normal Cluster Channels.
12. Under TEST2 Qmgr, define the SSL Enabled Cluster Sender Channel to TEST1 Qmgr (FR) Similar to Step 11, Interconnect the 2 FR Qmgrs using manaully defined Cluster Sender/Receiver Channel pairs. runmqsc TEST2 ############## DEFINE CHANNEL(TO.TEST1.S) CHLTYPE(CLUSSDR) CLUSTER(POC) TRPTYPE(TCP) CONNAME(‘127.0.0.1(1417)’) SSLCIPH(‘TLS_RSA_WITH_AES_128_CBC_SHA’) Check Cluster Channel Status ######################### DIS CHS(*) SSLPEER SSLCERTI AMQ8417: Display Channel Status details. CHANNEL(TO.TEST1.S) CHLTYPE(CLUSSDR) CONNAME(127.0.0.1(1414)) CURRENT RQMNAME(TEST1) SSLCERTI(CN=SSL CA,O=IBM,C=China) SSLPEER(SERIALNUMBER=58:BD:76:28,CN=TEST1 Queue Manager,O=IBM,C=India) STATUS(RUNNING) SUBSTATE(MQGET) XMITQ(SYSTEM.CLUSTER.TRANSMIT.QUEUE)
Checkpoint Test: SSL Cluster Channels should be running along with Normal Cluster Channels.
Note: Ensure that you select the Same Cipher Spec. Algorithm between the Sending/Receiving end of the Cluster Channels.
13. Under TEST2 Qmgr, define the SSL Enabled Cluster Sender Channel to TEST1 Qmgr (FR) As per the Cluster design rules, any PR Qmgr needs to be fully interconnected with any one of FR Qmgr. In this case, PR Qmgr TEST3 has manually defined secure Cluster receiver (already defined in *** Repeat Step 51.-5.10 ***). In this step, we are going to define secure Cluster Sender channel to TEST1 Qmgr. runmqsc TEST3 ############# DEFINE CHANNEL(TO.TEST1.S) CHLTYPE(CLUSSDR) CLUSTER(POC) TRPTYPE(TCP) CONNAME(‘127.0.0.1(1417)’) SSLCIPH(‘TLS_RSA_WITH_AES_128_CBC_SHA’)
Check Cluster Channel Status ######################## DIS CHS(*) SSLPEER SSLCERTI
Note: After activation of SSL/TLS Cluster Channels, stop the existing non SSL Cluster Channels, take them out of MQ Cluster POC. Steps for this part of the activity is not in scope of this exercise! The below figure represents the High Level Details of the Solution, Post Completion of Section 5
6. Create Application Users Alice & Bob
In this part of the exercise, we are going to create 2 users Alice & Bob using root ID. Alice (using MQ Client) should be able to put Messages using Client Connection Channel into a clustered QAlias defined under TEST1 Qmgr whose target is a cluster QLocal under TEST2 Qmgr. On the other hand, Bob (using MQ Client) should be able to get the Messages from this Local Q using CCDT file. Using root ID: useradd alice | useradd bob Set password for both alice and bob to be alice and bob respectively:
Sudo passwd alice Sudo passwd bob
7. MQ Client Configuration using CCDT
1. Create a Dedicated Qmgr CCDT for Administration & Maintenance of CCDT file In this Section, we are going to make use of a dedicated Qmgr CCDT for TAB file Administration & Maintenance activities. Define the Client Channel names to be used by TEST1 & TEST2 Qmgrs under CCDT using the below mentioned commands. Once completed, copy the updated AMQCLCHL.TAB file to a centralized location /home/CCDT accessible to both Alice & Bob. Define the corresponding SVRCONN Channels for each Client Connection Channel. Note: SVRCONN/Client Connection definition works in pair.
2. Create & Start CCDT Qmgr ######################### crtmqm CCDT strmqm CCDT
3. Go to directory of the TAB File ############################ cd /var/mqm/qmgrs/CCDT/@ipcc/ runmqsc CCDT ############ DEFINE CHANNEL(TEST1) CHLTYPE(CLNTCONN) CONNAME(‘127.0.0.1(1417)’) QMNAME(TEST1) DEFINE CHANNEL(TEST2) CHLTYPE(CLNTCONN) CONNAME(‘127.0.0.1(1415)’) QMNAME(TEST2)
4. Now, copy the updated TAB File AMQCLCHL.TAB into /home/CCDT cd /var/mqm/qmgrs/CCDT/@ipcc/ cp -p AMQCLCHL.TAB /home/CCDT Note: Give 777 permission to CCDT directory & AMQCLCHL.TAB file to avoid permission issues.
5. Create the corresponding SVRCONN Channels for each Client Connection Channel ——————————————————————————————————————— —- runmqsc TEST1 ############ DEFINE CHANNEL(TEST1) CHLTYPE(SVRCONN) runmqsc TEST2 ############ DEFINE CHANNEL(TEST2) CHLTYPE(SVRCONN)
8. Grant OAM Authorities
In this Section, we are going to configure necessary OAM Level Permissions for Alice & Bob on MQ Objects. As per our requirement, Alice should be able to connect to the Qmgr TEST1 & have necessary authority to put messages into the Clustered Alias Q (AMS_A) which points to Clustered Local Q (AMS_E). Similarly, Bob should be able to connect to the Qmgr TEST2 & have necessary authority to read incoming messages from the Local Q (AMS_E). Note: Execute Refresh Security command under TEST1 & TEST2 Qmgrs after setting up the below permissions. Alice ——— setmqaut -m TEST1 -t qmgr -p alice +inq +connect +dsp setmqaut -m TEST1 -t q -n AMS_A -p alice +put +browse +dsp setmqaut -m TEST2 -t q -n AMS_E -p alice +put +browse +dsp Bob —— setmqaut -m TEST2 -t qmgr -p bob +inq +connect +dsp setmqaut -m TEST2 -t q -n AMS_E -p bob +get +browse +dsp
runmqsc TEST1(2) ————————— REFRESH SECURITY
9. Set MQ Client Environment Variables
Here, we are going to setup the MQ Client Environment Variables for Alice & Bob. Open 2 different terminals; one each for Alice & Bob. Execute the below commands to set the MQ Client connection channel connectivity. Once ENV variables are set, go the sample programs & try to put / get Messages as Alice & Bob user respectively.
Alice’s Terminal ———————– export MQCHLTAB=AMQCLCHL.TAB export MQCHLLIB=/home/CCDT cd /opt/mqm/samp/bin ./amqsputc AMS_A TEST1
Bob’s Terminal ——————– export MQCHLTAB=AMQCLCHL.TAB export MQCHLLIB=/home/CCDT cd /opt/mqm/samp/bin ./amqsgetc AMS_E TEST2
Checkpoint Test: Alice should be able to put Message into the Clustered QAlias (AMS_A) under TEST1 Qmgr which points to Cluster QLocal (AMS_E) under TEST2 Qmgr. And, Bob should be able to browse / get the messages from the QL(AMS_E) as shown in the below diagram. The below figure depicts High Level Solution Details, Post completion of Section 9
10. Enable SSL for MQ Clients
In this part, we are going to secure the MQ Client Channels (used by Alice & Bob) with Queue Managers. We already configured a working Client Connection Channel between Alice <==> TEST1 Qmgr and between Bob <==> TEST2 Qmgr, covered in Sections 7- 9. In this part, we are going to enable SSL/TLS at MQ Client Channel Level.
For this exercise, we will make use of the Internal CA created in Section 4.
Create Keystore, generate CSR & get it signed by CA for Alice: ###################################################### Create the Keystore for Alice (/home/alice/keystore) ======1. runmqckm -keydb -create -db alice -pw Passw0rd -type cms -expire 365 -stash
Create a Certificate Request for Alice ======2. runmqckm -certreq -create -db alice.kdb -pw Passw0rd -label ibmwebspheremqalice -dn “CN=Alice Client,O=IBM,C=India” -file alice.req
Sign Alice Clients’s certificate using CA (/home/mqm/CA) *** Section 4 *** ======3. runmqckm -cert -sign -file alice.req -db SSL_CA.kdb -pw Passw0rd -label ssl_ca - target alice.cer -format ascii -expire 364
Add CA’s Public Certificate into Alice’s Keystore ======4. runmqckm -cert -add -db alice.kdb -pw Passw0rd -label ssl_ca -file ssl_ca.cer - format ascii -trust enable
Receive the CA Signed Certificate Request into Alice’s Keystore ======5. runmqckm -cert -receive -db alice.kdb -pw Passw0rd -file alice.cer -format ascii
List Certificate under MQ Client’s keystore ======6. runmqckm -cert -list -db alice.kdb -pw Passw0rd
Note: While generating CSR file in Step 2, the Certificate Label naming convention should be
Observation: Alice’s SSL Keystore
Repeat the Same Steps for Bob i.e. Create Keystore, generate CSR & get it signed by CA: ###################################################################### ######## Create the Keystore for Bob (/home/bob/keystore) ======1. runmqckm -keydb -create -db bob -pw Passw0rd -type cms -expire 365 -stash
Create a Certificate Request for Bob ======2. runmqckm -certreq -create -db bob.kdb -pw Passw0rd -label ibmwebspheremqbob -dn “CN=Bob Client,O=IBM,C=India” -file bob.req
Sign Alice Clients’s certificate using CA (/home/mqm/CA) *** Section 4 *** ======3. runmqckm -cert -sign -file bob.req -db SSL_CA.kdb -pw Passw0rd -label ssl_ca - target bob.cer -format ascii -expire 364
Add CA’s Public certificate into Bob’s Keystore ======4. runmqckm -cert -add -db bob.kdb -pw Passw0rd -label ssl_ca -file ssl_ca.cer - format ascii -trust enable
Receive the CA Signed Certificate Request into Bob’s Keystore ======5. runmqckm -cert -receive -db bob.kdb -pw Passw0rd -file bob.cer -format ascii
List Certificate under Bob’s Keystore ======6. runmqckm -cert -list -db bob.kdb -pw Passw0rd
Note: While generating CSR file in Step 2, the Certificate Label naming convention should be
Observation: Bob’s SSL Keystore
11. Update the TLS Cipher Spec
In order to use the SSL CIPH, you will need to replace the security policy library to the unrestricted :
Download the unrestricted files from the below url: https://www.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.security.co mponent.70.doc/security-component/sdkpolicyfiles.html extracted them into /opt/mqm/java/jre64/jre/lib/security folder
As described in Section 7, we again need to make use of the CCDT Queue Manager to update the Cipher Spec Algorithm in the existing Client Channels definitions following the commands mentioned below: cd /var/mqm/qmgrs/CCDT/@ipcc/ runmqsc CCDT ############ ALTER CHANNEL(TEST1) chltype(CLNTCONN) SSLCIPH(‘TLS_RSA_WITH_AES_128_CBC_SHA’) ALTER CHANNEL(TEST2) chltype(CLNTCONN) SSLCIPH(‘TLS_RSA_WITH_AES_128_CBC_SHA’)
Copy the updated AMQCLCHL.TAB file from (/var/mqm/qmgrs/CCDT/@ipcc/) to centralized location (/home/CCDT)
Update the corresponding SVRCONN Channels with TLS Cipher Spec. Algorithm As mentioned in Previous Step, update the Same TLS Cipher Spec Algorithm for the corresponding SVRCONN Channels under TEST1 & TEST2 Qmgrs. runmqsc TEST1 ############# ALTER CHANNEL(TEST1) CHLTYPE(SVRCONN) SSLCIPH(‘TLS_RSA_WITH_AES_128_CBC_SHA’) REFRESH SECURITY TYPE(SSL)
runmqsc TEST2 ############## ALTER CHANNEL(TEST2) CHLTYPE(SVRCONN) SSLCIPH(‘TLS_RSA_WITH_AES_128_CBC_SHA’) REFRESH SECURITY TYPE(SSL)
Set the MQ Client related Environment Variables for Alice & Bob as mentioned in Section 9. This time, we need to setup another additional SSL related Environment Variable for both Alice & Bob to point to their respective SSL keystores. export MQSSLKEYR=/home/alice/alice export MQSSLKEYR=/home/bob/bob Using sample programs, Alice puts messages over SSL enabled Client Connection Channel while Bob get the same messages over secure Channel from the other end of the IBM MQ Cluster network as demonstrated in the Case Study pictorial diagram mentioned below. Alice ———- $/opt/mqm/samp/bin> ./amqsputc AMS_A TEST1 Hello testing… runmqsc TEST1 ############# DIS CHS(TEST1) SSLPEER SSLCERTI dis chs(TEST1) SSLPEER SSLCERTI 1 : dis chs(TEST1) SSLPEER SSLCERTI AMQ8417: Display Channel Status details. CHANNEL(TEST1) CHLTYPE(SVRCONN) CONNAME(127.0.0.1) CURRENT SSLCERTI(CN=SSL CA,O=IBM,C=China) SSLPEER(SERIALNUMBER=58:BE:A1:54,CN=Alice Client,O=IBM,C=India) STATUS(RUNNING) SUBSTATE(RECEIVE)
Checkpoint Test: It will display that the Server Connection Channel is running with SSL enabled parameters SSLPEER & SSLCERTI.
Bob ——- $/opt/mqm/samp/bin> ./amqgetc AMS_E TEST2 Hello testing… runmqsc TEST2 ############# DIS CHS(TEST2) SSLPEER SSLCERTI dis chs(TEST2) SSLPEER SSLCERTI 1 : dis chs(TEST2) SSLPEER SSLCERTI AMQ8417: Display Channel Status details. CHANNEL(TEST2) CHLTYPE(SVRCONN) CONNAME(127.0.0.1) CURRENT SSLCERTI(CN=SSL CA,O=IBM,C=China) SSLPEER(SERIALNUMBER=58:BE:A3:8B,CN=Bob Client,O=IBM,C=India) STATUS(RUNNING) SUBSTATE(RECEIVE)
Checkpoint Test: It will display that the Server Connection Channel is running with SSL enabled parameters SSLPEER & SSLCERTI.
The Below Diagram shows the End to End Message Encryption(in-transit) while passing through SSL/TLS enabled Secure Channels from Alice to Bob.
Thus we have implemented the scenario wherein Application (Alice) using MQ Clients is sending data over SSL/TLS enabled Client Connection Channel, passing through SSL enabled MQ Cluster (TEST1 & TEST2) before being consumed by receiving Application (Bob) over secured Client Connection Channel. Hence, Business data/messages are encrypted while in transit throughout the MQ network. However, the messages will still be available in Plain Text while sitting in the Local Queues & accessible to all administrator having ‘mqm’ privileges. To eliminate this part of the security vulnerability, AMS comes into the picture!
12. Set AMS Rules & Configurations
Ensure that the AMS package is installed in your system by using the commands: -bash-4.1$ dspmqver -p 128 -v
-bash-4.1$ AMS provides two Quality of Protections(QOP) i.e. Digital Signature & Encryption. Depending on the Customer requirement, one can select & setup policies. In this exercise, we have selected Encryption policy which also includes Digital Signature as well. We are going to use the below two Queues created in Section 3 for AMS related configuration & Testing: AMS_A Cluster QAlias Queue defined under TEST1 Qmgr whose Target Q is AMS_E defined under TEST2 Qmgr. AMS_E Cluster Local Queue defined under TEST2 Qmgr.
1. Grant OAM Authorities to Alice & Bob on AMS enabled Application Queues (Completed in Section 8) 2. Grant OAM Authorities to Alice & Bob on 2 AMS related SYSTEM Queues (SYSTEM.PROTECTION.POLICY.QUEUE & SYSTEM.PROTECTION.ERROR.QUEUE)
Setup OAM related permissions on 2 AMS related SYSTEM queues on both TEST1 & TEST2 Qmgrs for Alice & Bob. Refresh Security Cache for both Qmgrs once completed.
Alice ——– setmqaut -m TEST1 -t q -n SYSTEM.PROTECTION.POLICY.QUEUE -p alice +put +browse setmqaut -m TEST1 -t q -n SYSTEM.PROTECTION.ERROR.QUEUE -p alice +put +browse setmqaut -m TEST2 -t q -n SYSTEM.PROTECTION.POLICY.QUEUE -p alice +put +browse setmqaut -m TEST2 -t q -n SYSTEM.PROTECTION.ERROR.QUEUE -p alice +put +browse Bob ——– setmqaut -m TEST2 -t q -n SYSTEM.PROTECTION.POLICY.QUEUE -p bob +put +browse setmqaut -m TEST2 -t q -n SYSTEM.PROTECTION.ERROR.QUEUE -p bob +put +browse
runmqsc TEST1(2) ————————– REFRESH SECURITY
3. Create AMS Keystores & Config files for Alice & Bob In this Step, we are going to create Alice & Bob’s keystores along with generating & exchanging their self-signed certificates into each other’s repositories.
Alice ——– Create the default path for Alice’s Configuration Directory ======mkdir /home/alice/.mqs -p Create the keystore for Alice ======runmqakm -keydb -create -db /home/alice/.mqs/alicekey.kdb -pw passw0rd -stash
Generate the Self-Signed Certificate for Alice ======runmqakm -cert -create -db /home/alice/.mqs/alicekey.kdb -pw passw0rd -label Alice_Cert -dn “cn=alice,o=IBM,c=IN” -default_cert yes
Extract the Self-Signed Certificate of Alice into a /tmp/certs directory ======runmqakm -cert -extract -db /home/alice/.mqs/alicekey.kdb -pw passw0rd -label Alice_Cert -target /tmp/certs/alice_public.arm
Bob —— Create the default path for Bob’s Configuration Directory ======mkdir /home/bob/.mqs -p
Create the keystore for Bob ======runmqakm -keydb -create -db /home/bob/.mqs/bobkey.kdb -pw passw0rd -stash
Generate the Self-Signed Certificate for Bob ======runmqakm -cert -create -db /home/bob/.mqs/bobkey.kdb -pw passw0rd -label Bob_Cert -dn “cn=bob,o=IBM,c=IN” -default_cert yes
Extract the Self-Signed Certificate of Bob into a /tmp/certs directory ======runmqakm -cert -extract -db /home/bob/.mqs/bobkey.kdb -pw passw0rd -label Bob_Cert -target /tmp/certs/bob_public.arm
4. Now, Add the Public Certificate of Alice & Bob into each other’s Keystores ======runmqakm -cert -add -db /home/bob/.mqs/bobkey.kdb -pw passw0rd -label Alice_Cert -file /tmp/certs/alice_public.arm runmqakm -cert -add -db /home/alice/.mqs/alicekey.kdb -pw passw0rd -label Bob_Cert -file /tmp/certs/bob_public.arm
Observation: Public Certs of Alice & Bob
Observation: Alice’s AMS Keystore
Observation: Bob’s AMS Keystore
5. Create the AMS Configuration files for Alice & Bob In this Step, create the config file keystore.conf under Alice & Bob’s default home directory as shown below: keystore.conf – Alice (/home/alice/.mqs/keystore.conf) ======cms.keystore=/home/alice/.mqs/alicekey cms.certificate=Alice_Cert
keystore.conf – Bob (/home/bob/.mqs/keystore.conf) ======cms.keystore=/home/bob/.mqs/bobkey cms.certificate=Bob_Cert
6. Setup Security Policies for Alice & Bob on AMS enabled Application Queues In the last part of this exercise, we are going to set the AMS rules which grant Alice user the necessary authority to put messages into AMS Queues.Those message will be Digitally signed using SHA1 algorithm & Encrypted using ASE256 Cipher Spec. Only Bob user has the required authority to decrypt & subsequently browse / get the messages from the AMS enabled Local Q (AMS_E).
1. Alice should be able to Put Messages into AMS enabled Application Queues i.e. AMS_A & AMS_E 2. Bob should be able to Get Messages from AMS_E Application Queue setmqspl -m TEST1 -p AMS_A -s SHA1 -a “CN=alice,O=IBM,C=IN” -e AES256 -r “CN=bob,O=IBM,C=IN” setmqspl -m TEST2 -p AMS_E -s SHA1 -a “CN=alice,O=IBM,C=IN” -e AES256 -r “CN=bob,O=IBM,C=IN”
################################################ Observation: AMS Policy set on QAlias (AMS_A) under TEST1
Observation: AMS Policy set on QL (AMS_E) under TEST2
13. Set Channel Auth (CHLAUTH) Rules
On top of the above MQ Security settings, as discussed from Sections 4-12, we can configure Additional Level of Security at the SVRCONN Channel Level using a new security feature introduced in IBM MQ v7.5 onwards called CHLAUTH. Using this functionality, we can set Rules to Allow / Block access from specified range of IP Addresses, User IDs, SSL DN names etc. By default CHLAUTH security feature is enabled in MQ 7.5 & above; all user IDs having administrative privileges will be blocked automatically while connecting though SYSTEM channels. In this Implementation, we have added Two sets of CHLAUTH rules on TEST1 Qmgr as mentioned below. Create a rule which applies to channels whose names match the pattern “TEST1”. Allow inbound connections from SSL/TLS subject’s Distinguished Names which match pattern “CN=Alice Client,O=IBM,C=India”. Assign a user ID of “alice” for access control checks for these connections. runmqsc TEST1 ———————– SET CHLAUTH(‘TEST1’) TYPE(SSLPEERMAP) SSLPEER(‘CN=Alice Client,O=IBM,C=India’) USERSRC(MAP) MCAUSER(‘alice’) DESCR(‘POC’) ACTION(ADD) SET CHLAUTH(‘TEST1’) TYPE(ADDRESSMAP) ADDRESS(‘10.9.*.*’) USERSRC(NOACCESS) DESCR(‘Block IP’) WARN(NO) ACTION(ADD) *// Block Inbound Connections from addresses which match pattern “10.9.*.*”. //*
Observation:
On the other end of the MQ network i.e.under TEST2 Qmgr, we are going to set another CHLAUTH Rules to Allow Bob to connect while validating its Distinguished Names as mentioned below: 1. Create a rule which applies to channels whose names match the pattern “TEST2”. 2. Allow inbound connections from SSL/TLS subject’s Distinguished Names which match pattern “CN=Bob Client,O=IBM,C=India”. 3. Assign a user ID of “bob” for access control checks for these connections.
runmqsc TEST2 ———————– SET CHLAUTH(‘TEST2’) TYPE(SSLPEERMAP) SSLPEER(‘CN=Bob Client,O=IBM,C=India’) USERSRC(MAP) MCAUSER(‘bob’) ACTION(ADD) Observation:
14. Test Results
Case 1: Alice puts a message into AMS enabled Queue (AMS_A) define under TEST1 Qmgr using sample utility program amqsput.
Observation 1:
Case 2: As soon as Alice puts a message mentioned in Case 1, SSL Enabled SVRCONN Channel (TEST1) & Cluster Sender Channel (TO.TEST2.S) started running under TEST1 Qmgr as highlighted in the below screenshot:
Observation 2:
Case 3: Bob is able to read the encrypted Message from the AMS enable Queue (AMS_E) defined under TEST2 Qmgr in Plan text using sample program amqsgetc. Observation 3:
Case 4: As soon as Bob issues the command to read the Message mentioned in Case 3, SSL Enabled SVRCONN (TEST2) started running under TEST2 Qmgr as mentioned in the below screenshot:
Observation 4:
Case 5: ‘mqm’ user does not have Authority to read (amqsbcg) the message from the AMS enable Queue (AMS_E) defined under TEST2 Qmgr.
Observation 5:
Case 6: How to verify if the Message from Alice is Digitally Signed & Encrypted in AMS enabled Q (AMS_E) defined under TEST2 Qmgr ? To achieve this tasks, we have follow the Steps mentioned below: Define a Queue Alias (AMS_A) under TEST2 qmgr which points to the AMS enabled Local Q (AMS_E) runmqsc TEST2 DEFINE QA(AMS_A) TARGET(AMS_E2) Observation 6: As ‘mqm’ user try to browse the QAlias (AMS_A) whose target Q is the AMS enable LQ (AMS_E) defined under TEST2 Qmgr.
Note: PDMQ signifies that the message has been Digitally Signed & the remaining gibberish part signifies that message has been Encrypted.
15. Conclusion
This article basically demonstrates the simultaneous usage & application of almost all the IBM® MQ built-in security features (Excluding Channel Exit Programs) in an Integrated Test Case as shown below diagrammatically. As per the below figure, Application (Alice) using MQ Clients is sending data over SSL/TLS enabled Client Connection Channel, passing through SSL enabled MQ Cluster (TEST1 & TEST2) before being consumed by receiving Application (Bob) over secured Client Connection Channel. Hence, Business data / messages are encrypted while in transit throughout the MQ network. However, the messages will still be available in Plain Text while sitting in the Local Queues & accessible to all administrator having ‘mqm’ privileges. To eliminate this part of the security vulnerability, IBM has introduced Advanced Message Security using which Administrators have the option to etiher Digitally Sign the data or Encrypt or both as per Client’s requirement.