Applying Transparent Data Encryption

Learning Objective

After completing this topic, you should be able to

recognize how Transparent Data Encryption is set up

1. Transparent Data Encryption

Transparent Data Encryption, also known as TDE, is available with Oracle Advanced
Security, commonly known as ASO, and provides easy-to-use protection for your data
without requiring changes to your applications.
TDE allows customers to encrypt sensitive data in individual columns or entire
tablespaces without having to manage encryption keys.
TDE does not affect access controls, which are configured using database roles, secure
application roles, system and object privileges, views, Virtual Private Database, also
known as VPD, Database Vault, or Oracle Label Security.

Supplement
Selecting the link title opens the resource in a new browser window.

Learning Aid
Access the learning aid Style Considerations for more information on the style
considerations for the Oracle 11g Database used in this course.
Any application or user that previously had access to a table will still have access to an
identical encrypted table. TDE is designed to protect data in storage, but does not replace
proper access control.
TDE is transparent to existing applications. Encryption and decryption occur at different
levels, depending on whether it is at the tablespace or column level. But in either case,
encrypted values are not displayed and are not handled by the application.
For example, with TDE, applications designed to display a 16-digit credit card number do
not have to be recoded to handle an encrypted string that may have many more
characters.
Several regulatory requirements have penalties for OS breaches if sensitive data is not
encrypted in the OS files. TDE eliminates the ability of anyone who has direct access to

the data files to gain access to the data by circumventing the database access control
mechanisms.
Even users with access to the data file at the OS level cannot access the data
unencrypted. TDE stores the master key outside the database in an external security
module, also referred to as ESM, thereby minimizing the possibility of both PII information
and the encryption key being compromised.
TDE decrypts the data only after database access mechanisms have been satisfied. TDE
is less expensive to implement than either application-based or file-based encryption.
There are some more benefits of TDE:

encrypts data in data files, redo log and archive log files, memory (only for column encryption),
and file backups

manages keys automatically

does not require changes to the application, and

encrypts indexes
TDE applies the principle of defense in depth in its design. The key architecture is a twotier system.
The master key is stored in ESM. This is either an Oracle Wallet or a Hardware Security
Module, abbreviated as HSM. This external store is protected by a password, operating
system permissions, and encryption.
The master encryption key is used to encrypt the table, and tablespace encryption keys
are used to encrypt the data. So the data is encrypted with a key that is unique for a
tablespace or a table. These keys are stored in the database in an encrypted form. They
have been encrypted with the master key, which is stored in ESM on the OS.
Some security regulations require a periodic change of encryption keys. This change of
keys means that the items that are encrypted are decrypted with the old key and
encrypted with the new key. This is also called rekeying.
A major advantage of the two-tier architecture is that table-level keys can be rekeyed by
changing the master key. This automatically causes table-level keys to be rekeyed, but
the table-level keys remain unchanged. So the data does not require rekeying. This
operation meets the Payment Card Industry requirement for rekeying, with a minimum of
overhead.
With TDE, you can specify different encryption algorithms to be used at the table or the

tablespace level. The available algorithms are 3DES168, AES128, AES192, and AES256.
The default is AES128.
TDE enables encryption for sensitive data in columns without requiring users or
applications to manage the encryption key. This freedom can be extremely important
when addressing, for example, regulatory compliance issues.
There is no need to use views to decrypt data because the data is transparently
decrypted when a user has passed the necessary access control checks. Security
administrators have the assurance that the data on disk is encrypted, yet handling
encrypted data is transparent to applications.
ESM is implemented through API that allows a variety of possible key storage solutions.
The default ESM is Oracle Wallet. HSM from several vendors are also supported for
storage of master keys.
TDE support of HSM varies by database version and whether it is column level or
tablespace level.

2. Creating the master key

Transparent Data Encryption, also known as TDE, creates a key for each table that uses
encrypted columns and each encrypted tablespace. The table key is stored in the data
dictionary, and tablespace keys are stored in tablespace data files. Both tablespace and
table keys are encrypted with a master key.
There is one master key for the database. The master key is stored in a PKCS12 wallet or
a PKCS11-based Hardware Security Module, abbreviated as HSM, outside the database.
For the database to use TDE, a wallet must exist.
To create a wallet and a master key, create a directory to hold the wallet, which is
accessible to the Oracle owner.
Then specify the location of the wallet file used to store the encryption master key by
adding this entry in $ORACLE_HOME/network/admin/sqlnet.ora.

Code
ENCRYPTION_WALLET_LOCATION=
(SOURCE=(METHOD=FILE)(METHOD_DATA=
(DIRECTORY=/u01/app/oracle/product/11.1.0/db_1/wallet)))
Then connect to the database as a user with appropriate privileges. The user must have
the ALTER SYSTEM privilege.

Code
sqlplus / as sysdba
After connecting to the database, create the encrypted wallet file using this command.

Code
SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY
"<password>";
If no encrypted wallet is present in the directory defined in SQLNET.ORA, it
1. creates an encrypted wallet (ewallet.p12)
2. opens the wallet, and
3. creates the database server master encryption key for TDE
If an encrypted wallet already exists, it
1. opens the wallet
2. creates or re-creates the database server master encryption key for TDE, and
3. re-encrypts the table and tablespace keys
Before encrypted columns can be viewed by a user, the wallet must be opened. A user
with the ALTER SYSTEM privilege must issue this command, where welcome1 is the
wallet password.

Code
ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY
welcome1;
If the wallet is not open and the user attempts to access an encrypted column, an error
message is generated.

Code
SQL> connect scott/tiger
Connected.
SQL> desc cust_payment_info
Name Null? Type

--------------------------------- -------- --------------FIRST_NAME VARCHAR2(11)

LAST_NAME VARCHAR2(10)
ORDER_NUMBER NUMBER(13)
CREDIT_CARD_NUMBER VARCHAR2(20) ENCRYPT
Oracle Database 11g: Security 18 - 10
Opening the Wallet (continued)
SQL> select first_name, last_name from cust_payment_info;
FIRST_NAME LAST_NAME
----------- ---------Jon Oldfield
Chris White
Alan Squire
SQL> select * from cust_payment_info;
select * from cust_payment_info
*
ERROR at line 1:
ORA-28365: wallet is not open

3. Using the auto login wallet

You can create an auto login wallet with the mkwallet utility or Oracle Wallet Manager.
The auto login wallet allows convenient access to encrypted data across database
instance restarts but removes the extra layer of separation of duties because the security
officer does not have to open the wallet before encrypted data can be accessed.
Transparent Data Encryption, also known as TDE, uses an auto login wallet only if it is
available at the correct location and the SQL command to open an encrypted wallet has
not already been executed. If an auto login wallet is being used, you must not use the
ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY "password" command.

Graphic
The Oracle Wallet Manager start page is open. The page has three menu options:
Wallet, Operations, and Help. On the navigation pane on this page, the Wallet
node is expanded to display the Certificate and Trusted Certificate nodes.
To set the wallet to auto login, perform the following steps:

Start Oracle Wallet Manager (owm on UNIX).

From Oracle Wallet Manager, open the wallet using the password.
The Wallet menu contains various menu options such as New, Open, and Download From The
Directory Service.

Provide the wallet directory location if the wallet is not in the default location. (The default location
of the wallet is /etc/ORACLE/WALLETS/oracle.)
You provide the wallet directory location using the Select Directory dialog box. The directories
listed in the Select Directory dialog box include gnome, gtk, and httpd.

