About InterBase Encryption

From InterBase

Go Up to Encrypting Your Data

Encryption is the process of applying an invertible algorithm to a block of data (plaintext) so that the encrypted data (ciphertext) bears no resemblance to the plaintext. Typically, an encryption key is applied to the plaintext to produce the ciphertext. The same encryption key is used to convert (decrypt) the ciphertext back to plaintext. The purpose of encryption is to protect data from being deciphered by unauthorized viewers or users. InterBase enables you to encrypt information at one or both of the following levels:

  • Database-level Encryption:
When you specify database-level encryption, InterBase encrypts all the database pages that contain user information. Non-user database pages are not encrypted. Non-user pages include the header page, log page, inventory pages, pointer pages, transaction inventory pages, index root pages, and generator pages.
You cannot specify which pages in a database to encrypt. Instead, you issue the encrypt database command from the database to which you are connected, and InterBase encrypts all the user-related pages in that database.
  • Column-level Encryption:
Column-level encryption is both more flexible and more specific. To encrypt a column, you specify the table that contains the column, followed by the name of the column. You can encrypt all of the columns in a table, or only individual columns you specify. For example, you can encrypt a payroll column in an Employee table so that both payroll and HR employees can access it. Then you might encrypt SSN information in the same table so that only payroll employees can access it. Users who need to access data in encrypted columns can be given decrypt privileges for that column.
When working with encrypted columns, the MIN, MAX, BETWEEN, and ORDER BY operations cannot use an index based on those fields due to the nature of the index key that is formed from the encrypted field value. So while the index is not useful for the above operations, it is still useful for equality matches and JOIN operations

Generally speaking, encrypting all of the user pages of a database takes much greater overhead than selectively encrypting individual columns. In addition, database performance can be adversely affected when a large number of concurrent queries access the same encrypted columns.

Encrypting Database Backup Files

To maintain the security and confidentiality of encrypted databases, you must also encrypt database backup files. The GBAK utility provides three additional switches to facilitate encrypt and decrypt operations on database backups. For instructions on how to encrypt and decrypt backup files, see Encrypting Backup Files.

Encrypting Network Communication (InterBase Encryption)

Data passed to a remote InterBase client from a database server is unencrypted during the transmission process. For information on how to encrypt information that is passed over a network, see Encrypting Your Data the InterBase Operations Guide.

About Industry Encryption Standards

InterBase encryption supports the use of the following industry encryption standards:

  • Data Encryption Standard (DES) is a 25-year-old industry standard. DES is a weak encryption standard but does not require a license to use.
  • Advanced Encryption Standard (AES) was adopted as a federal standard in 2002. AES enables a larger number of bits with which to scrambled data than DES does. Because AES offers much stronger encryption protection, the United States regulates its export. To address U.S. export regulations, users must obtain an InterBase license to use AES with InterBase. InterBase includes AES in the Server, ToGo and Desktop editions. Please, see About AES for more information about this stardard.
You do not need an AES addon license starting with InterBase XE3 release. InterBase 2009 and InterBase XE required the addon license. You specify the standard you want to use with InterBase when you create an encryption key. Instructions on how to create the encryption key are provided later in this chapter.

Who Can Create Encryption?

Encryption tasks, which are summarized in the table on the page An Overview of Encryption Tasks, are primarily performed by the following users: a SYSDSO, the database owner, and any individual table owners who are given permission to encrypt specific columns in a table. InterBase requires the creation of the System Database Security Owner (SYSDSO) user to implement specific encryption tasks. SYSDSO is a reserved user name, similar to SYSDBA.

The database owner is typically the person who creates the database. The database owner may or may not also be the administrator of the database.

The SYSDSO role controls three significant steps in the encryption process:

  • Creates a System Encryption Password (SEP).
  • Creates the encryption keys.
  • Grants the database owner access to the encryption keys, which s/he then uses to encrypt the database and/or its columns.

