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 >> 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
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] 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 check parameters for NULL_PTR
Hi Martin,
Martin Paljak:
> On 08.12.2009, at 14:09, Aktiv Co. Aleksey Samsonov wrote:
>
>>> Any idea?
>> C_CreateObject, C_FindObjectsInit, C_GenerateKeyPair, C_UnwrapKey :
>>
>> 1) if (pTemplate == NULL_PTR && ulCount > 0) { rv = CKR_ARGUMENTS_BAD;
>>
>> vs
>>
>> 2) if (pTemplate == NULL_PTR || ulCount == 0) { rv = CKR_ARGUMENTS_BAD;
>
> Would calling with an empty template make sense?
(for C_CreateObject, C_FindObjectsInit, C_GenerateKeyPair, C_UnwrapKey)
if (pTemplate == NULL_PTR) then
2. already error (CKR_ARGUMENTS_BAD)
or
1. no for the present and to try further (that'll do
CKR_TEMPLATE_INCOMPLETE, CKR_OK and etc)
___
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
> Any idea?
C_CreateObject, C_FindObjectsInit, C_GenerateKeyPair, C_UnwrapKey :
1) if (pTemplate == NULL_PTR && ulCount > 0) { rv = CKR_ARGUMENTS_BAD;
vs
2) if (pTemplate == NULL_PTR || ulCount == 0) { rv = CKR_ARGUMENTS_BAD;
?
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel
[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
[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 (r
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?
Viktor TARASOV: > Another possible, 'alternative to alternative' scheme is to use C_SetPin() > in the specific context (after C_Login(CKU_SPECIFIC_CONTEXT)). > > So, in CKU_USER_PIN context C_SetPin() is used to change user PIN, > in CKU_CONTEXT_SPECIFIC it's used to unblock user PIN. > > Afais, CKU_CONTEXT_SPECIFIC is not actually used. I think, this is a very good idea. ___ 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?
Pierre Ossman: > On Wed, 2 Dec 2009 12:48:56 +0300 > "Aktiv Co. Aleksey Samsonov" wrote: >> 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 >> > > I see. Does anyone have any comments on the general principle though > before I start putting time into updating to trunk? > +/* This assumes that either: > + * (a) We have a cached SO PIN > + * (b) We have previously logged in as CKU_SO and the card > + * will therefore accept the unblock request. */ > +rc = sc_pkcs15_unblock_pin(fw_data->p15_card, pin, > + slot_data->pin[CKU_SO].value, > + slot_data->pin[CKU_SO].len, > + pPin, ulPinLen); What are the cards support it? (sc_pkcs15_unblock_pin with "puk" is CKU_SO and "newpin" is pPin) How many of them from the total number working in OpenSC? Alternative sheme: Reimplement "reset_retry_counter" or "pin_cmd -> SC_PIN_CMD_UNBLOCK" that it no use "puk" and "newpin", it merely send apdu with ref_unblock_pin. At that time C_Login(..., CKU_SO, ...); C_InitPIN(..., "", 0) -> sc_pkcs15_unblock_pin(..., NULL, 0, "", 0); But, I don't like misuse of C_InitPIN concept. ___ 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: > On Wed, 2 Dec 2009 12:48:56 +0300 > "Aktiv Co. Aleksey Samsonov" wrote: >> Pierre Ossman: >>> 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 > > I see. Does anyone have any comments on the general principle though > before I start putting time into updating to trunk? What are your going to do with cache_pin and pkcs15_slot_data::pin ? ___ 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] 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
[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:
>
>>> 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:
>>> 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: > 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. Furthermore http://www.opensc-project.org/opensc/browser/trunk/src/pkcs15init/profile.c#L564: idx = id->value[id->len-1]; /* choice file ID */ it may be a surprise to use. ___ 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 "" 2>&1 > 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=
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 -> #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 -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-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:
> 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 }, len = 0x4,
index = 0x0, count = 0x, type = 0x2}, type = 0x1, ref =
0x1, named_pin = 0x,
len = 0x0, value = {0x0 }}
(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_keyca
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] 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] 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] [PATCH] Fix OpenSC PKCS#11 object grouping
Hello, Pierre Ossman: > On Mon, 5 Oct 2009 11:28:12 +0300 > Martin Paljak 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
[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] new opensc 0.11.* release?
Hello, Andreas Jellinghaus: > Am Samstag 03 Oktober 2009 10:05:37 schrieb Andreas Jellinghaus: >> Hi, >> >> shall we create a new opensc 0.11.* release? things to wait for >> before we create such a release? > > Aleksey commited the latest rutoken changes for GOST algorithm, > I added the pending patches for westcos driver and GemsafeV2 > emulation. Is there anything else? Shall we create a new 0.11.* > release? I want to make a few changes to cleanup. It takes me a few hours to do it. 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 [1] http://www.opensc-project.org/pipermail/opensc-devel/2009-October/012580.html ___ 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 [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 > 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
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] 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
[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
Re: [opensc-devel] Patch adding support for Aventra MyEID card
Hello. Martin Paljak: > On 17.09.2009, at 10:51, Andreas Jellinghaus wrote: >> also shall we create a new 0.11 release for the two new drivers > Why not? I think that's a great idea. >> or go straight for a new 0.12 release? > I think it can wait a bit and hope that maybe we can do more cleanup > work. I think it can wait and needs more cleanup and testing. ___ 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
[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] 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
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.
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. Thanks Andreas Jellinghaus: Am Freitag 11 September 2009 08:47:38 schrieb François Leblanc: Hello, This new patch with corrections noticed by Andreas, Thanks, commited to trunk with below changes. Regards, Andreas opensc-trunk-r3718_new.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] 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.
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 @@
-
+
+
+ true
+
+
+
+
true
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
Re: [opensc-devel] new opensc preview release
Hello, Andreas Jellinghaus: > http://www.opensc-project.org/files/opensc/testing/opensc-0.11.9-pre1.tar.gz > > this preview has all the latest changes. please give it a try > and let us know if it works for your, or what doesn't work. This preview are working in RutokenS and RutokenECP tests. Thanks ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] New releases?
Hello, Andreas Jellinghaus: > are there other changes/patches/projects that I forgot > and that need to be applied / need new releases too? Could you please apply the pkcs15-rutoken.c and pkcs15-rtecp.c patches I sent on 7/17/2009 to the next release? Thanks ___ 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
Aktiv Co. Aleksey Samsonov: Yes, this is not needed for linux, but ifd_scan_usb's in: src/ifd/sys-bsd.c:533: src/ifd/sys-bsd.c:597: src/ifd/sys-solaris.c:572: src/ifd/sys-sunray.c:347: /* FIXME: if we don't find a driver with vendor/product * then check for the interface type (ccid) and use * driver ccid... */ Patch for trunk revision 1159 is in attachment: corrected comment in src/ifd/sys-linux.c Thanks diff -u -r openct-trunk-r1159/src/ifd/sys-linux.c new/openct-trunk-r1159/src/ifd/sys-linux.c --- openct-trunk-r1159/src/ifd/sys-linux.c 2009-02-26 11:58:13.0 +0300 +++ new/openct-trunk-r1159/src/ifd/sys-linux.c 2009-07-17 13:52:37.0 +0400 @@ -502,7 +502,7 @@ id.val[0] = dev->descriptor.idVendor; id.val[1] = dev->descriptor.idProduct; - /* FIXME: if we don't find a driver with vendor/product + /* if we don't find a driver with vendor/product * then check for the interface type (ccid) and use * driver ccid... */ ___ 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
openct-control init -> ifd_scan_usb -> ifd_driver_for_id
but
openct-control attach ... -> ifd_driver_for_id
src/tools/openct-control.c:200:
if (!(driver = ifd_driver_for_id(&id))) {
/* fall back to ccid driver */
driver = "ccid";
}
This patch need only for ifd_scan_usb ("openct-control init") in not linux.
Alon Bar-Lev:
> This is strange... As the default is ccid for all.
>
> On Fri, Jul 17, 2009 at 11:50 AM, Aktiv Co. Aleksey
> Samsonov wrote:
>> Hello,
>>
>> Alon Bar-Lev:
>>> Why is it needed?
>>> Doesn't it report itself as CCID device?
>> Yes, this is not needed for linux, but ifd_scan_usb's in:
>> src/ifd/sys-bsd.c:533:
>> src/ifd/sys-bsd.c:597:
>> src/ifd/sys-solaris.c:572:
>> src/ifd/sys-sunray.c:347:
>>
>> /* FIXME: if we don't find a driver with vendor/product
>> * then check for the interface type (ccid) and use
>> * driver ccid... */
___
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, Andreas Jellinghaus: > Am Donnerstag 16 Juli 2009 14:35:19 schrieb Aktiv Co. Aleksey Samsonov: >> Could you please add patch for support Rutoken ECP tokens? (Patch for >> trunk revision 1158 is in attachment) Thanks. > > Could you check the other files in etc/ directory and modify them too? > > Most files only need new entries if the generic smart card rule doesn't > match the token (interface class 0xb). I checked certainly the other files in etc/ directory. Those files don't need to change. T: Bus=02 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 9 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=(none) E: Ad=81(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms Thanks ___ 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, Alon Bar-Lev: > Why is it needed? > Doesn't it report itself as CCID device? Yes, this is not needed for linux, but ifd_scan_usb's in: src/ifd/sys-bsd.c:533: src/ifd/sys-bsd.c:597: src/ifd/sys-solaris.c:572: src/ifd/sys-sunray.c:347: /* FIXME: if we don't find a driver with vendor/product * then check for the interface type (ccid) and use * driver ccid... */ > On Thu, Jul 16, 2009 at 3:35 PM, Aktiv Co. Aleksey Samsonov > wrote: >> 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 ___ 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
[opensc-devel] Fix: "rutoken" and "emv" detection
Hello,
FIX: sc_get_rutoken_driver above EMV because the detection gets caught
there first.
Patch for trunk revision 3698 is in attachment. Could you please add it?
Thanks
diff -u -r opensc-trunk-r3698/src/libopensc/ctx.c
new/opensc-trunk-r3698/src/libopensc/ctx.c
--- opensc-trunk-r3698/src/libopensc/ctx.c 2009-06-26 13:30:08.0
+0400
+++ new/opensc-trunk-r3698/src/libopensc/ctx.c 2009-06-26 17:42:22.0
+0400
@@ -73,6 +73,7 @@
{ "belpic", (void *(*)(void)) sc_get_belpic_driver },
{ "atrust-acos",(void *(*)(void)) sc_get_atrust_acos_driver },
{ "muscle", (void *(*)(void)) sc_get_muscle_driver }, /* Above EMV
because the detection gets caught there first */
+ { "rutoken",(void *(*)(void)) sc_get_rutoken_driver }, /* Above EMV
because the detection gets caught there first */
{ "emv",(void *(*)(void)) sc_get_emv_driver },
{ "incrypto34", (void *(*)(void)) sc_get_incrypto34_driver },
#ifdef ENABLE_OPENSSL
@@ -83,7 +84,6 @@
#ifdef ENABLE_OPENSSL
{ "entersafe",(void *(*)(void)) sc_get_entersafe_driver },
#endif
- { "rutoken",(void *(*)(void)) sc_get_rutoken_driver },
{ "rutoken_ecp",(void *(*)(void)) sc_get_rtecp_driver },
/* The default driver should be last, as it handles all the
* unrecognized cards. */
___
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 :
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
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
Aktiv Co. Aleksey Samsonov:
Patches for trunk revision 3698 are in attachment.
Sorry for inconvenience caused.
Patches for trunk revision 3698 are in attachment.
diff -u -r opensc-trunk-r3698/src/libopensc/iso7816.c
new/opensc-trunk-r3698/src/libopensc/iso7816.c
--- opensc-trunk-r3698/src/libopensc/iso7816.c 2009-06-25 15:00:55.0
+0400
+++ new/opensc-trunk-r3698/src/libopensc/iso7816.c 2009-06-25
15:57:27.0 +0400
@@ -446,11 +446,9 @@
apdu.resp = buf;
apdu.resplen = sizeof(buf);
apdu.le = 256;
- } else {
- apdu.resplen = 0;
- apdu.le = 0;
- apdu.cse = SC_APDU_CASE_3_SHORT;
- }
+ } else
+ 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");
if (file_out == NULL) {
diff -u -r opensc-trunk-r3698/src/libopensc/iso7816.c
new/opensc-trunk-r3698/src/libopensc/iso7816.c
--- opensc-trunk-r3698/src/libopensc/iso7816.c 2009-06-25 15:00:55.0
+0400
+++ new/opensc-trunk-r3698/src/libopensc/iso7816.c 2009-06-25
15:22:55.0 +0400
@@ -463,6 +463,8 @@
if (r)
SC_FUNC_RETURN(card->ctx, 2, r);
+ if (apdu.resplen < 2)
+ 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;
diff -u -r opensc-trunk-r3698/src/libopensc/iso7816.c
new/opensc-trunk-r3698/src/libopensc/iso7816.c
--- opensc-trunk-r3698/src/libopensc/iso7816.c 2009-06-25 15:00:55.0
+0400
+++ new/opensc-trunk-r3698/src/libopensc/iso7816.c 2009-06-25
15:29:52.0 +0400
@@ -519,17 +519,20 @@
{
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) {
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 +547,21 @@
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) {
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) {
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;
diff -u -r opensc-trunk-r3698/src/libopensc/iso7816.c
new/opensc-trunk-r3698/src/libopensc/iso7816.c
--- opensc-trunk-r3698/src/libopensc/iso7816.c 2009-06-25 15:00:55.0
+0400
+++ new/opensc-trunk-r3698/src/libopensc/iso7816.c 2009-06-25
15:35:46.0 +0400
@@ -528,6 +528,7 @@
sc_asn1_put_tag(0x81, buf, 2, p, 16, &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);
} else {
@@ -551,10 +552,12 @@
Re: [opensc-devel] iso7816.c:set_security_env:OPERATION_DECIPHER
Hello, Ludovic Rousseau: > 2009/6/23 Aktiv Co. Aleksey Samsonov : >> I propose the attached patch for iso7816.c. > > Can you split the patch is small and independent patches please? > And for each patch explain what the patch does and/or why it is needed. > > For example you can create one patch with only the assert() calls, etc. Patches for trunk revision 3698 are in attachment. 1) opensc-trunk-r3698_new1.diff Fix: If (in_path->type == SC_PATH_TYPE_PARENT) then: src/libopensc/iso7816.c: 433 apdu.p1 = 3; 434 pathlen = 0; 435 apdu.cse = SC_APDU_CASE_2_SHORT; and if (file_out == NULL) then 452 apdu.cse = SC_APDU_CASE_3_SHORT; => apdu.lc == 0 && apdu.le = 0, but apdu.cse = SC_APDU_CASE_3_SHORT; sc_transmit_apdu -> sc_check_apdu -> error 2) opensc-trunk-r3698_new2.diff Fix for the case when "apdu.resplen < 2" and checked buffer length. 3) opensc-trunk-r3698_new3.diff Check buffer length (*outlen) 4) opensc-trunk-r3698_new4.diff Add assert() calls to check constant buffer size. 5) opensc-trunk-r3698_new5.diff Remove dead code. Thanks ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add new driver for Rutoken ECP tokens
Ludovic Rousseau: > 2009/6/24 Aktiv Co. Aleksey Samsonov : >> Rutoken ECP: >> P: Vendor=0a89 ProdID=0030 Rev= 1.00 >> S: Manufacturer=Aktiv >> S: Product=Rutoken ECP > > It looks like the device is different from the one I have in my list > "Rutoken Magistra" [1] with idProduct: 0x0060. This is a different device. > Can you follow the procedure at [2] and send me the output.txt file? Yes, of course. I sent a email to you. > Thanks > > [1] http://pcsclite.alioth.debian.org/readers/Aktiv_Rutoken_Magistra.txt > [2] http://pcsclite.alioth.debian.org/ccid.html#CCID_compliant ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] Add new driver for Rutoken ECP tokens
Hello, Andreas Jellinghaus: > can you put this information into a wiki page? > you need to login with your account and password before you > can edit wiki pages / create new pages. if you don't have > an account, please send me a private email with user/password > and I will create one for you. Yes, of course. I sent a email to you. > the patch looks good to me, so I applied it to trunk. Thanks > Rutoken ECP is sold in russia only? Unfortunately, it is expected that Rutoken ECP will most likely be sold in Russia only. ___ 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);
memcp
[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] 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 = 0x41; May be (patch is in attachment)? Thanks ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] opensc-tool: SC_AC_OP_ERASE in ac_ops_ef (src/tools/opensc-tool.c:303)
Hi!
src/tools/opensc-tool.c:303:
const char *ac_ops_ef[] = {
"read", "update", "write", "erase", "rehab", "inval"
};
src/libopensc/opensc.h:92
/* Operations relating to access control (in case of DF) */
#define SC_AC_OP_SELECT 0
#define SC_AC_OP_LOCK 1
#define SC_AC_OP_DELETE 2
#define SC_AC_OP_CREATE 3
#define SC_AC_OP_REHABILITATE 4
.
/* Operations relating to access control (in case of EF) */
#define SC_AC_OP_READ 0
#define SC_AC_OP_UPDATE 1
/* the use of SC_AC_OP_ERASE is deprecated, SC_AC_OP_DELETE should be used
* instead */
#define SC_AC_OP_ERASE SC_AC_OP_DELETE
#define SC_AC_OP_WRITE 3
(http://www.opensc-project.org/opensc/changeset/2683/trunk/src/libopensc/opensc.h)
Patch for trunk revision 3694 is in attachment.
Thanks.
diff -u -r opensc-trunk-r3694/src/tools/opensc-tool.c
opensc-trunk-r3694_new/src/tools/opensc-tool.c
--- opensc-trunk-r3694/src/tools/opensc-tool.c 2008-12-27 19:15:30.0
+0300
+++ opensc-trunk-r3694_new/src/tools/opensc-tool.c 2009-06-09
16:39:50.0 +0400
@@ -301,7 +301,7 @@
"list"
};
const char *ac_ops_ef[] = {
- "read", "update", "write", "erase", "rehab", "inval"
+ "read", "update", "erase", "write", "rehab", "inval"
};
for (r = 0; r < depth; r++)
___
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
Hello. Andreas Jellinghaus: > can you also edit the wiki page, > and document what this change means for users? I will try to do so. > e.g. do people need to delete and re-initialize their tokens? Yes. For example: $pkcs15-init --erase-card $pkcs15-init --create-pkcs15 --so-pin "87654321" $pkcs15-init --store-pin --label "User PIN" --auth-id 02 --pin "12345678" > is there a security issue with the way the tokens were used earlier. It is not a security issue. > also, do you know any resellers of the rutoken in eu? Unfortunately, Rutoken S is not exported from Russia. ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
Re: [opensc-devel] OpenCT:configure.ac:OPENCT_CONF_PATH
Is "ifdhandler" correct? (Not "openct.conf" or "openct.conf.new"?) Alon Bar-Lev: > Should be. > > On 1/29/09, Aktiv Co. Aleksey Samsonov wrote: >> Hello. >> The openct trunk revision 1127: configure.ac: Line 400: >> >> CPPFLAGS_OPENCT_CONF_PATH='-DOPENCT_CONF_PATH="\"$(sysconfdir)/ifdhandler\""' >> - is it correct? ___ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
[opensc-devel] OpenCT:configure.ac:OPENCT_CONF_PATH
Hello. The openct trunk revision 1127: configure.ac: Line 400: CPPFLAGS_OPENCT_CONF_PATH='-DOPENCT_CONF_PATH="\"$(sysconfdir)/ifdhandler\""' - is it correct? ___ 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 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, ¶ms) < 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 > * Copyright (C) 2007 Eugene Hermann > > 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'
(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] opensc-explorer double free - fix
Patch opensc-0.11.4.trunk-r3498-fix_2free_osc-explorer.diff (for trunk trunk revision 3502) is draft Examples: 1) $ 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 2) $ opensc-explorer OpenSC Explorer version 0.11.4-svn OpenSC [3F00]> cd ff00 OpenSC [3F00/FF00]> cat only working EFs may be read OpenSC [3F00/FF00]> cd .. opensc-explorer: sc.c:492: sc_file_free: Assertion `sc_file_valid(file)' failed. Aborted etc. opensc-0.11.4.trunk-r3498-fix_2free_osc-explorer.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 - fix
Alon Bar-Lev: Do you sure you not require O_BINARY in rutoken-tool? O_BINARY is non-standard flag, but for generality... opensc-0.11.4.trunk-r3491-fix_msvc_o_binary.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] 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
Re: [opensc-devel] OpenSC svn build on Windows rutoken issues - fix
Alon Bar-Lev: > So what caused the need to apply this in the first place? I have not looked through change in winconfig.h.in and used http://www.opensc-project.org/opensc/browser/trunk/src/tools/pkcs11-tool.c?rev=3489#L961 as a basis. > Is there an issue to fix? This is an attempt to solve a possible problem. > Should I apply the winconfig.h.in fixup? No, it's not necessary. Does anyone have a problem compiling Rutoken code in MSVC now? ___ 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 - fix
Alon Bar-Lev: > Committed at rev 3490. Thanks! > This is not required. Right, current trunk is already true. > Anyway it looks like it is required only for MSVC. Yes, it's for MSVC only. ___ 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
