From: Peter Tomlinson (pwtiosis.co.uk)
Date: Mon Jan 24 2005 - 14:45:42 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Isn't it time to start to look at supporting the secure card reader/PIN
pad/display/biometric sensor? And secure channels right into the
application in the card, even down to the card platform in order to
authenticate it [1]? The time is coming when the use of the insecure
terminal on the internet is going to be first supplemented by the secure
mini-terminal and then eventually supplanted by the full specification
secure terminal. We need to start to prepare for the use of end-to-end
secure channels to be the norm for handling transactions - the user
certificates will then never appear again in plain in the insecure PC.
We also need mutual authentication, because it is vital for the
protection of the user that he or she deals with an authenticated server
in order to kill for ever the spoof web site that takes our money.

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
> Musclelists.musclecard.com
> http://lists.drizzle.com/mailman/listinfo/muscle
>

_______________________________________________
Muscle mailing list
Musclelists.musclecard.com
http://lists.drizzle.com/mailman/listinfo/muscle

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]