David Corcoran wrote:
> 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.
I think this is the right solution, isn't it ? The application
authenticates to the card at the start of its activity, then logs
out if it doesn't need to maintain the card open (i.e. the application
used the card to authenticate to a remote party, then logs out the card
and uses the established secure channel).
If the application needs to log in another time during its life, then
it could use the CHV cached, so no user interaction is required.
If the application need the card with a too high frequency, then
it is better that it never logs out during its activity. This is
the application's choice.
Obviously, if you're speaking about cards which support multiple
sessions/channels, then there must be a channel handler,...
> 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.
Very bad. You have to assure that only the application which opened
a session can use that session handler. You must save somewhere the
application's Process ID and use it for future verifications, for
every operation. Increasing the size of the hCard handle isn't useful,
unless you put a cryptographycally secure random number generator
to generate session handlers, but I think the best solution is the
other.
> 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.
I don't think that caching the card's CHV in a central middleware is
a good thing. As I stated before, I think that caching is application
dependent (application can decide when, how and where to cache, and
nobody
else). I think that application should be the only one which can ask
the user for his CHV, think of the PAM architecture. Graphic application
opens a dialog, textual application asks from the terminal.
If you use an external card-reader-numeric-pad, then the application
sees always the card opened, in the sense that it has not to ask
anything
to the user, and so the (eventual) middleware.
> 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.
I don't understand what you're saying. The fact that card supports
channel
management on not doesn't influence CHV management by applications,
according to me.
Maybe you're saying that each command should include a CHV verification
to be executed, but that's what card builder avoided with the
CHV_VERIFY and card state management.
Please, explain me what you wanted to say.
> 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 ?
I think that a superuser can do everything, including replace the user's
application with a malicious one which has the task to steal CHVs and
e-mail
them to him, or more realistically, he can activate some log activity of
the application that indirectly reveals the CHV.
Hope I didn't miss completely the question. Bye,
Tommaso Cucinotta.
--
/------------------------------------------------\
| Dr. Tommaso Cucinotta <[EMAIL PROTECTED]> |
+------------------------------------------------+
| Scuola Superiore di Studi Universitari |
| e Perfezionamento S.Anna |
| Pisa Italy |
\------------------------------------------------/
***************************************************************
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
***************************************************************