From the Wallet menu, select the Auto Login checkbox.

Other menu options in the Wallet menu include Save In System Default, Delete, Change
Password, and Exit.

Exit Oracle Wallet Manager by selecting Exit from the Wallet menu.

Note
Do not delete the encryption wallet; otherwise, master rekey operations will no
longer be possible. When using an auto login wallet, the new master key is
generated in the encryption wallet and then replicated into the auto login wallet.
The master keys are required to access encrypted data, and you must protect these keys
with backups. Because master keys reside in Oracle Wallet, the wallet should be
periodically backed up in a secure location along with the database data files. You must
back up a copy of the encryption wallet whenever a new master key is set.
If you lose the wallet that stores the master key, you can restore access to encrypted data
by copying the backed-up version of the wallet to the appropriate location. If the restored
wallet was archived after the last time the master key was reset, no additional action
needs to be taken.
If the restored wallet does not contain the most recent master key, you can recover old
data up to the point when the master key was reset by rolling back the state of the
database to that point in time.
All modifications to encrypted columns after the master key was reset are lost. There are
two wallets present whenever the wallet is open an obfuscated wallet with the extension
of sso and the encryption wallet identified with the p12 extension.
The obfuscated wallet is changed every time the wallet is opened, so it is not useful to
include it in backups. The encryption wallet holds current and past master keys. It must
be included in backups. There are separate and distinct wallets used for Recovery
Manager, also known as RMAN, and Oracle Secure Backup, abbreviated as OSB,
encryption.

You need to regenerate the master key only if it has been compromised. Changing the
master periodically may be required by regulation.
Change the master key with this command, where password is the wallet password.

Code
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "<password>";
The master key is generated by TDE using a random number generator.
The external security module, also referred to as ESM, is designed to hold a large
number of keys, but the capacity of ESM to hold keys is limited. Frequent regeneration of
the master key does not increase security and can exhaust the capacity of ESM.
The limit is determined by the maximum file size on the OS. The wallet is the default
ESM. All past master keys are held in the wallet or Hardware Security Module,
abbreviated as HSM, and are available if the old data is recovered from a backup or if the
database is recovered to a point in time before the key was regenerated.
Regenerating the master key does not cause the column data to be re-encrypted. It is not
possible to rekey a TDE tablespace. The workaround is to create a new tablespace with a
new, different key, and then move the tables and other objects to that tablespace.

Question
Which statements accurately describe master key regeneration?
Options:
1.

Frequent regenerations of keys increases security

2.

All past master keys are held in the wallet or HSM

3.

Regenerating the master key causes column data to be re-encrypted

4.

A master key only needs to be regenerated if it's been compromised

Answer
Option 1: This option is incorrect. Frequent regeneration of the master key does
not increase security, and can exhaust the capacity of the external security
module. The limit is determined by the maximum file size on the OS.
Option 2: This option is correct. The wallet is the default ESM. All past master
keys are held in the wallet or HSM and are available if old data is recovered from
a backup or if the database is recovered to a point in time before the key was
regenerated.

Option 3: This option is incorrect. Regenerating the master key does not cause
column data to be re-encrypted.
Option 4: This option is correct. You need to regenerate the master key only if it
has been compromised. Changing the master periodically may be required by
regulation.
Correct answer(s):
2. All past master keys are held in the wallet or HSM
4. A master key only needs to be regenerated if it's been compromised
In these two examples, a new key is generated. The first line generates a new key based
on the algorithm that was specified when the table columns were encrypted.
The second line generates a new key and changes the algorithm. Both examples cause
all encrypted data in the tables to be decrypted and updated with a new encrypted value.

Code
ALTER TABLE card_payment_info REKEY;
ALTER TABLE employee REKEY USING '3DES168';

Note
There is only one key and one algorithm per table, even if multiple columns are
encrypted in the table.
Rekeying individual table keys is an UPDATE operation because all encrypted values are
decrypted and re-encrypted.
There are some best practices that you should follow. Usually, rekeying the master is
sufficient to achieve the Payment Card Industry compliance. It does not impact the
availability of your database.

4. Using hardware security modules

Hardware Security Modules, abbreviated as HSM, is a physical device that provides
secure storage for encryption keys. It also provides secure computational space
(memory) to perform encryption and decryption operations.
HSM is a more secure alternative to Oracle Wallet. Transparent Data Encryption, also
known as TDE, can use HSM to provide enhanced security for sensitive data. HSM is
used to store the master encryption key used for TDE. The key is secure from

unauthorized access attempts because HSM is a physical device and not an operating
system file.
All encryption and decryption operations that use the master encryption key are
performed inside HSM. This means that the master encryption key is never exposed in
insecure memory.
HSM can be used for TDE Tablespace Encryption when TDE Tablespace Encryption has
not been used before with a wallet. The existing master key cannot be migrated from a
wallet to HSM.
If the master key is initially created in HSM, it can be used for TDE Tablespace
Encryption. There are several vendors that provide HSM. The vendor must also supply
the appropriate libraries.

Question
What are the features of HSM?
Options:
1.

It is a physical device that provides secure storage for encryption keys

2.

It provides secure memory for performing encryption and decryption operations

3.

It can be used for TDE Tablespace Encryption when TDE Tablespace Encryption
has been used before with a wallet

4.

If a master key is created in HSM, it cannot be used for TDE Tablespace Encryption

Answer
Option 1: This option is correct. HSM is a physical device that provides secure
storage for encryption keys. There are several vendors that provide HSM.
Option 2: This option is correct. HSM provides secure computational space to
perform encryption and decryption operations. HSM is a more secure alternative
to Oracle Wallet.
Option 3: This option is incorrect. HSM can be used for TDE Tablespace
Encryption when TDE Tablespace Encryption has not been used before with a
wallet. The existing master key cannot be migrated from a wallet to HSM.
Option 4: This option is incorrect. If the master key is initially created in HSM, it
can be used for TDE Tablespace Encryption.
Correct answer(s):

1. It is a physical device that provides secure storage for encryption keys

2. It provides secure memory for performing encryption and decryption operations
The ENCRYPTION_WALLET_LOCATION parameter in the SQLNET.ORA file specifies the
location of Oracle Wallet. To use HSM in place of a software wallet, you need to set the
METHOD attribute of the parameter to HSM.
If a DIRECTORY value is present in the ENCRYPTION_WALLET_LOCATION parameter,
make sure that you do not delete it. Although HSM does not require a DIRECTORY value,
the value is used to locate your old software wallet when migrating to HSM-based
Transparent Data Encryption.
Also, the DIRECTORY value may be required by tools, such as RMAN, to locate the
software wallet.

Code
ENCRYPTION_WALLET_LOCATION=
(SOURCE=(METHOD = HSM))
The HSM vendor provides a PKCS#11 library that you must copy to a specified directory
so that the Oracle server can locate it.
Depending on the OS you are using, you copy the library to specific locations:
UNIX and
If it is for UNIX, copy it to this location.
The location is:
/opt/oracle/extapi/[32,64]/hsm/{VENDOR}/{VERSION}/libapiname.ext
Windows
If it is for Windows, copy it to this location.
The location is:
%SYSTEM_DRIVE%\oracle\extapi\[32,64]\hsm\{VENDOR}\{VERSION}\libapiname.ext
Set up HSM according to the instructions provided by your HSM vendor. Using the HSM
management interface, create a user account and password that will be used by the
Oracle server to interact with HSM.
Create a master encryption key that will be stored in HSM. This key is used to encrypt
and decrypt column encryption keys in HSM. Execute this command to create the master
encryption key.

