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

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

On 9/28/2015 3:44 AM, helpcrypto helpcrypto wrote:
> On Fri, Sep 25, 2015 at 6:15 PM, Douglas E Engert <dee...@gm... <mailto:dee...@gm...>> wrote:
>
>     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.
>
>
> I don't have a PINPAD for testing, but our card doesn't seem to support CKF_PROTECTED_AUTHENTICATION_PATH

Any "card" can work with a pin pad reader.  CKF_PROTECTED_AUTHENTICATION_PATH is not a function of the card.


You say you are concerned with the PIN being stolen. The solution is a pin pad reader.
("card" does not include tokens that are a combination of card + reader or contactless cards.)


You said in another note:
"Users complaint this being annoying..."
There are many tradeoffs between easy of use and security.


>
>     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.
>
>
> Using 7816 we could establish a secure channel, but we dont have the needed keys to invoke operations like C_Sign, cause they are cripted with an unknown keys
>
> So: provider doesn't give us the keys, doesn't give us the mechanisms and their software is buggy...

>
>
>     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.
>
>
> A Javacard applet could do this operations in a secure way, but as we arn't able to populate the card, we cant't do anything.
>
>
> It looks promising!
>
> PS: according to openscdp, it seems we need the APDU, but we don't have them, so...

The point of using OpenSC is that you don't need to have the APDUs, as OpenSC implements the PKCS#11 API for many cards.

-- 

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