Authentication of crypto clients
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. 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
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
-----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-----
participants (4)
-
Adam Shostack -
andreas＠horten.artcom.de -
Nathaniel Borenstein -
Raph Levien