CS4235A – Fall 2006

Final Project

Database Encryption

Friday, November 17, 2006

Matt Schulze Ishita PatelZaheer Ahmed Brandy Gallien

Muhammad Ahsan Hussain

INDEX

I. Introduction

II. Algorithm Analysis

III. Performance Analysis

IV. Implementation

V. Software Packages

VI. References

I. Introduction

It has been said that most of the sensitive data maintained by enterprises is not encrypted.

However, the advent of e-commerce and the large number of information-stealing attacks

that have been witnessed over recent years have greatly changed the information climate.

Tougher, stricter laws on reporting security breaches have coupled with an ever-

increasing likelihood of attack (and the increased sensitivity of information that comes

with e-commerce) to stress the importance of total data security. [2] Since most of the

highly-sensitive data within enterprises is managed through the use of databases, securing

these databases must be a part of any enterprise’s efforts to crack down on data breaches.

Encryption of these databases plays a major part in guaranteeing that information will not

be accessed without proper authorization.

While there are many different algorithms with which the actual obfuscation of

the data may be done, a fundamental decision must be made first. Will the data in our

database be encrypted together (called file or table encryption), or separately (row or

column-level encryption)? For the purposes of this discussion, we will limit our

inspection to file and column encryption. Row encryption is less implemented in

practice, and is focused on providing a more individualized form of security than we are

interested in exploring here. Each strategy has its advantages and disadvantages, and

selecting between them requires careful consideration. We will first explore the two

options before attempting to decide between them. Afterwards, we will consider the

implementation of database encryption.

II. Algorithm Analysis

File Encryption

File encryption is as straightforward as it sounds; entire database files are encrypted at the

file level and stored in that fashion. It is the simplest means of database encryption, as it

takes no special measures to encrypt a database beyond what would be taken to encrypt

any other data. However, its simplicity comes at a price. The rigid demands and narrow

focus of most full file encryption methods require the use of external resources (both

software and personal) in order to affect the security of the database in a measurable way.

Firstly, it must be noted that file encryption alone only stops unauthorized users

from accessing the database. Because file encryption uses a single key (or key set) in

encrypting the entire database, a user with the right to access the database (such as a

database administrator) will have the key to decrypt the entire database. But, even if a

user has the right to access the database, there is often information within the database

that the said user has no need (or right) to access. Due to this reason, access control

mechanisms are necessary to limit the access of authorized users to the sensitive data.

The simplicity of this method also results in unnecessary rigidity. If everything

does not need to be encrypted or the items needing encryption are distributed throughout

many documents, the database manager may have to perform time-consuming data

manipulations in order to accumulate data before encryption. For instance, the database

administrator may need to copy all sensitive data into one file (and remove instances of

this data from other files). He may also need to move whole tables across pre-arranged

tablespaces and filegroups in order to satisfy the requirements of the file encryption

algorithm chosen. Applications using such databases may need to be reconfigured for the

new arrangements. [1] In essence, the simplicity of the algorithm is often countered by

the difficulty of arranging the data in a manner that will fit the rigid algorithm.

Significantly large databases encounter additional problems with the performance

of this algorithm. Much of this will be discussed later in the paper, but it is sufficient for

now to understand that much processing power and time will be lost while encrypting and

decrypting non-sensitive data.

Column Encryption

As opposed to full file encryption, column encryption gives the database manager the

ability to encrypt only the columns that contain sensitive data. If desired, different

columns can have separate keys, so that a user with access to one sensitive column does

not necessarily have access to others. It is a form of access control inherent within

column encryption, since users without a certain column’s key cannot access that

column’s information. However, column encryption can also be implemented in

conjunction with other access control methods for better monitoring and control of user

behavior.

For example, a user may be able to query the database about certain sensitive data

columns (like the average income of all the employees); the access control system may be

configured to allow such queries. At the same time, the user may find he is unable to

directly access information about any particular employee’s income because he does not

have access to the key to decrypt the data. In this way, fine-tuned controls can be

engineered through the use of encryption and access control software. Just as file

encryption’s simplicity led to excess rigidity, column encryption’s flexibility comes with

the trade-off of complication. Due to the large number of details that must be handled

within the algorithm, selecting the wrong algorithm could result in significant problems

with database performance.

If a database is typed, then it is possible that having encrypted columns will

require the datatypes assigned to certain columns to change. For instance, encrypted

numeric values may not, and probably will not, be strictly numeric anymore. Anything

referencing those columns will need to be modified accordingly. Though many column-