Code
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY
user_id:password
[MIGRATE USING "<wallet_password>"]
In this example, user_id is the user ID created using the HSM management interface;
password is the password created using the HSM management interface; and
wallet_password is the password required to open an existing Oracle Wallet on the
file system.
The MIGRATE USING "<wallet_password>" clause is applicable if you are already
using TDE. Existing column encryption keys are decrypted and then re-encrypted with the
new HSM-based master encryption key. You cannot use MIGRATE USING on the TDE
Tablespace Encryption master key.

Code
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY
user_id:password
[MIGRATE USING "<wallet_password>"]
If you want to use tablespace encryption with HSM, you must reconfigure the software
wallet. The software wallet is used to access the tablespace master key. You must also
reconfigure the software wallet if you have exported encrypted data or created encrypted
backups using the software wallet.
Certain tools, such as RMAN and Oracle Data Pump, require access to the old software
wallet to perform encryption and decryption operations on data backed up or exported
using the software wallet.
You can use Oracle Wallet Manager to change the password for the software wallet to the
HSM user_id:password. If your configuration does not require that the wallet be
explicitly opened, you can use an auto login wallet.

Code
ALTER SYSTEM SET ENCRYPTION WALLET OPEN
IDENTIFIED BY "user_id:password"
To make HSM accessible to the Oracle server, execute this command.
In this command, user_Id is the user ID created using the HSM management interface
and password is the password created using the HSM management interface.

Code
ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY user_Id:password

Summary
In this topic, you've learned how TDE is set up.

Configuring Encrypted Columns

Learning Objective

After completing this topic, you should be able to

configure encrypted columns

1. Creating encrypted columns

To create an encrypted column, use the ENCRYPT keyword when the table is created or
altered.
In this example, the NO SALT keywords are used to allow an index to be created over this
column. The default is SALT.

Code
CREATE TABLE cust_payment_info
(first_name VARCHAR2(11),
last_name VARCHAR2(10),
order_number NUMBER(13),
credit_card_number VARCHAR2(20)
ENCRYPT NO SALT );
SALT is a string that is added to the data before it is encrypted so that identical values in
the column have different encrypted values. It is not possible to create an index over a
column that has SALT.

Code
SQL> connect scott/tiger
Connected.

SQL> create table cust_info_salt

2 (first_name varchar2(11),
3 last_name varchar2(10),
4 order_number number(13),
5 CREDIT_CARD_NUMBER varchar2(20) ENCRYPT);
Table created.
SQL> create index cci_salt on
cust_info_salt(CREDIT_CARD_NUMBER);
create index cci_salt on cust_info_salt(CREDIT_CARD_NUMBER)
*
ERROR at line 1:
ORA-28338: cannot encrypt indexed column(s) with salt
This is the syntax of the ENCRYPT clause.

Code
CREATE TABLE cust_payment_info
(
credit_card_number VARCHAR2(20)
ENCRYPT USING 'AES256'
[IDENTIFIED BY password]
[NO SALT] ['NOMAC']);
ENCRYPT USING 'AES256'
The ENCRYPT clause allows you to specify the encryption algorithm to use. The name of
an algorithm implicitly determines the key length.
Valid algorithm names are 3DES168, AES128, AES192 (default), and AES256.
[IDENTIFIED BY password]
The IDENTIFIED BY <password> clause is optional. Specifying a password means that
the key used to protect the table will be based on that password.
The user does not have to remember the password, but can use that same password on
another table if necessary for example, for a partitioned table that needs the same key
shared across table partitions.
['NOMAC']
In database 10.2.0.4 and 11.1.0.7 versions, the NOMAC parameter enables you to skip the
integrity check performed by Transparent Data Encryption, also known as TDE.
This saves 20 bytes of disk space per encrypted value.

Question
Identify the characteristics of the ENCRYPT clause syntax.
Options:
1.

It allows you to specify the algorithm to use

2.

The IDENTIFIED BY <password> clause is required

3.

The NOMAC parameter allows you to skip TDE integrity checks

4.

The table creator determines the key length

Answer
Option 1: This option is correct. The ENCRYPT clause allows you to specify the
encryption algorithm to use. Valid algorithm names are 3DES168, AES128,
AES192(default), and AES256.
Option 2: This option is incorrect. The IDENTIFIED BY <password> clause is
optional. Specifying a password means that the key used to protect the table will
be based on that password.
Option 3: This option is correct. In database 10.2.0.4 and 11.1.0.7 versions, the
NOMAC parameter enables you to skip the integrity check performed by TDE. This
saves 20 bytes of disk space per encrypted value.
Option 4: This option is incorrect. The name of an algorithm implicitly determines
the key length.
Correct answer(s):
1. It allows you to specify the algorithm to use
3. The NOMAC parameter allows you to skip TDE integrity checks
A B-tree index can be created on an encrypted column with NO SALT. A B-tree may not be
created on a column with SALT. Equality lookup operations are supported on the index.
A bitmapped index cannot be created on encrypted columns. TDE column encryption is
not supported on foreign keys. This is because each table has its own encryption key. For
this reason, do not use sensitive data items such as a credit card number or a national
identity number as the primary key.
Index range-scan operations are supported for equality lookups because the value is
encrypted before the comparison with stored values. WHERE clauses with BETWEENAND
or LIKE comparison operators will use full-table scans.

Tablespace-level TDE supports all index types, all internal data types, and foreign keys.

Question
What are the considerations when creating an index on an encrypted column?
Options:
1.

A B-tree index can be created on an encrypted column with NO SALT

2.

A bitmapped index can be created on encrypted columns

3.

TDE column encryption is not supported on foreign keys

4.

Index range-scan operations are not supported for equality lookups

Answer
Option 1: This option is correct. A B-tree index can be created on an encrypted
column with NO SALT. A B-tree may not be created on a column with SALT.
Option 2: This option is incorrect. A bitmapped index cannot be created on
encrypted columns.
Option 3: This option is correct. TDE column encryption is not supported on
foreign keys. This is because each table has its own encryption key.
Option 4: This option is incorrect. Index range-scan operations are supported for
equality lookups because the value is encrypted before the comparison with
stored values. WHERE clauses with BETWEENAND or LIKE comparison operators
will use full-table scans.
Correct answer(s):
1. A B-tree index can be created on an encrypted column with NO SALT
3. TDE column encryption is not supported on foreign keys

2. Altering an encrypted column

You can alter the encryption of a column. You can remove the encryption or encrypt other
columns.

Code
ALTER TABLE cust_payment_info
MODIFY credit_card_number DECRYPT

All the encrypted columns in a single table must use the same algorithm. If there are two
or more columns that are encrypted, you can change the encryption algorithm for the
entire table with one command.

Code
ALTER TABLE cust_payment_info REKEY USING 'AES256';
The SALT property can be changed if there is no index on the column. If a column is
encrypted using the ALTER TABLEMODIFYENCRYPT command, rows are updated.
Unencrypted data will remain in data blocks until the space for the original version of the
rows is reclaimed. The ALTER TABLEMOVE command will only move the current
encrypted rows to a new location.

