Data Encryption Across the Network

---

If your database connection is not configured to use data encryption, data is sent across the network in a format that is designed for fast transmission. This format does not provide complete protection from hackers, and it can be decoded given some time and effort.

To address data security concerns, you might want to use data encryption to provide a more secure transmission of data. Consider using data encryption in the following scenarios:

You have offices that share confidential information over an intranet.
You send sensitive data, such as credit card numbers, over a database connection.
You need to comply with government or industry privacy and security requirements.

NOTE: Data encryption can adversely affect performance because of the additional overhead (mainly CPU usage) required to encrypt and decrypt data.

This section covers the following topics:

Supported Encryption Methods
Database-Specific Data Encryption
SSL Encryption
Configuring SSL for DB2
Configuring SSL for Oracle
Configuring SSL for Microsoft SQL Server
Configuring SSL for Sybase

Supported Encryption Methods

DataDirect XQuery supports the following encryption methods:

Database-specific encryption. DB2 defines its own encryption protocol for DB2 for Linux/UNIX/Windows and DB2 for z/OS only. See Database-Specific Data Encryption for more information.
Secure Sockets Layer (SSL). SSL is an industry-standard protocol for sending encrypted data over database connections. SSL secures the integrity of your data by encrypting information and providing client/server authentication. See SSL Encryption for more information.

Table 7-4 summarizes the data encryption methods supported by DataDirect XQuery.

Table 7-4. Data Encryption Methods Supported by DataDirect XQuery

Driver	Database-Specific	SSL
DB2 for Linux/UNIX/Windows	X	X1
DB2 for z/OS	X	X2
DB2 for iSeries		X3
Informix
MySQL
Oracle		X
Microsoft SQL Server		X4
Sybase		X

1Supported for V9.1 Fixpack 2 and higher for Linux/UNIX/Windows. 2Supported for DB2 v9.1 for z/OS. 3Supported for DB2 V5R3 and higher for iSeries. 4Supported for Microsoft SQL Server 2000 and higher.

Database-Specific Data Encryption

The DB2 driver supports a proprietary data encryption protocol for the following DB2 databases:

DB2 for Linux/UNIX/Windows
DB2 for z/OS

Configuring Data Encryption for DB2

To configure data encryption for a DB2 database:

Set the AuthenticationMethod property to clearText, encryptedPassword, or encryptedUIDPassword.
Set the EncryptionMethod property to DBEncryption or RequestDBEncryption.

SSL Encryption

SSL works by allowing the client and server to send each other encrypted data that only they can decrypt. SSL negotiates the terms of the encryption in a sequence of events known as the SSL handshake. The handshake involves the following types of authentication:

SSL server authentication requires the server to authenticate itself to the client.
SSL client authentication is optional and requires the client to authenticate itself to the server after the server has authenticated itself to the client.

NOTE: DB2 and Oracle are the only databases supported by DataDirect Connect for JDBC that support SSL client authentication.

The version of SSL that is used and which SSL cryptographic algorithm is used depends on which JVM you are using. Refer to your JVM documentation for more information about its SSL support.

Procedures for configuring SSL vary for the databases that support it. See the individual driver chapters for details about configuring SSL:

DB2 – Configuring SSL for DB2.
Oracle – Configuring SSL for Oracle
Microsoft SQL Server – Configuring SSL for Microsoft SQL Server
Sybase – Configuring SSL for Sybase

SSL Server Authentication

When the client makes a connection request, the server presents its public certificate for the client to accept or deny. The client checks the issuer of the certificate against a list of trusted Certificate Authorities (CAs) that resides in an encrypted file on the client known as a truststore. Optionally, the client may check the subject (owner) of the certificate. If the certificate matches a trusted CA in the truststore (and the certificate’s subject matches the value that the application expects), an encrypted connection is established between the client and server. If the certificate does not match, the connection fails and the driver throws an exception.

To check the issuer of the certificate against the contents of the truststore, the driver must be able to locate the truststore and unlock the truststore with the appropriate password. You can specify truststore information in either of the following ways:

Specify values for the Java system properties javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword. For example:

java -Djavax.net.ssl.trustStore=C:\Certificates\MyTruststore

and

java -Djavax.net.ssl.trustStorePassword=MyTruststorePassword

This method sets values for all SSL sockets created in the JVM.

Specify values for the connection properties TrustStore and TrustStorePassword. For example:

TrustStore=C:\Certficates\MyTruststore

and

TrustStorePassword=MyTruststorePassword

