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

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

On 9/28/2015 10:46 AM, helpcrypto helpcrypto wrote:
> On Mon, Sep 28, 2015 at 3:37 PM, Douglas E Engert <dee...@gm... <mailto:dee...@gm...>> wrote:
>
>     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.
>
>
> If the middleware were able to show a dialog to enter the PIN (hence my application not providing it), it would be better for me.

	
You may want to look at the Mozilla NSS:

   https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Overview

And if you application is in Java:

   https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/JSS

NSS has software crypto to do the verify and prompt for the PIN.

A NSS "security device" is actually a PKCS#11 library.
For example with FireFox tools->options->"Security Devices"->Load
is used to register a new PKCS#11 library, which could be OpenSC
to access a smartcard. If your card vendor provides .dll or .so file,
you could use the vendors driver.


On Windows you may want to use the Microsoft CryptoAPI.

   https://msdn.microsoft.com/en-us/library/windows/desktop/aa376210(v=vs.85).aspx

OpenSC provides the minidriver used by the MS CryptoAPI that can be uses to access smart cards. Most smart card vendors
provide a .dll to use with MS CryptoAPI.

And for Java with MS CryptoAPI see:

   http://www.oracle.com/technetwork/articles/javase/security-137537.html


> Also, proxyfying the pkcs#11 library won't do anything, cause the PIN will be NULL_PTR and if the middleware establish a SM with the card, the login APDU will be cripted.
>
> For me, that would be safe enough.

But not for the user. The PIN is in effect the user password to the card. If the card was stolen, or used without the user's knowledge
all you really know is the private key on the card signed the document.



>
>            - 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?
>
>
> 1.- This is what I have in mind: server prepares a batch of 10 documents to be signed and sign it with his private key.
> 2.- Opensource application receives, verify and show the documents to be signed (human friendly).
> 3.- "Extended PKCS#11 Javacard Applet" receives the request, verify the signature (server public key is stored in the card), request the PIN and signs.
> In other words...improving PKCS#11 spec with a function like "VerifySignatureRequestAndSign".
>
>         To sum-up: never trust the client,
>
>
>     But your middleware is running on the client, so why would a user trust your middleware?
>
>
> The middleware is not my problem, and it's supposed to be certified EAL4+...
>
>     > 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.
>
>
> Did I say I already have a "closed" card? xD
>
>
>         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.
>
>
> I'm not having any issue with OpenSC. I know what OpenSC and SPY are for.
> I was asking in this list because i though any of you could have an idea about how to solve the puzzle.
>
> Our card doesn't even comply with PKCS#15. Everything will be much easier if our card were "open".
>
> Thanks a lot, mr kaie.

-- 

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