level solutions have automated changes like these, it should be noted that this could

require significant changes to the database schema. In short, database structure may be

changed, and applications may need to be modified to acknowledge this change.

With column encryption, cryptographic time is not a key factor due to a

significantly lower volume of data manipulation. While this is a good thing, it also

increases the influence of other factors on the algorithm. In particular, the mechanisms

used for intercepting and redirecting data requests to account for the encryption of a

column must be carefully inspected, for they could have a severe effect on the

performance of the database. This topic will be discussed further in the performance

section, but for now it should be noted that issues like encrypted or decrypted caching of

table entries could have a heavy influence on the performance of the database (and also

carry tradeoffs that further complicate the matter).[2]

Depending on the style of encryption, column level encryption may also have an

effect on the indexing capabilities of a database since the user may query the encrypted

data. If the encryption is performed such that easy sorting is not possible, simple

indexing would become extremely complex, perhaps even impossible. Many advanced

column-level solutions on the market offer solutions to this problem, however the

overhead associated with these solutions should not be overlooked.

Lessening the Problems

Many of the problems associated with the above mentioned methods of encryption, if

ignored, could be catastrophic for a database’s security and/or performance. Some of

these issues could be resolved, for example, by incorporating access control software

with file encryption solutions to lower the need for external applications. Bundling this

software with the file encryption algorithm would lead to a more comprehensive solution.

It is also possible to have a column encryption solution where the client performs

all the decryption and encryption. Since the database would never hold unencrypted data,

this would eliminate the chance of insecure plaintext ever being located, and also reduce

the amount of database processing power required. Such a method would greatly

decrease the workload on the server, and should have a significant effect on performance.

[3] However, such an action would also heavily complicate the process behind certain

database queries. If certain information within the query could not be encrypted into a

comparable form, it would seem to be difficult or impossible to execute such queries

without giving the entire database over to the client and having them answer their own

question. Since no research was found exploring the effect on the querying process,

however, this is purely speculation.

Another possible improvement would involve operations which are less time

consuming than encryption. For example, a solution could encrypt the first data block,

and then XOR each subsequent block with the previous block. This method could

significantly increase the speed of decryption, since an XOR would likely be executed

faster in any computer architecture than most decryption methods would be. Combined

with the previous example (all cryptography done on the client side), research shows that

the total execution time of the encryption process was reduced by “about 10-40%,

depending [on] the image size”.[3]

III. Performance Analysis

All commercial-level databases currently provide column-level encryption, but this still

requires the database administrator to associate controls onto the columns. This paves

way for only authenticated users to access database columns. Now we can either go for

column-level encryption or for column access control. Column-level encryption allows

for anyone who has the key to be able to access the data where as for column level access

control, each column can only be accessed by whoever has access to that particular set of

data whether it is encrypted or not. We have seen that in terms of security there is no

difference between column-level encryption and column level access control. Column

level access control allows us to protect the data within our database.

Column-level encryption is mostly used to prevent the database administrator

from accessing sensitive information, but here the issue is that the Database

Administrators (DBAS) do not require encryption keys to view data. [2] This means that

someone posing as a Database Administrator can easily alter the password provided to

access the encryption key to the column-level encryption. Unencrypted data meant for

authorized users can be intercepted and stored in separate tables to be viewed later. Since

we know that encryption uses triggers and stored procedures, sensitive data is extremely

vulnerable to such man-in-the-middle attacks.

Encryption at the column level adds an overhead; however it is important to

realize that the overhead depends not on the total data encrypted but on the mechanism

with which this data is modified – the stored procedure. The performance related issues

are not because of cryptography use, but mostly due to the use of stored procedures in

order to insert this data into the database.

Column-level encryption might require calling a stored procedure that could

“require API calls outside the database server”.[4] This form of encryption would

“require a network round trip to perform the cryptography operation on a hardware box”

(Mark, p. 1). This is quite slower when compared to basic cryptographic operations due

to network and processor delays. “Each of these steps to hook into the database cause

substantial performance penalties that may be many times larger than the actual

cryptographic operation” (Vormetric, p. 3).

Performance in not only affected by “insertion point” (Vormetric, p. 3) in the

column-level encryption, but also by how well the database cache is tuned and by the

indexing of the database. When the encrypted data is selected by a query and stored into a

database cache, it is left encrypted. As a result, we don’t get any performance benefits

since the data should be decrypted first. When an encrypted column is selected through

the where-clause, we go through the whole table and not just the encrypted column. This

severely retards the performance of column-level encryption.

