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

[helpcrypto h. <hel...@gm...>]

On Fri, Sep 25, 2015 at 6:15 PM, Douglas E Engert <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



> 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...