On 03-11-2010 19:08, Jim Starkey wrote:

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

And this solves what, really?

People already can put the files behind the TCP server, as nobody need
direct access to the database.

And most people wanting encrypted or password-protected databases wants
that because they want to distribute their database to others but do not
want they to see the data from outside their applications.

Then, they're going to put the broker together with the server to have
the weak encryption they thinks is ok.


Adriano