________________________________________________________________________

Message: 15
Date: Wed, 10 Jan 2001 08:42:48 -0300
From: "Mauricio Longo" <mlongo@...> <mailto:mlongo@...>
Subject: Re: Re: Nailing down the external file problem.

Hi,

>Nowadays, before you give your mother a kiss you have to present her a few
>chalenges from your childhood to see if it's really her and not an
>impersonator. [:-)]

At least she usually knows her maiden name ;-).

> >
> > This is basically the case in most server environments, that run
> > unattended. The private key sits somewhere or the password to acess
> > the encrypted key does (host name or something). If you are serious
> > then you have hardware boards where the private key never leaves it.
> >
> > It is important the realise that if the server is compromised then the
> > local programs can be manipulated and then basically you are stuffed
> > (Ok there are some cases with hardward crypto and both client and
> > server certificates...).
> >
> >

>I'd leave open an alternative that is not too complex to store the private
>key on the server.

I think we can set up a range of options, but even simple can be fairly secure.

>Considering that no system is safe, Phil Zimmerman
>(creator of PGP), repeatedly points out in his PGP documentation that you
>are responsible for the safety of your computer. PGP trusts that the system
>is free of virus and trojans and so makes
>no effort to defend itself from these aggressors.

I agree, thats why on your server its not fatal to have private keys/passwords stored in the clear. Thats how your web server works.

>I've been working in a PKI related project for over 3 years now.

Well it looks like we have good company to assist with the design, review (and coding ;-).

>Only
>recently I've come to understand that you are never paranoid enough to stop
>everyone and that there is a point where you might actualy stop yourself and
>your system with too much security complexity without actually achieving
>your goal of stopping invasion.

Most companies do that when they install a firewall and chop off all the ports, suddenly ftp doesnt seem to work etc etc ;-).

>> > > Not so. Here is a simple scheme that works:
>> > >
>
> >
> > I know you said simple, but it's basically points the right way to go,
> > so here are my comments on what can be added (Im going for a complete
> > PKI solution with a CA not just generate a RSA keypair on the fly):
> >


>A complete PKI solution is cartainly the way to go, once you start down this
>path. This would, also, vault InterBase right to the top of the stack of
>dabase servers, where PKI enabled solutions are required.

Well we are currently in the gutter.

>It seems that
>Oracle started down this path but in a road full of bumps. (I've heard
>several serious security problems related, including one where you are
>allowed to upload Java code that will have complete access to the data in
>the database and can so return such data to you, even though you do not
>access previleges to that data.

I think Oracle are firing in all directions at once, certainly from what I've seen, and Im not supprised they shoot themselves in the foot occasionally. I think we would require all UDF and java code to be provided on the server, and placed there by the SYSDBA.

>> > > 1. Server generates a public key encyption key pair at startup
>> > > time.
>
> >
> > Server generates install or at user discression a root CA certificate.
> > The Ca cert private key is held encrypted (usually 3DES) and requires
> > a user entered password to be used.
> >

From what I've heard Blowfish or TwoFish might be better options of
symmetric algorithms. I've heard that there are known attacks that can be
used in most variants of DES, including 3DES, that significantly reduce the
work involved in a brute force attack, while no such attacks have been
discovered for Blowfish (TwoFish is after all younger, but also with no
known vulnerabilities.)

3DES seems to be acceptable for storing passwords. commerically (banks seem to be happy with it ;-, Speak any of the others and they seem to get itchy feet (only my experience). But SSLEAY and others usually come with a range of cypher routines, so it can be made configurable. (Does anyone remember the name of the recent DES replacement, was it the french one?, I think TwoFish was also a candidate?).

> > A server certificate and private key is generated, the server private
> > key is stored on disk accessible only to the server process, perhaps
> > encrypted with a local password.
> >
> > Having a PKI CA structure leaves open the option then that the client
> > can authenticate that the server is valid (handy across the internet).
> > And the possibility of generating client certificates at some stage as
> > well which is a bit tougher login process than just a password and is
> > also useful.
> >
> >

>Specially if it is possible, but not required that you use a certificate
>from an authority such as Verisign. I believe however that you should be
>able to create your own CA and sign your own certificates without having to
>pay for it.

Definately, (and SSSLEAY has complete CA code).

>One cheap alternative hardware nowadays is the mini-key.

Haven't heard of that one, is it the "tag" type one that clicks into the serial port, sort of like those software copy protection lock devices used to?

Realistically a software solution will work well, and can easily be expanded to support hardware devices.

> > I think the PKI works well, since it would allow the client to
> > authenticate the server avoiding man in the middle, attacks.
> >

>Couldn't agree more. It would also be very good marketing-wise. It would
>associate InterBase with a technology that considered "state of the art" at
>this time.

I agree, I also think we have to do it to get us back some credibility.

> > Also it is fairly easy to extend the above into an true SSL session,
> > if the client has a certificate generated by the same CA. The
> > possibility of sharing the CA amongst several servers is also
> > possible.
> >
> >

>Very good addition, SSL would give us standards complient encryption between
>client and server which would be a very nice marketing touch too. After
>all, people need good reasons to move from other DBs to InterBase and a free
>DB that offers better support for market standards is a very atractive
>alternative, from my point of view.

SSLEAY also has SSL (and the new one as well (is it TLS?)). Also need to check out openssl which as I said is the successor..

But this will all take some time (not heaps but 2-3weeks full time). That is going to be the problem for a part time
Cheers

Mark


--
Your database needs YOU!
http://firebird.sourceforge.net



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