| Subject | Re: [Firebird-Architect] database encryption |
|---|---|
| Author | Jim Starkey |
| Post date | 2010-11-04T16:21:52Z |
That's the problem that certificates are designed to solve. A
solution goes like this:
1. On initial connection, the broker sends its public key and
certificate.
2. The client verifies the certificate chain and that the name on the
certificate matches the name of the server.
The does require believing that things like reverse DNS work and there
are no untrustworthy characters in the certificate chain.
But it's also outside the original problem, which is how to keep
unauthorized people with physical access to the database file from
reading it.
solution goes like this:
1. On initial connection, the broker sends its public key and
certificate.
2. The client verifies the certificate chain and that the name on the
certificate matches the name of the server.
The does require believing that things like reverse DNS work and there
are no untrustworthy characters in the certificate chain.
But it's also outside the original problem, which is how to keep
unauthorized people with physical access to the database file from
reading it.
On 11/4/2010 11:47 AM, Andrew Berg wrote:
> As you describe it, it also does not prevent against a man-in-the-middle attack
> between the client and the broker, but that could be rather easily fixed by
> using something like Diffie-Hellman at the outset.
>
> -a
>
>
>
> ________________________________
> From: Jim Starkey<jstarkey@...>
> To: Firebird-Architect@yahoogroups.com
> Sent: Wed, November 3, 2010 2:26:40 PM
> Subject: Re: [Firebird-Architect] database encryption
>
> I think it address the problem where database medium, e.g. the disk,
> are not provably secure. An example would be a database running in a
> public cloud. The database file, broker store, and database executable
> can be all be compromised or hacked without exposure of the database.
>
> What it does not do is authenticate a broker to the client, so a
> completely compromised server with a hacked broker could spoof a correct
> broker and break the scheme. There's probably a solution for this, but
> I'm going to leave it for somebody else to solve.
>
>
> On 11/3/2010 5:17 PM, Doug Chamberlin wrote:
>> On 11/3/2010 5:08 PM, Jim Starkey wrote:
>>> OK, here's a schema that I think works...
>> So that we can evaluate this scheme properly while thinking it through,
>> to which of the many use cases that have come up over the years is this
>> intended to apply? In other words what protection level is intended?
>>
>
--
Jim Starkey
Founder, NimbusDB, Inc.
978 526-1376
[Non-text portions of this message have been removed]