Network Encryption

Contents

 [hide] 

• 1 Introduction
• 2 Net encryption setup
  • 2.1 Non JDBC or OCI (thick) JDBC client
  • 2.2 Thin JDBC client
• 3 Data integrity setup
• 4 Performances test

Introduction[edit]

Since June 2013, Net Encryption is now licensed 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:

• Oracle Advanced Security Administrator's Guide Release 8.1.7, Chapter 2
• Oracle Advanced Security Administrator's Guide Release 2 (9.2), Chapter 2
• Oracle® Database Advanced Security Administrator's Guide 10g Release 2, Chapter 4
• Oracle® Database Advanced Security Administrator's Guide 11g Release 2, Chapter 8
• Oracle® Database Security Guide 12c Release 1, Chapter 13

Net encryption setup[edit]

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

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:

SQLNET.ENCRYPTION_CLIENT=accepted

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

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):

SQLNET.ENCRYPTION_SERVER=required
SQLNET.ENCRYPTION_TYPES_SERVER=<encryption algorithm>

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). If no algorithm are provided, all available ones are taken by default.

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.

Thin JDBC client[edit]

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("oracle.net.encryption_client", "accepted");
props.put("oracle.net.encryption_types_client", "RC4_128");
props.put("user", "XXX");
props.put("password", "YYY");
Connection conn = DriverManager.getConnection("jdbc:oracle:thin:@myhost:1521:mySID", props);

Data integrity setup[edit]

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.

Performances test[edit]

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.

Algorithm	None		MD5		SHA-1
	Time	%None	Time	%None	Time	%None
None	79.6 s		80.5 s	101%	82.4 s	104%
DES	104.7 s	132%	107.1 s	135%	108.2 s	136%
3DES168	151.8 s	191%	153.9 s	193%	155.6 s	196%
AES128	88.8 s	112%	90.5 s	114%	92.1 s	116%
AES256	91.8 s	115%	93.5 s	117%	94.2 s	118%
RC4_128	81.6 s	103%	82.5 s	104%	85.0 s	107%
RC4_256	81.7 s	103%	82.8 s	104%	85.0 s	107%