You might consider Trusted Oracle. Basically you need to sign each message
with a valid authorization key (hence make it tamper proof). You would have
to use some sort of public key encryption. At least that seems the right
way to go. (think of each row as a message and have an extra column that is
a hash of the message, or digital signature)
Jim
<kmv_dev_at_yahoo.com> wrote in message
news:20020824204708.48df9a79.kmv_dev_at_yahoo.com...
> On Sat, 24 Aug 2002 21:10:55 +0200
> Sybrand Bakker <postbus_at_sybrandb.demon.nl> wrote:
>
> > On Sat, 24 Aug 2002 11:21:57 -0700, kmv_dev_at_yahoo.com wrote:
> >
> > >Hi,
> > >
> > >Can someone suggest ideas on how to build a tamper-proof
> > >server? i.e. I want to let my applications (an appserver)
> > >to access the db, insert, and do whatever it needs to
> > >complete the task. But once the transaction is committed,
> > >all events must be logged, time-stamped and digitally
> > >signed, and none of the records can be removed/modified
> > >(not even by a dba).
> > >
> > >Any suggestion is welcome.
> > >
> > >xx
> >
> >
> > Build your server, seal it, remove the keyboard, and sink it to the
> > bottom of the sea, and then you will have a tamper-proof server.
> > Other than that, your idea, bore out of distrust of everyone
> > including dba's, is just ridiculous.
> >
> > Regards
> >
> >
> > Sybrand Bakker, Senior Oracle DBA
> >
>
> It's not ridiculous, and sorry to offend the dba in you :)
>
> There's a need to build tamper-proof that must support
> secure audit trail. Every event and transaction must be
> traceable.
>
> It's not that we can't trust the dba. If we can't, then
> we won't hire the person, period. But we need to have
> proof in front of the law. In court, no proof, no shit.
> That's where secure audit trail comes in. And we have
> to be able to prove, like any case, beyond reasonable
> doubt.
>
> I'm not dba, and I'm asking the question if this is
> possible, and if anyone has any idea of how people
> would approach this problem. We are evaluating
> a platform to support secure audit trail end-to-end,
> that's all.
>
> xx
Received on Sun Aug 25 2002 - 00:07:20 CDT
