On Wednesday 22 March 2006 18:25, Karsten Ohme wrote:
> Why? You lock the card through the whole cryptographic operation. Not
> between single operations. The PIN must be entered e.g. for signing an
> email only once. This is OK.
Many users do not find it acceptable to enter a PIN for every e-mail signed,
every secure web site visited, every one-time password generated, every
retrieval of stored credentials for single sign-on authentication, etc.
When you use the smart card heavily, the requirement to repeatedly re-enter
the PIN becomes very burdensome and becomes an obstacle to usage. Average,
non security-focused users quickly become unwilling to use it at all and
argue instead for less-secure solutions. In practice, the best solution is
to allow the card to retain its authenticated state and to tell users that
they must take their cards with them when they leave their machines [1].
I'm speaking from real-world experience deploying multi-application smart card
authentication solutions to thousands of users. They will not accept having
to enter their PIN for every usage of the card.
> Except from this, this should not be the job of PCSC. The usual approach
> like for other communication protocols (e.g. the WWW) is to establish a
> secure connection. It may be possible to take over Internet connections
> from the same computer if these connection is not secured. But to
> prevent this e.g. SSL is used. Smart cards should offer also a mechanism
> for secure messaging and the most card implementations do.
Either I'm not understanding you or you didn't understand me. Arrogant as I
am, I choose to think you're not understanding me ;-)
To clarify: Given that users will refuse to re-enter their PIN hundreds of
times every day, using the approach mentioned by David Corcoran to address
the multi-user access issue means that some higher-level mechanism must be
implemented to cache the PIN so that each time the application needs to
perform a PIN-protected operation it can re-present the PIN. If many
different user-level applications use the smart card, then it's necessary to
either have each of them cache the PIN (requiring the user to enter the PIN
once per application) or else create some sort of a PIN-caching daemon which
they all connect to. More likely, it would become the smart card interface
daemon. That's unwieldy and also requires the PIN to be kept around in RAM
all the time, which is uncomfortable from a security perspective (though not
fatal).
> [SCARD_SCOPE_USER] is used in Windows. It is not useless. If many readers
> are attached to a system only the readers are listed which are in the scope
> of the user; readers he can access.
I know that, but it appears (to my limited knowledge) that there is actually
no way to associate readers with a user, making it useless.
Perhaps SCARD_SCOPE_USER isn't the best way to resolve this, but there must be
some solution. I have a client who wants to deploy a smart card solution on
pcsc-lite to a couple thousand Linux and Solaris machines, and the users will
not accept having to re-enter their PINs constantly. I'm not trying to say
that's your problem, or anyone else's here but mine, but I am saying that in
that environment, the fact that pcsc-lite provides no user-level segregation
of access is fatal. pcsc-lite cannot be used as-is in that environment, and
I think there are many others from which it will be excluded.
Thanks to the open source nature of pcsc-lite, I can (and will) modify
psc-lite to solve the problem. Obviously, I'd prefer it if the solution
could be put into mainline pcsc-lite, so I'd like to discuss if and how that
might be done.
Thanks,
Shawn
[1] A very good way to ensure that users do remove their card when they walk
away is to integrate the card with a proximity badge for door access control,
then put prox readers on the bathroom, break room, etc., in addition to
making a "badge always required" policy. It's extremely effective.
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
