Continue in 2 seconds

Encryption at Rest

Published
  • August 01 2005, 1:00am EDT

Encryption has a long and illustrious history. In World War II, the Americans and the British broke the German Enigma code and the Japanese Purple code, and those two events led to the downfall of Hitler's U-boat campaign in the Atlantic and Japanese troop movement throughout the Pacific Theater.

Today, encryption is found mainly in the movement of data. As data is to be transported, it is encrypted. Upon arriving at its destination, it is decrypted. During flight (i.e., the time that it is being moved), the message is deemed to be safe because if anyone were to encounter it, it would mean nothing. Only at the source and the destination is the data's true meaning apparent. This process is known as encryption in flight.

However, encryption at rest is an entirely different matter. Encryption at rest refers to the fact that the data is physically stored in an encrypted manner. It is appealing from the standpoint of security. Consider two databases - database A where there is encryption in flight and database B where there is encryption at rest. One day someone decides to steal database A. Assuming the person can succeed, once the person has database A in his/her hands, the data can be read like any other file. Stated differently, if a database can be removed or copied and taken to another environment, then none of the security measures that have been taken to protect the data can be in force.

The data in database B is encrypted as it is stored. If somebody steals the database or copies it and removes the data, unless the person can figure out how to decrypt the data, the data does no good whatsoever.

Is encryption of data at rest the optimal stance? Unfortunately, there are numerous major drawbacks with encrypted data at rest. The most obvious is that the data cannot be accessed. (Which defeats one of the major reasons for having a database in the first place.) If "Bill Inmon" is stored as "kljyuuyrat," it is going to be difficult to find the record for "Bill Inmon." In order to find the record, the person looking for it must know how to encrypt. If everyone knows how to encrypt and decrypt, then what is the purpose of encryption? However, suppose that there is a way for the system to automatically translate "Bill Inmon" into "kljyuuyrat" without the end user knowing what is going on. Now it becomes possible to use encryption at rest.

The problems don't end there. Suppose I want to find all people name "Bill." Do I look for "kljy"? Additionally, when I store data in the form of "kljyuuyrat," I destroy the sequence of the data. Whether the sequence is destroyed at the physical block level or at the index level is irrelevant. You could say at the physical block level that sequence doesn't matter, which may indeed be true. However, if sequence at the physical block level doesn't matter, then it will matter somewhere else, such as at the index level. Of course, there is the alternative of storing the index in the "Bill Inmon" format, but that defeats the purpose of encryption at rest because all someone has to do is steal the indexes, rather than the data. Encryption at rest sounds great from the standpoint of security, but in terms of practicality, it is a supremely bad idea.

One alternative is to encrypt at rest only a few fields of data. This may serve some purpose, but may actually be dangerous because encrypting only a few data elements may mislead the database administrator into thinking the data is safe when in fact it is not. Consider this very simple example in which the gender field has been encrypted. In the database, you would find: Bill Inmon, gender = v; Don Hardy, gender = v; Mary Hill, gender = k; Judy Wilson, gender = k; and Mike Hodson, gender = v.

Even though gender is encrypted, it doesn't take a genius to figure out what "v" and "k" mean. This is a very simple and obvious example, but the idea is the same in other situations. Encrypting only a small part of data is unacceptable for security reasons.

Encryption at rest quickly brings larger issues to the surface such as security versus usability. While encryption at rest gives a great deal of very fundamental protection, it wreaks havoc with normal operation of the database to the point that - from a practical standpoint - encryption at rest is unthinkable except for the most limited and specialized of databases. 

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access