1<!--$Id: encrypt.so,v 11.13 2007/03/27 14:20:56 sue Exp $--> 2<!--Copyright (c) 1997,2008 Oracle. All rights reserved.--> 3<!--See the file LICENSE for redistribution information.--> 4<html> 5<head> 6<title>Berkeley DB Reference Guide: Encryption</title> 7<meta name="description" content="Berkeley DB: An embedded database programmatic toolkit."> 8<meta name="keywords" content="embedded,database,programmatic,toolkit,btree,hash,hashing,transaction,transactions,locking,logging,access method,access methods,Java,C,C++"> 9</head> 10<body bgcolor=white> 11<a name="2"><!--meow--></a> 12<table width="100%"><tr valign=top> 13<td><b><dl><dt>Berkeley DB Reference Guide:<dd>Environment</dl></b></td> 14<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> 15</td></tr></table> 16<p align=center><b>Encryption</b></p> 17<p>Berkeley DB optionally supports encryption using the Rijndael/AES (also known 18as the Advanced Encryption Standard and Federal Information Processing 19Standard (FIPS) 197) algorithm for encryption or decryption. The 20algorithm is configured to use a 128-bit key. Berkeley DB uses a 16-byte 21initialization vector generated using the Mersenne Twister. All 22encrypted information is additionally checksummed using the SHA1 Secure 23Hash Algorithm, using a 160-bit message digest.</p> 24<p>The encryption support provided with Berkeley DB is intended to protect 25applications from an attacker obtaining physical access to the media on 26which a Berkeley DB database is stored, or an attacker compromising a system 27on which Berkeley DB is running but who is unable to read system or process 28memory on that system. 29<b>The encryption support provided with Berkeley DB will not protect applications 30from attackers able to read system memory on the system where Berkeley DB is 31running.</b></p> 32<p>Encryption is not the default for created databases, even in database 33environments configured for encryption. In addition to configuring for 34encryption by calling the <a href="/api_c/env_set_encrypt.html">DB_ENV->set_encrypt</a> or 35<a href="/api_c/db_set_encrypt.html">DB->set_encrypt</a> methods, applications must specify the 36<a href="/api_c/db_set_flags.html#DB_ENCRYPT">DB_ENCRYPT</a> flag before creating the database in order for the 37database to be encrypted. Further, databases cannot be converted to an 38encrypted format after they have been created without dumping and 39re-creating them. Finally, encrypted databases cannot be read 40on systems with a different endianness than the system that created 41the encrypted database.</p> 42<p>Each encrypted database environment (including all its encrypted 43databases) is encrypted using a single password and a single algorithm. 44Applications wanting to provide a finer granularity of database access 45must either use multiple database environments or implement additional 46access controls outside of Berkeley DB.</p> 47<p>The only encrypted parts of a database environment are its databases 48and its log files. Specifically, the <a href="/ref/env/region.html">shared memory regions</a> supporting the database environment are not 49encrypted. For this reason, it may be possible for an attacker to read 50some or all of an encrypted database by reading the on-disk files that 51back these shared memory regions. To prevent such attacks, applications 52may want to use in-memory filesystem support (on systems that support 53it), 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 54<a href="/api_c/env_open.html">DB_ENV->open</a> method, to place the shared memory regions in memory that 55is never written to a disk. As some systems page system memory to a 56backing disk, it is important to consider the specific operating system 57running on the machine as well. Finally, when backing database 58environment shared regions with the filesystem, Berkeley DB can be configured 59to overwrite the shared regions before removing them by specifying the 60<a href="/api_c/env_set_flags.html#DB_OVERWRITE">DB_OVERWRITE</a> flag. This option is only effective in the 61presence of fixed-block filesystems, journaling or logging filesystems 62will require operating system support and probably modification of the 63Berkeley DB sources.</p> 64<p>While all user data is encrypted, parts of the databases and log files 65in an encrypted environment are maintained in an unencrypted state. 66Specifically, log record headers are not encrypted, only the actual log 67records. Additionally, database internal page header fields are not 68encrypted. These page header fields includes information such as the 69page's <a href="/api_c/lsn_class.html">DB_LSN</a>, number, and position in the database's sort 70order.</p> 71<p>Log records distributed by a replication master to replicated clients are 72transmitted to the clients in unencrypted form. If encryption is 73desired in a replicated application, the use of a secure transport 74is strongly suggested.</p> 75<p>We gratefully acknowledge:</p> 76<p><ul type=disc> 77<li>Vincent Rijmen, Antoon Bosselaers and Paulo Barreto for writing the 78Rijndael/AES code used in Berkeley DB. 79<li>Steve Reid and James H. Brown for writing the SHA1 checksum code used 80in Berkeley DB. 81<li>Makoto Matsumoto and Takuji Nishimura for writing the Mersenne Twister 82code used in Berkeley DB. 83<li>Adam Stubblefield for integrating the Rijndael/AES, SHA1 checksum and 84Mersenne Twister code into Berkeley DB. 85</ul> 86<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> 87</td></tr></table> 88<p><font size=1>Copyright (c) 1996,2008 Oracle. All rights reserved.</font> 89</body> 90</html> 91
