Help with PKCS#15

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

Help with PKCS#15

Felipe Blauth
I'm struggling to understand how exactly a PKCS#15 smart cards works. So far I've read a lot on RSA Laboratories page and what I could understand there is that the aim of PKCS#15 structure is to create a standard on how objects (keys, certs, etc) are to be accessed and stored. So that any token with the PKCS#15   standard can identify itself to any aplication, regardless of the aplication Criptoki implementation. That is what it is said there, but many doubts rise from there.

By reading some of the PKCS#15 especification and the OpenSC page with explanations about PKCS#15 ( http://www.opensc-project.org/opensc/wiki/CardPersonalization ) I could understand that the standard defines how the filesystem is and where it stores the objects. But what happens with the PKCS#11 implementations? I suppose that it must have some diferences to access the card, using the PKCS#11 functions. I think this is what opensc does, by initializing a PKCS#15 card and using the libopensc-pkcs11.so to acess it. Am I correct?

So, if the cards supported by OpenSC, when initialized by it ( for example using pkcs15-init -C ), have a PKCS#15 structure, why not all functions of the card are available? For example, with OpenSC I can't delete objects of my smart card (a Starcos 2.3) but with the card own implementation of PKCS#11 I'm able to do it. Even when I initialize the card with  OpenSC and then I call my application ( a simple C application that uses the starcos module and call C_deleteObject()) it deletes the object.

In the OpenSC page it is said that :

Reading and writing files, PIN verification, signing and decryption happen in much the same way on all cards. Therefore, the "normal life" commands have been implemented in OpenSC for all supported cards.

However, creating and deleting files, PINs and keys is very card specific and has not yet been implemented for all cards. Currently, pkcs15-init is implemented for: Cryptoflex, Cyberflex, CardOS (etoken), GPK, Miocos, Starcos JCOP and Oberthur. (Check src/pkcs15init/pkcs15-*.c for possible updates). Because of this, and because pkcs15-init is not necessary for "normal life" operations, it has been put in a separate library and in a separate directory.

Does that means that I can USE a card with any module, but I can't alter it's content with any module? This is not verifyed in pratice. If I initialize a card with vendor software I can do nothing with OpenSC and vice-versa.

Im a little confused about all this =p, any help apreciated.

thanks,

Felipe Blauth






_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Help with PKCS#15

Martin Paljak-2
Hello,

This is a frequently asked question [1].
On Jun 22, 2010, at 22:15 , Felipe Blauth wrote:

> I'm struggling to understand how exactly a PKCS#15 smart cards works. So far I've read a lot on RSA Laboratories page and what I could understand there is that the aim of PKCS#15 structure is to create a standard on how objects (keys, certs, etc) are to be accessed and stored. So that any token with the PKCS#15   standard can identify itself to any aplication, regardless of the aplication Criptoki implementation. That is what it is said there, but many doubts rise from there.

