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

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

On 9/28/2015 6:56 AM, helpcrypto helpcrypto wrote:
> Hi.
>
>
> As said on first message: PINPADS are out of scope.
>
> We have 2 issues already, both have the same common problem: our card is closed and doesn't do things properly.
>
>   - The USER pin is sent on cleartext. The middleware should stablish a SM so login APDU will be crypted

You say pin pad readers out of the question, the PIN has to be entered somewhere and sent to the card.
Yet middleware is going to use the client OS to read it from a keyboard, so it is in plaintext somewhere.


>   - The Javacard/PKCS#11 API doesn't have a mechanism to "verify request before signing"
>
> In other words: If a server sends 10 documents to be signed, and we don't want to annoy the user with "confirm" dialogs, we have no way of being sure the requested wasn't compromised in some point.
> Even more if we code opensource.

I would read "verify request before signing", as the user gets to read the document and agrees to it,
which is whole point in signing the document.
No smartcard, by itself, can do this. It needs client software to display the document to the user,
yet you don't trust the client that is going to run your middleware.

If you don't want to "annoy" the user, with signing documents, why would a user trust any of your software?
Without even to confirm message how can the user agree to sign some but not all the documents you send?

>
> To sum-up: never trust the client,

But your middleware is running on the client, so why would a user trust your middleware?

 > or use an open hardware that let you load a secure apple to do these operations.

This all sounds like the same issues as EMV based credit cards. There the client is the reader with
a display and pin pad. But with EMV its just an amount the user has to agree too, not a document.
The user, merchant and credit card company have to trust the client (EMV reader+display+pinpad).


Don't know if these credit card ever went into production but they has a display and pin pad on the card:

   http://www.gizmag.com/emue-credit-card-visa-fraud/13374/

   http://www.gizmag.com/mastercard-display-card-singapore/24932/

So it is possible to put all of this on a card but the display is numeric only.

>
> Thanks.
>
>
> PS: OpenSC is also exposed to MITM attacks...otherwise PKCS11SPY wouldn't work.

SPY can work between any PKCS#11 application and any PKCS#11 library the application loads. It works with Mozilla NSS
for example. SPY is meant to be a MITM for debugging.

OpenSC is designed to provide a PKCS#11 API to smart cards where the user trusts the middleware.

OpenSC may not be for you. It sounds like you have bigger problems with your (and the user's) trust models.


-- 

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