Securing Data at Rest in Oracle 11g

Exclusive offer: get 50% off this eBook here
Oracle 11g Anti-hacker's Cookbook

Oracle 11g Anti-hacker's Cookbook — Save 50%

Over 50 recipes and scenarios to hack, defend, and secure your Oracle Database with this book and ebook.

$32.99    $16.50
by Adrian Neagu | October 2012 | Cookbooks Enterprise Articles Oracle

For almost all organizations, data security is a matter of prestige and credibility. The Oracle Database is one of the richest in features and the most used database in a variety of industries, where security is essential. In this article by Adrian Neagu, author of Oracle 11g Anti-hacker's Cookbook we will learn how to secure data at rest and will cover:

  • Using block device encryption
  • Using filesystem encryption with eCryptfs
  • Using DBMS_CRYPTO for column encryption
  • Using Transparent Data Encryption for column encryption
  • Using TDE for tablespace encryption
  • Using encryption with data pump
  • Using encryption with RMAN

(For more resources on Oracle, see here.)

Introduction

The Oracle physical database files are primarily protected by filesystem privileges. An attacker who has read permissions on these files will be able to steal the entire database or critical information such as datafiles containing credit card numbers, social security numbers, or other types of private information. Other threats are related to data theft from storage mediums where the physical database resides. The same applies for unprotected backups or dumps that can be easily restored or imported. The data in the database is stored in proprietary format that is quite easy to decipher. There are several sites and specialized tools available to extract data from datafiles, backups, and dumps, known generically as Data Unloading ( DUL). These tools are usually the last solution when the database is corrupted and there is no backup available for restore and recovery. As you probably have already guessed, they can be used by an attacker for data extraction from stolen databases or dumps (summary descriptions and links to several DUL tools can be found at http://www.oracle-internals.com/?p=17 Blvd). The technology behind DUL utilities is based on understanding how Oracle keeps the data in datafiles behind the scenes (a very good article about Oracle datafile internals, written by Rodrigo Righetti, can be found at http://docs.google.com/Doc?id=df2mxgvb_1dgb9fv). Once you decipher the mechanism you will be able to build your tool with little effort.

One of the best methods for protecting data at rest is encryption. We can enumerate the following as data encryption methods, described in this chapter for using with Oracle database:

  1. Operating system proprietary filesystem or block-based encryption
  2. Cryptographic API, especially DBMS_CRYPTO used for column encryption
  3. Transparent Data Encryption for encrypting columns, tablespaces, dumps, and RMAN backups

Using block device encryption

By using block device encryption the data is encrypted and decrypted at block-device level. The block device can be formatted with a filesystem. The decryption is performed once the filesystem is mounted by the operating system, transparently for users. This type of encryption protects best against media theft and can be used for datafile placement. In this recipe we will add a new disk and implement block-level encryption with Linux Unified Key Setup-on-disk-format (LUKS).

Getting ready

All steps will be performed with nodeorcl1 as root.

How to do it...

  1. Shut down nodeorcl1, then add a new disk to the nodeorcl1 system and boot it. Our new device will be seen by the operating system as /dev/sdb . Next, create a new partition /dev/sdb1 using fdisk as follows:
  2. [root@nodeorcl1 ~]# fdisk /dev/sdb WARNING: DOS-compatible mode is deprecated. It's strongly recommended to switch off the mode (command 'c') and change display units to sectors (command 'u'). Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First cylinder (1-5577, default 1): Using default value 1 Last cylinder, +cylinders or +size{K,M,G} (1-5577, default 5577): Using default value 5577 Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. Syncing disks.

  3. Format and add a passphrase for encryption on /dev/sdb1 device with cryptsetup utility as follows:

    [root@nodeorcl1 dev]# cryptsetup luksFormat /dev/sdb1 WARNING! ======== This will overwrite data on /dev/sdb1 irrevocably. Are you sure? (Type uppercase yes): YES Enter LUKS passphrase: P5;@o[]klopY&P] Verify passphrase: P5;@o[]klopY&P] [root@nodeorcl1 dev]#

  4. The access on the encrypted device is not performed directly; all operations are performed through a device-mapper. Open the device-mapper for /dev/sdb1 as follows:

    [root@nodeorcl1 mapper]# cryptsetup luksOpen /dev/sdb1 storage Enter passphrase for /dev/sdb1: P5;@o[]klopY&P] [root@nodeorcl1 mapper]# [root@nodeorcl1 mapper]# ls -al /dev/mapper/storage lrwxrwxrwx. 1 root root 7 Sep 23 20:03 /dev/mapper/storage -> ../ dm-4

  5. The formatting with a filesystem must also be performed on the device-mapper. Format the device-mapper with the ext4 filesystem as follows:

    [root@nodeorcl1 mapper]# mkfs.ext4 /dev/mapper/storage mke2fs 1.41.12 (17-May-2010) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) ………………………………………………………………………………………………………… This filesystem will be automatically checked every 38 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. [root@nodeorcl1 mapper]#

  6. Next we will configure the device-mapper /dev/mapper/storage for automatic mount during boot. Create a directory called storage that will be used as the mount point:

    [root@nodeorcl1 storage]# mkdir /storage

  7. The mapper-device /dev/mapper/storage can be mounted as a normal device:

    [root@nodeorcl1 storage]# mount /dev/mapper/storage /storage

  8. To make the mount persistent across reboots add /storage as the mount point for /dev/mapper/storage. First add the mapper-device name into /etc/crypttab:

    [root@nodeorcl1 storage]# echo "storage /dev/sdb1" > /etc/crypttab

  9. Add the complete mapper-device path, mount point, and filesystem type in /etc/fstab as follows:

    /dev/mapper/storage /storage ext4 defaults 1 2

  10. Reboot the system:

    [root@nodeorcl1 storage]# shutdown –r now

  11. At boot sequence, the passphrase for /storage will be requested. If no passphrase is typed then the mapper device will be not mounted.

How it works...

Block device encryption is implemented to work below the filesystem level. Once the device is offline, the data appears like a large blob of random data. There is no way to determine what kind of filesystem and data it contains.

There's more...

To dump information about the encrypted device you should execute the following command:

[root@nodeorcl1 dev]# cryptsetup luksDump /dev/sdb1 LUKS header information for /dev/sdb1 Version: 1 Cipher name: aes Cipher mode: cbc-essiv:sha256 Hash spec: sha1 Payload offset: 4096 MK bits: 256 MK digest: 2c 7a 4c 96 9d db 63 1c f0 15 0b 2c f0 1a d9 9b 8c 0c 92 4b MK salt: 59 ce 2d 5b ad 8f 22 ea 51 64 c5 06 7b 94 ca 38 65 94 ce 79 ac 2e d5 56 42 13 88 ba 3e 92 44 fc MK iterations: 51750 UUID: 21d5a994-3ac3-4edc-bcdc-e8bfbf5f66f1 Key Slot 0: ENABLED Iterations: 207151 Salt: 89 97 13 91 1c f4 c8 74 e9 ff 39 bc d3 28 5e 90 bf 6b 9a c0 6d b3 a0 21 13 2b 33 43 a7 0c f1 85 Key material offset: 8 AF stripes: 4000 Key Slot 1: DISABLED Key Slot 2: DISABLED Key Slot 3: DISABLED Key Slot 4: DISABLED Key Slot 5: DISABLED Key Slot 6: DISABLED Key Slot 7: DISABLED [root@nodeorcl1 ~]#

Using filesystem encryption with eCryptfs

The eCryptfs filesytem is implemented as an encryption/decryption layer interposed between a mounted filesystem and the kernel. The data is encrypted and decrypted automatically at filesystem access. It can be used for backup or sensitive files placement for transportable or fixed storage mediums. In this recipe we will install and demonstrate some of eCryptfs, capabilities.

Getting ready

All steps will be performed on nodeorcl1.

How to do it...

eCryptfs is shipped and bundled with the Red Hat installation kit.

  1. The eCryptfs package is dependent on the trouser package. As root user, first install the trouser package followed by installation of the ecryptfs-util package:

    [root@nodeorcl1 Packages]# rpm -Uhv trousers-0.3.4-4.el6.x86_64. rpm warning: trousers-0.3.4-4.el6.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY Preparing... ###################################### ##### [100%] 1:trousers ###################################### ##### [100%] [root@nodeorcl1 Packages]# rpm -Uhv ecryptfs-utils-82-6.el6. x86_64.rpm warning: ecryptfs-utils-82-6.el6.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY Preparing... ###################################### ##### [100%] 1:ecryptfs-utils ###################################### ##### [100%]

  2. Create a directory that will be mounted with the eCryptfs filesystem and set the oracle user as the owner:

    [root@nodeorcl1 ~]# mkdir /ecryptedfiles [root@nodeorcl1 ~]# chown -R oracle:oinstall /ecryptedfiles

  3. Mount /ecryptedfiles to itself using the eCryptfs filesystem. Use the default values for all options and use a strong passphrase as follows:

    [root@nodeorcl1 hashkeys]# mount -t ecryptfs /ecryptedfiles / ecryptedfiles Select key type to use for newly created files: 1) openssl 2) tspi 3) passphrase Selection: 3 Passphrase: lR%5_+KO}Pi_$2E Select cipher: 1) aes: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded) 2) blowfish: blocksize = 16; min keysize = 16; max keysize = 56 (not loaded) 3) des3_ede: blocksize = 8; min keysize = 24; max keysize = 24 (not loaded) 4) cast6: blocksize = 16; min keysize = 16; max keysize = 32 (not loaded) 5) cast5: blocksize = 8; min keysize = 5; max keysize = 16 (not loaded) Selection [aes]: Select key bytes: 1) 16 2) 32 3) 24 Selection [16]: Enable plaintext passthrough (y/n) [n]: Enable filename encryption (y/n) [n]: y Filename Encryption Key (FNEK) Signature [d395309aaad4de06]: Attempting to mount with the following options: ecryptfs_unlink_sigs ecryptfs_fnek_sig=d395309aaad4de06 ecryptfs_key_bytes=16 ecryptfs_cipher=aes ecryptfs_sig=d395309aaad4de06 Mounted eCryptfs [root@nodeorcl1 hashkeys]#

  4. Switch to the oracle user and export the HR schema to /ecryptedfiles directory as follows:

    [oracle@nodeorcl1 ~]$ export NLS_LANG=AMERICAN_AMERICA.AL32UTF8 [oracle@nodeorcl1 ~]$ exp system file=/ecryptedfiles/hr.dmp owner=HR statistics=none Export: Release 11.2.0.3.0 - Production on Sun Sep 23 20:49:30 2012 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Password: Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options Export done in AL32UTF8 character set and AL16UTF16 NCHAR character set About to export specified users ... …………………………………………………………………………………………………………….. . . exporting table LOCATIONS 23 rows exported . . exporting table REGIONS 4 rows exported . …………………………………………………………………………………………………….. . exporting post-schema procedural objects and actions . exporting statistics Export terminated successfully without warnings. [oracle@nodeorcl1 ~]$

  5. If you open the hr.dmp file with the strings command, you will be able to see the content of the dump file:

    [root@nodeorcl1 ecryptedfiles]# strings hr.dmp | more ……………………………………………………………………………………………………………………………………….. CREATE TABLE "COUNTRIES" ("COUNTRY_ID" CHAR(2) CONSTRAINT "COUNTRY_ID_NN" NOT NULL ENABLE, "COUNTRY_NAME" VARCHAR2(40), "REGION_ID" NUMBER, CONSTRAINT "COUNTRY_C_ID_PK" PRIMARY KEY ("COUNTRY_ID") ENABLE ) ORGANIZATION INDEX PCTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "EXAMPLE" NOLOGGING NOCOMPRESS PCTTHRESHOLD 50 INSERT INTO "COUNTRIES" ("COUNTRY_ID", "COUNTRY_NAME", "REGION_ ID") VALUES (:1, :2, :3) Argentina Australia Belgium Brazil Canada

  6. Next as root unmount /ecryptedfiles as follows:

    [root@nodeorcl1 /]# unmount /ecryptedfiles/

  7. If we list the content of the /ecryptedfile directory now, we should see that the file name and content is encrypted:

    [root@nodeorcl1 /]# cd /ecryptedfiles/ [root@nodeorcl1 ecryptedfiles]# ls ECRYPTFS_FNEK_ENCRYPTED.FWbHZH0OehHS.URqPdiytgZHLV5txs- bH4KKM4Sx2qGR2by6i00KoaCBwE-- [root@nodeorcl1 ecryptedfiles]# [root@nodeorcl1 ecryptedfiles]# more ECRYPTFS_FNEK_ENCRYPTED. FWbHZH0OehHS.URqPdiytgZHLV5txs-bH4KKM4Sx2qGR2by6i00KoaCBwE-- ………………………………………………………………………………………………………………………………… 9$Eî□□KdgQNK□□v□□ S□□J□□□ h□□□ PIi'ʼn□□R□□□□□siP □b □`)3 □W □W( □□□□c!□□8□E.1'□R□7bmhIN□□--(15%) ………………………………………………………………………………………………………………………………….

  8. To make the file accessible again, mount the /ecryptedfiles filesystem by passing the same parameters and passphrase as performed in step 3.

How it works...

eCryptfs is mapped in the kernel Virtual File System ( VFS ), similarly with other filesystems such as ext3, ext4, and ReiserFS. All calls on a filesystem will go first through the eCryptfs mount point and then to the current filesystem found on the mount point (ext4, ext4, jfs, ReiserFS). The key used for encryption is retrieved from the user session key ring, and the kernel cryptographic API is used for encryption and decryption of file content. The communication with kernel is performed by the eCryptfs daemon. The file data content is encrypted for each file with a distinct randomly generated File Encryption Key ( FEK ); FEK is encrypted with File Encryption Key Encryption Key ( FEKEK ) resulting in an Encrypted File Encryption Key ( EFEK) that is stored in the header of file.

There's more...

On Oracle Solaris you can implement filesystem encryption using the ZFS built-in filesystem encryption capabilities. On IBM AIX you can use EFS.

Oracle 11g Anti-hacker's Cookbook Over 50 recipes and scenarios to hack, defend, and secure your Oracle Database with this book and ebook.
Published: October 2012
eBook Price: $32.99
Book Price: $54.99
See more
Select your format and quantity:

Using DBMS_CRYPTO for column encryption

The DBMS_CRYPTO PL/SQL package is an important component of Oracle Cryptographic API. DBMS_CRYPTO can be wrapped in your own packages and used for encryption and decryption. It is mainly used for hindering data access using encryption on designated columns. Consider it as a selective method of encryption—the columns are stored in encrypted format on storage and remain encrypted during data access unless they are decrypted with the appropriate function.

In this recipe we will create a table EMPLOYEES_ENC and encrypt and decrypt the SALARY and COMMISSION_PCT columns of this table by using DBMS_CRYPTO wrapped in two functions.

Getting Ready

All steps will be performed on the HACKDB database.

How to do it...

  1. As root create a directory named hashkeydir and make the oracle user the owner:

    mkdir /hashkeydir chown oracle:oinstall /hashkeydir

  2. Connect as system and create a directory named encryption_keys as follows:

    SQL> conn system Enter password: Connected. SQL> SQL> create or replace directory encryption_keys as '/hashkeydir'; Directory created.

  3. Grant read and write privileges on the encryption_keys directory to the HR user as follows:

    SQL> grant read, write on directory encryption_keys to HR;

  4. Grant the execute privilege on the DBMS_CRYPTO PL/SQL package to HR as follows:

    SQL> grant execute on dbms_crypto to hr; Grant succeeded. SQL>

  5. Connect as the HR user and create a table named employees_enc as follows:

    SQL> conn HR Enter password: Connected. SQL> create table employees_enc as select first_name,last_name, salary, commission_pct from employees where salary is not null and commission_pct is not 2 null and rownum <= 5; Table created. SQL>

  6. Next, add two columns ENC_SALARY and ENC_COMMISSION_PCT defined as RAW type. ENC_SALARY will store the encrypted values for the SALARY column and ENC_COMMISSION_PCT for the COMMISSION_PCT column:

    SQL> ALTER TABLE EMPLOYEES_ENC ADD (ENC_SALARY RAW(50)); Table altered. SQL> ALTER TABLE EMPLOYEES_ENC ADD (ENC_COMMISSION_PCT RAW(50)); Table altered. SQL>

  7. At this step we will create a package named column_encryption_pkg and the wrapper function definitions for encryption and decryption implemented with DBMS_CRYPTO. We will explain in detail the scope of its functions and procedures later. Create the package column_encryption_pkg as follows:

    CREATE OR REPLACE PACKAGE encryption_pkg IS --Generate the encryption key for a given table PROCEDURE store_encryption_key ( p_dir_name IN VARCHAR2, p_key_filename IN VARCHAR2); --Retrieve the encryption key from the local storage --PROCEDURE get_encryption_key(p_dir_name IN VARCHAR2,p_key_ filename IN VARCHAR2); --Function used to encrypt a given string FUNCTION encrypt_column ( p_column_value IN VARCHAR2, p_dir_name IN VARCHAR2, p_key_filename IN VARCHAR2) RETURN raw; --Function used to decrypt a given string FUNCTION decrypt_column ( p_encrypted_value IN RAW, p_dir_name IN VARCHAR2, p_key_filename IN VARCHAR2) RETURN VARCHAR2; END column_encryption_pkg; SQL> / Package created. SQL>

  8. Next, create the PACKAGE BODY of column_encryption_pkg as follows:

    CREATE OR REPLACE PACKAGE BODY column_encryption_pkg IS SQLERRMSG VARCHAR2(255); SQLERRCDE NUMBER; ENC_TYP_3DES CONSTANT PLS_INTEGER := DBMS_CRYPTO.ENCRYPT_3DES -- use 3DES algorithm for encryption + DBMS_CRYPTO.CHAIN_CBC -- use CBC as block cipher chaining mode + DBMS_CRYPTO.PAD_PKCS5; -- use PKCS5 type padding PROCEDURE store_encryption_key ( p_dir_name IN VARCHAR2, p_key_filename IN VARCHAR2) IS var_key_length NUMBER := 256/8; -- key length 256 bits (32 bytes) var_encryption_key RAW (32); var_file_handler UTL_FILE.FILE_TYPE; BEGIN var_encryption_key := DBMS_CRYPTO.RANDOMBYTES (var_key_length); -- generate a random 256 bit length key var_file_handler := UTL_FILE.FOPEN(p_dir_name,p_key_ filename,'W',256); -- open the file for write UTL_FILE.PUT_RAW(var_file_handler,var_encryption_key,TRUE); -- write the encryption key into the file UTL_FILE.FCLOSE(var_file_handler); -- close the file handler END store_encryption_key; FUNCTION encrypt_column ( p_column_value IN VARCHAR2, p_dir_name IN VARCHAR2, p_key_filename IN VARCHAR2) RETURN RAW IS -- Local variables var_column_value_to_raw RAW(48); --initial string converted to raw var_encrypted_raw_column_value RAW(48); --encrypted value of the string var_encryption_key RAW (32); var_file_handler UTL_FILE.FILE_TYPE; encryption_key RAW (32); BEGIN var_column_value_to_raw := UTL_I18N.STRING_TO_RAW(p_column_ value, 'AL32UTF8'); var_file_handler := UTL_FILE.FOPEN(p_dir_name,p_key_ filename,'R',256); UTL_FILE. GET_RAW (var_file_handler, var_encryption_key, 32); encryption_key := var_encryption_key; var_encrypted_raw_column_value := DBMS_CRYPTO.ENCRYPT( src => var_column_value_to_raw ,typ => ENC_TYP_3DES ,KEY => encryption_ key ); RETURN var_encrypted_raw_column_value; EXCEPTION WHEN OTHERS THEN SQLERRMSG := SQLERRM; SQLERRCDE := SQLCODE; RETURN NULL; END encrypt_column; FUNCTION decrypt_column ( p_encrypted_value IN RAW, p_dir_name IN VARCHAR2, p_key_filename IN VARCHAR2) RETURN VARCHAR2 IS -- Local variables var_encryption_key RAW (32); var_column_raw_val_to_vr VARCHAR2(200); var_decrypted_raw_column_value RAW(200); var_file_handler UTL_FILE.FILE_TYPE; encryption_key RAW (32); BEGIN var_file_handler := UTL_FILE.FOPEN(p_dir_name,p_key_ filename,'R',256); UTL_FILE.GET_RAW (var_file_handler, var_encryption_key, 32); encryption_key := var_encryption_key; --decrypt the encrypted string var_decrypted_raw_column_value := DBMS_CRYPTO.DECRYPT( src => P_ ENCRYPTED_VALUE ,typ => ENC_TYP_3DES ,KEY => encryption_key ); --convert the value to varchar2 var_column_raw_val_to_vr := UTL_I18N.RAW_TO_CHAR(var_decrypted_ raw_column_value, 'AL32UTF8'); RETURN var_column_raw_val_to_vr; EXCEPTION WHEN OTHERS THEN SQLERRMSG := SQLERRM; SQLERRCDE := SQLCODE; RETURN NULL; END decrypt_column; END column_encryption_pkg; SQL> / Package body created. SQL>

  9. At this step we should be able to encrypt the SALARY and COMMISSION_PCT columns. First we have to generate the encryption key by executing the store_encryption_key procedure. Pass the directory name ( ENCRYPTION_KEYS) and the key storage file name (KEYFILE) as follows:

    SQL> execute column_encryption_pkg.store_encryption_ key('ENCRYPTION_KEYS','KEYFILE'); PL/SQL procedure successfully completed. SQL>

  10. Next, encrypt the SALARY and COMMISSION_PCT columns by executing the encrypt_column function in an UPDATE statement as follows:

    SQL> update employees_enc set enc_salary=column_encryption_pkg. encrypt_column(SALARY,'ENCRYPTION_KEYS','KEYFILE'),enc_commission_ pct=column_encryption_pkg.encry pt_column(COMMISSION_PCT,'ENCRYPTION_KEYS','KEYFILE'); 5 rows updated. SQL> commit 2 ; Commit complete. SQL>

  11. Next, verify that the decryption is working. We should have the same values at return as the original values.

    SELECT first_name, last_name, column_encryption_pkg.decrypt_column(ENC_SALARY,'ENCRYPTION_ KEYS','KEYFILE') AS DEC_SALARY, SALARY, column_encryption_pkg.decrypt_column(ENC_COMMISSION_ PCT,'ENCRYPTION_KEYS','KEYFILE') AS DEC_COMMISSION_PCT, COMMISSION_PCT FROM employees_enc WHERE salary =column_encryption_pkg.decrypt_column(ENC_ SALARY,'ENCRYPTION_KEYS','KEYFILE') AND commission_pct=column_encryption_pkg.decrypt_column(ENC_ COMMISSION_PCT,'ENCRYPTION_KEYS','KEYFILE');

  12. If the column values match, you should remove the unencrypted columns and continue to add values from now on to the corresponding encrypted columns by using the encrypt_column function. Also as an additional protection measure you should remove all the code comments and wrap the package and package body to hide the source code.

How it works...

The DBMS_CRYPTO package accepts as input values varchar2 and lob type fields, and implicitly returns RAW type data. Therefore it is necessary to cast the data from the initial type to RAW and cast back at return to the initial data type.

DBMS_CRYPTO.ENCRYPT_RC4:RC4 provides the following encryption algorithms:

  • For AES:
    • DBMS_CRYPTO.ENCRYPT_AES128: AES with 128-bit key size
    • DBMS_CRYPTO.ENCRYPT_AES192: AES with 192-bit key size
    • DBMS_CRYPTO.ENCRYPT_AES128: AES with 256-bit key size
  • For DES:
    • DBMS_CRYPTO.ENCRYPT_DES : DES wtih 56-bit key size
    • DBMS_CRYPTO.ENCRYPT_3DES_2KEY: 3DES with 112-bit key size
    • DBMS_CRYPTO.ENCRYPT_3DES: 3DES with 168-bit key size

We have briefly described these algorithms in Chapter 2, Defending the Network and Data in Transit.

The supported block cipher chaining modifiers, also known as block cipher modes of operations are ECB, CBC, CFB, and OFB. Cipher modes of operation protect against block replay attacks, enabling repeated and secure use of a block cipher under a single key, making the encryption of one block dependent on all preceding blocks.

The blocks are encrypted using an initialization vector (IV), which is a block of bits used to randomize the encryption. In this way, the resulting ciphertext is different every time even if the input plaintext is the same.

ECB (DBMS_CRYPTO.CHAIN_ECB) is the abbreviation for Electronic Codebook. It is the simplest and weakest cipher chaining modifier. It generates the same ciphertext for the same plaintext being very sensible to replay attacks. Therefore it is not recommended to use it in any circumstances.

CBC (DBMS_CRYPTO.CHAIN_CBC) is the abbreviation for Cipher block chaining. In this mode, on each block of plaintext before encryption an XOR operation is performed using the previous ciphertext block. In this method the encryption is randomized using an initialization vector at the beginning.

CFB (DBMS_CRYPTO.CHAIN_CFB) is the abbreviation for Cipher Feedback. CFB is similar to CBC; the operations are performed as in CBC but in the reverse order.

OFB (DBMS_CRYPTO.CHAIN_OFB) is the abbreviation for Output Feedback. It uses a stream cipher encryption scheme similar to CFB. It generates keystream block s, which are then XORed with the plaintext blocks to get the ciphertext.

The padding schemes provided by DBMS_CRYPTO are PKCS5, NONE, and NULL.

Padding is used to fill up empty blocks. Usually the size of plaintext to be encrypted is not an exact multiple of the block size. The recommended padding scheme is PKCS5.

There's more...

DBMS_CRYPTO can also be used for integrity check by using MD5 and SHA1 hashes, and Message Authentication Codes ( MAC). The difference between hashes and MAC is that hashes are used to guarantee integrity, whereas, a MAC guarantees integrity and authentication. The value generated by a hash is always the same and is based solely on an input value, while a MAC relies on generating the hash using a secret key.

The following is an example of a procedure for generating hash and MAC values using an input password. If the procedure is executed multiple times, it will generate the same hash and different MAC values for the same password.

SQL> Set serveroutput on DECLARE 2 l_pwd VARCHAR2(16) := 'my512pT*;(1)'; 3 l_raw_pwd RAW(128) := utl_raw.cast_to_raw(l_pwd); 4 l_key RAW(256) := DBMS_CRYPTO.RANDOMBYTES(128); 5 l_mac_val RAW(2048); 6 BEGIN 7 dbms_output.put_line('Password: ' || l_pwd); 8 dbms_output.put_line('Raw Password: ' || l_raw_pwd); 9 dbms_output.put_line('Key: ' || l_key); 10 11 l_mac_val := DBMS_CRYPTO.MAC(l_raw_pwd, 12 DBMS_CRYPTO.HMAC_SH1, l_key); 13 dbms_output.put_line('SHA-1 MAC: ' || l_mac_val); 14 15 l_mac_val := DBMS_CRYPTO.MAC(l_raw_pwd, 16 DBMS_CRYPTO.HMAC_MD5, l_key); 17 dbms_output.put_line('MD5 MAC: ' || l_mac_val); 18 END; 19 / Password: my512pT*;(1) Raw Password: 6D7935313270542A3B283129 Key: 3504D8D9D8DDF9696D1DFF26B0A94C44C78C6839663B6315B5656E940F47BBF100EA58F90 3148FE865E9D2D2E3B36A2C73B28C8B0752F5896A50309D082ADA5F SHA-1 MAC: 75FEAC60E9D6BA11BA562501FB500FF8591E08B6 MD5 MAC: 9A3DC312E2D635E59ADEB997681F5143 PL/SQL procedure successfully completed. SQL>

Using Transparent Data Encryption for column encryption

Transparent Data Encryption (TDE) relays on the database kernel mechanism and does not require additional programming. The key management is performed automatically by the database. From an architectural point of view, it was designed to protect the data from physical theft and it does not provide data access protection. The encryption is performed at storage level, and the column decryption occurs at data access. Therefore, the data will be visible for anyone with select privileges on tables containing encrypted columns with TDE. Being a feature provided by Oracle Advanced Security (OAS ), you must purchase the OAS pack license to use this capability.

In this recipe, we will encrypt the EMPLOYEES table's columns, SALARY and COMMISSION_PCT , using various options available for TDE column encryption.

Getting ready

All steps will be performed on the HACKDB database.

How to do it...

  1. As the oracle user, create a directory for the encryption wallet (be sure to secure the filesystem permissions as described in Chapter 1, Operating System Security):

    mkdir –p /security/wallets/tde chmod 600 /security/wallets/tde

  2. TDE encryption is performed using an external master key placed externally within an encryption wallet which is used to encrypt the table key, which in turn is used to encrypt and decrypt data in the table column. The encryption wallet location is defined within sqlnet.ora using ENCRYPTION_WALLET_PARAMETER. Backup sqlnet.ora and add the path to directory created in the previous step to ENCRYPTION_WALLET_LOCATION parameter as follows:

    ENCRYPTION_WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /security/wallets/tde) ) )

  3. Connect as system user and create the encryption wallet by executing the following statement:

    SQL> conn system Enter password: Connected. SQL>SQL> alter system set encryption key identified by "UYio71+^ZaPO";

  4. Connect as the user HR and modify the EMPLOYEES table's SALARY and COMMISSION_PCT columns, and encrypt the EMPLOYEES table's fields by executing the following statements:

    SQL> conn HR Enter password: Connected. Table altered. SQL> alter table hr.employees modify (salary encrypt ); Table altered. SQL> alter table employees modify (commission_pct encrypt ); Table altered.

  5. The information related to the encrypted columns can be found in the USER_ENCRYPTED_COLUMNS dictionary view at user-level and in the DBA_ENCRYPTED_COLUMNS system dictionary view at database-level:

  6. The default encryption algorithm is AES192. If you want to change the encryption algorithm, for example to AES256, issue the following command:

    SQL> alter table hr.employees rekey using 'AES256'; Table altered.

  7. If you want to regenerate the table encryption key, issue the following command:

    SQL> alter table hr.employees rekey; Table altered

  8. The default encryption mode is performed using salt . Salt is a cryptographic term used for a random string that is added to data before encryption and is used to prevent dictionary and pattern matching type attacks. To remove salt from encrypted columns execute the following:

    SQL> alter table hr.employees modify (salary encrypt no salt ); Table altered. SQL> alter table hr.employees modify (commission_pct encrypt no salt); Table altered.

  9. To decrypt the columns, execute the following command:

    SQL> alter table hr.employees modify (salary decrypt); Table altered. SQL> alter table hr.employees modify (commission_pct decrypt); Table altered. SQL>

  10. If you do not specify an explicit wallet location with ENCRYPTION_WALLET_LOCATION or WALLET_LOCATION the default database wallet location will be $ORACLE_BASE/admin/DB_UNIQUE_NAME/wallet or $ORACLE_HOME/admin/DB_UNIQUE_NAME/wallet.

