Another in the series of bitesize blog posts about features in MQ V8. Check out the whole series here.
WebSphere MQ Advanced Message Security (or AMS) is now available as an optionally installable component for MQ on the IBM i platform with MQ v8, this is the first time that this capability has been made available on the platform. It is now possible to use AMS policies to digitally sign and encrypt messages being exchanged with ILE COBOL, RPG, C and Java/JMS applications running on IBM i with other platforms.
AMS has three core concepts; certificates, policies and interceptors.
Digital Certificates are used to sign and encrypt messages - these certificates are associated with a user through a keystore configuration file.
Security Policies are used to associate what protection should be used when putting and getting messages from a queue.
Interceptors are the AMS libraries that apply protection to messages according to a policy, with MQ v7.5 and later, interceptors are built into both client and server libraries.
An MQ server installation with AMS installed enables security policy management and interceptors for both local MQ applications and remotely connected client applications.
Installing AMS on IBM i
To install AMS, you must first install the MQ server licensed program *BASE option before then installing option 2 "WebSphere MQ for IBM i - Security Policies". For example, using a savefile install;
RSTLICPGM LICPGM(5724H72) DEV(*SAVF) SAVF(MQ80PROD/MQ80AMS) RSTOBJ(*PGM) OPTION(2)
Once AMS is installed on an MQ server installation, any queue managers that are subsequently started will enable security policy management features and any applications that connect to the queue manager will enable interceptors.
Setting up cetificates and keystore.conf
The first step for setting up a user to start using AMS protection is to create a certificate and associate that with the users environment, the association is configured through a file held in the integrated filesystem (IFS). To create a self-signed certificate using the OpenSSL tooling shipped with IBM i, issue the following command from QShell;
/QOpenSys/usr/bin/openssl req -x509 -newkey rsa:2048 -keyout $HOME/private.pem -out $HOME/mycert.pem -nodes -days 365
The command will prompt for various distinguished name attributes for a new self-signed certificate, including Common Name (CN=), Organization (O=) and Country (C=) and this will create an unencrypted private key and a matching certificate, both in PEM (Privacy Enhanced Mail) format. For simplicity just enter values for common name, organization and country - these attributes and values are important when creating a policy.
AMS requires that both the certificate and private key are held in the same file, which can be achieved with a simple file concatenation;
cat $HOME/mycert.pem >> $HOME/private.pem
The private.pem file in $HOME now contains a matching private key and certificate, whilst the mycert.pem file contains all of the public certificates that the user can encrypt messages for and validate signatures. The two files need to be associated with the users environment by creating a keystore.conf in the default location for the user. By default AMS looks for the keystore configuration in a '.mqs' subdirectory of the users home directory. In QShell create the keystore.conf file;
mkdir -p $HOME/.mqs
echo "pem.private = $HOME/private.pem" > $HOME/.mqs/keystore.conf
echo "pem.public = $HOME/mycert.pem" >> $HOME/.mqs/keystore.conf
echo "pem.password = unused" >> $HOME/.mqs/keystore.conf
Creating a policy
Before creating a policy, a queue to hold protected messages needs to be created - at a CL command prompt enter;
CRTMQMQ QNAME(PROTECTED) QTYPE(*LCL) MQMNAME(<yourqm>)
A queue manager can be checked to ensure that it is capable of using security policies by using DSPMQM - check that "Security Policy Capability" shows *YES.
The simplest policy that can be defined is an integrity policy, which is achieved by creating a policy with a digital signature algorithm but no encryption algorithm, messages will be signed but not encrypted. If messages are to be encrypted, an encryption algorithm and one or more intended message recipients must be specified. A certificate in the public keystore for an intended message recipient is identified through a distinguished name. The distinguished names of the certificates in the public keystore, mycert.pem in $HOME, can be displayed using the following command in QShell;
/QOpenSys/usr/bin/openssl x509 -in $HOME/mycert.pem -noout -subject -nameopt RFC2253
The distinguished name needs to be entered as an intended recipient and the policy name must match the queue name to be protected - at a CL command prompt enter;
SETMQMSPL POLICY(PROTECTED) MQMNAME(<yourqm>) SIGNALG(*SHA256) ENCALG(*AES256) RECIP('CN=.., O=.., C=..')
Once the policy is created, any messages that are put, browsed or destructively removed via that queue name are subject to the AMS policy.
Testing the policy
The sample applications provided with MQ, such as AMQSPUT4, AMQSGET4, AMQSGBR4 and tools such as WRKMQMMSG can be used to put, browse and get messages using the PROTECTED queue name. Provided everything has been configured correctly, there should be no difference in application behaviour to that of an unprotected queue for this user. A user not setup for AMS, or a user that does not have the required private key to decrypt the message will however not be able to view the message, receiving a completion code of MQCC_FAILED (2) and reason code of MQRC_SECURITY_ERROR (2063).
To see that AMS protection is in effect, put some test messages to the PROTECTED queue, for example via AMQSPUT0 - an alias queue can then be created to browse the raw protected data whilst at rest.
CRTMQMQ QNAME(ALIAS) QTYPE(*ALS) TGTQNAME(PROTECTED) MQMNAME(<yourqm>)
Browsing using the ALIAS queue name, for example using AMQSBCG4 or WRKMQMMSG, should reveal larger 'scrambled' messages where a browse of the PROTECTED queue shows cleartext messages. The scrambled messages are visible, but the original cleartext is not decipherable via the ALIAS queue as there is no policy for AMS to enforce matching this name, hence the raw protected data is returned.