Chapter 13: Database Encryption

Many people think security is encryption and encryption is security. Encrypt it and it is secure, where “it” applies to anything and everything. This is a fallacy. Encryption is a critical element to security, but it plays different roles in different situations. For networks, encryption is a major part of the overall security. With databases, encryption is another layer of security defense, and you have to use it wisely; otherwise, you risk a zero increase in overall security and possibly a decrease in performance, usability, and accessibility; worst of all, you create a false sense of security.

This chapter evaluates the use of database encryption with Oracle’s new DBMS_CRYPTO package. This package, which replaces the DBMS_OBFUSCATION_TOOLKIT, provides significantly enhanced capabilities for encrypting, message authentication codes) of database data, all without leaving the confines of the secure database environment. Overall, encryption will be analyzed to determine when it’s an appropriate tool and when it’s not. You’ll look at examples of how to invoke encryption, explore the challenges and issues associated with it, and review how to really use the encryption capabilities with some database encryption best practices.

Encryption 101

Encryption has an interesting history. It dates back thousands of years and can even be traced to the Roman Empire. At that time, it was common for Julius Caesar, who was acting President and CEO of the Roman Empire, to send messages to his generals in the field. The messages were very sensitive because they gave orders on how to proceed on new military objectives.

The messages were sent by way of a messenger and there was a great risk that the messenger would be captured before the message was delivered. This seriously jeopardized the military strategy. As such, a simple encryption algorithm was devised and used to encrypt the messages. Only the generals and Julius Caesar knew how to encrypt and decrypt the messages. If the messenger was captured, bribery, persuasive arguments, or torturing techniques were ineffective in uncovering the content of the encrypted messages.

This helps to put the use of encryption into proper perspective. It’s important to understand the basic problem that encryption was designed to solve. Encryption provides protection of sensitive data for an unprotected medium. The messages represented sensitive data, and the messengers had to cross unprotected mediums (land, mountains, water, and so on).

Note 

Encryption protects sensitive data for an unprotected medium.

In today’s internetworked world, encryption is widely used because it clearly meets the criteria for which it was designed: encryption protects sensitive data passing through the unprotected Internet. Many security professionals have extensive experience in the network security realm and have a strong understanding of cryptography. This is one reason encryption is so popular today.

Databases and database security are significantly different from networks and network security. This is a very important principle because the value encryption provides differs when applied to problems outside its original problem definition. This will be your guiding principle for understanding when to use and when not to use encryption within the database.

The Basics

Encryption is the process of taking plaintext data and converting it into an undecipherable form. The result is encrypted data, which is formally known as ciphertext. Once the data has been encrypted, it generally needs to be decrypted. The decryption (the act of unencrypting) of data returns the ciphertext to its original plaintext form. The study of these two processes is called cryptography.

A plethora of books are available on the market discussing cryptography (my personal favorite is Bruce Schneier’s Applied Cryptography: Protocols, Algorithms, and Source Code in C, John Wiley & Sons). The mathematics involved and the issues and nuances of cryptography are staggering in number and complexity and well beyond the scope of this book. Fortunately, you don’t need to understand all aspects of encryption. This chapter defines only what you need to know to make the critical decisions about how and when to use encryption within the database.

Encryption Choices

There are many ways to encrypt data, but there are fewer ways to do it effectively. Many people are inclined to write their own encryption, just as Julius Caesar did. However, unless they are geniuses or very lucky, chances are their encryption will be poor. Today, effective encryption implies the use of standard and proven encryption algorithms. The proven part is important because it ensures that the encryption doesn’t have some fatal flaw that would allow an unauthorized person to determine the contents of the sensitive data.

Given that you wish to use standard encryption algorithms, there are quite a few from which to choose. Before you start picking algorithms to use in the database, you need to understand a little more about how encryption works.

The Algorithm and the Key

To encrypt data, two things are required: an encryption algorithm and an encryption key. The high level description of encrypting data is quite simple: plaintext data is fed into the encryption algorithm. An encryption key is also provided. Together, the algorithm uses the key and very sophisticated logic to encrypt the data. The process of decryption is analogous. It also requires a key and an algorithm.

Figure 13-1 illustrates how basic symmetric key encryption works. A plaintext message “Meet at Robert’s” is encrypted using an algorithm and a key. To recover the original message, the same key and algorithm must be used.

image from book
Figure 13-1: Symmetric key encryption requires the use of the same key for both the encryption and decryption process.

The overall strength of the encryption isn’t determined by just the algorithm or the key size. The strength is in the combination of the two. A common misconception is that larger keys for one algorithm mean that algorithm is stronger than another algorithm that uses a smaller key size. Some algorithms demand larger keys to make them as strong as other algorithms that use smaller key sizes. However, in some cases larger keys used within the same algorithm do make the encryption stronger.