While both file-level and column-level encryption impact the performance,

column-level encryption can retard the performance on much larger scale when compared

to file-level encryption. The reason for this is that column-level encryption requires API

calls to the hardware box. Since this is outside the database, performance is severely

affected. It is not uncommon for a column-level encryption to significantly increase the

CPU consumption.

In terms of integrating with the rest of the system and other existing applications,

file level encryption (the encryption layer above the file system) proves to be a much

better solution when compared to column-level encryption. This is because of its relative

decoupling from the database. With file-level encryption there is no need to worry about

changes in the database schema or the modifications in the network or applications

because of this independence. On the other hand, integration of a column-level

encryption might require changes to the database and to other associated applications. For

third-party applications, this might not even be an option because of the lack of such

support by the vendor.

While companies store most of their data inside the databases, some sensitive data

might also reside in additional storage. This is where column-level encryption could lead

to problems because it encrypts data inside the database. Most companies store large

amounts of data in flat files. Column-level encryption would not be feasible for such

solutions because it only applies to a single column of the file. Transactions and

debugging logs often contain cardholder data that cannot be supported by column-level

encryption.

IV. Implementation

In general, encryption is implemented after the access controls are in place. Encryption is

essentially a safeguard against the breach of access controls. Most attacks in the network

space occur on workstations, where data sits for long periods of time such as in the case

of a database which highlights the necessity for a well developed database encryption

solution. The most important aspect of such a solution lies with the issue of what data

exactly should be encrypted within the bounds of the database. Database lookups are

designed to be very efficient. Unlike typical file systems, databases are expected to look

through millions of tables searching for specific queries in seconds. This need for fast

access and retrieval places additional hardships on encrypting databases. A database

cannot afford to encrypt and decrypt each piece of data it must search. Therefore, it is

critical to properly plan encryption based on how an application will use the database.

Some of the more commonly implemented solutions are discussed below:

Encrypting all columns

If all the columns are encrypted in a database, then if a specific data field is queried

for, the entire column will need to be decrypted before obtaining the data field. This

will result in a huge amount of overhead. A similar situation will be encountered

when updating the database as well. However, no such issues would be incurred

while inserting to the table. Such a solution may be applicable for small databases,

but in case of large growing databases, cryptographic functions will be performed

every time the database is accessed, which is highly inefficient due to the high access

times and overheads involved.

Encrypting all but one column

In such a case, when the database is queried for a specific data field from the non-

encrypted column, then decryption is not performed by the engine until the actual row

that matches the selection criteria is located. The overhead time encountered due to

encryption has been drastically reduced in this case since the decryption of the rows

causes minimal overhead as compared to the earlier implementation. However, in

cases where the query depends on the encrypted fields, a similar overhead and timing

latency will be noticed. Hence, the non-encrypted column should be chosen

strategically to minimize overhead and query response times.

Encrypting only the most sensitive data column

If only column with the most sensitive data is encrypted, then it would vastly reduce

the chance of slow query responses due to decryption. The only significant

performance degradation would occur if the database’s query processor decided that

searching that particular column would give the most efficient search result. Such a

case would occur only when a query string contained only that particular column and

nothing else.

Before actually deciding which columns to encrypt, you should first gather a list of the

most common statements executed against the database. Most large applications are

highly dependent on a handful of queries. Analyzing the use and frequency of SQL

statements helps to reach an informed decision on how encrypting a particular column

will affect performance. Certain retail solutions such as Ingrian Networks Inc.'s “Ingrian

i321 DataSecure Appliance” can transparently and selectively encrypt specific columns

in a database and make them unreadable to employees who do not have the proper

security authorization. [5]

Key Management

When considering any encryption solution, key management is an extremely important

factor. Strong considerations should be given to how keys are accessed, how they’re

distributed and managed, where they are located, how they can be backed up and

recovered, and finally how data integrity can be ensured. Most file encryption solutions

today have some form of centralized key management, but keys are relocated to the host

for encrypting and decrypting the database. Storing the symmetric data encryption keys

in the database significantly reduces the overall security of the solution. The keys can be

comprised easily by most simple attacks on the host endangering the entire database.

Having the encryption keys reside in the same place as the data that these keys are

meant to protect is highly discouraged by most security professionals. In the more

advanced column level encryption solutions, the keys are not allowed to leave the secure

hardware platform. This allows security administrators to better manage keys and policy

from a centralized location, creating a true security and monitoring solution. This also

enables enterprises to enforce true separation of staff duties by enabling security

