[EMAIL PROTECTED] wrote:
>
> Tom, that is a very good question and a very tough question in deed. Some
> thoughts as a first attempt to answer:
>
> It would not feel right to me if OCF would try to solve a generic problem of how
> to synchronize programs in different virtual machines. It would also not feel
> right if OCF would try to mess with operating system calls that are not in the
> list of function offered by every Java implementation on every platform.
> (Although I admid that we commited the first sin in that direction already in
> bringing "native Browser support" into OCF.)
>
> A way around this problem is the approach suggested and practiced by the
> colleagues from Sun. If I remember correctly it is called "UPI" but I don't
> remember the meaning behind the acronym. Basically it is a setup where OCF is
> used in a single server process that does all smart card accesses. All programs
> needing smart card functions request the services from this one server process.
> What bothered me with this approach is that the single process now is
> responsible for controlling who is authorized to do what type of communication
> with the smart card. Nevertheless it seems to be a solution to the problem you
> brought up again.
In Sun's Solaris 8 OS release, we have included OCF and associated application
libraries as part of the standard OS feature set. We have also modified a number
of applications to make them smart card-aware (CDE dtlogin/dtsession, PAM,
etc...). We needed to be able to consider the smart cards and card terminals
as shared system resources, much as disks and printers and other devices are
shared by multiple processes and users on the system. To acheive this goal,
OCF is run as a daemon that is started by inetd.conf (sorry for the UNIXisms
here, please bear with me). Applications link with a shared library or include
a jar file in their CLASSPATH. If an application is a Java application, is
uses the classes in the jar file to communicate with the OCF daemon, and
if the application is not a Java application (and hence doesn't want to have
the burden of instantiating a JVM just to do smart card-related tasks) those
applications link with a shared library that is written in C and which
communicates with the OCF daemon. The applications themselves never actually
run OCF code in their JVM or address space.
The OCF daemon manages access to all the cards and card terminals on the
system, and one of the features it provides is the ability for an application
to request exclusive use of a card. Once exclusive access to the card is
granted by the OCF daemon, only applications executing under the same user
ID can access the card. The application libraries talk to the OCF daemon
using in-kernel RPC calls, which provide a mechanism for the OCF daemon to
determine the UNIX user ID of the application that is making a particular
RPC call to the OCF deamon. We wanted to be able to sign each transaction
between the application and the OCF daemon, but product release schedules
don't wait for nobody :-) so we never took that extra step.
The Solaris 8 work that I described built on the work we did in SunLabs
with the UPI concept and refined it so that it could provide a secure
and robust set of system services for smart cards and card terminals.
As we did this work for Solaris 8, it became clear that we were burying
OCF deeply into our services layer and the interfaces that applications
really wanted to use were at a higher level than OCF provides - our apps
wanted to be able to call a single "authenticate this user" API which
the OCF daemon would implement based on configuration in the daemon
properties. So, the login app could call "authenticate user" which would
translate, at the OCF level, into calls that verified a PIN, checked
an on-card password, asked the card to sign some data and verify the
signature, and perform a challenge-response. The application itself
doesn't need the code to do all this - it is embedded in the OCF daemon.
The benefit that we derived from basing our work on OCF was that OCF
provides a standard interface that allows card terminal vendors to
write card terminal drivers to, and it provides a (somewhat) standard
interface for card and applet vendors to write card services to, although
the latter is still in a state of flux and our card services interfaces
to OCF have deviated from the "standard" in some ways. At first, we
thought that this would be a major problem, but as we wrote and modified
more applications to be smart card-aware, we realized that apps don't
really care (or want to know) if the underlying card and card terminal
layer is OCF or PC/SC or MSCIL (Mike'sSmartCardInterfaceLayer) - the apps
wanted higher-level APIs such as the "authenticate" API that I described
and a PKCS#11 and PKCS#15 API and an e-commerce API. Just as I don't
write code that opens the SCCI controller's raw command port and send
read and write block commands to my SCSI disk, I use the filesystem
calls to open, close, read and write files, applications don't, for the
most part, care about APDUs or opening the Master File on a card;
in many cases, applications don't even care whether the authentication
that is being done on their behalf is being done by a smart card
subsystem or a software-based stack such as AMI or NSS or PKCS#xx.
Sorry for the long-winded description, I hope someone found it useful.
mike
> Frank Seliger
> IBM Pervasive Computing Division
> Schoenaicher Str. 220, 71032 Boeblingen, Germany
> [EMAIL PROTECTED] Tel. +49-7031-16-3142
>
> [EMAIL PROTECTED] on 2000-01-22 00:54:56
>
> Please respond to "Tom McKearney" <[EMAIL PROTECTED]>
>
> To: [EMAIL PROTECTED]
> cc: (bcc: Frank Seliger/Germany/IBM)
> Subject: [OCF] cross-JVM support?
>
> Is there ever going to be a version of OCF that will support OS-level
> mutexing so that multiple JVMs can run OCF apps?
> I may have to dump OCF because of this.
> It's a big limitation.
> If you have 2 applications that need to hit the smartcard at the same time,
> OCF can't do this. They have to be all in the same JVM.
> What if you're running a Java App on your machine and you have a Netscape
> browser window running?
> You're running 2 JVMs and OCF can't handle that.
> OCF needs to have an OS-specific extension that allows cross-JVM resource
> mutexing so that it can handle multiple apps.
>
> So, is there a plan to fix this?
>
> Tom
>
> ---
> > Visit the OpenCard web site at http://www.opencard.org/ for more
> > information on OpenCard---binaries, source code, documents.
> > This list is being archived at http://www.opencard.org/archive/opencard/
>
> ! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
> ! to
> ! [EMAIL PROTECTED]
> ! containing the word
> ! unsubscribe
> ! in the body.
>
> ---
> > Visit the OpenCard web site at http://www.opencard.org/ for more
> > information on OpenCard---binaries, source code, documents.
> > This list is being archived at http://www.opencard.org/archive/opencard/
>
> ! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
> ! to
> ! [EMAIL PROTECTED]
> ! containing the word
> ! unsubscribe
> ! in the body.
--
----------------------------------------------------------------------------
Michael Bender E-Mail: [EMAIL PROTECTED]
Sun Microsystems, Inc. Tel: 650-614-6941
901 San Antonio Road Tel Pager: 888-423-9066
Palo Alto, CA 94303-4900 URL Pager: http://www.skytel.com/Paging/
Mailstop: MPK06-201 Pager PIN: 4239066
----------------------------------------------------------------------------
---
> Visit the OpenCard web site at http://www.opencard.org/ for more
> information on OpenCard---binaries, source code, documents.
> This list is being archived at http://www.opencard.org/archive/opencard/
! To unsubscribe from the [EMAIL PROTECTED] mailing list send an email
! to
! [EMAIL PROTECTED]
! containing the word
! unsubscribe
! in the body.
