OK, here's a schema that I think works. It assumes the existence of a
connection broker process. The basic idea is that the connection broker
stores

<database, userName, encryption(server key, userPassword)>

and starts a database server on first valid reference. The database
server, in turn, uses page level encryption.

Here is the full order of battle for a database connection:

1. A client establishes a connection to the broker process.
2. The broker process exports a public key to the client
3. The client sends the database name, user name and password to the
broker encrypted by the broker's public key.
4. The broker decrypts the message and uses the database and user
names to look up an encrypted database encryption key, which it
decrypts using the password. It then uses the resulting database
encryption key to either start a new database server or to
validate the user against an already running database. In either
case, it returns the database port number and public key to the
client.
5. The client generates a random connection key that it encrypts with
the database public key, connects to the database server, and send
the public key encrypted session key to the database server.
Subsequent messages are then encrypted with the session key.

When a database user is created or a password changed, the database
server sends an appropriately encrypted message to broker containing the
database name, the user name, and the database page encryption key
encrypted by the user password.

The security of the system is limited only by the strength of user
passwords.

So what we have are the following keys:

1. A database page symmetric encryption key generated at database
creation time.
2. A database server public key pair generated by the database server
at start up time.
3. A broker public key pair generated by the broker at broker start
up time.
4. A symmetric session key generated by the client.

Nothing is saved on disk on the client, by the broker, or by the
database from which the database page encryption key can be computed
other than by the user password or brute force. Passwords, in turn, are
always transmitted encrypted.

On 11/3/2010 6:56 AM, sijun_kang wrote:
> It seems that "database encryption" was a topic previously discussed long time ago and it was concluded that encryption would not be more secure than obfustication in some scenarios. But still, I think there are other scenarios where encryption is the only methold to help secure the data. Since there are already some code (currently disabled) in the source, I wonder why it has never been released as a feature to the public? As mentioned in ticket "CORE-1913" (Firebird Core - Database encryption revisited, http://tracker.firebirdsql.org/browse/CORE-1913), in some applications, even the law requires encryption as a must-have. I wish this feature be made active as soon as possible. Any comment/insight on this? Thanks
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376



[Non-text portions of this message have been removed]