Network Encryption

From Oracle FAQ
Jump to: navigation, search


[edit] Introduction

Since June 2013, Net Encryption is now licencied with Oracle Enterprise Edition and doesn't require Oracle Advanced Security Option.

Oracle Advanced Security provides the following features:

  • Transparent Data Encryption (TDE) protects information in the database from media theft by encrypting sensitive data on disk.
  • Data encryption and integrity to ensure the privacy of communications over any protocol into the Oracle database.
  • Strong authentication services such as Kerberos, PKI, and Biometrics and RADIUS-compliant smart cards.

This page summarizes the tests done to encrypt the network traffic between an Oracle client and an Oracle database and check data integrity.

Complete documentation can be found in:

[edit] Net encryption setup

[edit] Non JDBC or OCI (thick) JDBC client

To setup the net encryption, several lines have to be added to the sqlnet.ora file both on the client and server sides.

On the client side, the following line was added:


This line indicates to the server side that the client accepts secure net traffic if it requests for.

Other possible values are:

  • rejected: the client rejects any connection requiring secure net traffic
  • requested: the security service is activated if the other side requests or requires it
  • required: the client accepts the connection only if the other side accepts a secure traffic

On the server side, the following lines were added (the other values are also possible):


Encryption status according to client and server parameter values is summarized in the following table (ORA-12660 is the error returned by Oracle in these cases):

Rejected Accepted Requested Required
Rejected OFF OFF OFF ORA-12660
Accepted OFF OFF ON ON
Requested OFF ON ON ON
Required ORA-12660 ON ON ON

The tested encryption algorithms were (other ones are available, refer to the documentation above):

  • DES: Data Encryption Standard (an old 56 bit encryption method)
  • 3DES168: triple DES with a three-key (168 bit) option
  • AES128: Advanced Encryption Standard with 128-bit key (currently the most use for data encryption)
  • AES256: Advanced Encryption Standard with 256-bit key (currently the most secure)
  • RC4_128: RC4 with 128-bit key (RC4 is the international standard for high-speed data encryption)
  • RC4_256: RC4 with 256-bit key

Note that a list of encryption algorithms can be given (and not just one) on each side and a negotiation occurs at connection time to determine which one will be taken (actually, the first common one in the lists).

To improve the strength of key generation the parameter SQLNET.CRYPTO_SEED can be added. It is set to 10 to 70 random characters, the more random the characters are and the lengther the string is, the stronger the keys are.

[edit] Thin JDBC client

In this case, sqlnet.ora file is not read and taken into account; we have to set properties on the connection.

For example:

DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
Properties props = new Properties();
props.put("", "accepted");
props.put("", "RC4_128");
props.put("user", "XXX");
props.put("password", "YYY");
Connection conn = DriverManager.getConnection("jdbc:oracle:thin:@myhost:1521:mySID", props);

[edit] Data integrity setup

Oracle also allows to verify data integrity by adding a checksum using MD5 or SHA-1 algorithm. To setup this feature two lines have to be added to sqlnet.ora file both on the client and server sides.

On the client side:

SQLNET.CRYPTO_CHECKSUM_CLIENT = [ accepted | rejected | requested | required ] 
SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENT = <crypto_checksum_algorithms>

On the server side:

SQLNET.CRYPTO_CHECKSUM_SERVER = [ accepted | rejected | requested | required ] 
SQLNET.CRYPTO_CHECKSUM_TYPES_SERVER = <crypto_checksum_algorithms>

12.1 version introduced some SHA-2 algorithms.

[edit] Performances test

The performances test (with release 10.2) consists in querying 100 times the DBA_OBJECTS view (select * from dba_objects) and collecting the overall elapsed time (about 220MB are exchanged on network). Tests are done on a loopback address to prevent counting real network times and on a totally idle server: tests are the only processes to run.

Each test is executed 3 times for each of the previously listed algorithms. The average elapsed response time from the client point of view is reported in the following table.

None79.6 s 80.5 s101%82.4 s104%
DES104.7 s132%107.1 s135%108.2 s136%
3DES168151.8 s191%153.9 s193%155.6 s196%
AES12888.8 s112%90.5 s114%92.1 s116%
AES25691.8 s115%93.5 s117%94.2 s118%
RC4_12881.6 s103%82.5 s104%85.0 s107%
RC4_25681.7 s103%82.8 s104%85.0 s107%