opensc-devel — discussion of developement of OpenSC and related projects

[Opensc-devel] Active Directory Certificate Services enrollment problems

[Matt C. <mat...@ou...>]

When I attempt to enroll a user for a smart card login certificate, Windows
tells me that the smart card is read-only[1]. I'm running Windows Server
2012 R2 and OpenSC 0.15.0g20150914124137 with a Smartcard-HSM card and
Identiv/SCM Microsystems SCR331 card reader. I've initialized it per the
instructions on the GitHub wiki. Any help is appreciated.

[1] http://i.coreduo.me.uk/U4FuFqe.png

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

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

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

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

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

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

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.

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


-- 

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

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

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

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.

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

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

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

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

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

On Fri, Sep 25, 2015 at 6:15 PM, Douglas E Engert <dee...@gm...>
wrote:

> It is not clear from the discussion if you have the card at one location
> and the PIN is entered at some other location.
>
> The PKCS#11 CKF_PROTECTED_AUTHENTICATION_PATH is usually not implemented
> on the card but
> is used with pin pad reader. The middleware sends a verify template
> (without a PIN) to the reader.
> The reader displays prompt messages then the user enters the PIN on the
> reader's pin pad. The reader
> sends the verify command with the PIN to the card. The card is plugged
> directly into the reader,
> and thus any attack to get the PIN has to modify the reader.
> The client machine never sees the PIN.
>

I don't have a PINPAD for testing, but our card doesn't seem to support
CKF_PROTECTED_AUTHENTICATION_PATH



> In the above case the card does not have to support
> CKF_PROTECTED_AUTHENTICATION_PATH.
>
> The user has to understand to only enter the PIN on the pin pad reader
> when the *reader* requests the PIN
> and never enter the PIN on any other device where it could be stolen.
> The user will also have to be careful not to insert the card into some
> other reader where a stolen PIN
> could then be used without the user's knowledge.
>
> As pointed out by others some cards require a verify just prior to a
> signature operation for some keys
> with no intervening APDUs to the card. In PKCS#11 this is called
> CKA_ALWAYS_AUTHENTICATE, in PKCS#15 and in OpenSC
> it is called user_consent. Check your card to see if it can enforce this
> for signature keys.
>

Using 7816 we could establish a secure channel, but we dont have the needed
keys to invoke operations like C_Sign, cause they are cripted with an
unknown keys

So: provider doesn't give us the keys, doesn't give us the mechanisms and
their software is buggy...


A bigger problem is the card will sign anything.
>
> You talk about a server sending documents to the client to be signed. The
> user
> need know what his card is signing, which requires some trust of the
> client software by the user.
> The server when it gets the signed document returned, needs to verify that
> the document
> has not been modified by verifying the signature using the user's
> certificate.
>
> The server could also co-sign and time stamp the document so others would
> have additional trust that the signatures
> are valid.
>

A Javacard applet could do this operations in a secure way, but as we arn't
able to populate the card, we cant't do anything.


It looks promising!

PS: according to openscdp, it seems we need the APDU, but we don't have
them, so...

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

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

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

[Opensc-devel] http://opensc.github.io/pam_pkcs11 is broken

[Ludovic R. <lud...@gm...>]

Hello,

The URL http://opensc.github.io/pam_pkcs11 used to provide HTML pages
form the pam_pkcs11 project.
One month ago Martin created a redirection of http://opensc.github.io/
to http://opensc-project.org/
See [1].
The URL http://opensc.github.io/pam_pkcs11 is now redirected to
https://www.opensc-project.org/pam_pkcs11 and get a 404 Not Found.

Unless someone complains I plan to remove the redirection installed by Martin.

The web page at https://www.opensc-project.org/ explains that the
project has moved to github. I think that opensc-project.org should
not be used any more to store "live" content.

Regards,

[1] https://github.com/OpenSC/opensc.github.io

-- 
 Dr. Ludovic Rousseau

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

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

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

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

[Ludovic R. <lud...@gm...>]

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

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

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

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.

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

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

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

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

[Andreas S. <and...@ca...>]

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

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

[Dirk-Willem v. G. <di...@we...>]

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

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

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

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.

Re: [Opensc-devel] new readers

[Dirk-Willem v. G. <di...@we...>]

On 23 Sep 2015, at 14:07, <J.W...@mi...> <J.W...@mi...> wrote:

