On Wednesday 22 March 2006 19:33, Karsten Ohme wrote:
> Well, and what about, if the call to SCardConnect is done with the
> SCARD_SHARE_EXCLUSIVE flag, so that no other user can access the
> readers. Is this enough?
No, it doesn't really change anything. Keep in mind that in the sort of
systems I work with there are multiple applications. Whether the locking out
of other processes is done at the transaction level or the card connection
level, the result is the same: It is not safe to release the lock without
resetting the card, which means the PIN will have to be re-presented for the
next operation, requiring either prompting the user or caching the PIN.
> If the connection to the readers is secured by a MAC or by encryption,
> only the user application knows the session keys.
That makes the problem even worse, because if you have three applications that
all want to use the card, only one of them will know the session key. Given
cards that support multiple sessions, the apps can share the cards, each one
with its own session keys (and each one having to authenticate
individually :-/), but most of the cards being deployed today don't support
multiple sessions -- and I don't think pcsc-lite supports multi-session
connections either.
> Without the SCARD_SHARE_EXCLUSIVE flag
> only DoS attempts are possible. So the user can stay logged in and no
> other user can access the card in this time.
But only from *one* application.
> The idea of a PIN may be obsolete in some time.
What will replace it? We must authenticate the user to the card somehow.
> Serious card terminals
> (OK, it is possible to spoof the PIN, but maybe this will change and
> then it is.) have a key pad to enter the PIN. It would violate the idea
> behind the concept that the untrustworthy computer never sees the PIN,
> only the trustworthy card terminal. Biometric (Although this is not a
> serious secure way to authenticate users in the present time.) data may
> also only be entered at the card terminal. The concept should include
> this.
Further support for my position! :-)
I agree that card readers with integral PIN pads are much better for security,
but with that improvement, PIN caching at the application level becomes
impossible and it becomes even *more* important to have some mechanism to
allow the card authentication state to persist over time and across
applications while simultaneously preventing another user from hijacking the
card.
> No, I was wrong. SCARD_SCOPE_USER is used as a domain identifier for
> database operations. E.g. adding a reader to a reader group or
> registering a new service provider. pcsc-lite does not use the concept
> of service providers (would replace the whole plugin concept of
> libmusclecard ...). So it is (?) unused in pcsc-lite. But the semantic
> should not differ from Windows and pcsc-lite.
It may be better to add an additional API than to change semantics in subtle
ways. That way an app written for pcsc-lite would simply not build on
Windows without #ifdefs or the like. Better to make the issue explicit.
That depends on what the effects of the violated assumptions are, though, and
it seems unlikely that Windows app developers actually expect another user to
be able to talk to the card.
This raises the question of how PCSC on Windows deals with the issue that I'm
raising. I know that on Windows if you are using Microsoft's remote desktop
technology, it "forwards" your local card reader(s) rather than using the
ones attached to the destination machine. But what about other remote access
solutions that don't take that care? Does Microsoft arrange that only
processes owned by the user logged in at the console have access to local
readers? That would probably work for Windows, and would work for some
configurations of Unix systems, but not all.
Actually, changing the ownership of /var/run/pcscd.comm to the user currently
logged in at the console and changing the permissions to exclude other users
is my current workaround to this issue. Maybe that is the best that can be
done? It seems very kludgy and limited.
Thanks for your comments,
Shawn.
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
