From 780b92ada9afcf1d58085a83a0b9e6bc982203d1 Mon Sep 17 00:00:00 2001 From: Lorry Tar Creator Date: Tue, 17 Feb 2015 17:25:57 +0000 Subject: Imported from /home/lorry/working-area/delta_berkeleydb/db-6.1.23.tar.gz. --- docs/programmer_reference/env_encrypt.html | 202 +++++++++++++++-------------- 1 file changed, 107 insertions(+), 95 deletions(-) (limited to 'docs/programmer_reference/env_encrypt.html') diff --git a/docs/programmer_reference/env_encrypt.html b/docs/programmer_reference/env_encrypt.html index 5c81dbed..6470fe9e 100644 --- a/docs/programmer_reference/env_encrypt.html +++ b/docs/programmer_reference/env_encrypt.html @@ -14,7 +14,7 @@

Library Version 11.2.5.3

Library Version 12.1.6.1

@@ -22,9 +22,7 @@ - +

Prev	Chapter 9. - The Berkeley DB Environment -	Chapter 9. The Berkeley DB Environment	Next

@@ -39,63 +37,65 @@

- Berkeley DB optionally supports encryption using the Rijndael/AES - (also known as the Advanced Encryption Standard and Federal - Information Processing Standard (FIPS) 197) algorithm for - encryption or decryption. The algorithm is configured to use a - 128-bit key. Berkeley DB uses a 16-byte initialization vector - generated using the Mersenne Twister. All encrypted information is - additionally checksummed using the SHA1 Secure Hash Algorithm, - using a 160-bit message digest. + Berkeley DB optionally supports encryption using the + Rijndael/AES (also known as the Advanced Encryption Standard + and Federal Information Processing Standard (FIPS) 197) + algorithm for encryption or decryption. The algorithm is + configured to use a 128-bit key. Berkeley DB uses a 16-byte + initialization vector generated using the Mersenne Twister. + All encrypted information is additionally checksummed using + the SHA1 Secure Hash Algorithm, using a 160-bit message + digest.

- The encryption support provided with Berkeley DB is intended to - protect applications from an attacker obtaining physical access to - the media on which a Berkeley DB database is stored, or an attacker - compromising a system on which Berkeley DB is running but who is - unable to read system or process memory on that system. - - The encryption support provided with Berkeley DB will not - protect applications from attackers able to read system memory - on the system where Berkeley DB is running. + The encryption support provided with Berkeley DB is + intended to protect applications from an attacker obtaining + physical access to the media on which a Berkeley DB database + is stored, or an attacker compromising a system on which + Berkeley DB is running but who is unable to read system or + process memory on that system. The + encryption support provided with Berkeley DB will not + protect applications from attackers able to read system + memory on the system where Berkeley DB is running.

-
+
To encrypt a database, you must configure the database for encryption prior to creating it. If you are using a database environment, you must also configure the environment for - encryption. In order to create an encrypted database within an - environment, you: + encryption. In order to create an encrypted database within an + environment, you:

-
- Configure the environment for encryption using the - DB_ENV->set_encrypt() method. +
+ Configure the environment for encryption using the + DB_ENV->set_encrypt() method.

- Open the database environment. + Open the database environment.

-
- Specify the DB_ENCRYPT flag to the database handle. +
+ Specify the DB_ENCRYPT flag to the database + handle.

-
+
Open the database.

-
- Once you have done that, all of the databases that you create in - the environment are encrypted/decrypted by the password you specify - using the DB_ENV->set_encrypt() method. +
+ Once you have done that, all of the databases that you + create in the environment are encrypted/decrypted by the + password you specify using the DB_ENV->set_encrypt() method.

For databases not created in an environment: @@ -103,13 +103,14 @@

-
- Specify the DB_ENCRYPT flag to the database handle. +
+ Specify the DB_ENCRYPT flag to the database + handle.

- Call the DB->set_encrypt() method. + Call the DB->set_encrypt() method.

@@ -119,89 +120,100 @@

-
+
Note that databases cannot be converted to an encrypted - format after they have been created without dumping and re-creating - them. Finally, encrypted databases cannot be read on systems with - a different endianness than the system that created the encrypted - database. + format after they have been created without dumping and + re-creating them. Finally, encrypted databases cannot be read + on systems with a different endianness than the system that + created the encrypted database.

- Each encrypted database environment (including all its encrypted - databases) is encrypted using a single password and a single - algorithm. Applications wanting to provide a finer granularity of - database access must either use multiple database environments or - implement additional access controls outside of Berkeley DB. + When a database is encrypted, its log files are also encrypted, so + accessing the logs also requires the encryption key. By default, + logs are placed in the same directory as the environment. When + using the SQL API, the logs are placed in the journal directory. + Encrypted log files should never be simply deleted. For + instructions on how to properly remove log files see, + Log file removal.

