Knowledge Discovery 25.2
Knowledge Discovery Expert

# Encryption in Knowledge Discovery

Knowledge Discovery uses encryption in various operations. This article describes some of the methods it uses.

NOTE: In Knowledge Discovery, the document Access Control Lists (ACLs) are obfuscated to disguise the data values, rather than encrypted.

## Transport Layer Security

You can configure the Knowledge Discovery component ACI, Service, and Index ports to use Transport Layer Security/Secure Sockets Layer (TLS/SSL). You can configure this by setting the `SSLConfig` parameter. This parameter is available in various configuration sections, to set SSL settings for the different ports. You set the `SSLConfig` parameter to a configuration section that contains the SSL settings that you want to use for that port or communication type. For more information, refer to the Knowledge Discovery Administration Guide.

This configuration allows you to use HTTPS, rather than plain HTTP for communication between Knowledge Discovery components. Certificates allow you to lock down this communication to trusted sources and destinations.

The `SSLConfig` configuration mechanism is also used to configure outgoing connections to secured components, for example in the configuration of an SSL-enabled child server in a DAH configuration.

## Application Level Encryption

Knowledge Discovery can use a number of application level security methods.

GSSAPI Encryption

Knowledge Discovery components can use the Generic Security Services Application Program Interface (GSSAPI) to establish a security context between components and then encrypt messages that pass between those components. This method is available only for the ACI port. The components establish the context with an action. Further messages are encrypted by the API, and wrapped inside ACI encryption.

GSSAPI encryption requires the use of a client connection that supports persistent connections, because the context object is associated with a particular connection.

You can configure GSS authentication on the ACI, service, and index ports without using ACI encryption. In this case, you can use GSS authentication with standard HTTP/HTTPS libraries for encryption.

To use this option, you set the `GSSServiceName` configuration parameter for your service, and you set the `RequireGSSAuth` configuration parameter in the `[Server]`, `[Service]`, and `[IndexServer]` sections, as required.

AES Encryption

AES encryption uses the Advanced Encryption Standard. You can use AES encryption to encrypt `SecurityInfo` strings. To enable AES encryption, you can set the `SecurityInfoKeys` configuration parameter to the name of the AES key file. Knowledge Discovery components then use this key file to encrypt and decrypt the strings.

OEM Encryption

A Knowledge Discovery component running with OEM license keys (without a License Server component) is enforced by the license to use ACI request encryption. In OEM environments, the ACI request must always be encrypted, but the response is always sent unencrypted.

All your components must share the OEM encryption key. The Knowledge Discovery SDKs provide methods to work with the OEM communication key provided with the license key.

NOTE: You can also operate ACI servers with an Enterprise OEM license. The Enterprise OEM license uses License Server to provide a standard license, and also includes an embedded OEM encryption key that allows optional ACI request encryption, without any additional configuration in your ACI components. When you use encryption for a request (by using the `Encrypted` action), it acts like OEM encryption (with an encrypted request and unencrypted response).

This option provides a way for you to migrate an OEM system to the standard licensing model without requiring you to immediately change existing applications that use OEM encryption.

SecurityInfo

The SecurityInfo string identifies the documents that a user is allowed to see, by checking user and group permissions against the document ACL for the chosen security model. You can set the `SecurityInfoKeys` configuration parameter to configure SecurityInfo strings to use either AES or BTEA encryption, by setting it to the file name of the AES key file, or a list of BTEA keys.

OpenText recommends that you use AES encryption, which is a more secure encryption algorithm. In this case you set `SecurityInfoKeys` to the filename and path of an AES key file. The key file must consist of exactly 64 hexadecimal characters. To prevent unauthorized access, limit access to the key file to the users that the Knowledge Discovery services run under.

For older systems that use TEA encryption, you set `SecurityInfoKeys` to a comma-separated list of four signed 32-bit integers (between 0 and 2147483647). The default Content component and Community component configuration file gives a default set of keys. You must always change this default value when you install these components. The BTEA keys are stored in plain text in the configuration file, so be aware of who has access to this file.

You must set `SecurityInfoKeys` to the same value for all components.

Configuration Files

Some configuration parameters accept encrypted values. You can generate encrypted values for these parameters by using the `autpassword` command-line tool.

Typically you can encrypt password parameters.

Copyright 2025 Open Text
Version 25.2 | Last updated April 2025

Send documentation feedback

Close

Send documentation feedback

To send feedback using your default email client, open an email window.

Otherwise, send your feedback and the information below to MFI-swpdl.idoldocsfeedback@opentext.com.

We appreciate your feedback!

Product: Knowledge Discovery 25.2

Topic Title: Encryption in Knowledge Discovery