Applied Oracle Security: Developing Secure Database and Middleware Environments- P8 doc

44 Part I: Oracle Database Security New Features
TDE Caveats
Column-level TDE encrypts and decrypts data at the SQL level, making it transparent to the end
user. As a result, several database features that access data at the kernel level are incompatible
with column-level TDE. Using change data capture (both synchronous and asynchronous),
streams (in 10g), materialized views, transportable tablespaces, and LOBs are not possible if
they include objects containing encrypted columns. These limitations disappear with tablespace
encryption available in 11g, as you will see in the next section.
Another potential drawback in TDE’s column-based encryption is that it cannot be used in
certain types of indexes or in the definition of a primary key/foreign key (PK/FK) relationship.
Indexes built on encrypted columns are created using the encrypted values stored in the column.
As a result, use of an index is possible for an equality match provided that the encryption was
defined using the “no salt” option. The index will not be used, however, in queries that do a range
scan. In fact, you will not be allowed to create an index on a column encrypted with the salt
directive (failing with ORA-28338: cannot encrypt indexed column[s] with salt).
In the case of PK/FK relationships, since each table is encrypted using its own table-level key,
the keys are different among tables and, therefore, the encrypted values for similar strings are
different. In this process, the relationship that existed between the data is lost without first decrypting
the column.
While many will argue that natural keys (those that are managed outside of the application,
such as SSNs, employee IDs, or stock numbers) are not good candidates as primary keys for
establishing uniqueness in a table, the fact is they are and have been used as primary keys
and are often found in applications that have, over time, been ported from other database
environments. As such, dealing with PK/FK relationships in application that require the
protection offered by TDE presents a special problem with column-level TDE. This limitation
is addressed in version 11g with the introduction of a new capability: tablespace encryption.
Tablespace Encryption: New with Oracle 11g
It is obvious that some very real business problems are satisfied by 10g’s column-level encryption
capability. In a separate subset of use cases, column-level encryptions limitations make it more
challenging to encrypt individual data elements to achieve the desired outcome and balance of
security and performance.

For instance, many times you might find that an existing application was built to use the most
sensitive information as a primary key. Packaged applications often present this problem, and you
have little control and limited in-depth knowledge of their data relationships. In such cases, when
faced with the challenges of the PCI-DSS or with new privacy legislation such as California’s SB
1386 all organizations’ healthcare providers must make substantial investments in cataloging,
analyzing, and remedying potential leaks for personal health information (PHI) or personally
identifiable information (PII).
Consider an insurance company’s claims system. Applications use the employee’s SSN as
the primary key for the insured record. It stands to reason that they would use the insured’s SSN
as part of the dependant’s record foreign key. As application developers and data architects
Chapter 2: Transparent Data Encryption 45
become more security conscious, this situation becomes far less likely, but it still happens. To
remedy this in 10g would have required a redevelopment effort to create a new, noncanonical,
primary key.
Using the tablespace encryption feature of 11g, it is possible to move all data considered to be
PHI or PII into an encrypted tablespace without needing to redesign the application. Additionally,
features such as streams and change data capture are again available when dealing with an
encrypted tablespace, making it a good candidate for use in a wider variety of applications than
column-level encryption.
Once the tablespace in created, anything stored in it will be encrypted using the algorithm
specified at definition time:
system@AOS> CREATE TABLESPACE ts_encrypted
2 DATAFILE '/home/oracle/product/11.1.0/oradata/aos/TSE_encrypted.dbf' size 400K
3 AUTOEXTEND ON
4 ENCRYPTION USING 'AES192'
5* DEFAULT STORAGE(ENCRYPT)
system@AOS> /
Tablespace created.
The tablespace TS_ENCRYPTED is then created using the 192-bit AES algorithm. This is
confirmed with a look at the v$encrypted_tablespaces view:

system@AOS> SELECT TS.name, ET.encryptedts, ET.encryptionalg
2 FROM v$tablespace TS, v$encrypted_tablespaces ET
3 WHERE
4 TS.ts# = ET.ts#;
NAME ENC ENCRYPT