By studying Figure 13-1, it may become clear that there remains a challenge to effective encryption. If Julius is sending General Suchnsuch an encrypted message, the general needs to know both the algorithm and the key that was used to encrypt the message. Studies of cryptography have shown that with today’s algorithms, the only thing that needs to remain a secret is the key. Public knowledge of the algorithm doesn’t aid the attacker in recovering the sensitive data. Obscuring the algorithm may seem like good security, but it’s only a nuisance to a determined attacker.

Note 

This point can’t be over-emphasized: many cycles are wasted on “protecting the algorithm” in the real world. If knowledge of the algorithm is sufficient to break your code, then your algorithm isn’t an encryption scheme at all.

Symmetric Key Encryption

There are two categories of encryption used today. The first is called symmetric key encryption. The algorithms for symmetric key encryption use the same key for both the encryption and decryption process; they are symmetric! A message encrypted with one key can only be decrypted with that exact same key.

Symmetric key algorithms are very secure and very efficient at encrypting and decrypting data. Some popular examples are RC4, RC5, DES, triple-DES (3DES), and the new Advanced Encryption Standard (AES). Because of their strength and efficiency, these are the algorithms used for “bulk encryption”—they encrypt large amounts of data.

When two people want to use symmetric key encryption, they need to have either a preestablished key or a secure way to transport the key. When two parties already know each other, it’s possible that they will both already know the encryption key. For two parties that have never met and now wish to share data securely, the problem of getting the key between the two parties becomes the major challenge. You can’t leave the key in plaintext because an attacker could see it. If you encrypt the key, you have to do so with another key, which only moves the problem elsewhere. This motivated the development of the second flavor of encryption, called asymmetric key encryption or public key encryption (PKE).

Public Key Encryption

With PKE, two keys act in a complementary manner. The PKE algorithms are mathematical inverses. Whatever one key does, the other key undoes. Furthermore, knowing the algorithm and having one of the keys doesn’t give the attacker an advantage in determining the other key or in recovering the encrypted data.

With PKE, the two keys are usually called the private key and the public key.

Note 

Data encrypted with the private key can only be decrypted with the public key, and vice versa.

“Private” and “public” are used to describe the keys because it’s typical for the public key to be accessible to many people. The private key remains a secret known only to the owner. As long as the private key remains private, this scenario works beautifully.

PKE therefore solves the key distribution problem. For two parties to communicate, they need access only to each other’s public keys. Figure 13-2 illustrates how PKE can be used to send a secret message between two parties. To ensure that the recipient (the server in the figure) is the only one that should receive the message, the message is encrypted with the recipient’s public key. As such, only the recipient will be able to decrypt the message because the only key that can be used is their private key (which only they have). Trying to decrypt the message with an incorrect key yields gibberish. An interloper will be unsuccessful in decrypting the message because they will not have the private key. Note the public key can’t be used to decrypt the message that was also encrypted with the public key.

image from book
Figure 13-2: Public key encryption uses two complementary keys to securely pass sensitive data.

There is another complementary capability that PKE provides. The private key can be used as an authentication method from the sender. As Figure 13-3 illustrates, a sender can encrypt a message with their private key. The recipient can use the client’s public key to decrypt the message. If the message decrypts, then the client’s identity is authenticated because only the sender has access to their private key and so only they could have encrypted the message.

image from book
Figure 13-3: Public key encryption can be used to authenticate parties to one another.

Symmetric Key and Public Key

Unfortunately, the public key algorithms require larger keys to achieve the same strength received from their symmetric key counter parts. Consequently, the public key algorithms perform more slowly and are more computationally expensive.

Today, public key and symmetric key encryption are used together as a part of the standard SSL network protocol. SSL is the de facto standard encryption mechanism for data on the Internet. Due to its superior performance characteristics, symmetric key encryption is used within SSL for bulk data encryption. To transport the symmetric keys securely between the two parties, public key encryption is used to encrypt the symmetric keys. In Figures 13-2 and 13-3, the secret message is actually the symmetric encryption key.

Public key technology gets more than its fair share of the attention considering that proportionately it actually encrypts a lot less data than symmetric key encryption. This is because the administrators and users have to interface directly with the public key technology. The symmetric key algorithms are neatly concealed and hidden from view.

Understanding and acknowledging the use of public key and symmetric key encryption is important to the Oracle Database because the database only supports symmetric key algorithms. The performance and efficiency of symmetric key algorithms make them a natural choice for the database. Unfortunately, this leaves open the issue of key management, which is addressed in the “Key Management” section later in this chapter.



Effective Oracle Database 10g Security by Design
Effective Oracle Database 10g Security by Design
ISBN: 0072231300
EAN: 2147483647
Year: 2003
Pages: 111

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net