Communication between CAKM for Oracle TDE and CipherTrust Manager

The communication protocols available to establish connection between CAKM clients and CipherTrust Manager (CM) servers are:

• tcp

• ssl

Both clients and servers must use the same protocol. For instance, the communication may fail if your server applications are configured to accept ssl requests but your clients are not sending them.

When using the tcp protocol, data exchanged between the client and server will be in plain text. In contrast, the ssl protocol ensures that data is exchanged in encrypted form (cipher text).

Note

The recommended protocol is ssl, which utilizes TLSv1.3 or TLSv1.2.

To connect to a CM, you need to configure the following parameters in the properties file (CADP_PKCS11.properties):

• Protocol

• NAE_IP

• NAE_Port

• Load_Balancing_Algorithm

• Connection_Timeout

• Connection_Retry_Intervals

The mandatory parameters listed above are required to configure CAKM Load Balancing or CAKM Multi-tier Load Balancing.

To know more about these properties, refer to Configuring Properties File.

Communication between Oracle TDE and CAKM APIs

Oracle calls calls CAKM APIs to retrieve the master key as explained below.

• Oracle calls the CAKM agent to request the Master Key

  • Master key is a symmetric key

  • Master key is cached by the CAKM agent

    • To enable Master key caching, set the value of Symmetric_Key_Cache_Enabled to yes in the CADP_PKCS11.properties file

• When Oracle server will request the master key, key will be returned from the CAKM cache

• DEK is managed and cached by Oracle

How CAKM agent interacts with Cluster of CM

To know how CAKM agent interact with Cluster of CM, refer to CAKM Load Balancing and CAKM Multi-tier Load Balancing.

CAKM Load Balancing

A load balancing group consists of multiple CipherTrust Manager (CM) servers that clients can connect to. The load balancer, a feature for clients, decides the most efficient way to connect to these servers. When concurrent requests are made, the load balancer selects which server to utilize, aiming to evenly distribute connections across the servers.

To create a load balancing group, simply list several server IP addresses or hostnames (separated by colons) in the NAE_IP parameter.

For example:

• NAE_IP.1=10.0.0.2:10.0.0.3:10.0.0.4

• NAE_IP.2=10.0.0.5:10.0.0.6:10.0.0.7

All the members of a load balancing group must use the same CADP_PKCS11.properties file for configurations. If the client uses NAE_Port=9000, all NAE servers must use port 9000.

How it Works

The following steps outline the process when a client connects to the load balancing group for the first time:

1. The client requests a connection from the load balancer. Since this is the initial connection request, the load balancer randomly selects one of the servers and establishes a connection. For subsequent requests, the load balancer uses the Load_Balancing_Algorithm (which can be set to round-robin, random, or none) to determine which server to connect to.

2. The client waits for a server response for the duration of the Connection_Timeout.

3. If Server 1 does not respond within the timeout, the client ignores it for the duration specified by the Connection_Retry_Interval.

4. The client attempts to connect to Server 2.

5. The client successfully establishes the connection.

6. The client uses this connection to send a cryptographic request to Server 2.

7. Server 2 sends back a response.

8. The client receives this response. If persistent connections are enabled, the load balancer retains the connection in the connection pool; otherwise, the connection is closed.

9. The client requests another connection. The load balancer uses either the round-robin or random algorithm (or none) to choose which CipherTrust Manager to use. If persistent connections are enabled, the load balancer checks the connection pool for an existing connection.

Note

If persistent connections are not enabled, the load balancer does not create a connection pool. Connection pools allow the client to reuse existing connections after receiving a server response. It is advisable to enable persistent connections, as the performance overhead of maintaining a connection pool is significantly lower than the cost of establishing a new connection for each client request.

CAKM Multi-tier Load Balancing

The multi-tier load balancing feature allows you to establish several levels of load balancing groups, known as tiers. If one tier becomes unreachable, the system automatically switches to the next tier. The maximum tier allowed is three. It is essential to configure the tiers sequentially; for example, tier 3 cannot exist without both tier 1 and tier 2 being set up first.

The following parameters are tier-aware, that is, their values can vary by tier:

• CA_File

• Cert_File

• Connection_Idle_Timeout

• Connection_Retry_Interval

• Connection_Timeout

• Connection_Read_Timeout

• Key_File

• NAE_Port

• Passphrase

• Protocol

• Size_of_Connection_Pool

To vary the values in tier, add the suffix .n to the parameter's name, where n is the tier number. You can choose to apply one value to all tiers by omitting the .n suffix.

For example:

To set up the port for tiers 1, 2, and 3, you can set the following:

• NAE_Port.1=9000

• NAE_Port.2=9000

• NAE_Port.3=7000

You can also set the following:

• NAE_Port=9000

• NAE_Port.3=8000

Because tier 1 and tier 2 do not have their own settings, they use the Port value. Tier 3 uses the Port.3 value.

You can not set the following as there is no setting for tier 1:

• NAE_Port.2 = 9000

• NAE_Port.3 = 7000

How it Works

The following steps outline the process when a client connects to the multi-tier load balancing group for the first time:

1. The client attempts to connect to tier 1. Refer to CAKM Load Balancing for detailed steps.

2. If client cannot connect to any server on tier 1, it moves on.

3. The client tries to connect to a server in tier 2. The load balancer randomly selects one of the servers in tier 2 and attempts to establish a connection. For subsequent requests, the load balancer will use the Load_Balancing_Algorithm to determine which server to connect to. The client will continue using tier 2 until tier 1 becomes available, cycling through all servers across tiers.

4. The client successfully establishes a connection with server 3 in tier 2.

5. The client utilizes this connection to send a cryptographic request to server 3.

6. Server 3 responds.

7. The client receives the response. If persistent connections are enabled, the load balancer retains the connection in the pool; otherwise, the connection is closed.

8. The client requests another connection. The load balancer uses the Load_Balancing_Algorithm to select the server. If persistent connections are enabled, the load balancer will check the connection pool for an existing connection with that server.

Note

If persistent connections are not enabled, the load balancer does not create a connection pool. Connection pools allow the client to reuse existing connections after receiving a server response. It is advisable to enable persistent connections, as the performance overhead of maintaining a connection pool is significantly lower than the cost of establishing a new connection for each client request.

CAKM Connection Pooling

The connections that are used for multiple client requests and server responses are called persistent connections.

Once opened, these connections are cached in a connection pool. You set the properties that enable persistent connections, determine the maximum size of the connection pool, and control how long unused connections are maintained.

If you do not enable persistent connections, connections are closed as soon as the client receives the server response. CipherTrust Manager recommends enabling persistent connections. The performance cost of maintaining a pool is much less than the cost of opening a new connection for each request. To disable the persistent connection

How it Works

The following steps describe what happens when the feature is enabled, and the client attempts to connect to the server:

1. Your application calls for a connection to the server.

2. The client checks if Use_Persistent_Connectionsis set to yes.

3. The client searches the connection pool for an existing connection.

4. The client uses an existing connection, if available. Else, it creates a new connection if there is space in the pool. If there is no space, the client returns an error.

5. The client uses the connection to communicate with the server.

6. When the operation is done, the connection stays in the pool and can be reused by the client. The pool closes connections that have been idle for the duration specified in the Connection_Idle_Timeout.

Related Parameters

To use connection pooling, you need to set the following parameters in the properties file:

• Use_Persistent_Connections

• Size_of_Connection_Pool

• Connection_Idle_Timeout

To know more about these properties, refer to Configuring Properties File.