Is Database Encryption Worth it?
Encrypting a database does have a superficial appeal. The rise of native encryption technologies, embedded into the database by the various vendors, have made encryption easier today than ever before.
By protecting your data and associated objects intellectual property can be preserved and the sun will always shine.
Or will it?
Microsoft SQL Server
Stored procedures in SQL Server enable a developer to encapsulate functionality into a block of code, which, in turn, can be optimised by the database for very fast processing. The code in a stored procedure can represent a business process or other logic that can easily be commercially sensitive. By default, SQL Server will take this code and store it in a system table called SysComments. If a user can access this table, which is not necessarily difficult, the code can be seen in plain text and therefore read and copied.
To prevent this from happening it is possible to encrypt a SQL Server stored procedure using the WITH ENCRYPTION clause. This will encrypt the logic in the SysComments system table and make the stored procedure indecipherable. Note that once a stored procedure has been encrypted neither the object owner or systems administrator can recover the plain language code, so it is imperative that a copy of the unencrypted stored procedure code is kept in a safe place.
Well, that is the official line.
The harsh reality is that the internet is awash with third party tools that can decrypt SQL Server stored procedures for $100 or so. Does this make the encryption of SQL Server stored procedures a waste of time? Probably not, as encryption will deter the casual observer. ISVs should incorporate suitable clauses in their End User Licence Agreement that forbid reverse engineering of code and I hope the courts will take a dim view of someone trying to break open your intellectual property. Ultimately if someone wants to get your code they will, but why not make it a little more difficult for them?
Oracle
This vendor supports the protection of PL/SQL code using a tool called the PL/SQL Wrap Utility. If you wrap code in Oracle it can still be treated the same as unwrapped code—it is just as portable. There are some limitations to the Oracle Wrap Utility. Specifically names of variables, columns, tables and string and number literals are not hidden by the tool and these will remain in plain view for others to see but at least the code is hidden. Running the Wrap Utility is done from the command line, the file to be wrapped is simply named alongside the name of the new wrapped file.
Database Encryption—the downside
Like most things in IT, there is always a negative to a positive. If encryption is so great why don’t developers use it everywhere—basically encrypt everything unless there is a good reason not to?
Unfortunately using encryption can both increase the volume of your database and decrease your system performance.
Some encryption algorithms used to encrypt data work on a fixed block size architecture. If the size of the data to be encrypted does not match these block sizes then some algorithms will pad out the blocks with wasted space to make them fit—and bloat your database.
A good example is the use of wrapping in an Oracle database. The size of a wrapped procedure can be up to three times the size of the same code unwrapped which in turn will increase the time it takes to install these procedures.
Performance can be massively affected if you are using indexed columns that are encrypted. Often this data is the type that makes sense to encrypt as it may be the most sensitive, such as a credit card number. The down side is that when you are adding or changing data the database will need to battle with the encryption algorithm to make the changes.
No one ever said database security was easy and a win-win. There will always be instances when the technology that supports the encryption will get in the way of the business objectives of the database. In this case you will need to make an informed view as to what if any data is encrypted in the database.