Any values specified by the TrustStore and TrustStorePassword properties override values specified by the Java system properties. This allows you to choose which truststore file you want to use for a particular connection.

Alternatively, you can configure the DataDirect Connect for JDBC drivers to trust any certificate sent by the server, even if the issuer is not a trusted CA. Allowing a driver to trust any certificate sent from the server is useful in test environments because it eliminates the need to specify truststore information on each client in the test environment. If the driver is configured to trust any certificate sent from the server, the issuer information in the certificate is ignored.

SSL Client Authentication (DB2 and Oracle)

If the server is configured for SSL client authentication, the server asks the client to verify its identity after the server has proved its identity. Similar to SSL server authentication, the client sends a public certificate to the server to accept or deny. The client stores its public certificate in an encrypted file known as a keystore.

The driver must be able to locate the keystore and unlock the keystore with the appropriate keystore password. Depending on the type of keystore used, the driver also may need to unlock the keystore entry with a password to gain access to the certificate and its private key.

DataDirect XQuery can use the following types of keystores:

Java Keystore (JKS) contains a collection of certificates. Each entry is identified by an alias. The value of each entry is a certificate and the certificate’s private key. Each keystore entry can have the same password as the keystore password or a different password. If a keystore entry has a password different than the keystore password, the driver must provide this password to unlock the entry and gain access to the certificate and its private key.
PKCS #12 keystore contains only one certificate. To gain access to the certificate and its private key, the driver must provide only the keystore password. The file extension of the keystore must be .pfx or .p12.

You can specify this information in either of the following ways:

Specify values for the Java system properties javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword. For example:

java -Djavax.net.ssl.keyStore=C:\Certificates\MyKeystore

and

java -Djavax.net.ssl.keyStorePassword=MyKeystorePassword

This method sets values for all SSL sockets created in the JVM.

NOTE: If the keystore specified by the javax.net.ssl.keyStore Java system property is a JKS and the keystore entry has a password different than the keystore password, the KeyPassword connection property must specify the password of the keystore entry. For example:

KeyPassword=MyKeyPassword

Specify values for the connection properties KeyStore and KeyStorePassword. For example:

KeyStore=C:\Certficates\MyKeyStore

and

KeyStorePassword=MyKeystorePassword

NOTE: If the keystore specified by the KeyStore connection property is a JKS and the keystore entry has a password different than the keystore password, the KeyPassword connection property must specify the password of the keystore entry. For example:

KeyPassword=MyKeyPassword

Any values specified by the KeyStore and KeyStorePassword properties override values specified by the Java system properties. This allows you to choose which keystore file you want to use for a particular connection.

Configuring SSL for DB2

The DB2 driver supports SSL encryption for the following databases:

DB2 V9.1 Fixpack 2 and higher for Linux/UNIX/Windows
DB2 v9.1 for z/OS
DB2 V5R3 and higher for iSeries

NOTE: Connection hangs can occur when the driver is configured for SSL and the database server does not support SSL. You may want to set a login timeout using the LoginTimeout property to avoid problems when connecting to a server that does not support SSL.

To configure SSL encryption:

Set the EncryptionMethod property to SSL.
Specify the location and password of the truststore file used for SSL server authentication. Either set the TrustStore and TrustStore properties or their corresponding Java system properties (javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword, respectively).
To validate certificates sent by the database server, set the ValidateServerCertificate property to true.
Optionally, set the HostNameInCertificate property to a host name to be used to validate the certificate. The HostNameInCertificate property provides additional security against man-in-the-middle (MITM) attacks by ensuring that the server the driver is connecting to is the server that was requested.
If your database server is configured for SSL client authentication, configure your keystore information:
Specify the location and password of the keystore file. Either set the KeyStore and KeyStore properties or their corresponding Java system properties (javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword, respectively).
If any key entry in the keystore file is password-protected, set the KeyPassword property to the key password.

Configuring SSL for Oracle

The Oracle driver supports SSL encryption for the following databases:

Oracle 11g (R1)
Oracle 10g (R1 and R2)
Oracle 9i (R1 and R2)

Oracle Advanced Security must be enabled on the database server to support SSL.

NOTE: Connection hangs can occur when the driver is configured for SSL and the database server does not support SSL. You may want to set a login timeout using the LoginTimeout property to avoid problems when connecting to a server that does not support SSL.

To configure SSL encryption:

