On Wed, Oct 04, 2000 at 11:27:35PM -0500, David Corcoran wrote:
> First, I would love it if someone had a glorious solution for this. If you
> do, please don't hesitate to mention it.
I don't have a glorious solution, but I have some ideas.
> 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.
That is what I'm looking for. Something to bridge the gap between the
user and the card. I need to make the channel open to the card
persitant in a way that balances security of the sensitive material on
the card and the convenience of the user.
> 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
I think we should prevent caching or storing the PIN at all costs.
I'll expand on this in a moment regarding the hostile host or
superuser.
> 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 guess the middleware I've inadvertently locked onto while groping in
the dark for answers has been PAM. The problem is I do not have enough
expertise on the PAM architecture to really see what is possible and
what is not. I think the best approach here is to not cache or
maintain PIN's but to keep the card open. Again, we maintain the
persitance of our verification without storing the PIN on the host.
The idea here is if we can open the card during initial log in on the
host, and access information (connectivity to the session that is open
through some sort of agent piece maintaining its lock on the card)
throughout the session in other applications, then we acheive a
transparent sign on for any other applications that use this middle
piece. At least from my initial looks at the PAM architecture, it
discusses use of a PAM client side piece that could potentially use an
agent for assistance. What I'm not clear on is if all of these PAM
components share a context contained within the initial log in that we
can access (to mainly access our connectivity back to the open card).
Can our initial log in to the session and identification as a user
serve as credential to access this agent that is keeping persistent
hold of the card throughout the session? ssh-agent handles this by
opening a unix-domain socket and setting access to only the user.
While at first glance this may seem overtly insecure, I think the
problem is not that bad. The abuse of this technique could happen
through a malicious superuser or imposter of the agent's user.
> 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 the point of giving up is sooner rather than later :). I don't
think prevention of a superuser or current user imposter abuse of an
inserted authenticated smartcard is necessary. We really only have to
worry about abuse beyond that. My reasoning is this. If there is a
malicious superuser or imposter with our user context, there are a
multitude of other ways they could abuse the card anyway. If they have
that context, they could easily trojan applications, access data
after/before decryption/encryption. I think the main goal here is to
isolate any potential damage to the current session. This means having
PIN information seen in the host as little as possible. If we verify
the card holder only at initial login and keep that card open, the
only time the PIN makes it into the host is at that initial instance.
This restricts PIN jacking to breached or malicious superusers who
have manipulated the initial authentication or middleware or PAM or
whatever or actively grabbed it from memory while it was happening. I
think prevention of anythine beyond that is wishful thinking. I think
a better approach would be take the Firewall/Intrusion Detection (or
castle wall/watchtower approach, depending on your preferred analogy)
and protect the initial login with Card Holder Verification and any
access throughout the session is not prevented but monitored and
potentially logged. My initial thoughts here are some utility to give
feedback to the user about when the middle ware is accessing the card
and potentially by what applicaiton. Kind of like the 'I'm encrypting'
icon in your browser. Obviously this puts a lot of the burden on the
user but I beleive that's the only place to put most of this since the
convenience of single sign on is for the user's sake. If the user
cannot use this information effectively, we couldn't have prevented it
even if we prompted them everytime they used the card (they would
probably blindly punch in a PIN everytime they were promted.)
I hope we can all continue to explore this topic and hopefully get
more information to fill in some of these gaps I have in my
discussion. Especially on the PAM front.
Stephen
***************************************************************
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
***************************************************************
