Menu
▾
▴
opensc-devel
|
From: helpcrypto h. <hel...@gm...> - 2015-09-25 08:36:53
|
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. |
|
From: Dirk-Willem v. G. <di...@we...> - 2015-09-25 09:23:51
|
On 25 Sep 2015, at 10:36, helpcrypto helpcrypto <hel...@gm...> 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 |
|
From: Andreas S. <and...@ca...> - 2015-09-25 09:34:51
|
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 > Ope...@li... > 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 |
|
From: helpcrypto h. <hel...@gm...> - 2015-09-25 12:46:06
|
On Fri, Sep 25, 2015 at 11:21 AM, Dirk-Willem van Gulik < di...@we...> wrote: > On 25 Sep 2015, at 10:36, helpcrypto helpcrypto <hel...@gm...> > 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 |
|
From: helpcrypto h. <hel...@gm...> - 2015-09-25 12:58:08
|
On Fri, Sep 25, 2015 at 11:15 AM, Andreas Schwier < and...@ca...> 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. |
|
From: Ludovic R. <lud...@gm...> - 2015-09-25 13:47:29
|
Hello, 2015-09-25 14:45 GMT+02:00 helpcrypto helpcrypto <hel...@gm...>: > 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 |
|
From: helpcrypto h. <hel...@gm...> - 2015-09-28 08:38:24
|
On Fri, Sep 25, 2015 at 3:47 PM, Ludovic Rousseau < lud...@gm...> wrote: > Hello, > > 2015-09-25 14:45 GMT+02:00 helpcrypto helpcrypto <hel...@gm...>: > > 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... |
|
From: Douglas E E. <dee...@gm...> - 2015-09-25 16:22:26
|
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 <DEE...@gm...> |
|
From: helpcrypto h. <hel...@gm...> - 2015-09-28 08:44:43
|
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... |
|
From: Douglas E E. <dee...@gm...> - 2015-09-28 11:04:33
|
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...>
|
|
From: helpcrypto h. <hel...@gm...> - 2015-09-28 11:57:21
|
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. |
|
From: Douglas E E. <dee...@gm...> - 2015-09-28 13:44:37
|
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...> |
|
From: helpcrypto h. <hel...@gm...> - 2015-09-28 15:46:46
|
On Mon, Sep 28, 2015 at 3:37 PM, Douglas E Engert <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. 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. |
|
From: Douglas E E. <dee...@gm...> - 2015-09-28 22:12:19
|
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 <DEE...@gm...> |
|
From: Douglas E E. <dee...@gm...> - 2015-09-28 17:06:44
|
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...> |
|
From: helpcrypto h. <hel...@gm...> - 2015-09-29 08:11:52
|
On Mon, Sep 28, 2015 at 6:59 PM, Douglas E Engert <dee...@gm...> wrote: > 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 > 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 <dee...@gm...> 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. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X