These concepts are not ones that the major suppliers will willingly implement, because they are too much of a challenege to the simple but insecure methods that the suppliers continue to churn out.
The real challenge is to provide secure means to use secure eID and eAuthentication across the internet, for the benefit of both the user and the service provider. Passports will not do this, even though we use them as ID documents. The US govt isn't moving towards ID cards - and physical ID cards and true eID are not the same. Across Europe we want interoperability of ID cards (physical cards with electronic supplement) in order to use them as travel documents, but the EC has no jurisdiction over national ID card methods, and the EC has not yet realised that it can promote interoperable eID without interfering with physical ID card schemes.
Peter
[1] The card needs a certificate, not a "manufacturer's ID" - and supporting the certificate there must be a database and a PKI.
Karsten Ohme wrote:
I have a Card Terminal with an PIN pad and I do not want that the only purpose of these keys is to cumber dust from falling down.
I plan to extend the musclecard library. For this reason I use the SCardControl function of the PC/SC implementation.
The question is the way to do this.
The musclecard library could be extended with a function MSCVerifyXXX(), but there are more possible ways to authenticate without passing a pin with the keyboard of a insecure computer. Maybe with biometrical data and so on. So this approach should be flexible enough to allow these different methods. But maybe the PIN pad is enough at a first sight.
Similar considerations apply to use cases like change PIN and so on.
Or maybe the current MSCverify is enough and the passed MSCTokenInfo structure can be used. What are the fields tokenType and addParams are used for?
In the PKCS11 library there is already a possibility to distinguish between terminals with special capabilities.
I quote from the specification:
"If the token has a “protected authentication path”, as indicated by the CKF_PROTECTED_AUTHENTICATION_PATH flag in its CK_TOKEN_INFO being set, then that means that there is some way for a user to be authenticated to the token without having the application send a PIN through the Cryptoki library."
So from the appropriate methods like C_Login the right method can be called.
For this to work in the pkcs11rc file must be a parameter describing the card terminal device(s) and there capabilities. Also some special parameters (e.g. for the proprietary functional unit handling the request, i.e PIN pad for SCardControl) must be present.
Bye, Karsten
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
