RE: ArcotSign (was Re: Does security depend on hardware?)

[Bruce Schneier <schneier@counterpane.com>]

At 08:43 AM 9/21/98 -0700, Todd S. Glassey wrote:
>Hey Bruce,
>doesn't this response of yours imply that the OS is what is comprimised?,
>that either the access models and control of the File System on the target
>system (that is the one with the million PW's strewn about the disk file
>system) is setup wrong or is just not functional. Otherwise why would I want
>to take up critical disk space with a management process that had to manage
>a million disk-based entities.

It's not that much disk space.  The million entries was a methphor.  They use
mathematics instead of raw disk storage.

>Oh and BTW - a simple runtime profiler (i.e. most of the runtime debuggers
>will suffice if they have trace capability) will crack which password is the
>right one, and I don't even need physical access to the machine to run it in
>Microsoft Land. Now if they used the CertCo model and split the key/pw into
>several sections and signed or encrypted them separately so that essentially
>you have a holographic PW its harder, but the Runtime Profiler is still
>capable of creating havoc in this model, I think.

Of course.  It's less secure than hardware solutions.

>That is exactly the point why SW alone solutions cannot provide the levels
>of trust that some forms of commerce require. If the OS is untrustworthy and
>you have to replicate the components of the system to confuse an intruder as
>to which is the "active entitiy"... then whats to stop the same person from
>building a sleeper or coopting the User Memory Space. It seems to me that
>this effort will just stop people that are cruising through others
>filespaces in search of gold.

Agreed.  Think of AOL as the ideal user for this idea.  They want something
a little more secure than passwords, but don't want to spend the money on
hardware.  Passwords can be guessed, or sniffed.  This system doesn't
allow passwords to be guessed, and there are some more additions to 
prevent sniffing (all pretty standard).  Sure, if the client machine is
compromised (installing a sniffer, etc), there is no security, but that's not
the real threat.

>As far as commercial trust models are concerned this solution, IMHO, is less
>than desirable and in some instances covers up but does not fix, various
>liability models for a complete system.

Sure.  But it's good enough for some things.

>It seems to me (standard disclaimers apply here), that in the real world,
>the best way to operate is to trust no one,  not your OS, not your ISP, and
>especially not your own people. What that mandates is that there is some
>"anchor process" that binds both policy and the systems that implement it to
>the firmament. I believe that this is the key to making tools like CDSA and
>others (OpSec) more functional. Besides, Imagine the strength of an audit
>process based upon one of these immutable policy anchors.

That's not the best way to operate in the real world.  I'd much rather have
friends, get married, and have a fun life than to trust no one.  I'd much
rather
take the occassional hit rather than sit alone in the dark holding a gun.
This
is the real world of ninny net users in chat rooms, this isn't online real
estate.

Bruce
**********************************************************************
Bruce Schneier, President, Counterpane Systems     Phone: 612-823-1098
101 E Minnehaha Parkway, Minneapolis, MN  55419      Fax: 612-823-1590
           Free crypto newsletter.  See:  http://www.counterpane.com