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

Re: [Opensc-devel] Question about C_InitToken reinitialize

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

You asked about OpenSC documentation. OpenSC attempts to present a PKC#11
interface for use by a user. But it really comes done to what the specific
token (card) allows. Many of the tokens do not support what you are trying
to do. OpenSC includes a number of card specific tools to help administer
cards.

In many security environments, the card is issued by some organization
(company/university/gov) where the user never knows the SO pin (if there is
one)  Many of these cards use  a 3DES or AES key for authentication to do
card administration. The card administration is done in a secure
environment so the SO pin and 3DES or AES keys are kept secure. OpenSC is
not trying to support such environments.

It sounds like you are in an environment where the user should know the SO
pin, as your question what if the user lost/forgot the SO pin. My answer
would to buy a new card.

So some questions about what are you really trying to do:
Do you have a specific card in mind?
Do you expect the user to do their own card administration? i.e. know the
SO pin?
Are you trying to be a card issuer and do remote administration over the
web?
(As hinted at above there are many security issues with doing this.)






On Mon, Oct 29, 2018 at 9:03 AM Bob Backlund <fig...@gm...>
wrote:

> Hi Paul,
>
> Thank you for your reply. I appreciate your help, I have some comments
> below.
>
> Hi! It seems that the SO PIN you passed should be checked by the token
> itself. In other words it can be stated as: in order to re-initialize the
> token you have to *log on* to that token.
>  - Do you mean that before I call the C_InitToken that the verification of
> the SO PIN should be done outside the C_InitToken, like calling the C_Login
> before the C_InitToken? The PKCS# 11 statement I mentioned is under the
> C_InitToken definition from my understanding the verification of the SO PIN
> should be done inside the C_InitToken. I am testing the C_InitToken with
> two test case, first test case is that I give the correct SO PIN, second
> case is I give the wrong SO PIN. On the first case my expectation is that
> C_InitToken will reset the card (deleting the deletable objects inside,
> reverting to the state when the first C_InitToken was called), second test
> case I expect the C_InitToken will give me an error and not reset the card.
>
> But that leads to the following problem: what to do if you forget the SO
> PIN and that is why you want to *reset* the token completely?
>  - The PKCS# 11 document answered that one here's what they said.
> If the SO PIN is lost, then the  card  must  be  reinitialized  using  a
> mechanism  outside  the  scope  of  this  standard.
>
> Second, if you look at the implementation of init_token() at
> pkcs11-tool.c, you find, that it asks for the *new* SO PIN, not the
> existing SO PIN. And that is true for the cards and tokens I'm working
> with: I enter there any SO PIN I want and get a newly initialized token
> with no data on it.
>  - I understand, your explanation makes sense with the current source
> code. But my problem is that, is it safe that way, because anyone can just
> call the C_InitToken to reset the card and deleting all the keys inside.
> How do you secure yourself from this scenario?
>
> Here's longer definition of C_InitToken from the PKCS# 11 document.
> C_InitToken initializes a token. slotID is the ID of the token’s slot;pPin
> points to the SO’s initial PIN (which need not be null-terminated);
> ulPinLen is the lengthin bytes of the PIN; pLabel points to the 32-byte
> label of the token (which must be padded with blank characters, and which
> must not be null-terminated). This standard allows PIN values to contain
> any valid UTF8 character, but the token may impose subset restrictions.
> Ifthe token has not beeninitialized(i.e.newfromthefactory),thenthe pPin
> parameterbecomes the initial value of the SO PIN. If the token is being
> reinitialized, the
> pPin parameter is checkedagainsttheexistingSOPINtoauthorize the
> initialization operation. In both cases, the SOPINisthevaluepPin after the
> function completes successfully. If the SO PIN is lost, then
> thecardmustbereinitializedusingamechanismoutsidethescopeofthisstandard.The
> CKF_TOKEN_INITIALIZED flag in the CK_TOKEN_INFO structure indicates the
> action thatwillresultfromcalling C_InitToken.Ifset,thetokenwillbe
> reinitialized,andtheclient must supply the existing SO password in pPin.
> Source: https://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-11r1.pdf
>
> Thank you for your help!
>
> fightingsibuyas
>
>
> On Mon, Oct 29, 2018 at 7:14 PM Paul Wolneykien <ma...@al...>
> wrote:
>
>> 29.10.2018 12:59, Bob Backlund пишет:
>> > Hi,
>> >
>> > Just some question on the C_InitToken implementation of OpenSC, the
>> > PKCS#11 document states the following below.
>> > /
>> > If the token is being reinitialized, the *pPin parameter is checked
>> > against the  existing SO PIN* to authorize the initialization operation.
>> > /
>> > When the token is reinitialized, the C_InitToken should verify the PIN
>> > passed to it with the one provided on the first initialization.
>> >
>> > I tried to trace the source code but it seems this is not handled on the
>> > C_InitToken layer, the C_InitToken will just pass the data (pin, pin
>> > length, label) to PKCS#11 framework, or the pkcs15_initialize function.
>>
>>   Hi! It seems that the SO PIN you passed should be checked by the token
>> itself. In other words it can be stated as: in order to re-initialize
>> the token you have to *log on* to that token. But that leads to the
>> following problem: what to do if you forget the SO PIN and that is why
>> you want to *reset* the token completely?
>>   Second, if you look at the implementation of init_token() at
>> pkcs11-tool.c, you find, that it asks for the *new* SO PIN, not the
>> existing SO PIN. And that is true for the cards and tokens I'm working
>> with: I enter there any SO PIN I want and get a newly initialized token
>> with no data on it.
>>
>>
>> > On this function, it will check if there is an implementation for the
>> > SC_CARDCTL_PKCS11_INIT_TOKEN command on the card level (card-*), the
>> > data is passed on this function. Most of the driver did not implement
>> > this one.
>> > After the call on this function, sc_pkcs15init_erase_card is also
>> > called, but data is not passed.
>> >
>> > After this, pkcs15nit_add_app is called, this is the function that do
>> > the initialization, but until here the existing SO validation was not
>> > handle, data was passed on this function.
>> >
>> > So, my question is if wanted to support the existing SO validation (as
>> > stated in PKCS#11 document) for the C_InitToken, what will be my
>> > approach? I was thinking of implementing SC_CARDCTL_PKCS11_INIT_TOKEN,
>> > but this is on the card level and it doesn't know anything about the
>> > PKCS#11 object or the PKCS# 15 structure.
>> >
>> > I appreciate if someone can put me on the direction or at least the a
>> > document that I can read that discusses this part of OpenSC.
>> >
>> > Thank you very much!
>> >
>> >
>> > Cheers,
>> >
>> > fightingsibuyas
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > Opensc-devel mailing list
>> > Ope...@li...
>> > https://lists.sourceforge.net/lists/listinfo/opensc-devel
>> >
>>
>>
>>
>> _______________________________________________
>> Opensc-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

Re: [Opensc-devel] Question about C_InitToken reinitialize

[Bob B. <fig...@gm...>]

Hi Paul,

Thank you for your reply. I appreciate your help, I have some comments
below.

Hi! It seems that the SO PIN you passed should be checked by the token
itself. In other words it can be stated as: in order to re-initialize the
token you have to *log on* to that token.
 - Do you mean that before I call the C_InitToken that the verification of
the SO PIN should be done outside the C_InitToken, like calling the C_Login
before the C_InitToken? The PKCS# 11 statement I mentioned is under the
C_InitToken definition from my understanding the verification of the SO PIN
should be done inside the C_InitToken. I am testing the C_InitToken with
two test case, first test case is that I give the correct SO PIN, second
case is I give the wrong SO PIN. On the first case my expectation is that
C_InitToken will reset the card (deleting the deletable objects inside,
reverting to the state when the first C_InitToken was called), second test
case I expect the C_InitToken will give me an error and not reset the card.

But that leads to the following problem: what to do if you forget the SO
PIN and that is why you want to *reset* the token completely?
 - The PKCS# 11 document answered that one here's what they said.
If the SO PIN is lost, then the  card  must  be  reinitialized  using  a
mechanism  outside  the  scope  of  this  standard.

Second, if you look at the implementation of init_token() at pkcs11-tool.c,
you find, that it asks for the *new* SO PIN, not the existing SO PIN. And
that is true for the cards and tokens I'm working with: I enter there any
SO PIN I want and get a newly initialized token with no data on it.
 - I understand, your explanation makes sense with the current source code.
But my problem is that, is it safe that way, because anyone can just call
the C_InitToken to reset the card and deleting all the keys inside. How do
you secure yourself from this scenario?

Here's longer definition of C_InitToken from the PKCS# 11 document.
C_InitToken initializes a token. slotID is the ID of the token’s slot;pPin
points to the SO’s initial PIN (which need not be null-terminated);
ulPinLen is the lengthin bytes of the PIN; pLabel points to the 32-byte
label of the token (which must be padded with blank characters, and which
must not be null-terminated). This standard allows PIN values to contain
any valid UTF8 character, but the token may impose subset restrictions.
Ifthe token has not beeninitialized(i.e.newfromthefactory),thenthe pPin
parameterbecomes the initial value of the SO PIN. If the token is being
reinitialized, the
pPin parameter is checkedagainsttheexistingSOPINtoauthorize the
initialization operation. In both cases, the SOPINisthevaluepPin after the
function completes successfully. If the SO PIN is lost, then
thecardmustbereinitializedusingamechanismoutsidethescopeofthisstandard.The
CKF_TOKEN_INITIALIZED flag in the CK_TOKEN_INFO structure indicates the
action thatwillresultfromcalling C_InitToken.Ifset,thetokenwillbe
reinitialized,andtheclient must supply the existing SO password in pPin.
Source: https://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-11r1.pdf

Thank you for your help!

fightingsibuyas


On Mon, Oct 29, 2018 at 7:14 PM Paul Wolneykien <ma...@al...>
wrote:

> 29.10.2018 12:59, Bob Backlund пишет:
> > Hi,
> >
> > Just some question on the C_InitToken implementation of OpenSC, the
> > PKCS#11 document states the following below.
> > /
> > If the token is being reinitialized, the *pPin parameter is checked
> > against the  existing SO PIN* to authorize the initialization operation.
> > /
> > When the token is reinitialized, the C_InitToken should verify the PIN
> > passed to it with the one provided on the first initialization.
> >
> > I tried to trace the source code but it seems this is not handled on the
> > C_InitToken layer, the C_InitToken will just pass the data (pin, pin
> > length, label) to PKCS#11 framework, or the pkcs15_initialize function.
>
>   Hi! It seems that the SO PIN you passed should be checked by the token
> itself. In other words it can be stated as: in order to re-initialize
> the token you have to *log on* to that token. But that leads to the
> following problem: what to do if you forget the SO PIN and that is why
> you want to *reset* the token completely?
>   Second, if you look at the implementation of init_token() at
> pkcs11-tool.c, you find, that it asks for the *new* SO PIN, not the
> existing SO PIN. And that is true for the cards and tokens I'm working
> with: I enter there any SO PIN I want and get a newly initialized token
> with no data on it.
>
>
> > On this function, it will check if there is an implementation for the
> > SC_CARDCTL_PKCS11_INIT_TOKEN command on the card level (card-*), the
> > data is passed on this function. Most of the driver did not implement
> > this one.
> > After the call on this function, sc_pkcs15init_erase_card is also
> > called, but data is not passed.
> >
> > After this, pkcs15nit_add_app is called, this is the function that do
> > the initialization, but until here the existing SO validation was not
> > handle, data was passed on this function.
> >
> > So, my question is if wanted to support the existing SO validation (as
> > stated in PKCS#11 document) for the C_InitToken, what will be my
> > approach? I was thinking of implementing SC_CARDCTL_PKCS11_INIT_TOKEN,
> > but this is on the card level and it doesn't know anything about the
> > PKCS#11 object or the PKCS# 15 structure.
> >
> > I appreciate if someone can put me on the direction or at least the a
> > document that I can read that discusses this part of OpenSC.
> >
> > Thank you very much!
> >
> >
> > Cheers,
> >
> > fightingsibuyas
> >
> >
> >
> >
> > _______________________________________________
> > Opensc-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opensc-devel
> >
>
>
>
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

Re: [Opensc-devel] Question about C_InitToken reinitialize

[Paul W. <ma...@al...>]

29.10.2018 12:59, Bob Backlund пишет:
> Hi,
> 
> Just some question on the C_InitToken implementation of OpenSC, the
> PKCS#11 document states the following below.
> /
> If the token is being reinitialized, the *pPin parameter is checked
> against the  existing SO PIN* to authorize the initialization operation.
> /
> When the token is reinitialized, the C_InitToken should verify the PIN
> passed to it with the one provided on the first initialization.
> 
> I tried to trace the source code but it seems this is not handled on the
> C_InitToken layer, the C_InitToken will just pass the data (pin, pin
> length, label) to PKCS#11 framework, or the pkcs15_initialize function.

  Hi! It seems that the SO PIN you passed should be checked by the token
itself. In other words it can be stated as: in order to re-initialize
the token you have to *log on* to that token. But that leads to the
following problem: what to do if you forget the SO PIN and that is why
you want to *reset* the token completely?
  Second, if you look at the implementation of init_token() at
pkcs11-tool.c, you find, that it asks for the *new* SO PIN, not the
existing SO PIN. And that is true for the cards and tokens I'm working
with: I enter there any SO PIN I want and get a newly initialized token
with no data on it.


> On this function, it will check if there is an implementation for the
> SC_CARDCTL_PKCS11_INIT_TOKEN command on the card level (card-*), the
> data is passed on this function. Most of the driver did not implement
> this one.
> After the call on this function, sc_pkcs15init_erase_card is also
> called, but data is not passed.
> 
> After this, pkcs15nit_add_app is called, this is the function that do
> the initialization, but until here the existing SO validation was not
> handle, data was passed on this function.
> 
> So, my question is if wanted to support the existing SO validation (as
> stated in PKCS#11 document) for the C_InitToken, what will be my
> approach? I was thinking of implementing SC_CARDCTL_PKCS11_INIT_TOKEN,
> but this is on the card level and it doesn't know anything about the
> PKCS#11 object or the PKCS# 15 structure. 
> 
> I appreciate if someone can put me on the direction or at least the a
> document that I can read that discusses this part of OpenSC.
> 
> Thank you very much!
> 
> 
> Cheers,
> 
> fightingsibuyas
> 
> 
> 
> 
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> 

[Opensc-devel] Question about C_InitToken reinitialize

[Bob B. <fig...@gm...>]

Hi,

Just some question on the C_InitToken implementation of OpenSC, the PKCS#11
document states the following below.


*If the token is being reinitialized, the pPin parameter is checked against
the  existing SO PIN to authorize the initialization operation.*
When the token is reinitialized, the C_InitToken should verify the PIN
passed to it with the one provided on the first initialization.

I tried to trace the source code but it seems this is not handled on the
C_InitToken layer, the C_InitToken will just pass the data (pin, pin
length, label) to PKCS#11 framework, or the pkcs15_initialize function.

On this function, it will check if there is an implementation for the
SC_CARDCTL_PKCS11_INIT_TOKEN command on the card level (card-*), the data
is passed on this function. Most of the driver did not implement this one.
After the call on this function, sc_pkcs15init_erase_card is also called,
but data is not passed.

After this, pkcs15nit_add_app is called, this is the function that do the
initialization, but until here the existing SO validation was not handle,
data was passed on this function.

So, my question is if wanted to support the existing SO validation (as
stated in PKCS#11 document) for the C_InitToken, what will be my approach?
I was thinking of implementing SC_CARDCTL_PKCS11_INIT_TOKEN, but this is on
the card level and it doesn't know anything about the PKCS#11 object or the
PKCS# 15 structure.

I appreciate if someone can put me on the direction or at least the a
document that I can read that discusses this part of OpenSC.

Thank you very much!


Cheers,

fightingsibuyas

Re: [Opensc-devel] eToken 5110 support (Gemalto/SafeNet/Aladdin)

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

Le mer. 17 oct. 2018 à 15:41, Juraj Šedivý <jur...@en...> a écrit :
>
> Hi,
>
> new to OpenSC. We're using (Gemalto) Safenet 5110 tokens at our company, which (AFAIK) are not supported by OpenSC. I'm querying about the possibility mentioned on your GitHub wiki about someone writing a new driver for it. Would there be any OpenSC developers willing to consider this?
>
> I have read a relevant thread in opensc-devel (https://sourceforge.net/p/opensc/mailman/message/32292116/), but could not make much sense of where OpenSC stands on the issue.
>
> We understand this is a community developed project and resources are probably scarce, so this is just an informal query. I'm not entirely sure how active the project is at the moment. I can't promise any funding/sponsorship in advance, but I would pitch the idea to my superiors if someone would be willing to try it.
>
> Currently we use the proprietary driver from Gemalto. Gemalto offers both Windows binaries and Linux RPM and DEB packages. Windows driver is fine, but on Linux, we have an annoying issue when using pam_pkcs11, with the driver getting stuck in an endless loop running the select() system call and using up an entire CPU core. We suspect the driver is to blame.

You should report the problem to Gemalto (if not already done).

I don't know any project to support this token in OpenSC.

Regards,

-- 
 Dr. Ludovic Rousseau

Re: [Opensc-devel] Engine support for ed25519 keys

[Jakub J. <jj...@re...>]

On Fri, 2018-09-14 at 18:40 +0000, Paras Shah (parashah) via Opensc-
devel wrote:
> Does the pkcs11 engine support the ed25519 keys?
> 
> I get the following error when I try to access the ed25519 key stored
> in SoftHSM via the openssl engine interface.
> 
> []:~$ openssl pkey -in
> "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a16
> 0d52b750862f;token=token%202.5.0-
> rc1;id=%22%22;object=ed25519%20leaf%20key;type=private" -inform
> ENGINE -engine pkcs11 -text
> engine "pkcs11" set.
> Enter PKCS#11 token PIN for token 2.5.0-rc1:
> Key not found.
> PKCS11_get_private_key returned NULL
> cannot load key from engine
> 140736065815424:error:80067065:pkcs11 engine:ctx_load_privkey:object
> not found:eng_back.c:862:
> 140736065815424:error:26096080:engine
> routines:ENGINE_load_private_key:failed loading private
> key:crypto/engine/eng_pkey.c:78:
> unable to load key
> 
> 
> The openssl version used above is 1.1.1. which supports the ed25519
> keys.

The current PKCS#11 specification does not define the ed25519 keys yet.
The SoftHSM has them in vendor-specific extensions (if I am right),
which is not interoperable with neither engine_pkcs11 nor openssl in
the end.

The next PKCS#11 specification should support the ed25519 keys in
standard way so once this will be out, SoftHSM fixed and the support
implemented in engine_pkcs11, all together will work. Until then, you
are limited to other key formats.

Regards,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.

[Opensc-devel] eToken 5110 support (Gemalto/SafeNet/Aladdin)

[Juraj Š. <jur...@en...>]

Hi,

new to OpenSC. We're using (Gemalto) Safenet 5110 tokens at our company,
which (AFAIK) are not supported by OpenSC. I'm querying about the
possibility mentioned on your GitHub wiki about someone writing a new
driver for it. Would there be any OpenSC developers willing to consider
this?

I have read a relevant thread in opensc-devel (
https://sourceforge.net/p/opensc/mailman/message/32292116/), but could not
make much sense of where OpenSC stands on the issue.

We understand this is a community developed project and resources are
probably scarce, so this is just an informal query. I'm not entirely sure
how active the project is at the moment. I can't promise any
funding/sponsorship in advance, but I would pitch the idea to my superiors
if someone would be willing to try it.

Currently we use the proprietary driver from Gemalto. Gemalto offers both
Windows binaries and Linux RPM and DEB packages. Windows driver is fine,
but on Linux, we have an annoying issue when using pam_pkcs11, with the
driver getting stuck in an endless loop running the select() system call
and using up an entire CPU core. We suspect the driver is to blame.

Running opensc-tool --atr returns the following:
Using reader with a card: AKS ifdh [eToken 5110 SC] 00 00
3b:d5:18:00:81:31:3a:7d:80:73:c8:21:10:30

As for reverse engineering, the Gemalto drivers are obviously copyrighted
and I'm not sure where the law stands on such issues. I was under the
impression that EU law allows reverse engineering under certain
circumstances ("ensuring compatibility" or something similar?), but no idea
about how it works elsewhere.

Best Regards,

Juraj Sedivy

Re: [Opensc-devel] Selective build

[Paras S. (parashah) <par...@ci...>]

Please disregard this. Sent in error.

From: "Paras Shah (parashah) via Opensc-devel" <ope...@li...>
Reply-To: "Paras Shah (parashah)" <par...@ci...>
Date: Monday, October 8, 2018 at 2:38 PM
To: "Paras Shah (parashah) via Opensc-devel" <ope...@li...>
Subject: Re: [Opensc-devel] Selective build

Glide I –force

git submodule update --init --recursive


From: "Alok Nikhil (anikhil)" <an...@ci...>
Date: Tuesday, September 25, 2018 at 11:46 AM
To: "Paras Shah (parashah)" <par...@ci...>
Subject: Selective build


  *   Make proto
  *   Go generate in core/system
  *   Make in core/ledger
  *   Go generate in utils/softhsmv2/hsm..
  *   go build core/communication/test/proto_node.go

Re: [Opensc-devel] Selective build

[Paras S. (parashah) <par...@ci...>]

Glide I –force

git submodule update --init --recursive


From: "Alok Nikhil (anikhil)" <an...@ci...>
Date: Tuesday, September 25, 2018 at 11:46 AM
To: "Paras Shah (parashah)" <par...@ci...>
Subject: Selective build


  *   Make proto
  *   Go generate in core/system
  *   Make in core/ledger
  *   Go generate in utils/softhsmv2/hsm..
  *   go build core/communication/test/proto_node.go

[Opensc-devel] Engine support for ed25519 keys

[Paras S. (parashah) <par...@ci...>]

Does the pkcs11 engine support the ed25519 keys?

I get the following error when I try to access the ed25519 key stored in SoftHSM via the openssl engine interface.

[]:~$ openssl pkey -in "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%22%22;object=ed25519%20leaf%20key;type=private" -inform ENGINE -engine pkcs11 -text
engine "pkcs11" set.
Enter PKCS#11 token PIN for token 2.5.0-rc1:
Key not found.
PKCS11_get_private_key returned NULL
cannot load key from engine
140736065815424:error:80067065:pkcs11 engine:ctx_load_privkey:object not found:eng_back.c:862:
140736065815424:error:26096080:engine routines:ENGINE_load_private_key:failed loading private key:crypto/engine/eng_pkey.c:78:
unable to load key


The openssl version used above is 1.1.1. which supports the ed25519 keys.

-- 
Paras

[Opensc-devel] SoftHSM + Openssl engine not working with EC keys

[Paras S. (parashah) <par...@ci...>]

I have softhsm-v2.5.0-rc1 which has ec keys imported in it. Now, when I try to use these keys from openssl CLI using the pkcs11 engine, it fails.



1. SoftHSM version



[]:~$ softhsm2-util --version

2.5.0rc1



2. SoftHSM token init



[]:~$ softhsm2-util --init-token --slot 0 --label "token 2.5.0-rc1"

=== SO PIN (4-255 characters) ===

Please enter SO PIN: ****

Please reenter SO PIN: ****

=== User PIN (4-255 characters) ===

Please enter user PIN: ****

Please reenter user PIN: ****

The token has been initialized and is reassigned to slot 928024111



3. ECC key in pkcs8 format



[]:~$ openssl pkey -in ~/tmp/secp256k1-key.pem.pkcs8 -text

-----BEGIN PRIVATE KEY-----

MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgYCXpIJyEAexhkvrCMGlF

A4sQItcIp6wm83WVoeOFzEyhRANCAATMfAkLtsynHRmRyYLn+uRpJUm6bOZJBQhK

N81nJv06fN6MY0nEzWG9jJsvSNlf5jW7yecbje2wWQL/JYqviFwr

-----END PRIVATE KEY-----

Private-Key: (256 bit)

priv:

    60:25:e9:20:9c:84:01:ec:61:92:fa:c2:30:69:45:

    03:8b:10:22:d7:08:a7:ac:26:f3:75:95:a1:e3:85:

    cc:4c

pub:

    04:cc:7c:09:0b:b6:cc:a7:1d:19:91:c9:82:e7:fa:

    e4:69:25:49:ba:6c:e6:49:05:08:4a:37:cd:67:26:

    fd:3a:7c:de:8c:63:49:c4:cd:61:bd:8c:9b:2f:48:

    d9:5f:e6:35:bb:c9:e7:1b:8d:ed:b0:59:02:ff:25:

    8a:af:88:5c:2b

ASN1 OID: secp256k1



4. Import the key into softhsm



[]:~$ softhsm2-util --import ~/tmp/secp256k1-key.pem.pkcs8 --label "ec key" --id 1111 --token "token 2.5.0-rc1"

Found slot 928024111 with matching token label.

=== User PIN (4-255 characters) ===

Please enter user PIN: ****

Please reenter user PIN: ****

The key pair has been imported.



5. Get the pkcs11 url for the private key



[]:~$ p11tool --login --provider=/usr/local/lib/softhsm/libsofthsm2.so --set-pin=1111 --list-all

Object 0:

                URL: pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%11%11;object=ec%20key;type=private

                Type: Private key

                Label: ec key

                Flags: CKA_PRIVATE; CKA_SENSITIVE;

                ID: 11:11



Object 1:

                URL: pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%11%11;object=ec%20key;type=public

                Type: Public key

                Label: ec key

                ID: 11:11



6. Try to access key with openssl engine.



[]:~$ openssl version

OpenSSL 1.1.1  11 Sep 2018



[]:~$ more ~/tmp/openssl.cnf

openssl_conf = openssl_init



[openssl_init]

engines=engine_section



[engine_section]

pkcs11 = pkcs11_section



[pkcs11_section]

engine_id = pkcs11

dynamic_path = /Users/parashah/Downloads/libp11-0.4.9/src/.libs/pkcs11.dylib

MODULE_PATH = /usr/local/lib/softhsm/libsofthsm2.so

init = 0



[]:~$ openssl pkey -in "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%11%11;object=ec%20key;type=private" -inform ENGINE -engine pkcs11 -text

engine "pkcs11" set.

Enter PKCS#11 token PIN for token 2.5.0-rc1:

140736065815424:error:100C0010:elliptic curve routines:i2d_ECPrivateKey:EC lib:crypto/ec/ec_asn1.c:995:

140736065815424:error:100D6010:elliptic curve routines:eckey_priv_encode:EC lib:crypto/ec/ec_ameth.c:242:

140736065815424:error:06071092:digital envelope routines:EVP_PKEY2PKCS8:private key encode error:crypto/evp/evp_pkey.c:72:

140736065815424:error:0907E073:PEM routines:do_pk8pkey:error converting private key:crypto/pem/pem_pk8.c:73:

====



Please let me know if I am missing anything.



--

Paras

[Opensc-devel] OpenSC release 0.19.0

[Frank M. <fra...@gm...>]

Hi all!

I'm happy to announce the new OpenSC release 0.19.0, which be found here
https://github.com/OpenSC/OpenSC/releases/tag/0.19.0 including the full
list of changes.

Most notably, this release contains fixes for mutliple issues, ranging from
stack based buffer overflows to out of bounds reads and writes on the heap.
They can be triggered by malicious smartcards sending malformed responses
to APDU commands. A detailed description can be found at X41-2018-002
<https://www.x41-dsec.de/lab/advisories/x41-2018-002-OpenSC/>. The issues
are tracked as CVE-2018-16391
<http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-16391> CVE
-2018-16392 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-16392>
CVE-2018-16393
<http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-16393> CVE
-2018-16418 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-16418>
CVE-2018-16419
<http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-16419> CVE
-2018-16420 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-16420>
CVE-2018-16421
<http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-16421> CVE
-2018-16422 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-16422>
CVE-2018-16423
<http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-16423> CVE
-2018-16424 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-16424>
CVE-2018-16425
<http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-16425> CVE
-2018-16426 <http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-16426>
CVE-2018-16427
<http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2018-16427>. Thanks to
Eric Sesterhenn from X41 D-Sec GmbH for reporting and helping fixing the
problems.

Regards, Frank

Re: [Opensc-devel] Upcoming release 0.19.0 needs testing

[Peter P. <pop...@gm...>]

Hi

MyEID card (applet version 3.3.3),  OpenSC compiled from sources
https://github.com/OpenSC/OpenSC/archive/0.19.0-rc1.tar.gz

All tests listed on the wiki give a correct result  (report below).

I have tested the initialization and upload of RSA key... and I found
error, steps to reproduce:

pkcs15-init -E
pkcs15-init -C --so-pin 00000000 --so-puk 00000000 --pin 11111111
pkcs15-init --store-pin --id 01 --pin 11111111 --puk 11111111 --so-pin
00000000
pkcs15-init -F
pkcs15-init  --store-private-key keys/rsa2048-key.pem --auth-id=1 --pin
11111111 --so-pin 00000000 --key-usage sign,decrypt --label test
Failed to store private key: Security status not satisfied

This fail is generated by "file create" operation:

Outgoing APDU (30 bytes):
00 E0 00 00 19 62 17 81 02 08 00 82 01 11 83 02 .....b..........
4B 01 86 03 11 11 FF 85 02 00 00 8A 01 00       K.............
0x7feb36626d80 10:30:41.131 [pkcs15-init]
reader-pcsc.c:213:pcsc_internal_transmit: called
0x7feb36626d80 10:30:41.132 [pkcs15-init] reader-pcsc.c:294:pcsc_transmit:
Incoming APDU (2 bytes):
69 82 i.

I searched "verify" operation in log ..  but there is no verify ..
$ OPENSC_DEBUG=255 pkcs15-init  --store-private-key keys/rsa2048-key.pem
--auth-id=1 --pin 11111111 --so-pin 00000000 --key-usage sign,decrypt
--label TEST 2>&1|grep "00 20"


Last working commit in git is f66ceab4bbc3cae529a22b5f3688076cc119bd7c,
commit 83f45cda2af16b65264103fbe0394fd422f0120d no longer works.
(gcc fail to compile ffe38fd87fc06879924759ca2e25eabb47ed6f0d,
360e95d45ac4123255a4c796db96337f332160ad,
8fe377e93b4b56060e5bbfb6f3142ceaeca744fa)



TESTS from WIKI page:
===================
Linux:
openssh without agent - working
openssh with agent - working
firefox login / TLS client auth - working

PKCS11-tool:
Please enter User PIN:
C_SeedRandom() and C_GenerateRandom():
  seeding (C_SeedRandom) not supported
  seems to be OK
Digests:
  all 4 digest functions seem to work
  MD5: OK
  SHA-1: OK
  RIPEMD160: OK
Signatures (currently only for RSA)
  testing key 0 (Certificate)
  all 4 signature functions seem to work
  testing signature mechanisms:
    RSA-X-509: OK
    RSA-PKCS: OK
    SHA1-RSA-PKCS: OK
Verify (currently only for RSA)
  testing key 0 (Certificate)
    RSA-X-509: OK
    RSA-PKCS: OK
    SHA1-RSA-PKCS: OK
Unwrap: not implemented
Decryption (currently only for RSA)
  testing key 0 (Certificate)
    RSA-X-509: OK
    RSA-PKCS: OK
No errors

WINDOWS (10, 64 bit)
cardutil -scinfo  is working, I can install certificate from card into win.
EDGE browser TLS auth fails (no pin dialog, same problem was in 0.18, but
0.17 is working)

Peter

On Tue, Aug 28, 2018 at 1:31 PM Frank Morgner <fra...@gm...>
wrote:

> Hi all!
>
> You'll find a pre-release of OpenSC 0.19.0 on Github
> <https://github.com/OpenSC/OpenSC/releases/tag/0.19.0-rc1>. A draft
> version of the user visible changes is available in this ticket
> <https://github.com/OpenSC/OpenSC/issues/1448>.
>
> Refer to the wiki page
> <https://github.com/OpenSC/OpenSC/wiki/Smart-Card-Release-Testing> on how
> to  systematically test your card. Please extend the page with test results
> from your smart cards.
>
>

[Opensc-devel] Upcoming release 0.19.0 needs testing

[Frank M. <fra...@gm...>]

Hi all!

You'll find a pre-release of OpenSC 0.19.0 on Github
<https://github.com/OpenSC/OpenSC/releases/tag/0.19.0-rc1>. A draft version
of the user visible changes is available in this ticket
<https://github.com/OpenSC/OpenSC/issues/1448>.

Refer to the wiki page
<https://github.com/OpenSC/OpenSC/wiki/Smart-Card-Release-Testing> on how
to  systematically test your card. Please extend the page with test results
from your smart cards.

This release contains fixes for a number of security issues. Due to the
severity of these problems, we try to publish the final release in the
beginning of September.

Regards,
Frank.

[Opensc-devel] unable to build pam_pkcs11

[Amit <ami...@re...>]

Hello,

https://github.com/OpenSC/pam_pkcs11/issues/29

# tar -xvf pam_pkcs11-0.6.9.tar.gz

# cd pam_pkcs11-0.6.9/

# ./configure

# make

  * |make all-recursive make[1]: Entering
    directory|/home/amitkuma2/Desktop/tak_print/pam_pkcs11-0.6.9'
    Making all in .
    make[2]: Entering
    directory |/home/amitkuma2/Desktop/tak_print/pam_pkcs11-0.6.9'
    make[2]: Leaving
    directory|/home/amitkuma2/Desktop/tak_print/pam_pkcs11-0.6.9'
    Making all in po
    make[2]: Entering
    directory |/home/amitkuma2/Desktop/tak_print/pam_pkcs11-0.6.9/po'
    make[2]: Nothing to be done for|all'.
    make[2]: Leaving
    directory |/home/amitkuma2/Desktop/tak_print/pam_pkcs11-0.6.9/po'
    Making all in doc make[2]: Entering
    directory|/home/amitkuma2/Desktop/tak_print/pam_pkcs11-0.6.9/doc'
    xsltproc 
    --stringparam section.autolabel 1 
    --stringparam section.label.includes.component.label 1 
    -o mappers_api.html pam_pkcs11.xsl mappers_api.xml
    warning: failed to load external entity
    "http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl"
    compilation error: file pam_pkcs11.xsl line 3 element import
    xsl:import : unable to
    load http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl
    make[2]: *** [mappers_api.html] Error 5
    make[2]: Leaving
    directory |/home/amitkuma2/Desktop/tak_print/pam_pkcs11-0.6.9/doc'
    make[1]: *** [all-recursive] Error 1 make[1]: Leaving
    directory|/home/amitkuma2/Desktop/tak_print/pam_pkcs11-0.6.9'
    make: *** [all] Error 2`


-- 
Thanks
Amit Kumar
!!If you stumble, get back up. 
What happened yesterday, no longer matters.
Today is another day to move closer to your GOAL!!

Re: [Opensc-devel] Is Le not logged

[Amit <ami...@re...>]

Thanks Perter

This site I am aware of But Yes indeed its partial. :)

Where can we find complete information.. That was my query.


On 08/14/2018 10:41 AM, Peter Popovec wrote:
> Hi,
>
> Partial information  is available at
> http://cardwerk.com/iso-7816-smart-card-standard/  
>
>
> On Mon, Aug 13, 2018 at 4:35 PM Amit <ami...@re...
> <mailto:ami...@re...>> wrote:
>
>     Thanks Douglas,
>
>     https://www.iso.org/standard/70479.html
>
>     This is to be paid version.
>
>     From where you get ISO 7816-4 [1]
>
>

-- 
Thanks
Amit Kumar
!!If you stumble, get back up. 
What happened yesterday, no longer matters.
Today is another day to move closer to your GOAL!!

Re: [Opensc-devel] Is Le not logged

[Peter P. <pop...@gm...>]

Hi,

Partial information  is available at
http://cardwerk.com/iso-7816-smart-card-standard/


On Mon, Aug 13, 2018 at 4:35 PM Amit <ami...@re...> wrote:

> Thanks Douglas,
>
> https://www.iso.org/standard/70479.html
>
> This is to be paid version.
>
> From where you get ISO 7816-4 [1]
>
>

Re: [Opensc-devel] Is Le not logged

[Amit <ami...@re...>]

Thanks Douglas,

https://www.iso.org/standard/70479.html

This is to be paid version.

>From where you get ISO 7816-4 [1]


On 08/13/2018 07:25 PM, Douglas E Engert wrote:
> ISO 7816-4 [1] answers most of your questions in Section "5.3 APDU
> message structure"
> and Section 6 - Basic Interindustry Commands"
>
> Note the class of the command determines if Lc and/or Le are present.
> The command your
> are looking at is "CA" see "6.9 GET DATA command" The protocol T=0 or
> T=1 also comes
> into play.
>
> As you read through 7816 you will not how complicated it is. And even
> worse when it is
> a proprietary command, where CLA byte is 8X or 9X. Thus there is a lot
> of code that
> your card may not be using, but other cards do.
>
> [1] http://cardwerk.com/iso-7816-smart-card-standard/
> or other source.
>
>
> On 8/8/2018 7:38 AM, Amit wrote:
>> Dear Devels,
>>
>> I see this after connecting Atos card 5.3
>> # /usr/local/bin/opensc-tool -a -vvv
>> 0x7fd485e77880 17:20:53.811 [opensc-tool]
>> apdu.c:378:sc_single_transmit: CLA:0, INS:CA, P1:1, P2:8D, data(0) (nil)
>> 0x7fd485e77880 17:20:53.811 [opensc-tool]
>> reader-pcsc.c:284:pcsc_transmit: reader 'Gemalto PC Twin Reader 00 00'
>> 0x7fd485e77880 17:20:53.811 [opensc-tool]
>> reader-pcsc.c:285:pcsc_transmit:
>> Outgoing APDU (5 bytes):
>> 00 CA 01 8D 02 .....
>> 0x7fd485e77880 17:20:53.811 [opensc-tool]
>> reader-pcsc.c:213:pcsc_internal_transmit: called
>> 0x7fd485e77880 17:20:53.815 [opensc-tool]
>> reader-pcsc.c:294:pcsc_transmit:
>> Incoming APDU (4 bytes):
>> 01 80 90 00 ....
>>
>> What is 02 in CAPDU (00 CA 01 8D 02)? Is this Le?
>>    P1=01(1st parameter), P2=8D(2nd parameter)
>>
>> Is RAPDU correct?  (01 80 90 00)
>> a. Asked P2 was 8D, but came=80. Does this mean card does not have
>> data starting from 01 8D?
>> b. Do I need to ask communication specs from manufacturer of card for
>> same.
>>
>> Too early to say but sorry I  feel there is lot of repetitive code we
>> can optimize it.
>>
>>
>> -- 
>> Thanks
>> Amit Kumar
>> !!If you stumble, get back up.
>> What happened yesterday, no longer matters.
>> Today is another day to move closer to your GOAL!!
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>>
>>
>> _______________________________________________
>> Opensc-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>

-- 
Thanks
Amit Kumar
!!If you stumble, get back up. 
What happened yesterday, no longer matters.
Today is another day to move closer to your GOAL!!

Re: [Opensc-devel] Is Le not logged

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

ISO 7816-4 [1] answers most of your questions in Section "5.3 APDU message structure"
and Section 6 - Basic Interindustry Commands"

Note the class of the command determines if Lc and/or Le are present. The command your
are looking at is "CA" see "6.9 GET DATA command" The protocol T=0 or T=1 also comes
into play.

As you read through 7816 you will not how complicated it is. And even worse when it is
a proprietary command, where CLA byte is 8X or 9X. Thus there is a lot of code that
your card may not be using, but other cards do.

[1] http://cardwerk.com/iso-7816-smart-card-standard/
or other source.


On 8/8/2018 7:38 AM, Amit wrote:
> Dear Devels,
> 
> I see this after connecting Atos card 5.3
> # /usr/local/bin/opensc-tool -a -vvv
> 0x7fd485e77880 17:20:53.811 [opensc-tool] apdu.c:378:sc_single_transmit: CLA:0, INS:CA, P1:1, P2:8D, data(0) (nil)
> 0x7fd485e77880 17:20:53.811 [opensc-tool] reader-pcsc.c:284:pcsc_transmit: reader 'Gemalto PC Twin Reader 00 00'
> 0x7fd485e77880 17:20:53.811 [opensc-tool] reader-pcsc.c:285:pcsc_transmit:
> Outgoing APDU (5 bytes):
> 00 CA 01 8D 02 .....
> 0x7fd485e77880 17:20:53.811 [opensc-tool] reader-pcsc.c:213:pcsc_internal_transmit: called
> 0x7fd485e77880 17:20:53.815 [opensc-tool] reader-pcsc.c:294:pcsc_transmit:
> Incoming APDU (4 bytes):
> 01 80 90 00 ....
> 
> What is 02 in CAPDU (00 CA 01 8D 02)? Is this Le?
>    P1=01(1st parameter), P2=8D(2nd parameter)
> 
> Is RAPDU correct?  (01 80 90 00)
> a. Asked P2 was 8D, but came=80. Does this mean card does not have data starting from 01 8D?
> b. Do I need to ask communication specs from manufacturer of card for same.
> 
> Too early to say but sorry I  feel there is lot of repetitive code we can optimize it.
> 
> 
> -- 
> Thanks
> Amit Kumar
> !!If you stumble, get back up.
> What happened yesterday, no longer matters.
> Today is another day to move closer to your GOAL!!
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> 

-- 

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

Re: [Opensc-devel] Is Le not logged

[Jakub J. <jj...@re...>]

On Wed, 2018-08-08 at 18:08 +0530, Amit wrote:
> Dear Devels,
> 
> I see this after connecting Atos card 5.3
> # /usr/local/bin/opensc-tool -a -vvv
> 0x7fd485e77880 17:20:53.811 [opensc-tool]
> apdu.c:378:sc_single_transmit:
> CLA:0, INS:CA, P1:1, P2:8D, data(0) (nil)
> 0x7fd485e77880 17:20:53.811 [opensc-tool]
> reader-pcsc.c:284:pcsc_transmit: reader 'Gemalto PC Twin Reader 00
> 00'
> 0x7fd485e77880 17:20:53.811 [opensc-tool] reader-
> pcsc.c:285:pcsc_transmit:
> Outgoing APDU (5 bytes):
> 00 CA 01 8D 02 .....
> 0x7fd485e77880 17:20:53.811 [opensc-tool]
> reader-pcsc.c:213:pcsc_internal_transmit: called
> 0x7fd485e77880 17:20:53.815 [opensc-tool] reader-
> pcsc.c:294:pcsc_transmit:
> Incoming APDU (4 bytes):
> 01 80 90 00 ....
> 
> What is 02 in CAPDU (00 CA 01 8D 02)? Is this Le?
>   P1=01(1st parameter), P2=8D(2nd parameter)

Yes, the 0x02 byte is Le from the Case 2 Short APDU [1]:

http://cardwerk.com/iso-7816-4-annex-a-smart-card-standard/#AnnexA_2E_1

> Is RAPDU correct?  (01 80 90 00)

Yes, The 0x01 0x80 are the two bytes you got in response to Le=0x02 and
0x90 and 0x00 are Status Words (SW1 and SW1) indicating success.

> a. Asked P2 was 8D, but came=80. Does this mean card does not have
> data
> starting from 01 8D?

The 0xCA instruction is generic ISO GET DATA:


http://cardwerk.com/smart-card-standard-iso7816-4-section-6-basic-interindustry-commands

The provided P1-P2 value 0x01 0x8D falls under Application data
(proprietary coding). The meaning is not defined by the ISO standard,
but by the vendor.

>From the card-cardos.c, this instruction is used to

 207         /* probe DATA FIELD LENGTH with GET DATA */

so the response just means the amount of bytes we can send the card or
receive from the card, nothing more nothing less.


> b. Do I need to ask communication specs from manufacturer of card for
> same.

This might help to figure out what needs to be done for card enrolling.

Regards,
-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat, Inc.

[Opensc-devel] Is Le not logged

[Amit <ami...@re...>]

Dear Devels,

I see this after connecting Atos card 5.3
# /usr/local/bin/opensc-tool -a -vvv
0x7fd485e77880 17:20:53.811 [opensc-tool] apdu.c:378:sc_single_transmit:
CLA:0, INS:CA, P1:1, P2:8D, data(0) (nil)
0x7fd485e77880 17:20:53.811 [opensc-tool]
reader-pcsc.c:284:pcsc_transmit: reader 'Gemalto PC Twin Reader 00 00'
0x7fd485e77880 17:20:53.811 [opensc-tool] reader-pcsc.c:285:pcsc_transmit:
Outgoing APDU (5 bytes):
00 CA 01 8D 02 .....
0x7fd485e77880 17:20:53.811 [opensc-tool]
reader-pcsc.c:213:pcsc_internal_transmit: called
0x7fd485e77880 17:20:53.815 [opensc-tool] reader-pcsc.c:294:pcsc_transmit:
Incoming APDU (4 bytes):
01 80 90 00 ....

What is 02 in CAPDU (00 CA 01 8D 02)? Is this Le?
  P1=01(1st parameter), P2=8D(2nd parameter)

Is RAPDU correct?  (01 80 90 00)
a. Asked P2 was 8D, but came=80. Does this mean card does not have data
starting from 01 8D?
b. Do I need to ask communication specs from manufacturer of card for same.

Too early to say but sorry I  feel there is lot of repetitive code we
can optimize it.


-- 
Thanks
Amit Kumar
!!If you stumble, get back up. 
What happened yesterday, no longer matters.
Today is another day to move closer to your GOAL!!

[Opensc-devel] pkcs11 engine private key loading

[Pavel L. <lob...@gm...>]

I'm writing application which decrypts SMIME messages using smart
card. I used source code of openssl cms command as reference. I'm able
to decrypt already however I face the following problem. When smart
card is removed while my application is running
ENGINE_load_private_key still returns private key reference without
any problem but later call to CMS_decrypt fails. Similarly when smart
card is not present during first call to ENGINE_load_private_key it
will continue to fail even after card is inserted again. I've tried to
call ENGINE_init before key loading and ENGINE_finish and ENGINE_free
after that but it didn't help. Only workaround I've found is exit the
process and start it again.

I would expect ENGINE_load_private_key to unlock the card if it is
present and is not unlocked already and fail if there is no card
inserted.

I'm not sure what is going on here. Maybe I just got the concept
wrong. I'm using debian testing with opensc 0.18.0-3 and openssl
1.1.0h-4.

Re: [Opensc-devel] OpenCT - Aladdin eToken PRO

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

0x8010002e is SCARD_E_NO_READERS_AVAILABLE So it looks like pcscd is running, but it can not find any readers.

Sounds like an install problem on FreeBSD
Google for: pcsc FreeBSD no readers

This shows a number if possible problems inclulding:

https://forums.freebsd.org/threads/card-reader.53496/


pcscd also has some traces. see -d option

It could also be a permission problem, some other application grabbing the reader before pcscd or
as one of teh above says, the installation order: pcsc first, then CCID


On 5/27/2018 12:15 AM, Steve Goldthorp wrote:
> 
> Entering my ATR returns 'Siemens CardOS M 4.01 (SLE66CX320P)'
> 
> All indications that I can see say it should be supported, but I cannot find any information on how to configure ‘things” to make it work…
> 
> 
> I have rebuilt my FreeBSD system to use pcsc and installed ccid drivers (pkg install ccid), when I run opens-tools -l I get no readers found.
> 
> Attached is the log file
> 
> 
> 
> 
> 
> 
> On 27 May 2018, at 12:52 am, Douglas E Engert <dee...@gm...> wrote:
> 
> How to get debugging info:
> 
> https://github.com/OpenSC/OpenSC/wiki/Using-OpenSC
> 
> Have you tried using pcsc in place of openct?
> 
> See if your card is supported:
> https://github.com/OpenSC/OpenSC/wiki/Aladdin-eToken-PRO
> 
> Enter your ATR here for more info:
> https://smartcard-atr.appspot.com
> 
> On 5/26/2018 7:33 AM, Steve Goldthorp wrote:
>> Hello,
>> I seem to be going around in circles trying to find out why my installation of openct and opensc don’t appear to be working.
>> I’m using FreeBSD 11.1
>> Below are the commands I’ve issued to try and see where it fails, but I really don’t know where to look next, any help will be greatly appreciated.
>> --------------------
>> ~ # dmesg | tail
>> ugen0.4: <AKS eToken Pro 4254> at usbus0
>> ~ # /usr/local/etc/rc.d/openct start
>> Starting openct.
>> ~ # openct-tool -v
>> OpenCT 0.6.20
>> ~ # openct-tool list
>> 0 Aladdin eToken PRO
>> ~ # openct-tool atr
>> Detcted Aladdin eToken PRO
>> Card present, status changed
> 
>> ATR: 3b f2 98 00 ff c1 10 31 fe 55 c8 03 15
>> ~ # opensc-tool -i
>> OpenSC 0.16.0 [gcc 4.2.1 Compatible FreeBSD Clang 4.0.0 (tags/RELEASE_400/final 297347)]
>> Enabled features: locking zlib openssl openct
>> ~ # opensc-tool -l
>> # Detected readers (openct)
>> Nr.  Card  Features  Name
>> 0    Yes             Aladdin eToken PRO
>> 1    No              OpenCT reader (detached)
>> ~ # opensc-tool -a
>> Using reader with a card: Aladdin eToken PRO
>> Failed to connect to card: Card command failed
>> ~ # pkcs11-tool -lt
>> error: PKCS11 function C_GetSlotInfo failed: rv = CKR_GENERAL_ERROR (0x5)
>> Aborting.
>> --------------------
>> Thanks and Regards,
>> Steve
>> If you have received this message in error, please reply to this e-mail to notify the sender of its incorrect delivery, and then delete both it and your reply. Thank you.
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Opensc-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> 

-- 

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

Re: [Opensc-devel] OpenCT - Aladdin eToken PRO

[Steve G. <ste...@ie...>]

Entering my ATR returns 'Siemens CardOS M 4.01 (SLE66CX320P)'

All indications that I can see say it should be supported, but I cannot find any information on how to configure ‘things” to make it work…


I have rebuilt my FreeBSD system to use pcsc and installed ccid drivers (pkg install ccid), when I run opens-tools -l I get no readers found.

Attached is the log file

Re: [Opensc-devel] OpenCT - Aladdin eToken PRO

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

How to get debugging info:

https://github.com/OpenSC/OpenSC/wiki/Using-OpenSC

Have you tried using pcsc in place of openct?

See if your card is supported:
https://github.com/OpenSC/OpenSC/wiki/Aladdin-eToken-PRO

Enter your ATR here for more info:
https://smartcard-atr.appspot.com

On 5/26/2018 7:33 AM, Steve Goldthorp wrote:
> Hello,
> 
> I seem to be going around in circles trying to find out why my installation of openct and opensc don’t appear to be working.
> 
> I’m using FreeBSD 11.1
> 
> Below are the commands I’ve issued to try and see where it fails, but I really don’t know where to look next, any help will be greatly appreciated.
> 
> --------------------
> 
> ~ # dmesg | tail
> ugen0.4: <AKS eToken Pro 4254> at usbus0
> 
> ~ # /usr/local/etc/rc.d/openct start
> Starting openct.
> 
> ~ # openct-tool -v
> OpenCT 0.6.20
> 
> ~ # openct-tool list
> 0 Aladdin eToken PRO
> 
> ~ # openct-tool atr
> Detcted Aladdin eToken PRO
> Card present, status changed

> ATR: 3b f2 98 00 ff c1 10 31 fe 55 c8 03 15
> 
> ~ # opensc-tool -i
> OpenSC 0.16.0 [gcc 4.2.1 Compatible FreeBSD Clang 4.0.0 (tags/RELEASE_400/final 297347)]
> Enabled features: locking zlib openssl openct
> 
> ~ # opensc-tool -l
> # Detected readers (openct)
> Nr.  Card  Features  Name
> 0    Yes             Aladdin eToken PRO
> 1    No              OpenCT reader (detached)
> 
> ~ # opensc-tool -a
> Using reader with a card: Aladdin eToken PRO
> Failed to connect to card: Card command failed
> 
> ~ # pkcs11-tool -lt
> error: PKCS11 function C_GetSlotInfo failed: rv = CKR_GENERAL_ERROR (0x5)
> 
> Aborting.
> 
> --------------------
> 
> 
> Thanks and Regards,
> Steve
> 
> If you have received this message in error, please reply to this e-mail to notify the sender of its incorrect delivery, and then delete both it and your reply. Thank you.
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Opensc-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
> 

-- 

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