Re: [opensc-devel] Initial ECDSA modifications to OpenSC for use with PIV cards in OpenSC #295
Hello,
Douglas E. Engert wrote:
Great for now. But in SVN pkcs15-sec.c:188,189:
187 switch (obj-type) {
188 /* FIXME -DEE GOSTR is misusing the sc_card_find_rsa_alg */
189 case SC_PKCS15_TYPE_PRKEY_GOSTR3410:
190 case SC_PKCS15_TYPE_PRKEY_RSA:
191 modlen = prkey-modulus_length / 8;
192 alg_info = sc_card_find_rsa_alg(p15card-card, prkey
This should be fixed sometime, as the GOSTR code is depending on
the RSA alg_info. But GOSTR should have sc_card_find_gostr_alg
and _sc_card_add_gostr_alg routines. In card-rtecp.c there are calls
to _sc_card_add_rsa_alg for 256, 512, 768, (look way to weak for RSA)
It look like they were added because pkcs15-sec.c:192 is only looking
at RSA. So in pkcs15-sec.c above, it is looking at the alg_info created
by the call at card-rtecp.c:73 _sc_card_add_rsa_alg(card, 256, flags, 0);
Agree. Fixed at 4931. Thanks!
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [opensc-commits] svn opensc changed[4930] add to r4904: fix calculating of signature size for CKK_GOSTR3410
Hello, 2010/12/9 Martin Paljak mar...@paljak.pri.ee: Hello, On Dec 9, 2010, at 9:23 AM, webmas...@opensc-project.org wrote: Revision: 4930 Author: s Date: 2010-12-09 07:23:10 + (Thu, 09 Dec 2010) Log Message: --- add to r4904: fix calculating of signature size for CKK_GOSTR3410 - *pLength *= 2; + *pLength = (*pLength + 7) / 8 * 2; Could you also add a comment? Why not (*pLength + 7) / 4? Yes of course. We need to convert a length in bits to bytes and multiply by two. So if we divide by 4 then we have incorrect rounding result (case (*pLength + 7) % 8 = 4). ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Initial ECDSA modifications to OpenSC for use with PIV cards in OpenSC #295
Hello,
2010/11/30 Douglas E. Engert deeng...@anl.gov:
On 11/29/2010 4:36 AM, Aleksey Samsonov wrote:
After fix it, I have fail in my tests with GOSTR (PKCS#11 C_Sign).
Unfortunately, I don't have logs now.
One thing to look at:
In pkcs15-sec.c in sc_pkcs15_compute_signature in the old code there
is no mention of GOSTR3410, so I assumed it was RSA only. The old code
had:
- alg_info = sc_card_find_rsa_alg(p15card-card, prkey-modulus_length);
- if (alg_info == NULL) {
- sc_debug(ctx, SC_LOG_DEBUG_NORMAL, Card does not support RSA with
key length %d\n, prkey-modulus_length);
- return SC_ERROR_NOT_SUPPORTED;
- senv.algorithm = SC_ALGORITHM_RSA;
If you card could support both RSA and GOSTR3410 (and card-rtecp.c
supports both with keylength = 256) it might have passed the old test,
and ignored the fact that senv.algorithm = SC_ALGORITHM_RSA.
The new code does a switch(obj-type) and I only added RSA and EC.
So adding something like:
+ case SC_PKCS15_TYPE_PRKEY_GOSTR3410:
+ modlen = prkey-modulus_length / 8;
+ alg_info = sc_card_find_gostr3410_alg(p15card-card,
prkey-modulus_length);
(A sc_card_find_gostr3410_alg routine is needed for this to work.)
+
+ if (alg_info == NULL) {
+ sc_debug(ctx, SC_LOG_DEBUG_NORMAL, Card does not support
GOSTR3410 key length %d\n, prkey-modulus_length);
+ return SC_ERROR_NOT_SUPPORTED;
+ }
+ senv.flags |= SC_SEC_ENV_ALG_PRESENT;
+ senv.algorithm = SC_ALGORITHM_RGOST3410;
+ break;
I need a few days for detail review.
Sorry for the delay with answer. Thanks for the detail.
My tests are work with simple diff (I'm going to commit late in the evening):
diff --git a/src/pkcs11/mechanism.c b/src/pkcs11/mechanism.c
--- a/src/pkcs11/mechanism.c2010-12-08 15:24:09.040752899 +0300
+++ b/src/pkcs11/mechanism.c2010-12-08 15:27:17.294754645 +0300
@@ -460,7 +460,7 @@
case CKK_GOSTR3410:
rv =
key-ops-get_attribute(operation-session, key, attr);
if (rv == CKR_OK)
- *pLength *= 2;
+ *pLength = (*pLength + 7) / 8 * 2;
break;
default:
rv = CKR_MECHANISM_INVALID;
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] r4904 and OpenSSL-1.0.0b in Fedora 14
Hello, One remark. We need use 'include openssl/opensslconf.h' for use OPENSSL_NO_EC. Сomplete example (or see src/pkcs11/openssl.c): #include openssl/opensslv.h /* for OPENSSL_VERSION_NUMBER */ #if OPENSSL_VERSION_NUMBER = 0x1000L #include openssl/conf.h #include openssl/opensslconf.h /* for OPENSSL_NO_* */ #ifndef OPENSSL_NO_EC #include openssl/ec.h #endif /* OPENSSL_NO_EC */ 2010/12/3 jons...@terra.es jons...@terra.es: OPENSSL_VERSION_NUMBER = 0x1000L !defined(OPENSSL_NO_EC) is the key, Douglas hopefully plans that into the next patch unless you do it before (I don't have a Fedora VM available at the moment) OK :-) attached patch works for me Juan Antonio ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Initial ECDSA modifications to OpenSC for use with PIV cards in OpenSC #295
Hello Douglas, 2010/11/23 Douglas E. Engert deeng...@anl.gov: I would especially like the GOSTR maintainers to look at this closely, as many of the flag tests and if statements where modified to support EC and hopefully make it easier to add algorithms in the future. There have compile error at libopensc/pkcs15-piv.c (see struct pubdata_st and static const pubdata pubkeys[PIV_NUM_CERTS_AND_KEYS] =) After fix it, I have fail in my tests with GOSTR (PKCS#11 C_Sign). Unfortunately, I don't have logs now. I need a few days for detail review. Thanks! ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Personal Review Of The Upcoming 0.12.0 Release
Hello Andre, Andre Zepezauer wrote: Hello Aleksey, I really hope that it isn't a huge disaster for your personal life, when support for Rutoken S will be dropped in the near future. The rational behind this decision may be the fact, that such a kind of device is technology from the past. If we were in the 80's then this would be state of the art. But today, everyone concerned in security should use more capable devices. Personally I don't use Rutoken S. It was historically formed that I support code for all Rutoken in OpenSC. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Personal Review Of The Upcoming 0.12.0 Release
Hello, Martin Paljak wrote: On Sep 1, 2010, at 9:41 AM, Aleksey Samsonov wrote: Rutoken S [1] doesn't support on-board RSA (as opposed to Rutoken ECP). Rutoken ECP [2] have on-board RSA (with RSA keys up to 2048 bits), GOST R 34.10-2001 (public-key cryptography), GOST 34.11-94 (hash) and GOST 28147-89 (symmetric-key algorithm). The file card-rutoken.c provides support Rutoken S. And this code worked on old scheme OpenSC. Already now (new scheme) all old functionality aren't working at Rutoken S. Example: software key generation was removed [3]. Right. Software RSA support for Rutoken S should then be removed. I'm going to cleanup code. OpenSC should be a gateway to key operations in hardware. Maybe, just maybe, it would make sense to support data objects over PKCS#11 for using smart cards like small secure flash drives (like TrueCrypt wants to use PKCS#11) but key material should never be automagically extracted into host memory and the user of OpenSC (PKCS#11) left the impression that key operations are taking place inside the token, when in fact they are not. I think, support data objects make sense. I will make cleanup Rutoken S code. Thanks ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Personal Review Of The Upcoming 0.12.0 Release
Hello, Martin Paljak wrote: On Aug 30, 2010, at 2:52 PM, Emanuele Pucciarelli wrote: The handful of drivers with insecure operations I was talking about, I got with the following command: grep -n OPENSSL libopensc/card-*.c But looking closer to each drivers source, I must confess that there are only two of them affected: http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card-westcos.c#L1244 http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card-rutoken.c#L1376 Looking at card-westcos.c:1117, I'd say that the insecure mode is only used with cards that do not have on-board RSA capabilities, but do have a private exportable key. In other words, it should only be a fallback. There used to be built in signaling for such scenarios, together with SC_ERROR_EXTRACTABLE_KEY return key that was not handled/implemented by the generic libopensc. That was not used and is removed since r4645 [1] Cards that don't support native RSA keys (meaning keys that can not be used for on-board operations) should be unsupported by default by OpenSC. Support for native but extractable keys is a whole different story. I doubt there are any modern smart cards that don't support native RSA these days. At least there is no reason to fake the support in OpenSC. Rutoken S is a very old devices (see [1]). They don't support on-board RSA, They have only on-board GOST 28147-89 cryptographic functions (GOST 28147-89 is a symmetric-key algorithm). On the other hand, it really seems that RSA is only done in software with card-rutoken.c. Perhaps that device does not support RSA in hardware at all? I suggest to remove the offending code and pay closer attention in the future to avoid such code. Will write it to the wiki as well. Apparently we need to clarify the capabilities of Rutoken (and different versions of it) regarding their RSA support *and* GOST support. Rutoken S [1] doesn't support on-board RSA (as opposed to Rutoken ECP). Rutoken ECP [2] have on-board RSA (with RSA keys up to 2048 bits), GOST R 34.10-2001 (public-key cryptography), GOST 34.11-94 (hash) and GOST 28147-89 (symmetric-key algorithm). The file card-rutoken.c provides support Rutoken S. And this code worked on old scheme OpenSC. Already now (new scheme) all old functionality aren't working at Rutoken S. Example: software key generation was removed [3]. Thanks [1] http://www.opensc-project.org/opensc/wiki/AktivRutokenS [2] http://www.opensc-project.org/opensc/wiki/AktivRutokenECP [3] http://www.opensc-project.org/opensc/changeset/4646 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Personal Review Of The Upcoming 0.12.0 Release
Hello,
Martin Paljak wrote:
2. The announcement of the GOST public key algorithm seems to me very
optimistic. Because the current implementation isn't functional at all
[1][2].
Good catch.
The GOST public key algorithm is working (the current implementation),
but in [1] [2] by a lucky chance. We need to fix logic in this case.
See
http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card-rtecp.c#L60
[1]http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15-sec.c#L86
[2]http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/card.c#L725
Trace example:
Breakpoint 1, _sc_card_find_rsa_alg (card=0x8e2530, key_length=256) at
card.c:730
730 for (i = 0; i card-algorithm_count; i++) {
(gdb) bt
#0 _sc_card_find_rsa_alg (card=0x8e2530, key_length=256) at card.c:730
#1 0x7fce3a329369 in sc_pkcs15_compute_signature (p15card=0x8e2b00,
obj=0x8eaff0,
flags=value optimized out, in=value optimized out, inlen=32,
out=value optimized out, outlen=64)
at pkcs15-sec.c:175
#2 0x0041118d in pkcs15_prkey_sign (ses=0x8ee2c0, obj=value
optimized out,
pMechanism=value optimized out, pData=value optimized out,
ulDataLen=32,
pSignature=value optimized out, pulDataLen=0x7128e8) at
framework-pkcs15.c:2401
#3 0x0040ca98 in sc_pkcs11_signature_final (operation=0x8ee230,
pSignature=0x712860 ,
pulSignatureLen=0x7128e8) at mechanism.c:425
#4 0x0040d546 in sc_pkcs11_sign_final (session=0x8ee2c0,
pSignature=0x712860 ,
pulSignatureLen=0x7128e8) at mechanism.c:307
#5 0x0040a82c in C_Sign (hSession=9364160, pData=0x708de0
1234567890123456789012345678901,
ulDataLen=32, pSignature=0x712860 , pulSignatureLen=0x7128e8) at
pkcs11-object.c:591
#6 0x004079b5 in main ()
(gdb) finish
Run till exit from #0 _sc_card_find_rsa_alg (card=0x8e2530,
key_length=256) at card.c:730
sc_pkcs15_compute_signature (p15card=0x8e2b00, obj=0x8eaff0,
flags=value optimized out,
in=value optimized out, inlen=32, out=value optimized out,
outlen=64) at pkcs15-sec.c:176
176 if (alg_info == NULL) {
Value returned is $1 = (sc_algorithm_info_t *) 0x8e27c0
(gdb) p/x *$1
$3 = {algorithm = 0x0, key_length = 0x100, flags = 0x8011, u = {_rsa
= {exponent = 0x0}}}
(gdb) n
175 alg_info = _sc_card_find_rsa_alg(p15card-card,
prkey-modulus_length);
(gdb)
176 if (alg_info == NULL) {
(gdb)
160 size_t modlen = prkey-modulus_length / 8;
(gdb)
183 if (inlen sizeof(buf) || outlen modlen)
(gdb)
185 memcpy(buf, in, inlen);
(gdb)
180 senv.algorithm = SC_ALGORITHM_RSA;
(gdb)
185 memcpy(buf, in, inlen);
(gdb)
195 if ((alg_info-flags SC_ALGORITHM_NEED_USAGE)
(gdb)
223 if ((flags == (SC_ALGORITHM_RSA_PAD_PKCS1 |
SC_ALGORITHM_RSA_HASH_NONE))
(gdb)
237 r = sc_get_encoding_flags(ctx, flags, alg_info-flags,
pad_flags, sec_flags);
(gdb)
238 if (r != SC_SUCCESS) {
(gdb)
245 if (pad_flags != 0) {
(gdb)
242 senv.algorithm_flags = sec_flags;
(gdb)
245 if (pad_flags != 0) {
(gdb)
242 senv.algorithm_flags = sec_flags;
(gdb)
245 if (pad_flags != 0) {
(gdb)
250 } else if ((flags SC_ALGORITHM_RSA_PADS) ==
SC_ALGORITHM_RSA_PAD_NONE) {
(gdb)
252 if (inlen modlen) {
(gdb)
260 senv.operation = SC_SEC_OPERATION_SIGN;
(gdb)
261 senv.flags = 0;
(gdb)
263 if (prkey-key_reference = 0) {
(gdb)
264 senv.key_ref_len = 1;
(gdb)
265 senv.key_ref[0] = prkey-key_reference 0xFF;
(gdb)
266 senv.flags |= SC_SEC_ENV_KEY_REF_PRESENT;
(gdb)
268 senv.flags |= SC_SEC_ENV_ALG_PRESENT;
(gdb)
270 r = sc_lock(p15card-card);
(gdb)
271 SC_TEST_RET(ctx, SC_LOG_DEBUG_NORMAL, r, sc_lock()
failed);
(gdb)
270 r = sc_lock(p15card-card);
(gdb)
271 SC_TEST_RET(ctx, SC_LOG_DEBUG_NORMAL, r, sc_lock()
failed);
(gdb)
273 if (prkey-path.len != 0) {
(gdb)
274 r = select_key_file(p15card, prkey, senv);
(gdb)
275 if (r 0) {
(gdb)
274 r = select_key_file(p15card, prkey, senv);
(gdb)
275 if (r 0) {
(gdb)
281 r = sc_set_security_env(p15card-card, senv, 0);
(gdb)
282 if (r 0) {
(gdb)
281 r = sc_set_security_env(p15card-card, senv, 0);
(gdb)
282 if (r 0) {
(gdb)
287 r = sc_compute_signature(p15card-card, tmp, inlen, out,
outlen);
(gdb) s
sc_compute_signature (card=0x8e2530, data=0x7fff14921100
1234567890123456789012345678901, datalen=32,
out=0x712860 , outlen=64) at sec.c:48
48 {
(gdb) n
51
Re: [opensc-devel] new versions
Hello, Aleksey Samsonov wrote: martin, do you want to create new releases? Need to test 0.11 branch with the openssl engine fix. Could you wait a few days? I'm try to find more clean solution. We have problem under the stipulation that load gost engine before loading engine_pkcs11 (which loading gost engine). I fixed to trunk and backported to releases/opensc-0.11.14. Thanks! ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new versions
Hello, Martin Paljak wrote: * what happend to opensc 0.11.*? I thought the problem with gost / engine_pkcs11 is so big, it should be fixed in the 0.11 line to help normal users, and so distributions can backport that fix if they want. Apparently Jean-Michel has some specific bugfixes in the Entersafe driver (can you pinpoint the changesets/bugs?) that also should be incorporated in addition to the OpenSSL/GOST issue. martin, do you want to create new releases? Need to test 0.11 branch with the openssl engine fix. Could you wait a few days? I'm try to find more clean solution. We have problem under the stipulation that load gost engine before loading engine_pkcs11 (which loading gost engine). ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc 0.11.13 and openssl 1.0 oddity
Hello,
Fix committed to trunk (revision 4347). Could you please test it?
Thanks
Aleksey Samsonov wrote:
Hello,
Martin Paljak wrote:
Hello,
On Apr 22, 2010, at 23:08 , Aleksey Samsonov wrote:
What are you think about solution in attachment? (openssl.cnf isn't
needed in this case)
Thanks
Index: src/pkcs11/openssl.c
+#ifndef OPENSSL_NO_ENGINE
+ENGINE *e;
+
+#if !defined(OPENSSL_NO_STATIC_ENGINE) !defined(OPENSSL_NO_GOST)
+ENGINE_load_gost();
+#else
+/* TODO: try to load dynamic gost engine */
Does this mean that the gost engine (and thus software gost
verification) only works if the gost engine is built in and not a
dynamic engine?
No. This mean that I'm going to do it if concept is true.
+#endif /* !OPENSSL_NO_STATIC_ENGINE !OPENSSL_NO_GOST */
+
+e = ENGINE_by_id(gost);
+if (e) {
+ENGINE_set_default(e, ENGINE_METHOD_ALL);
Doesn't this affect RSA operations?
Gost engine doesn't have callback for ENGINE_METHOD_RSA. Therefore it
doesn't affect.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc 0.11.13 and openssl 1.0 oddity
Hello,
Martin Paljak wrote:
Hello,
On Apr 22, 2010, at 23:08 , Aleksey Samsonov wrote:
What are you think about solution in attachment? (openssl.cnf isn't needed
in this case)
Thanks
Index: src/pkcs11/openssl.c
+#ifndef OPENSSL_NO_ENGINE
+ENGINE *e;
+
+#if !defined(OPENSSL_NO_STATIC_ENGINE) !defined(OPENSSL_NO_GOST)
+ENGINE_load_gost();
+#else
+/* TODO: try to load dynamic gost engine */
Does this mean that the gost engine (and thus software gost verification)
only works if the gost engine is built in and not a dynamic engine?
No. This mean that I'm going to do it if concept is true.
+#endif /* !OPENSSL_NO_STATIC_ENGINE !OPENSSL_NO_GOST */
+
+e = ENGINE_by_id(gost);
+if (e) {
+ENGINE_set_default(e, ENGINE_METHOD_ALL);
Doesn't this affect RSA operations?
Gost engine doesn't have callback for ENGINE_METHOD_RSA. Therefore it
doesn't affect.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc 0.11.13 and openssl 1.0 oddity
Hello, Call OPENSSL_config(NULL) was need for loading GOST engine. It was need for applications which use PKCS#11 (opensc-pkcs11.so) with GOST algorithms and which don't use openssl directly (not call OPENSSL_config(NULL)). Jan was right, he wrote more detailed: Jan Just Keijser wrote: the problem is not in openssl land but in the way the GOST engine is loaded by the pkcs11 software. The GOST engine requires a section in the openssl.cnf file to load the appropriate shared library. and to load (if not defined OPENSSL_NO_STATIC_ENGINE) static engine. The problem (with openssl) is , is that you cannot register an engine twice. So when a program loads and parses an openssl.cnf file which contains engine definitions then the second attempt to register that enginte will cause a failure. I've built the GOST engine myself and did *NOT* specify an openssl.cnf file : the gost engine still loads, but I am not sure if it is functional. In this case GOST algorithms do not work. In this case command openssl genpkey -engine gost -algorithm gost2001 -pkeyopt paramset:A works. But application which use PKCS#11 (not called OPENSSL_config) doesn't work. So the real question becomes: is this openssl.cnf section still necessary? Yes, it is. Andreas Jellinghaus wrote: Am Samstag 17 April 2010 16:30:02 schrieb Martin Paljak: Compatibility with OpenSSL 1.0 is a good reason for a new release but I've not yet understood if it really is a problem with OpenSC or OpenSSL (reading up) as far as I understand the issue: * the combination of openssl, gost engine and opensc has problems * to work around that, the config loading in opensc was disabled * that breaks normal openssl + engine_pkcs11 + opensc combination. so I think it is best to revert the hack for gost, so normal users can again use opensc with openssl and engine_pkcs11. the problem with gost engine remains then, but I don't know it well enough to say if the problem is in openssl, gost or opensc. or maybe the problem is using openssl with two engines (gost and engine_pkcs11) which both load opensc? not sure if I understood this right. but if the situation is like that, maybe the engines should be merged into one engine that handles both rsa and gost encryption? I guess Aleksey can explain the situaiton best (added as cc:). Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc 0.11.13 and openssl 1.0 oddity
Hello,
Andreas Jellinghaus wrote:
Am Freitag 16 April 2010 08:51:31 schrieb Aleksey Samsonov:
Hello,
Jan Just Keijser wrote:
in opensc-0.11.13/src/pkcs11/openssl.c there's section
106 void
107 sc_pkcs11_register_openssl_mechanisms(struct sc_pkcs11_card *card)
108 {
109 #if OPENSSL_VERSION_NUMBER = 0x1000L
110 /* FIXME: see openssl-1.0.0-beta3/engines/ccgost/README.gost */
111 OPENSSL_config(NULL);
112 #endif
It needs for loading and using engine with GOST algorithms.
I think we cannot break an existing and often used feature, for the sake
of a new feature, so there has to be a different way.
I'm absolutely agree with you.
so its a regression and the natural way to handle this would be to revert
your change. but it breaks opensc for gost users. what can we do for them
to improve the situation, without breaking openssl/engine/opensc use?
I started to looking for right solution. I can test if anyone has any
solutions.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New project coordinator: Martin Paljak
Hello Andreas, Thank you for your work! Good luck Martin! Andreas Jellinghaus wrote: Dear all, for several years I have coordinated the OpenSC, OpenCT, Libp11, Pam_p11 and Engine_PKCS11 projects: Created new releases, fixed some bugs, helped many users with questions, applied patches from developers all around the world, written some documentation, tested our software and the packaging by distributions, kept our server alive and up-to-date and done whatever else was necessary to keep the projects going. Still most work was done by everyone else, I only had to fill some gaps and start some processes to keep the projects going. Recently however I started a new job and at least right now I have little time available for these open source projects. Thus I'm very happy to announce Martin Paljak has agreed to take over as project coordinator for these projects. Martin is a long time contributer and very active developer to OpenSC. He has already taken care of several parts of OpenSC in the past and improved and maintained them, such as the PC/SC reader driver with a focus on the PIN-pad input system, or driver for estonian national ID cards. Also he has been co-administrator of our server for several years and very active on the mailing list, helping users and developers, and recently started to reorganize and greatly improve our wiki pages. I'd like to thank everyone for the support and encouragement I got as project coordinator and would like you to give the same to Martin Paljak as new project coordinator too. Of course I will continue to work on OpenSC and related projects to improve them and help users and all that, but I'm happy to pass the role of project coordinator to Martin, so the projects won't be held back by my recent time constrains. With kind regards Andreas Jellinghaus ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs15-rtecp.c question
Hello Viktor, Viktor TARASOV wrote: rv = sc_change_reference_data(card, pin_info-type, pin_info-reference, ... My humble question is: does there any mis-usage of the 'type' member of the 'pin_info' data? Afaik, 'type' in 'sc_pkcs15_pin_info' structure holds the PKCS#15 PinAttributes.pinType -- PIN encoding style; the 'sc_change_reference_data()' expects as a second argument the 'authentication method' like SC_AC_CHV. It's a bug. Thanks! Committed at revision 4037. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc 0.11.13 - all fixes commited?
Hi, Andreas Jellinghaus wrote: so is everything we want for 0.11.13 commited? Сhangeset r4027 and r4028. What do you think? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc 0.11.13 - all fixes commited?
Martin Paljak wrote: On Feb 15, 2010, at 19:04 , Aleksey Samsonov wrote: Сhangeset r4027 and r4028. What do you think? Leaks are bugs. Yes. Andreas Jellinghaus wrote: they look like nice clean bug fixes, so they make good candidates for the 0.11.13 release. feel free to commit them to 0.11.13 too. Commited. I'm terribly sorry for r4028+r4032 (r4031+r4033). ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new ubuntu packages
Hello, Andreas Jellinghaus wrote: Thanks to Stephan Hermann new openct and opensc packages for ubuntu are available: https://launchpad.net/ubuntu/+source/openct/0.6.19-1ubuntu2 https://launchpad.net/ubuntu/+source/opensc/0.11.12-1ubuntu1 To my knowledge they contain all the changes and fixes we wanted for packaging, so Ubuntu 10.04 lucid will have working smart card packages. If you can help with testing, that would be very welcome. OpenCT-0.6.19 was released after changeset 1174 in OpenCT [1] and changeset 3865 in OpenSC [2], but OpenSC was not released. OpenCT-0.6.19 + OpenSC-0.11.12 don't work with Rutoken S. [1] http://www.opensc-project.org/openct/changeset/1174 [2] http://www.opensc-project.org/opensc/changeset/3865 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] keycache broken between pkcs11 and pkcs15 layers
Hello, Xiaoshuo Wu wrote: On Sun, 17 Jan 2010 20:36:53 +0800, Xiaoshuo Wu xiaos...@ftsafe.com wrote: I'd like to hear your plan for these changes so as to help me fix this. I recovered cache_pin() in rev 3783, renamed it add_pins_to_keycache() and had some adjustment. When login/change PIN/init PIN/create object successful, we cache the pin. I made a patch for this, please review it, any advices are welcome, thank you. Please see patch in http://www.opensc-project.org/pipermail/opensc-devel/2009-November/012863.html for interim measures. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PKCS#11 and check parameters for NULL_PTR
Hello, Committed at trunk revision 3891. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] PKCS#11 and check parameters for NULL_PTR
Hello,
I propose a patch for PKCS#11
Fix: any of these calls
C_CreateObject(hSession, NULL_PTR, 1, NULL_PTR);
C_GetAttributeValue(hSession, hObject, NULL_PTR, 1);
C_SetAttributeValue(hSession, hObject, NULL_PTR, 1);
C_FindObjectsInit(hSession, NULL_PTR, 1);
C_FindObjects(hSession, NULL_PTR, 0, NULL_PTR);
C_FindObjects(hSession, NULL_PTR, 1, NULL_PTR);
C_FindObjects(hSession, NULL_PTR, 1, pulObjectCount);
C_DigestInit(hSession, NULL_PTR);
C_SignInit(hSession, NULL_PTR, hKey);
C_SignRecoverInit(hSession, NULL_PTR, hKey);
C_DecryptInit(hSession, NULL_PTR, hKey);
C_VerifyInit(hSession, NULL_PTR, hKey);
C_GenerateKeyPair(hSession, NULL_PTR, pubKeyTmpl, arraysize(pubKeyTmpl),
prvKeyTmpl, arraysize(prvKeyTmpl), hPubKey, hPrvKey);
C_GenerateKeyPair(hSession, pMechanism, pubKeyTmpl,
arraysize(pubKeyTmpl), NULL_PTR, 1, hPubKey, hPrvKey);
C_GenerateKeyPair(hSession, pMechanism, NULL_PTR, 1, prvKeyTmpl,
arraysize(prvKeyTmpl), hPubKey, hPrvKey);
=
Segmentation fault
Any idea?
Index: src/pkcs11/pkcs11-object.c
===
--- src/pkcs11/pkcs11-object.c (revision 3885)
+++ src/pkcs11/pkcs11-object.c (working copy)
@@ -40,6 +40,11 @@
rv = sc_pkcs11_lock();
if (rv != CKR_OK)
return rv;
+
+ if (pTemplate == NULL_PTR ulCount 0) {
+ rv = CKR_ARGUMENTS_BAD;
+ goto out;
+ }
dump_template(C_CreateObject(), pTemplate, ulCount);
rv = pool_find(session_pool, hSession, (void**) session);
@@ -129,6 +134,11 @@
if (rv != CKR_OK)
return rv;
+ if (pTemplate == NULL_PTR || ulCount == 0) {
+ rv = CKR_ARGUMENTS_BAD;
+ goto out;
+ }
+
rv = pool_find(session_pool, hSession, (void**) session);
if (rv != CKR_OK)
goto out;
@@ -187,6 +197,10 @@
if (rv != CKR_OK)
return rv;
+ if (pTemplate == NULL_PTR || ulCount == 0) {
+ rv = CKR_ARGUMENTS_BAD;
+ goto out;
+ }
dump_template(C_SetAttributeValue, pTemplate, ulCount);
rv = pool_find(session_pool, hSession, (void**) session);
@@ -230,6 +244,11 @@
if (rv != CKR_OK)
return rv;
+ if (pTemplate == NULL_PTR ulCount 0) {
+ rv = CKR_ARGUMENTS_BAD;
+ goto out;
+ }
+
rv = pool_find(session_pool, hSession, (void**) session);
if (rv != CKR_OK)
goto out;
@@ -324,6 +343,11 @@
if (rv != CKR_OK)
return rv;
+ if (phObject == NULL_PTR || ulMaxObjectCount == 0 || pulObjectCount ==
NULL_PTR) {
+ rv = CKR_ARGUMENTS_BAD;
+ goto out;
+ }
+
rv = pool_find(session_pool, hSession, (void**) session);
if (rv != CKR_OK)
goto out;
@@ -385,12 +409,17 @@
if (rv != CKR_OK)
return rv;
+ if (pMechanism == NULL_PTR) {
+ rv = CKR_ARGUMENTS_BAD;
+ goto out;
+ }
+
rv = pool_find(session_pool, hSession, (void**) session);
if (rv == CKR_OK)
rv = sc_pkcs11_md_init(session, pMechanism);
sc_debug(context, C_DigestInit returns %d\n, rv);
- sc_pkcs11_unlock();
+out: sc_pkcs11_unlock();
return rv;
}
@@ -483,6 +512,11 @@
if (rv != CKR_OK)
return rv;
+ if (pMechanism == NULL_PTR) {
+ rv = CKR_ARGUMENTS_BAD;
+ goto out;
+ }
+
rv = pool_find(session_pool, hSession, (void**) session);
if (rv != CKR_OK)
goto out;
@@ -632,6 +666,11 @@
if (rv != CKR_OK)
return rv;
+ if (pMechanism == NULL_PTR) {
+ rv = CKR_ARGUMENTS_BAD;
+ goto out;
+ }
+
rv = pool_find(session_pool, hSession, (void**) session);
if (rv != CKR_OK)
goto out;
@@ -727,6 +766,11 @@
if (rv != CKR_OK)
return rv;
+ if (pMechanism == NULL_PTR) {
+ rv = CKR_ARGUMENTS_BAD;
+ goto out;
+ }
+
rv = pool_find(session_pool, hSession, (void**) session);
if (rv != CKR_OK)
goto out;
@@ -864,6 +908,12 @@
rv = sc_pkcs11_lock();
if (rv != CKR_OK)
return rv;
+ if (pMechanism == NULL_PTR
+ || (pPublicKeyTemplate == NULL_PTR
ulPublicKeyAttributeCount 0)
+ || (pPrivateKeyTemplate == NULL_PTR
ulPrivateKeyAttributeCount 0)) {
+ rv = CKR_ARGUMENTS_BAD;
+ goto out;
+ }
dump_template(C_CreateObject(), PrivKey attrs, pPrivateKeyTemplate,
ulPrivateKeyAttributeCount);
dump_template(C_CreateObject(), PubKey attrs, pPublicKeyTemplate,
ulPublicKeyAttributeCount);
@@ -912,6 +962,11 @@
if (rv != CKR_OK)
return rv;
+
[opensc-devel] PKCS#11 and read-only session
Hello,
I propose a patch for PKCS#11
Fix: return CKR_SESSION_READ_ONLY from C_InitPIN, C_SetPIN,
C_CreateObject, C_CopyObject, C_DestroyObject, C_SetAttributeValue,
C_GenerateKey, C_GenerateKeyPair, C_UnwrapKey, C_DeriveKey if session is
read-only.
PKCS#11:
C_InitPIN can only be called in the 'R/W SO Functions' state.
C_SetPIN can only be called in the 'R/W Public Session' state, 'R/W SO
Functions' state, or 'R/W User Functions' state. An attempt to call it
from a session in any other state fails with error CKR_SESSION_READ_ONLY.
Only session objects can be created/destroyed/modified
(C_CreateObject/C_DestroyObject/C_SetAttributeValue) during a read-only
session.
But,
http://www.opensc-project.org/opensc/browser/trunk/src/pkcs11/pkcs11-session.c?rev=3862#L344
Why does it need (#if 0)?
Any idea?
Index: src/pkcs11/pkcs11-object.c
===
--- src/pkcs11/pkcs11-object.c (revision 3885)
+++ src/pkcs11/pkcs11-object.c (working copy)
@@ -46,6 +46,11 @@
if (rv != CKR_OK)
goto out;
+ if (!(session-flags CKF_RW_SESSION)) {
+ rv = CKR_SESSION_READ_ONLY;
+ goto out;
+ }
+
card = session-slot-card;
if (card-framework-create_object == NULL)
rv = CKR_FUNCTION_NOT_SUPPORTED;
@@ -86,6 +91,11 @@
if (rv != CKR_OK)
goto out;
+ if (!(session-flags CKF_RW_SESSION)) {
+ rv = CKR_SESSION_READ_ONLY;
+ goto out;
+ }
+
rv = pool_find_and_delete(session-slot-object_pool, hObject,
(void**) object);
if (rv != CKR_OK)
goto out;
@@ -193,6 +203,11 @@
if (rv != CKR_OK)
goto out;
+ if (!(session-flags CKF_RW_SESSION)) {
+ rv = CKR_SESSION_READ_ONLY;
+ goto out;
+ }
+
rv = pool_find(session-slot-object_pool, hObject, (void**) object);
if (rv != CKR_OK)
goto out;
@@ -871,6 +886,11 @@
if (rv != CKR_OK)
goto out;
+ if (!(session-flags CKF_RW_SESSION)) {
+ rv = CKR_SESSION_READ_ONLY;
+ goto out;
+ }
+
slot = session-slot;
if (slot-card-framework-gen_keypair == NULL) {
rv = CKR_FUNCTION_NOT_SUPPORTED;
@@ -916,6 +936,11 @@
if (rv != CKR_OK)
goto out;
+ if (!(session-flags CKF_RW_SESSION)) {
+ rv = CKR_SESSION_READ_ONLY;
+ goto out;
+ }
+
rv = pool_find(session-slot-object_pool, hUnwrappingKey,
(void**) object);
if (rv != CKR_OK) {
Index: src/pkcs11/pkcs11-session.c
===
--- src/pkcs11/pkcs11-session.c (revision 3885)
+++ src/pkcs11/pkcs11-session.c (working copy)
@@ -307,6 +307,11 @@
if (rv != CKR_OK)
goto out;
+ if (!(session-flags CKF_RW_SESSION)) {
+ rv = CKR_SESSION_READ_ONLY;
+ goto out;
+ }
+
slot = session-slot;
if (slot-login_user != CKU_SO) {
rv = CKR_USER_NOT_LOGGED_IN;
@@ -341,12 +346,11 @@
goto out;
sc_debug(context, Changing PIN (session %d)\n, hSession);
-#if 0
- if (!(ses-flags CKF_RW_SESSION)) {
+
+ if (!(session-flags CKF_RW_SESSION)) {
rv = CKR_SESSION_READ_ONLY;
goto out;
}
-#endif
slot = session-slot;
rv = slot-card-framework-change_pin(slot-card, slot-fw_data,
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PKCS#11 and check parameters for NULL_PTR
Aktiv Co. Aleksey Samsonov:
or
1. no for the present and to try further (that'll do
CKR_TEMPLATE_INCOMPLETE, CKR_OK and etc)
Incidentally:
CK_MECHANISM gostMech = { CKM_GOSTR3410_KEY_PAIR_GEN, NULL, 0 };
...
C_GenerateKeyPair(hSession, gostMech, NULL_PTR, 0, NULL_PTR, 0,
hPubKey, hPrvKey);
- CKR_OK
$ pkcs15-tool -D
...
Private RSA Key [Private Key]
Com. Flags : 3
Usage : [0x4], sign
Access Flags: [0x1D], sensitive, alwaysSensitive, neverExtract,
local
ModLength : 1024
Key ref : 1
Native : yes
Path: 3f001000100060020001
Auth ID : 02
ID : 45
Public RSA Key [Private Key]
Com. Flags : 2
Usage : [0x4], sign
Access Flags: [0x0]
ModLength : 1024
Key ref : 0
Native : no
Path: 3f005245
Auth ID :
ID : 45
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] PKCS#11 and read-only session
Martin Paljak: I don't think that obvious fixes for spec conformance need any vetting period. +1 anyway. Thanks. Committed at trunk revision 3886. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Pierre Ossman: I think we might have a language barrier here as I'm not quite following what you're trying to say. Sorry for inconvenience caused. The basic problem is that none of my PKCS#15 cards have an object for the PUK (and from what I can tell the PKCS#15 standard doesn't require them to). This means that we cannot do a C_Login with the PUK beforehand (as we cannot figure out the reference of the PUK for the VERIFY operation). Then alternative sheme isn't correct in this case. But, I fear for call sc_pkcs15_unblock_pin if we have a cached SO PIN (if SO PIN != PUK). ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Viktor TARASOV: - in CKU_SO_PIN context -- set PIN after SOPIN authentication; Sorry, it's not good idea -- there should be possibility to change SOPIN. Incidentally, this isn't work for current trunk. (change SOPIN by C_SetPin) (see slot_data_auth/slot_data_pin_info and http://www.opensc-project.org/opensc/browser/trunk/src/pkcs11/framework-pkcs15.c?rev=3868#L852) ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Unblocking PIN via PKCS#11?
Pierre Ossman: I've had another look at this and implemented a somewhat ugly hack to provide this functionality. Basically C_Login will return success for CKU_SO if it can't find an auth object and then rely on the PIN cache in C_InitPIN. Comment away! Please see: http://www.opensc-project.org/pipermail/opensc-devel/2009-November/012894.html http://www.opensc-project.org/pipermail/opensc-devel/2009-November/012891.html --- src/pkcs11/framework-pkcs15.c(revision 18564) For current trunk: In file included from framework-pkcs15.c:23: framework-pkcs15.c: In function 'pkcs15_login': framework-pkcs15.c:973: warning: implicit declaration of function 'cache_pin' framework-pkcs15.c: In function 'pkcs15_init_pin': framework-pkcs15.c:1144: error: 'struct pkcs15_slot_data' has no member named 'pin' framework-pkcs15.c:1145: error: 'struct pkcs15_slot_data' has no member named 'pin' make[3]: *** [framework-pkcs15.lo] Error 1 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch to make pkcs11 pin cache working
François Leblanc wrote: For now I propose this small patch to permit generate_key with pkcs11-tool. More universal (but not full and not good for future) patch is here: http://www.opensc-project.org/pipermail/opensc-devel/2009-November/012863.html ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs11 trouble on 0.12.0-svn
François Leblanc: Hi there, Hi, Does someone do commands like : pkcs11-tool -l -O It fails for me: error: PKCS11 function C_OpenSession failed: rv = CKR_TOKEN_NOT_PRESENT (0xe0) but if I do : pkcs11-tool -T Available slots: Slot 4 CEVGroup Software Reader 1 Please try $ pkcs11-tool -l -O --slot 4 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ID of cryptographic objects
Hello, Viktor TARASOV wrote: Aleksey Samsonov wrote: Thanks, but some potencial memory leaks. See patch in attachment. You can apply this patch, if you think it should be. ok As for me, there is no potential leaks -- I trust entirely the sc_asn1_encode() . Agree, there is an excessive 'if' . Personally, I prefer to know with more precision where an error took place, but I agree, it's a question of taste. Does anyone think that there is potencial memory leaks and correction is necessary? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ID of cryptographic objects
Hello,
Viktor TARASOV wrote:
Aktiv Co. Aleksey Samsonov wrote:
Viktor TARASOV:
skipped
It's commited ...
Thanks, but some remarks:
Potencial memory leaks (see /* */):
Thanks for your code revision.
Thanks, but some potencial memory leaks. See patch in attachment.
Index: src/pkcs15init/pkcs15-lib.c
===
--- src/pkcs15init/pkcs15-lib.c (revision 3858)
+++ src/pkcs15init/pkcs15-lib.c (working copy)
@@ -2324,8 +2324,10 @@
SC_FUNC_RETURN(ctx, 1, 0);
}
+ rv = SC_ERROR_INTERNAL;
+
/* Skip silently if key is not inintialized. */
- if (pubkey-algorithm == SC_ALGORITHM_RSA !pubkey-u.rsa.modulus.len)
+ if (pubkey-algorithm == SC_ALGORITHM_RSA
!pubkey-u.rsa.modulus.data)
goto done;
else if (pubkey-algorithm == SC_ALGORITHM_DSA
!pubkey-u.dsa.pub.data)
goto done;
@@ -2353,11 +2355,9 @@
size_t id_data_len = 0;
rv = sc_pkcs15_encode_pubkey(ctx, pubkey, id_data,
id_data_len);
- SC_TEST_RET(ctx, rv, Encoding public key error);
+ if (rv != SC_SUCCESS || !id_data || !id_data_len)
+ goto done;
- if (!id_data || !id_data_len)
- SC_TEST_RET(ctx, SC_ERROR_INTERNAL, Encoding public
key error);
-
SHA1(id_data, id_data_len, id-value);
id-len = SHA_DIGEST_LENGTH;
@@ -2365,14 +2365,17 @@
}
else {
sc_debug(ctx, Unsupported ID style: %i, profile-id_style);
- SC_TEST_RET(ctx, SC_ERROR_NOT_SUPPORTED, Non supported ID
style);
+ rv = SC_ERROR_NOT_SUPPORTED;
+ goto done;
}
+ rv = (int)id-len;
+
done:
if (allocated)
sc_pkcs15_free_pubkey(pubkey);
- SC_FUNC_RETURN(ctx, 1, id-len);
+ SC_FUNC_RETURN(ctx, 1, rv);
#endif
}
Index: src/libopensc/pkcs15-pubkey.c
===
--- src/libopensc/pkcs15-pubkey.c (revision 3858)
+++ src/libopensc/pkcs15-pubkey.c (working copy)
@@ -612,7 +612,7 @@
break;
default:
sc_debug(ctx, Unsupported private key algorithm);
- return SC_ERROR_NOT_SUPPORTED;
+ rv = SC_ERROR_NOT_SUPPORTED;
}
if (rv)
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Re-implement PIN cache and sc_pkcs15init_authenticate (sc_keycache_get_key)
Hello,
After changeset 3784
http://www.opensc-project.org/opensc/changeset/3784/branches
Give special attention to:
-static void cache_pin(void *, int, const sc_path_t *, const void *,
size_t);
and
http://www.opensc-project.org/opensc/browser/branches/martin/0.12/src/pkcs11/framework-pkcs15.c?rev=3784#L3003
Tests Rytoken ECP:
C_Login()
C_CreateObject() - (pkcs15_create_object - pkcs15_create_data -
sc_pkcs15init_store_data_object - sc_pkcs15init_store_data -
sc_pkcs15init_update_file) - sc_pkcs15init_authenticate -
---
[opensc-pkcs11] pkcs15-lib.c:3427:sc_pkcs15init_authenticate:
path=3f005501, op=1
[opensc-pkcs11] pkcs15-lib.c:3437:sc_pkcs15init_authenticate: r:[0x]
[opensc-pkcs11] pkcs15-lib.c:3438:sc_pkcs15init_authenticate:
acl:[0x0805ee48]
[opensc-pkcs11] pkcs15-lib.c:3455:sc_pkcs15init_authenticate: verify
---
do_get_and_verify_secret - sc_keycache_get_key returned is $1 = -1407
=
[opensc-pkcs11] misc.c:82:sc_to_cryptoki_error: opensc error: Requested
object not found (-1407)
Minimal patch (draft):
Index: src/pkcs11/framework-pkcs15.c
===
--- src/pkcs11/framework-pkcs15.c (revision 3852)
+++ src/pkcs11/framework-pkcs15.c (working copy)
@@ -1009,6 +1009,9 @@
rc = sc_pkcs15_verify_pin(card, pin, pPin, ulPinLen);
sc_debug(context, PIN verification returned %d\n, rc);
+ if (rc = 0)
+ sc_keycache_put_key(pin-path, pin-type, pin-reference,
+ pPin, ulPinLen);
return sc_to_cryptoki_error(rc, p11card-reader);
}
@@ -1016,7 +1019,8 @@
{
struct pkcs15_fw_data *fw_data = (struct pkcs15_fw_data *)
p11card-fw_data;
int rc = 0;
-
+
+ /* FIXME: cleanup keycache, to do opposite sc_keycache_put_key */
sc_pkcs15_pincache_clear(fw_data-p15_card);
sc_logout(fw_data-p15_card-card);
@@ -1054,6 +1058,9 @@
rc = sc_pkcs15_change_pin(fw_data-p15_card, pin, pOldPin,
ulOldLen,
pNewPin, ulNewLen);
sc_debug(context, PIN change returned %d\n, rc);
+ if (rc = 0)
+ sc_keycache_put_key(pin-path, pin-type, pin-reference,
+ pNewPin, ulNewLen);
return sc_to_cryptoki_error(rc, p11card-reader);
}
@@ -1099,6 +1106,8 @@
pkcs15_init_slot(fw_data-p15_card, slot, auth_obj);
pin_info = (sc_pkcs15_pin_info_t *) auth_obj-data;
+ sc_keycache_put_key(pin_info-path, pin_info-type,
pin_info-reference,
+ pPin, ulPinLen);
return CKR_OK;
}
Any idea?
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ID of cryptographic objects
Viktor TARASOV:
Aktiv Co. Aleksey Samsonov wrote:
Viktor TARASOV:
Hi,
Hi
Hi,
Nevertheless, IMHO, it would be nice, for the cryptographic objects (and
maybe for the others)
to have the possibility of some unique ID calculated from the object
itself, as it was discussed in thread:
'CKA_ID and pkcs15 ID' 05.09.2005 13:34 .
The idea is to have a choice of method to calculate the ID:
- SHA1 of the modulus (Mozilla style),
- SHA1 of public key (recommended by RFC2459)
- or the actual one byte ID (default).
Then use some additional profile option to indicate the method to be
used.
Any objection if I implement it?
I think, this is a true idea.
It's commited ...
Thanks, but some remarks:
Potencial memory leaks (see /* */):
1) sc_pkcs15_pubkey_from_prvkey:
579:pubkey = (struct sc_pkcs15_pubkey *) calloc(1, sizeof(struct
sc_pkcs15_pubkey));
...
584:switch (prvkey-algorithm) {
...
595: and 616:arr[ii].dst-data = malloc(arr[ii].src-len);
if (!arr[ii].dst-data)
return SC_ERROR_OUT_OF_MEMORY; /*
free(arr[XX].dst-data); free(pubkey) */
...
627:default:
sc_error(ctx, Unsupported private key algorithm);
return SC_ERROR_NOT_SUPPORTED; /* free(pubkey) */
...
2) sc_pkcs15_pubkey_from_cert:
615:pubkey = (struct sc_pkcs15_pubkey *) calloc(1, sizeof(struct
sc_pkcs15_pubkey));
...
658:SC_TEST_RET(ctx, SC_ERROR_INVALID_DATA, BIO new memory
buffer error); /* free(pubkey) */
...
662:SC_TEST_RET(ctx, SC_ERROR_INVALID_DATA, X509 parse error);
/* BIO_free(mem); free(pubkey) */
...
666:SC_TEST_RET(ctx, SC_ERROR_INVALID_DATA, Get public key
error); /* (if (pkey) free(EVP_PKEY_free(pkey);); X509_free(x);
BIO_free(mem); free(pubkey) */
...
669:pubkey-u.rsa.modulus.data = malloc(pubkey-u.rsa.modulus.len);
pubkey-u.rsa.exponent.len = BN_num_bytes(pkey-pkey.rsa-e);
pubkey-u.rsa.exponent.data =
malloc(pubkey-u.rsa.exponent.len);
if (!pubkey-u.rsa.modulus.data ||
!pubkey-u.rsa.exponent.data)
SC_TEST_RET(ctx, SC_ERROR_OUT_OF_MEMORY, Cannot
allocate key components); /* free(pubkey-u.rsa.modulus.data);
free(pubkey-u.rsa.exponent.data); ;EVP_PKEY_free(pkey); X509_free(x);
BIO_free(mem); free(pubkey) */
if (BN_bn2bin(pkey-pkey.rsa-n,
pubkey-u.rsa.modulus.data) != pubkey-u.rsa.modulus.len)
SC_TEST_RET(ctx, SC_ERROR_INVALID_DATA, BN to BIN
conversion error); /* !!! */
if (BN_bn2bin(pkey-pkey.rsa-e,
pubkey-u.rsa.exponent.data) != pubkey-u.rsa.exponent.len)
SC_TEST_RET(ctx, SC_ERROR_INVALID_DATA, BN to BIN
conversion error); /* !!! */
Also (style, mix tab/space character):
src/pkcs15init/pkcs15-lib.c:1397
src/pkcs15init/pkcs15-lib.c:1477
src/pkcs15init/pkcs15-lib.c:1393
src/libopensc/pkcs15.h:491: struct sc_pkcs15_pubkey **__out__);
src/libopensc/pkcs15-pubkey.c:655
and:
pkcs15-pubkey.c: In function 'sc_pkcs15_pubkey_from_cert':
pkcs15-pubkey.c:677: warning: comparison between signed and unsigned
pkcs15-pubkey.c:679: warning: comparison between signed and unsigned
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ID of cryptographic objects
Viktor TARASOV:
Aktiv Co. Aleksey Samsonov wrote:
Viktor TARASOV:
skipped
It's commited ...
Thanks, but some remarks:
Potencial memory leaks (see /* */):
Thanks for your code revision. I'll be more attentive.
Considering the 'SC_ERROR_OUT_OF_MEMORY' error,
IMHO, it's quiet dangerous to regroup the allocations,
then, if at least one pointer is not valid,
try to liberate the allocated memory without verifying of every
particular pointer.
src/pkcs15init/pkcs15-rtecp.c +529
src/pkcs15init/pkcs15-rtecp.c +542
src/libopensc/card-rutoken.c +1143
...
What do you mean by quiet dangerous to regroup the allocations?
src/pkcs15init/pkcs15-rtecp.c:
496: sc_rtecp_genkey_data_t data;
...
523:data.u.rsa.modulus = calloc(1, data.u.rsa.modulus_len);
524:data.u.rsa.exponent_len = key_info-modulus_length / 8 / 2;
525:data.u.rsa.exponent = calloc(1, data.u.rsa.exponent_len);
526:if (!data.u.rsa.modulus || !data.u.rsa.exponent)
527:{
/* 1. data.u.rsa.modulus == VALID_PTR; data.u.rsa.exponent == NULL */
/* 2. data.u.rsa.modulus == NULL; data.u.rsa.exponent == NULL */
/* 3. data.u.rsa.modulus == NULL; data.u.rsa.exponent == VALID_PTR */
528:free(data.u.rsa.modulus); /* if
data.u.rsa.modulus == NULL then no effect, else free mem */
529:free(data.u.rsa.exponent); if
data.u.rsa.exponent == NULL then no effect, else free mem */
/* data is local variable */
SC_FUNC_RETURN(card-ctx, 0,
SC_ERROR_OUT_OF_MEMORY);
}
http://www.opengroup.org/onlinepubs/7990989775/xsh/calloc.html:
RETURN VALUE
Upon successful completion with both nelem and elsize non-zero, calloc()
returns a pointer to the allocated space. If either nelem or elsize is
0, then either a null pointer or a unique pointer value that can be
successfully passed to free() is returned. Otherwise, it returns a null
pointer and sets errno to indicate the error.
http://www.opengroup.org/onlinepubs/7990989775/xsh/free.html:
DESCRIPTION
If ptr is a null pointer, no action occurs.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] ID of cryptographic objects
Viktor TARASOV:
Aktiv Co. Aleksey Samsonov wrote:
Viktor TARASOV:
Aktiv Co. Aleksey Samsonov wrote:
Viktor TARASOV:
skipped
It's commited ...
Thanks, good work.
--- /trunk/src/libopensc/pkcs15-pubkey.c (revision 3818)
+++ /trunk/src/libopensc/pkcs15-pubkey.c (revision 3820)
@@ -70,5 +70,5 @@
static const struct sc_asn1_entry c_asn1_gostr3410key_attr[] = {
- { value, SC_ASN1_PATH, SC_ASN1_TAG_SEQUENCE |
SC_ASN1_CONS, 0, NULL, NULL },
+ { value, SC_ASN1_PATH, SC_ASN1_TAG_SEQUENCE |
SC_ASN1_CONS, 0, NULL, NULL },
{ params_r3410, SC_ASN1_INTEGER, SC_ASN1_TAG_INTEGER, 0,
NULL, NULL },
;)) Those space characters were deliberately solution, but let it be.
Also I'm going to do some changes for GOST key, if you don't mind.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] 'return' versus 'SC_FUNC_RETURN'
Aleksey Samsonov wrote: Does it exists any rule for the assigning of the debug level for debug messages ? I think we have to follow common sence. Also you can find some information here http://www.opensc-project.org/pipermail/opensc-devel/2009-September/012466.html ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs15 init, problem with the profile
Hello, Aventra development: Does the other drivers work when initializing a card, and is the ACL set correctly? The ACL is set correctly for Rutoken. Example (Rutoken ECP): $ pkcs15-init -E -C --so-pin 87654321 --so-puk 21 1.txt 1.txt attached See: card.c:362:sc_create_file: called; type=2, path=3f002f00, size=128 - card-rtecp.c:239:set_sec_attr_from_acl - card-rtecp.c:780:rtecp_construct_fci - card-rtecp.c:561:rtecp_create_file: returning with: 0 [pkcs15-init] ctx.c:735:sc_context_create: === [pkcs15-init] ctx.c:736:sc_context_create: opensc version: 0.11.9-svn [pkcs15-init] reader-openct.c:79:openct_reader_init: called [pkcs15-init] sc.c:196:sc_detect_card_presence: called [pkcs15-init] reader-openct.c:194:openct_reader_detect_card_presence: called [pkcs15-init] sc.c:201:sc_detect_card_presence: returning with: 1 [pkcs15-init] sc.c:196:sc_detect_card_presence: called [pkcs15-init] reader-openct.c:194:openct_reader_detect_card_presence: called [pkcs15-init] sc.c:201:sc_detect_card_presence: returning with: 1 [pkcs15-init] card.c:110:sc_connect_card: called [pkcs15-init] reader-openct.c:218:openct_reader_connect: called [pkcs15-init] card.c:140:sc_connect_card: matching configured ATRs [pkcs15-init] card.c:182:sc_connect_card: matching built-in ATRs [pkcs15-init] card.c:188:sc_connect_card: trying driver: cardos [pkcs15-init] card.c:188:sc_connect_card: trying driver: cardos [pkcs15-init] card.c:188:sc_connect_card: trying driver: flex [pkcs15-init] card.c:188:sc_connect_card: trying driver: cyberflex [pkcs15-init] card.c:188:sc_connect_card: trying driver: gpk [pkcs15-init] card.c:188:sc_connect_card: trying driver: gemsafeV1 [pkcs15-init] card-gemsafeV1.c:120:gemsafe_match_card: called [pkcs15-init] card.c:188:sc_connect_card: trying driver: miocos [pkcs15-init] card.c:188:sc_connect_card: trying driver: mcrd [pkcs15-init] card.c:188:sc_connect_card: trying driver: asepcos [pkcs15-init] card.c:188:sc_connect_card: trying driver: setcos [pkcs15-init] card.c:285:sc_lock: called [pkcs15-init] reader-openct.c:410:openct_reader_lock: called [pkcs15-init] card.c:312:sc_unlock: called [pkcs15-init] reader-openct.c:437:openct_reader_unlock: called [pkcs15-init] card.c:188:sc_connect_card: trying driver: starcos [pkcs15-init] card.c:188:sc_connect_card: trying driver: tcos [pkcs15-init] card.c:188:sc_connect_card: trying driver: openpgp [pkcs15-init] card.c:188:sc_connect_card: trying driver: jcop [pkcs15-init] card.c:188:sc_connect_card: trying driver: oberthur [pkcs15-init] card.c:188:sc_connect_card: trying driver: belpic [pkcs15-init] card.c:188:sc_connect_card: trying driver: atrust-acos [pkcs15-init] card.c:188:sc_connect_card: trying driver: muscle [pkcs15-init] card.c:285:sc_lock: called [pkcs15-init] reader-openct.c:410:openct_reader_lock: called [pkcs15-init] card.c:312:sc_unlock: called [pkcs15-init] reader-openct.c:437:openct_reader_unlock: called [pkcs15-init] muscle.c:276:msc_select_applet: returning with: -1200 [pkcs15-init] card.c:188:sc_connect_card: trying driver: incrypto34 [pkcs15-init] card.c:188:sc_connect_card: trying driver: piv [pkcs15-init] card-piv.c:1769:piv_match_card: called [pkcs15-init] card-piv.c:493:piv_find_aid: called [pkcs15-init] card.c:285:sc_lock: called [pkcs15-init] reader-openct.c:410:openct_reader_lock: called [pkcs15-init] card.c:312:sc_unlock: called [pkcs15-init] reader-openct.c:437:openct_reader_unlock: called [pkcs15-init] iso7816.c:99:iso7816_check_sw: Function not supported [pkcs15-init] card.c:285:sc_lock: called [pkcs15-init] reader-openct.c:410:openct_reader_lock: called [pkcs15-init] card.c:312:sc_unlock: called [pkcs15-init] reader-openct.c:437:openct_reader_unlock: called [pkcs15-init] iso7816.c:99:iso7816_check_sw: Function not supported [pkcs15-init] card-piv.c:576:piv_find_aid: returning with: -1208 [pkcs15-init] card.c:188:sc_connect_card: trying driver: acos5 [pkcs15-init] card.c:188:sc_connect_card: trying driver: akis [pkcs15-init] card.c:188:sc_connect_card: trying driver: entersafe [pkcs15-init] card-entersafe.c:101:entersafe_match_card: called [pkcs15-init] card.c:188:sc_connect_card: trying driver: rutoken [pkcs15-init] card-rutoken.c:129:rutoken_match_card: called [pkcs15-init] card-rutoken.c:135:rutoken_match_card: returning with: 0 [pkcs15-init] card.c:188:sc_connect_card: trying driver: rutoken_ecp [pkcs15-init] card-rtecp.c:50:rtecp_match_card: returning with: 1 [pkcs15-init] card.c:196:sc_connect_card: matched: Rutoken ECP driver [pkcs15-init] card-rtecp.c:83:rtecp_init: returning with: 0 [pkcs15-init] card.c:221:sc_connect_card: card info: Rutoken ECP card, 0, 0x0 [pkcs15-init] card.c:222:sc_connect_card: returning with: 0 [pkcs15-init] card.c:285:sc_lock: called [pkcs15-init] reader-openct.c:410:openct_reader_lock: called [pkcs15-init] card.c:668:sc_card_ctl: called [pkcs15-init] card.c:675:sc_card_ctl: card_ctl(4) not supported [pkcs15-init] card.c:532:sc_select_file: called; type=2,
Re: [opensc-devel] OpenSC 0.11.11 -rc1 release candidate available
Hello, Kalev Lember: On 10/23/2009 04:39 PM, Andreas Jellinghaus wrote: Please give it a final test. http://www.opensc-project.org/files/opensc/testing/opensc-0.11.11-rc1.tar.gz Doesn't seem to compile with openssl-1.0 beta3 (distributed with Fedora 12, for example): /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/pkcs15init -I../../src/include -pthread -fno-strict-aliasing -g -O2 -MT openssl.lo -MD -MP -MF .deps/openssl.Tpo -c -o openssl.lo openssl.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/pkcs15init -I../../src/include -pthread -fno-strict-aliasing -g -O2 -MT openssl.lo -MD -MP -MF .deps/openssl.Tpo -c openssl.c -fPIC -DPIC -o .libs/openssl.o openssl.c:17:24: error: openssl/ec.h: No such file or directory Could you please send a config.log? Thanks ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.11.11 -rc1 release candidate available
Aktiv Co. Aleksey Samsonov: Hello, Kalev Lember: On 10/23/2009 04:39 PM, Andreas Jellinghaus wrote: Please give it a final test. http://www.opensc-project.org/files/opensc/testing/opensc-0.11.11-rc1.tar.gz Doesn't seem to compile with openssl-1.0 beta3 (distributed with Fedora 12, for example): /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/pkcs15init -I../../src/include -pthread -fno-strict-aliasing -g -O2 -MT openssl.lo -MD -MP -MF .deps/openssl.Tpo -c -o openssl.lo openssl.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/pkcs15init -I../../src/include -pthread -fno-strict-aliasing -g -O2 -MT openssl.lo -MD -MP -MF .deps/openssl.Tpo -c openssl.c -fPIC -DPIC -o .libs/openssl.o openssl.c:17:24: error: openssl/ec.h: No such file or directory Could you please send a config.log? Thanks openssl/opensslconf.h - #define OPENSSL_NO_EC Right? It is my bug. Thanks! ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc 0.11.11-pre1 with openssl 0.9.7 fix
Hello, Andreas Jellinghaus: here is a preview to 0.11.11, it contains a fix for compiling with openssl 0.9.7. please give it a try. I'm going to support GOST in tools, also I have some time to cleanup and fix warnings. Do we need a new branch? Thanks ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC 0.11.10-pre1 preview for testing
Hi, Andreas Jellinghaus: Hi, I made a preview in case we forgot something important. if you find some time, please test and report back. thanks! http://www.opensc-project.org/files/opensc/testing/opensc-0.11.10-pre1.tar.gz My tests are working. Thanks ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] changeset 3765 and sc_keycache_set_pin_name
Hello,
Aktiv Co. Aleksey Samsonov:
I think, we need to rollback:
Index: src/pkcs15init/keycache.c
===
--- src/pkcs15init/keycache.c (revision 3765)
+++ src/pkcs15init/keycache.c (working copy)
@@ -259,17 +259,11 @@
}
if (ref = 0) {
- int r;
/* Create the named PIN if it doesn't exist */
if (!(s = find_entry(path, SC_AC_CHV, ref, 0))) {
s = new_entry(path, SC_AC_CHV, ref);
if (s == NULL)
return SC_ERROR_OUT_OF_MEMORY;
-
- r = sc_keycache_get_key(path, SC_AC_CHV, -1,
s-value, MAX_SECRET);
- if(r 0)
- return SC_ERROR_OBJECT_NOT_FOUND;
- s-len = r;
}
/* Set the pin name */
---
Do you mind if I roll back? (for a new 0.11.* release)
Thanks
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] changeset 3765 and sc_keycache_set_pin_name
Hello, Andreas Jellinghaus wrote: Am Mittwoch 07 Oktober 2009 11:34:36 schrieb Aktiv Co. Aleksey Samsonov: I think, we need to rollback: propably the best idea. the old code was working, I don't understand why the new code is necessary (ok, I don't understand the whole keycache stuff I admit), so going back to the old code that worked for almost everyone ist the best plan I think. thanks a lot for all your testing and debugging! Thanks! Committed in revision 3771. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] changeset 3765 and sc_keycache_set_pin_name
Hello, Thanks for the answer. I think that this code is become obsolete and it needs to review, however I haven't detailed information about it. Martin Paljak: Hello Aleksey and others, Those of you who have used pkcs15init API, can anyone explain the way keycache works? There is some extra magic happening that does not only USER_PIN/SO_PIN - PIN value mapping but deals with naming PINs? What is this used for in keycache.c: libopensc/opensc.h:#define SC_AC_SYMBOLIC 0x0010 /* internal use only */ I've checked how card initialization works with KEYCACHE_DEBUG enabled but I can't really make conclusions as I've never directly worked with src/pkcs15init ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] changeset 3765 and sc_keycache_set_pin_name
Hello,
Andreas Jellinghaus:
Am Dienstag 06 Oktober 2009 16:06:52 schrieb Aktiv Co. Aleksey Samsonov:
Aktiv Co. Aleksey Samsonov:
Hello,
Rutoken initialization failed after
http://www.opensc-project.org/opensc/changeset/3765#file8
$ pkcs15-init -l Rutoken ECP User PIN -a 02 --pin 12345678 --puk
-P --so-pin 87654321 -F
Failed to store PIN: Requested object not found
=
new_entry - calloc
...
sc_keycache_get_key - search_key - if (s-len != 0) then error
Any idea?
Thanks.
Cause: http://www.opensc-project.org/opensc/changeset/3741
hmm. I'm not 100% sure how keycache works either. but
that code is bogus - int is returned from the function,
written into an unsigned int, which is then checked 0
which can't ever happen to unsigned int.
thus I fixed the code to get the value as int,
compare 0 and only write it into the unsigned int
len field if it is = 0.
Your patch is good, bug in
http://www.opensc-project.org/opensc/changeset/3741
Alternative:
Index: src/pkcs15init/keycache.c
===
--- src/pkcs15init/keycache.c (revision 3765)
+++ src/pkcs15init/keycache.c (working copy)
@@ -267,9 +267,8 @@
return SC_ERROR_OUT_OF_MEMORY;
r = sc_keycache_get_key(path, SC_AC_CHV, -1,
s-value, MAX_SECRET);
- if(r 0)
- return SC_ERROR_OBJECT_NOT_FOUND;
- s-len = r;
+ if (r 0)
+ s-len = r;
}
/* Set the pin name */
---
but I think this is not good idea.
I think, we need to rollback:
Index: src/pkcs15init/keycache.c
===
--- src/pkcs15init/keycache.c (revision 3765)
+++ src/pkcs15init/keycache.c (working copy)
@@ -259,17 +259,11 @@
}
if (ref = 0) {
- int r;
/* Create the named PIN if it doesn't exist */
if (!(s = find_entry(path, SC_AC_CHV, ref, 0))) {
s = new_entry(path, SC_AC_CHV, ref);
if (s == NULL)
return SC_ERROR_OUT_OF_MEMORY;
-
- r = sc_keycache_get_key(path, SC_AC_CHV, -1,
s-value, MAX_SECRET);
- if(r 0)
- return SC_ERROR_OBJECT_NOT_FOUND;
- s-len = r;
}
/* Set the pin name */
---
but no idea when keycache code is actually used.
can you post a backtrace? or does anyone else know?
Rainbow iKey 3000 initialization failed also:
$ pkcs15-init -E -C --so-pin 87654321 --so-puk
Using reader with a card: Rainbow iKey 3000
$ gdb pkcs15-init
(gdb) set args -l User PIN -a 02 --pin 12345678 --puk -P --so-pin
87654321 -F
(gdb) break sc_keycache_set_pin_name
(gdb) run
Starting program: /usr/local/bin/pkcs15-init -l User PIN -a 02 --pin
12345678 --puk -P --so-pin 87654321 -F
Breakpoint 2 at 0xb7e62649: file keycache.c, line 251.
Pending breakpoint sc_keycache_set_pin_name resolved
Using reader with a card: Rainbow iKey 3000
Breakpoint 2, sc_keycache_set_pin_name (path=0x8141bf8, ref=1, name=0)
at keycache.c:251
251 if (name 0 || name = SC_PKCS15INIT_NPINS)
(gdb) n
248 {
(gdb)
251 if (name 0 || name = SC_PKCS15INIT_NPINS)
(gdb)
256 if ((old = named_pin[name]) != NULL) {
(gdb)
261 if (ref = 0) {
(gdb)
264 if (!(s = find_entry(path, SC_AC_CHV, ref, 0))) {
(gdb)
265 s = new_entry(path, SC_AC_CHV, ref);
(gdb)
266 if (s == NULL)
(gdb) p/x *s
$2 = {next = 0x0, path = {value = {0x3f, 0x0, 0x50, 0x15, 0x0 repeats
12 times}, len = 0x4,
index = 0x0, count = 0x, type = 0x2}, type = 0x1, ref =
0x1, named_pin = 0x,
len = 0x0, value = {0x0 repeats 32 times}}
(gdb) bt
#0 sc_keycache_set_pin_name (path=0x8141bf8, ref=1, name=0) at
keycache.c:266
#1 0xb7e59618 in set_so_pin_from_card (p15card=Variable p15card is
not available.
) at pkcs15-lib.c:3213
#2 0xb7e5a775 in sc_pkcs15init_store_pin (p15card=0x8140dd0,
profile=0x813fe38, args=0xbfa9a1f8)
at pkcs15-lib.c:1017
#3 0x0804e142 in main (argc=Cannot access memory at address 0x0
) at pkcs15-init.c:716
(gdb) n
269 r = sc_keycache_get_key(path, SC_AC_CHV,
-1, s-value, MAX_SECRET);
(gdb) s
sc_keycache_get_key (path=0x8141bf8, type=1, ref=-1, key=0x8143254 ,
size=32) at keycache.c:222
(gdb)
222 if (!(s = search_key(path, type, ref)))
(gdb)
search_key (path=0x8141bf8, type=1, ref=-1) at keycache.c:126
126 if (type == SC_AC_SYMBOLIC) {
(gdb) n
123 {
(gdb)
126 if (type == SC_AC_SYMBOLIC) {
(gdb)
134 for (s = secret_cache; s; s = s-next) {
(gdb)
135 if (s-len != 0
(gdb) p/x *s
$3
Re: [opensc-devel] [opensc-commits] svn opensc changed [3757] add GOST R 34.10-2001 algorithm (only PKCS#11) by Aktiv Co.
Alon Bar-Lev: The pkcs11.h hank looks right. On Tue, Oct 6, 2009 at 8:08 AM, Andreas Jellinghaus a...@dungeon.inka.de wrote: When updating pkcs11.h, please sync with scut [1] Maintainer is at [2]. no worries, I will take care of that. is the patch ok otherwise? then I will apply it. Thanks very much! Before I had time to create a patch for them. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] changeset 3765 and sc_keycache_set_pin_name
Hello,
Rutoken initialization failed after
http://www.opensc-project.org/opensc/changeset/3765#file8
only (trunk/src/pkcs15init/keycache.c)
Example:
$ pkcs15-init -E -C --so-pin 87654321 --so-puk
OK!
$ pkcs15-init -l Rutoken ECP User PIN -a 02 --pin 12345678 --puk
-P --so-pin 87654321 -F
Failed to store PIN: Requested object not found
Breakpoint 2, sc_keycache_set_pin_name (path=0x8140590, ref=1, name=0)
at keycache.c:251
251 if (name 0 || name = SC_PKCS15INIT_NPINS)
(gdb) n
248 {
(gdb)
251 if (name 0 || name = SC_PKCS15INIT_NPINS)
(gdb)
256 if ((old = named_pin[name]) != NULL) {
(gdb)
261 if (ref = 0) {
(gdb)
264 if (!(s = find_entry(path, SC_AC_CHV, ref, 0))) {
(gdb)
265 s = new_entry(path, SC_AC_CHV, ref);
(gdb) s
new_entry (path=0x8140590, type=1, ref=1) at keycache.c:154
154 {
(gdb) n
157 s = (struct secret *) calloc(1, sizeof(*s));
(gdb) finish
Run till exit from #0 new_entry (path=0x8140590, type=1, ref=1) at
keycache.c:157
0xb7fa5703 in sc_keycache_set_pin_name (path=0x8140590, ref=1, name=0)
at keycache.c:265
265 s = new_entry(path, SC_AC_CHV, ref);
Value returned is $1 = (struct secret *) 0x8144790
(gdb) n
266 if (s == NULL)
(gdb)
269 r = sc_keycache_get_key(path, SC_AC_CHV,
-1, s-value, MAX_SECRET);
(gdb)
270 if(r 0)
(gdb)
292 }
(gdb) p r
$2 = -1407
=
new_entry - calloc
...
sc_keycache_get_key - search_key - if (s-len != 0) then error
Any idea?
Thanks.
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] [PATCH] Fix OpenSC PKCS#11 object grouping
Hello, Pierre Ossman: On Mon, 5 Oct 2009 11:28:12 +0300 Martin Paljak mar...@paljak.pri.ee wrote: On 05.10.2009, at 11:01, Pierre Ossman wrote: New attempt, this time against r3756 (r18006 was our internal repo, for those curious :)), as an attachment and without a signature on the mail. Hopefully everyone can read it this time. Applies and works for me. Glad to hear it. Does that also mean it will get merged in trunk? Oh yeah, I also forgot to mention that this patch also adds some more debug output. I found it helpful to see how the library chooses to associate objects, even though it currently only prints the index number. Maybe you can improve it so that it would log object/auth IDs? This would facilitate better debugging by looking at pkcs15-tool -D and then pkcs#11 debug log? Sure. Included patch gives this debug output: Thanks! Committed in revision 3769. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] changeset 3765 and sc_keycache_set_pin_name
Aktiv Co. Aleksey Samsonov: Hello, Rutoken initialization failed after http://www.opensc-project.org/opensc/changeset/3765#file8 $ pkcs15-init -l Rutoken ECP User PIN -a 02 --pin 12345678 --puk -P --so-pin 87654321 -F Failed to store PIN: Requested object not found = new_entry - calloc ... sc_keycache_get_key - search_key - if (s-len != 0) then error Any idea? Thanks. Cause: http://www.opensc-project.org/opensc/changeset/3741 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new opensc 0.11.* release?
Andreas Jellinghaus: Am Dienstag 06 Oktober 2009 10:17:08 schrieb Aktiv Co. Aleksey Samsonov: I want to make a few changes to cleanup. It takes me a few hours to do it. ok. no hurries, let me know when its done. a few days more or less before the next release doesn't matter. And there is a patch [PATCH] Fix OpenSC PKCS#11 object grouping [1]. If you want to apply it, I can do it. (src/pkcs11/framework-pkcs15.c was changed in revision 3757) thanks, please do. I forgot about those (a send patch was send as follow up). I finished this work, but have one problem (for Rutoken S/Rutoken ECP http://www.opensc-project.org/pipermail/opensc-devel/2009-October/012599.html) ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] add new public key algorithm (GOSTR3410)
Hello, Patch applied in revision 3757. Aleksey Samsonov wrote: Hello! I propose a patch for add GOST R 34.10-2001 algorithm (only PKCS#11 for the present). PKCS#11 and GOST: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d7.pdf This patch is first step. If it OK, I'll do: - cleanup code - add support to tools (pkcs15-init pkcs15-tool pkcs11-tool) - add off-card GOSTR3410 keypair generation - add GOST R 34.11-94 (CKM_GOSTR3410) Patch for trunk revision 3743 attached. Could you please add it? Thanks ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Changeset 3752: sc_check_apdu and datalen (lc)
Hello, Martin Paljak wrote: On 03.10.2009, at 15:19, Aleksey Samsonov wrote: Hello, Martin, could you explain please what for we need this change? http://www.opensc-project.org/opensc/changeset/3752/branches/martin/0.12/src/libopensc/apdu.c if SC_APDU_CASE_3_SHORT and apdu-datalen == 0 and apdu-lc == 0 then no error? Why? The reason is written here: http://itacns.corp.it/hg/itacns/file/adc0b2ceec86/patches/100-itacns.patch#l345 Thanks, I didn't see this. --- 346 +* The Italian CNS seems to want a 0 byte at the end of the command, 347 +* (a TLV structure with implicit tag, 0 length?) 348 +* This requires patching apdu.c as well. --- I think, here should be SC_APDU_CASE_1 and then SC_PROTO_T0, but if SC_PROTO_RAW then this is the task to handle in card reader driver (OpenCT). It made me think about it and I don't really know if it is OK or not, can't really decode ISO either with 100% clearity. Relevant copies from - http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_5_basic_organizations.aspx#chap5_3 - http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-4_annex-a.aspx#AnnexA_3 In case 3, the length Lc is not null; therefore the Lc field is present and the data field consists of the Lc subsequent bytes. I consider that Lc is not null definitely. I can't really judge if it is OK from ISO point of view or not (should not, but feels like could be). But if it makes a card work, I believe it is OK. I am left with the impression that a Lc byte in position B1 can be 0x00 to note that bytes B2..0 are 0 bytes of data. What do you think? Now it's clear, thanks. But still, I believe that the patch is not correct and this is the case of SC_APDU_CASE_1. We can make this card work only if we'll change code at level SC_PROTO_RAW, SC_PROTO_T0. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Changeset 3752: sc_check_apdu and datalen (lc)
Hello, Martin, could you explain please what for we need this change? http://www.opensc-project.org/opensc/changeset/3752/branches/martin/0.12/src/libopensc/apdu.c if SC_APDU_CASE_3_SHORT and apdu-datalen == 0 and apdu-lc == 0 then no error? Why? Thanks ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] pkcs15 init, problem with the profile
Hi, Example (This is a circumstance worthy of being noted) $ pkcs15-init -E -C ... ... No PIN objects ... Create DF (Example PKCS15-AppDF: (rutoken_ecp.profile) acl = *=NONE, DELETE=___CHV2___) ... Create PIN ... Create DF (Example PKCS15-AODF: (rutoken_ecp.profile) acl = *=NEVER, READ=NONE, UPDATE=___$SOPIN___, WRITE=___$SOPIN___, DELETE=___$SOPIN___) ... Aventra development: Hi! Hi We are trying to implement the pkcs15 initialization to the MyEID cards and can't get it to work. (...) Does anybody know where the problem might be? Does the other drivers work when initializing a card, and is the ACL set correctly? Yes it's working fine... at least for me. Perhaps can you send some logs Thanks for the offer, but we have now looked at the Rutoken ECP driver (thanks Aleksey) and noticed that we were missing some required implementations of some functions. We are currently doing the implementations, and hope to get it working soon. I will ask again if we still need some help with this. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new openct release?
Hi, shall we create a new openct release? There are almost no changes, but I'm for release. since 0.6.17 trunk got bsd fixes and rutoken S support. anything else we should wait for before creating a new release? Current trunk are working in RutokenS and RutokenECP tests. Andreas Jellinghaus: Hi, shall we create a new openct release? since 0.6.17 trunk got bsd fixes and rutoken S support. anything else we should wait for before creating a new release? Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] add new public key algorithm (GOSTR3410)
Hello,
Please, pay attention to (lest there be any doubt):
1.
src/libopensc/pkcs15-prkey.c:89:
static const struct sc_asn1_entry c_asn1_prkey[] = {
{ privateRSAKey, SC_ASN1_PKCS15_OBJECT, SC_ASN1_TAG_SEQUENCE
| SC_ASN1_CONS, SC_ASN1_OPTIONAL, NULL, NULL },
{ privateDSAKey, SC_ASN1_PKCS15_OBJECT, 2 | SC_ASN1_CTX |
SC_ASN1_CONS, SC_ASN1_OPTIONAL, NULL, NULL },
{ privateGOSTR3410Key, SC_ASN1_PKCS15_OBJECT, 3 | SC_ASN1_CTX
| SC_ASN1_CONS, SC_ASN1_OPTIONAL, NULL, NULL },
{ NULL, 0, 0, 0, NULL, NULL }
};
Is this tag (3 | SC_ASN1_CTX | SC_ASN1_CONS) permit/correct?
2.
src/pkcs11/openssl.c:103:
sc_pkcs11_register_openssl_mechanisms(struct sc_pkcs11_card *card)
{
#if OPENSSL_VERSION_NUMBER = 0x1000L
/* FIXME: see openssl-1.0.0-beta3/engines/ccgost/README.gost */
OPENSSL_config(NULL);
#endif
Is this the problem?
And also, I set the correct value CKA_GOSTR3410PARAMS in next patch.
Thanks
Aktiv Co. Aleksey Samsonov:
Hello!
I propose a patch for add GOST R 34.10-2001 algorithm (only PKCS#11 for
the present). PKCS#11 and GOST:
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d7.pdf
This patch is first step. If it OK, I'll do:
- cleanup code
- add support to tools (pkcs15-init pkcs15-tool pkcs11-tool)
- add off-card GOSTR3410 keypair generation
- add GOST R 34.11-94 (CKM_GOSTR3410)
Patch for trunk revision 3743 attached. Could you please add it?
Thanks
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] westcos_select_file and iso7816_select_file
Hello!
I propose a patch for src/libopensc/card-westcos.c if it's working.
src/libopensc/card-westcos.c:westcos_select_file:
309:case SC_PATH_TYPE_PATH:
apdu.p1 = 9;// Why is it needed? (9 ?)
336:if (file_out != NULL) {
apdu.resp = buf;
apdu.resplen = sizeof(buf);
apdu.le = 255;
} else {
apdu.resplen = 0;
apdu.le = 0;
apdu.cse = SC_APDU_CASE_3_SHORT;
}
Is this correct? (See
http://www.opensc-project.org/opensc/changeset/3700/trunk/src/libopensc
and
http://www.opensc-project.org/pipermail/opensc-devel/2009-June/012280.html)
Patch for trunk revision 3741 attached.
Thanks
diff -u -r opensc-trunk-r3742/src/libopensc/card-westcos.c
opensc-trunk-r3742_new/src/libopensc/card-westcos.c
--- opensc-trunk-r3742/src/libopensc/card-westcos.c 2009-09-12
07:04:48.0 +0400
+++ opensc-trunk-r3742_new/src/libopensc/card-westcos.c 2009-09-21
11:11:15.0 +0400
@@ -280,100 +280,11 @@
static int westcos_select_file(sc_card_t * card, const sc_path_t * in_path,
sc_file_t ** file_out)
{
- sc_context_t *ctx;
- sc_apdu_t apdu;
- u8 buf[SC_MAX_APDU_BUFFER_SIZE];
- u8 pathbuf[SC_MAX_PATH_SIZE], *path = pathbuf;
- int r, pathlen;
- sc_file_t *file = NULL;
- priv_data_t *priv_data = NULL;
- if (card-ctx-debug = 1)
- sc_debug(card-ctx, westcos_select_file\n);
- if (card == NULL)
- return SC_ERROR_INVALID_ARGUMENTS;
- priv_data = (priv_data_t *) card-drv_data;
- priv_data-file_id = 0;
- ctx = card-ctx;
- memcpy(path, in_path-value, in_path-len);
- pathlen = (int)in_path-len;
- sc_format_apdu(card, apdu, SC_APDU_CASE_4_SHORT, 0xA4, 0, 0);
- switch (in_path-type) {
- case SC_PATH_TYPE_FILE_ID:
- apdu.p1 = 0;
- if (pathlen != 2)
- return SC_ERROR_INVALID_ARGUMENTS;
- break;
- case SC_PATH_TYPE_DF_NAME:
- apdu.p1 = 4;
- break;
- case SC_PATH_TYPE_PATH:
- apdu.p1 = 9;
- if (pathlen == 2 memcmp(path, \x3F\x00, 2) == 0) {
- apdu.p1 = 0;
- }
+ priv_data_t *priv_data = (priv_data_t *) card-drv_data;
- else if (pathlen 2 memcmp(path, \x3F\x00, 2) == 0) {
- apdu.p1 = 8;
- pathlen -= 2;
- memcpy(path, in_path-value[2], pathlen);
- }
- break;
- case SC_PATH_TYPE_FROM_CURRENT:
- apdu.p1 = 9;
- break;
- case SC_PATH_TYPE_PARENT:
- apdu.p1 = 3;
- pathlen = 0;
- apdu.cse = SC_APDU_CASE_3_SHORT;
- break;
- default:
- return SC_ERROR_INVALID_ARGUMENTS;
- }
- apdu.p2 = 0;/* first record, return FCI */
- apdu.lc = pathlen;
- apdu.data = path;
- apdu.datalen = pathlen;
- if (file_out != NULL) {
- apdu.resp = buf;
- apdu.resplen = sizeof(buf);
- apdu.le = 255;
- } else {
- apdu.resplen = 0;
- apdu.le = 0;
- apdu.cse = SC_APDU_CASE_3_SHORT;
- }
- r = sc_transmit_apdu(card, apdu);
- if (r)
- return (r);
- if (file_out == NULL) {
- if (apdu.sw1 == 0x61)
- return 0;
- return sc_check_sw(card, apdu.sw1, apdu.sw2);
- }
- r = sc_check_sw(card, apdu.sw1, apdu.sw2);
- if (r)
- return (r);
- switch (apdu.resp[0]) {
- case 0x6F:
- file = sc_file_new();
- if (file == NULL)
- return SC_ERROR_OUT_OF_MEMORY;
- file-path = *in_path;
- if (card-ops-process_fci == NULL) {
- sc_file_free(file);
- return SC_ERROR_NOT_SUPPORTED;
- }
- if (apdu.resp[1] = apdu.resplen)
- card-ops-process_fci(card, file, apdu.resp + 2,
- apdu.resp[1]);
- *file_out = file;
- break;
- case 0x00: /* proprietary coding */
- return SC_ERROR_UNKNOWN_DATA_RECEIVED;
- default:
- return SC_ERROR_UNKNOWN_DATA_RECEIVED;
- }
- return 0;
+ assert(iso_ops iso_ops-select_file);
+ priv_data-file_id = 0;
+ return iso_ops-select_file(card, in_path, file_out);
}
static int _westcos2opensc_ac(u8 flag)
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] add new public key algorithm (GOSTR3410)
Hello! I propose a patch for add GOST R 34.10-2001 algorithm (only PKCS#11 for the present). PKCS#11 and GOST: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-30/pkcs-11v2-30m1-d7.pdf This patch is first step. If it OK, I'll do: - cleanup code - add support to tools (pkcs15-init pkcs15-tool pkcs11-tool) - add off-card GOSTR3410 keypair generation - add GOST R 34.11-94 (CKM_GOSTR3410) Patch for trunk revision 3743 attached. Could you please add it? Thanks opensc-trunk-r3743_gost3410.diff.bz2 Description: Binary data ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] SC_FUNC_RETURN and ctx-debug = level (/branches/martin/0.12)
Hi! Martin Paljak: Privet, On 14.09.2009, at 14:57, Aktiv Co. Aleksey Samsonov wrote: Patch for /branches/martin/0.12 revision 3732 is in attachment: rollback check (ctx-debug = level) in SC_FUNC_RETURN macro. Martin, could you please add it? Thanks for double-checking, applied/rolled back in r3733 In my patch http://www.opensc-project.org/pipermail/opensc-devel/attachments/20090914/45072333/attachment.txt there were not these http://www.opensc-project.org/opensc/changeset/3734 spaces. I'm trying to make these patches as convenient as possible to use. But it seemed that my patch was not convenient. Could you please tell because of what? So, either: - log level concept can be removed (0/1) altogether - or levels can be better defined and limited (3, not more than 4 levels with more well-defined purposes) and a SC_DEBUG macro with a level parameter created. code in log.c checks for debug level 0 so redundant = 1 style checks are scattered across files. Unlike long-running processes (servers) I have personally not found a reason to have some debug when I really need as much debug as possible from OpenSC, partly because I don't know which smaller than 9 number would give not too much garbage but enough information to be useful. In normal situations everything should just work and no debug log generated at all, but when things break it is always the best to have as much logs as possible. Thoughts? I consider, that different levels of debug prints are very useful. First of all developers need them, especially for developing of a new code, not for correcting mistakes. It is easy-to-use (handy) to see the log only from the level which you need or only of detail which you need. I think that in core files we have to more deliberate and better defined the output's level, but not to change the system and keep the levels up to 6. We may have defined from 0 to 6 levels, but for developers of card-drivers more than 6 levels may be allowed. Martin, if we replace everywhere sc_error to sc_debug, then how we provide details/reasons/tips to the user, and not just SC_ERROR_NOT_SUPPORTED (eg see src/pkcs15init/pkcs15-rtecp.c:rtecp_create_pin)? Thanks ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Fix: serial::len is used uninitialized in card-rtecp.c
Hello. BUG: serial-len is used uninitialized in rtecp_card_ctl:SC_CARDCTL_GET_SERIALNR (src/libopensc/card-rtecp.c) Could you please add attached patch? Thanks diff -u -r opensc-trunk-r3719/src/libopensc/card-rtecp.c opensc-trunk-r3719_new/src/libopensc/card-rtecp.c --- opensc-trunk-r3719/src/libopensc/card-rtecp.c 2009-06-28 07:26:54.0 +0400 +++ opensc-trunk-r3719_new/src/libopensc/card-rtecp.c 2009-09-15 14:10:49.0 +0400 @@ -639,6 +639,7 @@ apdu.resp = buf; apdu.resplen = sizeof(buf); apdu.le = sizeof(buf) - 2; + serial-len = sizeof(serial-value); break; case SC_CARDCTL_RTECP_GENERATE_KEY: if (!genkey_data) ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] westcos broke compiling without openssl
Andreas Jellinghaus: I haven't checked myself, but someone told me that opensc trunk isn't compiling without openssl. can anyone check? Version: 0.11.9-svn (trunk-r3720) User binaries: /usr/local/bin Configuration files: /usr/local/etc XSL stylesheets: /usr/share/sgml/docbook/xsl-stylesheets-1.49-1 man support: yes doc support: no zlib support:yes readline support:yes iconv support: yes OpenSSL support: no PC/SC support: no OpenCT support: no NSPlugin support:no PC/SC default provider: pinentry:/usr/bin/gpinentry Host:i686-pc-linux-gnu Compiler:gcc Preprocessor flags: Compiler flags: -fno-strict-aliasing -g -O2 Linker flags: Libraries: LTLIB_CFLAGS: LTLIB_LIBS: -lltdl READLINE_CFLAGS: READLINE_LIBS: -lreadline -lncurses ZLIB_CFLAGS: ZLIB_LIBS: -lz ICONV_CFLAGS: ICONV_LIBS: OPENSSL_CFLAGS: OPENSSL_LIBS:-lssl -lcrypto -ldl OPENCT_CFLAGS: OPENCT_LIBS: PCSC_CFLAGS: LIBASSUAN_CFLAGS: LIBASSUAN_LIBS: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../src/include -I../../src/common -DOPENSC_CONF_PATH=\/usr/local/etc/opensc.conf\ -fno-strict-aliasing -g -O2 -MT card-westcos.lo -MD -MP -MF .deps/card-westcos.Tpo -c card-westcos.c -fPIC -DPIC -o .libs/card-westcos.o card-westcos.c: In function 'westcos_get_crypte_challenge': card-westcos.c:772: error: 'DES_key_schedule' undeclared (first use in this function) card-westcos.c:772: error: (Each undeclared identifier is reported only once card-westcos.c:772: error: for each function it appears in.) card-westcos.c:772: error: expected ';' before 'ks1' card-westcos.c:780: error: 'const_DES_cblock' undeclared (first use in this function) card-westcos.c:780: error: expected expression before ')' token card-westcos.c:781: error: expected expression before ')' token card-westcos.c:782: error: expected expression before ')' token card-westcos.c: In function 'westcos_sign_decipher': card-westcos.c:1190: error: 'mem' undeclared (first use in this function) make[3]: *** [card-westcos.lo] Error 1 make[3]: Leaving directory `opensc-trunk-r3720/src/libopensc' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `opensc-trunk-r3720/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `opensc-trunk-r3720' make: *** [all] Error 2 ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] SC_FUNC_RETURN and ctx-debug = level (/branches/martin/0.12)
Hello!
Patch for /branches/martin/0.12 revision 3732 is in attachment: rollback
check (ctx-debug = level) in SC_FUNC_RETURN macro.
Martin, could you please add it?
Thanks
diff -u -r 0.12-r3732/src/libopensc/log.h 0.12-r3732_new/src/libopensc/log.h
--- 0.12-r3732/src/libopensc/log.h 2009-09-14 09:35:14.0 +0400
+++ 0.12-r3732_new/src/libopensc/log.h 2009-09-14 15:40:03.0 +0400
@@ -59,7 +59,9 @@
#define SC_FUNC_RETURN(ctx, level, r) do { \
int _ret = r; \
- sc_do_log(ctx, SC_LOG_TYPE_DEBUG, __FILE__, __LINE__, __FUNCTION__,
returning with: %d\n, _ret); \
+ if (ctx-debug = level) { \
+ sc_do_log(ctx, SC_LOG_TYPE_DEBUG, __FILE__, __LINE__,
__FUNCTION__, returning with: %d\n, _ret); \
+ } \
return _ret; \
} while(0)
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] unused parameters / -Wno-unused-parameter
Andreas Jellinghaus: I don't want to put __attribute__((unused)) everywhere to quiet gcc. Should we use -Wno-unused-parameters in configure when --enable-strict is added? that should quiet a lot of unreasonable warnings. I believe that the only true way to quiet a lot of unreasonable warnings deliberately use unused parameters: (void)unused_param1, (void)unused_param2;. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch adding support for westcos card.
Martin Paljak: On 11.09.2009, at 14:30, Aktiv Co. Aleksey Samsonov wrote: Hello. I propose a patch for src/libopensc/card-westcos.c to fix some compiler warnings and coding style and remove code duplication, but unfortunately I can't test it. Patch for trunk revision 3718. Were these the only functions that were overlapping ISO functionality? The functionality is the same. I also have questions about westcos-tool and if some of it's functions can't be implemented via pkcs15init interface (like -G)? Unfortunately I don't have many time to thoroughly look at remaining files for the present. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Patch adding support for westcos card.
François Leblanc:
Hi there,
Hello.
If someone can have a look and apply this patch or tell me correction to be
made,
.
--- src/libopensc/cards.h (revision 3716)^M
+++ src/libopensc/cards.h (working copy)^M
@@ -148,6 +148,8 @@^M
SC_CARD_TYPE_ENTERSAFE_FTCOS_PK_01C,
};
+extern sc_card_driver_t *sc_get_westcos_driver(void);
+extern sc_card_driver_t *sc_get_rutoken_driver(void);!!! That is
not correct.
extern sc_card_driver_t *sc_get_default_driver(void);
.
--- src/libopensc/ctx.c (revision 3716)^M
+++ src/libopensc/ctx.c (working copy)^M
@@ -51,6 +51,8 @@^M
static const struct _sc_driver_entry internal_card_drivers[] = {
/* legacy, the old name was etoken, so we keep that for a
while */
+ { westcos,(void *(*)(void)) sc_get_westcos_driver },
+ { rutoken,(void *(*)(void)) sc_get_rutoken_driver }, !!!
That is not correct.
{ cardos, (void *(*)(void)) sc_get_cardos_driver },
.
--- src/pkcs15init/Makefile.am (revision 3716)^M
+++ src/pkcs15init/Makefile.am (working copy)^M
@@ -24,7 +24,9 @@^M
rutoken.profile \
asepcos.profile \
entersafe.profile \
- rutoken_ecp.profile
+ rutoken_ecp.profile \
+ entersafe.profile \ !!! That is not correct.
+ westcos.profile
.
--- src/pkcs15init/pkcs15-init.h(revision 3716)^M
+++ src/pkcs15init/pkcs15-init.h(working copy)^M
@@ -389,6 +389,7 @@^M
extern int sc_pkcs15_create_pin_domain(sc_profile_t *, sc_card_t *,
const sc_pkcs15_id_t *, sc_file_t **);
+extern struct sc_pkcs15init_operations*
sc_get_pkcs15init_operations(void); !!! rename
sc_get_pkcs15init_operations to sc_pkcs15init_get_westcos_ops
extern struct sc_pkcs15init_operations *sc_pkcs15init_get_gpk_ops(void);
extern struct sc_pkcs15init_operations
*sc_pkcs15init_get_miocos_ops(void);
Thanks
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Fix:OpenCT:etc/openct.fdi and etc/openct.udev.modalias.in for Rutoken S
Hello,
Patch for trunk revision 1163 is in attachment: Add support for Rutoken
S in etc/openct.fdi and etc/openct.udev.modalias.in.
Could you please add it?
Thanks
diff -u -r openct-trunk-r1163/etc/openct.fdi
new/openct-trunk-r1163/etc/openct.fdi
--- openct-trunk-r1163/etc/openct.fdi 2009-04-29 11:17:17.0 +0400
+++ new/openct-trunk-r1163/etc/openct.fdi 2009-08-14 15:17:36.0
+0400
@@ -116,7 +116,13 @@
/match
/match
-
+ match key=usb.vendor_id int=0x0a89
+ match key=usb.product_id int=0x0020
+ merge key=smart_card_reader.openct_capable type=booltrue/merge
+ /match
+ /match
+
+
match key=usb.interface.class int=0x0b
merge key=smart_card_reader.openct_capable type=booltrue/merge
/match
diff -u -r openct-trunk-r1163/etc/openct.udev.modalias.in
new/openct-trunk-r1163/etc/openct.udev.modalias.in
--- openct-trunk-r1163/etc/openct.udev.modalias.in 2008-12-27
18:51:56.0 +0300
+++ new/openct-trunk-r1163/etc/openct.udev.modalias.in 2009-08-14
15:24:24.0 +0400
@@ -50,6 +50,8 @@
ENV{MODALIAS}==usb:v072Fp90D0*, RUN+=@udevdir@/openct_usb
# wbeiuu - driver not working yet
#ENV{MODALIAS}==usb:v104Fp0004*, RUN+=@udevdir@/openct_usb
+# Rutoken S
+ENV{MODALIAS}==usb:v0a89p0020*, RUN+=@udevdir@/openct_usb
# ePass3000
ENV{MODALIAS}==usb:v096ep0401*, RUN+=@udevdir@/openct_usb
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Fix: call sc_free_apps for pkcs15init-erase
Hello,
Bug (Rutoken S, Rutoken ECP):
$ pkcs15-init -E -C
$ pkcs15-init -E -C
$ opensc-explorer
OpenSC [3F00] cat 2f00
: 61 1F 4F 0C A0 00 00 00 63 50 4B 43 53 2D 31 35 a.O. ...cPKCS-15
0010: 50 09 52 75 74 6F 6B 65 6E 20 53 51 04 3F 00 50 P.Rutoken SQ.?.P
0020: 15 61 1F 4F 0C A0 00 00 00 63 50 4B 43 53 2D 31 .a.O. ...cPKCS-1
0030: 35 50 09 52 75 74 6F 6B 65 6E 20 53 51 04 3F 00 5P.Rutoken SQ.?.
0040: 50 15 00 00 00 00 00 00 00 00 00 00 00 00 00 00 P...
0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
OpenSC [3F00]
Could you please add attached patch?
Thanks
diff -u -r opensc-trunk-r3708/src/pkcs15init/pkcs15-rtecp.c
new/opensc-trunk-r3708/src/pkcs15init/pkcs15-rtecp.c
--- opensc-trunk-r3708/src/pkcs15init/pkcs15-rtecp.c2009-07-17
15:25:51.0 +0400
+++ new/opensc-trunk-r3708/src/pkcs15init/pkcs15-rtecp.c2009-07-17
15:34:12.0 +0400
@@ -39,9 +39,14 @@
*/
static int rtecp_erase(sc_profile_t *profile, sc_card_t *card)
{
+ int r;
+
if (!profile || !card)
return SC_ERROR_INVALID_ARGUMENTS;
- return sc_card_ctl(card, SC_CARDCTL_RTECP_INIT, NULL);
+ r = sc_card_ctl(card, SC_CARDCTL_RTECP_INIT, NULL);
+ if (r == SC_SUCCESS)
+ sc_free_apps(card);
+ return r;
}
static int create_sysdf(sc_profile_t *profile, sc_card_t *card, const char
*name)
diff -u -r opensc-trunk-r3708/src/pkcs15init/pkcs15-rutoken.c
new/opensc-trunk-r3708/src/pkcs15init/pkcs15-rutoken.c
--- opensc-trunk-r3708/src/pkcs15init/pkcs15-rutoken.c 2009-02-01
11:28:51.0 +0300
+++ new/opensc-trunk-r3708/src/pkcs15init/pkcs15-rutoken.c 2009-07-17
15:28:59.0 +0400
@@ -465,6 +465,8 @@
}
if (ret != SC_SUCCESS)
sc_error(card-ctx, Failed to erase: %s\n, sc_strerror(ret));
+ else
+ sc_free_apps(card);
return ret;
}
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenCT:ChipCard Interface Descriptor:dwFeatures and ISO/IEC 7816-12:2005
Hello,
Ludovic Rousseau:
It looks like your patch is correct. All the ICCD devices I know have
dwFeatures 0x = 0x840.
Patch applied in revision 1158
Thanks!
Could you please add patch for support Rutoken ECP tokens? (Patch for
trunk revision 1158 is in attachment) Thanks.
diff -u -r openct-trunk-r1158/etc/openct.conf.in
new/openct-trunk-r1158/etc/openct.conf.in
--- openct-trunk-r1158/etc/openct.conf.in 2009-02-06 12:33:08.0
+0300
+++ new/openct-trunk-r1158/etc/openct.conf.in 2009-07-16 16:25:20.0
+0400
@@ -134,6 +134,7 @@
usb:0b97/7772, # O2 Micro, Inc. Oz776 SmartCard Reader
usb:0bf8/1006, # fujitsu siemens 3.5 drive size reader
usb:0dc3/1004, # Athena Smartcard Solutions, Inc. ASEKey
+ usb:0a89/0030, # Aktiv Rutoken ECP
};
};
driver pertosmart1030 {
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenCT:ChipCard Interface Descriptor:dwFeatures and ISO/IEC 7816-12:2005
Hello,
ISO/IEC 7816-12:2005
7.2 The Class Specific Descriptor
Table 8 - Class specific descriptor for a USB-ICC
Offset: 40
Field: dwFeatures
Size:4
Value: 00840h
0002 00840h
0004 00840h
Description:
The value of the lower word (=0840) indicates
that the host will only send requests that are valid
for the USB-ICC.
The value of the upper word is the level of data
exchange with the USB-ICC:
h Character level exchanges
0002h Short APDU level exchanges
0004h Short and extended APDU level exchanges
But
Smart Card CCID version 1.1
5 Smart Card Device Class
5.1 Descriptor
Table 5.1-1 Smart Card Device Class Descriptors
for dwFeatures: 3) When a CCID doesn't declare the value 0010h the
frequency must be made via the manufacturer proprietary PC_to_RDR_Escape
command, same thing for the baud rate when the value 0020h is not
declared.
Patch for trunk revision 1157 is in attachment.
Thanks
diff -u -r openct-trunk-r1157/src/ifd/ifd-ccid.c
openct-trunk-r1157_new/src/ifd/ifd-ccid.c
--- openct-trunk-r1157/src/ifd/ifd-ccid.c 2009-02-26 11:58:13.0
+0300
+++ openct-trunk-r1157_new/src/ifd/ifd-ccid.c 2009-07-15 16:34:36.0
+0400
@@ -727,8 +727,13 @@
/* When a CCID doesn't declare the values 0010h and 0020h, the
* frequency or the baud rate must be made via manufacturer proprietary
* PC_to_RDR_Escape command. - ccid class specification v1.00
+ *
+ * The value of the lower word (=0840) indicates that the host will only
+ * send requests that are valid for the USB-ICC. - ISO/IEC 7816-12:2005
+ * 7.2/Table 8
*/
- if (~ccid.dwFeatures (0x10 | 0x20)) {
+ if ((ccid.dwFeatures 0x) != 0x0840
+~ccid.dwFeatures (0x10 | 0x20)) {
ct_error(ccid: required card initialization features missing);
free(st);
ifd_device_close(dev);
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] iso7816.c:set_security_env:OPERATION_DECIPHER
Hello,
Ludovic Rousseau:
maybe we can obsolete some of those card specific implementations,
if the only difference was this value?
Maybe. I had a look at card-setcos.c and the two
iso7816_set_security_env() functions are very similar. And they are
even more similar with the patch applied.
Any volunteer?
Patch for card-gemsafeV1.c is in attachment, but unfortunately I can't
test it. I don't have this device.
Thanks
diff -u -r opensc-trunk-r3698/src/libopensc/card-gemsafeV1.c
new/opensc-trunk-r3698/src/libopensc/card-gemsafeV1.c
--- opensc-trunk-r3698/src/libopensc/card-gemsafeV1.c 2008-09-10
17:50:39.0 +0400
+++ new/opensc-trunk-r3698/src/libopensc/card-gemsafeV1.c 2009-06-26
16:02:48.0 +0400
@@ -380,61 +380,25 @@
const struct sc_security_env *env,
int se_num)
{
- int r;
- struct sc_apdu apdu;
- u8 sbuf[SC_MAX_APDU_BUFFER_SIZE], *p = sbuf;
- u8 alg_ref = 0;
+ u8 alg_ref;
+ struct sc_security_env se_env = *env;
struct sc_context *ctx = card-ctx;
SC_FUNC_CALLED(ctx, 1);
- sc_format_apdu(card, apdu, SC_APDU_CASE_3_SHORT, 0x22, 0x41, 0);
- switch (env-operation) {
- case SC_SEC_OPERATION_DECIPHER:
- apdu.p2 = 0xB8;
- break;
- case SC_SEC_OPERATION_SIGN:
- apdu.p2 = 0xB6;
- break;
- default:
- return SC_ERROR_INVALID_ARGUMENTS;
- }
- apdu.le = 0;
-
- /* first step: set the algorithm reference */
- if (env-flags SC_SEC_ENV_ALG_REF_PRESENT)
- alg_ref = env-algorithm_ref 0xFF;
- else
- alg_ref = gemsafe_flags2algref(env);
- if (alg_ref) {
- /* set the algorithm reference */
- *p++ = 0x80;
- *p++ = 0x01;
- *p++ = alg_ref;
- } else
- sc_debug(ctx, unknown algorithm flags '%x'\n,
env-algorithm_flags);
- /* second step: set the key reference */
- if (env-flags SC_SEC_ENV_KEY_REF_PRESENT) {
- /* set the key reference */
- if (env-flags SC_SEC_ENV_KEY_REF_ASYMMETRIC)
- *p++ = 0x83;
- else
- *p++ = 0x84;
- *p++ = env-key_ref_len;
- memcpy(p, env-key_ref, env-key_ref_len);
- p += env-key_ref_len;
+ if (!(se_env.flags SC_SEC_ENV_ALG_REF_PRESENT)) {
+ /* set the algorithm reference */
+ alg_ref = gemsafe_flags2algref(se_env);
+ if (alg_ref) {
+ se_env.algorithm_ref = alg_ref;
+ se_env.flags |= SC_SEC_ENV_ALG_REF_PRESENT;
+ }
}
+ if (!(se_env.flags SC_SEC_ENV_ALG_REF_PRESENT))
+ sc_debug(ctx, unknown algorithm flags '%x'\n,
se_env.algorithm_flags);
-
- r = p - sbuf;
- apdu.lc = r;
- apdu.datalen = r;
- apdu.data = sbuf;
- apdu.resplen = 0;
-
- r = sc_transmit_apdu(card, apdu);
- SC_TEST_RET(card-ctx, r, APDU transmit failed);
- return sc_check_sw(card, apdu.sw1, apdu.sw2);
+ se_env.flags = ~SC_SEC_ENV_FILE_REF_PRESENT;
+ return iso_ops-set_security_env(card, se_env, se_num);
}
static int gemsafe_compute_signature(struct sc_card *card, const u8 * data,
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] iso7816.c:set_security_env:OPERATION_DECIPHER
Ludovic Rousseau:
2009/6/23 Andreas Jellinghaus a...@dungeon.inka.de:
maybe we can obsolete some of those card specific implementations,
if the only difference was this value?
Maybe. I had a look at card-setcos.c and the two
iso7816_set_security_env() functions are very similar. And they are
even more similar with the patch applied.
Any volunteer?
Patch for card-rtecp.c is attached. Could you please add it?
Thanks
diff -u -r opensc-trunk-r3698/src/libopensc/card-rtecp.c
new/opensc-trunk-r3698/src/libopensc/card-rtecp.c
--- opensc-trunk-r3698/src/libopensc/card-rtecp.c 2009-06-26
13:30:08.0 +0400
+++ new/opensc-trunk-r3698/src/libopensc/card-rtecp.c 2009-06-26
16:46:55.0 +0400
@@ -250,23 +250,18 @@
switch (in_path-type)
{
case SC_PATH_TYPE_FILE_ID:
- apdu.p1 = 0;
if (pathlen != 2)
SC_FUNC_RETURN(card-ctx, 1,
SC_ERROR_INVALID_ARGUMENTS);
break;
case SC_PATH_TYPE_PATH:
- apdu.p1 = 0x08;
if (pathlen = 2 memcmp(path, \x3F\x00, 2) == 0)
{
if (pathlen == 2)
- {
- /* only 3F00 supplied */
- apdu.p1 = 0;
- break;
- }
+ break; /* only 3F00 supplied */
path += 2;
pathlen -= 2;
}
+ apdu.p1 = 0x08;
break;
case SC_PATH_TYPE_DF_NAME:
case SC_PATH_TYPE_FROM_CURRENT:
@@ -286,11 +281,8 @@
apdu.le = sizeof(buf) - 2;
}
else
- {
- apdu.resplen = 0;
- apdu.le = 0;
apdu.cse = SC_APDU_CASE_3_SHORT;
- }
+
r = sc_transmit_apdu(card, apdu);
SC_TEST_RET(card-ctx, r, APDU transmit failed);
if (file_out == NULL)
@@ -383,49 +375,6 @@
SC_FUNC_RETURN(card-ctx, 2, r);
}
-static int rtecp_set_security_env(sc_card_t *card, const sc_security_env_t
*env,
- int se_num)
-{
- sc_apdu_t apdu;
- u8 buf[8], tmp, *p = buf;
- int r;
-
- (void)se_num; /* no warning */
- assert(card card-ctx env);
- sc_format_apdu(card, apdu, SC_APDU_CASE_3_SHORT, 0x22, 0x41, 0);
- switch (env-operation)
- {
- case SC_SEC_OPERATION_DECIPHER:
- apdu.p2 = 0xB8;
- break;
- case SC_SEC_OPERATION_SIGN:
- apdu.p2 = 0xB6;
- break;
- default:
- SC_FUNC_RETURN(card-ctx, 1, SC_ERROR_INVALID_ARGUMENTS);
- }
- if (env-flags SC_SEC_ENV_ALG_REF_PRESENT)
- {
- tmp = env-algorithm_ref 0xFF;
- sc_asn1_put_tag(0x80, tmp, sizeof(tmp), p, sizeof(buf) - (p -
buf), p);
- }
- if (env-flags SC_SEC_ENV_FILE_REF_PRESENT card-ctx-debug = 4)
- sc_debug(card-ctx, %s\n, SC_SEC_ENV_FILE_REF_PRESENT not
supported);
- if (env-flags SC_SEC_ENV_KEY_REF_PRESENT)
- sc_asn1_put_tag(env-flags SC_SEC_ENV_KEY_REF_ASYMMETRIC ?
0x83 : 0x84,
- env-key_ref, env-key_ref_len,
- p, sizeof(buf) - (p - buf), p);
-
- apdu.lc = p - buf;
- apdu.data = buf;
- apdu.datalen = p - buf;
-
- r = sc_transmit_apdu(card, apdu);
- SC_TEST_RET(card-ctx, r, APDU transmit failed);
- r = sc_check_sw(card, apdu.sw1, apdu.sw2);
- SC_FUNC_RETURN(card-ctx, 2, r);
-}
-
static int rtecp_rsa_cipher(sc_card_t *card, const u8 *data, size_t data_len,
u8 *out, size_t out_len, int sign)
{
@@ -828,7 +777,7 @@
rtecp_ops.verify = rtecp_verify;
rtecp_ops.logout = rtecp_logout;
/* restore_security_env */
- rtecp_ops.set_security_env = rtecp_set_security_env;
+ /* set_security_env */
rtecp_ops.decipher = rtecp_decipher;
rtecp_ops.compute_signature = rtecp_compute_signature;
rtecp_ops.change_reference_data = rtecp_change_reference_data;
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] Add new driver for Rutoken ECP tokens
Hi, I implemented support (currently only RSA) Rutoken ECP tokens (in Russian http://rutoken.ru/products/rutokends/) for OpenSC. Worked: ccid-1.3.10 + pcsc-lite-1.5.4 (pcsc-lite-1.5.2) + opensc Patch for trunk revision 3695 is in attachment. Initialize: $ pkcs15-init --erase-card --create-pkcs15 --so-pin 87654321 --so-puk $ pkcs15-init --store-pin --label User PIN --auth-id 02 --pin 12345678 --puk --so-pin 87654321 -F Rutoken ECP: T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 2.00 Cls=00(ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0a89 ProdID=0030 Rev= 1.00 S: Manufacturer=Aktiv S: Product=Rutoken ECP C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 2 Cls=0b(scard) Sub=00 Prot=00 Driver=usbfs E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms On-board cryptographic functions: - RSA (with RSA keys up to 2048 bits) - GOST R 34.10-2001 - GOST 34.11-94 - GOST 28147-89 - Key generation: ElGamal and Diffie-Hellman schemes - Random number generator Authentication: - 3 categories of owners: Administrator, User, Guest - 2 Global PIN-codes: Administrator and User - Local PIN-codes - Combined authentication - The possibility of simultaneous control of the access rights by the 7 Local PIN-codes File system features: - File structure of ISO/IEC 7816-4 - The level of subdirectory - limited by space available for file system - Number of file objects inside directory - up to 255, inclusive - Using files Rutoken Special File (RSF-files) to store keys and PIN-codes - Storage of private and symmetric keys, without the possibility of exports from device - Predefined directory for storing different kinds of key information (RSF-files) and automatic selection of the predefined directories - The total amount of memory for file structure - 64 kB Could you add patch if possible? Thanks opensc-trunk-r3695-rtecp.diff.gz Description: application/gzip ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] iso7816.c:set_security_env:OPERATION_DECIPHER
Hi,
I propose the attached patch for iso7816.c.
It looks like your patch is correct (according to ISO 7816-4 2003,
page 54, 7.5.11 MANAGE SECURITY ENVIRONMENT command)
Any objection from other list members?
almost every card driver has it's own set_security_env implementation,
so this change will not break any card, so it looks good to me.
maybe we can obsolete some of those card specific implementations,
if the only difference was this value?
Thanks
diff -u -r opensc-trunk-r3695/src/libopensc/iso7816.c
new/opensc-trunk-r3695/src/libopensc/iso7816.c
--- opensc-trunk-r3695/src/libopensc/iso7816.c 2008-12-27 19:15:30.0
+0300
+++ new/opensc-trunk-r3695/src/libopensc/iso7816.c 2009-06-23
15:46:32.0 +0400
@@ -449,7 +449,7 @@
} else {
apdu.resplen = 0;
apdu.le = 0;
- apdu.cse = SC_APDU_CASE_3_SHORT;
+ apdu.cse = (apdu.lc == 0) ? SC_APDU_CASE_1 :
SC_APDU_CASE_3_SHORT;
}
r = sc_transmit_apdu(card, apdu);
SC_TEST_RET(card-ctx, r, APDU transmit failed);
@@ -463,6 +463,8 @@
if (r)
SC_FUNC_RETURN(card-ctx, 2, r);
+ if (apdu.resplen = 1)
+ SC_FUNC_RETURN(card-ctx, 2, SC_ERROR_UNKNOWN_DATA_RECEIVED);
switch (apdu.resp[0]) {
case 0x6F:
file = sc_file_new();
@@ -473,7 +475,7 @@
sc_file_free(file);
SC_FUNC_RETURN(card-ctx, 2, SC_ERROR_NOT_SUPPORTED);
}
- if (apdu.resp[1] = apdu.resplen)
+ if ((size_t)apdu.resp[1] + 2 = apdu.resplen)
card-ops-process_fci(card, file, apdu.resp+2,
apdu.resp[1]);
*file_out = file;
break;
@@ -519,17 +521,21 @@
{
u8 *p = out;
u8 buf[64];
-
+
+ if (*outlen 2)
+ return SC_ERROR_BUFFER_TOO_SMALL;
*p++ = 0x6F;
p++;
buf[0] = (file-size 8) 0xFF;
buf[1] = file-size 0xFF;
- sc_asn1_put_tag(0x81, buf, 2, p, 16, p);
+ sc_asn1_put_tag(0x81, buf, 2, p, *outlen - (p - out), p);
if (file-type_attr_len) {
+ assert(sizeof(buf) = file-type_attr_len);
memcpy(buf, file-type_attr, file-type_attr_len);
- sc_asn1_put_tag(0x82, buf, file-type_attr_len, p, 16, p);
+ sc_asn1_put_tag(0x82, buf, file-type_attr_len,
+ p, *outlen - (p - out), p);
} else {
buf[0] = file-shareable ? 0x40 : 0;
switch (file-type) {
@@ -544,19 +550,23 @@
default:
return SC_ERROR_NOT_SUPPORTED;
}
- sc_asn1_put_tag(0x82, buf, 1, p, 16, p);
+ sc_asn1_put_tag(0x82, buf, 1, p, *outlen - (p - out), p);
}
buf[0] = (file-id 8) 0xFF;
buf[1] = file-id 0xFF;
- sc_asn1_put_tag(0x83, buf, 2, p, 16, p);
+ sc_asn1_put_tag(0x83, buf, 2, p, *outlen - (p - out), p);
/* 0x84 = DF name */
if (file-prop_attr_len) {
+ assert(sizeof(buf) = file-prop_attr_len);
memcpy(buf, file-prop_attr, file-prop_attr_len);
- sc_asn1_put_tag(0x85, buf, file-prop_attr_len, p, 18, p);
+ sc_asn1_put_tag(0x85, buf, file-prop_attr_len,
+ p, *outlen - (p - out), p);
}
if (file-sec_attr_len) {
+ assert(sizeof(buf) = file-sec_attr_len);
memcpy(buf, file-sec_attr, file-sec_attr_len);
- sc_asn1_put_tag(0x86, buf, file-sec_attr_len, p, 18, p);
+ sc_asn1_put_tag(0x86, buf, file-sec_attr_len,
+ p, *outlen - (p - out), p);
}
out[1] = p - out - 2;
@@ -664,14 +674,12 @@
int r, locked = 0;
assert(card != NULL env != NULL);
- sc_format_apdu(card, apdu, SC_APDU_CASE_3_SHORT, 0x22, 0, 0);
+ sc_format_apdu(card, apdu, SC_APDU_CASE_3_SHORT, 0x22, 0x41, 0);
switch (env-operation) {
case SC_SEC_OPERATION_DECIPHER:
- apdu.p1 = 0x81;
apdu.p2 = 0xB8;
break;
case SC_SEC_OPERATION_SIGN:
- apdu.p1 = 0x41;
apdu.p2 = 0xB6;
break;
default:
@@ -687,6 +695,7 @@
if (env-flags SC_SEC_ENV_FILE_REF_PRESENT) {
*p++ = 0x81;
*p++ = env-file_ref.len;
+ assert(sizeof(sbuf) - (p - sbuf) = env-file_ref.len);
memcpy(p, env-file_ref.value, env-file_ref.len);
p += env-file_ref.len;
}
@@ -696,6 +705,7 @@
else
*p++ = 0x84;
*p++ = env-key_ref_len;
+ assert(sizeof(sbuf) - (p - sbuf) = env-key_ref_len);
memcpy(p, env-key_ref, env-key_ref_len);
p += env-key_ref_len;
[opensc-devel] iso7816.c:set_security_env:OPERATION_DECIPHER
Hi,
ISO 7816-4: 7.5.11 MANAGE SECURITY ENVIRONMENT command:
Table 78 - P1
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
- - - 1 - - - - Secure messaging in command data field
- - 1 - - - - - Secure messaging in response data field
- 1 - - - - - - Computation, decipherment, internal authentication and
key agreement
1 - - - - - - - Verification, encipherment, external authentication and
key agreement
- - - - 0 0 0 1 SET
1 1 1 1 0 0 1 0 STORE
1 1 1 1 0 0 1 1 RESTORE
1 1 1 1 0 1 0 0 ERASE
* Any other value is reserved for future use by ISO/IEC JTC 1/SC 17.
Could you please clarify this:
src/libopensc/iso7816.c:669:iso7816_set_security_env:
case SC_SEC_OPERATION_DECIPHER:
apdu.p1 = 0x81; /* ??? */
apdu.p2 = 0xB8;
May be (patch is in attachment)?
Thanks
diff -u -r opensc-trunk-r3695/src/libopensc/iso7816.c
new/opensc-trunk-r3695/src/libopensc/iso7816.c
--- opensc-trunk-r3695/src/libopensc/iso7816.c 2008-12-27 19:15:30.0
+0300
+++ new/opensc-trunk-r3695/src/libopensc/iso7816.c 2009-06-22
12:08:14.0 +0400
@@ -667,7 +667,7 @@
sc_format_apdu(card, apdu, SC_APDU_CASE_3_SHORT, 0x22, 0, 0);
switch (env-operation) {
case SC_SEC_OPERATION_DECIPHER:
- apdu.p1 = 0x81;
+ apdu.p1 = 0x41;
apdu.p2 = 0xB8;
break;
case SC_SEC_OPERATION_SIGN:
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] BUG compiling with --disable-openssl
Hi! cardos-tool.c: In function 'cardos_format': cardos-tool.c:621: error: label 'erase_state' used but not defined cardos-tool.c:779: #ifdef ENABLE_OPENSSL ... erase_state: Thanks ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] patch for Rutoken
Alon Bar-Lev: On Monday 02 February 2009 12:35:20 Aktiv Co. Aleksey Samsonov wrote: also, do you know any resellers of the rutoken in eu? Unfortunately, Rutoken S is not exported from Russia. Why? The export of cryptography (GOST 28147-89) from Russia is a problem. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] patch for Rutoken
Alon Bar-Lev:
Can you please update the openct trunk so that Rutoken use the new
event interface?
OK, the updated patch is attached.
On 1/28/09, Alon Bar-Lev alon.bar...@gmail.com wrote:
Thanks.
Applied.
Thanks!
diff -u -r openct-0.6.15.trunk-r1127/src/ifd/ifd-rutoken.c
openct-0.6.15.trunk-r1127_new/src/ifd/ifd-rutoken.c
--- openct-0.6.15.trunk-r1127/src/ifd/ifd-rutoken.c 2008-12-31
20:37:50.0 +0300
+++ openct-0.6.15.trunk-r1127_new/src/ifd/ifd-rutoken.c 2009-01-28
17:34:12.0 +0300
@@ -32,15 +32,14 @@
ifd_device_params_t params;
ifd_debug(1, rutoken_open - %s, device_name);
- ifd_debug(1, %s:%d rutoken_open(), __FILE__, __LINE__);
- reader-name = ruToken driver;
+ reader-name = Rutoken S driver;
reader-nslots = 1;
if (!(dev = ifd_device_open(device_name)))
return -1;
if (ifd_device_type(dev) != IFD_DEVICE_TYPE_USB) {
- ct_error(ruToken driver: device %s is not a USB device,
device_name);
+ ct_error(Rutoken: device %s is not a USB device, device_name);
ifd_device_close(dev);
return -1;
}
@@ -48,7 +47,7 @@
params = dev-settings;
params.usb.interface = 0;
if (ifd_device_set_parameters(dev, params) 0) {
- ct_error(ruToken driver: setting parameters failed,
device_name);
+ ct_error(Rutoken: setting parameters failed, device_name);
ifd_device_close(dev);
return -1;
}
@@ -56,25 +55,24 @@
reader-device = dev;
dev-timeout = 1000;
- ifd_debug(1, %s:%d Checkpoint, __FILE__, __LINE__);
+ ifd_debug(1, rutoken_open - %s - successful, device_name);
return 0;
}
static int rutoken_activate(ifd_reader_t * reader)
{
- ifd_debug(1, %s:%d rutoken_activate(), __FILE__, __LINE__);
+ ifd_debug(1, called.);
return 0;
}
static int rutoken_deactivate(ifd_reader_t * reader)
{
- ifd_debug(1, %s:%d rutoken_deactivate(), __FILE__, __LINE__);
+ ifd_debug(1, called.);
return -1;
}
static int rutoken_getstatus(ifd_reader_t * reader, unsigned char *status)
{
- //ifd_debug(1, );
if(ifd_usb_control(reader-device, 0xc1, USB_ICC_GET_STATUS,
0, 0, status, 1, 1000) 0 )
return -1;
@@ -102,8 +100,6 @@
static int rutoken_card_reset(ifd_reader_t * reader, int slot, void *atr,
size_t atr_len)
{
- ifd_debug(1, %s:%d rutoken_card_reset(), __FILE__, __LINE__);
-
int nLen = 0, i;
ifd_debug(1, rutoken_card_reset, slot = %X, slot);
if(ifd_usb_control(reader-device, 0x41, USB_ICC_POWER_OFF, 0, 0, 0, 0,
-1) 0)
@@ -150,8 +146,6 @@
*/
static int rutoken_set_protocol(ifd_reader_t * reader, int nslot, int proto)
{
- ifd_debug(1, set protocol: {%d}, proto);
-
ifd_slot_t *slot;
ifd_protocol_t *p;
@@ -178,7 +172,6 @@
static int rutoken_card_status(ifd_reader_t * reader, int slot,
int *status)
{
- //ifd_debug(1, );
*status = IFD_CARD_PRESENT;
return 0;
}
@@ -397,6 +390,33 @@
return -1;
}
+static int rutoken_get_eventfd(ifd_reader_t * reader)
+{
+ ifd_debug(1, called.);
+
+ return ifd_device_get_eventfd(reader-device);
+}
+
+static int rutoken_event(ifd_reader_t * reader, int *status, size_t
status_size)
+{
+ (void)reader;
+ (void)status;
+ (void)status_size;
+
+ ifd_debug(1, called.);
+
+ return 0;
+}
+
+static int rutoken_error(ifd_reader_t * reader)
+{
+ (void)reader;
+
+ ifd_debug(1, called.);
+
+ return IFD_ERROR_DEVICE_DISCONNECTED;
+}
+
static struct ifd_driver_ops rutoken_driver;
void ifd_rutoken_register(void)
@@ -408,6 +428,9 @@
rutoken_driver.card_status = rutoken_card_status;
rutoken_driver.set_protocol = rutoken_set_protocol;
rutoken_driver.transparent = rutoken_transparent;
+ rutoken_driver.get_eventfd = rutoken_get_eventfd;
+ rutoken_driver.event = rutoken_event;
+ rutoken_driver.error = rutoken_error;
ifd_driver_register(rutoken, rutoken_driver);
}
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] patch for Rutoken
Hello. I propose the attached patch for Rutoken S codes. Changes: - use PKCS#15 (not builtin PKCS#15 emulator) - rutoken.profile (add privdata) - correct using ACL - correct erase procedure bin0MSZ0ZoczJ.bin Description: application/gzip ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] new releases before xmas?
not sure if they follow this mailing list. pkcs11-tool for Rutoken S is not yet supported (have problems). pkcs15-tool is supported (almost all options). Andreas Jellinghaus: Hi Pavel, can you check with the rutoken authors? not sure if they follow this mailing list. I neither have a token nor documentation (nor time right now), so I can't be of any help. rutoken is a new driver, so if it is not working 100% so far, that is not a show stopper for the next release. but of course it would be much better, if it worked. * card-rutoken.c: Support for Rutoken cards * * Copyright (C) 2007 Pavel Mironchik ruto...@rutoken.ru * Copyright (C) 2007 Eugene Hermann ruto...@rutoken.ru I hope they can help! Regards, Andreas ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] opensc-explorer double free - fix
Aktiv Co. Aleksey Samsonov: Examples: $ opensc-explorer OpenSC Explorer version 0.11.4-svn OpenSC [3F00] cat only working EFs may be read OpenSC [3F00] cat only working EFs may be read opensc-explorer: sc.c:492: sc_file_free: Assertion `sc_file_valid(file)' failed. Aborted Doesn't it need to be fixed? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] SIGSEGV print_tags_recursive - fix
Patch opensc-0.11.4.trunk-r3502-fix-segv_print_tags_asn1.diff (for trunk
trunk revision 3502) is draft.
Example 1 (SIGSEGV):
OpenSC Explorer version 0.11.4-svn
OpenSC [3F00] cd ff00
OpenSC [3F00/FF00] asn1 0001
Printing tags for buffer of length 512
[Switching to Thread -1211906368 (LWP 25131)]
Breakpoint 1, print_tags_recursive (buf0=0x8066060 , buf=0x8066060 ,
buflen=512, depth=0)
at asn1.c:219
219 size_t bytesleft = buflen;
(gdb) p *(char[512]*)buf
$21 = '\0' repeats 511 times
(gdb) bt
#0 print_tags_recursive (buf0=0x8066060 , buf=0x8066060 ,
buflen=512, depth=0) at asn1.c:219
#1 0xb7dc52d8 in sc_asn1_print_tags (buf=0x8066060 , buflen=512) at
asn1.c:292
#2 0x0804cd9e in do_asn1 (argc=1, argv=0xbfb95864) at
opensc-explorer.c:1571
#3 0x0804d4af in main (argc=1, argv=0xbfb95974) at opensc-explorer.c:1780
(gdb) until 230
print_tags_recursive (buf0=0x8066060 , buf=0x8066060 , buflen=512,
depth=0) at asn1.c:230
230 r = sc_asn1_read_tag(tagp, bytesleft, cla,
tag, len);
(gdb) p/x cla
$22 = 0xb7eea718
(gdb) p/x tag
$23 = 0xb7d9f8c8
(gdb) s
sc_asn1_read_tag (buf=0xbfb9572c, buflen=512, cla_out=0xbfb95734,
tag_out=0xbfb95730, taglen=0xbfb95728)
at asn1.c:56
56 const u8 *p = *buf;
(gdb)
57 size_t left = buflen, len;
(gdb)
60 if (left 2)
(gdb)
62 *buf = NULL;
(gdb)
63 if (*p == 0xff || *p == 0)
(gdb)
65 return SC_SUCCESS;
(gdb)
111 }
(gdb)
print_tags_recursive (buf0=0x8066060 , buf=0x8066060 , buflen=512,
depth=0) at asn1.c:231
231 if (r != SC_SUCCESS) {
(gdb) p/x cla
$24 = 0xb7eea718
(gdb) p/x tag
$25 = 0xb7d9f8c8
(gdb) n
235 hlen = tagp - p;
(gdb)
236 if (cla == 0 tag == 0) {
(gdb)
240 for (i = 0; i depth; i++) {
(gdb)
244 printf(%02X %s: tag 0x%02X, length %3d: ,
(gdb)
Program received signal SIGSEGV, Segmentation fault.
0xb7dc5108 in print_tags_recursive (buf0=0x8066060 , buf=0x8066060 ,
buflen=512, depth=0)
at asn1.c:244
Example 2 (Illegal length!):
$ opensc-explorer
OpenSC Explorer version 0.11.4-svn
OpenSC [3F00] cd ff00
OpenSC [3F00/FF00] asn1 0001
Printing tags for buffer of length 512
30 Univ: tag 0x10, length 120: SEQUENCE
30 Univ: tag 0x10, length 39: SEQUENCE
0C Univ: tag 0x0C, length 30: UTF8STRING [Sample Private Key
(Aktiv Co.)]
03 Univ: tag 0x03, length 2: BIT STRING [11]
04 Univ: tag 0x04, length 1: OCTET STRING [02]
30 Univ: tag 0x10, length 55: SEQUENCE
04 Univ: tag 0x04, length 42: OCTET STRING
[4944206F662070616972206F66205253412073616D706C65206B6579732028416B74697620436F2E2900]
03 Univ: tag 0x03, length 2: BIT STRING [100]
03 Univ: tag 0x03, length 2: BIT STRING [11101]
02 Univ: tag 0x02, length 1: INTEGER [0]
A0 Cntx: tag 0x00, length 0:
A1 Cntx: tag 0x01, length 18:
30 Univ: tag 0x10, length 16: SEQUENCE
30 Univ: tag 0x10, length 10: SEQUENCE
04 Univ: tag 0x04, length 8: OCTET STRING [3F00FF00]
02 Univ: tag 0x02, length 2: INTEGER [512]
30 Univ: tag 0x10, length 120: Illegal length!
OpenSC [3F00/FF00] cat 0001
: 30 78 30 27 0C 1E 53 61 6D 70 6C 65 20 50 72 69
0010: 76 61 74 65 20 4B 65 79 20 28 41 6B 74 69 76 20
0020: 43 6F 2E 29 03 02 06 C0 04 01 02 30 37 04 2A 49
0030: 44 20 6F 66 20 70 61 69 72 20 6F 66 20 52 53 41
0040: 20 73 61 6D 70 6C 65 20 6B 65 79 73 20 28 41 6B
0050: 74 69 76 20 43 6F 2E 29 00 03 02 05 20 03 02 03
0060: B8 02 01 00 A0 00 A1 12 30 10 30 0A 04 08 3F 00
0070: FF 00 00 00 00 00 02 02 02 00 00 00 00 00 00 00
0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
...
01F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
diff -u -r opensc-0.11.4.trunk-r3502/src/libopensc/asn1.c
opensc-0.11.4.trunk-r3502_new/src/libopensc/asn1.c
--- opensc-0.11.4.trunk-r3502/src/libopensc/asn1.c 2008-02-29
15:37:46.0 +0300
+++ opensc-0.11.4.trunk-r3502_new/src/libopensc/asn1.c 2008-04-28
17:11:00.0 +0400
@@ -223,7 +223,7 @@
const u8 *p = buf;
while (bytesleft = 2) {
- unsigned int cla, tag, hlen;
+ unsigned int cla = 0, tag = 0, hlen;
const u8 *tagp = p;
size_t len;
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenCT SIGSEGV mmap - fix
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210038592 (LWP 2240)] 0xb7e6e5b4 in memset () from /lib/tls/libc.so.6 (gdb) backtrace #0 0xb7e6e5b4 in memset () from /lib/tls/libc.so.6 #1 0xb7f4c28e in ct_status_alloc_slot (num=0xbffaed24) at status.c:144 #2 0x0804a5ac in main (argc=5, argv=Cannot access memory at address 0x5 ) at ifdhandler.c:119 openct/src/ct/status.c: ct_map_status: 55: addr = mmap(NULL, *size, prot, MAP_SHARED, fd, 0); !!! *size == 0 ct_status_alloc_slot: 108:info = (ct_info_t *) ct_map_status(O_RDWR, size); 109:if (info == NULL) 110:return NULL; !!! Linux-2.6.x: info == -1 // (info == MAP_FAILED) !!! Linux-2.4.x: info == NULL 143:memset(info[*num], 0, sizeof(ct_info_t)); !!! SIGSEGV http://www.opengroup.org/onlinepubs/95399/functions/mmap.html : RETURN VALUE Upon successful completion, the mmap() function shall return the address at which the mapping was placed ( pa); otherwise, it shall return a value of MAP_FAILED and set errno to indicate the error. linux/mm/mmap.c: do_mmap_pgoff: Linux-2.4.36: 414: if (!len) 415: return addr; http://git.kernel.org/?p=linux/kernel/git/wtarreau/linux-2.4.git;a=blob;f=mm/mmap.c;h=536510a249374f4b1cc0753a0dfb4cb44c741eff;hb=89daf14f822d33ecb1ea5681fd968bd6a46cfc8c#l415 Linux-2.6.25: 917: if (!len) 918: return -EINVAL; http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=mm/mmap.c;h=a32d28ce31cda697aff68fdc6c939560096e3a50;hb=4b119e21d0c66c22e8ca03df05d9de623d0eb50f#l918 diff -u -r openct-0.6.14/src/ct/status.c new/openct-0.6.14/src/ct/status.c --- openct-0.6.14/src/ct/status.c 2007-05-26 01:11:46.0 +0400 +++ new/openct-0.6.14/src/ct/status.c 2007-11-08 14:54:54.0 +0300 @@ -53,6 +53,8 @@ prot |= PROT_WRITE; addr = mmap(NULL, *size, prot, MAP_SHARED, fd, 0); + if (addr == MAP_FAILED) + addr = NULL; done:close(fd); return addr; ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC svn build on Windows rutoken issues - fix
Patch for trunk revision 3489 is in attachment. opensc-0.11.4.trunk-r3489-fix_msvc_build.diff.gz Description: application/gzip ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenSC svn build on Windows rutoken issues
Alon Bar-Lev: Much better!!! Can you please rebase and send all your modifications as single patch? Patch for trunk revision 3477 is in attachment. opensc-0.11.4.trunk-r3477-0.11.4.trunk-r3477_rutoken-0.3.3.diff.gz Description: application/gzip ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC svn build on Windows rutoken issues
Alon Bar-Lev: Patch opensc-0.11.4.trunk-r3476_rutoken-0.3.2_2.diff (for opensc-0.11.4.trunk-r3476-0.11.4.trunk-r3476_rutoken-0.3.2.diff) is draft. This patch solves the problem with exported functions. (Instead of pkcs15-prkey-rutoken.c it'll be rutoken-prkey.h). If this solution is better than previous one, but it's inappropriate to use line '#include ../libopensc/rutoken-prkey.h' in the file src/pkcs15init/pkcs15-rutoken.c, then I can fully split the file rutoken-prkey.h. Having code in include file is worse. Please try to convert the rutoken specific stuff into pkcs15 data structures. Patch opensc-0.11.4.trunk-r3477_rutoken-0.3.2_3.diff (for opensc-0.11.4.trunk-r3476-0.11.4.trunk-r3476_rutoken-0.3.2.diff) is draft2. opensc-0.11.4.trunk-r3477_rutoken-0.3.2_3.diff.gz Description: application/gzip ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenSC svn build on Windows rutoken issues
On Fri, Apr 11, 2008 at 11:40 AM, Aktiv Co. Aleksey Samsonov wrote: We are going to release tested patch for the current version of your code in a couple of days. It fixes a number of bugs in Rutoken code and changes card-rutoken.c file to meet OpenSC coding standards. Patch for trunk revision 3476 is in attachment. I believe that whitespace changes to existing code in this patch is are necessary because otherwise some files will not be formatted properly. Alon Bar-Lev: Please also explain why the pkcs15-prkey-rutoken.c is needed, there is not prkey specific file for any other card. This file is necessary to avoid redoubling of code. Alon Bar-Lev: Also at libopensc.exports you can see that only rutoken has card specific exports, this should also be modified. Patch opensc-0.11.4.trunk-r3476_rutoken-0.3.2_2.diff (for opensc-0.11.4.trunk-r3476-0.11.4.trunk-r3476_rutoken-0.3.2.diff) is draft. This patch solves the problem with exported functions. (Instead of pkcs15-prkey-rutoken.c it'll be rutoken-prkey.h). If this solution is better than previous one, but it's inappropriate to use line '#include ../libopensc/rutoken-prkey.h' in the file src/pkcs15init/pkcs15-rutoken.c, then I can fully split the file rutoken-prkey.h. opensc-0.11.4.trunk-r3476-0.11.4.trunk-r3476_rutoken-0.3.2.diff.gz Description: application/gzip opensc-0.11.4.trunk-r3476_rutoken-0.3.2_2.diff.gz Description: application/gzip ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
