On 11/17/2010 5:34 AM, Milan Babuskov wrote:

> Jim Starkey wrote:
>> Here is the architecture:
>>
>> 1. Servers generate RSA key pairs at startup time. They may, if they
>> wish, generate new key pairs anytime they wish.
>> 2. On first connection to a server, the client is given the server's
>> public key and a list of supported encryption algorithms.
>> 3. The client selects an algorithm, generates a one-time session key
>> using a secure random number generator, encrypts the algorithm
>> type and session key using the server's public key, and sends the
>> gook to the server
>> 4. The server decrypts the gook with its private key.
>> 5. Passwords are stored in the database as SHA-1 hashes
> Hi Jim,
>
> while this kind of architecture is completely reasonable for
> public-facing systems, it is not appropriate for Firebird. Any kind of
> public key mechanism like this one is susceptible to man-in-the-middle
> attacks. The only thing that makes it work is that you have a hierarchy
> of CAs and digital signatures covering all the trusted keys. That scheme
> is perfect for a SSL web server that requires the client to be online
> anyway, and also expects access from anonymous clients.

You're right about the man in the middle vulnerability. Perhaps a more
serious problem, however, is authentication of the server to the
client. I've pretty much given up on this approach.

I think my requirements are these:

* Client is authenticated to the server
* Server is authenticated to the client.
* Immunity to man in the middle attacks
* Resistance to dictionary attacks
* No requirement for either server or client certificates
* Database / account / password based authentication.

My current thinking is this:

1. An authentication key is form by the SHA-1 of the concatenation of
user name, database uuid, and password.
2. The client generates a random session key
3. The client encrypts the session key with AES and send it to the server
4. The server decrypts the session key and uses it for subsequent
communication (RC4 by default)

The server will stop responding to an account after n successive
failures for an account for progressively increasing time to thwart
dictionary attacks.

The reason that I'm considering rolling my own is to minimize connection
cost and latency. I haven't ground the numbers yet, but I'm presuming
that an AES connection handshake is computationally cheaper than TLS,
Diffie-Hellman, or SRP. If it isn't substantially cheaper, I'll going
with a standard protocol.

> Establishing a common CA which would provide digital signature for keys
> of every Firebird installation worldwide does not seem likely.
>
> However, it is assumed that when deploying your Firebird applications,
> you have control (or access) to both client and server side. Why not
> simply use a scheme like SSH or ZeBeDee?
>
> This means that you would create a public/private key pair for each
> client and have something like authorized_keys on the server, similar to
> SSH or ZeBeDee. You distribute private keys to clients and keep the
> public keys on the server. Upon connection, the server generates a
> symmetrical key (that uses some quick algorithm) which will be used for
> further communication. The server encrypts this key using client's
> public key and sends it. Since the client is the only party being able
> to decrypt that message, it prevents from man-in-the-middle attach.
>

Distributing keys to clients doesn't quite work if you want to support,
say, a hundred thousand iPads and the database is running on a couple of
dozen nodes during prime time throttling back to a half dozen when
everyone else should be sleeping.


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



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