Only if the cryptoki (PKCS#11) implementation implements PKCS#15 support.  OpenSC implements a PKCS#11 module that expects PKCS#15 formatted smart cards, but there can be PKCS#11 implementations that talk to remote servers or implement everything in software. It is just a software API. PKCS#15 does not define how the objects (keys, PINs) or PKCS#15 data structures are created on the card.

> By reading some of the PKCS#15 especification and the OpenSC page with explanations about PKCS#15 ( http://www.opensc-project.org/opensc/wiki/CardPersonalization ) I could understand that the standard defines how the filesystem is and where it stores the objects. But what happens with the PKCS#11 implementations? I suppose that it must have some diferences to access the card, using the PKCS#11 functions. I think this is what opensc does, by initializing a PKCS#15 card and using the libopensc-pkcs11.so to acess it. Am I correct?
Yes. See the explanation above.


> So, if the cards supported by OpenSC, when initialized by it ( for example using pkcs15-init -C ), have a PKCS#15 structure, why not all functions of the card are available? For example, with OpenSC I can't delete objects of my smart card (a Starcos 2.3) but with the card own implementation of PKCS#11 I'm able to do it. Even when I initialize the card with  OpenSC and then I call my application ( a simple C application that uses the starcos module and call C_deleteObject()) it deletes the object.

The functionality is limited by the card driver functionality in OpenSC. If the card driver does not implement the required functionality (starcos_ops.delete_file = NULL; which means the card driver author explicitly disallowed the delete functinality (or did not know how to implement it)) you can't use it.

Somebody needs to add the delete functionality to the STARCOS driver first.


> In the OpenSC page it is said that :
> Reading and writing files, PIN verification, signing and decryption happen in much the same way on all cards. Therefore, the "normal life" commands have been implemented in OpenSC for all supported cards.
Changing a PIN code is usually not considered as "creating objects" on the card.


> However, creating and deleting files, PINs and keys is very card specific and has not yet been implemented for all cards. Currently, pkcs15-init is implemented for: Cryptoflex, Cyberflex, CardOS (etoken), GPK, Miocos, Starcos JCOP and Oberthur. (Check src/pkcs15init/pkcs15-*.c for possible updates). Because of this, and because pkcs15-init is not necessary for "normal life" operations, it has been put in a separate library and in a separate directory.
>
> Does that means that I can USE a card with any module, but I can't alter it's content with any module? This is not verifyed in pratice. If I initialize a card with vendor software I can do nothing with OpenSC and vice-versa.

Which means the vendor software does not create PKCS#15 compliant structures or OpenSC is broken/not complete for the vendor support.



> Im a little confused about all this =p, any help apreciated.

[1] http://www.opensc-project.org/opensc/wiki/FrequentlyAskedQuestions

--
Martin Paljak
http://martin.paljak.pri.ee
+3725156495

_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Help with PKCS#15

Andreas Jellinghaus-2
In reply to this post by Felipe Blauth
Hi Felipe,

PKCS#15 is a format / file system standard. if we store a certificate on
the card, the PKCS#15 tells us to create a file (our profile has the details
where exactly we do that - pkcs#15 has some flexibility here), and the
PKCS#15 tells us to put some information about the certificate into
a directory file, so any software seeing the card for the first time
can look up in that directory file and see what is on the card.

in theory we support all operations available via pkcs#11 and do
the right thing(tm) as defined related to pkcs#15 structure.
but in practice not everything is implemented - everyone implemented
so far what they needed, and if you find some feature that you need,
but noone else needed so far, that feature is maybe not implemented
in opensc.

PKCS#15 has some flexibility in it. in theory we could analyze other
implementations of pkcs#15 and pkcs#11 very closely and tune/modify
opensc so it works exactly as that other implementation.

but in practice we aimed for compatiblity for "using the card", not
altering. so if you initialize it with some other software, you can
most likely not modify it with opensc - because so far noone cared
enough to test if it is possible, and tune/modify/improve opensc to
be compatible with cards initialized with other software.

but for pure using a card (login, read files and certs etc. and use
keys and all that), we care about that very much and did enough testing
and fixing and implementing compatibility so opensc is compatible with
cards initialized with other software. and it works the other way
round to, as far as I know.

but of course you would need to test yourself - we tested some of the
very popular software, but didn't follow those software packages closely,
so no idea if the vendor changed something important in the meantime.
and there are of course software packages around that we didn't test.

better than writing and maintaining a list is: test yourself!

and for all I have written: there are some drivers with "gold" status,
i.e. all the features we have work very, very well and we know opensc
to be compatible. but very few drivers are that well tested and written,
so you need to check for each card. best you test the features you
are interested, and give feedback if you need something, and it doesn't
work for you.

> Does that means that I can USE a card with any module, but I can't alter
> it's content with any module? This is not verifyed in pratice. If I
> initialize a card with vendor software I can do nothing with OpenSC and
> vice-versa.

if the vendor initializes in pkcs#15 format, you should be able to use
the card with opensc (if it is supported by opencs).

if the vendor has a proprietory format (e.g. aladdin for their etokens,
gemplus with gemsafe format, ...), then there is no compatbility, unless
someone added an emulation layer to opensc (there is none for aladdin,
but a very simple/limited one for gemsafe format).

Regards, Andreas
_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Help with PKCS#15

Viktor TARASOV-2
Andreas Jellinghaus wrote:
...

>> Does that means that I can USE a card with any module, but I can't alter
>> it's content with any module? This is not verifyed in pratice. If I
>> initialize a card with vendor software I can do nothing with OpenSC and
>> vice-versa.
>>    
>
> if the vendor initializes in pkcs#15 format, you should be able to use
> the card with opensc (if it is supported by opencs).
>
> if the vendor has a proprietory format (e.g. aladdin for their etokens,
> gemplus with gemsafe format, ...), then there is no compatbility, unless
> someone added an emulation layer to opensc (there is none for aladdin,
> but a very simple/limited one for gemsafe format).
>  

Actually for the Oberthur's card with applet 'AuthentIC v2' emulation
supported for the card usage and card initialization. Initialized with
OpenSC this card is compatible with the native Oberthur's middleware and
vice versa.

Actually some producers also use PKCS#15 specification for its cards and
middlewares. For such cards the OpenSC formating is  natively compatible
with the producer's middleware.
For example the IAS/ECC and Oberthur's 'AuthentIC v3' cards. Support in
OpenSC for these cards is currently under development in the 'IAS/ECC &
secure messaging' sub-project.

> Regards, Andreas
>  

Kind wishes,
Viktor.

--
Viktor Tarasov <[hidden email]>

_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Help with PKCS#15

Jean-Michel Pouré - GOOZE
In reply to this post by Felipe Blauth
On Tue, 2010-06-22 at 16:15 -0300, Felipe Blauth wrote:
> Does that means that I can USE a card with any module, but I can't
> alter it's content with any module? This is not verifyed in pratice.
> If I initialize a card with vendor software I can do nothing with
> OpenSC and vice-versa.

With Feitian PKI it is possible. Cards initialized with vendor software
are read-only on OpenSC. And vice-versa. I will try to comment further
on this issue as this is an interesting topic.
--
                  Jean-Michel Pouré - Gooze - http://www.gooze.eu

_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Problems with key size and initialisation

Josef Windorfer
In reply to this post by Andreas Jellinghaus-2
Hi,

I have found out two problems when I work with opensc (resp. pkcs15-init).
I don't know it's a problem on my side or a bug in opensc.

My hardware: Feitian pki card, KOBIL mIDentity and Cherry Smart Terminal
opensc: svn version

Problem 1:
I can't generate rsa key pairs with 2048 bit size.
I think the generation of the key successfully finished, but the
transmission failed:

 >Outgoing APDU data [    7 bytes] =====================================
 >00 46 00 00 02 08 00 .F.....
 >======================================================================
 >0xb77b86c0 23:22:37.369 [pkcs15-init] apdu.c:521:sc_transmit_apdu: called
 >0xb77b86c0 23:22:37.369 [pkcs15-init] card.c:290:sc_lock: called
 >0xb77b86c0 23:22:37.369 [pkcs15-init] reader-pcsc.c:232:pcsc_transmit:
reader 'KOBIL mIDentity (NK090000998) 00 00'
 >0xb77b86c0 23:22:37.369 [pkcs15-init] apdu.c:187:sc_apdu_log:
 >Outgoing APDU data [    7 bytes] =====================================
 >00 46 00 00 02 08 00 .F.....
 >======================================================================
 >0xb77b86c0 23:22:37.369 [pkcs15-init]
reader-pcsc.c:165:pcsc_internal_transmit: called
 >0xb77b86c0 23:23:45.432 [pkcs15-init] apdu.c:187:sc_apdu_log:
 >Incoming APDU data [    2 bytes] =====================================
 >90 00 ..
 >======================================================================
 >0xb77b86c0 23:23:45.432 [pkcs15-init] card.c:324:sc_unlock: called
 >0xb77b86c0 23:23:45.432 [pkcs15-init]
card-entersafe.c:372:entersafe_transmit_apdu: returning with: 0
 >0xb77b86c0 23:23:45.432 [pkcs15-init]
card-entersafe.c:328:entersafe_transmit_apdu: called
 >0xb77b86c0 23:23:45.432 [pkcs15-init] apdu.c:187:sc_apdu_log:
 >Outgoing APDU data [    5 bytes] =====================================
 >80 E6 2A 01 00 ..*..
 >======================================================================
 >0xb77b86c0 23:23:45.432 [pkcs15-init] apdu.c:521:sc_transmit_apdu: called
 >0xb77b86c0 23:23:45.432 [pkcs15-init] card.c:290:sc_lock: called
 >0xb77b86c0 23:23:45.432 [pkcs15-init] reader-pcsc.c:232:pcsc_transmit:
reader 'KOBIL mIDentity (NK090000998) 00 00'
 >0xb77b86c0 23:23:45.432 [pkcs15-init] apdu.c:187:sc_apdu_log:
 >Outgoing APDU data [    5 bytes] =====================================
 >80 E6 2A 01 00 ..*..
 >======================================================================
 >0xb77b86c0 23:23:45.432 [pkcs15-init]
reader-pcsc.c:165:pcsc_internal_transmit: called
 >0xb77b86c0 23:23:45.485 [pkcs15-init]
reader-pcsc.c:191:pcsc_internal_transmit: KOBIL mIDentity (NK090000998)
00 00:SCardTransmit/Control failed: 0x80100016
 >0xb77b86c0 23:23:45.485 [pkcs15-init]
reader-pcsc.c:343:pcsc_detect_card_presence: called
 >0xb77b86c0 23:23:45.485 [pkcs15-init]
reader-pcsc.c:265:refresh_attributes: KOBIL mIDentity (NK090000998) 00
00 status check
 >0xb77b86c0 23:23:45.485 [pkcs15-init]
reader-pcsc.c:284:refresh_attributes: event: 0x0120
 >0xb77b86c0 23:23:45.486 [pkcs15-init]
reader-pcsc.c:285:refresh_attributes: state: 0x0020
 >0xb77b86c0 23:23:45.486 [pkcs15-init]
reader-pcsc.c:295:refresh_attributes: card present
 >0xb77b86c0 23:23:45.486 [pkcs15-init]
reader-pcsc.c:348:pcsc_detect_card_presence: returning with: 1
 >0xb77b86c0 23:23:45.486 [pkcs15-init]
reader-pcsc.c:343:pcsc_detect_card_presence: called
 >0xb77b86c0 23:23:45.486 [pkcs15-init]
reader-pcsc.c:265:refresh_attributes: KOBIL mIDentity (NK090000998) 00
00 status check
 >0xb77b86c0 23:23:45.486 [pkcs15-init]
reader-pcsc.c:284:refresh_attributes: event: 0x0120
 >0xb77b86c0 23:23:45.486 [pkcs15-init]
reader-pcsc.c:285:refresh_attributes: state: 0x0120
 >0xb77b86c0 23:23:45.486 [pkcs15-init]
reader-pcsc.c:295:refresh_attributes: card present
 >0xb77b86c0 23:23:45.486 [pkcs15-init]
reader-pcsc.c:348:pcsc_detect_card_presence: returning with: 1
 >0xb77b86c0 23:23:45.486 [pkcs15-init] reader-pcsc.c:239:pcsc_transmit:
unable to transmit
 >0xb77b86c0 23:23:45.487 [pkcs15-init] apdu.c:399:do_single_transmit:
unable to transmit APDU
 >0xb77b86c0 23:23:45.487 [pkcs15-init] card.c:324:sc_unlock: called
 >0xb77b86c0 23:23:45.487 [pkcs15-init]
card-entersafe.c:372:entersafe_transmit_apdu: returning with: -1107
 >0xb77b86c0 23:23:45.487 [pkcs15-init]
card-entersafe.c:1319:entersafe_gen_key: APDU transmit failed: Transmit
failed
 >0xb77b86c0 23:23:45.487 [pkcs15-init] card.c:688:sc_card_ctl:
returning with: -1107
 >0xb77b86c0 23:23:45.487 [pkcs15-init]
pkcs15-entersafe.c:399:entersafe_generate_key: EnterSafe generate RSA
key pair failed: Transmit failed
 >0xb77b86c0 23:23:45.487 [pkcs15-init]
pkcs15-lib.c:1197:sc_pkcs15init_generate_key: Failed to generate key:
Transmit failed
 >Failed to generate key: Transmit failed

Problem 2:
For the initialisation of the smart card are profiles available. By
default exists a Security Officer (SO) and a User. By onepin exists only
a user with SO rights.
If I initialise the smart card with the command below, the so-pin will
be the user pin. There don't exist a user pin.
Is there a mistake on my side?

 >pkcs15-init --create-pkcs15 --profile pkcs15
--use-default-transport-key --pin <PIN> --puk <PUK> --so-pin <SO_PIN>
--so-puk <SO_PUK>


Thank you for your help!

Kind Regards
Josef
_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Problems with key size and initialisation

Jean-Michel Pouré - GOOZE
On Fri, 2010-06-25 at 23:51 +0200, Josef Windorfer wrote:
> I can't generate rsa key pairs with 2048 bit size.
> I think the generation of the key successfully finished, but the
> transmission failed:

This is bug: http://www.opensc-project.org/opensc/ticket/241
I realize that this bug exists on all platforms, not only on Mac OS X.
--
                  Jean-Michel Pouré - Gooze - http://www.gooze.eu

_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Problems with key size and initialisation

Jean-Michel Pouré - GOOZE
In reply to this post by Josef Windorfer
On Fri, 2010-06-25 at 23:51 +0200, Josef Windorfer wrote:
> If I initialise the smart card with the command below, the so-pin
> will
> be the user pin. There don't exist a user pin.
> Is there a mistake on my side?
>
>  >pkcs15-init --create-pkcs15 --profile pkcs15
> --use-default-transport-key --pin <PIN> --puk <PUK> --so-pin <SO_PIN>
> --so-puk <SO_PUK>

I think there is no so-pin for Feitian PKI, i.e. PIN and SOPIN are the
same.

$ pkcs15-init --create-pkcs15 --profile pkcs15+onepin
--use-default-transport-key --pin 0000 --puk 111111 --label "François
Pérou"

will initialize a PIN and PUK.
--
                  Jean-Michel Pouré - Gooze - http://www.gooze.eu

_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Problems with key size and initialisation

Josef Windorfer
In reply to this post by Jean-Michel Pouré - GOOZE


Am 26.06.2010 11:16, schrieb Jean-Michel Pouré - GOOZE:
> On Fri, 2010-06-25 at 23:51 +0200, Josef Windorfer wrote:
>> I can't generate rsa key pairs with 2048 bit size.
>> I think the generation of the key successfully finished, but the
>> transmission failed:
>
> This is bug: http://www.opensc-project.org/opensc/ticket/241
> I realize that this bug exists on all platforms, not only on Mac OS X.

Yes, the bug is not limited on Mac OS X.
I'm using ubuntu 10.04 with kernel version 2.6.32.

Thank you.
_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Problems with key size and initialisation

Martin Paljak-2
In reply to this post by Jean-Michel Pouré - GOOZE
Hello,
On Jun 26, 2010, at 12:16 , Jean-Michel Pouré - GOOZE wrote:

> On Fri, 2010-06-25 at 23:51 +0200, Josef Windorfer wrote:
>> I can't generate rsa key pairs with 2048 bit size.
>> I think the generation of the key successfully finished, but the
>> transmission failed:
>
> This is bug: http://www.opensc-project.org/opensc/ticket/241
> I realize that this bug exists on all platforms, not only on Mac OS X.

Not exactly.

This thread: 0x80100016 SCARD_E_NOT_TRANSACTED
Ticket #241: 0x80100017 SCARD_E_READER_UNAVAILABLE

Both need debugging on pcsc-lite/CCID level [1]

[1] http://pcsclite.alioth.debian.org/ccid.html#support
--
Martin Paljak
@martinpaljak.net
+3725156495

_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Problems with key size and initialisation

Martin Paljak-2
In reply to this post by Josef Windorfer
Hello,

On Jun 26, 2010, at 00:51 , Josef Windorfer wrote:

> I have found out two problems when I work with opensc (resp. pkcs15-init).
> I don't know it's a problem on my side or a bug in opensc.
>
> My hardware: Feitian pki card, KOBIL mIDentity and Cherry Smart Terminal
> opensc: svn version
>
> Problem 1:
> I can't generate rsa key pairs with 2048 bit size.
> I think the generation of the key successfully finished, but the
> transmission failed:
> reader-pcsc.c:191:pcsc_internal_transmit: KOBIL mIDentity (NK090000998)
> 00 00:SCardTransmit/Control failed: 0x80100016

Does the problem happen with both readers? Do you have some other readers to test as well?

The problem apparently comes from the reader driver (or firmware, in that matter).



> Problem 2:
> For the initialisation of the smart card are profiles available. By
> default exists a Security Officer (SO) and a User. By onepin exists only
> a user with SO rights.
> If I initialise the smart card with the command below, the so-pin will
> be the user pin. There don't exist a user pin.
> Is there a mistake on my side?
>
>> pkcs15-init --create-pkcs15 --profile pkcs15
> --use-default-transport-key --pin <PIN> --puk <PUK> --so-pin <SO_PIN>
> --so-puk <SO_PUK>

Feitian card only supports a single PIN code, thus the pkcs15+onepin profile must be used.

Because normal "home users" don't have a split personality that requires multiple personas to manage a card, IMHO the default profile could be switched to be the onepin profile. More advanced users who know they need a security officer abstraction can then enable alternative profiles as needed

Also, there's quite a lot of software that assumes "one token, one PIN" approach.

--
Martin Paljak
@martinpaljak.net
+3725156495

_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Problems with key size and initialisation

Martin Paljak-2
In reply to this post by Josef Windorfer

On Jun 26, 2010, at 00:51 , Josef Windorfer wrote:

> Hi,
>
> I have found out two problems when I work with opensc (resp. pkcs15-init).
> I don't know it's a problem on my side or a bug in opensc.
>
> My hardware: Feitian pki card, KOBIL mIDentity and Cherry Smart Terminal
Have a look here:

http://pcsclite.alioth.debian.org/unsupported.html#0x0D460x4000

--
Martin Paljak
@martinpaljak.net
+3725156495

_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Problems with key size and initialisation

Josef Windorfer
In reply to this post by Martin Paljak-2

>>> I can't generate rsa key pairs with 2048 bit size.
>>> I think the generation of the key successfully finished, but the
>>> transmission failed:
>>
>> This is bug: http://www.opensc-project.org/opensc/ticket/241
>> I realize that this bug exists on all platforms, not only on Mac OS X.
>
> Not exactly.
>
> This thread: 0x80100016 SCARD_E_NOT_TRANSACTED
> Ticket #241: 0x80100017 SCARD_E_READER_UNAVAILABLE
>
> Both need debugging on pcsc-lite/CCID level [1]
>
> [1] http://pcsclite.alioth.debian.org/ccid.html#support

I debugged on pcsc-lite/ccid level, as described in [1]:

The version of
libccid: 1.3.11-1
os: ubuntu 10.04, kernel 2.6.32-22-generic
pcsc-tools: 1.4.16-1

reader: KOBIL mIDentity (NK090000998) (ID: 0d46:3014 Kobil Systems GmbH)
and Cherry ST-1044U (NOTE: The logs created with Kobil Reader, the error
comes with the cherry reader too. I can check not before monday if it's
the same reason of the error)

/usr/sbin/pcscd --version:
 >pcsc-lite version 1.5.3.
 >Copyright (C) 1999-2002 by David Corcoran <[hidden email]>.
 >Copyright (C) 2001-2008 by Ludovic Rousseau <[hidden email]>.
 >Copyright (C) 2003-2004 by Damien Sauveron <[hidden email]>.
 >Report bugs to <[hidden email]>.
 >Enabled features: Linux libusb usbdropdir=/usr/lib/pcsc/drivers
 >confdir=/etc ipcdir=/var/run/pcscd

The log (cutout) of the command 'pkcs15-init -G rsa/2048 -a ff' from
starting key generation:

 >00000019 APDU: 00 46 00 00 02 08 00
 >00000017 ifdhandler.c:1170:IFDHTransmitToICC()
usb:0d46/3014:libusb:008:002 (lun: 0)
 >29245136 SW: 90 00
 >00000901 winscard_msg_srv.c:317:SHMProcessEventsContext() command
TRANSMIT_EXTENDED received by client 6
 >00000049 winscard.c:1647:SCardTransmit() Send Protocol: T=1
 >00000019 APDU: 80 E6 2A 01 00
 >00002154 ifdhandler.c:1170:IFDHTransmitToICC()
usb:0d46/3014:libusb:008:002 (lun: 0)
 >00050839 commands.c:1338:CCID_Receive() Can't read all data (262 out
of 268 expected)
 >00000030 SW:
 >00000010 ifdwrapper.c:722:IFDTransmit() Card not transacted: 612
 >00000009 winscard.c:1671:SCardTransmit() Card not transacted: 0x80100016
 >00000458 winscard_msg_srv.c:317:SHMProcessEventsContext() command
