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.
A better approach to be more transparent, because the hardware specific stuff is not important for the pkcs11rc configuration file, to have a configuration file for the libmusclecard library, describing the card terminal capabilities (display, PIN pad, supported transport protocols (T=0, T=1) ..., specific parameters) and to extend the configuration XML file for the MCardPlugin for specific arguments, e.g. the supported protocol types (I believe I have a card with broken T=1 protocol, so I had to compile a version with only T=0 support). But in both libraries at least one more function the obtain these parameters would be necessary.
Bye, Karsten
dito _______________________________________________ Muscle mailing list [email protected] http://lists.drizzle.com/mailman/listinfo/muscle
