Prevent "proxyfying" PKCS#11

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Prevent "proxyfying" PKCS#11

helpcrypto helpcrypto
Hi all


I hope you can find a solution for my problem, cause I can't. (And perhaps it's impossible)


Based on my knowledge of PKCS#11 standard, the spec is exposed to a MITM attack that steals the PIN when an application invokes C_Login against a PK#11 library.


While using CryptoAPI it's the system who shows the "PIN dialog" making it harder to crack/extract the PIN, C_Login function receives the PIN in plaintext, and "an evil software", like PKCS11SPY, could get access to it.

Sadly, using Pinpads is out of scope/beyond our possibilities.



Of course my app could check pkcs#11 library checksum and other mechanisms to "ensure" it is the library and not a proxy, but if my application is opensource (I'll love to), I'm fu*ked.

Is there any way to "trust" in the client? Can the server know the exe being executed is MY exe and an EVIL copy? (A private key embebed can also be cracked!)


Furthermore, our lovely card sends APDU for login in plainText, so anyone could see "1234" easily. And we are not able to establish a secure channel cause we lack the required keys.


Seems what I really need is something like a Javacard applet with an embebed "server public key", a component certificate and a session keypair for mutual authentication and cipher communications between server and client, but we aren't able to load this applet on the Card.

So, to sum up it seems it won't be possible to do what I need: a server asking to sign 10 documents and being sure only those are signed.

I understand this is Anders (& CO) argument about "smartcards were not designed for Web"


In the other hand, do you think is possible to "extend" WebcryptoAPI to generate/use keys to/from browser or system keystore?
IMHO, how it actually works, sucks.


Regards (and thanks)

PS: Never trust the client...that also sucks.



------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Prevent "proxyfying" PKCS#11

Andreas Schwier (ML)
Hi,

you mention a common problem with PIN authentication and smart cards: To
keep the PIN protected on the path between the PIN entry and chip must
be protected.

There are two alternatives:

1. Establish a secure channel between the card and the PIN pad.
2. Replace PIN authentication with public key authentication

The first is what TR-03110 does with PACE: The PIN is never traversing
the path from PIN pad to the card.

Alternatively you could use a protocol like ChipAuthentication to create
the secure channel before PIN verification occurs.

For C_Login the alternative is to use CKF_PROTECTED_AUTHENTICATION_PATH
and have a PIN dialog in the PKCS#11 module.

The second option is not very common with cards, even though that has a
lot of potential for server based scenarios.

In the current SmartCard-HSM we support creating a secure channel using
ChipAuthentication and use that channel to submit the PIN. The secure
channel is based on a 3 tier PKI that is used during device production
to issue a device certificate for the ChipAuthentication public key.

In the upcoming 2.0 release of the SmartCard-HSM we support public key
authentication (PKA) as replacement for PIN. PKA can be used in
combination with an n-of-m threshold scheme, so it is specifically
suited for applications where access to keys must be shared between key
custodians.

> Furthermore, our *lovely* card sends APDU for login in plainText, so
anyone
> could see "1234" easily. And we are not able to establish a secure channel
> cause we lack the required keys.
>
>
> Seems what I really need is something like a Javacard applet with an
> embebed "server public key", a component certificate and a session keypair
> for mutual authentication and cipher communications between server and
> client, but we aren't able to load this applet on the Card.
That's what the SmartCard-HSM does. And this is the mechanism we use
with the PKI-as-a-Service Demo [1]. A client (OCF) that acts as a
reverse APDU proxy connects to the server. The server application talks
to the remote card just like it talks to a locally connected card. It
initially reads and validates the device certificate, establishes a
secure channel with ChipAuthentication and then perform operations with
the card.

In the demo case, the PIN is entered locally at the client, either in
pop-up or using a PIN pad reader. The PIN is then bound to the secure
channel and if the secure channel terminates, the PIN authentication is
reset.
>
> So, to sum up it seems it won't be possible to do what I need: a server
> asking to sign 10 documents and being sure only those are signed.
That can be done. I even know a web based application that can
electronically sign document according to the strict German signature law.
>
> I understand this is Anders (& CO) argument about "smartcards were not
> designed for Web"
Not all smart cards are equals ;-)
>
>
> In the other hand, do you think is possible to "extend" WebcryptoAPI to
> generate/use keys to/from browser or system keystore?
That is something I never understood. Why does WebcryptoAPI not support
PKCS#11 ? What's the hidden agenda with software keys in the browser ?
Is it because Google/NSA want to know the key ?
> IMHO, how it actually works, sucks.
FullAck.

