<!--$Id: encrypt.so,v 11.13 2007/03/27 14:20:56 sue Exp $--> <!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> <!--See the file LICENSE for redistribution information.--> <html> <head> <title>Berkeley DB Reference Guide: Encryption</title> <meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> <meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> </head> <body bgcolor=white> <a name="2"><!--meow--></a> <table width="100%"><tr valign=top> <td><b><dl><dt>Berkeley DB Reference Guide:<dd>Environment</dl></b></td> <td align=right><a href="../env/security.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../env/remote.html"><img src="../../images/next.gif" alt="Next"></a> </td></tr></table> <p align=center><b>Encryption</b></p> <p>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.</p> <p>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. <b>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.</b></p> <p>Encryption is not the default for created databases, even in database environments configured for encryption. In addition to configuring for encryption by calling the <a href="../../api_c/env_set_encrypt.html">DB_ENV->set_encrypt</a> or <a href="../../api_c/db_set_encrypt.html">DB->set_encrypt</a> methods, applications must specify the <a href="../../api_c/db_set_flags.html#DB_ENCRYPT">DB_ENCRYPT</a> flag before creating the database in order for the database to be encrypted. Further, 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.</p> <p>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.</p> <p>The only encrypted parts of a database environment are its databases and its log files. Specifically, the <a href="../../ref/env/region.html">shared memory regions</a> 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 <a href="../../api_c/env_open.html#DB_PRIVATE">DB_PRIVATE</a> or <a href="../../api_c/env_open.html#DB_SYSTEM_MEM">DB_SYSTEM_MEM</a> flags to the <a href="../../api_c/env_open.html">DB_ENV->open</a> 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 <a href="../../api_c/env_set_flags.html#DB_OVERWRITE">DB_OVERWRITE</a> 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.</p> <p>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 <a href="../../api_c/lsn_class.html">DB_LSN</a>, number, and position in the database's sort order.</p> <p>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.</p> <p>We gratefully acknowledge:</p> <p><ul type=disc> <li>Vincent Rijmen, Antoon Bosselaers and Paulo Barreto for writing the Rijndael/AES code used in Berkeley DB. <li>Steve Reid and James H. Brown for writing the SHA1 checksum code used in Berkeley DB. <li>Makoto Matsumoto and Takuji Nishimura for writing the Mersenne Twister code used in Berkeley DB. <li>Adam Stubblefield for integrating the Rijndael/AES, SHA1 checksum and Mersenne Twister code into Berkeley DB. </ul> <table width="100%"><tr><td><br></td><td align=right><a href="../env/security.html"><img src="../../images/prev.gif" alt="Prev"></a><a href="../toc.html"><img src="../../images/ref.gif" alt="Ref"></a><a href="../env/remote.html"><img src="../../images/next.gif" alt="Next"></a> </td></tr></table> <p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> </body> </html>