1<?xml version="1.0" encoding="UTF-8" standalone="no"?> 2<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> 3<html xmlns="http://www.w3.org/1999/xhtml"> 4 <head> 5 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> 6 <title>Encryption</title> 7 <link rel="stylesheet" href="gettingStarted.css" type="text/css" /> 8 <meta name="generator" content="DocBook XSL Stylesheets V1.73.2" /> 9 <link rel="start" href="index.html" title="Berkeley DB Programmer's Reference Guide" /> 10 <link rel="up" href="env.html" title="Chapter��9.�� The Berkeley DB Environment" /> 11 <link rel="prev" href="env_security.html" title="Security" /> 12 <link rel="next" href="env_remote.html" title="Remote filesystems" /> 13 </head> 14 <body> 15 <div class="navheader"> 16 <table width="100%" summary="Navigation header"> 17 <tr> 18 <th colspan="3" align="center">Encryption</th> 19 </tr> 20 <tr> 21 <td width="20%" align="left"><a accesskey="p" href="env_security.html">Prev</a>��</td> 22 <th width="60%" align="center">Chapter��9.�� 23 The Berkeley DB Environment 24 </th> 25 <td width="20%" align="right">��<a accesskey="n" href="env_remote.html">Next</a></td> 26 </tr> 27 </table> 28 <hr /> 29 </div> 30 <div class="sect1" lang="en" xml:lang="en"> 31 <div class="titlepage"> 32 <div> 33 <div> 34 <h2 class="title" style="clear: both"><a id="env_encrypt"></a>Encryption</h2> 35 </div> 36 </div> 37 </div> 38 <p>Berkeley DB optionally supports encryption using the Rijndael/AES (also known 39as the Advanced Encryption Standard and Federal Information Processing 40Standard (FIPS) 197) algorithm for encryption or decryption. The 41algorithm is configured to use a 128-bit key. Berkeley DB uses a 16-byte 42initialization vector generated using the Mersenne Twister. All 43encrypted information is additionally checksummed using the SHA1 Secure 44Hash Algorithm, using a 160-bit message digest.</p> 45 <p>The encryption support provided with Berkeley DB is intended to protect 46applications from an attacker obtaining physical access to the media on 47which a Berkeley DB database is stored, or an attacker compromising a system 48on which Berkeley DB is running but who is unable to read system or process 49memory on that system. 50<span class="bold"><strong>The encryption support provided with Berkeley DB will not protect applications 51from attackers able to read system memory on the system where Berkeley DB is 52running.</strong></span></p> 53 <p>Encryption is not the default for created databases, even in database 54environments configured for encryption. In addition to configuring for 55encryption by calling the <a href="../api_reference/C/envset_encrypt.html" class="olink">DB_ENV->set_encrypt()</a> or 56<a href="../api_reference/C/dbset_encrypt.html" class="olink">DB->set_encrypt()</a> methods, applications must specify the 57<a href="../api_reference/C/dbset_flags.html#dbset_flags_DB_ENCRYPT" class="olink">DB_ENCRYPT</a> flag before creating the database in order for the 58database to be encrypted. Further, databases cannot be converted to an 59encrypted format after they have been created without dumping and 60re-creating them. Finally, encrypted databases cannot be read 61on systems with a different endianness than the system that created 62the encrypted database.</p> 63 <p>Each encrypted database environment (including all its encrypted 64databases) is encrypted using a single password and a single algorithm. 65Applications wanting to provide a finer granularity of database access 66must either use multiple database environments or implement additional 67access controls outside of Berkeley DB.</p> 68 <p>The only encrypted parts of a database environment are its databases 69and its log files. Specifically, the <a class="xref" href="env_region.html" title="Shared memory regions">Shared memory regions</a> supporting the database environment are not 70encrypted. For this reason, it may be possible for an attacker to read 71some or all of an encrypted database by reading the on-disk files that 72back these shared memory regions. To prevent such attacks, applications 73may want to use in-memory filesystem support (on systems that support 74it), or the <a href="../api_reference/C/envopen.html#open_DB_PRIVATE" class="olink">DB_PRIVATE</a> or <a href="../api_reference/C/envopen.html#envopen_DB_SYSTEM_MEM" class="olink">DB_SYSTEM_MEM</a> flags to the 75<a href="../api_reference/C/envopen.html" class="olink">DB_ENV->open()</a> method, to place the shared memory regions in memory that 76is never written to a disk. As some systems page system memory to a 77backing disk, it is important to consider the specific operating system 78running on the machine as well. Finally, when backing database 79environment shared regions with the filesystem, Berkeley DB can be configured 80to overwrite the shared regions before removing them by specifying the 81<a href="../api_reference/C/envset_flags.html#set_flags_DB_OVERWRITE" class="olink">DB_OVERWRITE</a> flag. This option is only effective in the 82presence of fixed-block filesystems, journaling or logging filesystems 83will require operating system support and probably modification of the 84Berkeley DB sources.</p> 85 <p>While all user data is encrypted, parts of the databases and log files 86in an encrypted environment are maintained in an unencrypted state. 87Specifically, log record headers are not encrypted, only the actual log 88records. Additionally, database internal page header fields are not 89encrypted. These page header fields includes information such as the 90page's <a href="../api_reference/C/lsn.html" class="olink">DB_LSN</a> number and position in the database's sort 91order.</p> 92 <p>Log records distributed by a replication master to replicated clients are 93transmitted to the clients in unencrypted form. If encryption is 94desired in a replicated application, the use of a secure transport 95is strongly suggested.</p> 96 <p>We gratefully acknowledge:</p> 97 <div class="itemizedlist"> 98 <ul type="disc"> 99 <li>Vincent Rijmen, Antoon Bosselaers and Paulo Barreto for writing the 100Rijndael/AES code used in Berkeley DB.</li> 101 <li>Steve Reid and James H. Brown for writing the SHA1 checksum code used 102in Berkeley DB.</li> 103 <li>Makoto Matsumoto and Takuji Nishimura for writing the Mersenne Twister 104code used in Berkeley DB.</li> 105 <li>Adam Stubblefield for integrating the Rijndael/AES, SHA1 checksum and 106Mersenne Twister code into Berkeley DB.</li> 107 </ul> 108 </div> 109 </div> 110 <div class="navfooter"> 111 <hr /> 112 <table width="100%" summary="Navigation footer"> 113 <tr> 114 <td width="40%" align="left"><a accesskey="p" href="env_security.html">Prev</a>��</td> 115 <td width="20%" align="center"> 116 <a accesskey="u" href="env.html">Up</a> 117 </td> 118 <td width="40%" align="right">��<a accesskey="n" href="env_remote.html">Next</a></td> 119 </tr> 120 <tr> 121 <td width="40%" align="left" valign="top">Security��</td> 122 <td width="20%" align="center"> 123 <a accesskey="h" href="index.html">Home</a> 124 </td> 125 <td width="40%" align="right" valign="top">��Remote filesystems</td> 126 </tr> 127 </table> 128 </div> 129 </body> 130</html> 131