TS_ENCRYPTED YES AES192
system@AOS>
Oracle 11g Configuration
In addition to tablespace encryption to protect entire collections of tables and their indexes, other
enhancements have been included in Oracle Database 11g. Support for TDE has been built into
Enterprise Manager’s database control graphical user interface (GUI), shown in Figure 2-8.
The management of the wallet is now presented with a more intuitive GUI (a bit more
intuitive than the SQLPLUS prompt). This allows for creating, opening, closing, and regenerating
the TDE Master Key. The option for both closing the wallet and regenerating the Master Key are
found under Advanced Options and appear as shown in Figure 2-9.
While the ability to create, open, and close a wallet are still available at the SQLPLUS
prompt, you can now accomplish this without ever leaving the database management console.
46 Part I: Oracle Database Security New Features
FIGURE 2-8 Enterprise Manager database control
FIGURE 2-9 Closing and rekeying the wallet under Advanced Options
Chapter 2: Transparent Data Encryption 47
TDE to Address PCI-DSS
In an effort to thwart the theft and misuse of credit card information (card numbers, cardholder
name, and expiration date), major credit card companies have agreed on a set of standards to
govern the storage and management of credit card data. The PCI-DSS comprises six control
objectives, sets of related requirements. The industry standard is an evolution of the initial
Cardholder Information Security Program (CISP) developed by Visa in 2001 to protect cardholder
data, wherever it resides. MasterCard’s Site Data Protection Program (SDP) was announced in the
spring of 2001 to “assist online merchants in defending against Internet hackers.”

PCI requires merchants and member service providers (MSPs) who process, store, or transmit
cardholder information to adhere to the following control objectives:
Build and maintain a secure IT network.
Protect cardholder data.
Maintain a vulnerability management program.
Implement strong access control measures.
Regularly monitor and test networks.
Maintain an information security policy.
If you use a credit card in your day-to-day business, you are already familiar with the primary
data elements involved in the DSS:
Primary account number (PAN)
Cardholder’s name
Service code (a three- or four-digit number on the magnetic stripe that specifies the
acceptance requirements and limitations for magnetic-stripe read transactions)
Expiration date
These elements are all permitted to be stored on automated systems under the PCI standard. The
primary account number is special when developing a PCI strategy, as only when this account
number is stored, processed, or transmitted by an organization does PCI apply. By using the PAN,
like most organizations that accept credit cards as a form of payment or authentication of identity,
you must comply with the PCI-DSS requirements.
Requirement 3 of the Digital Security Standard for the PCI regulation deals with the storage and
protection of cardholder data and is the requirement most directly addressed by the functionality of
TDE. Consider the following language in the DSS:
Requirement 3 of the DSS – Protect Cardholder Data
Encryption is a critical component of cardholder data protection. If an intruder circumvents
other network security controls and gains access to encrypted data, without the proper
■
■
■
■

■
■
■
■
■
■
48 Part I: Oracle Database Security New Features
cryptographic keys, the data is unreadable and unusable to that person. Other effective
methods of protecting stored data should be considered as potential risk mitigation
opportunities. For example, methods for minimizing risk include not storing cardholder
data unless absolutely necessary, truncating cardholder data if full PAN is not needed,
and not sending PAN in unencrypted e-mails.
AND
To minimize risk, store only those data elements needed for business. NEVER store the card
verification code or value or PIN verification value data elements.
Section 3.4 of the DSS goes on to advise that the PAN (at a minimum) must be rendered unreadable
anywhere it is stored using one of the following approaches:
Strong one-way hash functions (hashed indexes)
Truncation
Index tokens and pads (pads must be securely stored)
Strong cryptography with associated key management processes and procedures.
The MINIMUM account information that must be rendered unreadable is the PAN.
Organizations are looking at the available options to protect credit card data as required to
maintain day-to-day operations and comply with the DSS. All who accept and store credit card data
must comply or lose the ability to accept card transactions—be it an online retailer, a traditional
brick-and-mortar store, a local utility that stores credit card data for its monthly ePayment system, or
a state’s department of transportation storing credit card information for its customers who are billed
for toll usage. Luckily, protecting this valuable data can be accomplished in many ways.
The primary benefits of using TDE to help with a PCI-DSS–compliance strategy are threefold.
First, implementing the encryption to support PCI doesn’t require much, if anything, from the

