Edit File - File Manager

Edit File: encrypt.html

<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"></a>
<table width="100%"><tr valign=top>
<td><dl><dt>Berkeley DB Reference Guide:<dd>Environment</dl></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>
Encryption
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.
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-&gt;set_encrypt</a> or
<a href="../../api_c/db_set_encrypt.html">DB-&gt;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.
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 <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-&gt;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.
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.
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:
<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> </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>
Copyright (c) 1996,2008 Oracle. All rights reserved.
</body>
</html>

Back to File Manager