How it works...

The data is encrypted at storage level. This means that the transactions from redo logs, undo, and temp segments will contain these columns in encrypted format. The column data is encrypted also at buffer cache level being protected in this way against different memory read techniques. The columns' encryption keys are stored in the ENC$ dictionary table in encrypted form. The column-level keys are encrypted using the master key that has an external placement configured in sqlnet.ora, using the ENCRYPTION_WALLET_LOCATION or WALLET_LOCATION parameter. The master key value is generated randomly at its definition by TDE. Using the salt default option, the column will be prefixed with randomly generated strings. This method makes statistical attacks and hash matching difficult.

By default, the columns are encrypted using salt and MAC options. The default algorithm used is AES192 and the MAC is implemented using SHA1.

Information about encrypted columns can be found in the following dictionary views:

  • ALL_ENCRYPTED_COLUMNS
  • USER_ENCRYPTED_COLUMNS
  • DBA_ENCRYPTED_COLUMNS

There's more…

There are some limitations regarding column encryption, recommendations to be made, and some performance implications by using column encryption.

Performance implications

The following are performance implications caused by using the column encryption:

  • The database performance is not affected until the encrypted data is accessed or modified. Oracle claims that column encryption and decryption will impose an approximate 5 percent performance penalty. This is a rogue approximation, the performance penalty depends on many factors such as how many encrypted columns are selected, type of joins, if sorting is performed or not against encrypted columns and more. To find out the exact performance penalty you should perform several extensive tests against the encrypted data.
  • Storage overheads: The overhead will not be seen by using the dictionary views.