Code
ALTER TABLE cust_payment_info
MODIFY credit_card_number ENCRYPT
USING 'AES256' SALT
TDE column encryption performs the encrypt and decrypt operations in the SQL layer, so
that the data remains encrypted in the database buffer cache, undo, and redo memory,
and the associated files.
Some Oracle Database features, most of them related to data warehouse technologies,
bypass the SQL layer for better performance when moving large amounts of data
between tables. These features are not supported with TDE column encryption.
TDE column encryption is not supported at this time when used with materialized view
logs, which keep track of changes to a master table in order to update the materialized
view. Furthermore, using TDE with synchronous Change Data Capture, abbreviated as
CDC, BFILE data type, and Transportable Tablespaces is unsupported.
TDE column encryption can be used with most scalar data types.
The data types that can be encrypted are

CHAR

DATE

INTERVAL DAY TO SECOND

INTERVAL YEAR TO MONTH

NCHAR, and

NUMBER
Other scalar data types supported by TDE column encryption are

NVARCHAR2

RAW

TIMESTAMP (includes TIMESTAMP WITH TIME ZONE and TIMESTAMP WITH LOCAL TIME ZONE)

VARCHAR2 (must be less than or equal to 3,932 bytes)

Character large objects, commonly known as CLOB (SecureFiles), and

Binary large object, also known as BLOB, (SecureFiles)

TDE column encryption supports Oracle Data Guard in the physical standby
configuration. To use TDE with Data Guard, both primary and secondary databases must
be of the same version.
You have two choices in terms of security at secondary sites:

Make a file copy of the encrypted wallet on the primary site and ship it to the secondary site. In
this case, the wallet on the secondary site needs to be opened by a DBA before the databases can
process encrypted data in case of a failover.

Use an auto-open, obfuscated wallet that you create from the encrypted wallet on the primary site
and ship it to the secondary site.
To create an obfuscated wallet from an encrypted wallet, use this command, where pwd
is the password for both wallets and wrl is the directory where the new obfuscated wallet
is to be stored.

Code
mkwallet -s pwd wrl

Note
The file name of this new obfuscated, auto-open wallet is cwallet.sso.
In both cases, each time, the master key on the primary site is changed using the ALTER
SYSTEM SET KEY command, wallets must be shipped to all secondary sites. TDE column

encryption supports the Data Guard logical standby configuration.

Logs may be mined either on the source or the target database; thus, the wallet must be
the same for both databases. Every time the master key is changed using the ALTER
SYSTEM SET ENCRYPTION KEY IDENTIFIED BY <wallet_password> command, the
wallet must be copied from the primary database to the standby database.
An error is raised if the DBA attempts to change the master key on the standby database.
If auto login wallet is not used, the wallet must be opened on the standby. Wallet open
and close commands on the primary are not replicated on the standby.
A different password can be used to open the wallet on the standby. The wallet owner can
change the password to be used for the copy of the wallet on the standby.
Storage overhead associated with TDE column encryption can be significant. When
specified, SALT requires 16 bytes. Specifying NO SALT reduces storage requirement and
saves Critical Patch Update, abbreviated as CPU, cycles.
Message Authentication Code, also known as MAC, an integrity check associated with
each encrypted value, requires an additional 20 bytes. In addition, TDE will pad out
encrypted values to a multiple of 16 bytes. So if a credit card number required 9 bytes of
storage, encrypting the credit card number would require an additional 7 bytes of storage.
Encrypting a single column in a table with SALT will require between 37 and 52 bytes of
additional storage per row.
SALT is not needed if clear text values are unique, and SALT cannot be used with
columns that will be indexed.
In database 10.2.0.4 and 11.1.0.7 versions, the NOMAC parameter enables you to skip the
integrity check performed by TDE. This saves 20 bytes of disk space per encrypted value.
If the number of rows and encrypted columns in the table is large, this adds up to a
significant amount of disk space.
The NOMAC parameter also reduces the performance overhead. The NOMAC parameter is
applied to all columns of a table. If one column uses NOMAC, they all must use the NOMAC
option.
A customer encrypting a single column using both NO SALT and NOMAC parameters can
reduce the encryption overhead to between 1 and 15 bytes per row of additional storage,
instead of 37 to 52 bytes.
TDE column encryption cannot be used with foreign keys or with index types other than
B-tree indexes. SYS schema objects cannot be encrypted.
In Oracle Database 11g, internal large object, also referred to as LOB, data types (such

as BLOB and CLOB) can be encrypted, but external LOBs (such as binary large file
objects [BFILE data type]) cannot be encrypted.
Applications that need to use these unsupported features can use the TDE tablespace
encryption. TDE tablespace encryption supports all data types, except external table and
BFILE. The SYSTEM tablespace cannot be encrypted.

Note
External tables can have encrypted columns using the ORACLE_DATAPUMP
access driver.

3. Creating an encrypted tablespace

TDE tablespace encryption is performed at the I/O level on a per-block basis. The only
encryption penalty is associated with I/O, so the performance overhead will be seen in the
I/O statistics.
When there are a large number of columns in a table to be encrypted, tablespace
encryption may provide better performance than column encryption. SQL access paths
are unchanged and all data types are supported. Because the data is not encrypted in
memory, there is no difference in the handling of data when it is read off the disk.
All data types, index types, and even LOBs, are supported with tablespace encryption.
Data retrieved from encrypted tablespaces is protected whenever it is written to disk,
including temporary tablespaces, undo tablespace, and redo logs.
During operations such as JOIN and SORT, data that is selected from an encrypted
tablespace is encrypted when written to temporary tablespaces. Encrypted tablespaces
are transportable if the platforms have the same endianess and the same wallet.
There is currently no mechanism to rekey a tablespace. Tablespace encryption does not
require additional storage space.
The CREATE TABLESPACE command has an ENCRYPTION clause that sets the
encryption properties, and an ENCRYPT storage parameter that causes the encryption to
be used.
You specify USING 'encrypt_algorithm' to indicate the name of the algorithm to be
used. You can view the properties in the V$ENCRYPTED_TABLESPACES view.

Code

ALTER SYSTEM SET ENCRYPTION KEY

IDENTIFIED BY "<password>";
CREATE TABLESPACE encrypt_ts
DATAFILE '$ORACLE_HOME/dbs/encrypt.dat' SIZE 100M
ENCRYPTION USING '3DES168'
DEFAULT STORAGE (ENCRYPT);
Because tablespace encryption is performed at the I/O level, many of the restrictions that
apply to TDE column encryption do not apply to tablespace encryption.
The following restrictions apply to tablespace encryption:

Temporary and undo tablespaces cannot be encrypted. But when a data buffer containing data
from an encrypted tablespace is written to an undo or a temporary tablespace, that data block is
encrypted.

The BFILE data type and external tables are not encrypted because they are not stored in
tablespaces.

Transportable tablespaces across different endian platforms are not supported.

The key for encrypted tablespaces cannot be changed. A workaround is to create a tablespace
with the desired properties and move all objects to the new tablespace.
The previous version of the export and import utilities, exp and imp, did not support TDE.
An error message is raised when exp attempts to export a table with an encrypted
column.

Code
"EXP-00107: Feature (COLUMN ENCRYPTION) of column
ORDER_NUMBER in table <table_name> is not supported. The
table will not be exported."
The Data Pump Export utility, expdp, can export the table. By default, the data is stored
in the dump file in clear text. You can provide secure storage for the dump file by using
the ENCRYPTION_PASSWORD parameter of the expdp command.

Code
$ expdp system/oracle directory=DP_DIR dumpfile=tde.dmp
tables=(SCOTT.CUST_PAYMENT_INFO)
encryption_password="<password>"

