Encryption strategies in databases.
Boicea, Alexandru ; Ghita, Vlad ; Radulescu, Florin 等
1. INTRODUCTION
From source towards destination, data passes through one or more
intermediaries. Usually, messages across a network may be persistent for
some periods of time, from message queues to files or databases. Some
data within messages may be sensitive in nature, so its disclosure can
result in loss or damage, such as identity theft or criminal offenses.
Encryption is used to protect sensitive data inside a message.
Unencrypted data--plaintext--is converted to encrypted data--ciphertext.
Data is encrypted using a cryptographic key and an encryption algorithm,
making it unintelligible to parties other than the intended recipient.
At its destination, ciphertext is converted back to plaintext.
Encryption can be symmetric or asymmetric, but usually a mean solution
is used for data encryption: a symmetric algorithm is used to encrypt the message, then asymmetrically encrypt the shared key (Microsoft,
2005).
2. PLANNING A STRATEGY FOR DATABASE ENCRYPTION
Before starting designing a secure database encryption'
strategy, it is important to understand three things: how encryption
works, what is the data flow in the target application and how
database's encryption fits in the company's overall security
policy.
The encryption process may differ between situations. The security
of encrypted data depends on several factors such as the type of
algorithm used in encryption, the key size and the actual implementation
of the algorithm. There is a tension between security and access to
data; for example, a low security results in easy access to data--even
by unauthorized persons--but a high security may result in very hard
access--even by the authorized persons, like company's employees.
Encryption keys' management is also an important factor of
database security. (Oracle Corp., 2001).
In order to obtain a good management, the following questions
should be considered:
--Where will the keys be stored?
--How many keys are needed?
--Who will access the keys?
--How often will the keys be changed?
Furthermore, database encryption may be optimized even from the
beginning, depending on its way of implementation. In the following
sections we present two solutions of data encryption: encrypting the
data using DBMS facilities and encrypting the data outside DBMS, using
dedicated cryptographic servers (RSA Security Inc, 2002).
3. SOLUTION ONE--ENCRYPTING DATA WITHIN DBMS
While encryption within DBMS has a less impact on application
environment, there are some performance and security issues which must
be considered. Depending on algorithms and their implementation, the
encryption may degrade DBMS' performance. An inherent vulnerability
of this solution is the storing location of keys used in encryption;
they are often kept near the data, within a database table.
Encrypting data within DBMS is usually implemented as stored
procedures: before storing the data in database, an encryption procedure
is called; for decrypting the data, the reverse procedure is used. The
cryptographic procedures exist in DBMS as implemented by its vendors. In
Tab.1 are presented the pros and cons for this encryption strategy.
4. SOLUTION TWO--ENCRYPTING DATA OUTSIDE DBMS
Using this strategy in a client-server architecture, the sensitive
data will travel unencrypted within network in the shortest possible
time: encryption is performed by source application which introduce them
in the system, then data travels encrypted and will be stored in
database in an encrypted form. A reliable way to use this solution is by
creating a cryptographic server (further called Crypto Server or simply
CS) which will centralize the entire encryption process for database
environment. The administration and control tasks become easier for
complex applications with many databases. A great advantage of this
solution is the key management strategy, which is one of the safest. The
strategy implies separating the encryption keys by the encrypted data in
database: encrypted data are located at database server, while
encryption keys never leave the crypto server (RSA Security Inc., 2002).
All in all, this strategy provides higher security, better performance,
and also a lower cost of implementation--you can maximize the investment
by using one secure encryption solution across multiple applications and
lock down access to encryption keys. In Tab. 2 are presented pros and
cons for this encryption solution (Suse, 2000).
The cryptographic server is a specialized system used to centralize
the encryption process in complex database systems. Its task is to
dispose the database server with the overhead and performance
degradation involved in encryption process. The Crypto Server is
actually a new layer standing between application server and database
server. Data comes from application server and passes encrypted to the
database server. Also, there is a secured channel--usually SSL--between
application server and cryptographic server. At the client side (i.e.
application server), different levels of transparency could be
implemented, depending on the way the SQL query is built. For example,
the below queries are equal, but the second one forces CS to search for
the field in the internal repository and check its encryption status,
algorithm and keys used:
1. select decrypt(pwd, 'DES', ABCDEF1234567890) from
accounts;
2. selectpwdfrom accounts;
The main modules of Crypto Server are presented in Fig. 1.
[FIGURE 1 OMITTED]
* Client Connection Handler--this module manages the connection
with the application server; The Connection Listener waits for
connection requests and passes them to a Server Process
* Query Interpreter--is the "brain" of the system, being
able to make decisions on encrypted elements, algorithms and keys used,
based on analyzed SQL statements. The SQL Parser builds the tokens tree
and passes the query to the Optimizer. The last one finds out if an
element is encrypted or not, which algorithm and keys were used for
encryption (based on internal repository) and which way the query will
next follow.
* Repository--data and metadata storage location; is an internal
database of encrypted elements--fields, tables.
* Encryption Service--If an element is believed to be encrypted, it
will pass through an encryption/decryption process before being sent to
database server.
* Database Connector--handles connections to DB server.
5. CONCLUSIONS
Database security is a delicate subject but also a very important
one. Databases are a favorite target for attackers, just because of the
data they are containing. Therefore the strategy of security must cover
the entire system, starting with the physical layer to data
layer--network, server, application, data (Burtescu, 2009). The best
solution in database security is to keep performance degradation and
overhead caused by encryption service away from database, by using
specialized encryption machines, like cryptographic servers.
6. REFERENCES
Burtescu, Emil (2009) Database security: attacks and control
methods, JAQM Vol. 4 No. 4, Romania
Microsoft Corp. (2005) http://msdn.microsoft.com/en
us/library/aa480570.aspx, Accessed on 2010-05-10
Oracle Corp. (2001) Database Encryption in Oracle9i, An Oracle
Technical White Paper, USA
RSA Security Inc. (2002) Securing Data at Rest: Developing a
Database Encryption Strategy, DDES WP 0702, Ireland
Suse. (2000) Symmetric vs. Asymmetric Algorithms
http://www.suse.de/~garloff/Writings/mutt_gpg/node3.html Accessed on
2010-05-12
Tab. 1. Pros and Cons for DBMS encryption strategy
Pros Cons
Applications Extra processing = performance
are unaffected degradation
by encryption
system Encryption keys are stored near the
encrypted data
Encryption is
already Additional hardware is required to separate
integrated in the keys, which--purchased separately
many DBMSs
If keys protection is password-based, it is
insecure and difficult to manage
There is a limited choice of supported
algorithms
Tab. 2. Pros and Cons for Crypto Server encryption strategy
Pros Cons
Database server is unloaded Network overhead
with encryption processing
Needs to administrate more
Encryption keys are than one server
separated by data
Applications must be
Easy to implement strong modified in order to support
authentication methods the crypto server
Can separate roles for Must implement solutions for
administrators securing and monitoring the
crypto server
Much more control on users
accessing the data
Scalable--can work with
many applications and
databases
If DBMS doesn't include
encryption facilities, there is
no need to be replaced