administrators to control keys, users, groups, and policy whereas a database administrator

is effectively for all purposes a user of the encryption capabilities of the database. [6]

Some commonly implemented key management solutions include:

Key(s) can be stored in a strongly encrypted file (called a Profile) on the local storage

drive for easy and prompt access.

Key(s) can be stored in a Profile on a floppy disk, CD or USB key. The authorized

user must insert the floppy disk, CD or USB key in order to start the database.

Key(s) can be stored in a Profile on a remote machine (Proxy location). If the “Proxy”

machine is not found, the database will not initialize.

Key(s) can be embedded into the application with an API call.

Public Key Infrastructure implementation for distributing keys. [7]

Authentication and Auditing

Data encryption is only one part of the security puzzle. Without the proper authentication,

authorization, and auditing mechanisms, encryption fails to add anything to the security

aspect of the solution in place. File level security and auditing is extremely valuable

when dealing with files that are accessed directly by end users. However, data within a

database is accessed by end users either through front end applications or third party

database query tools that directly interface with the database.[8] The database files are

accessed by the service id or service account used to run the database server. Encryption

at the file level provides the ability to control and audit the actions of the service account

utilized. However, there is no way to control the database users who are actively

accessing the data within the database.

While file encryption fails to even complement the native security mechanisms of

a database server, column-level encryption takes existing security controls one step

further and helps to complement the other aspects of security controls in place. By

implementing authentication, authorization, and auditing measures at the column level, it

is possible to significantly increase security. For example, access can be granted at a

more modular level; two database users may have the rights to execute select queries on

the same table, but only one of the users can decrypt the encrypted columns. Auditing

goes further and allows any operation performed with sensitive data to be recorded. For

example, in a financial enterprise scenario, one will have the ability to know exactly how

many credit cards were decrypted, by which database users, from which tables and

columns, and at what times. Advanced authorization policies can be built around the

audit data including rate and time limiting. Column-level encryption also allows for

monitoring of database users activities. If a user is authorized to decrypt social security

numbers, you want to make sure they don’t walk out the door with all of the social

security numbers decrypted. Hence, the extent of authorization and auditing required by

the database and its underlying security controls also plays a big role in determining the

particular encryption solution to be deployed. [1]

Encryption Implementation

There are two forms of implementing any method of database encryption - the use of an

integrated encryption package in the database software, and the use of a third-party tool

as a wrapper to encrypt data when it is entered into specific columns or tables. Due to the

strength of database encryption as an information security tool, it is extremely common to

find first-party utilities included in database packages such as the Oracle 10g software

and Microsoft SQL Server 2005 [10] . Applying these built-in encryption packages to

currently existing databases is not usually a very difficult task - for example, after setting

up a wallet table to store encryption keys, one can encrypt a column in a Oracle 10g table

simply by making the call "alter table tablename modify (columnname encrypt);" [9].

Many of these recent implementations also are transparent to or can be made transparent

to applications using the database - the data returned from queries is returned

unencrypted, thus avoiding further alteration of existing software.

Unfortunately, these first-party solutions are far from perfect. If one is in the

possession of older database software, it is likely that the only encryption options will be

either DES or triple-DES, both of which have been superseded by AES and other, more

modern encryption systems [12]. This lack of more modern encryption standards may

leave data vulnerable even though the table has been encrypted and is believed safe.

More modern systems such as the latest MySQL release do implement the newer

standard. The key size used is completely database-dependent - MySQL defaults to 128

bit keys and can be raised to 256 bits should the source code be modified, while Oracle

10g has the built-in capability for 128, 192, and 256-bit AES keys [11] [12].

Often the keys for table and column encryption are stored somewhere in the

database itself, such as Oracle 10g's Wallet object, where they may be vulnerable to

attack by either database administrators or individuals posing as database administrators

[13]. The lack of encryption options and separate tables make these first-party tools

recommended mostly to individuals with recent database software, good administrator

training, and a large number of applications dependent on receiving plaintext data from

the database.

Actual implementation of integrated encryption solutions may prove more

difficult than attaching a third-party tool as an overlay. In MySQL, for example,

encrypting and decrypting table data requires making direct calls to the appropriate

function with a key whenever data is to be encrypted; routines to auto-encrypt data on

insertion and auto-decrypt on selection must be implemented by the user, and the burden

of key creation and management is completely on the end user [11]. This provides a great

deal of flexibility, but also poses a burden on the user to have a strong understanding of

database security concepts.

The production of third-party tools to provide databases with encrypted column