Note
The same password must be used to import the dump file using the Data Pump
Import, impdp.
Oracle Database 11g introduces SecureFiles implementation (of LOBs), which offers
intelligent compression and transparent encryption. Encrypted data in SecureFiles is
stored in place and is available for random reads and writes.
The encryption takes place at the block level. LOB implementation from earlier versions is
still supported for backward compatibility and is now referred to as BasicFiles.

Code
CREATE TABLE test1
(doc CLOB ENCRYPT USING 'AES128')
LOB(doc) STORE AS SECUREFILE (CACHE NOLOGGING)
If you add a LOB column to a table, you can specify how it should be created using
SECUREFILE or BASICFILE keywords. To ensure backward compatibility, the default
LOB type is BASICFILE.
To enable encryption of LOBs, you must create the LOB with the SECUREFILE keyword,
with encryption enabled (ENCRYPT) or disabled (DECRYPT, which is the default) on the
LOB column. The current TDE syntax is used for extending encryption to LOB data types.
There are multiple correct syntax possibilities.
Valid encryption algorithms are 3DES168, AES128, AES192, and AES256. The default is
AES192.

Code
CREATE TABLE test1
(doc CLOB ENCRYPT USING 'AES128')
LOB(doc) STORE AS SECUREFILE (CACHE NOLOGGING)

Summary
In this topic, you've learned how to configure encrypted columns.

Implementing TDE
Learning Objective

After completing this topic, you should be able to

implement Transparent Data Encryption

Exercise overview
You want to create a table that contains an encrypted column and view the data in the
format that is stored on disk before and after encryption. You also want to create an
encrypted tablespace and move several tables and the associated indexes to it.
In this exercise, you're required to prepare the database for encryption, encrypt a column
containing credit card information, move a table to cause valid data to be written to new
blocks, move schema objects to an encrypted tablespace, and test transparent
encryption.
This involves the following tasks:

preparing for encryption

encrypting a column

moving a table

moving schema objects

verifying transparent encryption

Task 1: Preparing for encryption

You have prepared the database and now want to implement Transparent Data
Encryption. Open the wallet and create the master encryption key using an ALTER
SYSTEM statement and a password of "welcome1." Then execute the lab_18_01_04.sql
script to create a table in the OE schema that holds sensitive customer payment
information. Use the @ command a specify a password of "oracle" for the OE user. View
all of the information in the OE.CUST_PAYMENT_INFO table. Execute the
lab_18_01_06.sql script to find the database address of the table. Connect as the
SYSDBA and set the tracefile identifier for the session to "LAB186." Dump the database
block to a trace file using the file# and block# retrieved previously. Then view the value of
the USER_DUMP_DEST parameter.

Steps list
Instructions
1. Type ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "welcome1"; and press Enter
2. Type @lab_18_01_04.sql and press Enter
3. Type oracle and press Enter

Steps list
Instructions
4. Type SELECT * FROM oe.cust_payment_info; and press Enter
5. Type @lab_18_01_06.sql and press Enter
6. Type CONNECT / as sysdba and press Enter
7. Type ALTER SESSION SET TRACEFILE_IDENTIFIER = LAB186; and press Enter
8. Type ALTER SYSTEM DUMP DATAFILE 4 BLOCK 413; and press Enter
9. Type SHOW PARAMETER user_dump_dest and press Enter

Task 2: Encrypting a column

List all files in the current directory containing LAB186 using the ls *LAB186*
command. Then use the less command followed by the filename to view the trace file.
After viewing that credit card numbers are visible, type q to exit less. Launch SQL*Plus
with the /nolog option and connect as the OE user with a password of "oracle." View the
column information for the CUST_PAYMENT_INFO table. Then modify the table to
encrypt the CREDIT_CARD_NUMBER column with NO SALT.

Steps list
Instructions
1. Type ls *LAB186* and press Enter
2. Type less orcl2_ora_17562_LAB186.trc and press Enter
3. Type q and press Enter
4. Type sqlplus /nolog and press Enter
5. Type CONNECT oe and press Enter
6. Type oracle and press Enter
7. Type DESC cust_payment_info and press Enter
8. Type ALTER TABLE cust_payment_info and press Enter
9. Type MODIFY (CREDIT_CARD_NUMBER encrypt no salt); and press Enter

Task 3: Moving a table

You have dumped the data block and found the trace file. In the trace file, the column is
encrypted by an update operation and the rows are rewritten in the block. There are two
entries for each row and the unencrypted form remains. You want to move the
OE.CUST_PAYMENT_INFO table as this causes the valid data to be written to new
blocks. Connect as the OE user with a password of "oracle." Move the

OE.CUST_PAYMENT_INFO table. Then view the INDEX_NAME, TABLE_NAME, and

STATUS columns of the USER_INDEXES table for this table. Include the FROM and
where clauses on separate lines. Then rebuild the unusable index.

Steps list
Instructions
1. Type CONNECT oe and press Enter
2. Type oracle and press Enter
3. Type ALTER TABLE oe.cust_payment_info MOVE; and press Enter
4. Type SELECT index_name, table_name, status and press Enter
5. Type FROM user_indexes and press Enter
6. Type WHERE table_name = 'CUST_PAYMENT_INFO'; and press Enter
7. Type ALTER INDEX CUST_PAYMENT_INFO_IDX REBUILD; and press Enter

Task 4: Moving schema objects

You have created an encrypted tablespace named ENCTBS with a file enctbs01.dbf. You
now want to move the HR schema to this new tablespace. Add the HR schema to the list
of schema objects to be reorganized using the search functionality. Select all of the
objects in the HR schema using the Select All and Next links. Then set the attributes by
type. For both tables and indexes, relocate objects to the ENCTBS tablespace. Accept all
other default selections to complete the configuration, and then view the job details.

Steps list
Instructions
1. Ensure Schema Objects is selected and click Next
2. Click Add
3. Type HR in the Schema text box and click Search
4. Click the Select All link and then click the Next 10 link
5. Click the Select All link and then click the Next 5 link
6. Click the Select All link and then click OK
7. Click Set Attributes By Type
8. In the Destination Tablespace for Tables, Table Partitions and Table Subpartitions section, select the Relocate
objects to another tablespace radio button and type ENCTBS in the associated text box
9. In the Destination Tablespace for Indexes, Index Partitions and Index Subpartitions section, select the Relocate
objects to another tablespace radio button, type ENCTBS in the associated text box, and click OK
10. Click Next on the Reorganize Objects: Objects, Reorganize Objects: Options, Reorganize Objects: Impact
Report, and Reorganize Objects: Schedule pages

Steps list
Instructions
11. Click Submit Job
12. Click View Job Details

Task 5: Verifying transparent encryption

You now want to ensure the encrypted tablespace, including the indexes, is completely
transparent to applications. Launch SQL*Plus connecting as the HR user. Specify a
password of "oracle_1" when prompted. Describe the EMPLOYEES table. Then view all
of the information in the EMPLOYEES table for the employee_id 106. Include the FROM
and WHERE clauses on separate lines.

Steps list
Instructions
1. Type sqlplus hr and press Enter
2. Type oracle_1 and press Enter
3. Type DESC employees and press Enter
4. Type SELECT * and press Enter
5. Type FROM employees and press Enter
6. Type WHERE employee_id = 106; and press Enter

Applying File Encryption

Learning Objective

After completing this topic, you should be able to

