On Mon, Feb 16, 2004 at 10:40:36PM +1100, Chris Nolan wrote: > Hello Vadim! > > On Mon, 2004-02-16 at 21:28, Vadim Fedukovich wrote: > > Dear Chris, > > > > authentication methods and protocols were researched for years. > > > > The method described is an easy one and probably could be implemented fast. > > However, one better start from requirements before any coding. > > For example: server is not authenticated here so man-in-the-middle > > is allowed by design > > Firstly, thanks for your reply! :-) > > The public key will be verified against a root CA. The public keys used > are all issued by a health organisation that is part of the federal > government of Australia.
this would unlikely stop the Trudy from pretending to be the server for a legitimate user and the user for the real server. He could pass a PKCS7 Enveloped from server to user and pass the hash back, isnt it? Maybe the hardware used and watched could stop this in case of properly controlled environment but it would definitely go over public network. Please consider to use SSL (client certificates) as well as well-known solutions from "authentication" chapter of some good crypto textbook Anyway, please consider requirements (threads) first, implementation next. > I'm a final-year software engineering student, so I can totally > understand and agree with your statement regarding man-in-the-middle > attacks and starting with requirements(the person-in-the-middle is named > Trudy according to Andy S Tanenbaum). > > My reason behind selecting this authentication method is that the user > will already have needed to enter two passwords - one to access their > cryptography store (I have no choice here - the API used to access the > authentication tokens is provided by the government body in question) > and another to access the private keys on their token (for signing and > decryption). Avoiding a third password actually makes sense in this > case, as many of the target audience would have a tendancy to have very > similar (if not identical) passwords across all domains. this would unlikely help to avoid Trudy as outlined > I'm doing some tinkering at this point. I can't use the provided API on > my chosen server platform (Linux) or any other platform as it relies on > the excellent SQLite which uses database-level locking. As the server > software is required to service 100s of concurrent sessions, the very > coarse-grained locking (and thus low concurrency is inappropriate). yes, it is important that your solution would do the job and provide a reasonable level of performance. It might be no less important to foil the threads according to security requirements You are not required to publish all the details but you'd better to have them documented first regards, Vadim > After I am done with this project, I intend to contribute to the OpenSSL > documentation, so any help that anyone gives me will not be wasted on my > small brain. :-) > > Regards, > > Chris > > > > regards, > > Vadim > > > > On Mon, Feb 16, 2004 at 06:48:26PM +1100, Chris Nolan wrote: > > > Hi all, > > > > > > I'm working on building a client-server setup for an application > > > involving Smartcards. I have a library for Smartcard access on the > > > Windows side and was hoping to do the following for authentication: > > > > > > 1. Using a certificate that contains the client's public encryption key, > > > send a PKCS7 message to the client. > > > 2. Get the client to send me a hash of the decrypted content. > > > > > > The problem is, wrapping my head around what to call and in what order > > > on the server side. The man pages are good, but don't really give me > > > much insight as to the structure of the API. > > > > > > Can anyone point me in the direction of some examples on how to do this? > > > The reason I want to use PKCS7 is because the library on the client side > > > is already setup to do this with a single C function call. > > > > > > Regards, > > > > > > Chris > > > > > > ______________________________________________________________________ > > > OpenSSL Project http://www.openssl.org > > > User Support Mailing List [EMAIL PROTECTED] > > > Automated List Manager [EMAIL PROTECTED] > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > User Support Mailing List [EMAIL PROTECTED] > > Automated List Manager [EMAIL PROTECTED] > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