STATUS received by client 6
 >00000641 winscard_msg_srv.c:317:SHMProcessEventsContext() command
STATUS received by client 6
 >00000912 winscard_msg_srv.c:317:SHMProcessEventsContext() command
END_TRANSACTION received by client 6
 >00000026 winscard.c:1208:SCardEndTransaction() Status: 0x00000000
 >00004296 winscard_msg_srv.c:317:SHMProcessEventsContext() command
DISCONNECT received by client 6
 >00000040 winscard.c:880:SCardDisconnect() Active Contexts: 1
 >00001599 ifdhandler.c:1043:IFDHPowerICC() action: Reset,
usb:0d46/3014:libusb:008:002 (lun: 0)
 >00038991 winscard.c:941:SCardDisconnect() Reset complete.
 >00000699 winscard_msg_srv.c:317:SHMProcessEventsContext() command
RELEASE_CONTEXT received by client 6
 >00000025 winscard.c:253:SCardReleaseContext() Releasing Context: 17015259
 >00000792 winscard_msg_srv.c:306:SHMProcessEventsContext() Client has
disappeared: 6
 >00000017 winscard_svc.c:146:ContextThread() Client die: 6
_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Problems with key size and initialisation

Josef Windorfer
In reply to this post by Martin Paljak-2
>> I have found out two problems when I work with opensc (resp. pkcs15-init).
>> I don't know it's a problem on my side or a bug in opensc.
>>
>> My hardware: Feitian pki card, KOBIL mIDentity and Cherry Smart Terminal
>> opensc: svn version
>>
>> Problem 1:
>> I can't generate rsa key pairs with 2048 bit size.
>> I think the generation of the key successfully finished, but the
>> transmission failed:
>> reader-pcsc.c:191:pcsc_internal_transmit: KOBIL mIDentity (NK090000998)
>> 00 00:SCardTransmit/Control failed: 0x80100016
>
> Does the problem happen with both readers? Do you have some other readers to test as well?
>
> The problem apparently comes from the reader driver (or firmware, in that matter).

The problem happen with both reader.
I have only the KOBIL mIDentity and the Cherry ST-1044U.
As I write in the email before, I can check the reason of the error for
the cherry reader not for monday.
_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Problems with key size and initialisation

Josef Windorfer
In reply to this post by Martin Paljak-2

>> Hi,
>>
>> I have found out two problems when I work with opensc (resp. pkcs15-init).
>> I don't know it's a problem on my side or a bug in opensc.
>>
>> My hardware: Feitian pki card, KOBIL mIDentity and Cherry Smart Terminal
> Have a look here:
>
> http://pcsclite.alioth.debian.org/unsupported.html#0x0D460x4000
>

The reader with the USB ID 0d46:3014 is listed on the "should work" list:
http://pcsclite.alioth.debian.org/shouldwork.html#0x0D460x3014
_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Problems with key size and initialisation

Jean-Michel Pouré - GOOZE
On Sat, 2010-06-26 at 13:26 +0200, Josef Windorfer wrote:
>
> The reader with the USB ID 0d46:3014 is listed on the "should work"
> list:
> http://pcsclite.alioth.debian.org/shouldwork.html#0x0D460x3014 

As for me, I used was an Omnikey Cardman 3121 usb on Mac OS X.
Communication error.

Also I tested using an Omnikey Cardman 3121 usb and a Feitin PKI token
on GNU/Linux + OpenSC svn + libccid 1.3.13. It Works.