Set the EncryptionMethod property to SSL.
Specify the location and password of the truststore file used for SSL server authentication. Either set the TrustStore and TrustStore properties or their corresponding Java system properties (javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword, respectively).
To validate certificates sent by the database server, set the ValidateServerCertificate property to true.
Optionally, set the HostNameInCertificate property to a host name to be used to validate the certificate. The HostNameInCertificate property provides additional security against man-in-the-middle (MITM) attacks by ensuring that the server the driver is connecting to is the server that was requested.
If your database server is configured for SSL client authentication, configure your keystore information:
Specify the location and password of the keystore file. Either set the KeyStore and KeyStore properties or their corresponding Java system properties (javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword, respectively).
If any key entry in the keystore file is password-protected, set the KeyPassword property to the key password.

Configuring SSL for Microsoft SQL Server

The SQL Server driver supports SSL encryption for the following databases:

Microsoft SQL Server 2000 or higher
Microsoft SQL Server 2000 Enterprise Edition (64-bit) or higher

Depending on your Microsoft SQL Server configuration, you can choose to encrypt all data, including the login request, or encrypt the login request only. Encrypting login requests, but not data, is useful for the following scenarios:

When your application needs security, but cannot afford to pay the performance penalty for encrypting data transferred between the driver and server.
When the server is not configured for SSL, but your application still requires a minimum degree of security. (Applicable to Microsoft SQL Server 2005 and higher only.)

NOTE: When SSL is enabled, the driver communicates with database protocol packets set by the server’s default packet size. Any value set by the PacketSize property is ignored.

Using SSL with Microsoft SQL Server

If your Microsoft SQL Server database server has been configured with an SSL certificate signed by a trusted CA, the server can be configured so that SSL encryption is either optional or required. When required, connections from clients that do support SSL encryption fail.

Although a signed trusted SSL certificate is recommended for the best degree of security, Microsoft SQL Server 2005 and higher can provide limited security protection even if an SSL certificate has not been configured on the server. If a trusted certificate is not installed, the server will use a self-signed certificate to encrypt the login request, but not the data.

Table 7-5 shows how the different EncryptionMethod property values behave with different Microsoft SQL Server configurations.

Table 7-5. EncryptionMethod Property and Microsoft SQL Server Configurations

Value	No SSL Certificate	SSL Optional	SSL Required
noEncryption	Login request and data are not encrypted.	Login request and data are not encrypted.	Connection attempt fails.
SSL	Connection attempt fails.	Login request and data are encrypted.	Login request and data are encrypted.
requestSSL	Login request and data are not encrypted.	Login request and data are encrypted.	Login request and data are encrypted.
loginSSL	Microsoft SQL Server 2005 and higher: Login request is encrypted; data is not. Microsoft SQL Server 2000: Connection attempt fails.	Login request is encrypted; data is not.	Login request and data are encrypted.

How to Configure SSL for Microsoft SQL Server

To configure SSL encryption for Microsoft SQL Server:

Choose the type of encryption for your application:
If you want the driver to encrypt all data, including the login request, set the EncryptionMethod property to SSL or requestSSL.
If you want the driver to encrypt only the login request, set the EncryptionMethod property to loginSSL.
Specify the location and password of the truststore file used for SSL server authentication. Either set the TrustStore and TrustStore properties or their corresponding Java system properties (javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword, respectively).
To validate certificates sent by the database server, set the ValidateServerCertificate property to true.
Optionally, set the HostNameInCertificate property to a host name to be used to validate the certificate. The HostNameInCertificate property provides additional security against man-in-the-middle (MITM) attacks by ensuring that the server the driver is connecting to is the server that was requested.

Configuring SSL for Sybase

The Sybase driver supports SSL encryption for the following databases:

Sybase Adaptive Server Enterprise 15.0
Sybase Adaptive Server Enterprise 12.5, 12.5.1, 12.5.2, 12.5.3, and 12.5.4

In addition, the Sybase Security and Directory Services package, ASE_SECDIR, is required.

NOTE: Connection hangs can occur when the driver is configured for SSL and the database server does not support SSL. You may want to set a login timeout using the LoginTimeout property to avoid problems when connecting to a server that does not support SSL.

To configure SSL encryption:

Set the EncryptionMethod property to SSL.
Specify the location and password of the truststore file used for SSL server authentication. Either set the TrustStore and TrustStore properties or their corresponding Java system properties (javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword, respectively).
To validate certificates sent by the database server, set the ValidateServerCertificate property to true.
Optionally, set the HostNameInCertificate property to a host name to be used to validate the certificate. The HostNameInCertificate property provides additional security against man-in-the-middle (MITM) attacks by ensuring that the server the driver is connecting to is the server that was requested.