> Until now _all_ of them failed to work with our AET applet and AET-drivers.
> The DP870 does work out-of-the-box with opensc >= 13.0
> Listing of open and protected structures (+PIN) work as expected.

Would be nice to confirm they also work with the usual Feitian and other white-label cards.

>  The second reader is one with Bluetooth,
> I am able to  connect/pair with the device (under Ubuntu-14.04-LTS), but that is as far as it gets.
> Before delving into it (when I’m got permission to do so) is it theoretically possible to use Bluetooth smartcard readers in general, or is this completely uncharted territory.

I’ve gotten quite a few to work that expose a dead normal CCID/Serial with PC/SC - and which under the cover where pretty much a normal reader with no Bluetooth specific features (like card unseat, out of range). I.e. just treating the device; and naming it/mknod-ing it as a serial or single usb bulk endpoint (ignoring the control and interrupt endpoint for (un)seat). pcsc-lite is fairly easy to hack for this.

Dw.

[Opensc-devel] new readers

[<J.W...@mi...>]

Dear all,

This week I received two readers from VASCO for evaluation, the DP870 and the DP875
Both are class-3 (PINPAD plus display), and the 875 has Bluetooth capabilities.

Last couple of years I have had quite a number of PINPAD readers for evaluation.
Most of them don't work at all under Linux, some of them do, like the Gemalto CT710 (tnx Martin), but only with generic cards, like MyEID.
Until now _all_ of them failed to work with our AET applet and AET-drivers.
The DP870 does work out-of-the-box with opensc >= 13.0
Listing of open and protected structures (+PIN) work as expected.


