On Wednesday 29 March 2006 03:05, Ludovic Rousseau wrote:
> Maybe another more radical solution is possible:
> - do not allow user V to use reader R if it is already used by U
> - instead of using SCardBeginTransaction/SCardEndTransaction the
> application should use SCardConnect/SCardDisconnect (with reset if
> needed)
As you pointed out, this would break many applications. Allowing another user
to silently take ownership but resetting the card shouldn't break things. As
I pointed out in the OS X case, the worst that happens is that the user is
prompted for their PIN more frequently.
> The question is: do an application want to share the smart card with
> another application? I proposed to use SCARD_SHARE_EXCLUSIVE but it
> has side effects.
The answer is clearly that applications do want to share the smart card, which
is why SCARD_SHARE_SHARED exists.
Perhaps we could introduce another sharing option, SCARD_SHARE_USER, which
would enable user limiting. It would break Windows compatibility, but only
in a minor, easily-fixed way...
#ifdef PCSC_LITE_SVC_IDENTITY
if (PCSC_LITE_SVC_IDENTITY >= 0x01030000)
shareMode = SCARD_SHARE_USER;
else
shareMode = SCARD_SHARE_SHARED;
#else
shareMode = SCARD_SHARE_SHARED;
#endif
This is better than the SCARD_SCOPE_USER abuse, IMO, since rather than quietly
changing semantics on Windows, it just won't compile without some #ifdefs
like the above.
That said, I've grown to like your suggestion that user limiting always be
enabled. It seems to me that the only cases it will break are cases that are
at present badly broken from a security perspective. Well, that assumes
there are no cases where the card holds data in volatile storage that is not
security sensitive, but is important to application functionality. If a set
of apps running as different users were using the smart card to manage a
mutex, for a very contrived example.
> The problem is that too many frameworks (CDSA, PKCS#11, direct PCSC
> access, etc.) want to talk to the same card at the same time. I don't
> know if we can find an solution.
At least for my applications, there *must* be a solution. It is simply not
acceptable that V can use U's credentials. IMHO, it's better to break
applications. Applications with broken functionality get fixed.
Applications with broken security often don't. If we can fix the security
hole without breaking applications, that's even better.
Shawn.
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