identify ways to apply file encryption

1. RMAN-encrypted backups
Recovery Manager, commonly known as RMAN, can create encrypted backups to either
tape or disk, as long as the required key management infrastructure is available.
RMAN encryption can use either a password-based key or a generated key held in
Oracle Wallet. The data is encrypted by RMAN before it is transmitted to the disk or tape
storage device, and no further encryption is performed.

RMAN backup encryption is available only in the Enterprise Edition of the database, and
the COMPATIBLE parameter must be set to 10.2.0 or higher.
Encrypted backup to disk does not require Oracle Advanced Security, commonly known
as ASO, but the use of RMAN with a third-party media manager library does require ASO
to provide the key infrastructure.
Encrypted backups to tape require Oracle Secure Backup, also referred to as OSB, to
provide the key infrastructure. OSB includes the same technology as ASO.
OSB version 10.2 is available in both Standard Edition and Enterprise Edition of Oracle
Database 11g. OSB includes the secure communications technology of ASO in the
Enterprise Edition to provide secure communication between hosts (administrative,
source, and target) in the OSB domain.
OSB encrypts the transmitted data and control messages with a default key of 1,024 bits
generated for each session using secure sockets layer, also known as SSL.
OSB provides this key from an embedded wallet that is separate from Oracle Wallet used
by RMAN to encrypt backups.
If RMAN encryption is provided, OSB does not encrypt the data again for transmission.
But if RMAN encryption is disabled, and the OSB host encryption policy is set to required,
the OSB encryption will be used for the data; if the OSB encryption policy is set to
allowed, in principal, the decision is referred to the next lower level.
You can modify the default security configuration in the following ways:

disable SSL for interhost authentication and communication by setting the securecomms security
policy in OSB
transmit identity certificates in manual certificate provisioning mode

set the key size for a host to a value from 512 to 4,096 bits, rather than the default of 1,024 bits,
and

disable encryption for backup data in transit by setting the encryptdataintransit security
policy
Because OSB-embedded wallets are used only for interdomain communication, they do
not have any direct relationship to the backup data written to tape. Therefore, if wallets
are destroyed and re-created, it does not affect the restoration of data from tape.
OSB does not share its wallets with other Oracle products. Besides maintaining its
password-protected wallet, each host in the domain maintains an obfuscated wallet. This

version of the wallet does not require a password.

The obfuscated wallet is created when the wallet is opened and destroyed when the
wallet is closed. This wallet, which is scrambled but not encrypted, enables the OSB
software to run without requiring a password during system startup.
The password for the password-protected wallet is generated by OSB and not made
available to the user. The password-protected wallet is not normally used after the
security credentials for the host have been established because the OSB daemons use
the obfuscated wallet.
To reduce the risk of unauthorized access to obfuscated wallets, OSB does not back
them up.
The obfuscated version of a wallet is named cwallet.sso. By default, the wallet is
located in this path on Linux and UNIX, and on Windows, it is located in this path.

Graphic
On Linux and UNIX, the wallet is located in the following path:
/usr/etc/ob/wallet
On Windows, the wallet is located in the following path:
C:\Program Files\Oracle\Backup\db\wallet

Note
As a best practice, back up the OSB-encrypted wallet, but do not back up the
obfuscated wallet.
OSB leverages RMAN backup encryption technology:

Encryption keys being transparently managed by the database.

Your ability to choose backup encryption at the database or tablespace level. (This is in addition
to Transparent Data Encryption, abbreviated as TDE, which you can use inside Oracle Database.)
Substantial protection through encryption algorithms up to 256-bit AES.
During transportation over the network, database backups are secured with RMAN
encryption (in which case, no additional SSL is used).
If your database backups are not encrypted by RMAN, OSB uses SSL by default. It also

secures your file-system backups over the network by using SSL.

RMAN can create encrypted backups on tape using OSB or a third-party media manager
with ASO.

2. Creating RMAN-encrypted backups

For improved security, Recovery Manager, commonly known as RMAN, backups created
as backup sets can be encrypted. Image copy backups cannot be encrypted.
Encrypted backups are decrypted automatically during restore and recover operations, as
long as the required decryption keys are available, by means of either a user-supplied
password or Oracle Encryption Wallet.
RMAN supports three encryption modes:

transparent

password, and

dual
Transparent encryption does not require DBA intervention as long as the required Oracle
key management infrastructure is available.
Transparent encryption is best suited for day-to-day backup operations, where backups
will be restored on the same database that they were backed up from.
Transparent encryption is the default encryption mode. You must first configure Oracle
Encryption Wallet to use transparent encryption.
To use transparent mode encryption, perform the following steps:

Code
ENCRYPTION_WALLET_LOCATION=
(SOURCE=(METHOD=FILE)(METHOD_DATA=
(DIRECTORY=/opt/oracle/product/10.2.0/db_1/)))
ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED
BY <password>;
ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY
<password>;

RMAN> CONFIGURE ENCRYPTION FOR DATABASE ON

RMAN> CONFIGURE ENCRYPTION FOR TABLESPACE
<tablespace_name> ON
RMAN> SET ENCRYPTION ALGORITHM 'algorithm name'
create a wallet
The first step is to create a wallet using Oracle Wallet Manager. By default, an unencrypted
wallet (cwallet.sso) is created when Oracle Database is installed. An encrypted wallet
(ewallet.p12) is recommended for use with backup set encryption. Place an entry in the
SQLNET.ORA file.
open the wallet
Before you can use backup set encryption, you need to make sure that the wallet is
opened by your instance. The password specified with the ALTER SYSTEM command is the
same password you specified when you created the wallet.
set the master key
When the wallet is opened, you need to set the master key from within your instance.
configure the RMAN encryption level, and
The CONFIGURE ENCRYPTION command is used to specify encryption settings for the
database or tablespaces within the database, which apply unless overridden using the SET
command.
Options specified for an individual tablespace take precedence over options specified for
the whole database.
set an encryption algorithm, if needed
Query V$RMAN_ENCRYPTION_ALGORITHMS to obtain a list of encryption algorithms
supported by RMAN. The default encryption algorithm is 128-bit AES.
When you use password encryption, you must provide a password to create and restore
encrypted backups. When you restore the password-encrypted backup, you must supply
the same password that was used to create the backup.
Password encryption is most appropriate for backups that will be restored at remote
locations, but which must remain secure in transit. To enable password encryption, use
this command in your RMAN scripts.

Code
SET ENCRYPTION ON IDENTIFIED BY <password> ONLY
Password encryption cannot be persistently configured. The Enterprise Manager interface
will place the proper command in the RMAN backup scripts that it generates.

Graphic
The Encryption section of the Enterprise Manager interface is open. You use this
section to encrypt the backup using the Oracle Encryption Wallet, a user-supplied
password, or both, to protect sensitive data. The section includes the Secure the
backup using Recovery Manager encryption checkbox, which is selected, and the
Encryption Algorithm drop-down list, in which AES128 is selected.
The Encryption Mode subsection contains two checkboxes: Backups will be
encrypted using the Oracle Encryption Wallet and Backups will be encrypted using
the following password, which is currently selected. This section also contains the
Password and Confirm Password fields. Both fields are filled.

Note
For security reasons, it is not possible to permanently modify your existing backup
environment so that RMAN backups are encrypted using password mode. You
can enable password-encrypted backups only for the duration of an RMAN
session.
Dual-mode encrypted backups can be restored transparently or by specifying a
password.
Dual-mode encrypted backups are useful when you create backups that are normally
restored using Oracle Encryption Wallet, but which occasionally need to be restored
where Oracle Encryption Wallet is not available.