Limitations

The following are the limitations caused by using the column encryption:

  • The use of streams replication, materialized view logs, transportable tablespaces, logminer, exp/imp, and Oracle Audit Vault, if you use REDO COLLECTORS that are based on streams replication technology.
  • You cannot encrypt indexed columns using the default salt option, and you cannot create indexes on columns encrypted with salt.
  • You cannot encrypt foreign key indexes using TDE column encryption. If this is a necessity consider moving tables with foreign indexes to encrypted tablespaces with TDE.
    • BINARY_DOUBLE
    • BINARY_FLOAT
    • CHAR
    • DATE
    • INTERVAL DAY TO SECOND
    • INTERVAL YEAR TO MONTH
    • LOBs (Internal LOBs and SECUREFILE LOBs Only)
    • NCHAR
    • NUMBER
    • NVARCHAR2
    • RAW
    • TIMESTAMP (includes TIMESTAMP WITH TIME ZONE and TIMESTAMP WITH LOCAL TIME ZONE)
    • VARCHAR2
  • The datatypes that can be encrypted with TDE column encryption are:

     

Recommendations

Do not encrypt columns used in index range scans, the optimizer will not take into consideration the index anymore. The default MAC option will add an additional 20 bytes overhead per encrypted value. Also MAC induces performance overhead due to integrity checking performed at data access. Using NOMAC option will reduce space and performance penalties considerably. Also by using salt there will be an additional 16 bytes overhead per encrypted data. Consider using nosalt option to reduce storage space. The downside of suppressing MAC and salt is that you will end up with weaker security per encrypted column. To save space you can use the NOMAC option. After the columns are encrypted, there can remain portions of data in cleartext format that belonged to columns before encryption. Therefore, it is recommended to move the tables containing encrypted columns to other tablespaces.