developers regarding changes to the application. The real work, encrypting/decrypting the data
and managing the key storage, is handled by the database. The setup requires only a few cycles
of a DBA and doesn’t necessarily impact day-to-day operations for other administrative staff.
Second, because the encryption occurs within the database engine and not the application,
it doesn’t matter if multiple applications are accessing the same data—again, since the database
handles the process transparently.
Last, if you were to build your own encryption logic into your application, storage of the keys
used to encrypt the credit card information must be stored somewhere. Where to store these keys
becomes a chicken-or-the-egg paradox, since the keys would need to be stored at a location this
is accessible to the applications that need them. If the keys and the encrypted data are colocated,
the protection offered by encrypting the credit card information is greatly diminished, since the
security of the storage is a main consideration in the first place.
For instance, you may never store Credit Verification Values (CVVs—CVV2 for Visa, CVC2 for
MasterCard, and CID for American Express). Those elements that may be stored—card number,
expiration date, and cardholder’s name—must use protection (such as encryption) to secure the data.
■
■
■
■
■
Chapter 2: Transparent Data Encryption 49
Operational Concerns
TDE, as you know, protects data at rest with a high level of assurance. Data, however, doesn’t rest
all the time. As organizations use data, other requirements come into play and data gets moved in
a variety of ways. Organizations move data from production to development environments, it is
loaded into data warehouses from source systems, it gets replicated to offsite disaster recovery
locations, it is moved temporarily to make administrative changes to systems, and it must sometimes
be moved as a result of hardware changes.
When moving data is a requirement, you cannot simply discard the security you’ve used to
protect your data; instead, you must extend that security to these new processes and procedures.

To accomplish the move in a secure fashion, you must think about data security (is it clear or
ciphertext?) and communication channel (network, file movement, and so on).
Data Guard with TDE
Oracle Data Guard allows you to maintain a copy of the database at a secondary location that is
periodically updated with changes made to the primary database by transmitting redo logs. When
used in conjunction with column-level encryption of TDE, both physical and logical standby are
possible and any data encrypted in the primary database is also encrypted in the redo log. Since
physical standby moves redo logs from the primary to secondary database and then applies them
directly, the wallet does not need to be opened because the data in the shipped log files has
already been encrypted and can be applied in its encrypted form.
Logical standby moves data from the primary to secondary location in the redo log, but in
contrast, it applies the changes to the secondary database using a process called SQL Apply. Since
SQL Apply must read the log files before applying the changes at the secondary location, an Oracle
Wallet with the same Master Key as the primary must be both present and open.
Performance
Most customers’ second question after, “How does TDE work?” is, “What effect will this have on the
performance of my database systems?” These are both certainly fair questions. Everyone is trying to
maximize their resources, get the most out of their hardware, and keep a user community satisfied
with their experience using applications that the database supports. So they are disappointed to hear
that while the first question is easy to answer (you’ve already got a pretty good idea of the mechanics),
the answer to the second question usually starts with something like, “It depends…,” followed by a
less than satisfying conversation.
The truth is, that answer depends on a number of factors—index participation for candidate
columns, current system performance, number of tables having encrypted columns, and the raw
number of rows in the average transaction having encrypted columns. Once these are understood,
it becomes apparent that applications fall into two categories: “minimal effects” or “drastic effects.”
Most applications fall into the first category, and TDE can be used successfully, especially if an
upgrade to 11g is an option.
Since arithmetic operations are always used when encrypting and decrypting, and despite the
fact that implementations use encryption algorithms designed for efficiency and elegance, they

slow system actions by taking processing power from other tasks. When used to encrypt varchar2
data in 10–20 character columns, TDE averages a 5–8 percent performance impact regarding
single query performance. Reports of performance degradation can generally be attributed to
50 Part I: Oracle Database Security New Features
index build failures after encrypting or to an application using LIKE, BETWEEN, or other functions
needing an index to perform well.
Be sure to test applications thoroughly after encrypting any column to gauge the impact of
encryption adequately, as you would when making any signification change. Using column-level
encryption a 10g or 11g environment, the following course of action helps minimize risk, if an
outage is permissible during the implementation:
1. Identify candidate columns for encryption (credit card number, national identifiers,
and so on).
2. Ensure that these are TDE supported datatypes.
3. Ensure that the column doesn’t participate in an index.
4. Ensure that the column is not part of a PK/FK relationship.
5. Encrypt the column(s).
6. Reorganize the table.
If an outage is not permissible during the implementation, follow these steps:
1. Identify candidate columns for encryption (credit card number, national identifiers,
and so on).
2. Ensure that these are TDE supported datatypes.
3. Ensure that the column doesn’t participate in an index,
4. Ensure that the column is not part of a PK/FK relationship.
5. Use online reorganization or modify the table as shown in the “Encrypting an Existing
Column” section earlier in this chapter, as it locks the tables (both old and new) for only
the period of time it takes to rename the tables.
By creating a very simple test case on a table with 100,000 rows of credit card data, and
running a set of timed queries to select values from the columns, we are able to measure the
effects of encryption versus a standard unencrypted query. It turns out that the query against
encrypted data takes slightly longer than a query on unencrypted data, as long as both are