Graphic
In the Encryption Mode subsection, in this example, the Backups will be encrypted
using the Oracle Encryption Wallet and Backups will be encrypted using the
following password checkboxes are selected.
To create dual-mode encrypted backup sets, specify this command in your RMAN scripts.

Code
SET ENCRYPTION ON IDENTIFIED BY 'password'
Use the SET DECRYPTION command to specify one or more decryption passwords to be
used when reading dual-mode or password-encrypted backups.
When RMAN reads encrypted backup pieces, it tries each password in the list until it finds
the correct one to decrypt that backup piece. An error is signaled if none of the specified

keys are correct. If you lose the password for a password-encrypted backup, you cannot
restore that backup.

Code
SET DECRYPTION IDENTIFIED BY '<password_1>'
{, '<password_2>',,'<password_n>' }
Because the Oracle key management infrastructure archives all previous master keys in
the wallet, changing or resetting the current database master key does not affect your
ability to restore encrypted backups performed using an older master key.
You may reset the database master key at any time, but RMAN will always be able to
restore all encrypted backups that were ever created by this database.
If you lose the wallet containing the key for a transparent encrypted backup, you cannot
restore that backup. Because the wallet contains all past backup encryption keys, a
restored wallet can be used to restore past encrypted backups up to the backup time of
the wallet. Encrypted backups made after the wallet backup will be lost.

Note
As a best practice, back up Oracle Wallet frequently.

Question
What are the characteristics of restoring encrypted backups?
Options:
1.

The SET DECRYPTION command is used to specify decryption passwords

2.

If you lose the password for a password-encrypted backup, you must recover the
backup

3.

Resetting the current database master key affects your ability to restore encrypted
backups

4.

When RMAN reads encrypted backup pieces, it tries each password in the list until it
finds the correct one

Answer
Option 1: This option is correct. Use the SET DECRYPTION command to specify
one or more decryption passwords to be used when reading dual-mode or
password-encrypted backups.

Option 2: This option is incorrect. If you lose the password for a passwordencrypted backup, you cannot restore that backup. Also, if you lose the wallet
containing the key for a transparent encrypted backup, you cannot restore that
backup.
Option 3: This option is incorrect. Because the Oracle key management
infrastructure archives all previous master keys in the wallet, changing or resetting
the current database master key does not affect your ability to restore encrypted
backups performed using an older master key.
Option 4: This option is correct. When RMAN reads encrypted backup pieces, it
tries each password in the list until it finds the correct one to decrypt that backup
piece. An error is signaled if none of the specified keys are correct.
Correct answer(s):
1. The SET DECRYPTION command is used to specify decryption passwords
4. When RMAN reads encrypted backup pieces, it tries each password in the list
until it finds the correct one
There are certain considerations for RMAN-encrypted backups.
Any RMAN backups created as backup sets can be encrypted. However, image copy
backups cannot be encrypted.
The V$RMAN_ENCRYPTION_ALGORITHMS view contains a list of encryption algorithms
supported by RMAN. If no encryption algorithm is specified, the default encryption
algorithm is 128-bit AES. You can change the algorithm by using these commands.

Code
RMAN> CONFIGURE ENCRYPTION ALGORITHM 'algorithmname'
RMAN> SET ENCRYPTION ALGORITHM 'algorithmname'
Oracle Database uses a new encryption key for every encrypted backup. The backup
encryption key is then encrypted with either the password or the database master key, or
both, depending on the chosen encryption mode. Individual backup encryption keys or
passwords are never stored in clear text.
Encryption can have a negative effect on disk backup performance. Because encrypted
backups use more CPU resources than non-encrypted backups, you can improve the
performance of encrypted backups to disks by using more RMAN channels.
You can change the master key any time without affecting your transparent encrypted
backups.

3. Data Pump encryption

Every file that could contain sensitive data should be protected in some way; the dump
file produced by Data Pump Export is no exception. In Oracle Database 11g, Data Pump
Export can encrypt the dump file.
Data Pump file encryption requires that Oracle Advanced Security, commonly known as
ASO, be installed. The expdp process receives the data unencrypted from the database,
even if the data is encrypted in the database with Transparent Data Encryption,
abbreviated as TDE.

Note
The exp process cannot decrypt data that has been encrypted with application
encryption, such as DBMS_CRYPTO procedures.
Data may be exported across network connections. If the expdp process connects to the
database using a service name, the data may be encrypted if ASO network encryption is
specified between the client (where expdp is executing) and the server.
The expdp process may also connect using a database link specified with the
NETWORK_LINK parameter. The data will be sent across this link in clear text unless the
database link has been configured to use network encryption.
The ENCRYPTION parameter determines the scope of the encryption that is, which data
elements are encrypted. The ENCRYPTION_MODE parameter determines the type of
encryption used that is, the type of key used. The ENCRYPTION_PASSWORD interacts
with both the other parameters.

