Securing Oracle E-Business Suite Applications Using Oracle Solaris

An Oracle White Paper

June 2013

Securing Oracle E-Business Suite Applications Using Oracle Solaris 11 on SPARC T5 and SPARC M5-32 Servers

Securing Oracle E-Business Suite Applications using Oracle Solaris 11 on SPARC T5 and SPARC M5-32 Servers

Introduction ....................................................................................... 1

Target Audience and Assumed Knowledge ....................................... 1

The Role and Relevance of Oracle’s SPARC T-Series Processor ..... 2

Oracle’s SPARC T5—Integrated Cryptographic Acceleration ............ 2

SPARC T5 Cryptographic Operational Model ................................ 4

The Role of the Oracle Solaris Cryptographic Framework Feature 4

End-to-End Application Security Using SPARC T5: Oracle E-Business Suite 12 Case Study ............................................ 4

Applied Security Scenarios ................................................................ 5

Transport-Layer Security ............................................................... 5

Web Tier: Transport-Layer Security ................................................... 6

Using Oracle Solaris KSSL for Web Tier Security .......................... 6

Application Tier: Transport-Layer Security ....................................... 11

Verifying Hardware-Assisted Security for Oracle Application Server ............................................................ 13

Database Tier Security .................................................................... 14

Oracle Database Security: Applied Scenarios ............................. 15

Securing Data at Rest Using ZFS Encryption .................................. 21

Summary ......................................................................................... 22

Further References.......................................................................... 22


1

Introduction

This document discusses how to secure Oracle E-Business Suite applications using Oracle

Solaris 11 security and the hardware-assisted cryptography capabilities of Oracle’s SPARC T5

processor-based servers. This document explores the end-to-end application security

scenarios, technical prerequisites, configuration, deployment, and verification guidelines for

Oracle E-Business Suite deployments running on Oracle Solaris 11-based SPARC T-Series

servers. In addition, this document covers Oracle SPARC T5 hardware-assisted cryptographic

acceleration where performance and data protection are deemed critical. The derived security

benefits can be leveraged into a variety of solutions including application software,

middleware, and infrastructure software.

The hardware-assisted cryptographic strategies and applied techniques presented in this

document have been tested and verified for use with Oracle E-Business Suite application

deployments on Oracle’s SPARC T4, Oracle’s SPARC T5, and Oracle’s SPARC M5-32

servers.

Target Audience and Assumed Knowledge

This document is intended for security practitioners as well as developers and administrators

of the Oracle E-Business Suite. Developers and administrators should be familiar with the

installation of Oracle’s SPARC T-Series processor-based servers, Oracle Solaris 11, Oracle E-

Business Suite security, Oracle Advanced Security and its features such as Transparent Data

Encryption and network encryption, Oracle HTTP server, and application security techniques

for secure communication using SSL/TLS protocols.


2

The Role and Relevance of Oracle’s SPARC T-Series Processor

As security has taken unprecedented importance in all facets of the IT industry, organizations are

proactively adopting cryptographic mechanisms to protect their businesses and information from

unauthorized access and ensuring its confidentiality and integrity during transit and in storage.

Cryptographic operations are heavily compute-intensive, burdening the host system with additional

CPU cycles and network bandwidth resulting in significant degradation of overall throughput of the

system and its hosted applications. For example, a host server capable of processing 1,000 transactions

per second can perform only 10 transactions per second after deploying SSL to secure communications

with the hosted application. To speed up cryptographic performance, security experts often

recommend and use cryptographic accelerator appliances to offload cryptographic operations and save

CPU cycles, enhancing the system throughput and its hosted applications. While useful, adopting a

specialized appliance for offloading cryptographic operations introduces a new set of costs,

complexities, and issues in terms of procurement, additional installation, configuration, testing

procedures, management, and support that significantly increases the power demands and costs of

deployment projects. Foreseeing the need for special-purpose hardware that can outpace workload

demands, Oracle introduced the industry's first and fastest on-chip hardware cryptographic capabilities

as part of the UltraSPARC T1 processor launched during 2005 and then continued to augment the

cryptography support into each new generation of Oracle’s SPARC T-Series family.

Oracle’s SPARC T5—Integrated Cryptographic Acceleration

The SPARC T5 processor is the fifth generation of Oracle’s SPARC T-Series family, and it leverages a

fundamental redesign of the core within a SPARC multicore/multithreaded processor architecture. By

redesigning the cores within each processor, introducing a new floating-point pipeline, and further

increasing network bandwidth, Oracle enabled the SPARC T5 processor to provide approximately 3X

the single-threaded throughput gains compared to its predecessor. The SPARC T5 processor includes

16 computing cores with 8 threads per core (128 threads per socket), on-chip memory management,

two 10 GbE interfaces, dual on-chip based PCIe generation 3 root complexes, on-chip/on-core based

cryptographic acceleration and hardware-enabled virtualization capabilities. As a result, the SPARC T5

processor eliminates the need for expensive custom hardware and software development by integrating

high-performance computing, security, and I/O onto a single chip.

The SPARC T5 features on-core cryptographic algorithms made available as unprivileged ISA

instructions. To support cryptographic operations, each core of the SPARC T5 processor contains a

stream-processing unit (SPU) that performs cryptographic functions at the same clock speed as the

computing core. The SPU on each is implemented within the core pipelines and is accessible by 29