The second reader is one with Bluetooth,
I am able to  connect/pair with the device (under Ubuntu-14.04-LTS), but that is as far as it gets.
Before delving into it (when I'm got permission to do so) is it theoretically possible to use Bluetooth smartcard readers in general, or is this completely uncharted territory.
(The Feitan BR301 only works through the USB-cable)

Kind regards, Hans.

______________________________________________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.

Re: [Opensc-devel] pam-p11 still exists, unstable download links

[Ludovic R. <lud...@gm...>]

Hello,

2015-09-07 21:43 GMT+02:00 Greg Troxel <gd...@ir...>:
>
> I am updating opensc-related packages in pkgsrc.
>
> https://opensc-project.org/opensc/wiki/pam_p11
> references a download link, but it is 404.   Does it exist?  Should I
> delete the package?

pam_p11 is hosted at https://github.com/OpenSC/pam_p11/releases
It is not really active. No change since 2013.

> A number of packages have unstable URLS like
>   https://alioth.debian.org/frs/download.php/file/4140/

This links works for me.
I agree that alioth uses strange URL. You can't just change the release number.

> I realize alioth probably works that way for a reason, but this causes
> two problems:
>
>   It's unncesssarily hard to do updates; just changing the version
>   number silently gets the old bits.
>
>   Code that tries to automatically check to see if updates are available
>   (see http://www.ki.nu/~makoto/pkgsrc/check-update/00_Summary.html )
>   doesn't work, because there the download base URL isn't a directory
>   with a bunch of versioned tarballs.
>
> So it would be really nice if the opensc projects had normal
> distribution directories.  I'll probably update them anyway even if not :-)

Sorry, I have no solution to your problem.

Bye

-- 
 Dr. Ludovic Rousseau

[Opensc-devel] pam-p11 still exists, unstable download links

[Greg T. <gd...@ir...>]

I am updating opensc-related packages in pkgsrc.

https://opensc-project.org/opensc/wiki/pam_p11
references a download link, but it is 404.   Does it exist?  Should I
delete the package?

A number of packages have unstable URLS like
  https://alioth.debian.org/frs/download.php/file/4140/
I realize alioth probably works that way for a reason, but this causes
two problems:

  It's unncesssarily hard to do updates; just changing the version
  number silently gets the old bits.

  Code that tries to automatically check to see if updates are available
  (see http://www.ki.nu/~makoto/pkgsrc/check-update/00_Summary.html )
  doesn't work, because there the download base URL isn't a directory
  with a bunch of versioned tarballs.

So it would be really nice if the opensc projects had normal
distribution directories.  I'll probably update them anyway even if not :-)

Greg

Re: [Opensc-devel] Yubico Neo with OpenPGP and PIV applets

[Simon J. <si...@jo...>]

Douglas E Engert <dee...@gm...> writes:

> Thanks for the response!
> and a few additional comments...
>
> On 9/2/2015 5:10 AM, Klas Lindfors wrote:
>> Hello,
>>
>>
>>     How does Yubico see the Neo being used if it has both a PIV and OpenPGP application?
>>
>>
>>  From Yubico's (or at least my) perspective the thinking around the applications is that PIV is used through OpenSC/Windows and OpenPGP is used through gnupg. Our perspective has been that they're
>> typically not used at the same time.
>
> Yes. But IIRC there have some comments in this or other mail list that
> while openpgp is using the card it locks the card up via PCSC, so the
> PIV can not be used for web authentication.
> Which implies that some users have programs running trying to use both
> applets. This may not be a Neo problem, but the openpgp card drivers.

That problem is because scdaemon opens the smartcard (via pcsc) in
exclusive mode, thereby locking out other pcsc users.  This was
discussed recently on the GnuPG devel list, and it is not related to NEO
or OpenSC.  One solution is to kill scdaemon when you want to do
non-scdaemon-based access.  It is not particulary pleasing, but at least
it works reliably.

>>     Is one default?
>>     How is the default set?
>>     Can the default be set on the card?
>>
>>
>> We've not thought of one of those two as default, more as options
>> depending on what the user wants / what the application
>> supports. There is no default selected applet on the Neo, and it
>> can't be set.
>
> The OpenSC issue is it can support both, and we need a better way for
> a user to tell OpenSC what it should do, or OpenSC need a way to
> present them via PKCS#11 as different tokens,
> in multiple slots.

Using PKCS#11 URLs in application contexts may help.  Then the user can
specify which token is intended.

>> It's an interesting idea, I'm not sure how practical it is (due to
>> several issues) but I'm happy to discuss possible solutions to
>> simultaneous use.
>
> If Neo hardware can support it, it could get around the openpgp
> locking problem. The Neo already presents itself as a USB keyboard,
> and a USB smartcard reader.
>
> It could present itself as a keyboard, and a USB reader for each
> application it supports via CCID. Each application having its own ATR.
> To the OS it looks like the user plugged in multiple readers with a different type of smart card in each.
> PCSC would treat them as separate readers and devices. Thus different
> smartcard middleware would not lock each other out while trying to use
> the cards.
> So combinations of Windows PIV driver, OpenSC or some other OpenPGP
> driver would see the card they wanted to see looking for the AID or
> ATR.

Interesting idea, but I don't see that it is feasible.  For example, how
to deal with concurrent access?  The smartcard can only have one app
selected at the same time anyway, as far as I understand.

/Simon

[Opensc-devel] Decrypt with private key

[Emmanuel N. de L. F. <emm...@se...>]

Hi, a have file encrypted file with public key and want to decrypt with private key of my smartcard. I tried this command but it fail.

$ pkcs11-tool --module /usr/lib/watchdata/ICP/lib/libwdpkcs_icp.so -l --pin MYPASSWD -m RSA-X-509 --usage-decrypt --id 10 -i /tmp/a -o /tmp/b

What's wrong? How to do that?

Some data:
$ pkcs11-tool --module /usr/lib/watchdata/ICP/lib/libwdpkcs_icp.so -l --pin MYPASSWD -O
Using slot 0 with a present token (0x1)
Private Key Object; RSA 
  label:      
  ID:         28313232393537302920454d4d414e55454c204e415a4152454e4f204445204c494d4120464552524f
  Usage:      decrypt, sign, unwrap
warning: PKCS11 function C_GetAttributeValue(ALWAYS_AUTHENTICATE) failed: rv = CKR_ATTRIBUTE_TYPE_INVALID (0x12)

Private Key Object; RSA 
  label:      
  ID:         10
  Usage:      decrypt, sign, unwrap
warning: PKCS11 function C_GetAttributeValue(ALWAYS_AUTHENTICATE) failed: rv = CKR_ATTRIBUTE_TYPE_INVALID (0x12)

Private Key Object; RSA 
  label:      
  ID:         10
  Usage:      decrypt, sign, unwrap
warning: PKCS11 function C_GetAttributeValue(ALWAYS_AUTHENTICATE) failed: rv = CKR_ATTRIBUTE_TYPE_INVALID (0x12)

Private Key Object; RSA 
  label:      
  ID:         10
  Usage:      decrypt, sign, unwrap
warning: PKCS11 function C_GetAttributeValue(ALWAYS_AUTHENTICATE) failed: rv = CKR_ATTRIBUTE_TYPE_INVALID (0x12)

Private Key Object; RSA 
  label:      
  ID:         10
  Usage:      decrypt, sign, unwrap
warning: PKCS11 function C_GetAttributeValue(ALWAYS_AUTHENTICATE) failed: rv = CKR_ATTRIBUTE_TYPE_INVALID (0x12)

Private Key Object; RSA 
  label:      
  ID:         10
  Usage:      decrypt, sign, unwrap
warning: PKCS11 function C_GetAttributeValue(ALWAYS_AUTHENTICATE) failed: rv = CKR_ATTRIBUTE_TYPE_INVALID (0x12)

Public Key Object; RSA 2048 bits
  label:      
  Usage:      encrypt, verify, wrap
Certificate Object, type = X.509 cert
  label:      (1229570) EMMANUEL NAZARENO DE LIMA FERRO
  ID:         28313232393537302920454d4d414e55454c204e415a4152454e4f204445204c494d4120464552524f
Public Key Object; RSA 1024 bits
  label:      
  ID:         10
  Usage:      encrypt, verify, wrap
Public Key Object; RSA 1024 bits
  label:      
  ID:         10
  Usage:      encrypt, verify, wrap
Public Key Object; RSA 1024 bits
  label:      
  ID:         10
  Usage:      encrypt, verify, wrap
Public Key Object; RSA 1024 bits
  label:      
  ID:         10
  Usage:      encrypt, verify, wrap
Public Key Object; RSA 1024 bits
  label:      
  ID:         10
  Usage:      encrypt, verify, wrap

$ pkcs11-tool --module /usr/lib/watchdata/ICP/lib/libwdpkcs_icp.so -l --pin MYPASSWD -M
Using slot 0 with a present token (0x1)
Supported mechanisms:
  RSA-PKCS-KEY-PAIR-GEN, keySize={1024,1024}, hw, generate_key_pair
  DES-KEY-GEN, hw, generate
  AES-KEY-GEN, hw, generate
  mechtype-2147483649, hw, generate
  DES3-KEY-GEN, hw, generate
  RSA-PKCS, keySize={1024,1024}, hw, encrypt, decrypt, sign, sign_recover, verify, verify_recover, wrap, unwrap
  RSA-X-509, keySize={1024,1024}, hw, encrypt, decrypt, sign, sign_recover, verify, verify_recover, wrap, unwrap
  MD2-RSA-PKCS, keySize={512,2048}, hw, sign, verify
  MD5-RSA-PKCS, keySize={512,2048}, hw, sign, verify
  SHA1-RSA-PKCS, keySize={512,2048}, hw, sign, verify
  SHA256-RSA-PKCS, keySize={512,2048}, hw, sign, verify
  DES-ECB, hw, encrypt, decrypt, wrap, unwrap
  DES-CBC, hw, encrypt, decrypt, wrap, unwrap
  DES-CBC-PAD, hw, encrypt, decrypt, wrap, unwrap
  mechtype-2147483650, hw, encrypt, decrypt, wrap, unwrap
  mechtype-2147483651, hw, encrypt, decrypt, wrap, unwrap
  mechtype-2147483652, hw, encrypt, decrypt, wrap, unwrap
  mechtype-2147483655, hw, encrypt, decrypt, wrap, unwrap
  mechtype-2147483656, hw, encrypt, decrypt, wrap, unwrap
  mechtype-2147483657, hw, encrypt, decrypt, wrap, unwrap
  AES-ECB, hw, encrypt, decrypt, wrap, unwrap
  AES-CBC, hw, encrypt, decrypt, wrap, unwrap
  AES-CBC-PAD, hw, encrypt, decrypt, wrap, unwrap
  DES3-ECB, hw, encrypt, decrypt, wrap, unwrap
  DES3-CBC, hw, encrypt, decrypt, wrap, unwrap
  DES3-CBC-PAD, hw, encrypt, decrypt, wrap, unwrap
  SHA-1, hw, digest
  SHA-1-HMAC, hw, sign, verify
  SHA-1-HMAC-GENERAL, hw, sign, verify
  MD2, hw, digest
  MD2-HMAC, hw, sign, verify
  MD2-HMAC-GENERAL, hw, sign, verify
  MD5, hw, digest
  MD5-HMAC, hw, sign, verify
  MD5-HMAC-GENERAL, hw, sign, verify
  SSL3-PRE-MASTER-KEY-GEN, keySize={48,48}, hw, generate
  SSL3-MASTER-KEY-DERIVE, keySize={48,48}, hw, derive
  SSL3-KEY-AND-MAC-DERIVE, keySize={48,48}, hw, derive
  SSL3-MD5-MAC, keySize={384,384}, hw, sign, verify
  SSL3-SHA1-MAC, keySize={384,384}, hw, sign, verify
  SHA256, hw, digest
  mechtype-593, hw, sign, verify
  mechtype-594, hw, sign, verify



-- 
-- 

“Se você quer ir rápido, vá sozinho. Se quer ir longe, vá acompanhado." (provérbio africano)

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

Emmanuel Ferro 

SERPRO - Escritório São Luís

SUPOP/OPFLA/OPSLS

Comitê Regional de Software Livre

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


-


"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco."

"This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure."

Re: [Opensc-devel] Yubico Neo with OpenPGP and PIV applets

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

Thanks for the response!
and a few additional comments...

On 9/2/2015 5:10 AM, Klas Lindfors wrote:
> Hello,
>
>
>     How does Yubico see the Neo being used if it has both a PIV and OpenPGP application?
>
>
>  From Yubico's (or at least my) perspective the thinking around the applications is that PIV is used through OpenSC/Windows and OpenPGP is used through gnupg. Our perspective has been that they're
> typically not used at the same time.

Yes. But IIRC there have some comments in this or other mail list that while openpgp is using the card it locks the card up via PCSC, so the PIV can not be used for web authentication.
Which implies that some users have programs running trying to use both applets. This may not be a Neo problem, but the openpgp card drivers.

>
>     Is one default?
>     How is the default set?
>     Can the default be set on the card?
>
>
> We've not thought of one of those two as default, more as options depending on what the user wants / what the application supports. There is no default selected applet on the Neo, and it can't be set.

The OpenSC issue is it can support both, and we need a better way for a user to tell OpenSC what it should do, or OpenSC need a way to present them via PKCS#11 as different tokens,
in multiple slots.

>
>
>     The Neo presents the same ATR for both. The Neo does not take advantage of the ATR Historical bytes.
>
>
> No, we've not used the ATR at all to advertise what applications are present, the ATR is also different over the contactless interface.

The PIV driver does not compare ATRs these days. I never noticed. It looks for the PIV aid on any card, its looking the the applet, not the card.
The OpenPGP driver needs to do this too.

>
>
>     Are there end users who want to use both, at the same time?
>
>
> There has been questions about this, not very common and we've not come up with a good solution for it.
>
>
>     Has Yubico look at presenting the Neo as two devices on the UCB bus with a different ATRs for the
>     OpenPGP and PIV applications? (Historical bytes including the AID?)

For example, using the NIST test cards. In my set (other sets may be different)

card 1 is a Gemalto PIV 1.5.5 DLv1 no NFC, uses T=0
3b:7d:96:00:00:80:31:80:65:b0:83:11:17:d6:83:00:90:00

Card 2 is a Oberthur ID-One PIV has NFC, uses T=1
3b:df:96:00:81:b1:fe:45:1f:83:80:73:cc:91:cb:f9:a0:00:00:03:08:00:00:10:00:79

Note the PIV AID in the historical bytes a0:00:00:03:08:00:00:10:00

>
>
> It's an interesting idea, I'm not sure how practical it is (due to several issues) but I'm happy to discuss possible solutions to simultaneous use.

If Neo hardware can support it, it could get around the openpgp locking problem. The Neo already presents itself as a USB keyboard, and a USB smartcard reader.

It could present itself as a keyboard, and a USB reader for each application it supports via CCID. Each application having its own ATR.
To the OS it looks like the user plugged in multiple readers with a different type of smart card in each.
PCSC would treat them as separate readers and devices. Thus different smartcard middleware would not lock each other out while trying to use the cards.
So combinations of Windows PIV driver, OpenSC or some other OpenPGP driver would see the card they wanted to see looking for the AID or ATR.

>
>
>     The OpenSC PIV drivers checks for the PIV AID. The OpenSC OpenPGP driver has not, but issue #507 is trying to address this.
>
>
> I've always found checking for AID to be more exact, but that's coming from and angle where multiple applications can be loaded and you can't really tell from the ATR exactly what applications might
> be found on a specific card.

I agree, it also means as an applet is ported to newer cards, because some issuing agency (gov or company...) wants to change cards.
The AID stays the same, the applet will still be found by the existing middleware.


>
>
>     Does Yubico developers follow the OpenSC discussions?
>
>
> I try to follow opensc-devel for relevant stuff and keep up to date with what happens in the code.
>
>     Do they test OpenSC with their devices?
>
>
> As I wrote above our view is that the PIV parts of YubiKey devices should work with OpenSC we test that.
>
>
>     Thanks.
>
>
> Thank you!
>
> /klas

-- 

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

Re: [Opensc-devel] Yubico Neo with OpenPGP and PIV applets

[Frank M. <mo...@in...>]

Hi, Klas!

Thanks for clearifying. With your response we'll use PIV as default for
the NEO.

Just one more question: We encountered a bug in the PIV applet that's
specific for the NEO, see https://github.com/OpenSC/OpenSC/pull/530.
We'd like to add a workaround only for the NEO. How do we identify the
NEO if the ATR is not unique (or may change depending on the interface)?

Greets, Frank.


Am Mittwoch, dem 02. September, um 12:10 Uhr schrieb Klas Lindfors:
> Hello,
> 
> 
> How does Yubico see the Neo being used if it has both a PIV and OpenPGP
> > application?
> >
> 
> >From Yubico's (or at least my) perspective the thinking around the
> applications is that PIV is used through OpenSC/Windows and OpenPGP is used
> through gnupg. Our perspective has been that they're typically not used at
> the same time.
> 
> 
> > Is one default?
> > How is the default set?
> > Can the default be set on the card?
> >
> 
> We've not thought of one of those two as default, more as options depending
> on what the user wants / what the application supports. There is no default
> selected applet on the Neo, and it can't be set.
> 
> 
> >
> > The Neo presents the same ATR for both. The Neo does not take advantage of
> > the ATR Historical bytes.
> >
> 
> No, we've not used the ATR at all to advertise what applications are
> present, the ATR is also different over the contactless interface.
> 
> 
> > Are there end users who want to use both, at the same time?
> >
> 
> There has been questions about this, not very common and we've not come up
> with a good solution for it.
> 
> 
> >
> > Has Yubico look at presenting the Neo as two devices on the UCB bus with a
> > different ATRs for the
> > OpenPGP and PIV applications? (Historical bytes including the AID?)
> >
> 
> It's an interesting idea, I'm not sure how practical it is (due to several
> issues) but I'm happy to discuss possible solutions to simultaneous use.
> 
> 
> >
> > The OpenSC PIV drivers checks for the PIV AID. The OpenSC OpenPGP driver
> > has not, but issue #507 is trying to address this.
> >
> 
> I've always found checking for AID to be more exact, but that's coming from
> and angle where multiple applications can be loaded and you can't really
> tell from the ATR exactly what applications might be found on a specific
> card.
> 
> 
> >
> > Does Yubico developers follow the OpenSC discussions?
> >
> 
> I try to follow opensc-devel for relevant stuff and keep up to date with
> what happens in the code.
> 
> 
> > Do they test OpenSC with their devices?
> >
> 
> As I wrote above our view is that the PIV parts of YubiKey devices should
> work with OpenSC we test that.
> 
> >
> >
> > Thanks.
> >
> 
> Thank you!
> 
> /klas

> ------------------------------------------------------------------------------
> Monitor Your Dynamic Infrastructure at Any Scale With Datadog!
> Get real-time metrics from all of your servers, apps and tools
> in one place.
> SourceForge users - Click here to start your Free Trial of Datadog now!
> http://pubads.g.doubleclick.net/gampad/clk?id=241902991&iu=/4140
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel


-- 
Frank Morgner

Virtual Smart Card Architecture http://vsmartcard.sourceforge.net
OpenPACE                        http://openpace.sourceforge.net
IFD Handler for libnfc Devices  http://sourceforge.net/projects/ifdnfc