and authentication solution will allow for secure transmission of
sensitive data between all entities across an enterprise.
In general, all administrative ports should be blocked from external
networks. Access control lists (ACLs) should be set up to restrict
access to certain devices on the network. For example, if a network-
based security appliance resides on the network, only those devices
that require access for administrative or cryptographic operations
should be granted access.
16.7 Encryption of multiple columns: database
If multiple columns of a database table are encrypted, it is strongly
recommended to use different encryption keys for each column. That
way, even if an attacker manages to compromise a single key, the
rest of the encrypted columns will remain secure. The only reason to
use a single key to encrypt multiple columns is if the columns all
contain values from the same set of data and the encrypted values
have to be compared with each other to determine equality (such as
when performing a join). The database schema and application logic
should be designed to minimize situations where this is necessary.
16.7.1 Creating indexes
Indexes are created to facilitate the search of a particular record or
a set of records from a database table. Indexes are created on a spe-
cific column or a set of columns. When the database table is selected,
and where conditions are provided, the database will typically use
the indexes to locate the records, avoiding the need to do a full table
scan. In many cases, searching on an encrypted column will require
the database to perform a full table scan regardless of whether an
index exists. For this reason, encrypting a column that is part of an
index is not recommended.
16.7.2 Primary key encryption
Encrypted columns can be a primary key or part of a primary key,
because the encryption of a piece of data is stable (it always produces
16.7 Encryption of multiple columns: database considerations 279
the same result), and no two distinct pieces of data will produce the
same cipher text, provided that the key and initialization vector used
are consistent. However, when encrypting entire columns of an
existing database, depending on the data migration method, data-
base administrators might have to drop existing primary keys and
any other associated reference keys, and re-create them after the data
are encrypted. For this reason, encrypting a column that is part of a
primary key constraint is not recommended. Because primary keys
are automatically indexed, there are also performance considera-
tions, as described previously.
16.7.3 Foreign key constraint
A foreign key constraint can be created on an encrypted column.
However, special care must be given during migration. To convert
an existing table to one that holds encrypted data, all the tables with
which it has constraints must first be identified. All referenced tables
have to be converted accordingly. In certain cases, the referential
constraints have to be temporarily disabled or dropped to allow
proper migration of existing data. They can be reenabled or
recreated once the data for all the associated tables are encrypted.
Because of this complexity, encrypting a column that is part of a
foreign key constraint is not recommended. Unlike indexes and
primary keys, though, encrypting foreign keys generally does not
present a performance impact.
16.7.4 Randomly generated initialization vectors
When using CBC mode of a block encryption algorithm, a randomly
generated IV is used and must be stored for future use when the data
are decrypted. Because the IV does not need to be kept secret, it can
be stored in the database. If the application requires having an IV per
column, which can be necessary to allow for searching within that
column, the value can be stored in a separate table. For a more
secure deployment, but with limited searching capabilities, an addi-
tional column can be added to the table and an IV can be generated
per row. In the case in which multiple columns are encrypted, but the
table has space limitations, the same IV can be reused for each
encrypted value in the row, even if the encryption keys for each
column are different, provided the encryption algorithm and key size
are the same.
280 16.7 Encryption of multiple columns: database considerations