Bloombase StoreSafe on Oracle
 Database encryption is a topic that easily ignites fierce discussions amongst enterprise management, business users and system administrators. Government agencies and financial institutes are mandated by national legislation and/or industry-wide information security standards to have their sensitive storage data secured from prying eyes, otherwise organizations and business owners are liable to prosecution, fines or contract annulment if sensitive customer data are ever exposed.
 |
With the pressure for confidential data protection on business owners, IT users and system adminstrators take an entirely different viewpoint and have intense objection to agreeing corporate operational data get encrypted. Enterprise core systems, for instance, enterprise and resource planning (ERP) and customers relation management (CRM) systems, are built on data servers typically database management systems. Relational databases benefit from high performance queries and accesses because of their structured design, file and storage systems performance optimization as well as the smart use of indexes. Implementing database encryption traditionally equals to change of schema, increased complexity to maintenance and worst of all, significant degradation in system performance, which are not welcomed by the user community. Positivity from business owners and negativity of users, system developers, administrators and operators on database privacy, results in endless debates not actual protection work done. |
Traditional Database Encryption
Oracle, the industry's defacto standard relational database management system (RDBMS), announced its obfuscation and cryptographic packages in the old days in form of pre-compiled stored procedure calls. Such procedure calls are for database developers' redevelopment of their existing application SQL functions to secure corporate sensitive data without the need to code into the details of cryptographic algorithms. However, obfuscation and cryptographic packages never gain their popularity
- Database schema needs to be altered to adapt to the encrypted binary data type, thus application codes need to be altered, and especially for off-the-shelf products, such are hardly be done
- Encrypted sensitive columns as query predicates result in poor performance range queries due to the fact that index sequence is broken after encryption
- Encryption key contents are required to be passed as input parameters to the cryptographic procedures in plain and usually hardcoded which heavily degrades the level of privacy of the system
- No key management options provided, applications need to manage their own keys
Oracle Transparent Database Encryption (TDE)
Oracle recently introduces Transparent Database Encryption (TDE) in Oracle 10g release candidate 2 with attempt to solve various technical problems with traditional way of database encryption, hoping to bring user and administrator communities out from the negative end of database encryption spectrum.
TDE claims no database schema needs to be changed. Therefore, off-the-shelf products can be entertained and indexed queries on encrypted columns will no longer be a performance concern. Instead of just cryptographic APIs are provided, TDE claims to work completely transparent at the data server during read/write where actual encryption and decryption are carried out without users nor database developers' attention. |
 |
Bloombase StoreSafe enterprise storage encryptor secures database repositories at storage level supporting virtually all enterprise applications with persistence layer built on filesystems and/or general-purpose storage devices. Bloombase StoreSafe secures storage data at complete application transparency. With similar claims from TDE offered by Oracle's 10g RC2, what is the core competancy of Bloombase StoreSafe?
The quick answer is - Performance.
Query Performance Tests
To compare query performance of both Oracle TDE and Bloombase StoreSafe encrypted data, the following schema mimicking a typical financial database holding credit card information is created
create table CARD_HOLDER (
ID numeric(20) null,
NAME varchar(255) null,
ADDR1 varchar(255) null,
ADDR2 varchar(255) null,
ADDR3 varchar(255) null,
ADDR4 varchar(255) null,
CITY varchar(255) null,
COUNTRY varchar(255) null,
GENDER varchar(1) null,
AGE int null,
PHONE varchar(255) null
);
create table CREDIT_CARD (
CARD_HOLDER_ID numeric(20) null,
NUM numeric(16) null,
CHECK_CODE numeric(3) null,
EXPIRY_MONTH numeric(2) null,
EXPIRY_YEAR numeric(2) null
);
|
|
To faciliate queries in its daily usage, the following indexes are built
create index CARD_HOLDERI1 on CARD_HOLDER (ID);
create index CARD_HOLDERI2 on CARD_HOLDER (NAME);
create index CARD_HOLDERI3 on CARD_HOLDER (GENDER);
create index CARD_HOLDERI4 on CARD_HOLDER (AGE);
create index CREDIT_CARDI1 on CREDIT_CARD (CARD_HOLDER_ID);
create index CREDIT_CARDI2 on CREDIT_CARD (NUM);
create index CREDIT_CARDI3 on CREDIT_CARD (EXPIRY_MONTH);
create index CREDIT_CARDI4 on CREDIT_CARD (EXPIRY_YEAR);
|
|
Both tables are created on the same tablespace file which are encrypted by Bloombase StoreSafe using AES 256 bit cryptographic cipher.
Whereas for Oracle TDE's setup, a TDE wallet is first created
alter system set key identified by "welcome1";
|
|
Open the TDE wallet
alter system set wallet open identified by "welcome1";
|
|
Database schema are then created on a separate tablespace file using the following commands together with same indexes built
create table CARD_HOLDER (
ID numeric(20) null,
NAME varchar(255) encrypt no salt,
ADDR1 varchar(255) encrypt,
ADDR2 varchar(255) encrypt,
ADDR3 varchar(255) encrypt,
ADDR4 varchar(255) encrypt,
CITY varchar(255) encrypt,
COUNTRY varchar(255) encrypt,
GENDER varchar(1) encrypt no salt,
AGE int encrypt no salt,
PHONE varchar(255) encrypt
);
create table CREDIT_CARD (
CARD_HOLDER_ID numeric(20) null,
NUM numeric(16) encrypt no salt,
CHECK_CODE numeric(3) encrypt,
EXPIRY_MONTH numeric(2) encrypt no salt,
EXPIRY_YEAR numeric(2) encrypt no salt
);
|
|
Similarly, the same set of indexes for case of Bloombase StoreSafe are created.
A million (1,000,000) sample credit card and card holder information are populated into both databases. Three typical queries are run to measure and compare the performance for both encrypted databases
- Query by card holder name
set time off echo on feedback on autotrace off
timing start
select * from
(select *
from CARD_HOLDER, CREDIT_CARD
where CARD_HOLDER.ID = CREDIT_CARD.CARD_HOLDER_ID
and CARD_HOLDER.NAME >= 'Louis the 999%'
order by CARD_HOLDER.NAME, CREDIT_CARD.NUM
asc)
where ROWNUM <= 10;
timing stop
|
|
- Query by age and gender group
set time off echo on feedback on autotrace off
timing start
select * from
(select *
from CARD_HOLDER, CREDIT_CARD
where CARD_HOLDER.ID = CREDIT_CARD.CARD_HOLDER_ID
and CARD_HOLDER.GENDER = 'F'
and CARD_HOLDER.AGE >= 28
and CARD_HOLDER.AGE <= 30
order by CARD_HOLDER.NAME, CREDIT_CARD.NUM
asc)
where ROWNUM <= 10;
timing stop
|
|
set time off echo on feedback on autotrace off
timing start
select * from
(select *
from CARD_HOLDER, CREDIT_CARD
where CARD_HOLDER.ID = CREDIT_CARD.CARD_HOLDER_ID
and CREDIT_CARD.EXPIRY_MONTH < '03'
and CREDIT_CARD.EXPIRY_YEAR < '01'
order by CARD_HOLDER.NAME, CREDIT_CARD.NUM
asc)
where ROWNUM <= 10;
timing stop |
|
The queries are run and their query elapse times recorded and summarized as follows
| |
Query 1 (sec) |
Query 2 (sec) |
Query 3 (sec) |
| Plain |
1.20
|
1.50
|
1.30
|
| Bloombase StoreSafe |
1.60 |
2.00 |
1.60 |
|
The results suggest Bloombase StoreSafe protected Oracle database has only slightly less performance than without encyprtion.
| |
Query 1 Elapse Change (%) |
Query 2 Elapse Change (%) |
Query 3 Elapse Change (%) |
| Bloombase StoreSafe vs Plain |
33.33 |
33.33 |
23.08 |
|
Oracle database encryption implemented using Bloombase StoreSafe results in a maximum increase of query processing time at 33.33%.
Relative throughputs are plotted against the queries as in below visual. Note the slight drop of throughput for Bloombase StoreSafe against plain.
Key Management
|
Oracle TDE's encryption key is stored as a PKCS#12 compliant key vault file on, again, filesystem which may reside on the same physical media storing the sensitive corporate data. Oracle TDE's wallet is a master key used to open an encrypted table key stored inside the same database file which actually encrypts the the secret data. Wallets can be archived as normal files on magnetic media for offsite.
Whereas for Bloombase StoreSafe, key management is done with ease using bundled KeyCastle via an SSL-secured user-friendly web-based console.
|
For systems where key security is of top priority, PKCS#11-compliant hardware security module can be used to store the key safely which is supported by Bloombase StoreSafe and can be managed by KeyCastle web-based key management console as well.
An All Purpose Generic Persistence Data Security Platform
Oracle TDE is ONLY available as a bundled option for version 10g RC2 instead of an independent pluggable add-on module. Therefore, systems running previous versions of Oracle can hardly enjoy TDE without upgrading their Oracle data server plus migrating their data files, as well as possibly their application architecture.
Enterprise data systems always span across RDBMS and beyond, for instance, file system, proprietary content repository, and raw volumes, etc. Sensitive data stored in databases which need to be protected might also available in its plain form in other persistence sub-systems, whereas the same rule applies - privacy.
Oracle TDE serves structured data stored in Oracle databases only without addressing privacy issues on the rest of enterprise data sub-systems. Bloombase StoreSafe is an all-purpose and generic storage encryption solution powering secure persistence data in virtually all storage sub-systems.
For more information about this test, please contact us at sales@bloombase.com
|
