[ZODB-Dev] Encrypted Storage / XML Documents

John J Lee jjl@pobox.com
Fri, 4 Apr 2003 15:47:27 +0100 (BST)


On Mon, 31 Mar 2003, Nick Pavlica wrote:

>   1) Is  there an encrypted or secure storage for ZODB?  I want to protect the
> data in the storage, even if the user gains full OS access to it.

That sounds hard / impossible.  I think you need to be clear about
precisely what you're trying to achieve.

Doesn't one of sleepycat's BSDDB packages have encryption in some form?
Perhaps the BSDDB Storage can use that, or be modified to use it.

Have you considered simply putting everything on an encrypted filesystem?
Something like loop-AES on linux, for example -- fast and transparent, and
works either direct from a partition or from a regular file.

Now the "but"s.

loop-AES, by its nature, only offers any protection when the filesystem is
unmounted.  If, OTOH, you want multiple encrypted files / filesystems,
you're still going to have to decrypt them before access.  Also, the
keys/passwords have to be stored somewhere.  So anyone with 'full OS
access' (root / Administrator access?) may be able to read the keys or the
data, or both.  Given that, your data may be almost as vulerable as it
would be in plaintext.

A quote from the sleepycat website:

http://www.sleepycat.com/docs/ref/env/encrypt.html

| 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.*

Maybe if the data is mostly BLOBs (binary large objects), or can be
treated as such, you could arrange that the BLOBs are kept encrypted, and
that the server never decrypts them at all.  Of course, you then have a
key distribution problem.


John