Strange.

--
                  Jean-Michel Pouré - Gooze - http://www.gooze.eu

_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Problems with key size and initialisation

Ludovic Rousseau
In reply to this post by Josef Windorfer
2010/6/26 Josef Windorfer <[hidden email]>:

>
>>>> I can't generate rsa key pairs with 2048 bit size.
>>>> I think the generation of the key successfully finished, but the
>>>> transmission failed:
>>>
>>> This is bug: http://www.opensc-project.org/opensc/ticket/241
>>> I realize that this bug exists on all platforms, not only on Mac OS X.
>>
>> Not exactly.
>>
>> This thread: 0x80100016 SCARD_E_NOT_TRANSACTED
>> Ticket #241: 0x80100017 SCARD_E_READER_UNAVAILABLE
>>
>> Both need debugging on pcsc-lite/CCID level [1]
>>
>> [1] http://pcsclite.alioth.debian.org/ccid.html#support
>
> I debugged on pcsc-lite/ccid level, as described in [1]:
>
> The version of
> libccid: 1.3.11-1
> os: ubuntu 10.04, kernel 2.6.32-22-generic
> pcsc-tools: 1.4.16-1
>
> reader: KOBIL mIDentity (NK090000998) (ID: 0d46:3014 Kobil Systems GmbH)
> and Cherry ST-1044U (NOTE: The logs created with Kobil Reader, the error
> comes with the cherry reader too. I can check not before monday if it's
> the same reason of the error)