indexed (see Figure 2-10). The difference between queries run on a nonindexed, unencrypted
column and those on an indexed, encrypted column are much more significant. This once again
highlights the need for good tuning and design of our index strategy for systems requiring quick
response times.
Since column-level encryption has the limitations mentioned earlier, not every application is
a good fit for its use. This can be due to need for index use such as ranges, PK/FK relationships or
nonsupported datatypes. In these cases, tablespace encryption provides good alternative, removing
these restrictions and encrypting at course granularity.
The process for migrating to tablespace-level encryption in an Oracle 11g environment can
be best described as follows:
1. Identify tables containing sensitive columns.
2. Create a new encrypted tablespace.
Chapter 2: Transparent Data Encryption 51
3. Move tables from an unencrypted to encrypted tablespace using ALTER TABLE customer
MOVE TABLESPACE encrypted_customer;.
The other area of performance to consider is storage. Column-level TDE takes more space
for each encrypted column (17–51 bytes per column). This additional space is the result of three
things: padding required by the algorithm, Message Authentication Code (20 bytes), and salt
(16 bytes). To minimize the amount of additional storage consumed by using TDE, consider
using the NO SALT and NOMAC directives when encrypting columns. When you’re dealing
with relatively minor sizes (36 bytes seems very small today), it’s easy to forget that in cases of
large data volumes, these can add up. For a table with one encrypted column and 2 million
rows, it is only 68 megabytes, but for customer with large data sets it can become daunting
(with 7 billion rows, the additional 240 gigabytes could be an issue). When faced with multiple
candidate columns stored in each of multiple tables, large databases must account for storage
requirements in planning and testing.
FIGURE 2-10 TDE timings unencrypted nonindexed versus encrypted with index
52 Part I: Oracle Database Security New Features
Exporting and Importing Encrypted Data
Moving data out of one system and into another is one of a DBA’s many tasks. Generally, tools

such as traditional export/import or the newer Data Pump are used to perform this task. Export
does not support tables with columns encrypted with TDE. Attempting to export the example
customer_enc table shows this incompatibility:
[oracle@aosdb ~] (aos-db)$ exp sh/oracle11g tables=customer_enc
Export: Release 11.1.0.6.0 - Production on Sat Aug 23 13:30:19 2008
Copyright (c) 1982, 2007, Oracle. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining
and Real Application Testing options
Export done in US7ASCII character set and AL16UTF16 NCHAR character set
server uses WE8MSWIN1252 character set (possible charset conversion)
About to export specified tables via Conventional Path
EXP-00107: Feature (COLUMN ENCRYPTION) of column CUST_CREDIT_CARD_NO in table
SH.CUSTOMER_ENC is not supported. The table will not be exported.
EXP-00091: Exporting questionable statistics.
Export terminated successfully with warnings.
[oracle@aosdb ~] (aos-db)$
Instead, TDE support is built in to Oracle Data Pump. Data Pump, like its predecessor, export/
import, allows administrative users to pull data from a table, store that data in a file on the filesystem,
and then pull the data from a datafile back into a table (on the same or another system). Data Pump
will export data in cleartext, but it can then encrypt (using a new key) the resulting dump file.
Using the Data Pump to export TDE-encrypted table data allows administrators to move data,
but you must remember that the data is decrypted by Data Pump and will be stored in the
filesystem as cleartext.
oracle@aosdb ~] (aos-db)$ expdp system/oracle11g DUMPFILE=exports:customer_enc.dmp tables=sh.
customer_enc
Export: Release 11.1.0.6.0 - Production on Saturday, 23 August, 2008 14:07:01
Copyright (c) 2003, 2007, Oracle. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining

and Real Application Testing options
Starting "SYSTEM"."SYS_EXPORT_TABLE_01": system/********
DUMPFILE=exports:customer_enc.dmp tables=sh.customer_enc
Estimate in progress using BLOCKS method
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 64 KB
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
. . exported "SH"."CUSTOMER_ENC" 8.843 KB 7 rows
ORA-39173: Encrypted data has been stored unencrypted in dump file set.
Master table "SYSTEM"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
**********************************************************************
Dump file set for SYSTEM.SYS_EXPORT_TABLE_01 is:
/tmp/exports/customer_enc.dmp
Job "SYSTEM"."SYS_EXPORT_TABLE_01" completed with 1 error(s) at 14:07:12
[oracle@aosdb ~] (aos-db)$
Chapter 2: Transparent Data Encryption 53
Fortunately, Data Pump reminds you that the data is now unprotected with the error message
“ORA-39173: Encrypted data has been stored unencrypted in dump file set.” This process makes
it easy to move data from one system to another without your worrying about having the same
Master Key available when importing, but it again puts your data into the “unprotected medium”
over which you have little control. Luckily, Data Pump includes a feature that allows you to
encrypt the resulting file using the ENCRYPTION_PASSWORD option:
[oracle@aosdb ~] (aos-db)$ expdp system/oracle11g DUMPFILE=exports:customer_enc_protected.dmp
TABLES=sh.customer_enc ENCRYPTION_PASSWORD='AppliedOracleSecurity'
Export: Release 11.1.0.6.0 - Production on Saturday, 23 August, 2008 14:15:07
Copyright (c) 2003, 2007, Oracle. All rights reserved.
Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production

With the Partitioning, Oracle Label Security, OLAP, Data Mining
and Real Application Testing options
Starting "SYSTEM"."SYS_EXPORT_TABLE_01": system/********
DUMPFILE=exports:customer_enc_protected.dmp TABLES=sh.customer_enc encryption_password=********
Estimate in progress using BLOCKS method
Processing object type TABLE_EXPORT/TABLE/TABLE_DATA
Total estimation using BLOCKS method: 64 KB
Processing object type TABLE_EXPORT/TABLE/TABLE
Processing object type TABLE_EXPORT/TABLE/CONSTRAINT/CONSTRAINT
Processing object type TABLE_EXPORT/TABLE/INDEX/STATISTICS/INDEX_STATISTICS
Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS
. . exported "SH"."CUSTOMER_ENC" 8.851 KB 7 rows
Master table "SYSTEM"."SYS_EXPORT_TABLE_01" successfully loaded/unloaded
******************************************************************************
Dump file set for SYSTEM.SYS_EXPORT_TABLE_01 is:
/tmp/exports/customer_enc_protected.dmp
Job "SYSTEM"."SYS_EXPORT_TABLE_01" successfully completed at 14:15:14
[oracle@aosdb ~] (aos-db)$
The password provided by ENCRYPTION_PASSWORD is used to encrypt the resulting file,
customer_enc_protected.dmp. It can then be imported only by providing the password.
Integration with Hardware Security Modules
When using TDE functionality, you will in turn be using an Oracle Wallet. As TDE uses the Oracle
Wallet to store and generate Master Key values to encrypt table keys and ultimately data, it does
so in a simple file-based manner. As mentioned earlier, the generation of the encryption wallet
sets the wallet password and generates a Master Key that is then stored in the Oracle Wallet using
PKCS #12. Some customers must conform with strict policy or procedural mandates with respect
to management of their encryption keys. In very highly protected (professionally paranoid)
customer environments, it is considered more secure to manage keys in a hardware device (HSM)
rather than on a file system. For those faced with such challenges, Oracle 11g TDE introduced the
ability to integrated TDE functionality with the Key Management and Key Backup capabilities of

an HSM device.
Several third-party vendors produce an Oracle TDE-certified HSM devices, with more being
added to the certified list every month. These devices manage several aspects of everyday
management of encryption keys. First, they are built to manage the encryption keys inside the
device from generation to disposal. This is important, because to keep keys protected, you need to
develop good policy and process for backup, restoration, and use of cryptographic keys from all the