information or to wrap the entire database file in an encrypted block is a rather large

business. These tools, such as provide a large suite of encryption options - for example

the DbEncrypt product can provide data encrypted with AES, DES, Triple DES,

Blowfish, Twofish, RC2 and RC4 compatible algorithms, Serpent, CAST128 and

CAST256, and Skipjack [13]. This variety allows users who are looking to optimize

speed or security to have a broad spectrum of options from which to select. As these

programs are not integrated into the database, it is possible to store key data in a separate

location, thus adding another layer of security and preventing compromise of database

files leading inevitably to compromise of encrypted database data. Some third-party

wrappers offer transparency to database-accessing software; it is highly advised to select

software with this feature to avoid rewriting or abandoning existing tools that require

plaintext from the database.

There exist a few downsides to the versatility and additional security of these

third-party tools, however. The first is cost: integrated database encryption comes with

the software, but many of the third-party solutions require a non-trivial investment for

purchase, for service or license fees, and possibly for an expanded range of encryption

algorithms. Non-transparent third-party solutions have the potential to break database and

application communication links, which may cause massive problems until the

applications have been modified to work with the new solution.

Application-layer encryption referring to the use of third-party encryption tools

requires rewrite of existing custom extended API based applications which is highly

impractical in most cases due to limited IT resources, lack of access to source code, or the

lack of familiarity with the old code. Rewriting applications is also very costly and

introduces an implementation time delay factor. Also, all applications that access the

encrypted data must also be changed to support the encryption and decryption model.

These third-party tools are recommended for concerns seeking a broad spectrum

of encryption options and concerns currently owning older database software that does

not support more modern methods of encryption. The costs to purchase a low- to mid-end

third party tool are likely significantly lower than paying for a complete database

upgrade, and upgrading security from DES to AES is very much a worthwhile goal due to

the significantly greater strength of AES encryption.

V. Software Packages

Column Level Security:

1) Encryption Wizard for Oracle

This tool is exclusively designed for Oracle Relational Database Management

Systems (RDBMS). It encrypts the data that resides within the database through an easy-

to-use Java interface. It is the only database encryption package that allows the

encryption of data at the schema level, the table level and the column level. This tool is

resident in the DBMS_Crypto and DBMS_Obfuscation_Toolkit packages.[14] The

wizard uses single key encryption and then stores the key in the Oracle database using

the Triple DES encryption algorithm. The key is either user specified or system

generated. Supported data types are character, date, integer, and large binary objects. The

Encryption Wizard for Oracle allows excellent system recovery in case of cryptographic

failures. It will self-diagnose incomplete encryption operations and allows an

administrator to finish the process later. [15]. The Encryption Wizard for Oracle uses

encryption key caching technology for fast encryption. It also uses a restricted user list

and optional authentication for the purpose of security. Encryption Wizard for Oracle is a

platform- independent solution that can be implemented on any operating system.

Requirements:

Oracle RDBMS versions 8.1.6 and above

Supports Unix, Linux or Windows environment

Wizard supports JRE 1.3 or higher

2) SecureDB

SecureDB provides security at the column level. This package provides a cost

effective deployment option requiring minimal changes at the application level. Its use of

column level encryption not only protects the data from external attacks, but also

provides access control for authorized users. SecureDB combines multiple levels of

authentication for role-based users to provide fine-grained control over encryption and

decryption of data elements. This level of control delivers separation of duty, ensuring

there are no super-users. SecureDB consists of the centralized management console and

lightweight database security adapters installed on the database server. “The system

architecture is designed to manage multiple database types, ensuring that your investment

in database security for one database vendor is leveraged to achieve the same level of

security for another database type.”[16] SecureDB supports the deployment of nCipher’s

Hardware Security Modules (HSM) for robust key management, which provides the

security, manageability, and scalability for the stored key [16].

System requirements:Operating Systems:

Windows NT Windows 2000/XP Windows 2003 20 MB free disk space Oracle Net8 Client nShield HSM support

Design for Secure DB:[4]

3) Table/File level encryption:

Cryptfs: A Stackable Vnode Level Encryption File System:

Cryptfs uses the concept of encapsulation to build a client file system with a

transparent layer of encryption. “It can operate on any native file system. As it is the

resident in the kernel, Cryptfs performs better than user-level file based server such as

Cryptographic File System for Unix”.[17] This also reduces the number of the context

switches and runs in privileged mode or user level mode and thus increases the

performance speed.

Cryptfs is implemented as a stackable vnode interface as shown in the figure1.