Graphic
An example of a service name is hr/****@HR_DB.

Question
Identify the features of Data Pump encryption.
Options:
1.

It requires that ASO be installed

2.

The ENCRYPTION_MODE parameter determines the scope of the encryption

3.

The expdp process receives the data unencrypted from the database

4.

Data cannot be exported across network connections

Answer
Option 1: This option is correct. In Oracle Database 11g, Data Pump Export can
encrypt the dump file. Data Pump file encryption requires that ASO be installed.
Option 2: This option is incorrect. The ENCRYPTION parameter determines the
scope of the encryption, and the ENCRYPTION_MODE parameter determines the
type of encryption used.
Option 3: This option is correct. The expdp process receives the data
unencrypted from the database, even if the data is encrypted in the database with
TDE.
Option 4: This option is incorrect. Data may be exported across network
connections. If the expdp process connects to the database using a service
name, such as hr/****@HR_DB, the data may be encrypted if ASO network
encryption is specified between the client and the server.
Correct answer(s):
1. It requires that ASO be installed
3. The expdp process receives the data unencrypted from the database
The ENCRYPTION parameter determines which elements of the dump file are encrypted.
The various settings are
ENCRYPTED_COLUMNS_ONLY
The ENCRYPTED_COLUMNS_ONLY setting causes only columns that have been declared
encrypted in the database to be encrypted in the dump file; all other data is in clear text.
DATA_ONLY
The DATA_ONLY setting causes all the data in the dump file to be encrypted, but not the
metadata such as the data definition language, also known as DDL, required to re-create
the objects.
METADATA_ONLY
The METADATA_ONLY setting encrypts the metadata but not the data.
ALL, and
The ALL setting causes the entire dump file to be encrypted. If the data being exported
includes SecureFiles, you must use the ALL setting to get encryption security for these
objects.
NONE

The NONE setting is the default. If ENCRYPTION_PASSWORD is set and ENCRYPTION is not
set, ENCRYPTION defaults to ALL.
The ENCRYPTION_PASSWORD parameter may be used by itself in the command line or
the parameter file. ENCRYPTION_PASSWORD specifies a key for re-encrypting encrypted
table columns so that they are not written as clear text in the dump file set.
If the export operation involves encrypted table columns, but an encryption password is
not supplied, the encrypted columns will be written to the dump file set as clear text, and
a warning will be issued.
There is no connection or dependency between the key specified with the Data Pump
ENCRYPTION_PASSWORD parameter and the key specified with the ENCRYPT keyword
when the table with encrypted columns was initially created. For example, suppose a
table is created with an encrypted column whose key is e3r.

Code
CREATE TABLE emp (salary NUMBER(8,2) ENCRYPT IDENTIFIED BY
"e3r");
When you export the EMP table, you can supply any arbitrary value for
ENCRYPTION_PASSWORD. It does not have to be e3r. Passwords should never be used
in a command line.
As a best practice, you should place the ENCRYPTION_PASSWORD parameter in a
parameter file.
For network exports, the ENCRYPTION_PASSWORD parameter is not supported with userdefined external tables that have encrypted columns. The table will be skipped and an
error message will be displayed, but the job will continue.

Code
CREATE TABLE emp (salary NUMBER(8,2) ENCRYPT IDENTIFIED BY
"e3r");

Question
Which statements most accurately describe the ENCRYPTION_PASSWORD
parameter?
Options:

1.

It may be used by itself in the command line

2.

It specifies a key for re-encrypting encrypted table columns

3.

It is supported with user-defined external tables that have encrypted columns

4.

There is a dependency between the key specified with this parameter and the key
specified with the ENCRYPT keyword at table creation

Answer
Option 1: This option is correct. The ENCRYPTION_PASSWORD parameter may be
used by itself in the command line or the parameter file.
Option 2: This option is correct. ENCRYPTION_PASSWORD specifies a key for reencrypting encrypted table columns so that they are not written as clear text in the
dump file set.
Option 3: This option is incorrect. For network exports, the
ENCRYPTION_PASSWORD parameter is not supported with user-defined external
tables that have encrypted columns.
Option 4: This option is incorrect. There is no connection or dependency between
the key specified with the Data Pump ENCRYPTION_PASSWORD parameter and
the key specified with the ENCRYPT keyword when the table with encrypted
columns was initially created.
Correct answer(s):
1. It may be used by itself in the command line
2. It specifies a key for re-encrypting encrypted table columns
The ENCRYPTION_MODE parameter sets the method of obtaining the key for encrypting
the dump file. The ENCRYPTION or ENCRYPTION_PASSWORD parameter must also be set
when specifying the ENCRYPTION_MODE parameter.
If the encryption wallet is configured and TRANSPARENT is specified, the dump file is
encrypted with no intervention by the DBA required. The ENCRYPTION_PASSWORD
parameter is not needed, and the expdp process will return an error if
ENCRYPTION_PASSWORD is specified.
A dump file exported in transparent mode may be imported transparently if the encryption
wallet is available. These dump files should be imported to the same database that they
exported from.
When PASSWORD mode is specified, the password is not stored, but must be specified on
import. Dump files created in password mode are best suited for cases where the file will
be imported offsite where the encryption wallet is not available.

ENCRYPTION_PASSWORD must be specified when using this mode. To import the dump
file, the same password must be specified, and the target table must have the same
encryption attributes as the source table (the same columns must be declared as
ENCRYPT or NO ENCRYPT).
Dual mode allows the dump file to be imported transparently where the encryption wallet
is available, or with a password where the wallet is not available.
TDE allows you to protect your database data files and image backups by encrypting the
data of sensitive columns.
Data Pump Export allows you to export that data into a dump file or an external table that
is created in XML format. By default, the data in the dump file is in clear text. In the
example, you can encrypt only the data, or you can encrypt the entire dump file. This
example uses transparent mode.

Code
expdp hr TABLES=employees
DIRECTORY=data_pump_dir DUMPFILE=hr_emp.dmp
ENCRYPTION_MODE=TRANSPARENT
ENCRYPTION=DATA_ONLY
When you want to encrypt in the dump file, only the columns that are encrypted in the
database, use ENCRYPTION=ENCRYPTED_COLUMNS_ONLY. ENCRYPTION_PASSWORD
must be specified. Therefore, ENCRYPTION_MODE must be PASSWORD.
This example uses password mode to generate the key. It also uses the encryption
password on the command line. Passwords should never be placed on the command
line. Use PARFILE with expdp or impdp to specify ENCRYPTION_PASSWORD.

Code
expdp oe TABLES=cust_payment_info
DIRECTORY=data_pump_dir DUMPFILE=cust_pay.dmp
ENCRYPTION_MODE=PASSWORD
ENCRYPTION=ALL
ENCRYPTION_PASSWORD=g&t1L47#

Summary
In this topic, you've learned how to apply file encryption.

Using RMAN Backup File Encryption

Learning Objective

After completing this topic, you should be able to

create and recover backups

Exercise overview
You want to configure Recovery Manager (RMAN) to use various types of encryption.
In this exercise, you're required to encrypt, create, and configure backups, and restore a
tablespace.
This involves the following tasks:

encrypting backups

creating a backup

configuring backups

restoring with encryption

Task 1: Encrypting backups

You want to configure RMAN to use transparent encryption. Display all of the currently
enabled CONFIGURE commands. Then modify your existing backup environment to that
all RMAN backups are encrypted using the CONFIGURE ENCRYPTION FOR
DATABASE ON; command. Exit RMAN and create the $HOME/backup directory.

Steps list
Instructions
1. Type show all; and press Enter
2. Type CONFIGURE ENCRYPTION FOR DATABASE ON; and press Enter
3. Type exit and press Enter
4. Type mkdir $HOME/backup and press Enter

Task 2: Creating a backup

You have shut down the database and issued STARTUP MOUNT to perform a cold
backup. You now want to use the RMAN backup command to make a backup of the

EXAMPLE tablespace to /home/oracle/backup/example001.bck. Set tag =

transparent so that it can be specified in the restore command. Include the format and
tag clauses on separate lines.

Steps list
Instructions
1. Type backup tablespace example and press Enter
2. Type format '/home/oracle/backup/example001.bck' and press Enter
3. Type tag 'transparent'; and press Enter

Task 3: Configuring backups

Open the wallet using SQL followed by the ALTER SYSTEM command in single quotes.
Specify a password of "welcome1." Then perform a backup of the EXAMPLE tablespace
to /home/oracle/backup/example001.bck again with a transparent tag. Set the encryption
mode to on with a password of "oracle1." Then make another backup of the EXAMPLE
tablespace to /home/oracle/backup/example002.bck with a tag of dual. Include all format
and tag clauses on separate lines.

Steps list
Instructions
1. Type SQL 'ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "welcome1"'; and press
Enter
2. Type backup tablespace example and press Enter
3. Type format '/home/oracle/backup/example001.bck' and press Enter
4. Type tag 'transparent'; and press Enter
5. Type SET ENCRYPTION ON IDENTIFIED BY "oracle1"; and press Enter
6. Type backup tablespace example and press Enter
7. Type format '/home/oracle/backup/example002.bck' and press Enter
8. Type tag 'dual'; and press Enter

Task 4: Restoring with encryption

You have backed up the EXAMPLE tablespace to example003.bck with a tag of
password. You have also shut down and mounted the database and remote the
example01.dbf file. Attempt to restore the EXAMPLE tablespace using the backup made
with transparent encryption. Then set decryption to use the password "password1" and
restore the EXAMPLE tablespace using password encryption.

Steps list
Instructions
1. Type RESTORE TABLESPACE example FROM TAG transparent; and press Enter
2. Type SET DECRYPTION IDENTIFIED BY "password1"; and press Enter
3. Type RESTORE TABLESPACE example FROM TAG "password"; and press Enter