<!--

$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.315 2005/04/23 03:27:40 momjian Exp $

$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.316 2005/05/08 03:29:06 momjian Exp $

-->

<chapter Id="runtime">

</sect1>

<sect1 id="encryption-approaches">

<title>Use of Encryption in <productname>PostgreSQL</productname></title>

<indexterm zone="encryption-approaches">

<primary>encryption</primary>

</indexterm>

<para> There is increasing interest in having verifiable mechanisms

to maintain the privacy of data in databases. In the United

States, legislation called <acronym>HIPAA</acronym> (Health

Insurance Portability and Accountability Act) requires that

personal health information is handled securely. The European

Union has similarly been developing directives as to how personal

data is to be managed there.</para>

<para> Questions frequently come up as to what functionality

<productname>PostgreSQL</productname> offers with regard to

supporting the use of data encryption. It uses and provides use of

encryption tools in several ways that may be useful to provide

protection against certain classes of attacks.</para>

<itemizedlist>

<listitem><para> Passwords stored in MD5 form </para>

<para> Passwords are normally not stored in

<quote>plaintext</quote> form in the database; they are hashed

using the built-in MD5 function, and <emphasis>that</emphasis> is

what is stored in the database. </para>

<programlisting>

sample=# alter user foo password 'some dumb value';

ALTER USER

sample=# select usename, passwd from pg_shadow where usename = 'foo';

usename | passwd

---------+-------------------------------------

foo | md5740daa4aaa084d85eb97648084a43bbb

(1 row)

</programlisting>

</listitem>

<listitem><para> Connections protected using SSL</para>

<para> There are various options to control how mandatory it is

to use SSL to protect data connections. At the most

<quote>paranoid</quote> end of the spectrum, you can configure

<filename>pg_hba.conf</filename> to have the database reject

connections that do <emphasis>not</emphasis> come in via

SSL.</para>

<para> The use of SSL, alone, is useful for protecting

communications against interception. It may not be necessary

for connections that take place across a carefully controlled

network; if connections are coming in from less controlled

sources, its use is highly recommended.</para></listitem>

<listitem><para> Connections authenticated using SSL</para>

<para> It is possible for both the client and server to provide

to one another SSL keys or certificates. It takes some extra

configuration on each side where these are used, but this likely

provides stronger verification of identity than the mere use of a

text password. </para></listitem>

<listitem><para> Using OS level encryption for entire database

partitions</para>

<para> On Linux, encryption can be layered on top of a filesystem

mount using what is called a <quote>loopback device;</quote> this

permits having a whole filesystem partition be encrypted on disk,

decrypted by the operating system. On FreeBSD, the equivalent

facility is called GEOM Based Disk Encryption, or

<acronym>gbde</acronym>.</para>

<para> This mechanism may be expected to be useful for protecting

against the threat that someone might pull disk drives out and

try to install them somewhere else to draw data off of them.

</para>

<para> In contrast, this mechanism does nothing to protect

against attacks when the filesystem is mounted, because when

mounted, the OS provides a <quote>view</quote> of the filesystem

accessible in plain text form. Furthermore, you need some way

for the encryption key to be passed to the operating system in

order to mount the filesystems, which encourages having the key

accessible somewhere on the host that mounts the disk.

</para></listitem>

<listitem><para> Using the contrib function library

<function>pgcrypto</function> so the database engine manages

encryption of certain fields.</para>

<para>If much of the data can be in plain text form, and only a

subset is particularly sensitive, this mechanism supports

treating them differently. The encrypted data is only ever

presented in <quote>unencrypted</quote> form while it is being

communicated between client and server, and the use of an SSL

layer of <quote>superencryption</quote> alleviates that

problem.</para>

<para> Unfortunately, in this approach, the encryption keys need

to be present on the server, even if only for a moment, which

presents the possibility of them being intercepted by someone

with access to the database server. As a result, this mechanism

is not suitable for storage of data that is too sensitive for

system administrators to have access to it. </para></listitem>

<listitem><para> Using cryptographic tools on the client </para>

<para> If it is not safe to trust the system administrators at

least somewhat, you may find it necessary to encrypt data at the

client level such that unencrypted data never appears on the

database server. This sort of <quote>paranoia</quote> is quite

appropriate for applications where it would be damaging for data

to be seen by inappropriate readers that might generally be

considered trustworthy, as can be the case with

medical and legal records.</para>

<para> Peter Wayner's book, <citation>Translucent

Databases</citation>, discusses how to do this in considerable

detail.</para></listitem>

</itemizedlist>

</sect1>

</chapter>

<!-- Keep this comment at the end of the file