Secure Communication between File-AID/EX components

This topic provides information on secured communication between different File-AID/EX components.

Overview of Secure Communication Configuration

 File-AID/EX is designed as a three-tier solution illustrated in the following figure:

Installation of the Data Studio client includes the communication manager and execution server components, which are used by default, but both components can be installed as separate services locally or remotely.

Data Studio supports two mechanisms of communication between the tiers:

• TCP/IP sockets
• Windows IPC (Inter-Process Communication, specifically - Named Pipes)

The Windows IPC mechanism is used only for communication between the tiers when they reside on the same machine and are parts of the same Workbench for Eclipse installation and run using the same workspace. In this scenario, the security of the communication is less critical, as no sniffing on the network would be able to capture the traffic between the tiers. This mechanism is used by default for communication between the client applications, the local communication manager and the local execution server. This can be changed to socket communication by adjusting an attribute in the configuration files.

To make the local communication manager to require the client applications and the local execution server to use socket communication when talking with it, open the 'manager.properties' file from '<workspace>\.com.compuware.fileaid.ex\cfg' directory and modify the UseIPCForLocal property to be set to "false". In this case the port specified as the port property in that file will be used for the socket communication.

To make the local execution server to require the local communication manager to use socket communication when talking with it, open the engine.properties file from <workspace>\.com.compuware.fileaid.ex\cfg directory and modify the UseIPCForLocal property to be set to false. In this case the port specified as the port property in that file will be used for the socket communication.

The rest of this section assumes that the communication between File-AID/EX tiers is implemented based on TCP/IP sockets. This is always the case for the most critical part of the communication - between the communication manager and Remote execution servers.

To prevent malicious network users from the ability to intercept network traffic and capture the exchange between different File-AID/EX components, starting with File-AID/EX Release 19.01 all communication is being encrypted using the standard Secure Socket Layer (TLS 1.2) mechanism.

This mechanism uses the RSA algorithm with public and private key pairs to establish the SSL handshake and to initiate secure exchange. Those keys are stored in keystore files, one for each tier, located in the in the <ProgramData>\BMC\FAEX\Cfg\security directory (on Windows, for Standalone execution server), or < Workbench for Eclipse>\.com.compuware.fileaid.ex\cfg\security directory (on Windows, for Data Studio) or <InstallDir>/cfg/security on UNIX/Linux), or <File-AID-Services InstallDir>\MMCServer\eclipse\workspace\configuration\security (for shared Communication Manger installed as part of File-AID Services on Windows). The names of the keystore files are:

• faexclient.keystore (for the client tier)
• faexcommmgr.keystore (for the communication tier)
• faexexecsvr.keystore (for the execution tier)

In addition to that, each tier is assigned a truststore file, which contains the certificate data of the File-AID/EX components that it can securely communicate with. The names of the truststore files are:

• faexclient.truststore (for the client tier)
  • Configured to trust only the communication tier (communication manager)

• faexcommmgr.truststore (for the communication tier)
  • Configured to trust the client and the execution tiers

