As enterprises become dispersed geographically, an increasing number of applications are accessing databases over unsecured networks. Data transmitted over the network is susceptible to sniffing and integrity attacks. The confidentiality and integrity of data transmissions over the network can be ensured by encrypting the data.
Prior to 9.40.UC1, the IBM Informix® Dynamic Server (IDS) supported only the encryption of password sent for access validation. IDS 9.4 goes further by adding the ability to encrypt the entire client - server communication. IDS 9.4 utilizes OpenSSL (www.openssl.org) implementation of various industry standard encryption algorithms for encrypting communication.
In this article we first introduce you to various concepts and terminologies involved in science of cryptology. Then we go on to discuss how the encryption technology has been incorporated in IDS 9.4. In later sections, we tell you how to configure an IDS 9.4 engine and clients to enable encrypting client-server communication.
What is encryption?
Encryption is the transformation of data into an unreadable form using a key. This makes it impossible to convert the data back to intelligible form without access to the key.
Encryption keys are managed in two ways:
- Symmetric Cryptography – The same key is used for both the encryption and decryption of the data.
- Public Key Cryptography –The decryption uses a different key than the encryption.
Encryption techniques used by IDS
IBM Informix Dynamic Server uses symmetric cryptography technique. As symmetric cryptography uses the same key is used to encrypt and decrypt data, client and server should first decide on a secret key to be used for encryption.
How a client and server communicate the secret key over an insecure
IBM Informix Dynamic Server uses Diffie-Hellman (DH) algorithm to exchange a secret key over the network. As incredible as it may sound, DH algorithm allows two parties to negotiate a shared secret key, even if the whole world is listening to the information both parties are exchanging. The DH key exchange between a client and server is depicted in Figure 1.
Once the shared secret key is established between a client and a server, they can start encrypting the data over the network using this shared secret key. Now we will discuss encryption/decryption mechanism involved with the help of Figure 2.
Every data packet to be sent over the network is encrypted using one of many of the industry standard encryption algorithms or ciphers that IDS supports.
Now that we have the shared secret key and the cipher to be used, are we ready for encryption ….? Not yet!!!
There is one step remaining. Before we encrypt a data packet, we need to calculate Message Authentication Code for the data packet. A Message Authentication Code (MAC) is sent along with every data packet. This is to make sure that no one tampers with encrypted data on its way over the unsecured network. MAC is similar to a fixed length checksum. MAC is calculated from a given message using a Hashing algorithm along with a key. We will refer to this key as MAC key. Even if the message is changed slightly, the resulting MAC changes completely. IDS uses SHA1/HMAC or a XOR hashing algorithm for the MAC, based on parameters which you configure depending on your security requirements.
Note that as an added security, the key used to calculate the Mac Key is different from key used for data encryption that was negotiated between the two client-server. Now that we have the plain text message and the calculated MAC for it, IDS bundles them together and encrypts the bundle to generate an encrypted data packet. The encrypted data packet is sent over the network.
The receiving end decrypts the encrypted data to get the plain text data and the MAC tagged along with message. Then a MAC is calculated for the retrieved plain text. The calculated MAC is verified with the MAC received. An error will be flagged and logged in IDS log if the verification fails for any reason.
- IDS allows you to fine tune various parameters involved in the encryption mechanism.
- IDS does not use the same shared secret key for entire time client server session is active.
- The Shared secret key is renegotiated at regular intervals, which can be specified by the user.
- IDS also lets you determine which encryption algorithms (cipher) you want to use.
- IDS selects an algorithm from the specified cipher list periodically. You can control the periodicity of cipher switch as well.
- IDS lets you control the MAC generation, depending on the size of the message packet being sent.
- You may also turn off the MAC authentication completely.
Now that we understand how encryption-decryption works, let’s see how this mechanism is incorporated in IDS.
What is an Encryption CSM?
Encryption technology is integrated with IDS as a pluggable Communication Supports Module (CSM). IBM IDS 9.4 provides an encryption CSM (called hereafter as ENCCSM) which enables you to encrypt entire client-server communications. CSM is a pluggable component of the broad-scope Communication Service Support (CSS) feature. The main objective of CSS is to support customer defined logic providing extended communication services, such as data compression and data security. CSS is an IBM Informix proprietary API whereas CSM is a public API.
At the design level, the CSS-subsystem supports execution of event handlers. The event-handling functions are embodied in CSMs. The CSS functions corresponding to these event-handlers are invoked directly by the CSS-caller i.e. Association Services Facility (ASF) though a CSS-API.
CSM processes the data before reading or writing it over the network.
Following figure 3 shows how encryption CSM fits in on client and server ends.
An encryption CSM which has been plugged in on server end encrypts all data packets being sent to the client and decrypts all data packets received from client. Similarly an encryption CSM which has been plugged in on client end does the same job vice-versa.
On Solaris, for engine Encryption CSM shared library is $INFORMIXDIR/lib/iencs09a.so For CSDK it is $INFORMIXDIR/lib/client/iencs09a.so. For JDBC clients, java class com.informix.jdbc.Crypto is java implementation of encryption CSM. This class is packaged along with IBM Informix JDBC driver jar (ifxjdbc.jar).
Now it is time to do some real work. You will see how to configure an instance of IDS to use encryption.
Configuring IDS to use Encryption CSM
Configuring IDS for encryption involves two steps.
- Defining an encryption CSM:
A CSM is defined along with its attributes in a text file which is referred by name ‘concsm.cfg’. The concsm.cfg file is located in $INFORMIXDIR/etc by default or the location of the file can be changed by setting environment variable INFORMIXCONCSMCFG specifying the absolute path of the file.
Following is the syntax used to define a CSM in concsm.cfg file.
where ENCCSMNAME is the name identifying the CSM. path is the absolute path of the CSM shared library. The field after that allows you to specify various configurable attributes for the CSM.
The figure 4 contains examples of the same.
- Associating the defined CSM with a particular instance of
This is done by specifying the CSM name in the options field of $INFORMIXSQLHOSTS using syntax ‘csm=(csmname)’
Figure 4 below shows same.
Following table describes each of the encryption CSM attribute.
|Path||Absolute path of the encryption library (iencs09a.so)|
|Cipher||Defines all the ciphers to be used by a session|
|Mac||Defines the MAC key files to be used by the session|
|Switch||Defines the cipher and key switch frequencies|
For a complete list of supported values of various parameters, please refer to IBM Informix Dynamic Server Administrator's guide version 9.4
In the 9.40.UC2 release, another way is provided to configure Encryption CSM (ENCCSM). From IDS9.40.XC2 onwards , you can specify encryption parameters in a text file , and you can refer to that file in your csm config file. This simplifies the task of configuring and managing ENCCSM. The older way of configuration is also supported for backward compatibility. The original supported format - "cipher[options],mac[options], switch[options]" - for csm-global-option in concsm.cfg is replaced with . Thus newly supported concsm.cfg Format is The CSM parameter file has each CSM parameter in form The same has been shown in Figure 5.
The CSM Parameter file contains the values for each configurable CSM attributes as described below:
ENCCSM_CIPHERS: <Ciphers to be used> ENCCSM_MAC: <MAC level> ENCCSM_MACFILES: <MAC file location> ENCCSM_SWITCH: <comma separated list of CIPHER and KEY change intervals in seconds>
Refer to Figure 5 for example.
The following restrictions apply to the parameter values:
- Each entry should be of the form separated by white spaces.
- No white spaces allowed within a Value.
- Each parameter should have one entry in the config file. If duplicate entries exist, then only first entry is considered, others will be ignored.
- Default values will be taken if parameter does not exist in the config file.
- "#" is the comment character. Any characters after comment character will be ignored (except when # is part of pathname value).
Configuring Enterprise Replication (ER) to use encryption
Enterprise Replication is configured for encryption by setting encryption configuration parameters in the ONCONFIG file as opposed to specifying the ENCCSM module with the "csm" option in the SQLHOSTS file. The ENCRYPT_CDR configuration parameter must be set to 1 or 2 to allow encryption.
Following are the parameters from ONCONFIG which are configured for ER encryption:
where level of 0 - no encryption, 1 – try to encrypt, 2 – must encrypt. With ENCRYPT_CDR set to 1, encryption is only used if the peer server can support encryption.
ENCRYPT_CIPHER: <ciphers to be used for ER encryption.> ENCRYPT_MAC: <MAC level to use with ER encryption> ENCRYPT_MACFILE: <MAC key files to use with ER encryption> ENCRYPT_SWITCH: <comma separated list of CIPHER and KEY switch intervals in seconds>
Please refer to IBM Informix Dynamic Server Administrator's reference version 9.4 for details regarding ER encryption parameters.
Commonly encountered Errors
Now that you have defined a CSM and configured instance of database server to use that CSM, it is time to bring the engine up. You do oninit -yv and engine comes up without any errors. You see “Initialization of Encryption...succeeded” on console. Now comes the tricky part! IDS will not start CSM Virtual Processor until a connection request is being made to the engine.
Note that engine reads concsm.cfg file only once, i.e. When creating CSM virtual processor. Thus even if you have configured your concsm.cfg file incorrectly, engine comes up without any errors!!!
To ensure that encryption parameters are set correctly, make an attempt to connect to the engine over encrypted port using dbaccess. If you have configured everything correctly, your connection attempt shall be successful.
However if there is an error in CSM configuration parameters, you will get
"5006: CSM: invalid global options” error. If you get such an error, see
online log for detailed error message. For example, if you have misspelled
cipher name in cipher tag, you will see following in online log.
"listener-thread: err = -5006: oserr = 0: errstr = Unknown cipher/mode requested: CSM: invalid global options"
or if you have specified incorrect location of Mac key file , you will see
"listener-thread: err = -5006: oserr = 0: errstr = MAC key file could not be read or is invalid: CSM: invalid global options."
Take the necessary corrective action and bounce the engine. Verify that you can connect successfully to the engine over the encrypted port. Note that any changes to concsm.cfg file, will not come into effect until you bounce the engine.
Following your first unsuccessful connection attempt, if you make second
unsuccessful connection attempt, error which is logged in online log does
not give specific details of error. You will see following in log for
second and subsequent unsuccessful connection attempts.
"listener-thread: err = -5006: oserr = 0: errstr = : CSM: invalid global options."
This happens because CSM VP has already been created when the first connection was attempted and thus configuration file is not parsed again for attempting the second connection.
Now that you have configured IDS instance successfully, let’s see how we configure a client to make an encrypted connection.
Configuring Database Clients
To be able to connect to an instance of IDS on a port for which encryption is enabled, clients should be configured to define and use encryption CSM, as shown in Figure 3 above.
Note that a client which makes a connection using encryption CSM cannot connect to IDS on port which is not configured to use Encryption CSM. As we will see later, you may configure the same instance of IDS so as to handle encrypted connections on one port and non-encrypted connections on a different port.
Steps involved in configuring client to use encryption CSM are similar to those for the server.
- Defining an encryption CSM
- Associating the defined CSM with the Client
Refer to Figure 4 above for details.
However note that for clients, encryption CSM library (iencs09a.so) is located at different location than for server. For CSDK, Client encryption CSM shared library is located in $INFORMIXDIR/lib/client directory whereas for engine it is located in INFORMIXDIR/lib directory. The encryption CSM shared library is available with CSDK 2.81.XC1 and higher.
As far as JDBC clients are concerned, a new data source property ‘CSM’ has
been added to make a connection using encryption CSM. Here is a java code
snippet which sets the CSM
The java encryption CSM is available with JDBC 2.21.JC5 and higher.
When an encrypted connection is being established, client and server exchange list of values for each of CSM attribute. Then they determine upon a negotiated list of values for the CSM attribute. The negotiated values are used during the session. For cipher attribute, the negotiated list is a list of ciphers common to server and client encryption CSM. Ciphers from the negotiated list are used during the session. Unlike cipher which is changed periodically during session, only one Mac Key is used for entire life of session. If the client and server CSMs have more than one common Mac Keys, the one which is generated most recently is selected. The Mac level to be used for the session is the highest common denominator value between client and server Mac level lists.
The connection attempt shall fail if server is not able to decide upon a negotiated value for any of the encryption attributes. for example , server refuses connection in all of the following scenarios.
- If cipher list for Client CSM and Server CSM do not have any cipher in common. In this case server fails to determine a list of ciphers to be used for the session.
- If Client CSM specifies a Mac level of medium, while Server specifies a Mac level of high. There is no common highest denominator value.
- If client and Server CSMs do not have a common Mac Key listed in their respective Mac Key lists.
Here is table which discusses various possibilities. The table assumes that encryption parameters other than the ones listed in the table are set correctly
|Encryption CSM Parameter||Server CSM value||Client CSM value||Connection Successful||Reason|
|cipher||allbut<bf>||bf-1:cbc,bf-2:cbc:bf-3:cbc||NO||No common cipher|
|Mac Level||low,medium||high||NO||Mac Key level can not determined. (There is a bug in 9.40.XC1 which lets connection through in this scenario. Same has been addressed in 9.40.XC2)|
|Mac Level||high,low,medium||low,off||YES||Mac level of low shall be used|
|Mac Key File||ifx/macFeb.dat,/ifx/macMarch.dat||/ifxclient/macFeb.dat||YES||Mac Key from file macFeb.dat will be used|
Configuring an IDS instance to cater encrypted and Non-encrypted connections
In certain scenarios you may want to configure your IDS instance to cater both encrypted and non encrypted connections. DBAs can achieve this by configuring ALIASES. This can be achieved by creating an alias by setting DBSERVERALIAS parameter from onconfig file, as shown in Figure 6.
All database clients which do not use encryption CSM connect to dbserv_non_necrypt while encrypted connections should go to dbserv_encrypt.
Frequently asked questions
- Do I need to recompile my applications to be able to use
No. You need not recompile applications which have been compiled using versions of CSDK earlier to CSDK2.81.XC1.
Encryption CSM is a pluggable module. You just need to define a CSM and refer to same in your sqlhosts file.
- What versions of Client tools and engine do I need to use?
You need to use IDS 9.40.XC1 and above
CSDK 2.81.XC1 and greater.
JDBC 2.21.JC5 and greater.
This feature is available on all platforms on which IDS9.40XC1 is released.
- Do I need to install OpenSSL library to be able to use
No. OpenSSL libraries are bundled along with IDS distribution.
IDS 9.40 and CSDK 2.81 bundle contains OpenSSL library version 0.9.6g
However If you are using JDBC client, you need to ensure that Java cryptography provider is installed along with JDK.
- Does this feature encrypt data which is stored on the disk?
No. encryption CSM encrypts client-server communication only.
It does not encrypt data which is stored in dbspace or sbspace.
- Will I be able to generate SQLIDEBUG trace after enabling
Yes. As seen in Figure 3, encryption CSM is a layer between the SQLI and network layer.
Thus the data reaching SQLI layer is not in encrypted form.
Thus SQLIDEBUG functionality shall be available as it has been before.
This article shows you how to use the encryption over the wire feature of IBM Informix Dynamic server. In initial sections, you get an overview of industry standard encryption techniques used for encrypting data. Later, we discuss how IDS incorporates these techniques to secure client-server communication over an unsecured network. The article goes on to discuss various configurable encryption CSM attributes and the interface IDS provides to specify them. After reading this article one should be able to configure an IDS server instance and clients to encrypt client-server communication.
Glossary of encryption terms
Plaintext: The data to be encrypted is called plaintext.
Cipher text: The encrypted data, obtained by operating encryption algorithm and encryption key on the unencrypted or plaintext, is called cipher text.
Cipher: A cipher is any method or algorithm used for encrypting text.
MAC (Message Authentication Code): A bit string that is a function of both data (either plaintext or cipher text) and a secret key, and that is attached to the data in order to allow data authentication. Note: The function used to generate the MAC must be a one-way function.
- For Details regarding encryption parameters and syntax used to specify same IBM Informix Dynamic Server Administrator's guide version 9.4
- For details about Enterprise Replication encryption parameters IBM Informix Dynamic Server Administrator's reference version 9.4
- Download IDS 9.40 trial version