new user-level instructions for performing cryptographic functions. During a cryptographic operation,

the cryptographic function will leverage SPU and also use parts of floating point/graphics unit (FGU)

and integer execution unit (EXU) pipelines with floating-point register files (FRF) and integer register

files (IRF). The logical depiction of SPU in the SPARC T5 processor is shown in Figure 1. As a result,

the SPU is designed to achieve wire-speed encryption and decryption on the processor's 10 GbE ports.


3

Figure 1: Oracle’s SPARC T5 processor—logical depiction of stream-processing unit (SPU)

The following Table 1 shows the cryptographic algorithms supported by the SPARC T5 processor.

ON-CORE CRYPTOGRAPHY SUPPORT ORACLE’S SPARC T5 PROCESSOR

ACCELERATOR DRIVER Userland (No drivers required)

PUBLIC KEY ENCRYPTION RSA, DSA, DH, ECC

BULK ENCRYPTION AES, DES, 3DES, RC4, Kasumi, Camellia

MESSAGE DIGESTS CRC32c, MD5, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512

APIS PKCS#11 Standard

Ucrypto APIs,

Java Cryptography Extensions (JCEs)

OpenSSL

Table 1: Oracle’s SPARC T5 processor—supported cryptographic algorithms


4

When compared to alternative on-chip/on-core implementations of competition processors, the

SPARC T5 offers a comprehensive set of algorithms supporting a long list of public-key encryption,

symmetric-key encryption, and message-digest algorithms.

SPARC T5 Cryptographic Operational Model

With the SPARC T5 and SPARC T4 processors, the applications can directly access the on-core

cryptographic functions, performing those functions in hardware without requiring use of special

configurations or drivers, kernel parameters, and administrative permissions.

Figure 2: SPARC T5 cryptographic operational model

The Role of the Oracle Solaris Cryptographic Framework Feature

In practice, the Oracle Solaris Cryptographic Framework acts as the core intermediary between the

applications and the underlying hardware. The framework enables user-level applications to

automatically leverage the hardware-assisted cryptographic acceleration functions. The Oracle Solaris

Cryptographic Framework libraries provide a set of cryptographic services and application

programming interfaces (APIs) whereby both kernel and user-level application consumers can

transparently delegate the cryptographic operations to hardware without adding any new code to the

application.

End-to-End Application Security Using SPARC T5: Oracle E-Business Suite 12 Case Study

The Oracle E-Business Suite applications can significantly gain security performance by offloading and

delegating their cryptographic operations to the on-core cryptographic capabilities of the SPARC T5

processor. In the case of Oracle E-Business Suite 12, the SPARC T5 processor’s on-core cryptographic


5

acceleration capabilities can be accessed in a variety of ways by the Oracle E-Business Suite

infrastructure components including Oracle HTTP Server, Oracle Application Server, and the Oracle

Database server.

Figure 3: Deployment of Oracle E-Business Suite: End-to-end security topology on SPARC T5

A typical deployment scenario of Oracle E-Business Suite infrastructure enabled with end-to-end

security topology (refer to Figure 3) requires the use of encryption at all levels to ensure secure data in

transit, secure data in processing, and secure data in storage. The SPARC T5-based cryptographic

acceleration can significantly contribute to the end-to-end security topology where the use of

cryptographic mechanisms is deemed critical. The delivery of high-performance security is

accomplished through the Oracle Solaris Cryptographic Framework that allows applications to

transparently offload and delegate their cryptographic operations to the on-core cryptographic

capabilities of the SPARC T5 processor. In addition, with the support of Oracle Solaris Cryptographic

Framework, the applications can leverage the Oracle Solaris-facilitated key storage and management

features.

Applied Security Scenarios

The Oracle E-Business Suite applications can offload select cryptographic operations to the SPARC T5

processor for the following applied security scenarios.

Transport-Layer Security

SSL/TLS is used to ensure confidentiality and integrity of the communication between the Oracle E-

Business Suite application tiers. With Oracle E-Business Suite deployment on SPARC T5 and SPARC

M5-32 servers, the computationally intensive SSL/TLS bound public-key encryption (ex. RSA, ECC),

bulk encryption (ex. AES, 3DES), message digest (ex. SHA1, SHA2), and random number generation

operations will be delegated automatically to perform using the on-core cryptographic instruction of

the SPARC T5 processor.


6

Web Tier Security—using SSL/TLS communication between the Oracle HTTP Server and the

client.

App Tier Security—using SSL/TLS reverse proxy communication between Oracle HTTP Server

and Oracle Application Server.

Database Tier Security—using SSL/TLS communication between Oracle Application Server and

Oracle Database.

Secure Data at Rest

Acceleration of cryptographic operations intended for supporting data stored in file system will be

accomplished through the use of encryption integrated with the Oracle Solaris ZFS file system. The

Oracle Solaris 11 ZFS encryption automatically leverages SPARC T5 hardware-assisted cryptographic

acceleration.

Secure Database

Oracle Database ensures confidentiality and integrity of data in transit and at rest using Oracle

Advanced Security options with the Transparent Data Encryption feature. Oracle Advanced Security

and Transparent Data Encryption combined provide support for network encryption, tablespace

encryption, and column-level data encryption. Both Oracle Advanced Security and Transparent Data

Encryption extend support for hardware-assisted cryptographic acceleration using Oracle’s SPARC T4

processor and Oracle Solaris 11 to support master key management operations.