+ Each encrypted database environment (including all its + encrypted databases) is encrypted using a single password and + a single algorithm. Applications wanting to provide a finer + granularity of database access must either use multiple + database environments or implement additional access controls + outside of Berkeley DB. +
+
The only encrypted parts of a database environment are its - databases and its log files. Specifically, the - Shared memory regions supporting - the database environment are not encrypted. For this reason, it - may be possible for an attacker to read some or all of an encrypted - database by reading the on-disk files that back these shared memory - regions. To prevent such attacks, applications may want to use - in-memory filesystem support (on systems that support it), or the - DB_PRIVATE or DB_SYSTEM_MEM flags to the DB_ENV->open() method, to - place the shared memory regions in memory that is never written to - a disk. As some systems page system memory to a backing disk, it - is important to consider the specific operating system running on - the machine as well. Finally, when backing database environment - shared regions with the filesystem, Berkeley DB can be configured - to overwrite the shared regions before removing them by specifying - the DB_OVERWRITE flag. This option is only effective in the - presence of fixed-block filesystems, journaling or logging - filesystems will require operating system support and probably - modification of the Berkeley DB sources. + databases and its log files. Specifically, the Shared memory regions + supporting the database environment are not encrypted. For + this reason, it may be possible for an attacker to read some + or all of an encrypted database by reading the on-disk files + that back these shared memory regions. To prevent such + attacks, applications may want to use in-memory filesystem + support (on systems that support it), or the DB_PRIVATE or + DB_SYSTEM_MEM flags to the DB_ENV->open() method, to place the + shared memory regions in memory that is never written to a + disk. As some systems page system memory to a backing disk, it + is important to consider the specific operating system running + on the machine as well. Finally, when backing database + environment shared regions with the filesystem, Berkeley DB + can be configured to overwrite the shared regions before + removing them by specifying the DB_OVERWRITE flag. This + option is only effective in the presence of fixed-block + filesystems, journaling or logging filesystems will require + operating system support and probably modification of the + Berkeley DB sources.

- While all user data is encrypted, parts of the databases and log - files in an encrypted environment are maintained in an unencrypted - state. Specifically, log record headers are not encrypted, only - the actual log records. Additionally, database internal page - header fields are not encrypted. These page header fields includes - information such as the page's DB_LSN number and position in the - database's sort order. + While all user data is encrypted, parts of the databases + and log files in an encrypted environment are maintained in an + unencrypted state. Specifically, log record headers are not + encrypted, only the actual log records. Additionally, database + internal page header fields are not encrypted. These page + header fields includes information such as the page's DB_LSN + number and position in the database's sort order.
-
- Log records distributed by a replication master to replicated - clients are transmitted to the clients in unencrypted form. If - encryption is desired in a replicated application, the use of a - secure transport is strongly suggested. +
+ Log records distributed by a replication master to + replicated clients are transmitted to the clients in + unencrypted form. If encryption is desired in a replicated + application, the use of a secure transport is strongly + suggested.

- We gratefully acknowledge: + We gratefully acknowledge:

- Vincent Rijmen, Antoon Bosselaers and Paulo Barreto for writing - the Rijndael/AES code used in Berkeley DB. + Vincent Rijmen, Antoon Bosselaers and Paulo Barreto + for writing the Rijndael/AES code used in Berkeley DB.

- Steve Reid and James H. Brown for writing the SHA1 checksum - code used in Berkeley DB. + Steve Reid and James H. Brown for writing the SHA1 + checksum code used in Berkeley DB.

- Makoto Matsumoto and Takuji Nishimura for writing the Mersenne - Twister code used in Berkeley DB. + Makoto Matsumoto and Takuji Nishimura for writing + the Mersenne Twister code used in Berkeley DB.

- Adam Stubblefield for integrating the Rijndael/AES, SHA1 - checksum and Mersenne Twister code into Berkeley DB. + Adam Stubblefield for integrating the Rijndael/AES, + SHA1 checksum and Mersenne Twister code into Berkeley DB.

-
+
Berkeley DB 11g Release 2 supports encryption using Intel's Performance Primitive (IPP) on Linux. This works only on Intel - processors. To use Berkeley DB with IPP encryption, you must have - IPP installed along with the cryptography extension. The IPP - performance is higher in most cases compared to the current AES - implementation. See - --with-cryptography - for more information. See the - + processors. To use Berkeley DB with IPP encryption, you must + have IPP installed along with the cryptography extension. The + IPP performance is higher in most cases compared to the + current AES implementation. See --with-cryptography + for more information. See the + Intel Documenation for more information on IPP.
-- cgit v1.2.1