Also, there could be situations when the unencrypted data chunks may remain in the swap area, and it is possible to be read by unauthorized users. A solution for this phenomenon may be to use a large page allocation for the database and sessions, or use encrypted swap filesystems. For example, eCryptfs provides encryption at filesystem-level for swap, and can be used on Linux.

See also

  • The Using filesystem encryption with eCryptfs recipe

Using TDE for tablespace encryption

While TDE Column encryption is available from 10 g R2, TDE tablespace encryption is an exclusive 11g feature and was introduced in Oracle R1 (11.1.0.5). Using this option ensures that all tables and indexes contained within a tablespace will be encrypted transparently.

In this recipe, we will create an encrypted tablespace called ENCRYPTED_TBS using TDE.

Getting ready

All steps will be performed using HACKDB database.

How to do it...

For this chapter we will reuse the encryption wallet defined in the previous recipe Using column Transparent Data Encryption:

  1. To create encrypted objects using TDE, the encryption wallet must have the status as OPEN. To check the availability of the encryption wallet, issue the following statement:

    SQL> select wrl_parameter,status from v$encryption_wallet; WRL_PARAMETER - STATUS ------------------------- -------------------------- /security/wallets/tde OPEN

  2. The wallet is open and can be used for encryption. Create encrypted tablespace CRYPTEDTBS as follows:

    SQL> SQL> CREATE TABLESPACE ENCRYPTED_TBS DATAFILE 'D:\APP\ORADATA\ HACKDB\encryptedtbs01.DBF' size 100m autoextend on next 100m maxsize unlimited default storage (en crypt) encryption; Tablespace created. SQL>

  3. More information about existing encrypted tablespaces can be found in the v$encrypted_tablespaces system view:

How it works...

Tablespaces are encrypted using an encryption key stored in the dictionary. Oracle 11 g R1 column encryption and tablespace encryption uses separate encryption keys in R2. These keys are unified in one principal key used for encrypting both columns and tablespaces. The algorithms that can be used for tablespace encryption are: 3DES168, AES128, AES192, and AES256, where AES192 is the default if no other algorithm is specified.

Information about encrypted tablespaces can be found in the V$ENCRYPTED_TABLESPACE dictionary view.

You may find the encrypted tablespaces in your database by querying the DBA_TABLESPACE and USER_TABLEPACES dictionary views.

The ENCRYPTED column indicates whether a tablespace is encrypted.

There's more…

Unlike column-based encryption, there is no additional storage for the encrypted tablespaces.

As a restriction, current tablespaces cannot be encrypted. The data can be moved by using alter table move, create table as select, or using data pump.

Encryption key management

TDE will not perform any encryption or decryption operation unless the encryption wallet is opened.

If you reboot or shutdown the database the encryption wallet will be closed too. To open the encryption wallet:

ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "UYio71+^ZaPO"

To close manually the encryption wallet issue the following:

ALTER SYSTEM SET ENCRYPTION WALLET CLOSE IDENTIFIED BY "UYio71+^ZaPO"

Using encryption with data pump

Table or full database dumps can also be a major source of information theft in case it is not protected. Oracle also provides encryption options for data pump exports using TDE or passwords. In this recipe we will generate dumps by exporting the HR schema using different encryption options. Next, we will import each dump by remapping the tablespace USERS to the tablespace ENCRYPTED_TBS, and using related options.

Getting ready

All steps will be performed on the database HACKDB.

How to do it...

  1. Create a directory /security/datapump for dumps and change its ownership to the user oracle:

    mkdir –p /backup/datapump chown oracle:oinstall /backup/datapump

  2. Connect as the user system and create an oracle directory mapped to the /backup/datapump directory by executing the following statement:

    SQL> create directory encrypted_dumps as '/storage/datapump'; Directory created.

  3. Export the schema HR by using the all option and the encryption mode transparent as follows:

    [oracle@nodeorcl1 ~]expdp dumpfile=encrypted_dumps:hr_encdump_ transparent.dmp logfile=encrypted_dumps:hr_encdump_transparent.log schemas=HR encryption=all encryption_mode=transparent Export: Release 11.2.0.3.0 - Production on Thu Aug 30 16:19:29 2012 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Username: system Password: Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production With the Partitioning and Oracle Label Security options Starting "SYSTEM"."SYS_EXPORT_SCHEMA_01": system/******** dumpfile=encrypted_dumps:hr_encdump_transparent.dmp logfile=encrypted_dumps:hr_encdump_transparent.lo g schemas=HR encryption=all encryption_mode=transparent …………………………………………………………………………………………………………………………………………………… Master table "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully loaded/ unloaded ****************************************************************** ************ [oracle@nodeorcl1~]

  4. Export the HR schema by using the all option for encryption and "ty745))+!>rto" as the encryption password:

    [oracle@nodeorcl1~] expdp dumpfile=encrypted_dumps:hr_encpdump_ password.dmp logfile=encrypted_dumps:hr_encdump_password.log schemas=HR encryption=all encryption_password="ty745OO+!>rto" Export: Release 11.2.0.3.0 - Production on Thu Aug 30 16:46:25 2012 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Username: system Password: Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production With the Partitioning and Oracle Label Security options Starting "SYSTEM"."SYS_EXPORT_SCHEMA_01": system/******** dumpfile=encrypted_dumps:hr_encpdump_password.dmp logfile=encrypted_dumps:hr_encdump_password.log schemas=HR encryption=all encryption_password=******** .......................................................... [oracle@nodeorcl1~]

  5. Export the HR schema by using the all option for encryption and use "ty745))+!>rto" as the encryption password. For encryption mode use dual mode and change the encryption algorithm to AES256:

    [oracle@nodeorcl1~] expdp dumpfile=encrypted_dumps:hr_encdump_ dualmode.dmp logfile=encrypted_dumps:hr_encdump_dualmode.log schemas=HR encryption=all encryption_password="ty745OO+!>rto" encryption_mode=dual encryption_algorithm=AES256 Export: Release 11.2.0.3.0 - Production on Thu Aug 30 16:07:59 2012 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Username: system Password: Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production With the Partitioning and Oracle Label Security options Starting "SYSTEM"."SYS_EXPORT_SCHEMA_01": system/******** dumpfile=encrypted_dumps:hr_encdump_dualmode.dmp logfile=encrypted_dumps:hr_encdump_dualmode.log schemas=HR encryption=all encryption_password=******** encryption_mode=dual encryption_algorithm=AES256 …………………………………………………………………………………………………………………………………………. Master table "SYSTEM"."SYS_EXPORT_SCHEMA_01" successfully loaded/ unloaded ****************************************************************** ************ .................................................. [oracle@nodeorcl1~]

  6. Import data using the first dump hr_encdump_transparent.dmp, remap the tablespace users to encrypted_tbs, and replace all tables:

    [oracle@nodeorcl1~] impdp dumpfile=encrypted_dumps:hr_encdump_transparent.dmp logfile=encrypted_dumps:import_hr_encdump_transparent.log remap_ tablespace=USER:ENCRYPTED_TBS table_exists_action=replace Import: Release 11.2.0.3.0 - Production on Thu Aug 30 16:41:11 2012 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Username: system Password: Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production With the Partitioning and Oracle Label Security options Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/ unloaded ………………………………………………………………………………………………………………………………………………….. [oracle@nodeorcl1~]

  7. Because this dump was made by using the encryption mode password, it cannot be imported unless a decryption password is given:

    [oracle@nodeorcl1~] impdp dumpfile=encrypted_dumps:hr_encpdump_password.dmp logfile=encrypted_dumps:import_hr_encdump_password.log remap_ tablespace=users:encrypt ed_tbs table_exists_action=replace encryption_ password="ty745OO+!>rto" Import: Release 11.2.0.3.0 - Production on Thu Aug 30 17:06:10 2012 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Username: system Password: Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production With the Partitioning and Oracle Label Security options Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/ unloaded Starting "SYSTEM"."SYS_IMPORT_FULL_01": system/******** dumpfile=encrypted_dumps:hr_encpdump_password.dmp logfile=encrypted_dumps:import_hr_encdump_password.log remap_ tablespace=users:encrypted_tbs table_exists_action=replace encryption_password=******** ……………………………………………………………………………………………………………………………… [oracle@nodeorcl1~]

  8. Dumps made using dual mode will first check for the encryption key within the wallet used for encrypting the exported dump (the wallet must be in open state). Import hr_encdump_dualmode.dmp made with the encryption mode dual, with the encryption wallet open:

    [oracle@nodeorcl1~] impdp dumpfile=encrypted_dumps:hr_encdump_dualmode.dmp logfile=encrypted_dumps:import_hr_encdump_dualmode.log remap_ tablespace=users:encrypted_tbs table_exists_action=replace Import: Release 11.2.0.3.0 - Production on Thu Aug 30 17:10:39 2012 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. Username: system Password: Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production With the Partitioning and Oracle Label Security options Master table "SYSTEM"."SYS_IMPORT_FULL_01" successfully loaded/ unloaded. [oracle@nodeorcl1~]

How it works...

The encryption of dumps is controlled by the ENCRYPTION parameter. The possible values for this parameter are:

  • ENCRYPTED_COLUMNS_ONLY: The encrypted columns are exported to the dump file set in encrypted format
  • DATA_ONLY: All data is exported in encrypted format
  • METADATA_ONLY: All metadata is exported in encrypted format
  • ALL: All data and metadata is exported to the dump file set in encrypted format
  • NONE: Nothing is encrypted

The ENCRYPTION_MODE parameter controls the mode of encryption and may have the following values:

  • DUAL: This encrypts the dump using the wallet and the password provided by the ENCRYPTION_PASSWORD parameter. While importing the data, if you share the same master key as the source database then the password is not mandatory and the dump can be imported using master key decryption.
  • TRANSPARENT: This encrypts the dump using the master key within the wallet. The source database must have the same master key.

This mode can be combined with ENCRYPTION_PASSWORD. At import the password will be mandatory. In this way the data is encrypted using the password provided and the destination database might have another encryption master key.

While you import the data from a dump created in transparent mode, you have to ensure that your encryption wallet is opened at the destination database and contains the same encryption key.

Using encryption with RMAN

Database backups also represent a very important area to be defended. Similarly with data pump dumps, backups made with RMAN can be encrypted and decrypted using encryption wallets. In this recipe we will enable RMAN encryption. We will also make a full backup followed by a restore. Next, we will save and delete the encryption wallet, and try a restore and recovery. We also emphasize the importance of saving these keys in a safe place.

Getting ready

All steps will be performed on nodeorcl1.

How to do it...

  1. Create a new directory to be used as the destination for future backups with the oracle user as the owner:

    mkdir –p / backup/rman chown oracle:oinstall /backup/rman

  2. Connect with RMAN and enable the encryption of backups for the database as follows:

    [oracle@nodeorcl1~] rman target / RMAN> CONFIGURE ENCRYPTION FOR DATABASE ON; new RMAN configuration parameters: CONFIGURE ENCRYPTION FOR DATABASE ON; new RMAN configuration parameters are successfully stored RMAN>

  3. Perform a full database back up:

    RMAN> run 2> { allocate channel d1 device type disk format /backup/ rman/%U_%d_0_enc'; 3> backup incremental level 0 database; 4> backup archivelog all delete input; } using target database control file instead of recovery catalog …………………………………………………………………………………………………………………… ……………………………………………………… ………………………………………………………….. tag=TAG20120222T174122 comment=NONE channel d1: backup set complete, elapsed time: 00:01:25 channel d1: starting incremental level 0 datafile backup set channel d1: specifying datafile(s) in backup set including current control file in backup set including current SPFILE in backup set channel d1: starting piece 1 at 22-FEB-12 channel d1: finished piece 1 at 22-FEB-12 ……………………………………………………………………………………………………………………………… released channel: d1 RMAN>

  4. Shut down the database:

    RMAN> shutdown immediate database closed database dismounted Oracle instance shut down RMAN>

  5. Rename the wallet to ewallet_old:

    mv wallet ewallet_old

  6. Start up the database in mount mode and try to issue a database restore:

    RMAN> restore database; Starting restore at 22-FEB-12 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=133 device type=DISK channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set …………………………………………………………….. ORA-19913: unable to decrypt backup ORA-28365: wallet is not open

  7. Rename the wallet to ewallet and open it:

    mv ewallet_old wallet sqlplus / as sysdba SQL*Plus: Release 11.2.0.3.0 Production on Wed Feb 22 18:03:10 2012 Copyright (c) 1982, 2011, Oracle. All rights reserved. Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - Production With the Partitioning and Oracle Label Security options SQL> ALTER SYSTEM SET WALLET OPEN IDENTIFIED BY "UYio71+^ZaPO"; System altered.

  8. Now, you should be able to restore and recover your database:

    rman target / Recovery Manager: Release 11.2.0.3.0 - Production on Wed Feb 22 18:08:41 2012 Copyright (c) 1982, 2011, Oracle and/or its affiliates. All rights reserved. connected to target database: HCKDB (DBID=265134230, not open) RMAN> run 2> { restore database; 3> recover database; 4> alter database open; } Starting restore at 22-FEB-12 using target database control file instead of recovery catalog ………………………. Finished recover at 22-FEB-12 database opened RMAN>

How it works...

The encryption of backup sets is performed in the transparent mode using the encryption wallet. The mechanism is identical with the transparent mode used for data pump.

There's more...

Always try to save the master key in a safe place and do not include it along with your backup sets, an attacker who can open the encryption wallet (if it is of the auto-login type it does not require password) will be able to restore the database (by default RMAN does not backup set the master key). Without the appropriate database master key, it will be impossible to restore and recover your database from encrypted backups.

Resources for Article :



Further resources on this subject:


Books From Packt


Mastering Oracle Scheduler in Oracle 11g Databases
Mastering Oracle Scheduler in Oracle 11g Databases

Oracle Database 11g – Underground Advice for Database Administrators
Oracle Database 11g – Underground Advice for Database Administrators

Oracle 11g R1/R2 Real Application Clusters Essentials
Oracle 11g R1/R2 Real Application Clusters Essentials

Oracle 11g R1 / R2 Real Application Clusters Handbook
Oracle 11g R1 / R2 Real Application Clusters Handbook

Oracle 11g Streams Implementer's Guide
Oracle 11g Streams Implementer's Guide

Oracle GoldenGate 11g Implementer's guide
Oracle GoldenGate 11g Implementer's guide

Oracle ADF Enterprise Application Development—Made Simple
Oracle ADF Enterprise Application Development—Made Simple

 Oracle JDeveloper 11gR2 Cookbook
Oracle JDeveloper 11gR2 Cookbook


Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software