From: Adam Shostack <adam@lighthouse.homeport.org>
Date: Tue, 30 Jan 1996 15:18:43 +0800
To: raph@c2.org (Raph Levien)
Subject: Re: Authentication of crypto clients
In-Reply-To: <Pine.SUN.3.91.960129160857.27262A-100000@infinity.c2.org>
Message-ID: <199601300532.AAA05850@homeport.org>
MIME-Version: 1.0
Content-Type: text


Raph Levien wrote:
| This post contains (somewhat) technical discussion of (what I believe
| is) an important issue in integrating crypto with applications that do
| not contain their own cryptographic implementation. If that doesn't
| interest you, hit 'n' to resume your regularly scheduled flamefest.
n  (Sorry, couldn't resist. :)

	A crypto provider can't protect itself from requests to do
things.  What it might be able to do is find out what program is in
that memory space and tell the user "FV keyboard scanner would like to
run IDEA on 128 bytes of data.  Allow?"

	There are flaws in this 'whos that knocking on my door?'
approach.  The first is that programs might be able to claim to be
other programs.  I know under UNIX, its pretty trivial to change
argv[0] and make a program show up as something else in the process
list.  Is this easy on Macs & PCs?  (I know its possible, due to a
lack of protected memory.)

	My next suggestion would be for services to register with the
crypto provider, and pass some token back and forth.  Admittedly, an
evil service could look for the token, then attempt to morph into a
good program, then request crypto services, but we're begening to
stretch.

	There might be a benefit to having programs do this, becuase
it makes the task of a trojan or worm more difficult, and looking over
the viruses out there, most of them are pretty simple, and don't do a
lot to interact cleanly with the OS.  (This is because most viruses in
the wild are PC viruses, and PCs don't have OSs, they have program
loaders. :)  Seriously, there are **far** fewer Mac viruses, and a
free program to reliably catch all of them.  I'd strongly suggest that
this is because programming a Mac virus to interact with the computer
cleanly is tricky.

	WRT Premail, what yummy crypto tokens does it store?  I'll
apologize for not being up on its exact capabilities.

Adam

| The issue is: how does the crypto provider authenticate the client?
| For example, if the crypto provider can accpet connections from any
| application in the user's process space, then any bogus application
| can easily start decrypting and signing as it likes. In this model, a
| precondition for security is that no bogus programs can be allowed to
| run.
|
| An alternative, slightly more complex model is that the client must
| somehow authenticate itself to the crypto provider. One simple way of
| doing this is to require the client request a password from the user,
| which is then forwarded to the crypto provider. The crypto provider
| will only provide service on connections which have been authenticated
| in this way. This model gives security even in the face of some bogus
| applications.
| 
| Of course, as Nathaniel quietly reminded us this morning, any bogus
| application which can intercept keystrokes can subvert any such client
| authentication. Barry Jaspan (in his analysis of a security flaw in
| SSH 1.2.0) reminds us that access to the image of the process is also
| sufficient to break security. Perhaps the class of bogus programs
| which have enough capabilities to connect to the crypto provider, but
| not enough to intercept keystrokes or examine RAM is null, meaning
| that the two models have equivalent security. Actually, the simpler
| model has some security advantages, because the client never has to
| deal with any very sensitive material, such as the password.
| 
| I'm interested in this question right now because the current version
| of premail implements the simpler model (in fact, it simply stores all
| the secrets in a file in /tmp, with permissions set to 600). I want to
| know whether it's worth the trouble to design and implement an
| approach based on per-client authentication.
| 
| This issue is also relevant to the discussion of Microsoft's CAPI,
| which (as far as I can tell) allows only the simpler model. I'm not
| saying it's bad, but I do feel that the implications should be
| discussed. Thus, I have forwarded a copy of this post to
| cryptapi@microsoft.com in case they have any comments.
| 
| If there's been a discussion of this that I missed, then apologies for
| brining it up again and appreciation in advance for any pointers.
| 
| Raph
| 


-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume