Hi,
Wonderful discussion. I hope this generates a bit of traffic. I have been
struggling with this one myself. This is something to be considered with
Apple's OS X smartcard infrastructure and I have had alot of discussion
with Apple people about this.
First, I would love it if someone had a glorious solution for this. If you
do, please don't hesitate to mention it.
At some point in the middleware there needs to be some higher level channel
management. PC/SC provides rudimentary channel management for applications
to share a reader or readers but we are now discussing channel management
dealing with cards.
Here are some ideas - some bad and good in their own ways.
Each application maintains an exclusive right to the reader and when they
are finished reset the card on disconnect. One plus is that this prevents
another application from using previously authenticated portions of the
card. The negative is that the application on connect again must
re-authenticate to the card. Maybe the application will request the PIN
every time or cache it in some way. In PC/SC it is possible to session
steal by guessing the random hCard handle which is a 32 bit number. One
possibility is to change the DWORD in SCARDHANDLE to a struct which holds a
128 byte key to make the guessing much more difficult. To the application
it would be transparent but it is a change to the original PC/SC design.
Alternatively, there could be a middleware that does this. It tracks
applications and provides a PC/SC API which calls the PC/SC API's and
maintains a list of PIN's and states and changes state when another
application requests a reader. This middleware would have 1 exclusive
contest to a reader and share it and provide a state machine for
applications. Here the PIN is cached and all PIN's would be cached at one
location - not so good from a security standpoint.
In Mac OS X there is something called Mach IPC which allows the kernel to
restrict application access by certain parameters. For OS X this would be
a solution but this does not exist for Linux, Solaris, or others. It is a
pain to constantly ask the user a PIN but currently most cards don't
support channel management which would be the best solution for this
problem in my opinion.
We must figure that there could be alot of things to maintain state on such
as file pointer location, directories, PIN's, and key authentications which
will all be card dependant and it is difficult to abstract these across all
types of cards.
If caching is the option, how and where do we cache the PIN - middleware or
the application. If the card supports channel management it would be ideal
if the card required a cryptogram for each command that is transacted and
the card itself would maintain state. This would require a bit more
complicated structure on the cards which many are not ready for at this
time but I don't think we are too far away from having cards with this type
of functionality since we can run Linux on some PCMCIA cards right now.
Next, we must consider session stealing. At what point do we protect this
from occurring. If a user has root access they can modify the kernel and
track kernel calls which would give the cryptogram on even session managed
cards. Even if the PIN is cached at the application we still must consider
a superuser poking around at memory. At what point do we give up ?
These are some thoughts to be considered. Steven, I appreciate your long
discussion because I think it is necessary to have in order to use
smartcards in a suitable way.
Best Regards,
Dave
>On Wed, Oct 04, 2000 at 06:40:03PM -0500, David Corcoran wrote:
>> Also, if you have an interesting project that you are using pcsc-lite
>> please contact me and tell me - I'm always interested to hear what people
>> are doing.
>
>I'm struggling with a few concepts in applications I've been playing
>around with in how pcsc integrates with the rest of the operating
>system, Linux in my case.
>
>I'm interested in how people are using pcsc as well. I have been
>playing with openssh for example. My ultimate goal would be a general
>authentication service utilizing smartcard services, but I wonder
>about a lot of design decisions.
>
>In my brief hacking of openssh, I started modifying their ssh-agent.
>This service allows for initial startup of the agent and sign in when
>adding private keys to the agent. In my case I faked out the agent and
>instead added the smartcard services as my private key. That way, any
>time I used ssh, it would 'naturally' consult the agent for RSA
>authentication and away it went with no user interaction. The initial
>goal of the agent is to give the user a seamless experience when using
>RSA authentication with ssh. My integration with pcsc provided the
>same experience but I was just playing with it and hardcoded CHV
>verification into the agent. Obviously this is not a real solution.
>Now when turning to a real implementation, I run into some practical
>problems.
>
>The first is when to do CHV. I could do it every time I access the
>card, but this would mean interaction with the user every time they
>used the smartcard. I could store the CHV, but that's next in line to
>doing private key processing on the host, I didn't want to store
>sensitive information on the host hence my purchase of the smartcard.
>I could sign into the card and leave it open. Is this possible or
>desirable? Would this lock the card from use with other applications?
>
>Then I thought, what if I open the card when initially sign in and
>leave it open with some other sort of middleware and just access the
>middleware with all of my apps? Is this the real purpose of pcsc's RPC
>design? If that's the case I could just do everything in relation to
>that, but how do I then control access to pcsc?
>
>I'm hitting a wall or something here, and any kind of guidance would
>be greatly appreciated. I really want something I could build around
>along the lines of initial sign into the system and then rudimentary
>control over how apps access these services during the life of the
>session. It should be resiliant to brief interruptions of card
>availability (user pulls the card to go to lunch for example). Also,
>I'd like to monitor access to the card along the lines of an applet
>that lets the user know what apps are accessing the card so he/she can
>pull it if something funny looks like it's going on. Obviously, I'm
>simply asking for single sign on (haha).
>
>I'd also like to talk with any PAM gurus out there and some direction
>on that architecture. In my initial research it looks like it's built
>with plugs for an agent type architecture that I don't see many people
>using. I even found some good architectural discussion from HP's PAM
>designs for a smartcard infrastructure.
>
>I guess I like the idea of a Kerberos type infrastructure where I
>unlock my ticket granting architecture initially and all
>authentication and trust flows from there. I just think Kerberos is a
>little overkill, adminsitratively difficult, and showing weakness
>when put along modern techniques such as asymmetric cryptography and
>tamper resistant smartcard hardware.
>
>I feel like a solution is within reach. My real question is: with all
>of this powerful open source software, why do we continue to take
>incremental steps when more agressive steps are possible? We have the
>option of ignoring many legacy issues and yet even in research type
>situations, we continue to stay mired in aging techniques and
>technology. I think open source and efforts of projects such as
>M.U.S.C.L.E. have the tools and capability of at least letting us
>glimpse this future. I'm sure the payment is in blood, sweat, and tears
>of developers such as David Corcoran and Tommaso Cucinotta (who works
>on the smartsign project, I used his and David's efforts with ssp-lite
>for my hacking on openssh). I'd be willing to contribute to the fund
>but my blood, sweat, and tear currency needs a little help getting
>spent :).
>
>I'm sure this was a lot longer blurb than David was expecting with his
>innocent "interesting project" note that I am responding to, but I am
>interested in comments on this stuff.
>
>If you don't want to comment on the philosophical stuff, at least
>comment on the simple questions of how people are dealing with when
>and how to do CHV for 'unlocking' use of the private key on a
>smartcard. That one was on topic :)
>
>Stephen Pellicer
>***************************************************************
>Linux Smart Card Developers - M.U.S.C.L.E.
>(Movement for the Use of Smart Cards in a Linux Environment)
>http://www.linuxnet.com/smartcard/index.html
>***************************************************************
David Corcoran Purdue University
1008 Cherry Lane
West Lafayette, IN 47906
[EMAIL PROTECTED]
765 - 427 - 5147 http://www.linuxnet.com
***************************************************************
Linux Smart Card Developers - M.U.S.C.L.E.
(Movement for the Use of Smart Cards in a Linux Environment)
http://www.linuxnet.com/smartcard/index.html
***************************************************************