Please send me the output.txt as described in [1] for the Kobil reader.

> /usr/sbin/pcscd --version:
>  >pcsc-lite version 1.5.3.
>  >Copyright (C) 1999-2002 by David Corcoran <[hidden email]>.
>  >Copyright (C) 2001-2008 by Ludovic Rousseau <[hidden email]>.
>  >Copyright (C) 2003-2004 by Damien Sauveron <[hidden email]>.
>  >Report bugs to <[hidden email]>.
>  >Enabled features: Linux libusb usbdropdir=/usr/lib/pcsc/drivers
>  >confdir=/etc ipcdir=/var/run/pcscd
>
> The log (cutout) of the command 'pkcs15-init -G rsa/2048 -a ff' from
> starting key generation:
>
>  >00000019 APDU: 00 46 00 00 02 08 00
>  >00000017 ifdhandler.c:1170:IFDHTransmitToICC()
> usb:0d46/3014:libusb:008:002 (lun: 0)
>  >29245136 SW: 90 00
>  >00000901 winscard_msg_srv.c:317:SHMProcessEventsContext() command
> TRANSMIT_EXTENDED received by client 6
>  >00000049 winscard.c:1647:SCardTransmit() Send Protocol: T=1
>  >00000019 APDU: 80 E6 2A 01 00
>  >00002154 ifdhandler.c:1170:IFDHTransmitToICC()
> usb:0d46/3014:libusb:008:002 (lun: 0)
>  >00050839 commands.c:1338:CCID_Receive() Can't read all data (262 out
> of 268 expected)

I would need more logs as explained in [2].
The CCID driver complains that not enough bytes arrived.

Bye

[1] http://pcsclite.alioth.debian.org/ccid.html#CCID_compliant
[2] http://pcsclite.alioth.debian.org/ccid.html#support

--
 Dr. Ludovic Rousseau
_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Help with PKCS#15

Felipe Blauth
In reply to this post by Jean-Michel Pouré - GOOZE
Thank you, with your information the specification of PKCS#15 in RSA Laboratories page has became more clear.

 My question now is: is it possible to create a PKCS#15 structure only coding against PKCS#11 (with opensc module)? I've worked a little with PKCS#11 interface and opensc-pkcs11.so module and, I want to know if opensc-pkcs11.so creates the PKCS#15 structure on the fly.  I mean,  if you list the slots of a blank card using OpenSC module, it will list 15 virtual slots. From this start point I can initialize a RW session with the slot and initialize the token, store certificates, keys and so on. If I only work this way, will this card be PKCS#15 compatible (in other words, will it create the same structure created when pkcs15-init --initialize-card command is fired)? By now I can't test myself, but soon I will be able to do it and post my results.


Another thing I wanted to know is, and I'm sure this has been discussed here already, but I can't find it, is that the whole comunication from the pc to the card. Some questions like what is PC/SC (pcsc-lite) is it an interface to talk to the reader?  Does PKCS#11 implementations talk to it? And who implements that API ?

Regards,

Felipe Blauth,

_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Help with PKCS#15

Martin Paljak-2
Hello,
(this should be discussed on opensc-devel apparently), but IMO the separation between opensc-user and opensc-devel is not a good idea..)