Andreas

[1] http://demo.openscdp.org/paas.html

>
>
> Regards (and thanks)
>
> PS: Never trust the client...that also sucks.
>
>
>
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>


--

    ---------    CardContact Software & System Consulting
   |.##> <##.|   Andreas Schwier
   |#       #|   Schülerweg 38
   |#       #|   32429 Minden, Germany
   |'##> <##'|   Phone +49 571 56149
    ---------    http://www.cardcontact.de
                 http://www.tscons.de
                 http://www.openscdp.org
                 http://www.smartcard-hsm.com


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Prevent "proxyfying" PKCS#11

Dirk-Willem van Gulik
In reply to this post by helpcrypto helpcrypto
On 25 Sep 2015, at 10:36, helpcrypto helpcrypto <[hidden email]> wrote:

> I hope you can find a solution for my problem, cause I can't. (And perhaps it's impossible)

> Based on my knowledge of PKCS#11 standard, the spec is exposed to a MITM attack that steals the PIN when an application invokes C_Login against a PK#11 library.
...
> Sadly, using Pinpads is out of scope/beyond our possibilities.

This won’t solve your problem directly - but may still be useful (especially as I am guessing that as you are CC-ing the Mozilla list - that you are concerned with browsers).

One way we got things this to pass munster was to carefully make a threatmap/actor analysies - and then meet the various compliance & infosec expectations was by 1) dispensing with the PIN and 2) having a `what you know’ as part of the interaction through the browser (only).

As this concerned access to something which was only accessible through the browser - we essentially argued that if one where able to manipulate the local browser/keyboard/system to such an extent as to be able to capture the PIN near the PKCS library/driver  - one would almost most certainly be able to get `at’ whatever the chipcard & pin where protecting `in’ the browser.

Dw



------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Prevent "proxyfying" PKCS#11

helpcrypto helpcrypto
On Fri, Sep 25, 2015 at 11:21 AM, Dirk-Willem van Gulik <[hidden email]> wrote:
On 25 Sep 2015, at 10:36, helpcrypto helpcrypto <[hidden email]> wrote:

> I hope you can find a solution for my problem, cause I can't. (And perhaps it's impossible)

> Based on my knowledge of PKCS#11 standard, the spec is exposed to a MITM attack that steals the PIN when an application invokes C_Login against a PK#11 library.
...
> Sadly, using Pinpads is out of scope/beyond our possibilities.

This won’t solve your problem directly - but may still be useful (especially as I am guessing that as you are CC-ing the Mozilla list - that you are concerned with browsers).
Indeed

One way we got things this to pass munster was to carefully make a threatmap/actor analysies - and then meet the various compliance & infosec expectations was by 1) dispensing with the PIN and 2) having a `what you know’ as part of the interaction through the browser (only).

Server-side signature won't be a problem, as security is left for the browser, but we are using cards, so the PIN has to reach the card, where the certificate is stored.
 
 
As this concerned access to something which was only accessible through the browser - we essentially argued that if one where able to manipulate the local browser/keyboard/system to such an extent as to be able to capture the PIN near the PKCS library/driver  - one would almost most certainly be able to get `at’ whatever the chipcard & pin where protecting `in’ the browser.

We are actually at that point. Browser is displaying a random number (kind of OTP) and application show it to let the user know the request is "trusted".
But we still have the issue with the data sent from server. eg: server sent "sign these 10 documents" to our opensource Java local application which asks PKCS#11 to do it.
Anyone could decompile, and inject an 11th doc on the request.
That's what we are trying to avoid and our opinion is actually: if the computer is compromised, you can't do anything.


Thanks for your answers


------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Prevent "proxyfying" PKCS#11

helpcrypto helpcrypto
In reply to this post by Andreas Schwier (ML)
On Fri, Sep 25, 2015 at 11:15 AM, Andreas Schwier <[hidden email]> wrote:
Hi,

you mention a common problem with PIN authentication and smart cards: To
keep the PIN protected on the path between the PIN entry and chip must
be protected.

There are two alternatives:

1. Establish a secure channel between the card and the PIN pad.

If you are talking about 7816 SM, we can't, cause the provider doesn''t give us the needed keys.

 
2. Replace PIN authentication with public key authentication

The first is what TR-03110 does with PACE: The PIN is never traversing
the path from PIN pad to the card.

Alternatively you could use a protocol like ChipAuthentication to create
the secure channel before PIN verification occurs.