Vnode is short for “virtual node”, a data structure in the UNIX operating system which

represents open file, directories, devices, or other entities.

As shown in the figure1, system calls are translated into virtual node level calls

and invoke their cryptfs equivalent. This invokes the generic vnode operation which calls

the respective lower level file system. Key management is done by providing the root

user the authority to mount instances of cryptfs. Cryptfs is the encryption layer on top of

the file system. However the user does not have the authority to encrypt or decrypt files.

Cryptfs manages keys in the memory data structure that are associated not only with the

user id of the root user, but with the combination of userID and sessionID. Even if the

attacker manages to get the appropriate userID, he/she has to figure out the sessionID

which is system generated. [17]

VI. References

[1] "Database Encryption: Evaluating File Versus Column Level Approaches." 2005. Ingrian Networks. http://techfinder.vnunet.com/shared/write/vnu/collateral/WTP/10000000220_88372_11290_49752_76105_02413_Ing2.pdf?ksi=10000009915&ksc=21259910666.

[2] "Database Encryption Vormetric CoreGuard Vs. Column Level Approaches."Vormetric Inc. 09 Dec. 2005. 14 Nov. 2006 <http://www.vormetric.com/documents/FINALPart2DatabaseEncryptionCoreGuardvsColumnLevelWhitePaper7.pdf>.

[3] Sien, Ooi B., Azman Samsudin, and Rahmat Budiarto. "A New Image-Database Encryption Based on a Hybrid Approach of Data-At-Rest and Data-in-Motion Encryption Protocol." IEEExplore. 23 Apr. 2004. School of Computer Science, Universiti Sains Malaysia.http://ieeexplore.ieee.org.gtel.gatech.edu:2048/iel5/9145/29024/01307907.pdf?tp=&arnumber=1307907&isnumber=29024

[4] Mark, Heather. "File Level Encryption and PCI Compliance." Transaction World. 29 Dec. 2005. Director of Industry Marketing, Vormetric Inc. 15 Nov. 2006 <http://www.transactionworld.com/>.

[5] Newman, Aaron C. "Encryption of Data At Rest." IT Toolbox. 28 May 2002. Application Security, Inc (ASI). <http://database.ittoolbox.com/white-papers/encryption-of-data-at-rest-1922>.

[6] "Employing Encryption to Secure Consumer Data: a Best Practices Guide for Retailers." The Inquirer. Jan. 2006. Ingrian Networks. <http://techfinder.theinquirer.net/vnuinquirer/search/viewabstract/100000610/index.jsp>.

[7] "SQL Server Security." Netlib. <www.netlib.com/sql-server-security.shtml>.

[8] "The Case for Encryption." Eweek. <www.eweek.com/article2/0,1895,1848652,00.asp>.

[9] "Application Security Inc. - DbEncrypt - Database Encryption for the Enterprise" Application Security, Inc. http://www.appsecinc.com/products/dbencrypt/oracle/algorithms.shtml (11. November 2006).

[10] Foster, James C. "Look before leaping into database encryption" SearchSecurity.com http://searchsecurity.techtarget.com/tip/0,289483,sid14_gci1219561,00.html (11. November 2006).

[11] "MySQL AB:: MySQL 5.0 Reference Manual :: 12.9.2 Encryption and Compression Functions" MySQL AB http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html (11. November 2006).

[12] Nanda, Arup. "DBAzine.com: Protect from Prying Eyes: Encryption in Oracle 10g, Part 1" DBAzine.com http://www.dbazine.com/olc/olc-articles/nanda11 (10. November 2006).

[13] "Security: Transparent Data Encryption" Oracle.comhttp://www.oracle.com/technology/oramag/oracle/05-sep/o55security.html (10. November 2006).

[14] “IBM Data Encryption for IMS and DB2 Databases”. IBM Software Management. 09/16/2006. <http://www306.ibm.com/software/data/db2imstools/db2tools/ibmencrypt.html>

[15] “Encryption Wizards for Oracle.” Relational Database for Consultant, Inc.

11/16/2006.< http://www.relationalwizards.com/html/ora_encyrption.html>

[16]“Column Level Database Encryption Secured by nCIPHER”.nCIPHER.May 2005. Access Date: 11/16/06. < www.papertrail.co.za/sa/nc_securedb.pdf>

[17] Erez Zadok, Ion Badulescu, and Alex Shender. “Cryptfs: A Stackable Vnode Encryption File level System.” 1998. Access Date: 11/16/2006. < www.am-utils.org/docs/cryptfs/cryptfs.html>