On Jun 26, 2010, at 23:34 , Felipe Blauth wrote:
>  My question now is: is it possible to create a PKCS#15 structure only coding against PKCS#11 (with opensc module)? I've worked a little with PKCS#11 interface and opensc-pkcs11.so module and, I want to know if opensc-pkcs11.so creates the PKCS#15 structure on the fly.  I mean,  if you list the slots of a blank card using OpenSC module, it will list 15 virtual slots. From this start point I can initialize a RW session with the slot and initialize the token, store certificates, keys and so on. If I only work this way, will this card be PKCS#15 compatible (in other words, will it create the same structure created when pkcs15-init --initialize-card command is fired)? By now I can't test myself, but soon I will be able to do it and post my results.
Even though PKCS#11 specifies functions for initializing tokens, the "unofficial statement" from people close to the PKCS#11 workgroup have claimed to "clean hands from token personalization". Which means PKCS#15 allows for quite complex schemes and it is not possible to map all of them into (simpler) PKCS#11 calls.

So you can have some success, but probably you won't get far. pkcs15-init + using opensc-pkcs11.so is the way to go. But if it works, the structures created via opensc-pkcs11.so will indeed be PKCS#15 compatible.



> Another thing I wanted to know is, and I'm sure this has been discussed here already, but I can't find it, is that the whole comunication from the pc to the card. Some questions like what is PC/SC (pcsc-lite) is it an interface to talk to the reader?  Does PKCS#11 implementations talk to it? And who implements that API ?

Browse around in OpenSC wiki, you should find overview descriptions as well as pictures [1].

If you have questions or improvements for the FAQ [2] please give your comments.

PC/SC is used to talk to readers, and readers talk to cads. OpenSC implements the API (means, it implements support for *using* this API) which also means OpenSC PKCS#11 uses it.
[1] http://www.opensc-project.org/opensc/attachment/wiki/OverView/OpenSC.png
[2] http://www.opensc-project.org/opensc/wiki/FrequentlyAskedQuestions
--
Martin Paljak
@martinpaljak.net
+3725156495

_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
Reply | Threaded
Open this post in threaded view
|

Re: Problems with key size and initialisation

Ludovic Rousseau
In reply to this post by Ludovic Rousseau
2010/6/26 Josef Windorfer <[hidden email]>:

>
>
> Am 26.06.2010 18:27, schrieb Ludovic Rousseau:
>>
>> 2010/6/26 Josef Windorfer<[hidden email]>:
>>>
>>>>>> I can't generate rsa key pairs with 2048 bit size.
>>>>>> I think the generation of the key successfully finished, but the
>>>>>> transmission failed:
>>>>>
>>>>> This is bug: http://www.opensc-project.org/opensc/ticket/241
>>>>> I realize that this bug exists on all platforms, not only on Mac OS X.
>>>>
>>>> Not exactly.
>>>>
>>>> This thread: 0x80100016 SCARD_E_NOT_TRANSACTED
>>>> Ticket #241: 0x80100017 SCARD_E_READER_UNAVAILABLE
>>>>
>>>> Both need debugging on pcsc-lite/CCID level [1]
>>>>
>>>> [1] http://pcsclite.alioth.debian.org/ccid.html#support
>>>
>>> I debugged on pcsc-lite/ccid level, as described in [1]:
>>>
>>> The version of
>>> libccid: 1.3.11-1
>>> os: ubuntu 10.04, kernel 2.6.32-22-generic
>>> pcsc-tools: 1.4.16-1
>>>
>>> reader: KOBIL mIDentity (NK090000998) (ID: 0d46:3014 Kobil Systems GmbH)
>>> and Cherry ST-1044U (NOTE: The logs created with Kobil Reader, the error
>>> comes with the cherry reader too. I can check not before monday if it's
>>> the same reason of the error)
>>
>> Please send me the output.txt as described in [1] for the Kobil reader.
>
> The file output.txt ist the log-file described in [1]

OK. It is the same reader I have in my database.

> The file pcsc is the log-file described in [2]

I still do not have enough logs. You are still using:
00000864 ifdhandler.c:1545:init_driver() LogLevel: 0x0003

Since you can't follow instructions of the web page correctly you will
edit the file /usr/lib/pcsc/drivers/ifd-ccid.bundle/Contents/Info.plist
and change the ifdLogLevel from 3 to 7.

> I don't know why the pcsc-lite version 1.5.3 is used, i have uninstalled it.
> Actually I have installed pcsc-lite 1.6.1, but I still work on it.

I guess you have one in /usb/sbin and the other in /usr/local/sbin

Bye

[1] http://pcsclite.alioth.debian.org/ccid.html#CCID_compliant
[2] http://pcsclite.alioth.debian.org/ccid.html#support

--
 Dr. Ludovic Rousseau
_______________________________________________
opensc-user mailing list
[hidden email]
http://www.opensc-project.org/mailman/listinfo/opensc-user
12