For C_Login the alternative is to use CKF_PROTECTED_AUTHENTICATION_PATH
and have a PIN dialog in the PKCS#11 module.

Our card doesn't support that.
Also note that not only the PIN is exposed, but the requests for signature.
(I send 5 documents to be signed, evil application add 1 and the user signed 6 without our knowledge)

 
The second option is not very common with cards, even though that has a
lot of potential for server based scenarios.

In the current SmartCard-HSM we support creating a secure channel using
ChipAuthentication and use that channel to submit the PIN. The secure
channel is based on a 3 tier PKI that is used during device production
to issue a device certificate for the ChipAuthentication public key.

In the upcoming 2.0 release of the SmartCard-HSM we support public key
authentication (PKA) as replacement for PIN. PKA can be used in
combination with an n-of-m threshold scheme, so it is specifically
suited for applications where access to keys must be shared between key
custodians.

Sadly, our card is "closed" and we are not able to do anything...otherwise i could load a Javacard applet to do what I need in a secure way.


> Furthermore, our *lovely* card sends APDU for login in plainText, so
anyone
> could see "1234" easily. And we are not able to establish a secure channel
> cause we lack the required keys.
>
>
> Seems what I really need is something like a Javacard applet with an
> embebed "server public key", a component certificate and a session keypair
> for mutual authentication and cipher communications between server and
> client, but we aren't able to load this applet on the Card.
That's what the SmartCard-HSM does. And this is the mechanism we use
with the PKI-as-a-Service Demo [1]. A client (OCF) that acts as a
reverse APDU proxy connects to the server. The server application talks
to the remote card just like it talks to a locally connected card. It
initially reads and validates the device certificate, establishes a
secure channel with ChipAuthentication and then perform operations with
the card.

In the demo case, the PIN is entered locally at the client, either in
pop-up or using a PIN pad reader. The PIN is then bound to the secure
channel and if the secure channel terminates, the PIN authentication is
reset.

Have to have an eye on [1]!

>
> So, to sum up it seems it won't be possible to do what I need: a server
> asking to sign 10 documents and being sure only those are signed.
That can be done. I even know a web based application that can
electronically sign document according to the strict German signature law.
>
> I understand this is Anders (& CO) argument about "smartcards were not
> designed for Web"
Not all smart cards are equals ;-)
>
>
> In the other hand, do you think is possible to "extend" WebcryptoAPI to
> generate/use keys to/from browser or system keystore?
That is something I never understood. Why does WebcryptoAPI not support
PKCS#11 ? What's the hidden agenda with software keys in the browser ?
Is it because Google/NSA want to know the key ?
> IMHO, how it actually works, sucks.
FullAck.

Andreas

[1] http://demo.openscdp.org/paas.html

I really have to read about this, but I don't know if our card will support it.



------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Prevent "proxyfying" PKCS#11

Ludovic Rousseau
In reply to this post by helpcrypto helpcrypto
Hello,

2015-09-25 14:45 GMT+02:00 helpcrypto helpcrypto <[hidden email]>:
> But we still have the issue with the data sent from server. eg: server sent
> "sign these 10 documents" to our opensource Java local application which
> asks PKCS#11 to do it.
> Anyone could decompile, and inject an 11th doc on the request.

Some cards can be configured so that the PIN have to be presented
before _each_ signature.
If the user knows he has 10 documents to sign and he is asked to enter
his PIN 11 times then he should detect a problem.

The user should verify after each signature that the document he
wanted to sign is correctly signed. If not then he should suspect a
problem. Maybe another document has been signed instead, or something
went wrong.

If you do not use a pinpad the PIN is available somewhere in RAM and a
rogue software could use it.

> That's what we are trying to avoid and our opinion is actually: if the
> computer is compromised, you can't do anything.

Exact. If the computer is compromised you have NO idea of what it is doing.

Bye

--
 Dr. Ludovic Rousseau

------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Prevent "proxyfying" PKCS#11

Douglas E Engert
In reply to this post by helpcrypto helpcrypto
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  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Prevent "proxyfying" PKCS#11

helpcrypto helpcrypto
In reply to this post by Ludovic Rousseau
On Fri, Sep 25, 2015 at 3:47 PM, Ludovic Rousseau <[hidden email]> wrote:
Hello,

2015-09-25 14:45 GMT+02:00 helpcrypto helpcrypto <[hidden email]>:
> But we still have the issue with the data sent from server. eg: server sent
> "sign these 10 documents" to our opensource Java local application which
> asks PKCS#11 to do it.
> Anyone could decompile, and inject an 11th doc on the request.

