2
Configuring Data Encryption and Integrity

This chapter describes how to configure native Net8 data encryption and integrity for Oracle Advanced Security, in the following sections:

• Oracle Advanced Security Encryption

• Oracle Advanced Security Data Integrity

• Diffie-Hellman Based Key Management

• Configuring Data Encryption and Integrity

Oracle Advanced Security Encryption

This section describes data encryption algorithms available in the current release of Oracle Advanced Security:

• Overview

• DES Algorithm for Standards-Based Encryption

• Triple-DES Support

• RSA RC4 Algorithm for High Speed Encryption

  Note: Prior versions of Oracle Advanced Security provided three editions: Domestic, Upgrade, and Export--each with different key lengths. Release 8.1.7 now contains a complete complement of the available encryption algorithms and key lengths, previously only available in the Domestic edition. Users deploying prior versions of the product can obtain the Domestic edition for a specific product release.

Overview

The purpose of a secure cryptosystem is to convert plaintext data into unintelligible ciphertext based on a key, in such a way that it is very hard (computationally infeasible) to convert ciphertext back into its corresponding plaintext without knowledge of the correct key. In a symmetric cryptosystem, the same key is used both for encryption and decryption of the same data. Oracle Advanced Security provides the DES, 3DES, and RC4 symmetric cryptosystems for protecting the confidentiality of Net8 traffic.

DES Algorithm for Standards-Based Encryption

Oracle Advanced Security provides the Data Encryption Standard (DES) algorithm. DES has been a U.S. government standard for many years and is sometimes mandated in the financial services industry. Because it has been a standard for so long, DES is deployed throughout the world for use in a wide variety of applications.

Triple-DES Support

Oracle Advanced Security supports Triple-DES encryption (3DES), which encrypts message data with three passes of the DES algorithm. 3DES provides a high degree of message security, but with a performance penalty--the magnitude of which is dependant upon on the speed of the processor performing the encryption; 3DES typically takes three times as long to encrypt a data block as compared with the standard DES algorithm.

3DES is available in two-key and three-key versions, with effective key lengths of 112-bits and 168-bits, respectively. Both versions operate in outer Cipher Block Chaining (CBC) mode.

DES40 Algorithm

The DES40 algorithm, available in every release of Oracle Advanced Security, Oracle Advanced Networking Option, and Secure Network Services, is a variant of DES in which the secret key is preprocessed to provide 40 effective key bits. It was designed to provide DES-based encryption to customers outside the U.S. and Canada at a time when the U.S. export laws were more restrictive. Now, in Oracle Advanced Security Release 8.1.7, DES40, DES, and 3DES are all available for export. DES40 is still supported to provide backward-compatibility for international customers.

RSA RC4 Algorithm for High Speed Encryption

The RC4 algorithm, developed by RSA Data Security Inc., has become the international standard for high-speed data encryption. Despite ongoing attempts by cryptographic researchers to crack it, the only known method of unauthorized decryption is brute-force. RC4 is a variable key-length stream cipher that operates at several times the speed of DES, making it possible to encrypt even large, bulk data transfers with minimal performance consequences.

Oracle Advanced Security Release 8.1.7 provides an RC4 implementation with 40-bit, 56-bit, 128-bit, and 256-bit key lengths. This provides backward-compatibility and strong encryption, with no material performance compromise.

See Also: Configuring Encryption on the Client and the Server. Table 2-2, Valid Encryption Algorithms.

Oracle Advanced Security Data Integrity

Encryption of network data provides data privacy, so that unauthorized parties are not able to view plaintext data as it passes over the network. Oracle Advanced Security also provides protection against two forms of active attack:

Data Modification Attack	An unauthorized party intercepts data in transit, alters it, and retransmits it. Example: The monetary amount of $100 is changed to $10,000.
Replay Attack	An entire set of valid data is repetitively retransmitted. Example: A valid $100 withdrawal is resubmitted ten times.

Data Integrity Algorithms Supported

Oracle Advanced Security lets you select a keyed, sequenced implementation of the Message Digest 5 (MD5) algorithm or the Secure Hash Algorithm (SHA-1) to protect against both of these forms of attack. Both of these hash algorithms create a checksum that changes if the data is altered in any way. This protection operates independently from the encryption process--you can enable data integrity with or without enabling encryption.

See Also: Configuring Integrity on the Client and the Server. Table 2-3, Valid Integrity Algorithms.

Diffie-Hellman Based Key Management

The secrecy of encrypted data depends upon the existence of a secret key shared between the communicating parties. A key is a secret exclusively shared by parties on both sides of a connection. Without the key, it is extremely difficult (computationally infeasible) to decrypt an encrypted message or to tamper undetectably with a cryptographic-checksummed message. Providing and maintaining such secret keys is referred to as key management.

Secure key distribution is difficult in a multi-user environment. Oracle Advanced Security uses the well known Diffie-Hellman key negotiation algorithm to perform secure key distribution for both encryption and data integrity.

When encryption is used to protect the security of encrypted data, keys must be changed frequently to minimize the effects of a compromised key. For this reason, the Oracle Advanced Security key management function changes the session key with every session.

Authentication Key Fold-in

The purpose of Authentication Key Fold-in is to defeat a possible third party attack (historically called the man-in-the-middle attack) on the Diffie-Hellman key negotiation. It strengthens the session key significantly by combining a shared secret, known only to the client and the server, with the original session key negotiated by Diffie-Hellman.

The client and the server begin communicating using the session key generated by Diffie-Hellman. When the client authenticates to the server, they establish a shared secret that is only known to both parties. Oracle Advanced Security combines the shared secret and the Diffie-Hellman session key to generate a stronger session key designed to defeat a man-in-the-middle attack.

Note: The authentication key fold-in function is an imbedded feature of Oracle Advanced Security and requires no configuration by the system or network administrator.

Configuring Data Encryption and Integrity

This section describes how to configure Oracle Advanced Security native Net8 encryption and integrity, and presumes the prior installation of Oracle Net8.

The network or security administrator sets up the encryption and integrity configuration parameters. The profile on client and server systems using data encryption and integrity (sqlnet.ora file) must contain some or all of the parameters listed in this section, under the following topics:

• Activating Encryption and Integrity

• Negotiating Encryption and Integrity

• Setting the Encryption Seed

• Configuring Encryption and Integrity Parameters Using Net8 Assistant

  See Also: Chapter 9, Configuring Secure Socket Layer Authentication, to configure the SSL feature for encryption, integrity, and authentication

Activating Encryption and Integrity

In any network connection, it is possible for both the client and server to each support more than one encryption algorithm and more than one integrity algorithm. When a connection is made, the server selects which algorithm to use, if any, from those algorithms specified in the sqlnet.ora files.

The server searches for a match between the algorithms available on both the client and the server, and picks the first algorithm in its own list that also appears in the client list. If one side of the connection does not specify an algorithm list, all the algorithms installed on that side are acceptable. The connection fails with error message ORA-12650 if either side specifies an algorithm that is not installed.

Encryption and integrity parameters are defined by modifying a sqlnet.ora file on the clients and the servers on the network.

You can choose to configure any or all of the available Oracle Oracle Advanced Security encryption algorithms (Table 2-2), and either or both of the available integrity algorithms (Table 2-3). Only one encryption algorithm and one integrity algorithm are used for each connect session.

Note: Oracle Advanced Security selects the first encryption algorithm and the first integrity algorithm enabled on the client and the server. Oracle Corporation recommends that you select algorithms and key lengths in the order in which you prefer negotiation--probably with the strongest key length first.

See Also: Appendix A, Data Encryption and Integrity Parameters

Negotiating Encryption and Integrity

To negotiate whether to turn on encryption or integrity, you can specify four possible values for the Oracle Advanced Security encryption and integrity configuration parameters. The four values are listed in the order of increasing security. The value REJECTED provides the minimum amount of security between client and server communications, and the value REQUIRED provides the maximum amount of network security:

• REJECTED

• ACCEPTED

• REQUESTED

• REQUIRED

The default value for each of the parameters is ACCEPTED.

REJECTED

Select this value if you do not elect to enable the security service, even if required by the other side.

In this scenario, this side of the connection specifies that the security service is not allowed. If the other side is set to REQUIRED, the connection terminates with error message ORA-12650. If the other side is set to REQUESTED, ACCEPTED, or REJECTED, the connection continues without error and without the security service enabled.

ACCEPTED

Select this value to enable the security service if required or requested by the other side.

In this scenario, this side of the connection does not require the security service, but it is allowed if the other side is set to REQUIRED or REQUESTED. If the other side is set to REQUIRED or REQUESTED, and an algorithm match is found, the connection continues without error and with the security service enabled. If the other side is set to REQUIRED and no algorithm match is found, the connection terminates with error message ORA-12650.

If the other side is set to REQUESTED and no algorithm match is found, or if the other side is set to ACCEPTED or REJECTED, the connection continues without error and without the security service enabled.

REQUESTED

Select this value to enable the security service if the other side allows it.

In this scenario, this side of the connection specifies that the security service is desired but not required. The security service is enabled if the other side specifies ACCEPTED, REQUESTED, or REQUIRED. There must be a matching algorithm available on the other side--otherwise the service is not enabled. If the other side specifies REQUIRED and there is no matching algorithm, the connection fails.

REQUIRED

Select this value to enable the security service or disallow the connection.

In this scenario, this side of the connection specifies that the security service must be enabled. The connection fails if the other side specifies REJECTED or if there is no compatible algorithm on the other side.

Table 2-1 shows whether the security service is enabled, based on a combination of client and server configuration parameters. If either the server or client has specified REQUIRED, the lack of a common algorithm causes the connection to fail. Otherwise, if the service is enabled, lack of a common service algorithm results in the service being disabled.

Table 2-1 Encryption and Data Integrity Negotiation

Note: Encryption is not used when ACCEPTED is set to ON for both the client and the server.

