Thoughts on droplets
Tue, 2 Nov 1999 10:39:48 -0800 (PST)
> > I think it is highly probable that there is no means to
> >assure that an outside TCB can be trusted. Currently,
> >attempts to achieve this are based on secret hardware.
> Nonsense. straightforward cryptography. This is
> not the same as secret
> hardware -- the security rests in the
> mathematics, not in some undisclosed
> property of the hardware.
So this hypothetical hardware contains only publicly
available algorithms and no secret keys?
In order to create trusted external TCBs, I believe you are
going to have to use a shared secret that is magically
protected from dissemination. I just don't believe in
magic. Worse, I believe accepting magic means giving
control over to the magicians, which allows them to make
> >Using trusted external TCBs also does not set the right
> >design tone for application developers. Surely you do
> >advocate applications being designed with 'secret' keys.
> Indeed not. I advocate a design in which there
> is a minimal amount of
> trusted software that provides the necessary
> security guarantees to the
> rest of the applications. This, in principle, is
> no different from what is
> true in E. Or do you mean to suggest that E has
> no security kernel?
There is nothing 'secret' about the E security kernel. E's
security does not rely on protecting a shared secret. Your
hypothetical hardware scheme does. How are you going to
convince application developers that it is OK for you to
use a shared secret, but that they should not do the same.
Please address the control issue. It is the most important.
How do you know that authority over the shared secret will
not give outside powers the ability to make additional
demands. Denying some party the secret hardware would
effectively shut them out of the market. This is a large
power that some people would like to wield.
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com