However, the SYSDSO cannot encrypt databases or columns, nor can s/he grant or revoke access to encrypted data. Only a database owner and/or an individual table owner can actually encrypt a database or columns in a database; the SYSDSO simply creates the tools (the encryption keys) that are needed to perform the encryption. Requiring that multiple users set up and implement encryption, rather than just one, adds an additional layer of database security.

In addition, only the user who encrypts a column or database can grant decrypt privileges to those who need to view or modify the encrypted data. For more information about granting decrypt permission, see Granting Decrypt Permission.

Generally speaking, only the user who grants the permission can revoke the permission. For more information, see Revoking Encrypt and Decrypt Permissions.

Decrypt permission is only required for column-level encryption. It is not required for database-level encryption.

Creating the SYSDSO User

The database owner uses the following syntax to create the SYSDSO user:


You must keep the SYSDSO user for as long as you use the encryption keys created by that same SYSDSO.

If the SET PASSWORD clause is not specified, the default SYSDSO password will be the password of the person who creates the account. This makes it easier for the account creator to temporarily acquire SYSDSO privileges to create and test encryptions during development without having to login to do so. When the SYSDSO password is subsequently changed, the account creator loses this privilege. Presumably, this handoff would occur at deployment time, when transferring these duties to a security authority.

An Overview of Encryption Tasks

The following list identifies the tasks that need to be performed to encrypt a database and/or its columns, and to give users the appropriate access rights. The steps are typically performed by a SYSDSO and a database owner unless additional individuals are given encrypt privileges to specific columns. See Who Can Create Encryption? for more information about how the SYSDSO and database owner use the InterBase encryption feature.

To implement encryption using InterBase, perform the tasks listed in the table. The following sections provide detailed instructions on how to perform steps 3-7.

Step # Task Performed by


Ensure that Embedded User Authentication (EUA) is enabled on the database you plan to encrypt. For instructions on how to enable EUA using isql, see the InterBase Operations Guide. For instructions on how to enable EUA using IBConsole, see Encrypting a Database with IBConsole of this chapter.

Database owner


Create a System Database Security Owner (SYSDSO) account using the command on Creating the SYSDSO User.

Database owner


Create a System Encryption Password (SEP).



Create an encryption key for the database and/or the columns you want the database or table owner to encrypt.



Grant the database owner privileges to use the encryption keys to perform encryption.



Encrypt the database and/or columns.

Database owner or individual table owner


Grant or revoke decrypt privileges to other users.

Database owner or individual table owner

Requirements and Support

InterBase encryption is supported on all InterBase platforms. Before using it, you must install or do the following:

  • Embedded User Authentication (EUA) must be enabled to grant specified users decrypt privileges to access data in encrypted columns. For instructions on how to enable EUA using isql, see the InterBase Operations Guide. For instructions on how to enable EUA using IBConsole, see Encrypting a Database with IBConsole of this chapter.
  • Due to government regulation of strong encryption, you must obtain a license from InterBase to use AES with InterBase.You do not need a special license to use DES with InterBase.
  • This feature requires ODS 13 and is not available on older ODS databases. Therefore, a backup and restore to ODS 13 is required for pre-existing databases to use InterBase encryption. For more information about performing backups and restores, see the InterBase Operations Guide.
The table below shows which primary ODS version corresponds to each InterBase release:
InterBase version Primary ODS version
2020 18
2017 17
XE7 16
XE3 15
XE 15
2009 13
2007 12
7.0 11
6.0 10
The InterBase release may support certain older ODS versions as well (see the Migration Issues section of the Readme for that release). There is no official release of ODS 14 as a primary ODS.
InterBase uses OpenSSL or a derivation of that version to support InterBase encryption. InterBase embeds OpenSSL libraries in InterBase server/client to help implement encryption-related features. OpenSSL contains libraries for the most widely known encryption and message digest algorithms in use today. InterBase uses these libraries as the basis for supporting database and column-level encryption functionality.

See Also

Advance To: