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:

Operating system proprietary filesystem or block-based encryption
Cryptographic API, especially DBMS_CRYPTO used for column encryption
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...

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:

[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.

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]#

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

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]#

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
```
The mapper-device /dev/mapper/storage can be mounted as a normal device:
```
[root@nodeorcl1 storage]# mount /dev/mapper/storage /storage
```
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
```
Add the complete mapper-device path, mount point, and filesystem type in /etc/fstab as follows:
```
/dev/mapper/storage /storage                              
ext4    defaults        1 2 
```

Reboot the system:

[root@nodeorcl1 storage]# shutdown –r now

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.

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%]

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
```

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]#

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 ~]$

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

Next as root unmount /ecryptedfiles as follows:

[root@nodeorcl1 /]# unmount /ecryptedfiles/

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'ŉ□□R□□□□□siP □b □`)3 □W □W( □□□□c!□□8□E.1'□R□7bmhIN□□--(15%) ………………………………………………………………………………………………………………………………….

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.