This article provides a description of the data encryption package (DBMS_OBFUSCATION_TOOLKIT) that allows you to encrypt data in a database. Data encryption topics are presented in the following sections:
- Securing Sensitive Information
- Principles of Data Encryption
- Solutions For Stored Data Encryption in Oracle9i
- Data Encryption Challenges
- Example of Data Encryption PL/SQL Program
- Securing Sensitive Information
The Internet poses new challenges in information security, especially for those organizations seeking to become e-businesses. Many of these security challenges can be addressed by the traditional arsenal of security mechanisms:
- Strong user authentication to identify users
- Granular access control to limit what users can see and do
- Auditing for accountability
- Network encryption to protect the confidentiality of sensitive data in transmission
Encryption is an important component of several of the above solutions. For example, Secure Sockets Layer (SSL), an Internet-standard network encryption and authentication protocol, uses encryption to strongly authenticate users by means of X.509 digital certificates. SSL also uses encryption to ensure data confidentiality, and cryptographic checksums to ensure data integrity. Many of these uses of encryption are relatively transparent to a user or application. For example, many browsers support SSL, and users generally do not need to do anything special to enable SSL encryption.
Oracle has provided network encryption between database clients and the Oracle database since Oracle7. Oracle Advanced Security, an option to Oracle9i, provides encryption and cryptographic integrity check for any protocol supported by Oracle9i, including Net8, Java Database Connectivity (JDBC) (both "thick" and "thin" JDBC), and the Internet Intra-Orb Protocol (IIOP). Oracle Advanced Security also supports SSL for Net8, "thick" JDBC and IIOP connections.
While encryption is not a security cure-all, it is an important tool used to address specific security threats, and will become increasingly important with the growth of e-business, especially in the area of encryption of stored data. For example, while credit card numbers are typically protected in transit to a web site using SSL, the credit card number is often stored in the clear (un-encrypted), either on the file system, where it is vulnerable to anyone who can break into the host and gain root access, or in databases. While databases can be made quite secure through proper configuration, they can also be vulnerable to host break-ins if the host is mis-configured. There have been several well-publicized break-ins, in which a hacker obtained a large list of credit card numbers by breaking into a database.
Encryption of stored data thus represents a new challenge for e-businesses, and can be an important tool in dealing with specific types of security threats.
Principles of Data Encryption
While there are many good reasons to encrypt data, there are many bad reasons to encrypt data. Encryption does not solve all security problems, and may even make some problems worse. The following section describes some of the misconceptions about encryption of stored data. It includes these topics:
- Principle 1: Encryption Does Not Solve Access Control Problems
- Principle 2: Encryption Does Not Protect Against a Malicious DBA
- Principle 3: Encrypting Everything Does Not Make Data Secure
Principle 1: Encryption Does Not Solve Access Control Problems
Most organizations need to limit access to data to those who have a "need to know." For example, a human resources system may limit employees to reviewing only their own employment records, while managers of employees may see the employment records of those employees working for them. Human resources specialists may also need to see employee records for multiple employees.
This type of security policy-----limiting data access to those with a need to see it-----is typically addressed by access control mechanisms. The Oracle database has provided strong, independently-evaluated access control mechanisms for many years. Recently, Oracle9i has added the ability to enforce access control to an extremely fine level of granularity, through its Virtual Private Database capability.
Because human resources records are considered sensitive information, it is tempting to think that this information should all be encrypted "for better security." However, encryption cannot enforce the type of granular access control described above, and may actually hinder data access. In the human resources example, an employee, his manager, and the HR clerk all need to access the employee's record. If employee data is encrypted, then each person also has to be able to access the data in un-encrypted form. Therefore, the employee, the manager and the HR clerk would have to share the same encryption key to decrypt the data. Encryption would therefore not provide any additional security in the sense of better access control, and the encryption might actually hinder the proper functioning of the application. An additional issue is that it is very difficult to securely transmit and share encryption keys among multiple users of a system.
A basic principle behind encrypting stored data is that it must not interfere with access control. For example, a user who has SELECT privilege on EMP should not be limited by the encryption mechanism from seeing all the data he is otherwise allowed to see. Similarly, there is little benefit to encrypting part of a table with one key and part of a table with another key if users need to see all encrypted data in the table; it merely adds to the overhead of decrypting the data before users can read it. Provided that access controls are implemented well, there is little additional security provided within the database itself from encryption. Any user who has privilege to access data within the database has no more nor any less privilege as a result of encryption. Therefore, encryption should never be used to solve access control problems.
Principle 2: Encryption Does Not Protect Against a Malicious DBA
Some organizations are concerned that a malicious user can gain elevated (DBA) privilege through guessing a password. These organizations would like to encrypt stored data to protect against this threat. However, the correct solution to this problem is to protect the DBA account, and to change default passwords for other privileged accounts. The easiest way to break into a database is through an unchanged password for a privileged account (for example, SYS/CHANGE_ON_INSTALL).
Note that there are many other destructive things a malicious user can do to a database once he gains DBA privilege. Examples include corrupting or deleting data, exporting user data to the file system to mail the data back to himself so as to run a password cracker on it, etc. Encryption will not protect against these threats.
Some organizations are concerned that database administrators (DBAs), because they typically have all privileges, are able to see all data in the database. These organizations feel that the DBAs should merely administer the database, but should not be able to see the data that the database contains. Some organizations are also concerned about the concentration of privilege in one person, and would prefer to partition the DBA function, or enforce two-person access rules.
It is tempting to think that encrypting all data (or significant amounts of data) will solve the above problems, but there are better ways to protect against these threats. First of all, Oracle does support limited partitioning of DBA privilege. Oracle9i provides native support for SYSDBA and SYSOPER users. SYSDBA has all privileges, but SYSOPER has a limited privilege set (such as startup and shutdown of the database). Furthermore, an organization can create smaller roles encompassing a number of system privileges. A JR_DBA role might not include all system privileges, but only those appropriate to a more junior database administrator (such as CREATE TABLE, CREATE USER, and so on). Oracle also enables auditing the actions taken by SYS (or SYS-privileged users) and storing that audit trail in a secure operating system location. Using this model, a separate auditor who has root on the OS can audit all actions by SYS, enabling the auditor to hold all DBAs accountable for their actions.
The audit_sys_operations parameter in Oracle9i Database Administrator's Guide
Furthermore, the DBA function by its nature is a trusted position. Even organizations with the most sensitive data-----such as intelligence agencies-----do not typically partition the DBA function. Instead, they vet their DBAs strongly, because it is a position of trust. Periodic auditing can help to uncover inappropriate activities.
Encryption of stored data must not interfere with the administration of the database; otherwise, larger security issues can result. For example, if by encrypting data you corrupt the data, you've created a security problem: data is not meaningful and may not be recoverable.
Encryption can be used to mitigate the ability of a DBA-----or other privileged user-----to see data in the database. However, it is not a substitute for vetting a DBA properly, or for limiting the use of powerful system privileges. If an untrustworthy user has significant privilege, there are multiple threats he can pose to an organization, and these may be far more significant than viewing un-encrypted credit card numbers.
Principle 3: Encrypting Everything Does Not Make Data Secure
It is a pervasive tendency to think that if storing some data encrypted strengthens security, then encrypting everything makes all data secure.
As described above, encryption does not address access control issues well. Consider the implications of encrypting an entire production database. All data must be decrypted to be read, updated, or deleted, and the encryption must not interfere with normal access controls. Encryption is inherently a performance-intensive operation; encrypting all data will significantly affect performance. Availability is a key aspect of security and if, by encrypting data, you make data unavailable, or the performance adversely affects availability, then you have created a new security problem.
Encryption keys must be changed regularly as part of good security practice, which necessitates that the database be inaccessible while the data is being decrypted and re-encrypted with a new key or keys. This also adversely affects availability.
While encrypting all or most of the data in a production database is clearly a problem, there may be advantages to encrypting data stored off-line. For example, an organization may store backups for a period of six months to a year off-line, in a remote location. Of course, the first line of protection is to secure the data in a facility to which access is controlled--a physical measure. However, there may be a benefit to encrypting this data before it is stored. Since it is not being accessed on-line, performance need not be a consideration. While Oracle9i does not provide this facility, there are vendors who can provide such encryption services. Before embarking on large-scale encryption of backup data, organizations considering this approach should thoroughly test the process. It is essential that any data which is encrypted before off-line storage, can be decrypted and re-imported successfully.
Solutions For Stored Data Encryption in Oracle9i
DBMS_OBFUSCATION_TOOLKIT provides several means for addressing the security issues that have been discussed. This section includes these topics:
- Oracle9i Data Encryption Capabilities
- Data Encryption Challenges
Oracle9i Data Encryption Capabilities
While there are many security threats that encryption cannot address well, it is clear that an additional measure of security can be achieved by selectively encrypting sensitive data before storage in the database. Examples of such data could include:
- Credit card numbers
- National identity numbers
- Passwords for applications whose users are not database users
To address these needs, Oracle9i provides a PL/SQL package to encrypt and decrypt stored data. The package, DBMS_OBFUSCATION_TOOLKIT, is provided in both Standard Edition and Enterprise Edition Oracle9i. This package currently supports bulk data encryption using the Data Encryption Standard (DES) algorithm, and includes procedures to encrypt (DESEncrypt) and decrypt (DESDecrypt) using DES. The DBMS_OBFUSCATION_TOOLKIT also includes functions to encrypt and decrypt using 2-key and 3-key DES, in outer cipher block chaining mode. They require keylengths of 128 and 192 bits, respectively.
The DBMS_OBFUSCATION_TOOLKIT includes a cryptographic checksumming capabilities (MD5), and the ability to generate a secure random number (GetKey). Secure random number generation is important part of cryptography; predictable keys are easily-guessed keys, and easily-guessed keys may lead to easy decryption of data. Most cryptanalysis is done by finding weak keys or poorly-stored keys, rather than through brute force analysis (cycling through all possible keys).
Do not use DBMS_RANDOM as it is unsuitable for cryptographic key generation.
Key management is programmatic. That is, the application (or caller of the function) must supply the encryption key; and this means that the application developer must find a way of storing and retrieving keys securely. The relative strengths and weaknesses of various key management techniques are discussed below. The DBMS_OBFUSCATION_TOOLKIT package, which can handle both string and raw data, requires the submission of a 64-bit key. The DES algorithm itself has an effective key length of 56-bits.
The DBMS_OBFUSCATION_TOOLKIT is granted to PUBLIC by default. Oracle strongly recommends that this grant be revoked. In general, there is no reason why users should be able to encrypt stored data outside the context of an application.