Web Tier: Transport-Layer Security

To secure the transport layer of the Web tier, the Oracle E-Business Suite applications and their

hosting Oracle HTTP Server rely on the mod_ossl provider for SSLv3/TLSv1 protocols and Oracle

Wallet Manager for managing SSL certificates. On Oracle Solaris 11-based deployments, it is

recommended that the Oracle HTTP Server can make use of Oracle Solaris Kernel SSL proxy (KSSL)

service as an SSL proxy for handling transport-layer security operations. Like any other kernel module,

KSSL tightly integrates with the Oracle Solaris kernel and makes use of on-core cryptographic

acceleration provided by the SPARC T5 processor.

Using Oracle Solaris KSSL for Web Tier Security

KSSL is an Oracle Solaris kernel module that acts as a server-side SSL protocol service for offloading

operations such as SSL/TLS-based communication, SSL/TLS termination, and reverse proxies for

end-user applications. KSSL takes advantage of the Oracle Solaris Cryptographic Framework (SCF) to

act as an SSL proxy server, performing complete SSL handshake processing in the Oracle Solaris OS

kernel. KSSL automatically uses the SPARC T5 processor-based hardware-assisted cryptographic

acceleration, PKCS#11 keystores, and hardware security modules for enabling SSL acceleration and

secure key storage (refer to Figure 4).


7

The key technology aspects and the security benefits of using KSSL include:

Helps to introduce—nonintrusively—an SSL proxy server for Web servers, Java EE application

servers, and applications that do not support SSL.

