Presenting the basics of SSL/TLS , usage of SSL protocol to secure the IBM MQ channels. Secure Communications between two Queue Managers and various test cases , between an application and Queue Manager , Errors , Certificate Renewal ..
3. Security Fundamentals
What is Cryptography
– Cryptography is the science of writing in secret
code and is an ancient art .
How it used to be years ago?
– Substitution ciphers ( CAESAR CIPHER )
– Transposition ciphers
5. Security Fundamentals
The purpose of cryptography
“ Five Primary Functions “
Privacy/confidentiality: Ensuring that no one can read the message except the intended
receiver.
Authentication: The process of proving one's identity.
Integrity: Assuring the receiver that the received message has not been altered in any
way from the original.
Non-repudiation: A mechanism to prove that the sender really sent this message.
Key exchange: The method by which crypto keys are shared between sender and
receiver.
6. Security Fundamentals
Cryptology
Cryptography Crypt analysis
Asymmetric Key (Public Key Cryptography) Symmetric Key ( Single key used for E & D )
means ‘not equal or similar’
RSA – E , D , key Exchange , Digital Signatures
Diffie-Hellman – Key Exchange
Digital Signature Algorithm (DSA) – Key Exchange
ElGamal
Elliptic Curve Cryptography (ECC)
PKI (Public Key Infrastructure)
Block Cipher (blocks of data
can be E & D at a time.
Stream
Cipher
Bit-wise E &D
DES (IBM's )
3DES
AES
7. Security Fundamentals
PKI (Public Key Infrastructure)
A public key infrastructure (PKI) is a system for the creation, storage, and distribution of
digital certificates which are used to verify that a particular public key belongs to a certain
entity. The PKI creates digital certificates which map public keys to entities, securely
stores these certificates in a central repository and revokes them if needed.
A PKI consists of:
A certificate authority (CA) that stores, issues and signs the digital certificates.
A registration authority which verifies the identity of entities requesting their digital
certificates to be stored at the CA.
A central directory—i.e., a secure location in which to store and index keys
A certificate management system managing things like the access to stored certificates
or the delivery of the certificates to be issued.
A certificate policy.
“ PKI is itself often used as a synonym for a CA implementation.”
10. Security Fundamentals
Hashing
Integrity is provided by hashing the messages. A hash is very much like a fingerprint and the hash
algorithm is constructed so that the smallest change in the source produces a completely different and
unpredictable hash value. When the message arrives at its destination, the hash provides some
assurance that the message has not been tampered with. The integrity function is not optional. When
SSL is enabled for a WebSphere MQ channel, all messages on that channel are hashed and verified.
11. Security Fundamentals
Why SSL / TLS ?
“The internet is insecure by default...Internet channels are not secure......”
“SSL creates an encrypted connection between systems” allowing for private
information to be transmitted without the problems of eavesdropping, data
tampering, and message forgery.
SSL is a protocol and is capable of securing any transmission over TCP.
14. MQ Security
GSKit – Global Security Kit
What is it ?
IBM Global Security Kit is a common component that is used by a number of IBM products
for its cryptographic and SSL/TLS capabalities.
IBM Global Security Kit is a library and set of command line tools that provides SSL along
with base cryptographic functions .
GSKit is a component and not a stand-alone product.
GSKit supports two installation methods :
– Global installation & local installation.
On a global installation, a single GSKit instance is shared by mutiple products. In this
configuration ,gskit libraries and executables are placed in a common loation outside of the
product's installation directory.
On a local installation , each product has its own , private version of GSKit.
Continued...
15. MQ Security
MQ Global Security Kit
In WebSphere MQ Version 7.0.1, if you select SSL and TLS support during installation, GSKit
Version 7.0 is installed and run by default.
GSKit V8.0 is now integrated with WebSphere MQ version 7.1 and 7.5 ..
If you want to use SHA2 hashing , and in turn TLS 1.2 you will have to install GSKit v8.0.
If you want to use the above point features in MQ 7.0.1 , install the GSKit8 in the system .
GSKit 8 can only be installed when Fix pack 4 or above is the MQ 7.0.1.(>=4).
The location of gskit8 at the system level is usually /usr/opt/ibm.
Can list the GSKit8 packages with lslpp -l or rpm -qa.
GSKit which comes with the MQ itself , its version can be checked with mq control command.
dspmqver -p64
17. MQ Security
GSKit v8
If you have a certificate with the wrong label name in a key store, you can correct
the
label name.
It is easy with GSKitv8.
“ runmqckm/runmqakm provide a '-cert -rename' option “
If you need to manage SSL or TLS certificates in a way that is FIPS-compliant,
use the Runmqakm command.
Command to do the same –
runmqckm -cert -rename -db key.kdb -label <incorrectlabelname> -new_label
ibmwebspheremqnewqmname.
If using GSKitv7, you will need to export, delete, import - with new label name.
For more information on label renaming with GSKit v7 please refer .
18. MQ Security
Terminology
Keystore & Trust store
A encrypted and password protected database to store certificates & private keys.
Many formats are there for keystore.( Most common are CMS & JKS ) .
Keystore contains :
Certificate Signing Requests ( CSR )
Personal Certificates ( CA Signed or self signed )
Private keys associated with a Personal Certificate
Signer certificates (provided by the CA or extracted from self – signed )
19. MQ Security
Terminology
GSKit stores public and private keys and certificates of a queue manager and in specific
cases the signer certificate of the client in a key database. A key database consists of a file
with a .kdb extension and up to three other files with .sth, .rdb, and .crl extensions.
Command to create a key database : go to the queue managers ssl directory & then
gsk8capicmd -keydb -create -db <filename>.kdb -pw 1234 -type cms -expire 1000 -stash
20. MQ Security
Trust store
Two different,but related meanings :
As a file, a specialized keystore used for storing Signer Certificates.
As a function,the portion of the keystore file that contains Signer Certificates.
It also holds the certificate but this store is created at the application side.
The Java™ Secure Socket Extension (JSSE) is a framework and provides the Java
implementation of the Secure Sockets Layer (SSL) protocol. JSSE uses SSL and the
Transport Layer Security (TLS) protocol to enable clients and servers to conduct secure
communications over TCP/IP.
For more information please refer
21. MQ Security
Certificate Signing Request
A request for a personal certificate generated and formatted as CSR.
The CSR is transmitted to a Certificate Authority.
The CSR does not contain the private key . This key remains with the keystore.
Personal Certificate
An X.509 certificate asserting the identity of a server , a URL or a person.
Contains the Public key and is associated with a private key through the keystore.
Either Self signed or issued by a certificate authority.
Multiple formats for certificates :
ARM , DER , PEM , PKCS12
Certificate formats containing a private key should be password protected.
22. MQ Security
Public Certificate
The certificate issued by a CA ( containing Public but not private key) in response to a CSR.
A subset (Signer-portion) of a self signed Personal certificate containing only the public key.
This certificate is exchanged during the SSL Handshake.
Private key
The private ( secret ) part of a Public/Private key pair.
Created when a CSR is generated and stored in the keystore from which the CSR originated.
Associated with a public certificate when the certificate is “ Received “ from the CA.
23. MQ Security
Connecting two queue managers using SSL or TLS :
Important points :
Obtain and manage your digital certificates ( next slides ).
During the SSL or TLS handshake, the SSL or TLS client always obtains
and validates a digital certificate from the server. With the WebSphere MQ
implementation, the SSL or TLS server always requests a certificate from the
client.
SSL client refers to the connection initiating the handshake.
The SSL or TLS server always validates the client certificate if one is sent. If the client
does not send a certificate, authentication fails only if the end of the channel that is
acting as the SSL or TLS server is defined with either the SSLCAUTH parameter set to
REQUIRED or an SSLPEER parameter value set.
If the SSLCAUTH parameter of the server side of the channel is set to OPTIONAL , then
the server doesn't require the client certificate and hence the authentication doesn't fails.
24. MQ Security
Connecting two queue managers using SSL or TLS :
Using self-signed certificates for mutual authentication of two queue managers.
Two queue managers, QM1 and QM2, which need to communicate securely.
Mutual authentication to be carried out between QM1 and QM2.
Test your secure communication using self-signed certificates.
Resultant Configuration looks like
The key repository for QM1 contains the certificate for QM1 and the public certificate from QM2.
The key repository for QM2 contains the certificate for QM2 and the public certificate from QM1.
25. MQ Security
Using self-signed certificates for mutual authentication of two queue managers
Steps :
Prepare the key repository on each queue manager.
Create a self-signed certificate for each queue manager.
Extract a copy of each certificate.(to get the public part of the certificate)
Transfer the public part of the QM1 certificate to the QM2 system and vice versa
using a utility such as FTP.
Add the partner certificate to the key repository for each queue manager.
On QM1, define a sender channel and associated transmission queue, by issuing
commands like the following example.
Continued...
26. MQ Security
Using self-signed certificates for mutual authentication of two queue managers
On QM2, define a receiver channel, by issuing a command like the following
example
Both the channels should use the same cipher spec value specified in the SSLCIPH parameter.
For more information please refer
27. MQ Security
Using CA-signed certificates for mutual authentication of two queue managers
Two queue managers called QMA and QMB, which need to communicate securely.
Require mutual authentication to be carried out between QMA and QMB.
Resulting configuration looks like :
The key repository for QMA contains QMA's certificate and the CA certificate.
The key repository for QMB contains QMB's certificate and the CA certificate.
In this example both QMA's certificate and QMB's certificate were issued by the same CA.
If QMA's certificate and QMB's certificate were issued by different CAs then the key repositories for
QMA and QMB must contain both CA certificates.
Continued...
28. MQ Security
Using CA-signed certificates for mutual authentication of two queue managers
Steps :
Prepare the key repository on each queue manager
Request a CA-signed certificate for each queue manager. You might use different CAs
for the two queue managers. --- Creation of CSR
Add the Certificate Authority certificate ( Root CA certificate ) to the key repository
for each queue Manager .If the Queue managers are using different Certificate
Authorities then the CA certificate for each Certificate Authority must be added to
both key repositories.
Receive the CA-signed certificate (personal certificate)to the key repository for each qmgr.
On QMA, define a sender channel.
Continued...
29. MQ Security
Using CA-signed certificates for mutual authentication of two queue managers
On QMB, define a receiver channel
Both the channels should use the same cipher spec value specified in the SSLCIPH parameter.
For more information please refer
30. MQ Security
Connecting two queue managers using one-way authentication
QM1 connects using one-way authentication to QM2.
Resulting configuration looks like this:
With SSLCAUTH ( optional ) at the receiver channel , the SSL Server (QM2) will not not
validate the SSL Client ( QM1) personal certificate and hence the authentication will not fail.
For more information , please refer
31. MQ Security
Connecting a client to a queue manager anonymously
C1 connects anonymously to QM1 over a SSL enabled SVRCONN channel.
Resulting configuration looks like this:
ALTER CHANNEL(C1.TO.QM1) CHLTYPE(SVRCONN) SSLCAUTH(OPTIONAL)
For more information , please refer
32. MQ Security
General Errors :
Errors that can cause an SSL connection from a Java/JMS client to a queue manager to fail.
Using non-FIPS cipher with FIPS enabled on client.
Cipher suite not set on client or server.
Cipher Mismatch.
Missing client personal certificate.
Missing server personal certificate.
Missing server signer on client.
Missing client signer on server.
SSLPEER set on server does not match certificate.
SSLPEER set on client does not match certificate.
Using a non-FIPS cipher with FIPS enabled on the queue manager.
Can not find or open queue manager key database.
Can not find or use queue manager key database password stash file.
For more information please refer
33. MQ Security
General Errors :
Common reasons why an SSL secured WebSphere MQ channel will fail to start
In each case the SSLCIPH attribute has been correctly specified on each side of the channel
definition, but attempts to start the channel cause it to enter RETRYING state:
Missing certificates (personal or signer) on the server (RCVR) side of the SSL
channel.
Expired certificates on the server (RCVR) side of the SSL channel.
Missing certificates on the client (SDR) side of the SSL channel which are required to trust
the certificate provided by the server.
Missing personal certificate on the SSL client (SDR), when SSLCAUTH(REQUIRED) is
specified on the channel.
For more information please refer
34. MQ Security
Renewing Digital Certificates used by WebSphere MQ
Planning Process :
Is the certificate being renewed a self-signed, or CA signed certificate?
If it is a CA signed certificate, will it be signed by the same CA? ...same certificate
chain?
Can I create a second certificate in the existing keystore?
Will down-time be required?
35. MQ Security
Renewing Digital Certificates used by WebSphere MQ
Process for Self – signed
The certificate must be recreated, and the expiring certificate replaced.
Actually creating a new certificate and replacing the original, rather than renewing an
existing certificate.
Since self-signed certificates are not based on signed certificate requests, the renewal
process to regenerate a “CSR” does not apply.
Continued..
36. MQ Security
Renewing Digital Certificates used by Web Sphere MQ
Process for CA -Signed
It's important to know if your certificate will be signed by the same CA and
certificate chain.
This is an important question because the answer will determine whether or not you
need to send the CA's signer certificate to your remote partners. If your certificate
will not change in any way other than the expiry date, and you will be sending it to the
same certificate authority by way of their renewal process, it is likely that the signer
certificates will not change, therefore, your remote partners will not need to take any
action during your renewal process.
37. MQ Security
Renewing Digital Certificates used by WebSphere MQ
Downtime required or not ?
Down time is not required when renewing your digital certificate as long as you plan
accordingly.
Ensure that all signer certificates have been appropriately distributed and installed
into all of your remote partner's key stores.
Any changes in the key store files do not take effect on the Queue Manager until
REFRESH SECURITY TYPE(SSL) is run
or
Queue Manager is restarted
For more information please refer
38. MQ Security
Renewing Digital Certificates used by WebSphere MQ
Downtime required or not ?
Down time is not required when renewing your digital certificate as long as you plan
accordingly.
Ensure that all signer certificates have been appropriately distributed and installed
into all of your remote partner's key stores.
Any changes in the key store files do not take effect on the Queue Manager until
REFRESH SECURITY TYPE(SSL) is run
or
Queue Manager is restarted
For more information please refer
39. MQ Security
Cipher Spec
While planning for a Cipher Spec to be used at the channels SSLCIPH value , please look
for the product version specific documentation.
For Example :
link
If a application is communicating with a queue manager over a SSL/TLS enabled
SVRCONN channel , also look for a CIPHER SUITE value corresponding to a cipherspec.
( Again MQ version specific ) . Sample link
C QMGR
SVRCONN
Cipher Suite Cipher Spec
At the server end of an MQI channel, the name of a CipherSpec can be specified as the value of the
SSLCIPH parameter on a DEFINE CHANNEL CHLTYPE(SVRCONN) command. At the client
end of an MQI channel, a WebSphere MQ classes for Java application can set the sslCipherSuite field
in the MQEnvironment class.
40. MQ Security
A Note about FIPS (Standard Governing Cipher Specs )
The Federal Information Processing Standards (FIPS) specify, specific ciphersuites
that are acceptable for use in US government installations. Many non-government
shops also use FIPS as a baseline for their own secure configurations. To assist in
configuring FIPS-compliant networks, the queue manager has an attribute called
SSLFIPS that can be set to YES or NO. When set to YES, SSL channels are restricted
to use only FIPS approved encryption algorithms.
41. MQ Security
Note :
The location of the key repository of a queue manager is specified in the queue
manager's Key Repository attribute. SSLKEYR
Default value of this attribute will be the queue manager's ssl directorykey.....
If you have created the keystore file or keydata base with some other name , suppose qmkey .kdb,
then change the SSLKEYR attribute value with the same keystore name by altering the QMGR.
Extension of the keystore “ .kdb “ should not be included in the SSLKEYR attribute.
Otherwise during the SSL Handshake , it may throw an error “ Key repository cannot be found “.
42. MQ Security
Available Tools
IBM Global Security Kit (GSKit)
– Multiple Software versions
– Command Line
MQ version 7.0.1
Available Command line tool gsk7cmd,gsk7capicmd
MQ version 7.0.1 ( Fix Pack >=4 ) &
GSKit 8 installed
Available Command line tool gsk8cmd,gsk8capicmd
MQ version 7.1 , 7.5 , 8.0
Available Command line tool runmqakm,runmqckm
Open Source
– Command Line
openssl