• faexexecsvr.truststore (for the execution tier)
  • Configured to trust only the communication tier (communication manager) and itself (execution server

Finally, the main configuration directory (<ProgramData>\BMC\FAEX\Cfg or < Workbench for Eclipse>\.com.compuware.fileaid.ex\cfg (on Windows) or <InstallDir>/cfg on UNIX/Linux) or <File-AID-Services InstallDir>\MMCServer\eclipse\workspace\configuration (for shared communication manager on Windows)contains the following property files, which are defining the location and access to the keystores and truststores:

• clientSecurity.properties (client tier)
• managerSecurity.properties (communication tier)
• engineSecurity.properties (execution tier)

The keystore and truststore files can be queried and modified using the keytool.exe utility provided as part of JRE. It can be found, for example, in the jre/bin folder under File-AID/EX installation. See Oracle JRE documentation on the list of supported commands and their formats.

To open these files with keytool.exe (or other keystore management applications), a password is required. The following are the default passwords (case-sensative).

• cwfaexClient (client tier keystore and truststore)
• cwfaexCommMgr (communication tier keystore and truststore)
• cwfaexExecSvr (execution tier keystore and truststore)

Regenerating Keys for Secure Communication

Depending on the company security policies, it may be necessary to perform periodic changes of the keys used for secure communication between File-AID/EX tiers. File-AID/EX provides a tool that makes such a replacement easier.

Open Workbench for Eclipse with File-AID/EX feature and select File-AID/EX > Administration > Key Management from the menu. It opens the Key Management dialog box. Refer File-AID EX User Guide for details on how to use it.

Using the Key Management dialog box, a user can regenerate the keys and create new keystore and truststore files for each tier. It also generates new security properties files that contain encrypted passwords for them.

After the new files are generated, all existing and future installations of File-AID/EX (including Workbench for Eclipse with File-AID/EX feature) need to be updated to include the new keys. All running applications, including local and remote execution servers and the communication managers need to be restarted.

To simplify the step of updating of all installations, see the section Sharing Keystore and Truststore Files Between Multiple Installations.

Using Custom Keys for Secure Communication

While the approach described in the previous section allows to generate new keys, it may still be insufficient for companies that use specific PKI (Public Key Infrastructure) that may require that all keys used for secure communication to be generated by the PKI framework. Another example when use of keys provided externally is required is when company’s security policies require that all keys used in secure communication are certified by a trusted CA (Certificate Authority).

To use already existing public/private key pairs and certificates for secure exchange between File-AID/EX tiers, open the Key Management dialog box as described in the previous section. Select the option to not generate the new keys. The tool will then create new empty keystore and truststore files with the specified passwords. After that, the keytool applications included in the JRE can be used to populate the generated keystore and truststore files.

The keystore and truststore files used by File-AID/EX applications follow the PKCS 12 (.p12) format for keystores. If the custom public/private key pairs are not available as a .p12 file, and provided, for example, in .JKS or other forms, other third-party tools may be required to convert them to the .p12 format. One of the popular and powerful options is the OpenSSL toolkit. Consult OpenSSL documentation for details.

After the keystore files are populated with the custom keys, the JRE keytool utility can be used to export the certificates to files and then to import these certificates to the corresponding truststores. Refer to the Overview of Secure Communication Configuration for the details on which certificates should be imported to which truststores.

As with regenerated keys, after the keystore and truststore files are populated and tested, all existing and future installations of File-AID/EX (including Workbench for Eclipse with File-AID/EX feature) need to be updated to include the new keys. All running applications, including local and remote execution servers and the communication managers need to be restarted after the update.

To simplify the step of updating of all installations, see the section Sharing Keystore and Truststore Files Between Multiple Installations.

Assigning Different Sets of Keys to Different Installations of File-AID/EX 

In some scenarios, it may be beneficial to have different keys assigned to different installations of File-AID/EX.

For example, execution servers running in the production environments may have narrow restrictions on which users or client applications can access them. It is possible to generate separate sets of keys for such execution servers using one of the approaches explained above.

In order to give a certain group of the File-AID/EX client applications access to such remote execution server, use the JRE keytool utility to export its certificate to a file and then import that file to the client’s installation Communication Tier truststore (typically – faexcommmgr.truststore). Since two-directional certificate validation is performed, in order to establish secure communication, the client installation’s communication manager certificate should also be exported from its keystore and then imported to the execution server truststore.

This approach can also be used in another situation, for example – when the company switches to a new set of keys, and some of the client installations still use keystores with old keys. In order to allow such clients to communicate with certain execution servers over a grace period, the new keys certificates can be imported to execution servers’ truststores in addition to the old certificates. The execution servers will work with both sets of keys until all users have their keys updated, and then the old certificates can be safely deleted from the execution server truststore.

Sharing Keystore and Truststore Files Between Multiple Installations

While by default the keystore and truststore files are placed in the security directory under the cfg folder, it is possible to place them in any other location accessible to the users under which accounts the applications run. In many scenarios it is beneficial to place them to a shared directory on the network, in which case any updates of the keys will be instantly available to multiple (or all) installations of File-AID/EX.

In order to specify a different location for keystore and truststore files, open the corresponding *Security.properties file and modify the keystore and truststore properties.

For example, the default content of the engineProperties file contains the following lines:

These values provide the path to the keystore and truststore files relative to the cfg folder. Modify these values to point to a shared network location that contains the original (default), regenerated or custom files using standard UNC path.

Make sure that the shared directories that contain these files are protected and available only to the users designated to run (and maintain) File-AID/EX applications, and that the keystores and truststores of all remote execution servers are only available to the user accounts associated with those servers and to the administrators performing system maintenance, such as keys and certificates updates.