Authentication of crypto clients

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

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "Raph" == Raph Levien <raph@c2.org> writes:

    Raph> The issue is: how does the crypto provider authenticate the
    Raph> client?

If you consider the client to be untrusted software, I'm afraid the
answer is probably not at all.

Andreas


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAgUBMQ2eeUyjTSyISdw9AQG6RgP+KNg7GbFVvs+L2AxmyWL6rsBBZ8lB7gX9
ZrK7Xros5SclXVmxqIPdlJsl6KqzrTCkk21ZzDsAtbvRCPdaEHouQ2l5tPqMr3BY
OQYpL7+hQmq9KHuh6VT8YLYn3JqMMcPevOb922wd2WpC2VlyjrPDY31sEwRizj2q
39UgEI/XMZE=
=zaAv
-----END PGP SIGNATURE-----

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

Excerpts from mail: 30-Jan-96 Re: Authentication of crypt.. Adam
Shostack@homeport.o (4311*)

> 	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....

Yeah, the flaws are pretty bad.  We tried this approach in "active mail"
systems back in the early-to-mid-1980's.  The user was asked to assess
his trust level for the email-received code that was trying to run.  The
problem we found was that even relatively sophisticated users were very
quick to be fooled into believing that the "From" address was
legitimate.  Similarly, I suspect that if I named my keyboard scanner
"Windows 95", most people would probably be fooled, and the fact that
your API asked the question would only make the user feel MORE secure
about saying "yes".....
--------
Nathaniel Borenstein <nsb@fv.com>
Chief Scientist, First Virtual Holdings
FAQ & PGP key: nsb+faq@nsb.fv.com