Some cards can be configured so that the PIN have to be presented
before _each_ signature.
If the user knows he has 10 documents to sign and he is asked to enter
his PIN 11 times then he should detect a problem.

Althouth that could solve "partially" the problem, it's not an intended feature. Users complaint this being annoying, even if we cache the PIN and just request yes/no to confirm.

 
The user should verify after each signature that the document he
wanted to sign is correctly signed. If not then he should suspect a
problem. Maybe another document has been signed instead, or something
went wrong.

As stated previusly, if our client application is open-source, anyone could manipulate that and show whatever they want.

 
If you do not use a pinpad the PIN is available somewhere in RAM and a
rogue software could use it.

> That's what we are trying to avoid and our opinion is actually: if the
> computer is compromised, you can't do anything.

Exact. If the computer is compromised you have NO idea of what it is doing.

Starting to get convinced...

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Prevent "proxyfying" PKCS#11

helpcrypto helpcrypto
In reply to this post by Douglas E Engert
On Fri, Sep 25, 2015 at 6:15 PM, Douglas E Engert <[hidden email]> 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...

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Prevent "proxyfying" PKCS#11

Douglas E Engert


On 9/28/2015 3:44 AM, helpcrypto helpcrypto wrote:

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


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Prevent "proxyfying" PKCS#11

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

To sum-up: never trust the client, or use an open hardware that let you load a secure apple to do these operations.

Thanks.


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

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Prevent "proxyfying" PKCS#11

Douglas E Engert


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  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Prevent "proxyfying" PKCS#11

helpcrypto helpcrypto
On Mon, Sep 28, 2015 at 3:37 PM, Douglas E Engert <[hidden email]> 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.
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.

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

------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Prevent "proxyfying" PKCS#11

Douglas E Engert


On 9/28/2015 10:46 AM, helpcrypto helpcrypto wrote:

> On Mon, Sep 28, 2015 at 3:37 PM, Douglas E Engert <[hidden email] <mailto:[hidden email]>> 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  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Prevent "proxyfying" PKCS#11

Douglas E Engert
In reply to this post by helpcrypto helpcrypto
In your first note, you implied that you were writing an application to sign documents.
This application might be a web app. You also say you want to send 10 documents signed by the server
but don't say anything about what is a document.

Have you looked at Adobe Reader? It could be started from a web page, and it can
sign documents, and use  PKCS#11 or Windows Certificate store and thus use a smart card.

https://helpx.adobe.com/acrobat/kb/certificate-signatures.html

Or Google for: adobe reader pkcs11 smartcard


It looks like Adobe Reader can also verify signatures on a document.


  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Prevent "proxyfying" PKCS#11

helpcrypto helpcrypto
In reply to this post by Douglas E Engert
On Mon, Sep 28, 2015 at 6:59 PM, Douglas E Engert <[hidden email]> wrote:
On 9/28/2015 10:46 AM, helpcrypto helpcrypto wrote:
On Mon, Sep 28, 2015 at 3:37 PM, Douglas E Engert <[hidden email] <mailto:[hidden email]>> 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

Already knew about these alternatives.
I think I didn't explained myself properly or you didn't understand.

PKCS#11 API has 2 ways of working: requiring the PIN on C_Login or don't ask for it, showing a middleware-GUI. (pinpads apart)
As our middleware doesn't show any dialog, we are enforced to send the PIN, so MITM can get the PIN (even keylogger if the PIN dialog is not based on random number locations).


In the other hand, If my server want to sign 10 specific documents, theres no way to "detect" the request wasn't altered, because the trust channel between application and card is broken.


The only real trustworthy scneario is having a card which securely communicates to server, but we don't have that card. Our is closed and we lack needed keys/privileges.

 
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.



On Tue, Sep 29, 2015 at 12:05 AM, Douglas E Engert <[hidden email]> wrote:

In your first note, you implied that you were writing an application to sign documents.
This application might be a web app. You also say you want to send 10 documents signed by the server
but don't say anything about what is a document.
Have you looked at Adobe Reader? It could be started from a web page, and it can sign documents, and
use  PKCS#11 or Windows Certificate store and thus use a smart card.

https://helpx.adobe.com/acrobat/kb/certificate-signatures.html

Or Google for: adobe reader pkcs11 smartcard

It looks like Adobe Reader can also verify signatures on a document.

Let me be more clear: xml, txt or whatever, not only PDF. I also know what PAdES can do for me, but this is a protocol question, rather than signature-alterbatives.



------------------------------------------------------------------------------

_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel