Re: [Opensc-devel] Prevent "proxyfying" PKCS#11

[Douglas E E. <dee...@gm...>]

It is not clear from the discussion if you have the card at one location and the PIN is entered at some other location.

The PKCS#11 CKF_PROTECTED_AUTHENTICATION_PATH is usually not implemented on the card but
is used with pin pad reader. The middleware sends a verify template (without a PIN) to the reader.
The reader displays prompt messages then the user enters the PIN on the reader's pin pad. The reader
sends the verify command with the PIN to the card. The card is plugged directly into the reader,
and thus any attack to get the PIN has to modify the reader.
The client machine never sees the PIN.

In the above case the card does not have to support CKF_PROTECTED_AUTHENTICATION_PATH.

The user has to understand to only enter the PIN on the pin pad reader when the *reader* requests the PIN
and never enter the PIN on any other device where it could be stolen.
The user will also have to be careful not to insert the card into some other reader where a stolen PIN
could then be used without the user's knowledge.

As pointed out by others some cards require a verify just prior to a signature operation for some keys
with no intervening APDUs to the card. In PKCS#11 this is called CKA_ALWAYS_AUTHENTICATE, in PKCS#15 and in OpenSC
it is called user_consent. Check your card to see if it can enforce this for signature keys.


A bigger problem is the card will sign anything.

You talk about a server sending documents to the client to be signed. The user
need know what his card is signing, which requires some trust of the client software by the user.
The server when it gets the signed document returned, needs to verify that the document
has not been modified by verifying the signature using the user's certificate.

The server could also co-sign and time stamp the document so others would have additional trust that the signatures
are valid.




-- 

  Douglas E. Engert  <DEE...@gm...>