Setting the Encryption Seed

Three seeds are used to generate a random number on the client and on the server. One of the seeds is a user-defined encryption seed (sqlnet.crypto_seed=) that can be 10 to 70 characters in length--and changed at any time. The Diffie-Hellman key exchange uses the random numbers to generate unique session keys for every connect session.

Configuring Encryption and Integrity Parameters Using Net8 Assistant

You can set up or change encryption and integrity parameter settings using Net8 Assistant. This section describes the following topics:

• Configuring Encryption on the Client and the Server

• Configuring Integrity on the Client and the Server

  See Also: Appendix A, Data Encryption and Integrity Parameters, for valid encryption algorithms Net8 Assistant online help, for more detailed configuration information

Configuring Encryption on the Client and the Server

To configure encryption on the client and on the server:

1. Start Net8 Assistant:
   • On UNIX, run netasst from $ORACLE_HOME/bin.

   • On Windows NT, choose Start > Programs > Oracle - HOME_NAME > Network Administration > Net8 Assistant.

2. In the Navigator window, expand Local > Profile.

3. From the list in the right window pane, select Oracle Advanced Security.

   The Oracle Advanced Security tabbed window appears:

   
   
4. Choose the Encryption tab.

5. Depending upon which system you are configuring, in the Encryption list, select CLIENT or SERVER.

6. From the Encryption Type list, select one of the following:
   • REQUESTED

   • REQUIRED

   • ACCEPTED

   • REJECTED

7. In the Encryption Seed field, enter between 10 and 70 random characters; the encryption seed for the client should not be the same as that for the server.

8. Select an encryption algorithm in the Available Methods list. Move it to the Selected Methods list by choosing the right arrow [>]. Repeat for each additional method you want to use.

9. Choose File > Save Network Configuration; the sqlnet.ora file is updated.

10. Repeat this procedure to configure encryption on the other system. The sqlnet.ora file on the two systems should contain the following entries:
    • On the server:

      SQLNET.ENCRYPTION_SERVER = [accepted | rejected | requested | required]
      SQLNET.ENCRYPTION_TYPES_SERVER = (valid_encryption_algorithm [,valid_
      encryption_algorithm])
      SQLNET.CRYPTO_SEED = "10-70 random characters"
      

    • On the client:

      SQLNET.ENCRYPTION_CLIENT = [accepted | rejected | requested | required]
      SQLNET.ENCRYPTION_TYPES_CLIENT = (valid_encryption_algorithm [,valid_
      encryption_algorithm])
      SQLNET.CRYPTO_SEED = "10-70 random characters"
      
      

Valid encryption algorithms and their associated legal values are summarized by Table 2-2:

Table 2-2 Valid Encryption Algorithms

Algorithm Name	Legal Value
RC4 256-bit key	RC4_256
RC4 128-bit key	RC4_128
RC4 56-bit key	RC4_56
RC4 40-bit key	RC4_40
3-key 3DES	3DES168
2-key 3DES	3DES112
DES 56-bit key	DES
DES 40-bit key	DES40

Configuring Integrity on the Client and the Server

To configure data integrity on the client and on the server:

1. Start Net8 Assistant:
   • On UNIX, run netasst from $ORACLE_HOME/bin.

   • On Windows NT, choose Start > Programs > Oracle - HOME_NAME > Network Administration > Net8 Assistant.

2. In the Navigator window, expand Local > Profile.

3. From the list in the right pane, select Oracle Advanced Security; the Oracle Advanced Security tabbed window appears:

   
   

4. Choose the Integrity tab.

5. Depending upon which system you are configuring, choose the Server or Client check box.

6. From the Checksum Level list, select one of the following checksum level values:
   • REQUESTED

   • REQUIRED

   • ACCEPTED

   • REJECTED

7. Choose File > Save Network Configuration; the sqlnet.ora file is updated.

8. Repeat this procedure to configure integrity on the other system. The sqlnet.ora file on the two systems should contain the following entries:
   • On the server:

     SQLNET.CRYPTO_CHECKSUM_SERVER = [accepted | rejected | requested | 
     required]
     SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = (valid_crypto_checksum_algorithm 
     [,valid_crypto_checksum_algorithm])
     

   • On the client:

     SQLNET.CRYPTO_CHECKSUM_CLIENT = [accepted | rejected | requested | 
     required]
     SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT = (valid_crypto_checksum_algorithm 
     [,valid_crypto_checksum_algorithm])
     
     

Valid integrity algorithms and their associated legal values are displayed by Table 2-3:

Table 2-3 Valid Integrity Algorithms

Algorithm Name	Legal Values
MD5	MD5
SHA-1	SHA1

Note: Under Oracle Advanced Security Release 8.1.7, two integrity algorithms are available: MD5 and SHA-1. MD5 can be enabled or disabled by using the Oracle Advanced Security tabbed window displayed under Configuring Integrity on the Client and the Server. To enable SHA-1, you must edit the sqlnet.ora file by adding SHA1 as a valid_crypto_checksum_algorithm.