Listens to secured requests on the designated SSL port (ex. http://:443) and renders cleartext traffic

via a reverse proxy port (ex. http://:8000) for an underlying Oracle HTTP Server.

All SSL operations, including the SSL handshake and session state, are performed asynchronously

in the Oracle Solaris kernel and without the knowledge of the target application server.

Automatically uses the Oracle Solaris Cryptographic Framework for off-loading operations to the

underlying hardware cryptographic accelerators without any extra effort.

Manages all SSL certificates independently and supports most standard formats, including PKCS12

and PEM. Key artifacts can be stored in a flat file (OpenSSL) or a PKCS#11 conforming keystore

(ex. HSMs, NSS, Oracle Solaris PKCS#11 softtoken) to help ensure the protection of private keys.

Supports the use of Oracle Solaris Zones. Each IP-identified zone can be configured with a KSSL

proxy.

Figure 4: Using the Oracle Solaris KSSL proxy for Web tier SSL with Oracle HTTP Server


8

Configuring KSSL for Oracle WebLogic SSL Acceleration

Using the KSSL kernel module as an SSL proxy requires obtaining and installing a certificate from a

certificate authority1. Here are the steps to configure a testing KSSL accelerator:

Using OpenSSL Certificates (Flat-File Keystore)

1. Create a self-signed certificate using openssl utility.

# /usr/sfw/bin/openssl req -x509 -nodes -days 365

-subj /C=US/ST=State/L=City/CN=serverhostname -newkey rsa:1024 -keyout /etc/pki/key00.pem -out /etc/pki/cert00.pem

2. Concatenate and place all certificate artifacts in a single file.

# cat cert00.pem key00.pem > /etc/pki/mySSLCerts.pem

3. Move to the /etc/pki directory and execute the following command.

# chown 600 mySSLCerts.pem

4. Configure the KSSL proxy and its redirect HTTP cleartext port. Assuming the Oracle

WebLogic server default listen port, or cleartext port, is port 7001. Make sure the

/etc/pki/passwordfile includes the password of the keystore.

# ksslcfg create -f pem -i /etc/pki/mySSLCerts.pem -x 7001 –p /etc/pki/passwordfile serverhostname 443

5. Use the Service Management Facility feature of Oracle Solaris to verify that KSSL service is

enabled.

# svcs -a | grep “kssl”

6. Alternatively, use the Oracle Solaris ‘netstat –an’ command to verify KSSL is listening on port

443.

# netstat -an | grep 443

7. Use a Web browser to check that the Oracle HTTP Server listens to the KSSL secured port.

Go to https://myservername.com:443

1 For production deployments the use of a certificate authority is essential. However, a self-signed certificate also can be used for testing purposes.


9

Using PKCS#11-Based Oracle Solaris Soft Token Keystore

To ensure the security of private-key and server certificates and tamper-proof keystores, it is often

recommended to use hardware security modules (HSMs). KSSL supports usage of PKCS#11-based

HSMs (ex. Oracle’s Sun Crypto Accelerator 6000 PCIe Card), software keystores (ex. NSS, Oracle

Solaris PKCS#11 sofftoken). The following command and options are typically used for configuring

PKCS#11-based keystores.

To configure KSSL using an Oracle Solaris PKCS#11 sofftoken the steps are as follows:

1. Configure a “Sun Software PKCS#11 Sofftoken” keystore using pktool utility.

# pktool setpin keystore=pkcs11

2. Create a self-signed certificate.

# pktool gencert keystore=pkcs11 label=”ksslCert” subject=”C=US,O=Oracle, OU=ISVE, CN=serverhostname”

serial=0x000000001

3. Enable “Sun Software PKCS#11 Sofftoken” token as metaslot.

# cryptoadm enable metaslot

token=“Sun Software PKCS#11 Softtoken”

Configure the KSSL service identifying the PKCS#11 keystore assuming the Softtoken is created in

the home directory of the user and the certificate alias is ksslCert. Make sure the

/etc/pki/passwordfile includes the password of the keystore. When creating the password file,

Oracle recommends restricting the associated file and directory permissions. In addition, a strong

password should be used.

4. # ksslcfg create –f pkcs11 –d $HOME/.sunw

-T “Sun Software PKCS#11 Sofftoken” -C “ksslCert” -p /etc/pki/passwordfile

-x 8000 serverhostname 443

5. To verify that KSSL service is enabled, execute the svcs command as follows:

# svcs -a | grep “kssl”

6. After completing the KSSL configuration, restarting the Oracle HTTP Server is required to

enable use of KSSL.

Using SSL Cipher Suites in KSSL


10

To enforce the KSSL service to negotiate using specific SSL3/TLSv1 cipher suites, the KSSL

configuration ksslconfig command must use -c option followed by the required list of

<cipherSuites> in a sorted order. For example, to use AES cipher suites

TLS_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_AES_256_CBC_SHA with

KSSL configuration:

# ksslcfg create –c rsa_aes_128_cbc_sha,rsa_aes_256_cbc_sha

-f pem -i /etc/pki/mySSLCerts.pem -x 7001 –p /etc/pki/passwordfile serverhostname 443

Oracle E-Business Suite Security Configuration for KSSL

To ensure KSSL service is in use for Web tier, it is critical to make the following Oracle E-Business

Suite configuration changes in the Context file. Users may choose to use Oracle E-Business Suite—

Oracle Application Manager Context Editor to change the following SSL-related variables as shown in

Table 2:

KSSL SERVICE : SSL/TLS CONFIGURATION IN CONTEXT FILE

VARIABLE NON-SSL CONFIGURATION SSL CONFIGURATION

s_url_protocol http https

s_local_url_protocol http https

s_webentryurlprotocol http https

s_active_webport Same as s_webport Same as KSSL_port

s_webssl_port Not applicable Same as KSSL_port

s_help_web_agent URL constructed with http protocol and

s_webport

URL constructed with https protocol and

KSSL port

s_login_page URL constructed with http protocol and

s_webport


KSSL port

s_external_url URL constructed with http protocol and

s_webport


KSSL port

s_webentryhost same as s_webhost Hostname used in KSSL configuration

s_webentrydomain same as s_webhost Domain name used in KSSL configuration

s_enable_sslterminator # Remove the # to use ssl_terminator.conf

Table 2: SSL/TLS Configuration in Context File for KSSL


11

7. If disabling the HTTP port and forcing all users to access the application via the HTTPS

protocol is desired, it is necessary to add the following redirect rule to

$INST_TOP/ora/10.1.3/Apache/Apache/conf/custom.conf file:

RewriteCond %{HTTPS} !=on RewriteRule ^/?(.*) https://<servername.domain>:<ssl port>/$1 [R,L]

8. After updating the Context file and custom config files, it is required to run the Autoconfig

scripts. Autoconfig can be run by using the adautocfg.sh script in the middle tier

$ADMIN_SCRIPTS_HOME directory.

Application Tier: Transport-Layer Security

In Oracle E-Business Suite 12, the Oracle Application Server environment is managed by Oracle

Process Monitoring and Notification services, which is a set of processes that include the Oracle

HTTP Server and Oracle Containers for J2EE (part of Oracle Application Server where the Java

Platform, Enterprise Edition [Java EE] application processes run). Thus it is critical to enable secure

communication between the Oracle HTTP Server and the Oracle Application Server layers using an

SSL/TLS configuration. Oracle Application Server enabled SSL/TLS communication between Oracle

HTTP Server and Oracle Application Server containers using AJPS.

1. To begin with enabling SSL/TLS between Oracle HTTP Server and Oracle Application Server

containers, it is required create and use a Java KeyStore (JKS) keystore for supporting the initial

storage of keys and certificates used with Oracle Application Server containers. The steps for

creating the JKS keystore and the key pairs for use with Oracle Application Server is as follows:

Logon to the application middle tier—Oracle Application Server environment.

Source the middle tier environment file (APPS<sid_machine>.env) located in the APPL_TOP

directory.

Navigate to the $INST_TOP/ora/10.1.3 and source the <sid_machine>.env file

to set the 10.1.3 ORACLE_HOME variables.

2. Create a new Java keystore along with an SSL certificate signing request (CSR) for use with Oracle

Application Server to support SSL/TLS communication. Use the Java keytool with -certreq

option to create a new RSA key pair with SHA1withRSA as the signature algorithm. The following

example shows creating a Java keystore keystore.jks and a key pair with alias sslcert using key

algorithm RSA and signature SHA1withRSA.

keytool -certreq -keyalg RSA -alias myalias -file certreq.txt -storepass changeit

-validity 365 -keystore keystore.jks

3. Once certificate authority signed the CSR, the signed certificate must be copied to

($INST_TOP/certs/j2ee) directory as jks_server.crt along with the certificate authority's root


12

certificate, which should be renamed jks_ca.crt, and the authority’s intermediate certificate (if

applicable), which should be renamed jks_intca.crt.

Now use the import command to add it to the keystore substituting the appropriate

parameters for the OC4J instance.

$ keytool -import -alias myca -keystore server.jks -storepass password -file jks_ca.crt

$ keytool -import -alias myintca -keystore server.jks -storepass password -file jks_intca.crt

$ keytool -import -keystore server.jks -storepass password -file jks_server.crt

Update the Context file to include SSL/TLS attributes for Oracle Application Server (Table

3).

ORACLE APPLICATION SERVER : SSL/TLS CONFIGURATION IN CONTEXT FILE

VARIABLE NON-SSL CONFIGURATION SSL CONFIGURATION

s_oc4j_secure false true

s_ajp_protocol ajp ajps

s_forms_tracking_cookies disabled enabled

s_oc4j_ssl off on

Table 3: SSL/TLS Configuration in Context File for Oracle Application Server

4. Stop all the services using the adstpall.sh script in the middle tier $ADMIN_SCRIPTS_HOME

directory.

5. Run AutoConfig using the adautocfg.sh script in the middle tier $ADMIN_SCRIPTS_HOME

directory.

6. Update the keystore password in the <credential> element of system-jazn-data.xml

file.

<user> <name>oc4jstore</name> <display-name>OC4J keystore admin user</display-name> <guid>7D1943D0AF0411DC8F65CFCE4073EF3D</guid> <description>E-Business OC4J keystore admin user</description> <credentials>changeme< credentials>

</user>


13

7. Restart the application tier services, using the $ADMIN_SCRIPTS_HOME/adstrtal.sh script.

Verify the Oracle E-Business Suite application to ensure both Web tier and app tier are accessible

via SSL/TLS communication.

On Oracle Solaris 11 SPARC deployments, the Java Cryptography Extension (JCE) provider is

bundled with the Java runtime environment, which facilitates the PKCS#11 interfaces for delegating

the cryptographic operations intended for SSL. The availability of PKCS#11 interfaces via Java

Cryptographic Extension (JCE) framework enables the Oracle Application Server-deployed

applications, XML Web services, and Java EE applications to automatically take advantage of on-core

cryptographic acceleration for SSL-based cryptographic workloads. The SunPKCS11 provider is a

Java-based PKCS#11 implementation that integrates with underlying PKCS#11 implementations

provided by the SCF and its exposed cryptographic providers. The SunPKCS11 provider does not

implement its own cryptographic algorithms (refer to Figure 5).

Figure 5: Oracle Application Server security using Oracle’s SPARC T5 server

With the above configuration, the cryptographic operations of the SSL/TLS protocol will

automatically take advantage of the SPARC T5 hardware-assisted cryptographic acceleration.

Accelerating SSL/TLS Using Oracle’s Ucrypto Provider

With the release of JDK7 update 4, Oracle introduced a new Ucrypto provider that leverages Oracle

Solaris 11 Ucrypto APIs for offloading and delegating of cryptographic operations supported by the

SPARC T4 based on-core cryptographic instructions. To leverage Oracle’s Ucrypto provider, it is

required to make sure that the Ucrypto provider is identified as the default provider in the Java security

properties file java.security located at $JAVA_HOME/jre/lib/security/ directory.

security.provider.1=com.oracle.security.ucrypto.UcryptoProvider ${java.home}/lib/security/ucrypto-solaris.cfg

Verifying Hardware-Assisted Security for Oracle Application Server


14

To ensure the hardware-assisted cryptographic acceleration is configured to use and working with the

security scenarios, it is recommended to use the following Oracle Solaris DTrace script. DTrace is a

feature of Oracle Solaris.

#!/usr/sbin/dtrace -s pid$1:libsoftcrypto:yf*:entry, pid$1:libmd:yf*:entry

{ @[probefunc] = count(); }

tick-10sec { printa(@);

clear(@); trunc(@,0); }

tick-100sec {exit(0);}

Save the above script as ‘cryptoverify.d’ file and run the DTrace script including the “OC4J server’s

Java process id” as command line argument.

# dtrace -s cryptoverify.d <OC4J Server Process ID>

For example, in an SSL/TLS encryption scenario using TLS_RSA_WITH_AES_128_CBC_SHA

cipher suite, a positive and growing value of aes jobs indicates that cryptographic acceleration is

operational on the target AES bulk encryption payloads. Refer to the following sample output.

# dtrace -s cryptoverify.d 5774 dtrace: script 'crypto-t4.d' matched 51 probes

CPU ID FUNCTION:NAME 65 83719 :tick-10sec yf_aes128_ecb_decrypt 39922

yf_aes128_load_keys_for_decrypt 39922 65 83719 :tick-10sec

yf_aes128_ecb_decrypt 44108 yf_aes128_load_keys_for_decrypt 44108 65 83719 :tick-10sec

yf_aes128_ecb_decrypt 44534 yf_aes128_load_keys_for_decrypt 44534

..

Database Tier Security

Oracle E-Business Suite 12 relies on Oracle Database security for ensuring confidentiality and integrity

of data in transit and at rest using encryption at all levels. As part of Oracle Advanced Security options

and Oracle Database 11g Transparent Data Encryption, Oracle Database features support for network

encryption, tablespace encryption, and column-level data encryption. Transparent Data Encryption


15

uses standard algorithms and facilitates a built-in key management services for supporting data

encryption. Since Oracle Database 11g (11.2.0.3), Transparent Data Encryption extended support for

hardware-assisted cryptographic acceleration using SPARC T5 processor and Oracle Solaris 11 to

support offloading cryptographic processing associated with tablespace encryption and master key

based operations (refer to Figure 5).

Figure 5: Oracle Database security: Applied security scenarios

Oracle Database Security: Applied Scenarios

Oracle Advanced Security option and Transparent Data Encryption play the role of encryption and

decryption of data stored in an Oracle Database and in transit by providing support for all encryption

operations applied to network communication, tablespace and column-level encryption, and encrypted

backups. Transparent Data Encryption has been tested and verified to use SPARC T5 hardware-

assisted cryptographic acceleration for most encryption operations. The applied security scenarios are

as follows:

Tablespace encryption

Master key management using PKCS#11

o Oracle Solaris PKCS#11 softtoken-based Oracle wallet

Centralized key store for securing the master key used to encrypt and

decrypt the keys performing actual data encryption.

Encryption/decryption of tablespace and column encryption keys

Encryption/decryption support for Oracle Data Pump utility


16

Encryption/decryption of backup/restore using Oracle Recovery

Manager (Oracle RMAN)

o Master key backup and recovery

Master Key Management Using Oracle Solaris PKCS#11 Softtoken

Oracle Database 11g supports the use of PKCS#11-based HSM keystore as Oracle wallet. Using

Oracle Solaris PKCS#11 softtoken-based Oracle wallet secures the master key from duplication and

copying during database and filesystem backups. This can be done using Oracle Solaris PKCS#11

sofftoken referred to as “Sun Software PKCS#11 Sofftoken.”

1. Configure a “Sun Software PKCS#11 Sofftoken” keystore using SCF pktool utility. Set

the PIN/Passphrase for accessing the Softtoken keystore.

# pktool setpin keystore=pkcs11 Create new passphrase:

Re-enter new passphrase:

2. Enable “Sun Software PKCS#11 Sofftoken” token as metaslot

# cryptoadm enable metaslot

token=“Sun Software PKCS#11 Sofftoken”

Copy the PKCS#11 library to Oracle suggested directory structure. On Oracle

Solaris SPARC environment, create a directory for the PKCS#11 library:

# mkdir –p /opt/oracle/extapi/64/hsm/sun/1.0.0/lib

Copy Oracle Solaris libpkcs11.so to the PKCS#11 library directory

# cp /usr/lib/sparcv9/libpkcs11.so

/opt/oracle/extapi/64/hsm/sun/1.0.0/lib

3. Make sure that Oracle install user:group for Oracle PKCS#11 library directory, and make

sure the directory is assigned with read and write privileges.

# chown –R oracle:oinstall <..directory...>

In the Oracle Solaris environment, users may choose to set an environment

variable (in the Oracle default user shell) “SOFTTOKEN_DIR” .

# export SOFTTOKEN_DIR=/export/home/oracle/.sunw

To configure Transparent Data Encryption to use the Oracle Solaris PKCS#11 softtoken, initially it is

required to setup an HSM-based Oracle wallet identifying the source of master key as HSM.


17

Edit the $TNS_ADMIN/sqlnet.ora and add an

ENCRYPTION_WALLET_LOCATION parameter as follows:

ENCRYPTION_WALLET_LOCATION =

(SOURCE=(METHOD=HSM) (METHOD_DATA=

(DIRECTORY = /export/home/oracle/11g/network/admin/)))]

Log in to SQLPlus as “system” or “sysdba” and create a HSM wallet.

$ sqlplus “/ as sysdba” SQL> alter system set encryption key

identified by “HSM Username:Password”;

Username:Password are the credentials of the dedicated user account for

Transparent Data Encryption for support performing master key management

operations with the Oracle Solaris PKCS#11 softtoken keystore.

If the database is previously using an Oracle software wallet, then users are able to migrate the master

key to the configured Oracle Solaris PKCS#11 softtoken. The migration process automatically

decrypts existing data objects and re-encrypts them using the newly created master encryption key on

the Oracle Solaris PKCS#11 softtoken. In case of Oracle Transparent Data Encryption configuration

previously configured using a “software wallet,” then it is required to migrate the master key from the

software wallet to HSM by adding MIGRATE USING “software_wallet_password” clause to

the preceding sqlplus command. The software_wallet_password is the original password for

the software wallet.

SQL> alter system set encryption key identified by

“HSM Password” migrate using “software_wallet_password”;

Oracle Tablespace Encryption

Oracle Database 11.2.0.3 introduced support for Oracle’s SPARC T4 and SPARC T5 hardware-

assisted cryptographic acceleration for Oracle Transparent Data Encryption. As the installation

process automatically identifies the processor of the host machine, te chnically there is no setup

required for the use of Oracle’s SPARC T4/SPARC T5 hardware-accelerated cryptography.

Once it is deployed, Oracle Database will use SPARC T5 hardware-accelerated cryptography for both

encryption and decryption operations involved with tablespace encryption, network encryption,

encrypted backups, and restore and encrypted dump files.

Testing and Verifying Oracle Transparent Data Encryption on Oracle’s SPARC T5 and Oracle Solaris 11

To test and verify Transparent Data Encryption using the master encryption key stored in the Oracle

Solaris PKCS#11 softtoken, we recommend the following list of SQL examples to demonstrate


18

Transparent Data Encryption operations that rely on the Oracle Solaris PKCS#11 softtoken resident

master key.

1. Make sure the database is up and running. Log in and connect to sqlplus as system.

$ sqlplus “/ as sysdba”

SQL> startup;

SQL> connect as system/password;

2. Verify opening and closing the Oracle Solaris PKCS#11 softtoken-based HSM wallet. Make

sure users use the username and password created for accessing Transparent Data Encryption.

SQL> ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY "tdepassword";

System altered.

SQL> select WRL_TYPE, STATUS from v$encryption_wallet;

WRL_TYPE STATUS

-------------------- --------------

HSM OPEN

SQL> ALTER SYSTEM SET WALLET CLOSE IDENTIFIED BY

"tdepassword";

System altered.

3. Creating an encrypted tablespace using HSM Wallet.

Make sure the HSM wallet is open.

SQL> ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY "tdepassword";

Now, create the encrypted tablespace.

SQL> CREATE TABLESPACE SCASecuredTablespace

2 DATAFILE

'/export/home/oracle/11g/oradata/scasecuretbs1.dbf'

3 SIZE 50M

4 ENCRYPTION

5 DEFAULT STORAGE(ENCRYPT);


19

4. Creating a table on encrypted tablespace, which automatically encrypts all data objects stored.

SQL> CREATE TABLE PERSON

2 (first_name VARCHAR2(11),

3 last_name VARCHAR2(10),

4 social_security_number NUMBER(9),

5 address VARCHAR2(25),

6 city VARCHAR2(25),

7 state VARCHAR2(2)) TABLESPACE SecuredTablespace;

5. Encrypted export/import files using Oracle Data Pump utility can use HSM resident master

key for encrypting and decrypting dump files.

By default, without specifying encryption makes all export dump file stored in an

unencrypted file. Here is the example showing export file dumped without encryption.

$ expdp system/oracle@sid tables=employee

To enforce export dump file encryption using master key, first make sure the HSM wallet

remains open. Users need to use ENCRYPTION_MODE=TRANSPARENT to enable

encryption of the dump file using the master key stored in the HSM wallet. Specifying

option, ENCRYPTION_MODE=DUAL encrypts the dump set using the master key

stored in the wallet and additionally using the password for encryption. Here is the

example:

$ expdp system/oracle@sid tables=employee encryption=all

encryption_password=pwd4encrypt encryption_algorithm=AES256

encryption_mode=DUAL

To import the dump file encrypted using master key, make sure the HSM wallet remains

open and set the option specifying the password used for encryption. Here is an example:

$ impdp system/oracle@Ssid encryption_password=pwd4encrypt

tables=employee table_exists_action=replace

6. Backup and restore of database using Oracle Recovery Manager (Oracle RMAN) can use

HSM resident master key.

Make sure the HSM wallet is open before performing backup/restore/recover database

command and also ensure the database is in archivelog mode. Here is the example:

SQL> shutdown immediate;

Database closed.


20

Database dismounted.

ORACLE instance shut down.

SQL> startup mount;

ORACLE instance started.

Database mounted.

SQL> alter database archivelog;

Database altered.

SQL> alter database open;

Database altered.

SQL> ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY

"oracle:password";

System altered.

SQL> exit

Use the rman utility, make sure to set encryption on before executing the backup command.

Here is the example:

RMAN> connect target sysoper/oracle;

connected to target database: sid (DBID=1555558107)

RMAN> set encryption on;

RMAN> backup as compressed backupset database;

Oracle Network Data Encryption

Oracle network data encryption enables encryption of data in transit over the network between the

Oracle Database server and the Oracle clients. Oracle Database supports the use of an Oracle Solaris

PKCS#11 keystore that leverages Oracle’s SPARC T4 and SPARC T5 hardware-assisted cryptographic

acceleration for performing select cryptographic operations. To enable this support, the Oracle wallet

must be configured to wallet type as PKCS#11 that allows the use of Oracle Solaris PKCS#11

softtoken instead of filesystem-based wallet. The Oracle Wallet Manager application allows configuring

the PKCS#11-based wallet to support storing and managing PKI certificate credentials including

private keys, certificates, and trusted certificates needed by SSL/TLS protocol for securing

communication and client/server authentication.

As a prerequisite, it is required to configure a “Sun Software PKCS#11 Softtoken” keystore. Refer to

steps (1) to (3) as described in section “Master Key Management using Oracle Solaris PKCS#11

Softtoken.” Once configured, use the Oracle Wallet Manager utility to set up the PKCS#11-based

Oracle wallet. To configure SSL/TLS, refer to the steps described in section “Configuring Secure

Sockets Layer Authentication” of Oracle Database Advanced Security Administrator’s Guide. It is


21

critical that the server choose SSL cipher suites, including algorithms supported by Oracle’s SPARC

T4/SPARC T3 processor. For example, SSL_RSA_WITH_AES_128_CBC_SHA is supported as it

uses RSA (handshake and authentication) and AES-128 for bulk encryption. The Oracle default SSL

cipher suite SSL_RSA_WITH_RC4_128_SHA requires the use of RC4 for bulk encryption, which is

not supported.

Securing Data at Rest Using ZFS Encryption

Both Oracle E-Business Suite infrastructure components and Oracle Database applications are tested

to install and run on the encrypted file system provided by Oracle Solaris 11 ZFS encryption

capabilities. By default, ZFS uses the Oracle Solaris 11 cryptographic services APIs, which

automatically benefit from the hardware acceleration of the AES algorithm available on the SPARC T5

processors. The policy for encryption is set at the dataset level when datasets (file systems or ZVOLs)

are created. Each ZFS on disk block (smallest size is 512 bytes, largest is 128 k) is encrypted using AES

algorithm in either CCM or GCM mode. The wrapping keys need to be provided by the Oracle Solaris

administrator who creates the file system, which can be changed at any time without taking the file

system offline. The data encryption keys are randomly generated at dataset creation time. The easiest

way to create the wrapping keys is to use the existing Oracle Solaris pktool command:

$ pktool genkey

keystore=file keytype=aes keylen=128

outkey=/export/home/user/mykey

Using ZFS encryption support can be as easy as this:

# zfs create -o encryption=on -o

keysource=raw,file:///export/home/user/mykey

myfilesystem/cryptofs

Alternatively, for ensuring secure storage and retrieval of wrapping keys, it is recommended to use the

Oracle Solaris PKCS#11 softtoken as keystore for storing wrapping keys. Using Oracle Solaris

PKCS#11 softtoken as keystore ensures that the wrapping key is encrypted in storage and the keystore

is protected by a PIN. The steps involved with creating and storing the wrapping key in an Oracle

Solaris PKCS#11 softtoken keystore and using the key to create an encrypted ZFS data set is as

follows:

# pktool genkey

keystore=pkcs11 keytype=aes keylen=128 label=mykey


22

Enter PIN for Sun Software PKCS#11 softtoken:

# zfs create -o encryption=on

-o keysource=raw,pkcs11:object=mykey myfilesystem/cryptofs

Enter PKCS#11 token PIN for ' myfilesystem/cryptofs’

In the example above, an AES key is created in the default softtoken keystore for the user. This

keystore requires authentication to create and use keys stored in it, so a user is prompted for the

keystore PIN (it is really a passphrase, but PKCS#11 terminology uses the word PIN for legacy

reasons). The syntax of the PKCS#11 URI that is used with the keysource property allows for

specifying a path to the PIN file. Using this method ensures that the actual wrapping key is encrypted

and protected in the PKCS#11 keystore.

For more details on ZFS encryption, refer to the Oracle Solaris ZFS Administration Guide.

Summary

This whitepaper presented various security strategies for Oracle E-Business Suite applications using

Oracle Solaris 11 security and Oracle’s SPARC T5 processor’s hardware-assisted cryptographic

acceleration features. The paper unveiled the core mechanisms, configuration, deployment strategies,

and the role and relevance of using the Oracle Solaris Cryptographic Framework and Java

Cryptographic Extensions-based techniques for delivering high performance end-to-end security

solution for Oracle E-Business Suite 12 and Oracle Database server applications. Adopting SSL/TLS

encryption for data in transit and encrypted data at rest has become critical for delivering end-to-end

security of multitier business applications and to meet regulatory compliance mandates.

The use of Oracle’s SPARC T5 hardware-assisted cryptographic acceleration for end-to-end security

deployments has certainly yielded tangible, immediate, and cost-efficient results in the form of faster

secure transactions and better response times—all without adding any additional security equipment

costs, changes in power usage profiles, or elaborate system configurations. The derived performance

characteristics will also clarify the massive burden unaccelerated cryptographic workloads can have on

a server. To summarize, Oracle’s SPARC T5 processor-based servers and blades has proven high-

performance enterprise security with consistent scalability for Oracle E-Business Suite 12 applications

and Oracle Database server, while also delivering reductions in space, power consumption, and cost.

Further References

Oracle E-Business Suite Documentation Library


23

http://docs.oracle.com/cd/E18727_01/index.htm

Oracle Fusion Middleware Documentation Library

http://docs.oracle.com/cd/E14571_01/soa.htm

Oracle Database Advanced Security Administrator’s Guide

http://docs.oracle.com/cd/E11882_01/network.112/e10746/toc.htm

Oracle Database Security Guide


Oracle’s SPARC T-Series Servers

http://www.oracle.com/us/products/servers-storage/servers/sparc-enterprise/t-series/index.html

Java PKCS#11 Reference Guide

http://download.oracle.com/javase/6/docs/technotes/guides/security/p11guide.html

Oracle Solaris Administration: Security Services

http://docs.oracle.com/cd/E23824_01/html/821-1456/index.html

Oracle Solaris ZFS Administration Guide

http://docs.oracle.com/cd/E19253-01/819-5461/index.html

http://docs.oracle.com/cd/E18727_01/index.htm

http://docs.oracle.com/cd/E14571_01/soa.htm



http://www.oracle.com/us/products/servers-storage/servers/sparc-enterprise/t-series/index.html

http://download.oracle.com/javase/6/docs/technotes/guides/security/p11guide.html

http://docs.oracle.com/cd/E23824_01/html/821-1456/index.html

http://docs.oracle.com/cd/E19253-01/819-5461/index.html

Securing E-Business Suite Applications using

Oracle Solaris 11 on SPARC T5 and SPARC

M5-32 Servers

June 2013

Author: Ramesh Nagappan

John Snyder

Glenn Brunette

Henry Chen

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

Worldwide Inquiries:

Phone: +1.650.506.7000

Fax: +1.650.506.7200

oracle.com

Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

This document is provided for information purposes only, and the contents hereof are subject to change without notice. This

document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in

law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any

liability with respect to this document, and no contractual obligations are formed either directly or indirectly by this document. This

document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our

prior written permission.

Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.

Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and

are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are

trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 0113

Documents

Securing Oracle E-Business Suite Applications Using Oracle Solaris