from:"Andre Zepezauer"

Re: [opensc-devel] Issue during delete object with Athena Cards

2011-07-27 Thread Andre Zepezauer

Hi Martin,

- Original Message -
From: Martin Paljak mar...@martinpaljak.net
Date: Tuesday, July 26, 2011 4:42 pm
Subject: Re: [opensc-devel] Issue during delete object with Athena Cards
To: Andre Zepezauer andre.zepeza...@student.uni-halle.de
Cc: HOURY William william.ho...@atos.net, 
'opensc-devel@lists.opensc-project.org' 
opensc-devel@lists.opensc-project.org

 Hello,
 On Jul 26, 2011, at 12:46 PM, Andre Zepezauer wrote:
  this regression could be related to #370 [1]. William, please open a 
 New
  Ticket and upload the required Attachments.

 #370 does not affect the problem, as pkcs15-init is not affected by 
 lock_login, which is a PKCS#11 option.

IMO the bug in #370 is caused by application re-selection which is conditional
in the PKCS#11 layer. Lock_login is only the condition that may trigger the bug.

My first assumption is, that re-selection also happens on William's cards. But 
let's
wait and see.

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Issue during delete object with Athena Cards

2011-07-26 Thread Andre Zepezauer

Hello,

this regression could be related to #370 [1]. William, please open a New
Ticket and upload the required Attachments.

Regards
Andre

[1] http://www.opensc-project.org/opensc/ticket/370

On Tue, 2011-07-26 at 07:55 +, HOURY William wrote:
 Hello all,
 
  
 
 We seem to have a regression issue between OpenSC 12.1  OpenSC 12.0
 with the Athena ASEPCOS card. The issue is still there in OpenSC 12.2.
 
  
 
 When I try to delete an object on the card using PKCS15-init, it fails
 every time saying the security status is not satisfied.
 
  
 
 It’s quite easy to reproduce. I have a card with 2 PIN  2 PUK and
 with the following objects:
 
  
 
 
 Private RSA Key [Private Key]
 
 Object Flags   : [0x3], private, modifiable
 
 Usage  : [0x2C], sign, signRecover, unwrap
 
 Access Flags   : [0x0]
 
 ModLength  : 1024
 
 Key ref: 0 (0x0)
 
 Native : yes
 
 Path   : 3f0050150100
 
 Auth ID: 01
 
 ID : 46
 
  
 
 X.509 Certificate [/DC=pmtdom/DC=local/L=MDS/OU=PMT/CN=user1]
 
 Object Flags   : [0x2], modifiable
 
 Authority  : no
 
 Path   : 3f0050153104
 
 ID : 46
 
 Encoded serial : 02 0A 61738741005C
 
 
  
 
 Then I try to remove the certificate using the following command line:
 
 pkcs15-init -D cert --id 46 --so-pin 12345678 --pin 12345678
 
  
 
 And get the following error:
 
 Failed to delete object 0: Security status not satisfied
 
 Deleted 0 objects
 
 Failed to delete object(s): Security status not satisfied
 
  
 
 As I said, it works well with OpenSC 12.0…
 
  
 
 Thanks for your help,
 
  
 
 William
 
 
 
 __
 
 Ce message et les pièces jointes sont confidentiels et réservés à
 l'usage exclusif de ses destinataires. Il peut également être protégé
 par le secret professionnel. Si vous recevez ce message par erreur,
 merci d'en avertir immédiatement l'expéditeur et de le détruire.
 L'intégrité du message ne pouvant être assurée sur Internet, la
 responsabilité du groupe Atos ne pourra être engagée quant au contenu
 de ce message. Bien que les meilleurs efforts soient faits pour
 maintenir cette transmission exempte de tout virus, l'expéditeur ne
 donne aucune garantie à cet égard et sa responsabilité ne saurait être
 engagée pour tout dommage résultant d'un virus transmis.
 
 This e-mail and the documents attached are confidential and intended
 solely for the addressee; it may also be privileged. If you receive
 this e-mail in error, please notify the sender immediately and destroy
 it. As its integrity cannot be secured on the Internet, the Atos group
 liability cannot be triggered for the message content. Although the
 sender endeavors to maintain a computer virus-free network, the sender
 does not warrant that this transmission is virus-free and will not be
 liable for any damages resulting from any virus transmitted.
 
 ___
 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] silent build rules for OpenSC

2011-07-23 Thread Andre Zepezauer

Hello Martin,

On Thu, 2011-06-30 at 12:56 +0300, Martin Paljak wrote:
 Tarballs builds (which also run make distcheck etc) actually should
 come with --enable-strict, which should also be the default option for
 developers. If not constantly, then every now and then. Hopefully this
 will trigger refactoring at some stage. But for everyday use the clean
 output from make is so much better - it is actually possible to notice
 issues.

please consider the inclusion of the following patch.
BTW: 'make  /dev/null' to get essential output only.
 
Index: configure.ac
===
--- configure.ac(revision 5569)
+++ configure.ac(working copy)
@@ -568,7 +568,7 @@
CFLAGS=${CFLAGS} -pedantic
 fi
 if test ${enable_strict} = yes; then
-   CFLAGS=${CFLAGS} -Wall -Wextra
+   CFLAGS=${CFLAGS} -Wall -Wextra -Wno-unused-parameter
 fi
 if test $GCC = yes; then
# This should be resolved not ignored.


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Changeset 5558 in opensc

2011-06-08 Thread Andre Zepezauer

On Wed, 2011-06-08 at 11:50 +0200, Jean-Pierre Szikora wrote:
 On 06/07/2011 03:17 PM, Andre Zepezauer wrote:
  Hello Jean-Pierre,
 
  SC_PKCS15_PIN_FLAG_VERIFY_RC_COUNTER doesn't correspond to any flag
  defined in PKCS#15. Furthermore, the capability to modify the return
  code of the VERIFY command is not specific to PKCS#15.
 
  Why not using a different approach? In example it's possible to detect
  the installed packages of CardOS. Depending of the presence of the
  Verify Retry Counter Package the flags in TEST BSO could be set
  accordingly.
 
 Hi Andre,
 
 Any comment/objection?

A flag SC_CARD_FLAG_ISO_VERIFY would be of general use. If set, then
it's possible to send the VERIFY command with *empty* data field to get
the number of further allowed retries coded in SW '63CX'.

That means, that cardos_have_verifyrc_package would be placed better in
card-cardos.c and only card-flags  SC_CARD_FLAG_ISO_VERIFY needs to
be checked in pkcs15-cardos.c

Prerequisite is that opensc-tool -s 00 20 00 01 returns something
like: Received (SW1=0x63, SW2=0xC3)

Any comment/objection?

 Index: src/pkcs15init/pkcs15-cardos.c
 ===
 --- src/pkcs15init/pkcs15-cardos.c(revision 5563)
 +++ src/pkcs15init/pkcs15-cardos.c(working copy)
 @@ -62,6 +62,7 @@
  sc_file_t *, int);
  static intdo_cardos_extract_pubkey(sc_card_t *card, int nr, u8 tag,
  sc_pkcs15_bignum_t *bn);
 +static intcardos_have_verifyrc_package(sc_card_t *card);
  
  /* Object IDs for PIN objects.
   * SO PIN = 0x01, SO PUK = 0x02
 @@ -413,7 +414,7 @@
  unsigned charpinpadded[256];
  struct tlvtlv;
  unsigned intattempts, minlen, maxlen;
 -intr;
 +intr, hasverifyrc;
  
  if (auth_info-auth_type != SC_PKCS15_PIN_AUTH_TYPE_PIN)
  return SC_ERROR_OBJECT_NOT_VALID;
 @@ -445,6 +446,10 @@
  /* parameters */
  tlv_next(tlv, 0x85);
  tlv_add(tlv, 0x02);/* options byte */
 +hasverifyrc = cardos_have_verifyrc_package(card);
 +if (hasverifyrc == 1)
 +/* Use 9 byte OCI parameters to be able to set VerifyRC bit*/
 +tlv_add(tlv, 0x04);/* options_2 byte with bit 2 set to
 return CurrentErrorCounter*/
  tlv_add(tlv, attempts  0xf);/* flags byte */
  tlv_add(tlv, CARDOS_ALGO_PIN);/* algorithm = pin-test */
  tlv_add(tlv, attempts  0xf);/* errcount = attempts */
 @@ -786,6 +791,56 @@
  return r;
  }
  
 +static int cardos_have_verifyrc_package(sc_card_t *card)
 +{
 +sc_apdu_t apdu;
 +u8rbuf[SC_MAX_APDU_BUFFER_SIZE];
 +int   r;
 +const u8  *p = rbuf, *q;
 +size_tlen, tlen = 0, ilen = 0;
 +
 +sc_format_apdu(card, apdu, SC_APDU_CASE_2_SHORT, 0xca, 0x01, 0x88);
 +apdu.resp= rbuf;
 +apdu.resplen = sizeof(rbuf);
 +apdu.lc = 0;
 +apdu.le = 256;
 +r = sc_transmit_apdu(card, apdu);
 +SC_TEST_RET(card-ctx, SC_LOG_DEBUG_NORMAL, r, APDU transmit failed);
 +
 +if ((len = apdu.resplen) == 0)
 +/* looks like no package has been installed  */
 +return 0;
 +
 +while (len != 0) {
 +p = sc_asn1_find_tag(card-ctx, p, len, 0xe1, tlen);
 +if (p == NULL)
 +return 0;
 +if (card-type == SC_CARD_TYPE_CARDOS_M4_3){
 +/* the verifyRC package on CardOS 4.3B use Manufacturer ID
 0x01*/
 +/* and Package Number 0x07*/
 +q = sc_asn1_find_tag(card-ctx, p, tlen, 0x01, ilen);
 +if (q == NULL || ilen != 4)
 +return 0;
 +if (q[0] == 0x07)
 +return 1;
 +} else if (card-type == SC_CARD_TYPE_CARDOS_M4_4){
 +/* the verifyRC package on CardOS 4.4 use Manufacturer ID
 0x03*/
 +/* and Package Number 0x02*/
 +q = sc_asn1_find_tag(card-ctx, p, tlen, 0x03, ilen);
 +if (q == NULL || ilen != 4)
 +return 0;
 +if (q[0] == 0x02)
 +return 1;
 +} else{
 +return 0;
 +}
 +p   += tlen;
 +len -= tlen + 2;
 +}
 +
 +return 0;
 +}
 +
  static struct sc_pkcs15init_operations sc_pkcs15init_cardos_operations = {
  cardos_erase,
  NULL,/* init_card */
 

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Changeset 5558 in opensc

2011-06-08 Thread Andre Zepezauer

On Wed, 2011-06-08 at 17:45 +0300, Martin Paljak wrote:
 Hello,
 
 
 On Wed, Jun 8, 2011 at 17:37, Andre Zepezauer
 andre.zepeza...@student.uni-halle.de wrote:
  More elegant indeed. Some nice documentation about the real meaning of the 
  flag would also be nice. most cards do almost ISO to support pinpads.
  But not all support the status query...
 
  Maybe I'm wrong, but IMO Viktor had implemented the status query through
  empty data field some time ago. So, there would be at least two cards
  which does support it.
 
 
 
 There was discussion about it a few months ago, probably at the same
 time. The general consensus (also my personal opinion) seemed to be
 that it is safer not to probe the card, as there are several cards
 that don't support the convention and some even decrease the retry
 counter (like the buggy new ID-card in Estonia...)
 
 Even though many cards override pin_cmd, extra care should be taken to
 not accidentally block a PIN code, thus the feature (like a flag)
 should be set case-by-case.

Would it be safe enough to set a specific flag in the drivers init
function? And if set, then the status query could be performed without
casing harm.

Open questions:
* is it worth to make that effort
* how many cards do have support for that feature

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Changeset 5558 in opensc

2011-06-08 Thread Andre Zepezauer

On Wed, 2011-06-08 at 17:31 +0200, Andre Zepezauer wrote:
 On Wed, 2011-06-08 at 17:45 +0300, Martin Paljak wrote:
  Hello,
  
  
  On Wed, Jun 8, 2011 at 17:37, Andre Zepezauer
  andre.zepeza...@student.uni-halle.de wrote:
   More elegant indeed. Some nice documentation about the real meaning of 
   the flag would also be nice. most cards do almost ISO to support 
   pinpads.
   But not all support the status query...
  
   Maybe I'm wrong, but IMO Viktor had implemented the status query through
   empty data field some time ago. So, there would be at least two cards
   which does support it.
  
  
  
  There was discussion about it a few months ago, probably at the same
  time. The general consensus (also my personal opinion) seemed to be
  that it is safer not to probe the card, as there are several cards
  that don't support the convention and some even decrease the retry
  counter (like the buggy new ID-card in Estonia...)
  
  Even though many cards override pin_cmd, extra care should be taken to
  not accidentally block a PIN code, thus the feature (like a flag)
  should be set case-by-case.
 
 Would it be safe enough to set a specific flag in the drivers init
 function? And if set, then the status query could be performed without
 casing harm.
 
 Open questions:
 * is it worth to make that effort

Some usage scenarios:

Let pkcs11-tool -L show the following flags: CKF_USER_PIN_COUNT_LOW,
CKF_USER_PIN_FINAL_TRY, CKF_USER_PIN_LOCKED

Let pkcs11-tool -l show something like this:
Logging into My Token (PIN).
Please enter User PIN (*** FINAL TRY ***):

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] Changeset 5558 in opensc

2011-06-07 Thread Andre Zepezauer

Hello Jean-Pierre,

SC_PKCS15_PIN_FLAG_VERIFY_RC_COUNTER doesn't correspond to any flag
defined in PKCS#15. Furthermore, the capability to modify the return
code of the VERIFY command is not specific to PKCS#15.

Why not using a different approach? In example it's possible to detect
the installed packages of CardOS. Depending of the presence of the
Verify Retry Counter Package the flags in TEST BSO could be set
accordingly.

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] Using -Wno-unused-parameter -Werror in nightly builds

2011-05-31 Thread Andre Zepezauer

Hello,

when the following warnings becomes fixed, then we could use the
compiler options -Wno-unused-parameter -Werror in nightly builds. This
would be of help to avoid the introduction of new warnings of this kind.

Regards
Andre

pkcs15-oberthur-awp.c: In function ‘awp_new_container_entry’:
pkcs15-oberthur-awp.c:250: warning: comparison between signed and unsigned
pkcs15-oberthur-awp.c: In function ‘awp_update_container’:
pkcs15-oberthur-awp.c:601: warning: comparison between signed and unsigned
pkcs15-oberthur-awp.c: In function ‘awp_encode_data_info’:
pkcs15-oberthur-awp.c:1182: warning: pointer targets in assignment differ in 
signedness
pkcs15-oberthur-awp.c: In function ‘awp_remove_from_object_list’:
pkcs15-oberthur-awp.c:1806: warning: comparison between signed and unsigned
pkcs15-authentic.c: In function ‘authentic_reference_to_pkcs15_id’:
pkcs15-authentic.c:101: warning: comparison between signed and unsigned
pkcs15-authentic.c: In function ‘authentic_docp_set_acls’:
pkcs15-authentic.c:303: warning: comparison between signed and unsigned
pkcs15-iasecc.c: In function ‘iasecc_file_convert_acls’:
pkcs15-iasecc.c:312: warning: initialization discards qualifiers from pointer 
target type
pkcs15-iasecc.c: In function ‘iasecc_sdo_convert_to_file’:
pkcs15-iasecc.c:576: warning: comparison between signed and unsigned
card-piv.c: In function ‘piv_compute_signature’:
card-piv.c:2025: warning: comparison between signed and unsigned
card-piv.c:2046: warning: comparison between signed and unsigned
card-westcos.c: In function ‘westcos_sign_decipher’:
card-westcos.c:1182: warning: comparison between signed and unsigned
card-iasecc.c: In function ‘iasecc_pin_get_policy’:
card-iasecc.c:1904: warning: comparison between signed and unsigned
card-iasecc.c:1921: warning: comparison between signed and unsigned
card-iasecc.c: In function ‘iasecc_pin_cmd’:
card-iasecc.c:2138: warning: comparison between signed and unsigned
card-iasecc.c: In function ‘iasecc_qsign_data_sha1’:
card-iasecc.c:2769: warning: comparison between signed and unsigned
card-iasecc.c: In function ‘iasecc_qsign_data_sha256’:
card-iasecc.c:2818: warning: comparison between signed and unsigned
iasecc-sdo.c: In function ‘iasecc_sdo_parse_card_answer’:
iasecc-sdo.c:1179: warning: comparison between signed and unsigned
pkcs15-piv.c: In function ‘piv_get_guid’:
pkcs15-piv.c:220: warning: comparison between signed and unsigned
pkcs15-oberthur.c: In function ‘sc_oberthur_read_file’:
pkcs15-oberthur.c:308: 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] Unwrap, with openssl, a key wrapped inside Smart Card

2011-04-13 Thread Andre Zepezauer

On Wed, 2011-04-13 at 14:44 -0300, Felipe Blauth wrote:
 Hello to all,
 
 Simple question:
 Is it  possible, using openssl, to unwrap a key wraped inside a Smart
 Card with C_Wrap function?

Maybe, but the question here is how the key becomes wrapped in the smart
card. OpenSC doesn't support that kind of key-wrapping.

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] magic 0x20 in pkcs15-piv.c

2011-03-07 Thread Andre Zepezauer

On Sat, 2011-03-05 at 08:06 -0600, Douglas E. Engert wrote:
 
 On 3/4/2011 10:40 AM, Andre Zepezauer wrote:
  Hello Douglas,
 
  what's that magic value 0x20 and where it becomes set?
 
 
 It goes back to 2006:
 http://www.opensc-project.org/pipermail/opensc-devel/2006-May/008569.html
 
 It was for testing and could be removed.

Done in r5221.

 
  http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15-piv.c#L586
  http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15-piv.c#L707
  http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15-piv.c#L835
 
 
 
 

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] r5124

2011-03-07 Thread Andre Zepezauer

On Mon, 2011-02-28 at 15:33 +0100, Andre Zepezauer wrote:
 Hello Martin,
 
 I would like to commit the attached patch. Any objections?

Committed in r5222.

 On Thu, 2011-02-03 at 14:36 +0200, Martin Paljak wrote:
  Hello,
  
  On Thu, Jan 27, 2011 at 20:08, Andre Zepezauer
  andre.zepeza...@student.uni-halle.de wrote:
   Hello Martin,
  
   some comments on r5124:
  
   1. The values of pin_info-reference and prkey_info-key_reference
   shouldn't be compared because:
  
   * pin_info-reference is used as P2 parameter in VERIFY command
   * prkey_info-key_reference is used in MSE SET tag 0x84
  
  OK, I see your point.
  Looking at your patch: could it be extracted into a small lookup
  function like the current one that is used? such a small lookup
  function with a small doxygen doc would look really nice.
  
  I see it has been working up to because of a coincidence...
 ___
 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

[opensc-devel] magic 0x20 in pkcs15-piv.c

2011-03-04 Thread Andre Zepezauer

Hello Douglas,

what's that magic value 0x20 and where it becomes set?

http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15-piv.c#L586
http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15-piv.c#L707
http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15-piv.c#L835


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] pkcs15-gemsafeV1

2011-03-04 Thread Andre Zepezauer

Hello,

I found some magic in pkcs15-gemsafeV1.c [1]. Anyone knows where these
lower 4 bits are set? If not, I will remove these lines as part of a
larger patch.

[1] 
http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15-gemsafeV1.c#L308

Regards
Andre


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] r5124

2011-02-28 Thread Andre Zepezauer

Hello Martin,

I would like to commit the attached patch. Any objections?

On Thu, 2011-02-03 at 14:36 +0200, Martin Paljak wrote:
 Hello,
 
 On Thu, Jan 27, 2011 at 20:08, Andre Zepezauer
 andre.zepeza...@student.uni-halle.de wrote:
  Hello Martin,
 
  some comments on r5124:
 
  1. The values of pin_info-reference and prkey_info-key_reference
  shouldn't be compared because:
 
  * pin_info-reference is used as P2 parameter in VERIFY command
  * prkey_info-key_reference is used in MSE SET tag 0x84
 
 OK, I see your point.
 Looking at your patch: could it be extracted into a small lookup
 function like the current one that is used? such a small lookup
 function with a small doxygen doc would look really nice.
 
 I see it has been working up to because of a coincidence...
Index: src/libopensc/pkcs15-pin.c
===
--- src/libopensc/pkcs15-pin.c	(revision 5215)
+++ src/libopensc/pkcs15-pin.c	(working copy)
@@ -499,12 +499,21 @@
 		return;
 	}
 
-	/* If the PIN protects a private key with user consent, don't cache it */
-	if (sc_pkcs15_find_prkey_by_reference(p15card, NULL, pin_info-reference, obj) == SC_SUCCESS) {
-		if (obj-user_consent) {
-			sc_debug(ctx, SC_LOG_DEBUG_NORMAL, Not caching a PIN protecting a key with user consent);
-			return;
+	/* If the PIN protects an object with user consent, don't cache it */
+	obj = p15card-obj_list;
+	while (obj != NULL) {
+		/* Compare 'sc_pkcs15_object.auth_id' with 'sc_pkcs15_pin_info.auth_id'.
+		 * In accordance with PKCS#15 6.1.8 CommonObjectAttributes and
+		 * 6.1.16 CommonAuthenticationObjectAttributes with the exception that
+		 * CommonObjectAttributes.accessControlRules are not taken into account. */
+		if (sc_pkcs15_compare_id(obj-auth_id, pin_info-auth_id)) {
+			/* Caching is refused, if the protected object requires user consent */
+			if (obj-user_consent  0) {
+sc_debug(ctx, SC_LOG_DEBUG_NORMAL, caching refused (user consent));
+return;
+			}
 		}
+		obj = obj-next;
 	}
 
 	r = sc_pkcs15_allocate_object_content(pin_obj, pin, pinlen);
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] sc_ctx_detect_readers patch

2011-02-14 Thread Andre Zepezauer

On Mon, 2011-02-14 at 13:23 -0600, Douglas E. Engert wrote:
 
 On 2/11/2011 6:02 PM, Andre Zepezauer wrote:
  On Fri, 2011-02-11 at 15:16 -0600, Douglas E. Engert wrote:
 
  On 2/11/2011 3:02 PM, Andre Zepezauer wrote:
  On Fri, 2011-02-11 at 22:25 +0200, Martin Paljak wrote:
  Furthermore, any cardmod adjustments can be implemented and isolated
  with ifdef-s,
 
  The only #ifdef ENABLED_CARDMOD left is in ctx, and that could easily 
  be
  removed as it tests the app_name for cardmod (The 
  cardmod/Makefile.am
  has one to compile or not.)  That test for the app_name is needed 
  today
  because of the way the readers are initialized, and the cardmod looks
  like a separate driver. This could change if the mods were merged 
  better
  in reader-pcsc.c
 
  As you said above, The cardmod modifications to
  reader-pcsc for the most part turn off all these features, so they 
  don't
  get accidentally executed and cause problems..
 
 
  #ifdef-s in reader-pcsc.c are OK to assure those limitations.
  But those ifdef-s only should exist in reader-pcsc.c, as the only 
  reader driver the minidriver will know about is the pcsc driver. And 
  to make it very sure, if the codebase is compiled to produce 
  minidriver DLL, the extra ifdef-s will guarantee that those 
  restrictions are enforced (actually it should be assured by the 
  minidriver code that nothing gets called that would confuse 
  reader-pcsc.c)
 
 
  I would still assume that the first thing a combined driver would do
  would be to set a use_provided_readers or cardmod_mode flag so
  #ifdefs are not used, but if statements are.
 
  This would allow the same build to be used for both cardmod and pkcs#11.
 
  If-s should suffice, I assume the same. Eventually #ifdef-s and a 
  separate compile could probably allow to reduce the overall binary dll 
  size even more.
 
  BTW: There was a _standalone_ reader-cardmod.c proposed on Monday. It
  uses the 'init' function to pass in the handles. Making 'init' a stub
  and using its body for the new 'use_reader' function should be enough to
  make it work with current trunk.
 
  Have you tried this?
 
 
  The only thing that could be shared with the original reader-pcsc.c is
  'transmit'. And even that could be re-written from scratch if closer
  coupling to the underlying platform is required.
 
  See attachment for a more compact implementation of 'transmit'.
 
 
 Can you please try these modifications on your own systems.

Haven't a MS Windows box at hand, sorry.

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] sc_ctx_detect_readers patch

2011-02-11 Thread Andre Zepezauer

On Fri, 2011-02-11 at 11:24 +0200, Martin Paljak wrote:
 On Fri, Feb 4, 2011 at 01:19, Andre Zepezauer
 andre.zepeza...@student.uni-halle.de wrote:
 
  BTW: The main handle in OpenSC is 'sc_pkcs15_card_t' and not
  'sc_context_t'. In fact 'sc_context_t' is really unimportant. But
  sc_pkcs15_card_t holds all the operational state the is required to make
  things working. Have a look at VENDOR_SPECIFIC, there is only one OpenSC
  specific field needed.
 
 This is actually a very good idea.
 sc_pkcs15_card_from_handles(hContext, hCard) - pkcs15_card_t or NULL
 is a sensible thing to expose, in pair with
 sc_pkcs15_card_from_reader(reader_name) (used by Tokend)

What's about sc_pkcs15_card_from_reader(sc_reader_t *reader)? Seems that
this could work for both. How that reader becomes instantiated depends
on the requirements/environment of the particular application.

Additionally it could also be usable for secure messaging, when
providing custom reader implementations.


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] sc_ctx_detect_readers patch

2011-02-11 Thread Andre Zepezauer

On Fri, 2011-02-11 at 14:06 -0600, Douglas E. Engert wrote:
 
 On 2/11/2011 11:43 AM, Martin Paljak wrote:
 
  On Feb 11, 2011, at 6:55 PM, Douglas E. Engert wrote:
  On 2/11/2011 3:24 AM, Martin Paljak wrote:
  On Fri, Feb 4, 2011 at 01:19, Andre Zepezauer
  andre.zepeza...@student.uni-halle.de   wrote:
 
  BTW: The main handle in OpenSC is 'sc_pkcs15_card_t' and not
  'sc_context_t'. In fact 'sc_context_t' is really unimportant. But
  sc_pkcs15_card_t holds all the operational state the is required to make
  things working. Have a look at VENDOR_SPECIFIC, there is only one OpenSC
  specific field needed.
 
  This is actually a very good idea.
  sc_pkcs15_card_from_handles(hContext, hCard) -   pkcs15_card_t or NULL
  is a sensible thing to expose, in pair with
  sc_pkcs15_card_from_reader(reader_name)
 
  But the reader-pcsc.c is still out there detecting readers. Given a
  reader_name this may work on Mac. Given a handle on Windows to a reader,
  one could read the reader name, but if there are multiple readers from the
  same vendor with the same name how do you tell them apart? Who
  creates the unique name for the readers on the system?
  Given a handle  do you determine you have found the same reader that
  the Microsoft BaseCSP said to use.
 
  reader-pcsc.c must detect readers only when asked to do that.
 
  PC/SC subsystem assigns reader names. And two readers from the same 
  manufacturer IIRC get index number appended to the end of the name, like 
  with pcsc-lite ?
 
 
 OK then it would be possible to use the BaseCSP provided handle to get
 the reader name, then use the reader name to get a new handle
 to the same reader.
 
 That would be a completely different approach for cardmod then what
 we have been talking about in other e-mails.
 
 The question is which is a better way to do this? Are there any subtle
 differences in not using the handles provided by the BaseCSP?

Yes, the BaseCSP could use SCARD_SHARE_EXCLUSIVE. Then you are locked
out with new handles.

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] sc_ctx_detect_readers patch

2011-02-11 Thread Andre Zepezauer

On Fri, 2011-02-11 at 22:25 +0200, Martin Paljak wrote:
Furthermore, any cardmod adjustments can be implemented and isolated
with ifdef-s,

The only #ifdef ENABLED_CARDMOD left is in ctx, and that could easily be
removed as it tests the app_name for cardmod (The cardmod/Makefile.am
has one to compile or not.) That test for the app_name is needed today
because of the way the readers are initialized, and the cardmod looks
like a separate driver. This could change if the mods were merged better
in reader-pcsc.c

As you said above, The cardmod modifications to
reader-pcsc for the most part turn off all these features, so they don't
get accidentally executed and cause problems..

#ifdef-s in reader-pcsc.c are OK to assure those limitations.
But those ifdef-s only should exist in reader-pcsc.c, as the only reader
driver the minidriver will know about is the pcsc driver. And to make it
very sure, if the codebase is compiled to produce minidriver DLL, the
extra ifdef-s will guarantee that those restrictions are enforced
(actually it should be assured by the minidriver code that nothing gets
called that would confuse reader-pcsc.c)

I would still assume that the first thing a combined driver would do
would be to set a use_provided_readers or cardmod_mode flag so
#ifdefs are not used, but if statements are.

This would allow the same build to be used for both cardmod and pkcs#11.

If-s should suffice, I assume the same. Eventually #ifdef-s and a separate
compile could probably allow to reduce the overall binary dll size even more.

BTW: There was a _standalone_ reader-cardmod.c proposed on Monday. It
uses the 'init' function to pass in the handles. Making 'init' a stub
and using its body for the new 'use_reader' function should be enough to
make it work with current trunk.

The only thing that could be shared with the original reader-pcsc.c is
'transmit'. And even that could be re-written from scratch if closer
coupling to the underlying platform is required.

Regards
Andre

http://www.opensc-project.org/pipermail/opensc-devel/2011-February/015910.html
http://www.opensc-project.org/pipermail/opensc-devel/attachments/20110207/5b57cb23/attachment-0001.c

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] sc_ctx_detect_readers patch

2011-02-11 Thread Andre Zepezauer

On Fri, 2011-02-11 at 15:16 -0600, Douglas E. Engert wrote:

On 2/11/2011 3:02 PM, Andre Zepezauer wrote:
On Fri, 2011-02-11 at 22:25 +0200, Martin Paljak wrote:
Furthermore, any cardmod adjustments can be implemented and isolated
with ifdef-s,

As you said above, The cardmod modifications to
reader-pcsc for the most part turn off all these features, so they don't
get accidentally executed and cause problems..

I would still assume that the first thing a combined driver would do
would be to set a use_provided_readers or cardmod_mode flag so
#ifdefs are not used, but if statements are.

This would allow the same build to be used for both cardmod and pkcs#11.

If-s should suffice, I assume the same. Eventually #ifdef-s and a separate
compile could probably allow to reduce the overall binary dll size even
more.

Have you tried this?

Yep, but not with BaseCSP.

Additionally a stripped down reader-pcsc (renamed to reader-cardmod) is
attached. It works well with a modified version of opensc-pkcs11.so and
should work in the same way for cardmod. Integration into the build
system is still required and possibly some debugging.

The only thing that could be shared with the original reader-pcsc.c is
'transmit'. And even that could be re-written from scratch if closer
coupling to the underlying platform is required.

Regards
Andre

http://www.opensc-project.org/pipermail/opensc-devel/2011-February/015910.html
http://www.opensc-project.org/pipermail/opensc-devel/attachments/20110207/5b57cb23/attachment-0001.c

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] sc_ctx_detect_readers patch

2011-02-11 Thread Andre Zepezauer

On Fri, 2011-02-11 at 15:16 -0600, Douglas E. Engert wrote:
 
 On 2/11/2011 3:02 PM, Andre Zepezauer wrote:
  On Fri, 2011-02-11 at 22:25 +0200, Martin Paljak wrote:
  Furthermore, any cardmod adjustments can be implemented and isolated
  with ifdef-s,
 
  The only #ifdef ENABLED_CARDMOD left is in ctx, and that could easily be
  removed as it tests the app_name for cardmod (The cardmod/Makefile.am
  has one to compile or not.)  That test for the app_name is needed today
  because of the way the readers are initialized, and the cardmod looks
  like a separate driver. This could change if the mods were merged better
  in reader-pcsc.c
 
  As you said above, The cardmod modifications to
  reader-pcsc for the most part turn off all these features, so they don't
  get accidentally executed and cause problems..
 
 
  #ifdef-s in reader-pcsc.c are OK to assure those limitations.
  But those ifdef-s only should exist in reader-pcsc.c, as the only reader 
  driver the minidriver will know about is the pcsc driver. And to make it 
  very sure, if the codebase is compiled to produce minidriver DLL, the 
  extra ifdef-s will guarantee that those restrictions are enforced 
  (actually it should be assured by the minidriver code that nothing gets 
  called that would confuse reader-pcsc.c)
 
 
  I would still assume that the first thing a combined driver would do
  would be to set a use_provided_readers or cardmod_mode flag so
  #ifdefs are not used, but if statements are.
 
  This would allow the same build to be used for both cardmod and pkcs#11.
 
  If-s should suffice, I assume the same. Eventually #ifdef-s and a separate 
  compile could probably allow to reduce the overall binary dll size even 
  more.
 
  BTW: There was a _standalone_ reader-cardmod.c proposed on Monday. It
  uses the 'init' function to pass in the handles. Making 'init' a stub
  and using its body for the new 'use_reader' function should be enough to
  make it work with current trunk.
 
 Have you tried this?
 
 
  The only thing that could be shared with the original reader-pcsc.c is
  'transmit'. And even that could be re-written from scratch if closer
  coupling to the underlying platform is required.

See attachment for a more compact implementation of 'transmit'.
/*
 * reader-pcsc.c: Reader driver for PC/SC interface
 *
 * Copyright (C) 2002  Juha Yrjölä juha.yrj...@iki.fi
 * Copyright (C) 2009,2010 Martin Paljak mar...@paljak.pri.ee
 *
 * This library is free software; you can redistribute it and/or
 * modify it under the terms of the GNU Lesser General Public
 * License as published by the Free Software Foundation; either
 * version 2.1 of the License, or (at your option) any later version.
 *
 * This library is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this library; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 */

#include config.h

#include assert.h
#include stdlib.h
#include string.h

#include libopensc/internal.h
#include libopensc/internal-winscard.h

#include reader-cardmod.h

/* Logging */
#define PCSC_TRACE(reader, desc, rv) do { sc_debug(reader-ctx, SC_LOG_DEBUG_NORMAL, %s: desc : 0x%08lx\n, reader-name, rv); } while (0)
#define PCSC_LOG(ctx, desc, rv) do { sc_debug(ctx, SC_LOG_DEBUG_NORMAL, desc : 0x%08lx\n, rv); } while (0)


static unsigned int pcsc_proto_to_opensc(DWORD proto)
{
	switch (proto) {
	case SCARD_PROTOCOL_T0:
		return SC_PROTO_T0;
	case SCARD_PROTOCOL_T1:
		return SC_PROTO_T1;
	case SCARD_PROTOCOL_RAW:
		return SC_PROTO_RAW;
	default:
		return 0;
	}
}

static int pcsc_transmit(sc_reader_t *reader, sc_apdu_t *apdu)
{
SCARD_IO_REQUEST sSendPci, sRecvPci;
LONG rv;

	size_t   ssize, rsize;
	u8   *sbuf = NULL, *rbuf = NULL;
	int  r;

	struct pcsc_private_data *priv = (struct pcsc_private_data *) reader-ctx-reader_drv_data;

	/* prepare sbuf, ssize */
	r = sc_apdu_get_octets(reader-ctx, apdu, sbuf, ssize, pcsc_proto_to_opensc(priv-dwProtocol));
	if (r != SC_SUCCESS)
		goto out;

	/* prepare rbuf, rsize */
rsize = apdu-le + 2;
rbuf = malloc(rsize);
if (rbuf == NULL) {
r = SC_ERROR_OUT_OF_MEMORY;
goto out;
}

	/* don't know */
sSendPci.dwProtocol = priv-dwProtocol;
sSendPci.cbPciLength = sizeof(sSendPci);

	rv = SCardTransmit(priv-hSCard, sSendPci, sbuf, ssize, sRecvPci, rbuf, (DWORD *) rsize);

if (rv != SCARD_S_SUCCESS) {
PCSC_TRACE(reader, SCardTransmit/Control failed, rv);
switch (rv) {
	case SCARD_W_REMOVED_CARD: r = SC_ERROR_CARD_REMOVED; break;
	default: r = SC_ERROR_TRANSMIT_FAILED

Re: [opensc-devel] sc_ctx_detect_readers patch

2011-02-08 Thread Andre Zepezauer

Hello Douglas,

please have a look at that picture [1]. FYI the cardmod resides on the
same level as OpenSC.tokend does. As you can see, there is a clear
distinction between the library 'libopensc' and the applications (shown
at the top).

So, if there is a problem within a particular application, that problem
should also be fixed within the same application. If that isn't possible
at all, then improvements in libopensc may be considered. Preferable in
a way that other/future applications can also take advantage of it.
That's my personal opinion and the reason of my resistance about your
patch.

On Tue, 2011-02-08 at 09:09 -0600, Douglas E. Engert wrote:
 Today the opensc cardmod driver is experimental and it has issues

Are you talking about the opensc cardmod application [1]?

 My goal this week is to get the use_reader patch committed,

You don't have to but you could explain how that would improve libopensc
[1]?

 as well as the other fixes to the cardmod code.

No objections.

 After that if you have improvements and a way to test them,
 please try them.

What are you talking about?

Regards
Andre

[1] http://www.opensc-project.org/opensc/attachment/wiki/OverView/OpenSC.png

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] sc_ctx_detect_readers patch

2011-02-08 Thread Andre Zepezauer

On Tue, 2011-02-08 at 14:42 -0600, Douglas E. Engert wrote:
  So, if there is a problem within a particular application, that problem
  should also be fixed within the same application. If that isn't possible
  at all, then improvements in libopensc may be considered.
 
 Yes that is the situation. use_reader is an improvement in that is
 allows the calling module, cardmod, to pass in the handles that are to
 be used.

And how to use that feature? Something like that:

r = sc_ctx_use_reader(p15card-card-ctx, hSCardCtx, hSCard);

That would change the low level pcsc-handle of an existing p15card (i.e.
an emulator). The existing p15card would become connected with a
different physical card. Well, maybe like that:

r = sc_ctx_use_reader(card-ctx, hSCardCtx, hSCard);

Hmmm, card drivers do also cache some data (i.e. serial number).
Additionally a single card driver doesn't work for different kinds of
physical cards. What is left is that one:

r = sc_context_create(ctx, parm);  /* followed by */
r = sc_ctx_use_reader(ctx, hSCardCtx, hSCard);

Feel free to extent this list with your intended use cases.

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] sc_ctx_detect_readers patch

2011-02-07 Thread Andre Zepezauer

On Mon, 2011-02-07 at 11:32 -0600, Douglas E. Engert wrote:
 
 On 2/4/2011 2:20 AM, Martin Paljak wrote:
 
  I think Douglas is incrementally working on the existing codebase. Why the 
  cardmod
   driver was squeezed into reader-pcsc.c the way it is in the first place is 
 beyond
   me, as Francois noted, I was not very hot about it [1].
 
 
 Yes, I am trying to work with the current code base. The missing piece is 
 passing
 in the two handles from the cardmod.c to the reader-pcsc.c cardmod code.
 The use of the use_reader and sc_ctx_use_reader can do this.

Have a look at the attached patch.

1. It uses the init() function of reader-drivers to pass in additional
arguments.

2. It adds two fields to sc_context_param_t to let the caller of
sc_context_create() provide its own custom driver. How that is to be
used is shown in the diff of src/cardmod/cardmod.c

Additionally a stripped down reader-pcsc (renamed to reader-cardmod) is
attached. It works well with a modified version of opensc-pkcs11.so and
should work in the same way for cardmod. Integration into the build
system is still required and possibly some debugging.

Regards
Andre
Index: src/libopensc/reader-pcsc.c
===
--- src/libopensc/reader-pcsc.c	(revision 5188)
+++ src/libopensc/reader-pcsc.c	(working copy)
@@ -612,7 +612,7 @@
 	0, 0, NULL
 };
 
-static int pcsc_init(sc_context_t *ctx)
+static int pcsc_init(void *init_data, sc_context_t *ctx)
 {
 	struct pcsc_global_private_data *gpriv;
 	scconf_block *conf_block = NULL;
@@ -1580,7 +1580,7 @@
 	0, 0, NULL
 };
 
-static int cardmod_init(sc_context_t *ctx)
+static int cardmod_init(void *init_data, sc_context_t *ctx)
 {
 	struct pcsc_global_private_data *gpriv;
 	scconf_block *conf_block = NULL;
Index: src/libopensc/ctx.c
===
--- src/libopensc/ctx.c	(revision 5188)
+++ src/libopensc/ctx.c	(working copy)
@@ -105,6 +105,7 @@
 	/* The default driver should be last, as it handles all the
 	 * unrecognized cards. */
 	{ default,	(void *(*)(void)) sc_get_default_driver },
+	{ iso7816,(void *(*)(void)) sc_get_iso7816_driver },
 	{ NULL, NULL }
 };
 
@@ -648,21 +649,20 @@
 		return SC_ERROR_OUT_OF_MEMORY;
 	}
 
+	if (parm-reader_drv != NULL) {
+		ctx-reader_driver = parm-reader_drv;
+	} else {
 #ifdef ENABLE_PCSC
 	ctx-reader_driver = sc_get_pcsc_driver();
-	#ifdef ENABLE_CARDMOD
-	if(strcmp(ctx-app_name, cardmod) == 0) {
-		ctx-reader_driver = sc_get_cardmod_driver();
-	}
-	#endif
 #elif ENABLE_CTAPI
 	ctx-reader_driver = sc_get_ctapi_driver();
 #elif ENABLE_OPENCT
 	ctx-reader_driver = sc_get_openct_driver();
 #endif
+	}
 
 	load_reader_driver_options(ctx);
-	ctx-reader_driver-ops-init(ctx);
+	ctx-reader_driver-ops-init(parm-reader_drv_init_data, ctx);
 	
 	load_card_drivers(ctx, opts);
 	load_card_atrs(ctx);
Index: src/libopensc/reader-ctapi.c
===
--- src/libopensc/reader-ctapi.c	(revision 5188)
+++ src/libopensc/reader-ctapi.c	(working copy)
@@ -499,7 +499,7 @@
 	return -1;
 }
 
-static int ctapi_init(sc_context_t *ctx)
+static int ctapi_init(void *init_data, sc_context_t *ctx)
 {
 	int i;
 	struct ctapi_global_private_data *gpriv;
Index: src/libopensc/reader-openct.c
===
--- src/libopensc/reader-openct.c	(revision 5188)
+++ src/libopensc/reader-openct.c	(working copy)
@@ -64,7 +64,7 @@
  * is loaded
  */
 static int
-openct_reader_init(sc_context_t *ctx)
+openct_reader_init(void *init_data, sc_context_t *ctx)
 {
 	unsigned int	i,max_virtual;
 	scconf_block *conf_block;
Index: src/libopensc/opensc.h
===
--- src/libopensc/opensc.h	(revision 5188)
+++ src/libopensc/opensc.h	(working copy)
@@ -250,7 +250,7 @@
 #define SC_PROTO_RAW		0x1000
 #define SC_PROTO_ANY		0x
 
-struct sc_reader_driver {
+typedef struct sc_reader_driver {
 	const char *name;
 	const char *short_name;
 	struct sc_reader_operations *ops;
@@ -258,7 +258,7 @@
 	size_t max_send_size; /* Max Lc supported by the reader layer */
 	size_t max_recv_size; /* Mac Le supported by the reader layer */
 	void *dll;
-};
+} sc_reader_driver_t;
 
 /* reader flags */
 #define SC_READER_CARD_PRESENT		0x0001
@@ -359,7 +359,7 @@
 struct sc_reader_operations {
 	/* Called during sc_establish_context(), when the driver
 	 * is loaded */
-	int (*init)(struct sc_context *ctx);
+	int (*init)(void *init_data, struct sc_context *ctx);
 	/* Called when the driver is being unloaded.  finish() has to
 	 * release any resources. */
 	int (*finish)(struct sc_context *ctx);
@@ -692,6 +692,10 @@
 	unsigned long flags;
 	/** mutex functions to use (optional) */
 	sc_thread_context_t *thread_ctx;
+	/** custom reader driver or NULL for default driver **/
+	sc_reader_driver_t *reader_drv;
+	/** initial data **/
+	void *reader_drv_init_data;

Re: [opensc-devel] sc_ctx_detect_readers patch

2011-02-07 Thread Andre Zepezauer

On Mon, 2011-02-07 at 14:27 -0600, Douglas E. Engert wrote:
 
 On 2/7/2011 11:26 AM, Douglas E. Engert wrote:
 
 
  On 2/3/2011 11:58 PM, Martin Paljak wrote:
 
  On Feb 3, 2011, at 10:04 PM, Douglas E. Engert wrote:
 
  I would consider using a new hook, like use_reader or  
  use_pcsc_parameters to
  send the arguments to reader-pcsc.c and set the (pcsc, not cardmod) driver 
  to
  cardmod state. The reader operations API is by no means set in stone.
  Nor is there need to abstract it away too much, the usage pattern is
  known and the code path to implement it should be as simple as possible
  (sc_XXX wrapper that will not be used by any other reader driver, like
  sc_cancel and sc_wait_for_event are examples of somewhat bad ideas.
  Yet it is a working pattern.)
 
  I agree, a new entry point use_reader would work. I will look at adding such
  and entry point that will be ignored by the other drivers, and callable
  as sc_ctx_use_reader(ctx, void *, void *)
 
 
 Attached is a patch that implements a sc_ctx_use_reader, to pass in two void
 pointers to an underling driver. The code to use this from cardmod.c to the
 cardmod code in reader-pcsc.c (or where ever it ends up) will be added as part
 of a much larger patch.
 
 The intent is to keep this sc_ctx_use_reader patch simple and small so it
 can be committed soon.

The essence of both proposals side-by-side¹:

Patch A: Index: src/libopensc/opensc.h
===
--- src/libopensc/opensc.h  (revision 5188)
+++ src/libopensc/opensc.h  (working copy)
@@ -359,7 +359,7 @@
 struct sc_reader_operations {
/* Called during sc_establish_context(), when the driver
 * is loaded */
-   int (*init)(struct sc_context *ctx);
+   int (*init)(struct sc_context *ctx, void *init_data);


Patch B: Index: src/libopensc/opensc.h
===
--- src/libopensc/opensc.h  (revision 5187)
+++ src/libopensc/opensc.h  (working copy)
@@ -388,6 +388,8 @@
int timeout, void **reader_states);
/* Reset a reader */
int (*reset)(struct sc_reader *, int);
+   /* used to pass in reader handles in cardmod mode */
+   int (*use_reader)(struct sc_context *ctx, void * pcsc_context_handle, 
void * pcsc_card_handle);

Regards
Andre

[1] in chronological order of submission

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] sc_ctx_detect_readers patch

2011-02-07 Thread Andre Zepezauer

On Mon, 2011-02-07 at 16:00 -0600, Douglas E. Engert wrote:
  Attached is a patch that implements a sc_ctx_use_reader, to pass in two 
  void
  pointers to an underling driver. The code to use this from cardmod.c to the
  cardmod code in reader-pcsc.c (or where ever it ends up) will be added as 
  part
  of a much larger patch.
 
  The intent is to keep this sc_ctx_use_reader patch simple and small so it
  can be committed soon.
 
  The essence of both proposals side-by-side¹:
 
 Actually not.
 
 The use_reader version can be called multiple times to change the handles
 as this  is one of the major issues I found with the way the BaseCSP calls
 the cardmod. The cardmod.c can then call sc_ctx_use_reader just after
 the call to sc_context_create, and can call it later if the BaseCSP
 provides different handles.

Why not calling sc_context_create() for every pair of hSCardCtx,hSCard
the cardmod is unaware of? From a context created in that way a new
p15card can be instantiated. And that would let to a nice one-to-one
mapping between hSCardCtx,hSCard and p15cards.

From a pair of hSCardCtx,hSCard (provided with every call) you can
then easily lookup the right p15card. And everything else goes as usual.

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] emulation dll for DNIe

2011-02-07 Thread Andre Zepezauer

On Fri, 2011-02-04 at 23:31 +0100, Juan Antonio Martinez wrote:
 About visibility of certificates and keys patch, notice that 
 DNIe requires the user to enter pin for just read (neither
 signature nor authentication) user certificates. It's not 
 standard, I know, but seems to be a very common issue in 
 some cards

I didn't know that, but it's addressed in the attached patch.
Index: src/libopensc/pkcs15-dnie.c
===
--- src/libopensc/pkcs15-dnie.c	(revision 223)
+++ src/libopensc/pkcs15-dnie.c	(working copy)
@@ -195,22 +195,12 @@
  /* Perform required fixes */
  p15_obj = p15card-obj_list;
  while (p15_obj != NULL) {
-  /* Add 'auth_id' to private keys */
-  if ((p15_obj-type  SC_PKCS15_TYPE_CLASS_MASK) == SC_PKCS15_TYPE_PRKEY) {
+  /* Add missing 'auth_id' to private objects */
+  if ((p15_obj-flags  SC_PKCS15_CO_FLAG_PRIVATE)  (p15_obj-auth_id.len == 0)) {
p15_obj-auth_id.value[0] = 0x01;
p15_obj-auth_id.len = 1;
   }
-#if 0
-  /* Unset flags 'private, modifiable' on public keys */
-  if ((p15_obj-type  SC_PKCS15_TYPE_CLASS_MASK) == SC_PKCS15_TYPE_PUBKEY) {
-   p15_obj-flags = ~(SC_PKCS15_CO_FLAG_PRIVATE | SC_PKCS15_CO_FLAG_MODIFIABLE);
-  }
 
-  /* Unset flags 'private, modifiable' on certificates */
-  if ((p15_obj-type  SC_PKCS15_TYPE_CLASS_MASK) == SC_PKCS15_TYPE_CERT) {
-   p15_obj-flags = ~(SC_PKCS15_CO_FLAG_PRIVATE | SC_PKCS15_CO_FLAG_MODIFIABLE);
-  }
-#endif
   p15_obj = p15_obj-next;
  }
 
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] emulation dll for DNIe

2011-02-07 Thread Andre Zepezauer

On Tue, 2011-02-08 at 03:16 +0100, Juan Antonio Martinez wrote:
 El lun, 07-02-2011 a las 23:58 +0100, Andre Zepezauer escribió:
  On Fri, 2011-02-04 at 23:31 +0100, Juan Antonio Martinez wrote:
   About visibility of certificates and keys patch, notice that 
   DNIe requires the user to enter pin for just read (neither
   signature nor authentication) user certificates. It's not 
   standard, I know, but seems to be a very common issue in 
   some cards
  
  I didn't know that, but it's addressed in the attached patch.
 
 Worked fine. Applied. Thanks (again :-) 
 Also, problems with DODF addressed files have gone away
 
 FYI: DNIe driver is in the final testing stage. Just hunting 
 the last wild pointer (well, Buffer too small bug ) in
 dnie_compute_signature()...

Please provide full logs!

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] sc_ctx_detect_readers patch

2011-02-04 Thread Andre Zepezauer

On Fri, 2011-02-04 at 07:58 +0200, Martin Paljak wrote:
 On Feb 3, 2011, at 10:04 PM, Douglas E. Engert wrote:
 
  I have updates #321 with a new version of the cardmod patch
  and would like to start to commit it in pieces.
  
  Piece 1 is the attachment I sent on 1/28 as new.martin.patch
  based on Martin's patch from 1/19. This was the patch that would
  work for Brian. The main change is adding two parameters to all
  the *_detect_readers routines.  Martin's patch already required these
  to be added in a number of places.
  
  Is there any objection to adding this patch now?
 
 I would consider using a new hook, like use_reader or  
 use_pcsc_parameters to send the arguments to reader-pcsc.c and set the 
 (pcsc, not cardmod) driver to cardmod state. The reader operations API is 
 by no means set in stone. Nor is there need to abstract it away too much, the 
 usage pattern is known and the code path to implement it should be as simple 
 as possible (sc_XXX wrapper that will not be used by any other reader driver, 
 like sc_cancel and sc_wait_for_event are examples of somewhat bad ideas. 
 Yet it is a working pattern.)

Attachment shows a different approach. It's not a complete solution but
should be sufficient to demonstrate an alternative method of
SCARDCONTEXT passing.

Regards
Andre
Index: src/libopensc/reader-pcsc.c
===
--- src/libopensc/reader-pcsc.c	(revision 5127)
+++ src/libopensc/reader-pcsc.c	(working copy)
@@ -1900,6 +1900,20 @@
 	SC_FUNC_RETURN(ctx, SC_LOG_DEBUG_VERBOSE, ret);
 }
 
+int sc_cardmod_set_ctx(sc_reader_t *reader, SCARDCONTEXT hSCardCtx, SCARDHANDLE hSCard)
+{
+	struct pcsc_private_data *priv;
+
+	if (reader == NULL || strcmp(reader-driver-name, cardmod) != 0)
+		return SC_ERROR_INVALID_ARGUMENTS;
+
+	priv = GET_PRIV_DATA(reader);
+	priv-gpriv-pcsc_ctx = hSCardCtx;
+	priv-pcsc_card = hSCard;
+
+	return SC_SUCCESS;
+}
+
 struct sc_reader_driver * sc_get_cardmod_driver(void)
 {
 
Index: src/cardmod/cardmod.c
===
--- src/cardmod/cardmod.c	(revision 5127)
+++ src/cardmod/cardmod.c	(working copy)
@@ -1454,6 +1454,14 @@
 			vs-reader = sc_ctx_get_reader(vs-ctx, 0);
 			if(vs-reader)
 			{
+r = sc_cardmod_set_ctx(vs-reader, pCardData-hSCardCtx, pCardData-hScard);
+if (r != SC_SUCCESS)
+{
+	logprintf(pCardData, 0, );
+	/* TODO: free allocated resources */
+	return SCARD_F_UNKNOWN_ERROR;
+}
+
 logprintf(pCardData, 3, %s\n, NULLSTR(vs-reader-name));
 	
 r = sc_connect_card(vs-reader, (vs-card));
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] DNIe driver: Needs Information on writing pkcs15-xxxx files

2011-02-03 Thread Andre Zepezauer

On Thu, 2011-02-03 at 12:03 +0100, jons...@terra.es wrote:
 Hi All:
 
 I've concluded that DNIe card is not so pkcs15 compliant as
 promissed... 
 I think I need rewriting of several file permissions and paths, as
 information
 provided in card pkcs15 structure seems to be wrong or incomplete
 
 I've studying the source code of provided drivers, but still unsure on
 how to process.
 
 Is there any kind of information about how to write pkcs15-xxx files?
 specifically, 
 to specify visibility flags of public keys and rewriting paths in CDF
 file

Please send the following dumps:
pkcs15-tool -D
opensc-tool -f

Explain what should be fixed. If there are only minor issues (i.e. some
wrong flags or paths) then you can go with a very lightweight emulator.
I will explain later.

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] r5124

2011-02-03 Thread Andre Zepezauer

On Thu, 2011-02-03 at 14:36 +0200, Martin Paljak wrote:
 Hello,
 
 On Thu, Jan 27, 2011 at 20:08, Andre Zepezauer
 andre.zepeza...@student.uni-halle.de wrote:
  Hello Martin,
 
  some comments on r5124:
 
  1. The values of pin_info-reference and prkey_info-key_reference
  shouldn't be compared because:
 
  * pin_info-reference is used as P2 parameter in VERIFY command
  * prkey_info-key_reference is used in MSE SET tag 0x84
 
 OK, I see your point.
 Looking at your patch: could it be extracted into a small lookup
 function like the current one that is used? such a small lookup
 function with a small doxygen doc would look really nice.

That patch could be some lines shorter when using
sc_pkcs15_compare_id(). Additionally that would improve readability.

I don't know what kind of function you did mean. Extracting only that
patch into a new function?

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] DNIe driver: Needs Information on writing pkcs15-xxxx files

2011-02-03 Thread Andre Zepezauer

Hello Juan Antonio,

attached tar file contains an external loadable emulator. Most things in
it are written to the information I got from your 'pkcs15-tool -D' dump.
But don't expect it to work instantly.

I assumed following locations:
* EF.TokenInfo 3F005032
* EF.ODF 3F005031

Maybe put an 'exit(0)' at the end of the 'bind' function and use
'OPENSC_DEBUG=9'. I mean until you got that stuff loaded correctly.

Post your new logs when the emulator is working or ask questions if
there are problems in getting it loaded.

Regards
Andre


dnie.tar
Description: Unix tar archive
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] DNIe driver: Needs Information on writing pkcs15-xxxx files

2011-02-03 Thread Andre Zepezauer

On Thu, 2011-02-03 at 16:15 +0100, Andre Zepezauer wrote:
 Hello Juan Antonio,
 
 attached tar file contains an external loadable emulator. Most things in
 it are written to the information I got from your 'pkcs15-tool -D' dump.
 But don't expect it to work instantly.
 
 I assumed following locations:
   * EF.TokenInfo 3F005032
   * EF.ODF 3F005031
 
 Maybe put an 'exit(0)' at the end of the 'bind' function and use
 'OPENSC_DEBUG=9'. I mean until you got that stuff loaded correctly.

I was talking about that 'bind' function:

Index: src/libopensc/pkcs15.c
===
--- src/libopensc/pkcs15.c  (revision 5126)
+++ src/libopensc/pkcs15.c  (working copy)
@@ -959,12 +959,14 @@
goto error;
}
 done:
+   exit(0);
fix_starcos_pkcs15_card(p15card);
 
*p15card_out = p15card;
sc_unlock(card);
SC_FUNC_RETURN(ctx, SC_LOG_DEBUG_NORMAL, SC_SUCCESS);
 error:
+   exit(0);
sc_unlock(card);
sc_pkcs15_card_free(p15card);
SC_FUNC_RETURN(ctx, SC_LOG_DEBUG_NORMAL, r);


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] sc_ctx_detect_readers patch

2011-02-03 Thread Andre Zepezauer

On Thu, 2011-02-03 at 14:04 -0600, Douglas E. Engert wrote:
 I have updates #321 with a new version of the cardmod patch
 and would like to start to commit it in pieces.
 
 Piece 1 is the attachment I sent on 1/28 as new.martin.patch
 based on Martin's patch from 1/19. This was the patch that would
 work for Brian. The main change is adding two parameters to all
 the *_detect_readers routines.  Martin's patch already required these
 to be added in a number of places.
 
 Is there any objection to adding this patch now?

Yes, why you want to call 'sc_context_create()' altogether. There is not
much functionality in it. So you could easily implement the required
initialisation in 'CardAcquireContext()'.

Next point is reader-pcsc.c: Why do you belief that squeezing in a
second driver namely cardmod is a good idea? Why not implement a new
one? Read the documents provided by Microsoft. Most things are managed
by the CSP framework and therefore a reader-cardmod would be straight
forward consisting mostly of stub functions.

To make things short: Not calling 'sc_context_create()' and implementing
a new reader-driver would make your proposal obsolete.

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] emu

2011-02-03 Thread Andre Zepezauer

 Ok, now module loads... but fails on locating pkcs15 files, 
 as rsc_pkcs15_make_absolute_path() removes 5015 on _every_ 
 file...
 
 FYI: I know about these paths:
 
 These are (afaik) standard locations:
 3F00: DF Master.File
 3F005015: DF PKCS15 App
 3F0050155031: EF ODF
 3F0050155032: EF Tokeninfo
 3F0050155033: EF Unused
 3F0050156000: EF AODF
 3F0050156001: EF PRKDF
 3F0050156002: EF PUKDF
 3F0050156004: EF CDF
 3F0050156005: EF DODF
 
 These are DNIe specific, addressed by above pkcs15 files,
 and shows the relative path problem

No problem. Remove that 'rsc_pkcs15_make_absolute_path()' hack and try
the attached file instead. If it isn't working, then send output of
opensc-tool -s 00:A4:08:00:04:50:15:50:31:00 -s 00:B0:00:00:00.
#include stdlib.h
#include string.h
#include ../config.h
#include libopensc/log.h
#include libopensc/asn1.h
#include libopensc/pkcs15.h


/* Card driver related */

static
int match_card(struct sc_card *card)
{
	/* Do card recognition here */

	return 1;
}


/* Helper functions to get the pkcs15 stuff bound. */

static
int dump_ef(sc_card_t *card, const char *path, u8 *buf, size_t *buf_len) {
	int rv;
	sc_file_t *file = sc_file_new();
	sc_format_path(path, file-path);
	sc_select_file(card, file-path, file);
	if (file-size  *buf_len)
		return SC_ERROR_BUFFER_TOO_SMALL;
	rv = sc_read_binary(card, 0, buf, file-size, 0);
	if (rv  0)
		return rv;
	*buf_len = rv;

	return SC_SUCCESS;
}

static const struct sc_asn1_entry c_asn1_odf[] = {
{ privateKeys, SC_ASN1_STRUCT, SC_ASN1_CTX | 0 | SC_ASN1_CONS, 0, NULL, NULL },
{ publicKeys,  SC_ASN1_STRUCT, SC_ASN1_CTX | 1 | SC_ASN1_CONS, 0, NULL, NULL },
{ trustedPublicKeys,   SC_ASN1_STRUCT, SC_ASN1_CTX | 2 | SC_ASN1_CONS, 0, NULL, NULL },
{ secretKeys,  SC_ASN1_STRUCT, SC_ASN1_CTX | 3 | SC_ASN1_CONS, 0, NULL, NULL },
{ certificates,SC_ASN1_STRUCT, SC_ASN1_CTX | 4 | SC_ASN1_CONS, 0, NULL, NULL },
{ trustedCertificates, SC_ASN1_STRUCT, SC_ASN1_CTX | 5 | SC_ASN1_CONS, 0, NULL, NULL },
{ usefulCertificates,  SC_ASN1_STRUCT, SC_ASN1_CTX | 6 | SC_ASN1_CONS, 0, NULL, NULL },
{ dataObjects, SC_ASN1_STRUCT, SC_ASN1_CTX | 7 | SC_ASN1_CONS, 0, NULL, NULL },
{ authObjects, SC_ASN1_STRUCT, SC_ASN1_CTX | 8 | SC_ASN1_CONS, 0, NULL, NULL },
{ NULL, 0, 0, 0, NULL, NULL }
};

static const unsigned int odf_indexes[] = {
SC_PKCS15_PRKDF,
SC_PKCS15_PUKDF,
SC_PKCS15_PUKDF_TRUSTED,
SC_PKCS15_SKDF,
SC_PKCS15_CDF,
SC_PKCS15_CDF_TRUSTED,
SC_PKCS15_CDF_USEFUL,
SC_PKCS15_DODF,
SC_PKCS15_AODF,
};


static
int parse_odf(const u8 * buf, size_t buflen, struct sc_pkcs15_card *p15card)
{
const u8 *p = buf;
size_t left = buflen;
int r, i, type;
sc_path_t path;
struct sc_asn1_entry asn1_obj_or_path[] = {
{ path, SC_ASN1_PATH, SC_ASN1_CONS | SC_ASN1_SEQUENCE, 0, path, NULL },
{ NULL, 0, 0, 0, NULL, NULL }
};
struct sc_asn1_entry asn1_odf[10];

	sc_path_t *path_prefix = calloc(1, sizeof(sc_path_t));
	sc_format_path(3F005015, path_prefix);
	
sc_copy_asn1_entry(c_asn1_odf, asn1_odf);
for (i = 0; asn1_odf[i].name != NULL; i++)
sc_format_asn1_entry(asn1_odf + i, asn1_obj_or_path, NULL, 0);
while (left  0) {
r = sc_asn1_decode_choice(p15card-card-ctx, asn1_odf, p, left, p, left);
if (r == SC_ERROR_ASN1_END_OF_CONTENTS)
break;
if (r  0)
return r;
type = r;
r = sc_pkcs15_make_absolute_path(path_prefix, path);
if (r  0)
return r;
r = sc_pkcs15_add_df(p15card, odf_indexes[type], path, NULL);
if (r)
return r;
}
return 0;
}


/***/
/* Public Module Functions */
/***/

const char *sc_driver_version() {
return PACKAGE_VERSION;		/* defined in config.h of OpenSC */
}


int bind(sc_pkcs15_card_t *p15card, sc_pkcs15emu_opt_t *options)
{
	u8 buf[1024];
	sc_pkcs15_df_t *df;
	sc_pkcs15_object_t *p15_obj;
	size_t len = sizeof(buf);
	int rv;

	/* Check for correct card driver (i.e. iso7816) */
	if (strcmp(p15card-card-driver-short_name, iso7816) != 0)
		return SC_ERROR_WRONG_CARD;

	/* Check for correct card */
	if (match_card(p15card-card) != 1)
		return SC_ERROR_WRONG_CARD;

	/* Set root path of this application */
	p15card-file_app = sc_file_new();
	sc_format_path(3F00, p15card-file_app-path);

	/* Load TokenInfo */
	rv = dump_ef(p15card-card, 3F0050155032, buf, len);
	if (rv != SC_SUCCESS) {
		sc_debug(p15card-card-ctx, SC_LOG_DEBUG_NORMAL, Reading of EF.TOKENINFO failed: %d, rv);
		return rv;
	}
	rv = sc_pkcs15_parse_tokeninfo(p15card-card-ctx, p15card-tokeninfo, buf,

Re: [opensc-devel] sc_ctx_detect_readers patch

2011-02-03 Thread Andre Zepezauer

 Its not a straight forward as you might think. Have you tried reading the 135
 page Windows Smart Card Minidriver Specification?
 http://www.microsoft.com/whdc/device/input/smartcard/sc-minidriver.mspx

At least in so far to get a picture of the workings. And my impression
is, that all the state management of cards is handled by the framework
and thus the reader-driver is only required to do I/O (i.e. send/receive
APDU:s).

BTW: The main handle in OpenSC is 'sc_pkcs15_card_t' and not
'sc_context_t'. In fact 'sc_context_t' is really unimportant. But
sc_pkcs15_card_t holds all the operational state the is required to make
things working. Have a look at VENDOR_SPECIFIC, there is only one OpenSC
specific field needed.

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] sc_ctx_detect_readers patch

2011-02-03 Thread Andre Zepezauer

On Thu, 2011-02-03 at 15:55 -0600, Douglas E. Engert wrote:
 
 On 2/3/2011 3:14 PM, Andre Zepezauer wrote:
  On Thu, 2011-02-03 at 14:04 -0600, Douglas E. Engert wrote:
  I have updates #321 with a new version of the cardmod patch
  and would like to start to commit it in pieces.
 
  Piece 1 is the attachment I sent on 1/28 as new.martin.patch
  based on Martin's patch from 1/19. This was the patch that would
  work for Brian. The main change is adding two parameters to all
  the *_detect_readers routines.  Martin's patch already required these
  to be added in a number of places.
 
  Is there any objection to adding this patch now?
 
  Yes, why you want to call 'sc_context_create()' altogether. There is not
  much functionality in it. So you could easily implement the required
  initialisation in 'CardAcquireContext()'.
 
 I disagree there is a lot of functionality in it. It main functions is to
 read the config files, and other initialization needed by OpenSC, and that
 is more then enough to justify calling it.

I got it. The whole file ctx.c is basically one single function, that is
scattered into a lot of small functions, which are mostly called once.
The fact that most of these functions are 'static' makes it even more
interesting. So, it seem that calling 'sc_context_create()' is really
required.

There is still the option to separate reader-pcsc and reader-cardmod.
That this would be the best solution shows the following example:

1. A Mini-Driver doesn't need to detect readers at all. Thus it should
define driver-ops-detect_readers = NULL. That's the trick.
2. Looking at 'detect_readers' of the current driver looks like rocket
science [1]. IMO there is something fundamentally wrong. 

Regards
Andre

[1] 
http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/reader-pcsc.c#L1662


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] pkcs15-tool -D vs pkcs11-tool -O

2011-02-02 Thread Andre Zepezauer

On Tue, 2011-02-01 at 23:17 +0100, Juan Antonio Martinez wrote:
 El mar, 01-02-2011 a las 20:18 +0100, Andre Zepezauer escribió:
  Hello Juan Antonio,
  
  On Mon, 2011-01-31 at 20:15 +0100, Juan Antonio Martinez wrote:
   Any hint to start debugging?
  If you are using opensc-trunk, then try this one:
 
 Great!! works fine for me. Thanks a lot. 
 
 Please, commit patch to opensc-trunk repository... 

Better to unset the 'private' flag on public keys. Then everything
should work as expected without any commit.

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] pkcs15-tool -D vs pkcs11-tool -O

2011-02-01 Thread Andre Zepezauer

Hello Juan Antonio,

On Mon, 2011-01-31 at 20:15 +0100, Juan Antonio Martinez wrote:
 Any hint to start debugging?

If you are using opensc-trunk, then try this one:

Index: pkcs11/framework-pkcs15.c
===
--- pkcs11/framework-pkcs15.c   (revision 5125)
+++ pkcs11/framework-pkcs15.c   (working copy)
@@ -2834,7 +2834,13 @@
case CKA_MODULUS:
return get_modulus(pubkey-pub_data, attr);
case CKA_MODULUS_BITS:
-   return get_modulus_bits(pubkey-pub_data, attr);
+   if (pubkey-pub_info) {
+   check_attribute_buffer(attr, sizeof(CK_ULONG));
+   *(CK_ULONG *) attr-pValue = (CK_ULONG) 
pubkey-pub_info-modulus_length;
+   return CKR_OK;
+   } else {
+   return get_modulus_bits(pubkey-pub_data, attr);
+   }
case CKA_PUBLIC_EXPONENT:
return get_public_exponent(pubkey-pub_data, attr);
case CKA_VALUE:

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] r5124

2011-01-27 Thread Andre Zepezauer

Hello Martin,

some comments on r5124:

1. The values of pin_info-reference and prkey_info-key_reference
shouldn't be compared because:

* pin_info-reference is used as P2 parameter in VERIFY command
* prkey_info-key_reference is used in MSE SET tag 0x84

There is no relation between these two values. See PKCS#15 for the
meaning of these attributes and attachment for another solution.

2. The Authentication-Objects can have two authId attributes because:

* they can protect objects (this is 
CommonAuthenticationObjectAttributes-authId)
* they could be protected by another PIN i.e. for unblocking purpose
  (this is CommonObjectAttributes-authId)

3. User consent for PIN objects does make sense i.e. for unblocking purpose

4. There is also a ticket relating to pin re-validation (#293).

Regards
Andre
Index: src/libopensc/pkcs15-pin.c
===
--- src/libopensc/pkcs15-pin.c	(revision 5124)
+++ src/libopensc/pkcs15-pin.c	(working copy)
@@ -499,12 +499,21 @@
 		return;
 	}
 
-	/* If the PIN protects a private key with user consent, don't cache it */
-	if (sc_pkcs15_find_prkey_by_reference(p15card, NULL, pin_info-reference, obj) == SC_SUCCESS) {
-		if (obj-user_consent) {
-			sc_debug(ctx, SC_LOG_DEBUG_NORMAL, Not caching a PIN protecting a key with user consent);
-			return;
+	/* If the PIN protects an object with user consent, don't cache it */
+	obj = p15card-obj_list;
+	while (obj != NULL) {
+		if (obj-auth_id.len == pin_info-auth_id.len) {
+			if (memcmp(obj-auth_id.value, pin_info-auth_id.value, pin_info-auth_id.len) == 0) {
+/* When we get here, then 'obj' is protected by this PIN */
+if (obj-user_consent  0) {
+	sc_debug(ctx, SC_LOG_DEBUG_NORMAL,
+		Not caching a PIN protecting an object with user consent);
+	return;
+}
+			}
 		}
+
+		obj = obj-next;
 	}
 
 	r = sc_pkcs15_allocate_object_content(pin_obj, pin, pinlen);
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Braking change in OpenSC 0.12.0 tokenInfo

2011-01-22 Thread Andre Zepezauer

On Sat, 2011-01-22 at 15:42 +0200, Martin Paljak wrote:
 On Jan 21, 2011, at 9:33 AM, Aventra wrote:
  Could this fix that Andre has proposed be committed to trunk?
  It should work for all cards, since it only makes two elements of the 
  TokenInfo optional.
 Yes, but I'm not able to directly locate the relevant part in the ASN.1 
 description (for objId) that tell they are optional that I could reference in 
 the commit message.
 
 If you can speed that up would help.

From A. ASN.1 module (page 65):

AlgorithmInfo ::= SEQUENCE {
reference   Reference,
algorithm   PKCS15-ALGORITHM.id({AlgorithmSet}),
parameters  
PKCS15-ALGORITHM.Parameters({AlgorithmSet}{@algorithm}),
supportedOperations 
PKCS15-ALGORITHM.Operations({AlgorithmSet}{@algorithm}),
algId   
PKCS15-ALGORITHM.objectIdentifier({AlgorithmSet}{@algorithm}) OPTIONAL,
algRef  Reference OPTIONAL
}

In addition to the proposed patch a mechanism is required, so that the
absence of these two fields could be noticed. That is because
sc_supported_algo_info.algo_ref [1] will always hold a value. The
question is, if that value is valid?

In the case of the absence of algRef in AlgorithmInfo (see above) the
value of sc_supported_algo_info.algo_ref [1] is invalid.

Definition of Reference:
pkcs15-ub-reference INTEGER ::= 255
Reference ::= INTEGER (0..pkcs15-ub-reference)

[1] 
http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/opensc.h#L148


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] IAS ECC

2011-01-17 Thread Andre Zepezauer

Hello Viktor,

from Changeset 5094 [1]:
[...] 'path' is [now] mandatory for the 'Local' PINs.

I think of it as a temporary solution to fix a weakness of IAS ECC
cards as specified by The Gixel Group [2]. But keep in mind that the
behaviour up to revision 4927 was conforming with PKCS#15 and ISO
7816-15. After your changes [3] that isn't the case any longer. 

As stated in another thread [4] it will break Java Cards and you should
be prepared to move that hack into an emulator.

Regards
Andre

[1] http://www.opensc-project.org/opensc/changeset/5094
[2] 
http://www.gixel.fr/includes/cms/_contenus/bibliotheque/file/CAP%20/IAS%20ECC%20v1_0_1UK.pdf
[3] 
http://www.opensc-project.org/opensc/changeset?reponame=new=5094%40trunk%2Fsrc%2Flibopensc%2Fpkcs15-pin.cold=4927%40trunk%2Fsrc%2Flibopensc%2Fpkcs15-pin.c
[4] 
http://www.opensc-project.org/pipermail/opensc-devel/2011-January/015697.html


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] r5081

2011-01-16 Thread Andre Zepezauer

On Sun, 2011-01-16 at 11:58 +0100, Viktor TARASOV wrote:
  There you can find the semantics of the SELECT command defined for Java
  Cards. Read section 3 Java Card Applet Lifetime especially 3.2 and
  3.4. Hopefully the following becomes more clear.
 
 Unfortunately not. I found nothing that can be related to the main topic.
 
 To resume the main topic:
 PKCS#15, when describing 'local' PINs, uses the term 'given application'.
 The sense of existence of the 'local' PIN is to protect data within this 
 application.
 Opensc pkcs15 framework should have the complete description of the PIN usage.
 That's why the path to 'given application' is mandatory for the 'local' PINs 
 and has to be present in sc_pkcs15_pin_info data type .
 If local PINs have no 'path' defined in PinAttributes.path, I propose to 
 derive it from the pkcs#15 context .

That patch is not required. From PKCS#15 6.8.2 Pin objects:
PinAttributes.path: Path to the DF in which the PIN resides. The path
 shall be selected by a host application before doing a PIN operation,
 in order to enable a suitable authentication context for the PIN
 operation. If not present, a card-holder verification must always be
 possible to perform without a prior `SELECT' operation.

To me it seems, that you want to fix just another bug for the broken
IAS/ECC cards. Why not writing an emulator for them to avoid pollution
of generic code with these undocumented hacks?

 It comes from itself that selection of the 'given application' has to precede 
 the access to the protected data within it.
 In any case it should not effect the PIN verification and further functioning 
 .
 (It's true also because technically the 'local' PIN is created inside this 
 application .)
 And, in spite of my multiple demands, I have not seen explication of how 
 technically it can have an effect .
 
 Your reference to the ticket 252 do not brings more. I don't see how it can 
 be related to the main topic.

 Local PIN with no path required.
 2. Have you seen such a card ? Can you post here it's AODF ?
 Have a look at [1]. There you will find an example.

 For me this ticket is about some on-card object protected by obscure PIN that 
 is not present in AODF of the card and
 that's the reason of 'erase' failure. If you see more, you would have to 
 expose more detailed explication.
 
 I stop here, thanks.
 
 Kind wishes,
 Viktor.

[1] http://www.opensc-project.org/opensc/ticket/252


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] r5081

2011-01-14 Thread Andre Zepezauer

On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote:
 Hello Andre,
 
 On 14.01.2011 04:24, Andre Zepezauer wrote:
  please have a look at PKCS#15 6.8.2 Pin objects for the definition of
  local and global PIN objects. There is no mention of storage location.
 There is mention of 'path'.
 The difference between 'global' and 'local' is that the first one can be 
 verified from any location on the card,
 the second one is 'visible' only from somewhere under the DF (or application) 
 where it's defined.
 
 So, we need (or, if you like, it's useful) to have 'path' defined for the 
 local PINs, to be able to select it's path before verification.

From PKCS#15 6.8.2 Pin objects:
 PinAttributes.path: Path to the DF in which the PIN resides. The path shall 
be selected
  by a host application before doing a PIN operation, in order to enable a 
suitable
  authentication context for the PIN operation. If not present, a card-holder 
verification
  must always be possible to perform without a prior `SELECT' operation.

Regards
Andre


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] r5081

2011-01-14 Thread Andre Zepezauer

On Fri, 2011-01-14 at 14:14 +0100, Viktor TARASOV wrote:
 On 14.01.2011 13:37, Andre Zepezauer wrote:
  On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote:
  Hello Andre,
 
  On 14.01.2011 04:24, Andre Zepezauer wrote:
  please have a look at PKCS#15 6.8.2 Pin objects for the definition of
  local and global PIN objects. There is no mention of storage location.
  There is mention of 'path'.
  The difference between 'global' and 'local' is that the first one can be 
  verified from any location on the card,
  the second one is 'visible' only from somewhere under the DF (or 
  application) where it's defined.
 
  So, we need (or, if you like, it's useful) to have 'path' defined for the 
  local PINs, to be able to select it's path before verification.
 
 My previous assumptions comes from this citation.
 It seems that I am terribly missing something. Can you give more details?
 
 
   From PKCS#15 6.8.2 Pin objects:
PinAttributes.path: Path to the DF in which the PIN resides. The path 
  shall be selected
 by a host application before doing a PIN operation, in order to enable a 
  suitable
 authentication context for the PIN operation.
 That's 'local' PIN.
 
  If not present, a card-holder verification
 must always be possible to perform without a prior `SELECT' operation.
 That's the global one.
 
 
 So we desperately need the 'path' for the local PINs. So that 'host 
 application' can select the path
 'before doing a PIN operation'.
 You probably know another way to do verification from the random location on 
 the card ?

Take Java Card with PKI applet as an example. Once the applet is
selected, it is possible to perform the VERIFY command from every
location within that applet. That's 'local' PIN too. Because it's only
valid for that applet but not for the whole card.

BTW care must be take with re-selecting an applet in Java Cards, because
it may invalidate all previously verified PINs.
 
Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Creation of card pkcs#15 structure

2011-01-14 Thread Andre Zepezauer

On Fri, 2011-01-14 at 17:42 +0200, Aventra wrote:
 Hi,
 
  From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel-
   Anybody can change the profile if they want to. We have defined a
 default
  profile for MyEID that suits common cases.
  
  Just for the sake of curiosity, can you post here an example of
 'protected'
  profile for MyEID card?
 
 We don't have that kind of profile, but somebody could make one if they
 like.
  
  
   What do you think, will it be sufficient, during the card
 initialization,
   to create all xDF files that have 'CREATE' protected by SOPIN ?
   What I mean is that OpenSC would create the whole structure defined in
 the
   profile, regardless of the ACL:s.
   I know that the driver can do this by itself, but why not implement it
 to
  OpenSC so that it would work for all cards?
  Personally I have no objections, but we cannot take rapid decision for all
 the
  cards. I don't know if actually somebody considers as useful
  to not create all xDFs (including rarely used DODF, SKDF, ). We'll be
 waiting
  for the other opinions.
  
  What can be done easily is a new profile option create-all-xDF. So that,
 you
  will have the possibility to do what you want in a non-intrusive for the
 other
  cards manner.
  
  Take also into consideration that all card profile are loaded after the
  general 'pkcs15.profile', where all xDF are defined.
  And so the list of xDFs to create is not completely controlled by the
 card's
  profile.
  
 OK, well then perhaps this should be implemented to the card driver.
 
  
   One thing it could do, is to check when initialization is done each of
 the
   known identifiers (PrKDF, PuKDF, CDF..),
   if these have been defined in the profile, it would create them.
  
   One additional feature that is lacking from OpenSC is that it does not
   create the PIN codes automatically (except the SO-PIN).
  Sorry I do not follow what you mean.
 
 I mean that currently when initializing a MyEID card you need to run the
 following commands:
 - pkcs15-init -C  /* create structure */
 - pkcs15-init -P -a 1 /* create user pin */
 - pkcs15-init -F  /* finalize (activate) card */

Looks like a simple shell script would be the right solution.

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] r5081

2011-01-14 Thread Andre Zepezauer

On Fri, 2011-01-14 at 16:00 +0100, Viktor TARASOV wrote:
 On 14.01.2011 15:17, Andre Zepezauer wrote:
  On Fri, 2011-01-14 at 14:14 +0100, Viktor TARASOV wrote:
  On 14.01.2011 13:37, Andre Zepezauer wrote:
  On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote:
  Hello Andre,
 
  On 14.01.2011 04:24, Andre Zepezauer wrote:
  please have a look at PKCS#15 6.8.2 Pin objects for the definition of
  local and global PIN objects. There is no mention of storage location.
  There is mention of 'path'.
  The difference between 'global' and 'local' is that the first one can be 
  verified from any location on the card,
  the second one is 'visible' only from somewhere under the DF (or 
  application) where it's defined.
 
  So, we need (or, if you like, it's useful) to have 'path' defined for 
  the local PINs, to be able to select it's path before verification.
  My previous assumptions comes from this citation.
  It seems that I am terribly missing something. Can you give more details?
 
 
   From PKCS#15 6.8.2 Pin objects:
 PinAttributes.path: Path to the DF in which the PIN resides. The path 
  shall be selected
  by a host application before doing a PIN operation, in order to 
  enable a suitable
  authentication context for the PIN operation.
  That's 'local' PIN.
 
  If not present, a card-holder verification
  must always be possible to perform without a prior `SELECT' 
  operation.
  That's the global one.
 
 
  So we desperately need the 'path' for the local PINs. So that 'host 
  application' can select the path
  'before doing a PIN operation'.
  You probably know another way to do verification from the random location 
  on the card ?
  Take Java Card with PKI applet as an example. Once the applet is
  selected, it is possible to perform the VERIFY command from every
  location within that applet. That's 'local' PIN too. Because it's only
  valid for that applet but not for the whole card.
 
 
 OK, let us adjust the terminology.
 I am talking about the PKCS#15 card. This card starts from some MF, where 
 exist EF.DIR, probably EF.ATR, ..., as well as application DFs.
 The AID of application DFs are present in the EF.DIR records.
 The global PINs are defined at the MF level or above, the local ones are 
 defined in application DFs.
 
 In my comprehension to create/use the PKCS#15 objects you don't need to jump 
 higher then MF, and thus to reset status of 'global' PINs.
 You have another vision, examples ?
 
 
  BTW care must be take with re-selecting an applet in Java Cards, because
  it may invalidate all previously verified PINs.
 
 The AIDs of the applets of your Java Card, are they present in some EF.DIR ?
 Can its be discovered by the procedure previewed by PKCS#15 ?

You only need to have a default applet that can handle SELECT 2F00 and
READ BINARY to dump EF.DIR. The next command would be a SELECT BY
NAME, which is handled by the runtime environment and switches form one
applet to another. Now you can proceed with 5031 and 5032.

The whole process is nearly transparent. There are only two issues I
encountered so far:
* there is no MF per default, but it could be simulated by the applets
* SELECT BY NAME is handled by the Java RE which imposes it's own
  semantics for that command

 Our card starts from EF.DIR. Everything that is above this file is out of 
 PKCS#15 context.
 
 
 
  Regards
  Andre
 
 Kind wishes,
 Viktor.
 

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] r5081

2011-01-14 Thread Andre Zepezauer

On Fri, 2011-01-14 at 18:31 +0100, Viktor TARASOV wrote:
 On 14.01.2011 17:53, Andre Zepezauer wrote:
  On Fri, 2011-01-14 at 17:31 +0100, Viktor TARASOV wrote:
  On 14.01.2011 16:51, Andre Zepezauer wrote:
  On Fri, 2011-01-14 at 16:00 +0100, Viktor TARASOV wrote:
  On 14.01.2011 15:17, Andre Zepezauer wrote:
  On Fri, 2011-01-14 at 14:14 +0100, Viktor TARASOV wrote:
  On 14.01.2011 13:37, Andre Zepezauer wrote:
  On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote:
  Hello Andre,
 
  On 14.01.2011 04:24, Andre Zepezauer wrote:
  please have a look at PKCS#15 6.8.2 Pin objects for the 
  definition of
  local and global PIN objects. There is no mention of storage 
  location.
  There is mention of 'path'.
  The difference between 'global' and 'local' is that the first one 
  can be verified from any location on the card,
  the second one is 'visible' only from somewhere under the DF (or 
  application) where it's defined.
 
  So, we need (or, if you like, it's useful) to have 'path' defined 
  for the local PINs, to be able to select it's path before 
  verification.
  My previous assumptions comes from this citation.
  It seems that I am terribly missing something. Can you give more 
  details?
 
 
   From PKCS#15 6.8.2 Pin objects:
   PinAttributes.path: Path to the DF in which the PIN resides. 
  The path shall be selected
by a host application before doing a PIN operation, in order to 
  enable a suitable
authentication context for the PIN operation.
  That's 'local' PIN.
 
  If not present, a card-holder verification
must always be possible to perform without a prior `SELECT' 
  operation.
  That's the global one.
 
 
  So we desperately need the 'path' for the local PINs. So that 'host 
  application' can select the path
  'before doing a PIN operation'.
  You probably know another way to do verification from the random 
  location on the card ?
  Take Java Card with PKI applet as an example. Once the applet is
  selected, it is possible to perform the VERIFY command from every
  location within that applet. That's 'local' PIN too. Because it's only
  valid for that applet but not for the whole card.
  OK, let us adjust the terminology.
  I am talking about the PKCS#15 card. This card starts from some MF, 
  where exist EF.DIR, probably EF.ATR, ..., as well as application DFs.
  The AID of application DFs are present in the EF.DIR records.
  The global PINs are defined at the MF level or above, the local ones are 
  defined in application DFs.
 
  In my comprehension to create/use the PKCS#15 objects you don't need to 
  jump higher then MF, and thus to reset status of 'global' PINs.
  You have another vision, examples ?
 
 
  BTW care must be take with re-selecting an applet in Java Cards, because
  it may invalidate all previously verified PINs.
  The AIDs of the applets of your Java Card, are they present in some 
  EF.DIR ?
  Can its be discovered by the procedure previewed by PKCS#15 ?
  You only need to have a default applet that can handle SELECT 2F00 and
  READ BINARY to dump EF.DIR. The next command would be a SELECT BY
  NAME, which is handled by the runtime environment and switches form one
  applet to another. Now you can proceed with 5031 and 5032.
 
  Well, it seems that we are talking about the same thing.
 
  We've gone away from the original item.
  Do you have something against committed proposal to complete the missing 
  'path' for the local PINs when decoding AODF ?
  Yes, the patch you have committed is a fix for cards not following
  PKCS#15 and ISO 7816-15. Therefore it is placed wrong. Your current
  proposal effects every card not only the broken ones.
 
 
 Explain me please how it effects the other cards.
 
 The other 'normal' cards
   - for the local PINs they have 'local' set in their pinFlags and have the 
 'path' in pinAttributes;
   - for the global PIN they have no 'local' in pinFlags and have no path in 
 pinAttributes.
 
 
 There are 'anormal' cards that for the local PINs have flag 'local' in 
 pinFlags, but have no 'path' in pinAttributes.
 My proposal concerns these ones.
 
 
 Please, give me a detailed description of the PinAttributes that can be 
 effected by this proposal.

Local PIN with no path required.


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] r5081

2011-01-14 Thread Andre Zepezauer

On Fri, 2011-01-14 at 18:50 +0100, Viktor TARASOV wrote:
 On 14.01.2011 18:36, Andre Zepezauer wrote:
  On Fri, 2011-01-14 at 18:31 +0100, Viktor TARASOV wrote:
  On 14.01.2011 17:53, Andre Zepezauer wrote:
  On Fri, 2011-01-14 at 17:31 +0100, Viktor TARASOV wrote:
  On 14.01.2011 16:51, Andre Zepezauer wrote:
  On Fri, 2011-01-14 at 16:00 +0100, Viktor TARASOV wrote:
  On 14.01.2011 15:17, Andre Zepezauer wrote:
  On Fri, 2011-01-14 at 14:14 +0100, Viktor TARASOV wrote:
  On 14.01.2011 13:37, Andre Zepezauer wrote:
  On Fri, 2011-01-14 at 10:20 +0100, Viktor TARASOV wrote:
  Hello Andre,
 
  On 14.01.2011 04:24, Andre Zepezauer wrote:
  please have a look at PKCS#15 6.8.2 Pin objects for the 
  definition of
  local and global PIN objects. There is no mention of storage 
  location.
  There is mention of 'path'.
  The difference between 'global' and 'local' is that the first one 
  can be verified from any location on the card,
  the second one is 'visible' only from somewhere under the DF (or 
  application) where it's defined.
 
  So, we need (or, if you like, it's useful) to have 'path' defined 
  for the local PINs, to be able to select it's path before 
  verification.
  My previous assumptions comes from this citation.
  It seems that I am terribly missing something. Can you give more 
  details?
 
 
 From PKCS#15 6.8.2 Pin objects:
PinAttributes.path: Path to the DF in which the PIN resides. 
  The path shall be selected
 by a host application before doing a PIN operation, in order 
  to enable a suitable
 authentication context for the PIN operation.
  That's 'local' PIN.
 
  If not present, a card-holder verification
 must always be possible to perform without a prior `SELECT' 
  operation.
  That's the global one.
 
 
  So we desperately need the 'path' for the local PINs. So that 'host 
  application' can select the path
  'before doing a PIN operation'.
  You probably know another way to do verification from the random 
  location on the card ?
  Take Java Card with PKI applet as an example. Once the applet is
  selected, it is possible to perform the VERIFY command from every
  location within that applet. That's 'local' PIN too. Because it's only
  valid for that applet but not for the whole card.
  OK, let us adjust the terminology.
  I am talking about the PKCS#15 card. This card starts from some MF, 
  where exist EF.DIR, probably EF.ATR, ..., as well as application DFs.
  The AID of application DFs are present in the EF.DIR records.
  The global PINs are defined at the MF level or above, the local ones 
  are defined in application DFs.
 
  In my comprehension to create/use the PKCS#15 objects you don't need 
  to jump higher then MF, and thus to reset status of 'global' PINs.
  You have another vision, examples ?
 
 
  BTW care must be take with re-selecting an applet in Java Cards, 
  because
  it may invalidate all previously verified PINs.
  The AIDs of the applets of your Java Card, are they present in some 
  EF.DIR ?
  Can its be discovered by the procedure previewed by PKCS#15 ?
  You only need to have a default applet that can handle SELECT 2F00 and
  READ BINARY to dump EF.DIR. The next command would be a SELECT BY
  NAME, which is handled by the runtime environment and switches form one
  applet to another. Now you can proceed with 5031 and 5032.
  Well, it seems that we are talking about the same thing.
 
  We've gone away from the original item.
  Do you have something against committed proposal to complete the missing 
  'path' for the local PINs when decoding AODF ?
  Yes, the patch you have committed is a fix for cards not following
  PKCS#15 and ISO 7816-15. Therefore it is placed wrong. Your current
  proposal effects every card not only the broken ones.
 
  Explain me please how it effects the other cards.
 
  The other 'normal' cards
 - for the local PINs they have 'local' set in their pinFlags and have 
  the 'path' in pinAttributes;
 - for the global PIN they have no 'local' in pinFlags and have no path 
  in pinAttributes.
 
 
  There are 'anormal' cards that for the local PINs have flag 'local' in 
  pinFlags, but have no 'path' in pinAttributes.
  My proposal concerns these ones.
 
 
  Please, give me a detailed description of the PinAttributes that can be 
  effected by this proposal.
  Local PIN with no path required.
 
 1. If no path required, it means that it can be verified from every where in 
 the card --  it's the global PIN.

That's your personal interpretation (see below).

 2. Have you seen such a card ? Can you post here it's AODF ?
 
 3. Finally, if no path required, selection of some path will not a effect 
 it's verification.

As stated before, SELECT BY NAME has very special semantics on Java
Cards and is completely different from just select another DF.
Therefore there will be harm if used carelessly.

So, please take the specification as is:

If not present, a card-holder verification must always

[opensc-devel] Missing patch for public review

2011-01-14 Thread Andre Zepezauer

Hello Viktor,

even not completed yet it's quite obvious what you want achieve with
r5092 [1]. Its purpose is the selection of specific algorithms for the
cryptographic operations sign and decipher. Tag 0x80 in the data field
of MSE command and specific to each private key.

That intention is novel of cause, because it's an enabler for cards with
mixed key sets. In example RSA, ECC, GOST (3DES and AES) on a single
card without heavy workarounds in the drivers itself. That's possible
because selection of algorithms is done in a common place namely
pkcs15-sec.c controlled by some PKCS#15 data structures.

It should be noted that the right mechanisms are in place since nine
years now [2] and that a completely working patch was presented some
months ago [3]. That patch was fully PKCS#15 conform and capable of
serving all drivers at once. In example the iso7816 driver was instantly
passing tag 0x80 to the card without any modifications to the driver
itself.

So, my solution was presented for public review [3]. Please do the same
and provide a similar patch [4]. And keep in mind that it is of general
interest because lots of drivers can take advantage of it.

Regards
Andre

[1] http://www.opensc-project.org/opensc/changeset/5092
[2] 
http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/iso7816.c?rev=177#L566
[3] http://www.opensc-project.org/pipermail/opensc-devel/2010-August/014618.html
[4] http://www.opensc-project.org/opensc/wiki/DevelopmentPolicy#Mailinglist

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Misleading information about capabilities of readers

2011-01-13 Thread Andre Zepezauer

Hello,

On Thu, 2011-01-13 at 11:37 +0100, Ludovic Rousseau wrote:
 Found the bug (I think).
 
 The CCID driver calculate a timeout accordings to the card ATR. In
 your case the timeout is 1428 ms rounded to 2 seconds.
 Log says:
 0007 ifdhandler.c:791:IFDHSetProtocolParameters() Timeout: 2 seconds
 
 The same timeout is used by the reader and by the CCID driver. I think
 the CCID driver (libusb in fact) triggers its timeout just before the
 reader does. So the driver do not get the reader error message.

I don't think that libccid is the source of trouble. Check out this:

grep -A 1 3B\ F.\ 18\ ..\ ..\ 81\ 31\ FE\ 45 smartcard_list.txt

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Configure content of the log message

2011-01-13 Thread Andre Zepezauer

Hello,

OpenSC as a library doesn't need it's own logging system. Such things
are better placed at application level. If debugging is necessary, then
'export OPENSC_DEBUG=9' + pkcs11-spy works for me.

What would be the advantage of having logs of different instances of
OpenSC intermixed in a single file?

Regards
Andre

On Thu, 2011-01-13 at 16:14 +0100, Viktor TARASOV wrote:
 Hi,
 
 what do you think about possibility to configure content of the log message.
 
 I mean something like this in 'opensc.conf':
 
 app default {
  log_level = debug;
  log debug  {
  debug = 8;
  debug_file = /tmp/opensc-debug.log;
 
  print_pid = false; #default true
  print_timestamp = false; #default true
  print_app_name = false; #default true
  }
 ...
 
 
 Kind wishes,
 Viktor.
 
 
 ___
 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] Misleading information about capabilities of readers

2011-01-13 Thread Andre Zepezauer

On Thu, 2011-01-13 at 18:39 +0100, Jean-Michel Pouré - GOOZE wrote:
 Le jeudi 13 janvier 2011 à 18:08 +0100, Peter Stuge a écrit :
   * Unsupported.
   * Supported (and not should work).
   * Supported and reviewed (and not Supported).
  
  The good names depend on what support means in this context. I
  don't know that. Do you? Maybe Ludovic can help clarify? 
 
 A word should always be used in the common sense. 
 
 In free software, supported means that a hardware/software can run,
 until anyone can fill a bug report or indicate that it is not supported.
 And then people propose patches. This is the common sense of
 supported.
 
 Take the example of smartcards in OpenSC. A lot of them are declared
 supported, but presently only 3 or 4 work very well and are not end of
 life.
 
 Again:
 * Supported and reviewed by libccid author:
 Means that the hardware is supported and carefully reviewed. This is an
 indication of quality, but also that the vendor paid money.

It would be easier to call it 'certified'. And of cause, certification
may be a service that is not for free.

 * Supported
 This is the usual meaning. Here is the R-301-v2.
 * Unsupported
 The reader did not fully pass the benchmark. There should be an
 indication of impact on OpenSC. If a reader is reported to work with
 OpenSC, users should know.
 

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Configure content of the log message

2011-01-13 Thread Andre Zepezauer

On Thu, 2011-01-13 at 17:58 +0100, Viktor TARASOV wrote:
 On 13.01.2011 17:07, Andre Zepezauer wrote:
  Hello,
 
  OpenSC as a library doesn't need it's own logging system. Such things
  are better placed at application level. If debugging is necessary, then
  'export OPENSC_DEBUG=9' + pkcs11-spy works for me.
 
  What would be the advantage of having logs of different instances of
  OpenSC intermixed in a single file?
 
 To have shorter line in logs,
  card.c:322:sc_unlock: called
 instead of
  0x2b20d02e53f0 17:50:57.667 [opensc-explorer] card.c:322:sc_unlock: 
 called

Making the lines shorter isn't that bad. But making it configurable is a
lot of overhead. Personally I wouldn't miss anything if a line would
look like this: card.c:322:sc_unlock: called

 Well, I do not see general enthusiasm, let's forget it.
 
  Regards
  Andre
 Kind wishes,
 Viktor.
 
 
  On Thu, 2011-01-13 at 16:14 +0100, Viktor TARASOV wrote:
  Hi,
 
  what do you think about possibility to configure content of the log 
  message.
 
  I mean something like this in 'opensc.conf':
 
  app default {
log_level = debug;
log debug  {
debug = 8;
debug_file = /tmp/opensc-debug.log;
 
print_pid = false; #default true
print_timestamp = false; #default true
print_app_name = false; #default true
}
  ...
 
 
  Kind wishes,
  Viktor.
 
 
  ___
  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

[opensc-devel] r5081

2011-01-13 Thread Andre Zepezauer

Hello Viktor,

please have a look at PKCS#15 6.8.2 Pin objects for the definition of
local and global PIN objects. There is no mention of storage location.

So, why trying to fix something that's not broken? BTW it segfaults.

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Cryptoflex unsupprted?

2011-01-12 Thread Andre Zepezauer

Hello,

On Wed, 2011-01-12 at 10:53 +0100, François Schauber wrote:
 Hi,
 
 I just discovered OpenSC. I try to read my card, a Cryptoflex, but it
 seems unsupported.
 
 D:\Program Files\OpenSC Project\OpenSCopensc-tool.exe --reader 0 -a
 3b:95:18:40:14:64:02:01:01:02
 
 D:\Program Files\OpenSC Project\OpenSCopensc-tool.exe --reader 0
 --name
 Unsupported card
 
 Are all the card drivers included in OpenSC or we can download it
 somewhere?

All drivers are included. But it's possible to re-configure a specific
driver to serve your card too. In your case, you have to add the
following lines to /etc/opensc.conf:

card_atr 3b:95:18:40:14:64:02:01:01:02 {
name = Unknown-Cryptoflex;
driver = flex;
}

Which version are you running? 'opensc-tool -i'

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Misleading information about capabilities of readers

2011-01-12 Thread Andre Zepezauer

On Wed, 2011-01-12 at 12:26 +0200, Aventra development wrote:
 Hi,

  -Original Message-
  From: opensc-devel-boun...@lists.opensc-project.org [mailto:opensc-devel-
  boun...@lists.opensc-project.org] On Behalf Of Ludovic Rousseau
  Sent: 12. tammikuuta 2011 11:22
  To: opensc-devel
  Subject: Re: [opensc-devel] Misleading information about capabilities of
  readers

  2011/1/11 Andre Zepezauer andre.zepeza...@student.uni-halle.de:
   Hello,

   the wiki page of MyEID [1] contains the following paragraph:

   Many readers don't support receiving the default amount of data (254).
   Problems will only appear when reading larger files from the card (e.g.
   certificates). So if you have problems with reading the card with no
   apparent reason, try to set this to e.g. 192, to be on the safe side.
   You can then try to iterate to find the maximum for your card reader.

   That statement is simply wrong, because every USB reader can handle
   Short-APDUs of every size. For that reason no other card has similar
   problems.

  Every _non-bogus_ reader.
  For example the Feitian SCR301 [2] is bogus and can't support CASE 2
  APDU with Le=0 (256 bytes). That is why this reader is listed in the
  unsupported list of my CCID driver.

   If there are readers that don't work properly with MyEID, then list them
   explicitly by name. That would definitely of more help to users then
   such a vague statement like Many readers don't support [...].

  The reader above has a problem with Le=256. Le=254 should work and the
  reader should not have a problem with MyEID.

  I don't know which readers have problem with MyEID. An explicit list
  of bogus readers would be great so that users can avoid buying such
  readers.

 There is nothing special about MyEID that would cause the issue. In windows
 everything works just fine if we follow the readers maxIFSD value.
 One difference with many other cards supported by OpenSC that they use T=0
 protocol (MyEID use T=1).

I have a guess about the source of trouble: MyEID cards do not support
T1-Block-Chaining.

@Ludovic: What's your opinion?

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Cryptoflex unsupprted?

2011-01-12 Thread Andre Zepezauer

On Wed, 2011-01-12 at 11:44 +0100, François Schauber wrote:
 D:\Program Files\OpenSC Project\OpenSCopensc-tool.exe -i
 opensc 0.12.0 [gcc  4.4.4]
 Enabled features: zlib openssl pcsc(winscard.dll)
 
 I added the lines in the opensc.conf but it's not enough, i assume
 it's necessary to add the lines to treat the APDU treatment specific
 to this Cryptoflex card.

The given configuration should be sufficient to attach the Cryptoflex
driver to your card. I have tested it locally and had successfully
attached Cryptoflex driver to OpenPGP card:

card_atr 3B:FA:13:00:FF:81:31:80:45:00:31:C1:73:C0:01:00:00:90:00:B1 {
name = Unknown Cyberflex;
driver = flex;
}

Please provide debug logs. 'export OPENSC_DEBUG=9'


 2011/1/12 Andre Zepezauer andre.zepeza...@student.uni-halle.de
 Hello,
 
 
 On Wed, 2011-01-12 at 10:53 +0100, François Schauber wrote:
  Hi,
 
  I just discovered OpenSC. I try to read my card, a
 Cryptoflex, but it
  seems unsupported.
 
  D:\Program Files\OpenSC Project\OpenSCopensc-tool.exe
 --reader 0 -a
  3b:95:18:40:14:64:02:01:01:02
 
  D:\Program Files\OpenSC Project\OpenSCopensc-tool.exe
 --reader 0
  --name
  Unsupported card
 
  Are all the card drivers included in OpenSC or we can
 download it
  somewhere?
 
 
 All drivers are included. But it's possible to re-configure a
 specific
 driver to serve your card too. In your case, you have to add
 the
 following lines to /etc/opensc.conf:
 
 card_atr 3b:95:18:40:14:64:02:01:01:02 {
name = Unknown-Cryptoflex;
driver = flex;
 }
 
 Which version are you running? 'opensc-tool -i'
 
 Regards
 Andre
 
 

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Misleading information about capabilities of readers

2011-01-12 Thread Andre Zepezauer

On Wed, 2011-01-12 at 17:22 +0200, Aventra development wrote:
 Hi,
 
  -Original Message-
  From: Andre Zepezauer [mailto:andre.zepeza...@student.uni-halle.de]
  Sent: 12. tammikuuta 2011 12:46
  
   There is nothing special about MyEID that would cause the issue. In
 windows
   everything works just fine if we follow the readers maxIFSD value.
   One difference with many other cards supported by OpenSC that they use
 T=0
   protocol (MyEID use T=1).
  
  I have a guess about the source of trouble: MyEID cards do not support
  T1-Block-Chaining.
 
 MyEID supports this block chaining because it is based on standard NXP JCOP
 smartcard chips. 
 However, block chaining is used only after the maximum packet size is
 reached, i.e. above 256 bytes, 
 so it would not be used here anyway.
 
 From our point of view, this is handled totally transparently by the reader
 and the smartcard chip.

Manually adjusting max_*_size to some magic value isn't transparent at
all. So the question is, why MyEID needs such adjustment whereas other
cards don't. You should definitely start investigating that issue.

As a short term solution you could provide a list of readers known to
work. That would be most valuable for your customers.

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Misleading information about capabilities of readers

2011-01-12 Thread Andre Zepezauer

On Wed, 2011-01-12 at 19:41 +0200, Aventra wrote:
 Hi,
 
  -Original Message-
-Original Message-
From: Andre Zepezauer [mailto:andre.zepeza...@student.uni-halle.de]
Sent: 12. tammikuuta 2011 12:46

 There is nothing special about MyEID that would cause the issue. In
   windows
 everything works just fine if we follow the readers maxIFSD value.
 One difference with many other cards supported by OpenSC that they
 use
   T=0
 protocol (MyEID use T=1).
   
I have a guess about the source of trouble: MyEID cards do not support
T1-Block-Chaining.
  
   MyEID supports this block chaining because it is based on standard NXP
 JCOP
   smartcard chips.
   However, block chaining is used only after the maximum packet size is
   reached, i.e. above 256 bytes,
   so it would not be used here anyway.
  
   From our point of view, this is handled totally transparently by the
 reader
   and the smartcard chip.
  
  Manually adjusting max_*_size to some magic value isn't transparent at
  all. So the question is, why MyEID needs such adjustment whereas other
  cards don't. You should definitely start investigating that issue.
 
 Yes, I agree that this is something that we would not want to do, but we are
 stuck with it for the moment.
 
 My questions are:
  - have other OpenSC users tried cards that use T=1 protocol?

CardOS and E-Token were very popular in the past. These are T=1 only
devices too (T=0 unsupported): 3B F2 18 00 02 C1 0A 31 FE 58 C8 08 74

They work out of the box with SCM SCR-335 readers driven by libccid. No
adjustments required. Extended-APDUs up to 300+X bytes are working.

  - have somebody managed to use MyEID cards without adjusting the
 configuration?
 
  As a short term solution you could provide a list of readers known to
  work. That would be most valuable for your customers.
 
 Since we have only encountered readers that require the configuration tweak,
 we have decided to add the information on how to change the configuration to
 the wiki page.
 Hope this can be solved somehow in the future.

Just a guess:

Quotation from Java Card (TM) Platform, Version 2.2.1:
The incoming APDU data size may be bigger than the APDU buffer size and may
therefore need to be read in portions by the applet. Similarly, the outgoing
response APDU data size may be bigger than the APDU buffer size and may need
to be written in portions by the applet. The APDU class has methods to
facilitate this.

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] Misleading information about capabilities of readers

2011-01-11 Thread Andre Zepezauer

Hello,

the wiki page of MyEID [1] contains the following paragraph:

Many readers don't support receiving the default amount of data (254).
Problems will only appear when reading larger files from the card (e.g.
certificates). So if you have problems with reading the card with no
apparent reason, try to set this to e.g. 192, to be on the safe side.
You can then try to iterate to find the maximum for your card reader.

That statement is simply wrong, because every USB reader can handle
Short-APDUs of every size. For that reason no other card has similar
problems.

If there are readers that don't work properly with MyEID, then list them
explicitly by name. That would definitely of more help to users then
such a vague statement like Many readers don't support [...].

Regards
Andre

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





___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Braking change in OpenSC 0.12.0 tokenInfo

2011-01-10 Thread Andre Zepezauer

This patch should fix it:

Index: libopensc/pkcs15.c
===
--- libopensc/pkcs15.c  (revision 5078)
+++ libopensc/pkcs15.c  (working copy)
@@ -42,8 +42,8 @@
{ algorithmPKCS#11,   SC_ASN1_INTEGER,SC_ASN1_TAG_INTEGER,
0, NULL, NULL },
{ parameters, SC_ASN1_NULL,   SC_ASN1_TAG_NULL,   
0, NULL, NULL },
{ supportedOperations,SC_ASN1_BIT_FIELD,  SC_ASN1_TAG_BIT_STRING, 
0, NULL, NULL },
-   { objId,  SC_ASN1_OBJECT, SC_ASN1_TAG_OBJECT, 
0, NULL, NULL },
-   { algRef, SC_ASN1_INTEGER,SC_ASN1_TAG_INTEGER,
0, NULL, NULL },
+   { objId,  SC_ASN1_OBJECT, SC_ASN1_TAG_OBJECT, 
SC_ASN1_OPTIONAL, NULL, NULL },
+   { algRef, SC_ASN1_INTEGER,SC_ASN1_TAG_INTEGER,
SC_ASN1_OPTIONAL, NULL, NULL },
{ NULL, 0, 0, 0, NULL, NULL }
 };

On Mon, 2011-01-10 at 11:21 +0200, Aventra development wrote:
 Hi,
 
  
 
 I have been testing the new release and sadly found a braking change
 that causes cards that are not initialized with (the current version
 of) OpenSC to result in the message “Unsupported card”. The cause is
 the token info (5032 file). There is some element that OpenSC
 requires, otherwise it results in “Unsupported Card”.
 
  
 
 Previously OpenSC worked well with cards not initialized with it, but
 now it seems that it does not. Does anybody know what changed and why?
 
 I tried to browse the source and the changes, but did not manage to
 track it back to any change that affected this… I’m not even sure when
 this change has been done, but somewhere between versions 0.11.13 and
 0.12.0.
 
  
 
 Any help would be appreciated. Below is a log that shows the error and
 the content of the tokenInfo file. The major difference is that cards
 not initialized by OpenSC does not have the lastUpdate value.
 
  
 
 Debug log and below that there is a more detailed log about ASN.1
 parsing:
 
  
 
 2011-01-05 12:26:07.066 [pkcs15-tool] card.c:548:sc_select_file:
 called; type=2, path=3f0050155032
 
 2011-01-05 12:26:07.066 [pkcs15-tool]
 card-myeid.c:202:myeid_select_file: called
 
  
 
 2011-01-05 12:26:07.066 [pkcs15-tool] apdu.c:527:sc_transmit_apdu:
 called
 
 2011-01-05 12:26:07.066 [pkcs15-tool] card.c:295:sc_lock: called
 
 2011-01-05 12:26:07.081 [pkcs15-tool] reader-pcsc.c:242:pcsc_transmit:
 reader 'O2 O2Micro CCID SC Reader 0'
 
 2011-01-05 12:26:07.081 [pkcs15-tool] apdu.c:187:sc_apdu_log:
 
 Outgoing APDU data [   10 bytes] =
 
 00 A4 08 00 04 50 15 50 32 FF .P.P2.
 
 ==
 
 2011-01-05 12:26:07.081 [pkcs15-tool]
 reader-pcsc.c:175:pcsc_internal_transmit: called
 
 2011-01-05 12:26:07.175 [pkcs15-tool] apdu.c:187:sc_apdu_log:
 
 Incoming APDU data [   27 bytes] =
 
 6F 17 80 02 00 46 82 01 01 83 02 50 32 86 03 03 oF.P2...
 
 3F FF 85 02 00 00 8A 01 07 90 00?..
 
 ==
 
 2011-01-05 12:26:07.175 [pkcs15-tool] card.c:329:sc_unlock: called
 
 2011-01-05 12:26:07.175 [pkcs15-tool]
 card-myeid.c:240:myeid_process_fci: called
 
  
 
 2011-01-05 12:26:07.191 [pkcs15-tool]
 iso7816.c:304:iso7816_process_fci: processing FCI bytes
 
 2011-01-05 12:26:07.191 [pkcs15-tool]
 iso7816.c:309:iso7816_process_fci:   file identifier: 0x5032
 
 2011-01-05 12:26:07.191 [pkcs15-tool]
 iso7816.c:316:iso7816_process_fci:   bytes in file: 70
 
 2011-01-05 12:26:07.191 [pkcs15-tool]
 iso7816.c:335:iso7816_process_fci:   shareable: no
 
 2011-01-05 12:26:07.191 [pkcs15-tool]
 iso7816.c:355:iso7816_process_fci:   type: working EF
 
 2011-01-05 12:26:07.206 [pkcs15-tool]
 iso7816.c:357:iso7816_process_fci:   EF structure: 1
 
 2011-01-05 12:26:07.206 [pkcs15-tool]
 card-myeid.c:256:myeid_process_fci: id (5032) sec_attr (3 3F FF)
 
 2011-01-05 12:26:07.206 [pkcs15-tool]
 card-myeid.c:269:myeid_process_fci: File id (5032) status
 SC_FILE_STATUS_ACTIVATED (0x7)
 
 2011-01-05 12:26:07.222 [pkcs15-tool]
 card-myeid.c:274:myeid_process_fci: returning with: 0 (Success)
 
 2011-01-05 12:26:07.222 [pkcs15-tool]
 card-myeid.c:208:myeid_select_file: returning with: 0 (Success)
 
 2011-01-05 12:26:07.222 [pkcs15-tool] card.c:569:sc_select_file:
 returning with: 0 (Success)
 
 2011-01-05 12:26:07.222 [pkcs15-tool] card.c:416:sc_read_binary:
 called; 70 bytes at index 0
 
 2011-01-05 12:26:07.222 [pkcs15-tool] apdu.c:527:sc_transmit_apdu:
 called
 
 2011-01-05 12:26:07.238 [pkcs15-tool] card.c:295:sc_lock: called
 
 2011-01-05 12:26:07.238 [pkcs15-tool] reader-pcsc.c:242:pcsc_transmit:
 reader 'O2 O2Micro CCID SC Reader 0'
 
 2011-01-05 12:26:07.238 [pkcs15-tool] apdu.c:187:sc_apdu_log:
 
 Outgoing APDU data [5 bytes] =
 
 00 B0 00 00 46 F

Re: [opensc-devel] Fixed bug in 0.12.0

2010-12-23 Thread Andre Zepezauer

On Thu, 2010-12-23 at 09:54 +0200, Martin Paljak wrote:
 Hello,
 On Dec 23, 2010, at 5:40 AM, Andre Zepezauer wrote:
  On Thu, 2010-12-23 at 03:10 +0100, Peter Stuge wrote:
  That bug always occurs if there is an EF (i.e. EF.PrKD, EF.PuKD, EF.SKD)
  that contains either broken ASN.1 or uses an encoding that OpenSC isn't
  able to decode. The committed message [1] contains all the details about
  the bug and the fix. 
  
  Maybe you can mention something about known failure cases?
  
  A profile that stores some x509Certificates and one pgpCertificate aka
  PGP public key. See PKCS#15 section 6.6 Certificates.
 Is it a common scenario? Should this only affect cards which are not 
 initialized with OpenSC?

Interestingly this bug isn't that new. It only becomes triggered now,
because the search operation continues on partial failure.

It only affects cards which already encountered problems before #266 was
fixed. For these cards, the search operation
__sc_pkcs15_search_objects() may now return successfully even if
decoding of some EFs failed. Continued searches may trigger that bug.

The number of effected cards should be small to zero. Cards working
flawlessly in the past are not effected. The profile with
pgpCertificates is local experimental stuff only.

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] Fixed bug in 0.12.0

2010-12-22 Thread Andre Zepezauer

Hello,

today I encountered a new bug that was introduced with the fix of #266.
A working patch was committed in r4983.

That bug always occurs if there is an EF (i.e. EF.PrKD, EF.PuKD, EF.SKD)
that contains either broken ASN.1 or uses an encoding that OpenSC isn't
able to decode. The committed message [1] contains all the details about
the bug and the fix. 

Regards
Andre

[1] http://www.opensc-project.org/opensc/changeset/4983

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Fixed bug in 0.12.0

2010-12-22 Thread Andre Zepezauer

Hello Peter,

On Thu, 2010-12-23 at 03:10 +0100, Peter Stuge wrote:
 Andre Zepezauer wrote:
  Hello,
  
  today I encountered a new bug that was introduced with the fix of
  #266. A working patch was committed in r4983.
 
 Please be careful about wording in the subject. It is very much
 unclear what the version number means. :\

Agreed. Up to now, there was no official announcement of a 0.12.0
release.

  That bug always occurs if there is an EF (i.e. EF.PrKD, EF.PuKD, EF.SKD)
  that contains either broken ASN.1 or uses an encoding that OpenSC isn't
  able to decode. The committed message [1] contains all the details about
  the bug and the fix. 
 
 Maybe you can mention something about known failure cases?

A profile that stores some x509Certificates and one pgpCertificate aka
PGP public key. See PKCS#15 section 6.6 Certificates.

Decoding of x509Certificates is processed without error. Each
x509Certificate is appended to p15card-obj_list. When the last object
in EF.CD (pgpCert) is processed then the ASN.1 decoder fails with:

asn1.c:1279:asn1_decode: returning with: -1402 (Required ASN.1 object not found)

In that case, the function sc_pkcs15_parse_df returns also -1402 and
*doesn't* flag df as enumerated (df-enumerated == 0). On the next
invocation of __sc_pkcs15_search_objects the EF.CD is processed again.
And all the x509Certificates are appended to obj_list again and again
and again 

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] OpenSC 12.0

2010-12-20 Thread Andre Zepezauer

Hello Martin,

On Mon, 2010-12-20 at 17:42 +0200, Martin Paljak wrote:
 Hello,
 On Dec 20, 2010, at 4:58 PM, Brian Thomas wrote:
  I’m just wondering if anybody has a good estimation as to when OpenSC 12.0 
  will be released as final?
 
 There were some additional fixes to building without OpenSSL and with Visual 
 Studio [1]. Other than that, it seems to be ready. Unless there will be other 
 comments, it should be announced latest tomorrow evening.

what's about the active tickets [2]. Should we try to reduce them to a
minimum before the final release is announced? IMO not much would be
left, if we would handle them as follows:

1. #216 #220 #269 #291 and maybe more could be closed if there where a
final confirmation that states that things are working

2. moving all the enhancements/supports forward to 0.12.1, because it's
unlikely that they get fixed in 0.12.0

3. finding a solutions for all the remaining tickets. That could be:
* fixing them now or
* fixing them in 0.12.1

@All:
Other ideas about how to handle the active tickets relating to 0.12.0?

Regards
Andre

 [1] 
 http://www.opensc-project.org/opensc/log/trunk?action=stop_on_copymode=stop_on_copyrev=4979stop_rev=4961limit=100
[2] 
http://www.opensc-project.org/opensc/query?status=assignedstatus=newstatus=reopenedgroup=statusmilestone=0.12.0

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] OpenSC 12.0

2010-12-20 Thread Andre Zepezauer

On Mon, 2010-12-20 at 22:49 +0200, Martin Paljak wrote:
 Hi,
 
 On Dec 20, 2010, at 7:10 PM, Andre Zepezauer wrote:
  On Mon, 2010-12-20 at 17:42 +0200, Martin Paljak wrote:
  Hello,
  On Dec 20, 2010, at 4:58 PM, Brian Thomas wrote:
  I’m just wondering if anybody has a good estimation as to when OpenSC 
  12.0 will be released as final?
  
  There were some additional fixes to building without OpenSSL and with 
  Visual Studio [1]. Other than that, it seems to be ready. Unless there 
  will be other comments, it should be announced latest tomorrow evening.
  
  what's about the active tickets [2]. Should we try to reduce them to a
  minimum before the final release is announced? IMO not much would be
  left, if we would handle them as follows:
 That would be nice, but if there's no feedback and it can't be independently 
 verified by somebody, it can just be left there for the defined grace period 
 and closed once it either times out or is claimed to be verified by somebody.
 
 
  1. #216 #220 #269 #291 and maybe more could be closed if there where a
  final confirmation that states that things are working
 #216 should probably get some feedback from Linux packagers to be finally 
 settled, but that's something that will be visible once 0.12.0 is out. 
 Apparently nobody volunteered to provide sample Debian packages...  A 
 suggestion Do your packages with pcsc-lite support by default would 
 probably do good. But the issue is resolved by now, yes. For the rest the 
 previous comment should be sficient?
 
  2. moving all the enhancements/supports forward to 0.12.1, because it's
  unlikely that they get fixed in 0.12.0
 Support tickets should be discarded. As said, support category is only 
 meant for administrative categorization purposes..
 
 
  3. finding a solutions for all the remaining tickets. That could be:
  * fixing them now or
  * fixing them in 0.12.1
 Best effort basis for 0.12.X onwards. Should push out the 0.12 before 
 Christmas.

In other words, milestone 0.12.0 would be finished within the next view
days. Good, no objections about that. But having the ticket system in a
state, that reflects that fact would be nice too. According to the three
points above, that means either closing tickets or pushing them forward
to the next milestone.

How it was handled in the releases before?

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Interpretation of SC_ALGORITHM_* flags

2010-12-14 Thread Andre Zepezauer

 What could be the ISO version of SHA1 + PKCS#1 + RSA Stef was
 referencing to in the e-mail I referenced in this thread?

Maybe that one:
[1] http://www.alvestrand.no/objectid/1.2.840.113549.1.1.5.html

Assuming the following definition

ASN1-ENCODE ::= SEQUENCE {
 algorithm  OBJECT IDENTIFIER,
 digest OCTET STRING }

then [1] would match ASN1-ENCODE + PKCS1-PAD + RSA as well as
CKM_SHA1_RSA_PKCS :)

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] westcos still fakes crypto hardware

2010-12-13 Thread Andre Zepezauer

Hello,

attached is the missing patch. It removes the RSA faking, but leaves
everything else as is.

BTW: Is the source code of that applet publicly available. If so, it
shouldn't be that hard to add the cryptographic operations. With or
without hardware-support.

Regards
Andre

On Wed, 2010-12-08 at 08:35 +0100, francois.lebl...@cev-sa.com wrote:
 Hello,
 
 For know I don't have patch for removing software operation on westcos,
 
 This is needed until westcos with cryptographics becomes available...
 
 But like I make my own build, I use openssl, you can build without openssl
 
 I will provide one for westcos user...
 
 It is ok for you  this way?
 
 François.
 
 
 
 De :
 Martin Paljak mar...@paljak.pri.ee
 A:
 Andre Zepezauer andre.zepeza...@student.uni-halle.de
 Cc :
 opensc-devel opensc-devel@lists.opensc-project.org
 Date:
 07/12/2010 19:38
 Objet :
 Re: [opensc-devel] westcos still fakes crypto hardware
 Envoyé par :
 opensc-devel-boun...@lists.opensc-project.org
 
 
 
 Hello,
 On Dec 7, 2010, at 8:25 PM, Andre Zepezauer wrote:
 
  Hello,
  
  the westcos driver still fakes crypto-hardware. It first extracts the
  key material from the card and than performs the crypto operations in
  software. Following that schema, then every card could easily support
  every crypto-algorithm. OpenSSL would make it possible. What would be
  the next thing in OpenSC, support for GSM/UMTS SIM cards?
 Do you know LGPL compatible A5/1 libraries ? :)
 
 Seriously though, a patch that removes the software operations would be 
 useful.
 
 François, do you have one or will it break anything?
 
 Password encryption in key importing is also still present. I would really 
 like to do a test to see if native exportable keys are supported by some 
 cards. I know this can be done with JavaCards but don't know if any applet 
 implements it.
 
Index: src/libopensc/card-westcos.c
===
--- src/libopensc/card-westcos.c	(revision 4943)
+++ src/libopensc/card-westcos.c	(working copy)
@@ -31,11 +31,6 @@
 
 #ifdef ENABLE_OPENSSL
 #include openssl/des.h
-#include openssl/rsa.h
-#include openssl/evp.h
-#include openssl/pem.h
-#include openssl/err.h
-#include openssl/bio.h
 #endif
 
 #ifndef min
@@ -50,23 +45,7 @@
 #define WESTCOS_RSA_NO_HASH_NO_PAD		(0x20)
 #define WESTCOS_RSA_NO_HASH_PAD_PKCS1	(0x21)
 
-#ifdef ENABLE_OPENSSL
-#define DEBUG_SSL
-#ifdef DEBUG_SSL
-static void print_openssl_error(void)
-{
-	static int charge = 0;
-	long r;
 
-	if (!charge) {
-		ERR_load_crypto_strings();
-		charge = 1;
-	}
-	while ((r = ERR_get_error()) != 0)
-		fprintf(stderr, %s\n, ERR_error_string(r, NULL));
-}
-#endif
-#endif
 
 typedef struct {
 	sc_security_env_t env;
@@ -1099,14 +1078,8 @@
 {
 	int r;
 	int idx = 0;
-	u8 buf[180];
 	sc_file_t *keyfile = sc_file_new();
 	priv_data_t *priv_data = NULL;
-	int pad;
-#ifdef ENABLE_OPENSSL
-	RSA *rsa = NULL;
-	BIO *mem = BIO_new(BIO_s_mem());
-#endif
 
 	if (card == NULL)
 		return SC_ERROR_INVALID_ARGUMENTS;
@@ -1138,103 +,7 @@
 		goto out2;
 	}
 	
-#ifndef ENABLE_OPENSSL
 	r = SC_ERROR_NOT_SUPPORTED;
-#else
-	if (keyfile == NULL || mem == NULL || priv_data == NULL) {
-		r = SC_ERROR_OUT_OF_MEMORY;
-		goto out;
-	}
-	if ((priv_data-env.flags)  SC_ALGORITHM_RSA_PAD_PKCS1)
-		pad = RSA_PKCS1_PADDING;
-
-	else if ((priv_data-env.flags)  SC_ALGORITHM_RSA_RAW)
-		pad = RSA_NO_PADDING;
-
-	else {
-		r = SC_ERROR_INVALID_ARGUMENTS;
-		goto out;
-	}
-	r = sc_select_file(card, (priv_data-env.file_ref), keyfile);
-	if (r)
-		goto out;
-
-	do {
-		int alire;
-		alire = min(((keyfile-size) - idx), sizeof(buf));
-		if (alire = 0)
-			break;
-		sc_debug(card-ctx, SC_LOG_DEBUG_NORMAL,
-			idx = %d, alire=%d\n, idx, alire);
-		r = sc_read_binary(card, idx, buf, alire, 0);
-		if (r  0)
-			goto out;
-		BIO_write(mem, buf, r);
-		idx += r;
-	} while (1);
-	BIO_set_mem_eof_return(mem, -1);
-	if (!d2i_RSAPrivateKey_bio(mem, rsa)) {
-		sc_debug(card-ctx, SC_LOG_DEBUG_NORMAL,
-			RSA key invalid, %d\n, ERR_get_error());
-		r = SC_ERROR_UNKNOWN;
-		goto out;
-	}
-
-	/* pkcs11 reset openssl functions */
-	rsa-meth = RSA_PKCS1_SSLeay();
-	if (RSA_size(rsa)  outlen) {
-		sc_debug(card-ctx, SC_LOG_DEBUG_NORMAL, Buffer too small\n);
-		r = SC_ERROR_OUT_OF_MEMORY;
-		goto out;
-	}
-#if 1
-	if (mode) {		/* decipher */
-		r = RSA_private_decrypt(data_len, data, out, rsa, pad);
-		if (r == -1) {
-
-#ifdef DEBUG_SSL
-			print_openssl_error();
-
-#endif
-			sc_debug(card-ctx, SC_LOG_DEBUG_NORMAL,
-Decipher error %d\n, ERR_get_error());
-			r = SC_ERROR_UNKNOWN;
-			goto out;
-		}
-	}
-
-	else {			/* sign */
-
-		r = RSA_private_encrypt(data_len, data, out, rsa, pad);
-		if (r == -1) {
-
-#ifdef DEBUG_SSL
-			print_openssl_error();
-
-#endif
-			sc_debug(card-ctx, SC_LOG_DEBUG_NORMAL,
-Signature error %d\n, ERR_get_error());
-			r = SC_ERROR_UNKNOWN;
-			goto out;
-		}
-	}
-
-#else
-	if (RSA_sign(nid, data, data_len, out, outlen, rsa) != 1) {
-		sc_debug(card-ctx

Re: [opensc-devel] reader max_x_size

2010-12-13 Thread Andre Zepezauer

Hello Martin,

On Mon, 2010-12-13 at 13:50 +0200, Martin Paljak wrote:
 Hello,
 On Dec 12, 2010, at 6:30 PM, Andre Zepezauer wrote:
  So it's better to have a common place for such tweaks. In the smart card
  world this should be preferable the read driver. Applications should
  only care about capabilities of cards. Especially support for extended
  APDU and chaining.
 Agreed, this would be the ideal case. 
 
 Also see #296  [1]
 
 [1] http://www.opensc-project.org/opensc/ticket/296#comment:1

it's nice to have some support on that :)

For the Extended APDU and Chaining capabilities OpenSC should also have
a look at the Historical Bytes. Maybe someday there will be a card
without dedicated driver. The iso-driver and information from Hist-Bytes
should be sufficient (at least for operational read-only state). So,
that's my direction.

Regards
Andre



___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] reader max_x_size

2010-12-13 Thread Andre Zepezauer

On Mon, 2010-12-13 at 13:53 +0200, Martin Paljak wrote:
 Hello,
 
 
 On Dec 12, 2010, at 12:13 PM, Andreas Jellinghaus wrote:
  but stuff like this might happen all the time - most tokens are sold
  as solution with chip/reader/token device plus software as a bundle,
  so any alternative software like opensc is exploring unknown seas
  and might find bugs...
  
  so in general I think it would be good to have a few knobs to tweak,
  preferable without recompiling, if we run into problems with some
  tokens.
 Indeed, knobs are nice. 
 
 IMHO the problem with the max_*_size tunables is the somewhat random way how 
 they are used in the code and the difficulty to apply it cleanly to all 
 drivers (and the question if this should be done outside of crippled card 
 drivers in the first place)

I would like to propose the attached patch. The only thing that is
changed, is the level of emphasise on the max_x_size options. Users with
USB devices really shouldn't care about them.

Regards
Andre
Index: etc/opensc.conf.in
===
--- etc/opensc.conf.in	(revision 4943)
+++ etc/opensc.conf.in	(working copy)
@@ -43,18 +43,10 @@
 	# The following section shows definitions for PC/SC readers.
 	reader_driver pcsc {
 		# This sets the maximum send and receive sizes.
-		# Some reader drivers have limitations, so you need
-		# to set these values. For usb devices check the
-		# properties with lsusb -vv for dwMaxIFSD
-		#
-		# These values will be used for APDU communication
-		# and are used for maximum Lc/Le calculation
-		# (will not include CLA, INS, P1, P2 or SW1, SW2).
-		#
-		# Default: send: 255, recv: 256
+		# Default: n/a
 		# max_send_size = 255;
 		# max_recv_size = 256;
-		
+		#
 		# Connect to reader in exclusive mode?
 		# Default: false
 		# connect_exclusive = true;
@@ -90,12 +82,9 @@
 		# Virtual readers to allocate.
 		# Default: 2
 		# readers = 5;
-
-		# This sets the maximum send and receive sizes.
-		# Some reader drivers have limitations, so you need
-		# to set these values. For usb devices check the
-		# properties with lsusb -vv for dwMaxIFSD
 		#
+		# This sets the maximum send and receive sizes.
+		# Default: n/a
 		# max_send_size = 255;
 		# max_recv_size = 256;
 	};
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] reader max_x_size

2010-12-13 Thread Andre Zepezauer

On Mon, 2010-12-13 at 15:51 +0100, Andre Zepezauer wrote:
 On Mon, 2010-12-13 at 13:53 +0200, Martin Paljak wrote:
  Hello,
  
  
  On Dec 12, 2010, at 12:13 PM, Andreas Jellinghaus wrote:
   but stuff like this might happen all the time - most tokens are sold
   as solution with chip/reader/token device plus software as a bundle,
   so any alternative software like opensc is exploring unknown seas
   and might find bugs...
   
   so in general I think it would be good to have a few knobs to tweak,
   preferable without recompiling, if we run into problems with some
   tokens.
  Indeed, knobs are nice. 
  
  IMHO the problem with the max_*_size tunables is the somewhat random way 
  how they are used in the code and the difficulty to apply it cleanly to all 
  drivers (and the question if this should be done outside of crippled card 
  drivers in the first place)
 
 I would like to propose the attached patch. The only thing that is
 changed, is the level of emphasise on the max_x_size options. Users with
 USB devices really shouldn't care about them.

Committed revision 4947.

 Regards
 Andre


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] westcos still fakes crypto hardware

2010-12-13 Thread Andre Zepezauer

On Mon, 2010-12-13 at 13:09 +0200, Martin Paljak wrote:
 Hello,
 
 On Dec 13, 2010, at 10:02 AM, Andre Zepezauer wrote:
  attached is the missing patch. It removes the RSA faking, but leaves
  everything else as is.
 
 Looks reasonable.
  
  BTW: Is the source code of that applet publicly available. If so, it
  shouldn't be that hard to add the cryptographic operations. With or
  without hardware-support.
 I doubt it (or the link to the applet source would have already been 
 available somewhere)

Bad for westcos. Sure that someone would be willing to implement the
missing RSA computation for free. That could also have been done in the
past. With closed source that task is left to the vendor.

@Francois:
The removal was foreseeable since at least August 2010 [1][2]. So, you
should be prepared for it.

[1] http://www.opensc-project.org/pipermail/opensc-devel/2010-August/014679.html
[2] 
http://www.opensc-project.org/opensc/wiki/DevelopmentPolicy?action=diffversion=12


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] reader max_x_size

2010-12-12 Thread Andre Zepezauer

On Sun, 2010-12-12 at 18:30 +0100, Ludovic Rousseau wrote:
 2010/12/12 Andre Zepezauer andre.zepeza...@student.uni-halle.de:
  On Sun, 2010-12-12 at 11:13 +0100, Andreas Jellinghaus wrote:
  hmm. for details on using ccid readers ludovic knows this stuff
  much better than I do.
 
  for some other readers, I remember one token where the chip card
  inside has a maxIFSCD of 255 in the atr, so we could send quite
  big t=1 frames. but the reader chip in that token would only work
  with smaller commands.
 
  not sure if I could work around that in openct, or needed opensc
  to generate smaller apdus in the first place.
 
  but stuff like this might happen all the time - most tokens are sold
  as solution with chip/reader/token device plus software as a bundle,
  so any alternative software like opensc is exploring unknown seas
  and might find bugs...
 
  so in general I think it would be good to have a few knobs to tweak,
  preferable without recompiling, if we run into problems with some
  tokens.
 
  Then the question is: where is the right place for such tweaks. Our
  current approach would translate to a configuration option in a
  web-browser, that limits the size of web-pages. And of cause all the
  other network applications must be configured separately in similar way.
  Fortunately that's not the case.
 
  So it's better to have a common place for such tweaks. In the smart card
  world this should be preferable the read driver. Applications should
  only care about capabilities of cards. Especially support for extended
  APDU and chaining. How these APDU:s are transmitted is left to the read
  driver. Additionally the driver has better knowledge of readers and
  therefore is able to implement more advanced tweaks.
 
 Your solution can't work.

Which solution?

 The driver cannot split a long APDU into two smaller ones.

Correct. But with TPDU and Extended APDU level exchange the APDU is
transmitted in multiple parts anyway. Everything is still implemented in
the drivers (i.e. libccid).

 So the application has to know the maximum size and generate correct APDU.

Naturally that is 261 bytes for short APDU and 65545 bytes for extended
ones. The only thing the application has to know is the level of support
for extended APDU and chaining. There is nothing else the application
should care about.

If there is something wrong, then please explain.

 A few years ago I proposed a solution [1] for the application to know
 the maximum usable size using SCARD_ATTR_MAXINPUT [2]. But this is not
 PC/SC standard. I proposed something similar to the PC/SC workgroup. I
 don't know yet if the idea has been accepted.

Regards
Andre

 [1] 
 http://www.opensc-project.org/pipermail/opensc-devel/2006-November/009199.html
 [2] http://svn.debian.org/wsvn/pcsclite/trunk/Drivers/ccid/SCARDGETATTRIB.txt


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] New Italian CNS/eID patch

2010-12-12 Thread Andre Zepezauer

On Sun, 2010-08-15 at 12:56 +0200, Emanuele Pucciarelli wrote:
 Greetings,
 
 I have uploaded a new, updated patch for Italian CNS support against
 the current trunk:
 
 http://www.opensc-project.org/opensc/attachment/ticket/177/itacns-patch3.diff
 
 Now all Secure Messaging bits are completely out (I'm working on that
 separately) and there is only a tiny bit of dead code in apdu.c – I'm
 unsure how to deal with that. The check *should* be there for short
 Case 3 APDU's, but I can see no way to disable that only for Italian
 CNS cards without fundamental changes to apdu.c (i.e. something like a
 sc_trasnmit_apdu_without_check() function, or a purposefully broken
 APDU flag in the sc_apdu_t structure).

Actually you want to transmit a CASE 1 APDU ;)

http://www.opensc-project.org/opensc/ticket/299


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] reader max_x_size

2010-12-11 Thread Andre Zepezauer

Hello Andreas,

some time ago, you have changed the comments on reader max_x_sizes in
opensc.conf [1]:

Some reader drivers have limitations, so you need to set these values.
For usb devices check the properties with lsusb -vv for dwMaxIFSD.

Can you remember why pointing the user to dwMaxIFSD? AFAIK this value is
of relevance only for T=1 protocol. But T=1 is capable of transmitting a
single APDU in multiple parts, where each part can have a size of up to
dwMaxIFSD. In the result T=1 can easily handle APDU:s of every size and
therefore the above hint is misleading.

I would like to remove these lines in opensc.conf. Any objections?

Regards
Andre

[1] http://www.opensc-project.org/opensc/changeset/3124/



___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] fix for r4874, r4902

2010-12-11 Thread Andre Zepezauer

Hello Douglas,

please can you review the attached patch. It fixes some problems in
r4874 and f4902.

Thanks
Index: src/libopensc/pkcs15-pubkey.c
===
--- src/libopensc/pkcs15-pubkey.c	(revision 4939)
+++ src/libopensc/pkcs15-pubkey.c	(working copy)
@@ -516,7 +516,7 @@
 	 * x and y are same size, and field_length = sizeof(x) in bits. */
 	/* TODO: -DEE  support more then uncompressed */
 	key-field_length = (ecpoint_len - 1)/2 * 8; 
-	if (ecpoint_data);
+	if (ecpoint_data)
 		free (ecpoint_data);
 
 	return r;
@@ -774,12 +774,13 @@
 		goto out;
 	}
 
-	len = read(f, tagbuf, sizeof(tagbuf)); /* get tag and length */
-	if (len  0) {
+	r = read(f, tagbuf, sizeof(tagbuf)); /* get tag and length */
+	if (r  2) {
 		sc_debug(ctx, SC_LOG_DEBUG_NORMAL,Problem with \%s\\n,filename);
 		r =  SC_ERROR_DATA_OBJECT_NOT_FOUND;
 		goto out;
 	}
+	len = r;
 	body = tagbuf;
 	if (sc_asn1_read_tag(body, 0xf, cla_out,
 			tag_out, bodylen) != SC_SUCCESS) {
@@ -797,8 +798,8 @@
 	memcpy(rbuf, tagbuf, len); /* copy first or only part */
 	if (rbuflen  len) {
 		/* read rest of file */
-		len = read(f, rbuf + sizeof(tagbuf), rbuflen - sizeof(tagbuf)); 
-		if (len != rbuflen - sizeof(tagbuf)) {
+		r = read(f, rbuf + len, rbuflen - len); 
+		if (r  (int)(rbuflen - len)) {
 			r = SC_ERROR_INVALID_ASN1_OBJECT;
 			free (rbuf);
 			rbuf = NULL;
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] textual output of return codes

2010-12-11 Thread Andre Zepezauer

Hello,

I would like to commit the attached patch. It enables the textual output
of SC_ERROR return codes in debug messages. Any objections?

Regards
Andre

Index: src/pkcs11/misc.c
===
--- src/pkcs11/misc.c	(revision 4939)
+++ src/pkcs11/misc.c	(working copy)
@@ -56,7 +56,7 @@
 
 static CK_RV sc_to_cryptoki_error_common(int rc)
 {
-	sc_debug(context, SC_LOG_DEBUG_NORMAL, opensc error: %s (%d)\n, sc_strerror(rc), rc);
+	sc_debug(context, SC_LOG_DEBUG_NORMAL, libopensc return value: %d (%s)\n, rc, sc_strerror(rc));
 	switch (rc) {
 	case SC_SUCCESS:
 		return CKR_OK;
Index: src/libopensc/errors.c
===
--- src/libopensc/errors.c	(revision 4939)
+++ src/libopensc/errors.c	(working copy)
@@ -116,7 +116,7 @@
 		Unknown error,
 		PKCS#15 compatible smart card not found,
 	};
-	const char *no_errors = No errors;
+	const char *no_errors = Success;
 	const int misc_base = -SC_ERROR_UNKNOWN;
 	const char **errors = NULL;
 	int count = 0, err_base = 0;
Index: src/libopensc/log.h
===
--- src/libopensc/log.h	(revision 4939)
+++ src/libopensc/log.h	(working copy)
@@ -65,14 +65,21 @@
 
 #define SC_FUNC_RETURN(ctx, level, r) do { \
 	int _ret = r; \
-	sc_do_log(ctx, level, __FILE__, __LINE__, __FUNCTION__, returning with: %d\n, _ret); \
+	if (_ret = 0) { \
+		sc_do_log(ctx, level, __FILE__, __LINE__, __FUNCTION__, \
+			returning with: %d (%s)\n, _ret, sc_strerror(_ret)); \
+	} else { \
+		sc_do_log(ctx, level, __FILE__, __LINE__, __FUNCTION__, \
+			returning with: %d\n, _ret); \
+	} \
 	return _ret; \
 } while(0)
 
 #define SC_TEST_RET(ctx, level, r, text) do { \
 	int _ret = (r); \
 	if (_ret  0) { \
-		sc_do_log(ctx, level, __FILE__, __LINE__, __FUNCTION__, %s: %s\n, (text), sc_strerror(_ret)); \
+		sc_do_log(ctx, level, __FILE__, __LINE__, __FUNCTION__, \
+			%s: %d (%s)\n, (text), _ret, sc_strerror(_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] [opensc-commits] svn opensc changed[4930] add to r4904: fix calculating of signature size for CKK_GOSTR3410

2010-12-09 Thread Andre Zepezauer

On Thu, 2010-12-09 at 14:31 +0300, Aleksey Samsonov wrote:
 Hello,
 
 2010/12/9 Martin Paljak mar...@paljak.pri.ee:
  Hello,
  On Dec 9, 2010, at 9:23 AM, webmas...@opensc-project.org wrote:
 
  Revision: 4930
  Author:   s
  Date: 2010-12-09 07:23:10 + (Thu, 09 Dec 2010)
 
  Log Message:
  ---
  add to r4904: fix calculating of signature size for CKK_GOSTR3410
 
  - *pLength *= 2;
  + *pLength = (*pLength + 7) / 8 * 2;
 
  Could you also add a comment? Why not (*pLength + 7) /  4?
 
 Yes of course. We need to convert a length in bits to bytes and
 multiply by two. So if we divide by 4 then we have incorrect rounding
 result (case (*pLength + 7) % 8 = 4).

Maybe it would be appropriate to define a macro for the conversion. The
Reason is, that there are a lot of places where the conversion is
computed as follows: byte_count = bit_count / 8. That is obviously wrong
in 7 of 8 cases. Also it would improve readability.

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] [opensc-commits] svn opensc changed[4930] add to r4904: fix calculating of signature size for CKK_GOSTR3410

2010-12-09 Thread Andre Zepezauer

On Thu, 2010-12-09 at 09:38 -0600, Douglas E. Engert wrote:
 
 On 12/9/2010 8:41 AM, Andre Zepezauer wrote:
  On Thu, 2010-12-09 at 14:31 +0300, Aleksey Samsonov wrote:
  Hello,
 
  2010/12/9 Martin Paljakmar...@paljak.pri.ee:
  Hello,
  On Dec 9, 2010, at 9:23 AM, webmas...@opensc-project.org wrote:
 
  Revision: 4930
  Author:   s
  Date: 2010-12-09 07:23:10 + (Thu, 09 Dec 2010)
 
  Log Message:
  ---
  add to r4904: fix calculating of signature size for CKK_GOSTR3410
 
  - *pLength *= 2;
  + *pLength = (*pLength + 7) / 8 * 2;
 
  Could you also add a comment? Why not (*pLength + 7) /  4?
 
  Yes of course. We need to convert a length in bits to bytes and
  multiply by two. So if we divide by 4 then we have incorrect rounding
  result (case (*pLength + 7) % 8= 4).
 
  Maybe it would be appropriate to define a macro for the conversion. The
  Reason is, that there are a lot of places where the conversion is
  computed as follows: byte_count = bit_count / 8. That is obviously wrong
  in 7 of 8 cases. Also it would improve readability.
 
 It may comes down to does an algorthim support non-multiple of 8 bits? And
 if it can, is it ever used with non multiple of 8 bits? I have never sees an
 RSA key that was not a multiple of 8, so it may not be an issue for most of
 OpenSC.
 
 If one is not a multiple of 8, how is it padded?

At least for RSA_PKCS1 the most significant octet is always zero. See
PKCS1 01- and 02-padding schema. Therefore the padded signature input is
always less than the modulus when compared numerical.

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] westcos still fakes crypto hardware

2010-12-07 Thread Andre Zepezauer

Hello,

the westcos driver still fakes crypto-hardware. It first extracts the
key material from the card and than performs the crypto operations in
software. Following that schema, then every card could easily support
every crypto-algorithm. OpenSSL would make it possible. What would be
the next thing in OpenSC, support for GSM/UMTS SIM cards?

Regards
Andre 

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] westcos still fakes crypto hardware

2010-12-07 Thread Andre Zepezauer

On Tue, 2010-12-07 at 20:38 +0200, Martin Paljak wrote:
 Hello,
 On Dec 7, 2010, at 8:25 PM, Andre Zepezauer wrote:
 
  Hello,
  
  the westcos driver still fakes crypto-hardware. It first extracts the
  key material from the card and than performs the crypto operations in
  software. Following that schema, then every card could easily support
  every crypto-algorithm. OpenSSL would make it possible. What would be
  the next thing in OpenSC, support for GSM/UMTS SIM cards?
 Do you know LGPL compatible A5/1 libraries ? :)

Only GPL, but really amazing:
http://openbsc.osmocom.org/trac/

 Seriously though, a patch that removes the software operations would be 
 useful.
 
 François, do you have one or will it break anything?
 
 Password encryption in key importing is also still present. I would really 
 like to do a test to see if native exportable keys are supported by some 
 cards. I know this can be done with JavaCards but don't know if any applet 
 implements it.
 

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] 0.11.9 -- 0.12.0

2010-12-07 Thread Andre Zepezauer

Hello Martin,

not a big issue, but IMO the link to 0.11.12 in the NEWS file should be
removed. See development tree below:


releases   0.11.8   0.11.9   0.11.10   0.11.11 -- 0.11.12 -- 0.11.13 -- 
0.11.14 0.12.0
  ||| | 
   |
  ||| | 
   |
  ||| | 
   |
trunk X
X-- trunk
   |   |
   |   |
   |   |
branches   X---X


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] PKCS#15 ObjectValue

2010-12-01 Thread Andre Zepezauer

On Wed, 2010-12-01 at 08:31 -0600, Douglas E. Engert wrote:
 
 On 11/30/2010 8:16 PM, Andre Zepezauer wrote:
  On Tue, 2010-11-30 at 16:16 -0600, Douglas E. Engert wrote:
 
  On 11/30/2010 3:22 PM, Andre Zepezauer wrote:
  Hello Douglas,
 
  for problem you tried to solve with r4901 there is a more general
  solution. That solution would involve the mapping of the ASN1 type
  ObjectValue to the corresponding C-structures.
 
  In the case related to r4901, the hook would be
  sc_pkcs15_pubkey_info_t-path. The underlying ASN1 type of that variable
  is ObjectValue. Which is defined by PKCS#15 as a CHOICE between PATH,
  RAW and SubjectPublicKeyInfo. Only the PATH choice is supported yet.
 
  In the long term that should be completed and 'path' should be replaced
  by 'value' with a type capable to hold one of PATH, RAW or
  SubjectPublicKeyInfo.
 
  I could implement that. But not before 0.12 is out. Because it requires
  some changes on asn1-decoders. In the mean time it's better to place the
  variable 'emulated' on sc_pkcs15_pubkey_info_t. Then the function
  sc_pkcs15_read_pubkey could be modified to handle the two cases (path or
  emulated) transparently.
 
  Sounds interesting, but today, the emulated works with the EC code I
  am working on using the PIV card that is emulating the pubkey
 
  You are going to emulate something that hasn't to be emulated at all.
  The use-case where the whole public key is included within the meta-data
  is already defined by PKCS#15. Public-key-meta-data is mapped to
  sc_pkcs15_pubkey_info_t and so the pubkey as DER-encoded SPKI should
  reside there.
 
  I would like to leave it the way it is, at least until I get all the EC
  code committed.
 
  You could commit to a specialised branch and merge to trunk when 0.12 is
  released. In the mean time, things could be integrated better if
  necessary.
 
 Let me point out that no code is using the mod today, and will only
 be used by the PIV to start with. As you point out the the pubkey
 for EC at least could be a SPKI, and this looks promising.

SPKI-encoding is common to all keys. In the specific case of EC,
DER-encoded ECPoint is possible too. See the ASN1 definitions of
{KEY-TYPE}PublicKeyChoice in PKCS#15.

KEY-TYPE := RSA | EC | DH | DSA | KEA

According to the specs, exactly one out of {path, url, raw, spki} is
always included in meta-data.

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] PKCS#15 ObjectValue

2010-11-30 Thread Andre Zepezauer

Hello Douglas,

for problem you tried to solve with r4901 there is a more general
solution. That solution would involve the mapping of the ASN1 type
ObjectValue to the corresponding C-structures.

In the case related to r4901, the hook would be
sc_pkcs15_pubkey_info_t-path. The underlying ASN1 type of that variable
is ObjectValue. Which is defined by PKCS#15 as a CHOICE between PATH,
RAW and SubjectPublicKeyInfo. Only the PATH choice is supported yet.

In the long term that should be completed and 'path' should be replaced
by 'value' with a type capable to hold one of PATH, RAW or
SubjectPublicKeyInfo.

I could implement that. But not before 0.12 is out. Because it requires
some changes on asn1-decoders. In the mean time it's better to place the
variable 'emulated' on sc_pkcs15_pubkey_info_t. Then the function
sc_pkcs15_read_pubkey could be modified to handle the two cases (path or
emulated) transparently.

Regards
Andre

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] pkcs11-tool

2010-11-29 Thread Andre Zepezauer

On Mon, 2010-11-29 at 08:50 -0600, Douglas E. Engert wrote:
 
 On 11/25/2010 10:23 AM, Andre Zepezauer wrote:
  Hello,
 
  I would like to commit the attached patch. It modifies the method of
  public key retrieval in pkcs11-tool.
 
  Currently the non standard attribute CKA_VALUE is uses. With the patch
  applied, only attributes defined by PKCS#11 are used for public key
  retrieval. Tested with OpenSSL 0.9.8.
 
 Yes, some pub key objects don't have CKA_VALUE: RSA and EC. I am not
 sure about GOST. I can add  the code for EC.
 Looks good to me.

This is a non complete list of keys with CKA_VALUE attribute. In most
cases the value of CKA_VALUE attribute isn't suitable as input for
d2i_PublicKey().

EC Private
DH Public/Private
DSA Public/Private
GOST Public/Private


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] Verification of send/receive Limits

2010-11-25 Thread Andre Zepezauer

On Thu, 2010-11-25 at 09:28 +0100, Ludovic Rousseau wrote:
 2010/11/23 Andre Zepezauer andre.zepeza...@student.uni-halle.de:
  Dear OpenSC developers,
 
  it seems to me that there are some myths in the OpenSC community about
  the send/receive limitations of cards and readers.
 
  In OpenSC there are two places where limitations on send/receive sizes
  could be imposed. These are based on capabilities of cards and readers.
  Maybe there are cards with limitations, but at least ACOS5 and STARCOS
  shouldn't have. The ACOS5 manual states that it supports PUT DATA with
  Lc=255 (Section 5.28) and in the driver Le=256 is used several times.
  The STARCOS 1.2 manual (published in 1996) doesn't state anything on
  send/receive limitations. Other candidates are westcos, which isn't a
  PKI card anyway and entersafe with manual available only under NDA.
 
  Complete list of effected cards looks like this:
  acos5, akis, atrust-acos, entersafe, gpk, miocos, starcos, westcos
 
  My assumption is, that some of the limitations are artificial and
  effected cards could send/receive more than they do at the moment. But I
  don't have one of these cards and therefore can't verify it myself.
 
  That's why I need your help. If you have one of these cards, then please
  remove the lines card-max_send_size, card-max_recv_size in the driver
  and run some tests afterwards. I.e. opensc-tool -f would be fine. Or
  just write some data objects with:
  pkcs15-init -W [file] --application-id 1.2.3 --label MyObject -a 01
 
  Please include log-files with APDU sequences in your reply. Vendor and
  Model of reader would be helpful too.
 
 Log using a Feitian card and a GemPC Twin reader [1].
 I also join the file I wrote on the card. It is the svnignore file
 from the SVN repository :-)
 
 I am not sure the test is useful. I get:
 0xb74486c0 09:15:20.036 [pkcs15-init] apdu.c:187:sc_apdu_log:
 Outgoing APDU data [  229 bytes] =
 00 D6 00 00 E0 4D 61 6B 65 66 69 6C 65 0A 4D 61 .Makefile.Ma
 6B 65 66 69 6C 65 2E 69 6E 0A 63 6F 72 65 0A 61 kefile.in.core.a
 72 63 68 69 76 65 0A 61 63 69 6E 63 6C 75 64 65 rchive.acinclude
 2E 6D 34 0A 61 63 6C 6F 63 61 6C 2E 6D 34 0A 61 .m4.aclocal.m4.a
 75 74 6F 6D 34 74 65 2E 63 61 63 68 65 0A 63 6F utom4te.cache.co
 6D 70 69 6C 65 0A 63 6F 6E 66 64 65 66 73 2E 68 mpile.confdefs.h
 0A 63 6F 6E 66 69 67 2E 2A 0A 63 6F 6E 66 69 67 .config.*.config
 75 72 65 0A 63 6F 6E 66 74 65 73 74 0A 63 6F 6E ure.conftest.con
 66 74 65 73 74 2E 63 0A 64 65 70 63 6F 6D 70 0A ftest.c.depcomp.
 69 6E 73 74 61 6C 6C 2D 73 68 0A 6C 69 62 74 6F install-sh.libto
 6F 6C 0A 6C 69 62 74 6F 6F 6C 2E 6D 34 0A 6C 74 ol.libtool.m4.lt
 2A 2E 6D 34 0A 6C 74 6D 61 69 6E 2E 73 68 0A 6D *.m4.ltmain.sh.m
 69 73 73 69 6E 67 0A 6D 6B 69 6E 73 74 61 6C 6C issing.mkinstall
 64 69 72 73 0A 73 6F 5F 6C 6F 63 61 74 69 6F 6E dirs.so_location
 73 0A 73 74 61  s.sta
 ==
 0xb74486c0 09:15:20.036 [pkcs15-init] apdu.c:527:sc_transmit_apdu: called
 0xb74486c0 09:15:20.036 [pkcs15-init] card.c:295:sc_lock: called
 0xb74486c0 09:15:20.036 [pkcs15-init] reader-pcsc.c:231:pcsc_transmit:
 reader 'Gemalto GemPC Twin 00 00'
 0xb74486c0 09:15:20.036 [pkcs15-init] apdu.c:187:sc_apdu_log:
 Outgoing APDU data [  229 bytes] =
 00 D6 00 00 E0 4D 61 6B 65 66 69 6C 65 0A 4D 61 .Makefile.Ma
 6B 65 66 69 6C 65 2E 69 6E 0A 63 6F 72 65 0A 61 kefile.in.core.a
 72 63 68 69 76 65 0A 61 63 69 6E 63 6C 75 64 65 rchive.acinclude
 2E 6D 34 0A 61 63 6C 6F 63 61 6C 2E 6D 34 0A 61 .m4.aclocal.m4.a
 75 74 6F 6D 34 74 65 2E 63 61 63 68 65 0A 63 6F utom4te.cache.co
 6D 70 69 6C 65 0A 63 6F 6E 66 64 65 66 73 2E 68 mpile.confdefs.h
 0A 63 6F 6E 66 69 67 2E 2A 0A 63 6F 6E 66 69 67 .config.*.config
 75 72 65 0A 63 6F 6E 66 74 65 73 74 0A 63 6F 6E ure.conftest.con
 66 74 65 73 74 2E 63 0A 64 65 70 63 6F 6D 70 0A ftest.c.depcomp.
 69 6E 73 74 61 6C 6C 2D 73 68 0A 6C 69 62 74 6F install-sh.libto
 6F 6C 0A 6C 69 62 74 6F 6F 6C 2E 6D 34 0A 6C 74 ol.libtool.m4.lt
 2A 2E 6D 34 0A 6C 74 6D 61 69 6E 2E 73 68 0A 6D *.m4.ltmain.sh.m
 69 73 73 69 6E 67 0A 6D 6B 69 6E 73 74 61 6C 6C issing.mkinstall
 64 69 72 73 0A 73 6F 5F 6C 6F 63 61 74 69 6F 6E dirs.so_location
 73 0A 73 74 61  s.sta
 ==
 0xb74486c0 09:15:20.036 [pkcs15-init]
 reader-pcsc.c:164:pcsc_internal_transmit: called
 0xb74486c0 09:15:20.074 [pkcs15-init] apdu.c:187:sc_apdu_log:
 Incoming APDU data [2 bytes] =
 90 00 ..
 ==
 
 The file is 658 bytes but sent in chunk of 229 bytes.
 
 $ grep max_ /etc/opensc/opensc.conf
   #max_send_size = 252;
   #max_recv_size = 252;
   #max_send_size = 252;
   #max_recv_size

[opensc-devel] pkcs11-tool

2010-11-25 Thread Andre Zepezauer

Hello,

I would like to commit the attached patch. It modifies the method of
public key retrieval in pkcs11-tool.

Currently the non standard attribute CKA_VALUE is uses. With the patch
applied, only attributes defined by PKCS#11 are used for public key
retrieval. Tested with OpenSSL 0.9.8.

Regards
Andre
Index: src/tools/pkcs11-tool.c
===
--- src/tools/pkcs11-tool.c	(revision 4880)
+++ src/tools/pkcs11-tool.c	(working copy)
@@ -1930,6 +1930,7 @@
 VARATTR_METHOD(ID, unsigned char);
 VARATTR_METHOD(OBJECT_ID, unsigned char);
 VARATTR_METHOD(MODULUS, unsigned char);
+VARATTR_METHOD(PUBLIC_EXPONENT, unsigned char);
 VARATTR_METHOD(VALUE, unsigned char);
 VARATTR_METHOD(GOSTR3410_PARAMS, unsigned char);
 
@@ -2490,13 +2491,14 @@
 #ifdef ENABLE_OPENSSL
 static EVP_PKEY *get_public_key(CK_SESSION_HANDLE session, CK_OBJECT_HANDLE privKeyObject)
 {
-	unsigned char  *id;
-	CK_ULONGidLen;
+	unsigned char  *id, *modulus, *exponent;
+	CK_ULONGidLen, modLen, expLen;
 	CK_OBJECT_HANDLE pubkeyObject;
 	unsigned char  *pubkey;
 	const unsigned char *pubkey_c;
 	CK_ULONGpubkeyLen;
 	EVP_PKEY   *pkey;
+	RSA*rsa;
 
 	id = NULL;
 	id = getID(session, privKeyObject, idLen);
@@ -2512,6 +2514,39 @@
 	}
 	free(id);
 
+	switch(getKEY_TYPE(session, pubkeyObject)) {
+		case CKK_RSA:
+			pkey = EVP_PKEY_new();
+			rsa = RSA_new();
+			modulus = getMODULUS(session, pubkeyObject, modLen);
+			exponent = getPUBLIC_EXPONENT(session, pubkeyObject, expLen);
+			if ( !pkey || !rsa || !modulus || !exponent) {
+printf(public key not extractable\n);
+if (pkey)
+	free(pkey);
+if (rsa)
+	free(rsa);
+if (modulus)
+	free(modulus);
+if (exponent)
+	free(exponent);
+return NULL;
+			}
+			rsa-n = BN_bin2bn(modulus, modLen, NULL);
+			rsa-e = BN_bin2bn(exponent, expLen, NULL);
+			EVP_PKEY_assign_RSA(pkey, rsa);
+			free(modulus);
+			free(exponent);
+			return pkey;
+		case CKK_DSA:
+		case CKK_ECDSA:
+		case CKK_GOSTR3410:
+			break;
+		default:
+			printf(public key of unsupported type\n);
+			return NULL;
+	}
+
 	pubkey = getVALUE(session, pubkeyObject, pubkeyLen);
 	if (pubkey == NULL) {
 		printf(couldn't get the pubkey VALUE attribute, no validation done\n);
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] Verification of send/receive Limits

2010-11-23 Thread Andre Zepezauer

Dear OpenSC developers,

it seems to me that there are some myths in the OpenSC community about
the send/receive limitations of cards and readers.

In OpenSC there are two places where limitations on send/receive sizes
could be imposed. These are based on capabilities of cards and readers.
Maybe there are cards with limitations, but at least ACOS5 and STARCOS
shouldn't have. The ACOS5 manual states that it supports PUT DATA with
Lc=255 (Section 5.28) and in the driver Le=256 is used several times.
The STARCOS 1.2 manual (published in 1996) doesn't state anything on
send/receive limitations. Other candidates are westcos, which isn't a
PKI card anyway and entersafe with manual available only under NDA.

Complete list of effected cards looks like this:
acos5, akis, atrust-acos, entersafe, gpk, miocos, starcos, westcos

My assumption is, that some of the limitations are artificial and
effected cards could send/receive more than they do at the moment. But I
don't have one of these cards and therefore can't verify it myself. 

That's why I need your help. If you have one of these cards, then please
remove the lines card-max_send_size, card-max_recv_size in the driver
and run some tests afterwards. I.e. opensc-tool -f would be fine. Or
just write some data objects with:
pkcs15-init -W [file] --application-id 1.2.3 --label MyObject -a 01

Please include log-files with APDU sequences in your reply. Vendor and
Model of reader would be helpful too.

Kind Regards
Andre Zepezauer

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] pkcs11-spy

2010-11-22 Thread Andre Zepezauer

Hello,

 2010/11/20 Andre Zepezauer andre.zepeza...@student.uni-halle.de:
  I would like to commit a change to pkcs11-spy, that changes the output
  related to enquiries on attribute values (C_GetAttributeValue). The
  reason for that change is that PKCS#11 defines a precise algorithm for
  these enquiries. That algorithm depends for example on pointer
  (NULL_PTR) and size of input-buffer.
 
  The new output is more detailed and less verbose. And it makes tracing
  of applications a little bit more easy. See attached file sample.txt.
 
  The patch uses the following format string with variable sized hex-dump
  of pointers:  sprintf(buf, 0x%0*lx / %ld, 2 * ptr_sz, ptr, buf_len);
 
  It works well on Linux (32 and 64 bit). But does this kind of format
  string would work on other platforms too? Other objections about that
  patch?
 
 In buf_spec() function why do you declare ptr_sz as static?
 I agree buf need to be static since the pointer to the buffer is
 returned by ptr_sz should not be static.

Agreed.

 Why do you cast size in a (CK_LONG) if the value is in fact a CK_ULONG?
 Why not use %lu and no cast:
   sprintf(buf, 0x%0*lx / %lu, 2 * ptr_sz, value, size);
 

The cast is required by PKCS#11 specs:
If the specified attribute [...] for the object cannot be revealed
because the object is sensitive or unextractable, then the ulValueLen
field in that triple is modified to hold the value -1 (i.e., when it is
cast to a CK_LONG, it holds -1).

 No other objection.
 
 I don't know if the field width is supported on Windows. Nothing in
 printf(3) says this is a glibc extension so I may work on other
 systems.

A grep over the OpenSC source code gave only one result where variable
field width is used within a format string. This is in cardmod.
Therefore I would prefer to avoid it. New patch without variable field
width is attached.

Regards
Andre

Index: src/pkcs11/pkcs11-display.c
===
--- src/pkcs11/pkcs11-display.c	(revision 4877)
+++ src/pkcs11/pkcs11-display.c	(working copy)
@@ -84,6 +84,17 @@
 #define CKA_CERT_MD5_HASH		(CKA_TRUST + 101)
 
 
+static char *buf_spec(CK_VOID_PTR value, CK_ULONG size)
+{
+	static char buf[64];
+	if (sizeof(CK_VOID_PTR) == 4) {
+		sprintf(buf, 0x%08lx / %ld, value, (CK_LONG) size);
+	} else {
+		sprintf(buf, 0x%016lx / %ld, value, (CK_LONG) size);
+	}
+	return buf;
+}
+
 void print_enum(FILE *f, CK_LONG type, CK_VOID_PTR value, CK_ULONG size, CK_VOID_PTR arg)
 {
   enum_spec *spec = (enum_spec*)arg;
@@ -109,7 +120,7 @@
 {
   CK_ULONG i;
   if(size != (CK_LONG)(-1)  value != NULL) {
-fprintf(f, [size : 0x%lX (%ld)]\n, size, size);
+fprintf(f, %s\n, buf_spec(value, size));
 for(i = 0; i  size; i++) {
   if (i != 0) {
 	if ((i % 32) == 0)
@@ -153,7 +164,7 @@
   CK_ULONG i, j;
   CK_BYTE  c;
   if(size != (CK_LONG)(-1)) {
-fprintf(f, [size : 0x%lX (%ld)]\n, size, size);
+fprintf(f, %s\n, buf_spec(value, size));
 for(i = 0; i  size; i += j) {
   for(j = 0; ((i + j  size)  (j  32)); j++) {
 	if (((j % 4) == 0)  (j != 0)) fprintf(f,  );
@@ -862,20 +873,20 @@
 			if(ck_attribute_specs[k].type == pTemplate[j].type) {
 found = 1;
 fprintf(f, %s , ck_attribute_specs[k].name);
-if(pTemplate[j].pValue) {
+if(pTemplate[j].pValue  ((CK_LONG) pTemplate[j].ulValueLen)  0) {
 	ck_attribute_specs[k].display
 	(f, pTemplate[j].type, pTemplate[j].pValue,
 		pTemplate[j].ulValueLen,
 	ck_attribute_specs[k].arg);
 } else {
-	fprintf(f, has size %ld\n, pTemplate[j].ulValueLen); 
+	fprintf(f, %s\n, buf_spec(pTemplate[j].pValue, pTemplate[j].ulValueLen));
 }
 k = ck_attribute_num;
 			}
 		}
 		if (!found) {
 			fprintf(f, CKA_? (0x%08lx), pTemplate[j].type);
-			fprintf(f, has size %ld\n, pTemplate[j].ulValueLen); 
+			fprintf(f, %s\n, buf_spec(pTemplate[j].pValue, pTemplate[j].ulValueLen));
 		}
 	}
 }
@@ -891,13 +902,13 @@
   if(ck_attribute_specs[k].type == pTemplate[j].type) {
 	found = 1;
 	fprintf(f, %s , ck_attribute_specs[k].name);
-	fprintf(f, requested with %ld buffer\n, pTemplate[j].ulValueLen); 
+	fprintf(f, %s\n, buf_spec(pTemplate[j].pValue, pTemplate[j].ulValueLen));
 	k = ck_attribute_num;
   }
 }
 if (!found) {
 	fprintf(f, CKA_? (0x%08lx), pTemplate[j].type);
-	fprintf(f, requested with %ld buffer\n, pTemplate[j].ulValueLen); 
+	fprintf(f, %s\n, buf_spec(pTemplate[j].pValue, pTemplate[j].ulValueLen));
 }
   }
 }
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] #269

2010-11-22 Thread Andre Zepezauer

On Mon, 2010-11-22 at 09:12 -0600, Douglas E. Engert wrote:
 
 On 11/21/2010 3:24 AM, Jean-Michel Pouré - GOOZE wrote:
  Le samedi 20 novembre 2010 à 18:05 +0100, Andre Zepezauer a écrit :
  BTW: This is *exactly* the subset of CCID readers NOT supporting 2048
  bit keys. Because they can transmit only Short APDUs.
 
 If a card can support chaining (CLA=10), then it can use 2048 bit keys
 with these readers.

The same is true for the ENVELOPE command. Nevertheless there is a large
fraction of cards that won't work.

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] #269

2010-11-21 Thread Andre Zepezauer

On Sun, 2010-11-21 at 09:44 +0100, Ludovic Rousseau wrote:
 Hello,
 
 2010/11/20 Andre Zepezauer andre.zepeza...@student.uni-halle.de:
  at the moment I'm investigating the max_x_size problem. Here is a short
  preview of things I found so far. More detailed results will be attached
  to #269.
 
  Current state of affairs:
 
  1. currently I concentrate only on USB CCID devices
  2. there are in fact three different kinds
 * TPDU
 * Short APDU
 * Short and Extended APDU
  3. TPDU and Ext-APDU devices don't need special handling.
It's for sure that these devices would at least transmit EVERY
Short APDU (255/256) (A fact to remember)
References that confirm that fact: [1] [2]
  4. looking closer at the third kind of devices (only Short APDU),
let to an interesting result. The following list will show.
 * fist column is dwMaxCCIDMessageLength
 * second column is a file under pcsclite/trunk/Drivers/ccid/readers
 
 Keep in mind that dwMaxCCIDMessageLength also includes the CCID
 header: 10 bytes.
 So the maximum useful data length sent to the card is 
 dwMaxCCIDMessageLength-10.
 
 With my CCID driver you can get the maximum usable size using
 SCardGetAttrib(..., SCARD_ATTR_MAXINPUT, ...) [3]
 
 I also try to push, in the PC/SC workgroup, a way to know at the
 application level if a reader+driver supports extended APDU or not.
 But it is not yet done. Maybe I should start a discussion also on the
 opensc-devel list.
 
 [3] http://svn.debian.org/wsvn/pcsclite/trunk/Drivers/ccid/SCARDGETATTRIB.txt
 
  261 Aktiv_Rutoken_Magistra.txt
  261 Gemalto_PDT.txt
  261 GnD_StarSignCardToken550.txt
  261 JCOP41V221.txt
  261 Oberthur-CosmoCard1.txt
  261 Oberthur-CosmoCard.txt
  261 Philips_SmartMX.txt
  271 ACR122U_PICC.txt
  271 Akasa_AK-CR-03.txt
  271 Aktiv_Rutoken_ECP.txt
  271 Alcor_SCR001.txt
  271 ATMEL_AT91SC192192CT-USB.txt
  271 ATMEL_AT91SO.txt
  271 ATMEL_AT98SC032CT.txt
  271 ATMEL_VaultIC420.txt
  271 ATMEL_VaultIC440.txt
  271 ATMEL_VaultIC460.txt
  271 AU9520.txt
  271 CardMan3021.txt
  271 CardMan3121.txt
  271 CardMan3621.txt
  271 CardMan3821.txt
  271 CardMan4321.txt
  271 CardMan5121.txt
  271 CardMan5125.txt
  271 CardMan5321.txt
  271 CardMan6121.txt
  271 CherrySmartBoardXX1X.txt
  271 CherrySmartTerminalXX1X.txt
  271 CherrySmartTerminalXX7X.txt
  271 CherryST1044U.txt
  271 CherryXX33.txt
  271 CherryXX44.txt
  271 Covadis_Auriga.txt
  271 FujitsuSiemens_SmartCard_Keyboard_USB_2A.txt
  271 FujitsuSiemens_SmartCard_USB_2A.txt
  271 GemPC433_SL.txt
  271 KAAN_SIM_III.txt
  271 mIDentity.txt
  271 Omnikey_noname1.txt
  271 Sitecom_MD-010.txt
  271 Smart_SBV280.txt
  271 SpringCard_CrazyWriter.txt
  271 SpringCard_CSB6_Basic.txt
  271 SpringCard_CSB6_Secure.txt
  271 SpringCard_CSB6_Ultimate.txt
  271 SpringCard_EasyFinger_Standard.txt
  271 SpringCard_EasyFinger_Ultimate.txt
  271 SpringCard_Prox_N_Roll.txt
  271 Teo.txt
  271 Todos_AGM2_CCID.txt
  271 Todos_Cx00.txt
  271 Vasco_DP905.txt
  271 Xiring_Leov2.txt
  271 Xiring_XI-SIGN_6000.txt
  271 Xiring_XI-SIGN.txt
  278 GemProxDU_contactless.txt
  278 GemProxSU_contactless.txt
  280 GnD_StarSignCardToken350.txt
  512 TianYu_CCID_SmartKey.txt
  512 VMware_Virtual_USB_CCID.txt
  2048GoldKey_PIV_Token.txt
 
  Assuming that devices with dwMaxCCIDMessageLength=261 are all USB_Tokens
  and not readers. Then it looks like that all these readers of third kind
  can also handle 255/256.
 
 It think you forgot to count the 10 bytes of CCID header.

As state above, I excluded the devices with dwMaxCCIDMessageLength=261.
These devices are most probably USB tokens and have always a card
present. Limitations of cards are handled separately. And they can be
adjusted to match the limitations of the connected reader. The reader is
always the same for a given USB token and therefore max_x_sizes are
adjusted by card capabilities.

All the remaining devices are willing to receive at least 271 bytes. And
therefore are able to handle Short APDU:s of every size.

Command APDU:
 10  CCID header
  5  CLA INS P1 P2 LC
255  Data
  1  LE

271

Response APDU:
 10  CCID header
256  Data
  2  SW1 SW2
---
268

What's wrong?

  All in all this let to the conclusion that all known USB CCID devices
  can handle at least 255/256. (data set is retrieved from libccid source
  code)
 
  And this in turn would make the description in opensc.conf very brief.
  Maybe like this: If you have a usb device, then you can go with the
  defaults.
 
  Regards
  Andre
 
  [1] 
  http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_CCID_Rev110.pdf
  [2] http://pcsclite.alioth.debian.org/ccid_extended_apdu.html
 
 

___
opensc-devel mailing list

Re: [opensc-devel] #269

2010-11-21 Thread Andre Zepezauer

Dear Jean-Michel,

it's nice to here that the given information is useful and of practical
relevance. But it's in no way a new discovery. All this can also be
found at libccid homepage [1].

As a guideline for users I would recommend to use readers with support
for TPDU protocol. The reason behind is, that TPDU protocol doesn't
impose any limitation. When cards with support for 4096 bit keys become
available in the future, then your current TPDU reader can handle it
with ease.

The list that follows is compiled form data of libccid source code and
includes all readers with TPDU support. How well a reader is actually
supported by libccid should be checked at [2].

Kind Regards
Andre Zepezauer

[1] http://pcsclite.alioth.debian.org/ccid_extended_apdu.html
[2] http://pcsclite.alioth.debian.org/ccid/section.html

On Sun, 2010-11-21 at 10:30 +0100, Jean-Michel Pouré - GOOZE wrote:
 Dear Andre,
 
 I have been testing tons of legacy readers before retailing ours and I
 can confirm that some of these readers do not support 2048bit keys.
 
 We still have 100 of them in stock (I will not give the name, we don't
 retail them) and I will probably give them for free during training
 sessions, now that we know there is no chance to have them working with
 2048bit keys.
 
 Kind regards,

ACR122U.txt
ACR38U-CCID.txt
ACS_ACR100.txt
ACS_ACR38_plugin.txt
ACS_AET65.txt
ActivCardV2.txt
ActivCardV3.txt
ActivkeySim.txt
Aladdin_eToken_PRO_USB_72K_Java.txt
Alya.txt
ASEDrive_IIIe_KB.txt
ASE_IIIe.txt
Athena_IDProtect_Key.txt
ATMEL_AT90SCR050.txt
ATMEL_AT90SCR100.txt
AxaltoV3.txt
BludriveII.txt
Broadcom_5880.txt
Broadcom_5880v2.txt
Broadcom_5880v3.txt
BZH_uKeyCI800-K1.txt
C3PO_KBR36.txt
C3PO_LTC32_USBv2.txt
C3PO_TLTC2USB.txt
CardMan1021.txt
Charismathics.txt
CherrySmartTerminalST2XXX.txt
CryptoIdentity.txt
Dectel_CI692.txt
DellSCRK.txt
DellSK-3106.txt
Eutron_CryptoIdentity.txt
Eutron_Digipass_860.txt
Eutron_Smart_Pocket.txt
Feitian_SCR301.txt
Gemalto_HybridSmartcardReader.txt
Gemalto_SG.txt
GemaltoSmartEnterpriseGuardian.txt
GemCoreSIMPro.txt
Gem_e-SealPro.txt
GemPC_Express.txt
GemPCKey.txt
GemPCPinpad.txt
GemPCPinpadv2.txt
GemPCTwin_serial.txt
GemPCTwin.txt
GemProxDU_contact.txt
GemProxSU_contact.txt
GPFCryptoStick.txt
HP_kus-0133.txt
HP_MFP_SmartCardReader.txt
HPUSBSmartCardKeyboard.txt
HPUSBSmartCardReader.txt
iDream.txt
iMONO.txt
jNet_jToken_s1.txt
Kingtrust_Multi-Reader.txt
Lenovo.txt
LTC31.txt
LTC31v2.txt
LTC36.txt
MSI_StarReader_SMART.txt
MySmartPad.txt
Neowave_Weneo2.txt
Neowave_Weneo.txt
Panasonic_USB_Smart_Card_Reader_7A-Smart.txt
Raritan_D2CIM-DVUSB.txt
ReinerSCT.txt
SCL010.txt
SCL01x.txt
SCR3310_2.txt
SCR3310.txt
SCR3311.txt
SCR331-DI-NTTCom.txt
SCR331-DI.txt
SCR331.txt
SCR3320.txt
SCR333.txt
SCR3340.txt
SCR335.txt
SCR3500.txt
SCR355.txt
SDI010.txt
sid800.txt
SIM_Pocket_Combo.txt
SIM_Pocket_Combo.txt
Softforum_XecureHSM.txt
SPR532.txt
Synnix_STD200.txt
Tianyu_Smart_Card_Reader.txt
Vega-Alpha.txt
Verisign_secure_storage_token.txt


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] #269

2010-11-20 Thread Andre Zepezauer

Hello,

at the moment I'm investigating the max_x_size problem. Here is a short
preview of things I found so far. More detailed results will be attached
to #269.

Current state of affairs:

1. currently I concentrate only on USB CCID devices
2. there are in fact three different kinds
* TPDU
* Short APDU
* Short and Extended APDU
3. TPDU and Ext-APDU devices don't need special handling.
   It's for sure that these devices would at least transmit EVERY
   Short APDU (255/256) (A fact to remember)
   References that confirm that fact: [1] [2]
4. looking closer at the third kind of devices (only Short APDU),
   let to an interesting result. The following list will show.
* fist column is dwMaxCCIDMessageLength
* second column is a file under pcsclite/trunk/Drivers/ccid/readers

261 Aktiv_Rutoken_Magistra.txt
261 Gemalto_PDT.txt
261 GnD_StarSignCardToken550.txt
261 JCOP41V221.txt
261 Oberthur-CosmoCard1.txt
261 Oberthur-CosmoCard.txt
261 Philips_SmartMX.txt
271 ACR122U_PICC.txt
271 Akasa_AK-CR-03.txt
271 Aktiv_Rutoken_ECP.txt
271 Alcor_SCR001.txt
271 ATMEL_AT91SC192192CT-USB.txt
271 ATMEL_AT91SO.txt
271 ATMEL_AT98SC032CT.txt
271 ATMEL_VaultIC420.txt
271 ATMEL_VaultIC440.txt
271 ATMEL_VaultIC460.txt
271 AU9520.txt
271 CardMan3021.txt
271 CardMan3121.txt
271 CardMan3621.txt
271 CardMan3821.txt
271 CardMan4321.txt
271 CardMan5121.txt
271 CardMan5125.txt
271 CardMan5321.txt
271 CardMan6121.txt
271 CherrySmartBoardXX1X.txt
271 CherrySmartTerminalXX1X.txt
271 CherrySmartTerminalXX7X.txt
271 CherryST1044U.txt
271 CherryXX33.txt
271 CherryXX44.txt
271 Covadis_Auriga.txt
271 FujitsuSiemens_SmartCard_Keyboard_USB_2A.txt
271 FujitsuSiemens_SmartCard_USB_2A.txt
271 GemPC433_SL.txt
271 KAAN_SIM_III.txt
271 mIDentity.txt
271 Omnikey_noname1.txt
271 Sitecom_MD-010.txt
271 Smart_SBV280.txt
271 SpringCard_CrazyWriter.txt
271 SpringCard_CSB6_Basic.txt
271 SpringCard_CSB6_Secure.txt
271 SpringCard_CSB6_Ultimate.txt
271 SpringCard_EasyFinger_Standard.txt
271 SpringCard_EasyFinger_Ultimate.txt
271 SpringCard_Prox_N_Roll.txt
271 Teo.txt
271 Todos_AGM2_CCID.txt
271 Todos_Cx00.txt
271 Vasco_DP905.txt
271 Xiring_Leov2.txt
271 Xiring_XI-SIGN_6000.txt
271 Xiring_XI-SIGN.txt
278 GemProxDU_contactless.txt
278 GemProxSU_contactless.txt
280 GnD_StarSignCardToken350.txt
512 TianYu_CCID_SmartKey.txt
512 VMware_Virtual_USB_CCID.txt
2048GoldKey_PIV_Token.txt

Assuming that devices with dwMaxCCIDMessageLength=261 are all USB_Tokens
and not readers. Then it looks like that all these readers of third kind
can also handle 255/256.

All in all this let to the conclusion that all known USB CCID devices
can handle at least 255/256. (data set is retrieved from libccid source
code)

And this in turn would make the description in opensc.conf very brief.
Maybe like this: If you have a usb device, then you can go with the
defaults.

Regards
Andre

[1] http://www.usb.org/developers/devclass_docs/DWG_Smart-Card_CCID_Rev110.pdf
[2] http://pcsclite.alioth.debian.org/ccid_extended_apdu.html

___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] #269

2010-11-20 Thread Andre Zepezauer

BTW: This is *exactly* the subset of CCID readers NOT supporting 2048
bit keys. Because they can transmit only Short APDUs.

 261   Aktiv_Rutoken_Magistra.txt
 261   Gemalto_PDT.txt
 261   GnD_StarSignCardToken550.txt
 261   JCOP41V221.txt
 261   Oberthur-CosmoCard1.txt
 261   Oberthur-CosmoCard.txt
 261   Philips_SmartMX.txt
 271   ACR122U_PICC.txt
 271   Akasa_AK-CR-03.txt
 271   Aktiv_Rutoken_ECP.txt
 271   Alcor_SCR001.txt
 271   ATMEL_AT91SC192192CT-USB.txt
 271   ATMEL_AT91SO.txt
 271   ATMEL_AT98SC032CT.txt
 271   ATMEL_VaultIC420.txt
 271   ATMEL_VaultIC440.txt
 271   ATMEL_VaultIC460.txt
 271   AU9520.txt
 271   CardMan3021.txt
 271   CardMan3121.txt
 271   CardMan3621.txt
 271   CardMan3821.txt
 271   CardMan4321.txt
 271   CardMan5121.txt
 271   CardMan5125.txt
 271   CardMan5321.txt
 271   CardMan6121.txt
 271   CherrySmartBoardXX1X.txt
 271   CherrySmartTerminalXX1X.txt
 271   CherrySmartTerminalXX7X.txt
 271   CherryST1044U.txt
 271   CherryXX33.txt
 271   CherryXX44.txt
 271   Covadis_Auriga.txt
 271   FujitsuSiemens_SmartCard_Keyboard_USB_2A.txt
 271   FujitsuSiemens_SmartCard_USB_2A.txt
 271   GemPC433_SL.txt
 271   KAAN_SIM_III.txt
 271   mIDentity.txt
 271   Omnikey_noname1.txt
 271   Sitecom_MD-010.txt
 271   Smart_SBV280.txt
 271   SpringCard_CrazyWriter.txt
 271   SpringCard_CSB6_Basic.txt
 271   SpringCard_CSB6_Secure.txt
 271   SpringCard_CSB6_Ultimate.txt
 271   SpringCard_EasyFinger_Standard.txt
 271   SpringCard_EasyFinger_Ultimate.txt
 271   SpringCard_Prox_N_Roll.txt
 271   Teo.txt
 271   Todos_AGM2_CCID.txt
 271   Todos_Cx00.txt
 271   Vasco_DP905.txt
 271   Xiring_Leov2.txt
 271   Xiring_XI-SIGN_6000.txt
 271   Xiring_XI-SIGN.txt
 278   GemProxDU_contactless.txt
 278   GemProxSU_contactless.txt
 280   GnD_StarSignCardToken350.txt
 512   TianYu_CCID_SmartKey.txt
 512   VMware_Virtual_USB_CCID.txt
 2048  GoldKey_PIV_Token.txt


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

[opensc-devel] pkcs11-spy

2010-11-19 Thread Andre Zepezauer

Hello,

I would like to commit a change to pkcs11-spy, that changes the output
related to enquiries on attribute values (C_GetAttributeValue). The
reason for that change is that PKCS#11 defines a precise algorithm for
these enquiries. That algorithm depends for example on pointer
(NULL_PTR) and size of input-buffer.

The new output is more detailed and less verbose. And it makes tracing
of applications a little bit more easy. See attached file sample.txt.

The patch uses the following format string with variable sized hex-dump
of pointers:  sprintf(buf, 0x%0*lx / %ld, 2 * ptr_sz, ptr, buf_len);

It works well on Linux (32 and 64 bit). But does this kind of format
string would work on other platforms too? Other objections about that
patch?

Regards
Andre



===
Before:
===

47: C_GetAttributeValue
[in] hSession = 0x8a75080
[in] hObject = 0x8a74718
[in] pTemplate[1]: 
CKA_NETSCAPE_EMAIL(Netsc)   requested with 0 buffer
[out] pTemplate[1]: 
CKA_NETSCAPE_EMAIL(Netsc)   has size -1
Returned:  18 CKR_ATTRIBUTE_TYPE_INVALID

127: C_GetAttributeValue
[in] hSession = 0x8a75080
[in] hObject = 0x8a74718
[in] pTemplate[2]: 
CKA_ID  requested with 0 buffer
CKA_CLASS   requested with 0 buffer
[out] pTemplate[2]: 
CKA_ID  has size 12
CKA_CLASS   has size 4
Returned:  0 CKR_OK


128: C_GetAttributeValue
[in] hSession = 0x8a75080
[in] hObject = 0x8a74718
[in] pTemplate[2]: 
CKA_ID  requested with 12 buffer
CKA_CLASS   requested with 4 buffer
[out] pTemplate[2]: 
CKA_ID  [size : 0xC (12)]
344D656A ABBF1222 EC50B3A3
CKA_CLASS   CKO_CERTIFICATE  
Returned:  0 CKR_OK


==
After:
==

47: C_GetAttributeValue
[in] hSession = 0x8a73210
[in] hObject = 0x8a71fd0
[in] pTemplate[1]: 
CKA_NETSCAPE_EMAIL(Netsc)   0x / 0
[out] pTemplate[1]: 
CKA_NETSCAPE_EMAIL(Netsc)   0x / -1
Returned:  18 CKR_ATTRIBUTE_TYPE_INVALID

127: C_GetAttributeValue
[in] hSession = 0x8a73210
[in] hObject = 0x8a71fd0
[in] pTemplate[2]: 
CKA_ID  0x / 0
CKA_CLASS   0x / 0
[out] pTemplate[2]: 
CKA_ID  0x / 12
CKA_CLASS   0x / 4
Returned:  0 CKR_OK


128: C_GetAttributeValue
[in] hSession = 0x8a73210
[in] hObject = 0x8a71fd0
[in] pTemplate[2]: 
CKA_ID  0x08cf8ea8 / 12
CKA_CLASS   0x08cf8ec0 / 4
[out] pTemplate[2]: 
CKA_ID  0x08cf8ea8 / 12
344D656A ABBF1222 EC50B3A3
CKA_CLASS   CKO_CERTIFICATE  
Returned:  0 CKR_OK

Index: src/pkcs11/pkcs11-display.c
===
--- src/pkcs11/pkcs11-display.c	(revision 4877)
+++ src/pkcs11/pkcs11-display.c	(working copy)
@@ -84,6 +84,14 @@
 #define CKA_CERT_MD5_HASH		(CKA_TRUST + 101)
 
 
+static char *buf_spec(CK_VOID_PTR value, CK_ULONG size)
+{
+	static const size_t ptr_sz = sizeof(CK_VOID_PTR);
+	static char buf[64];
+	sprintf(buf, 0x%0*lx / %ld, 2 * ptr_sz, value, (CK_LONG) size);
+	return buf;
+}
+
 void print_enum(FILE *f, CK_LONG type, CK_VOID_PTR value, CK_ULONG size, CK_VOID_PTR arg)
 {
   enum_spec *spec = (enum_spec*)arg;
@@ -109,7 +117,7 @@
 {
   CK_ULONG i;
   if(size != (CK_LONG)(-1)  value != NULL) {
-fprintf(f, [size : 0x%lX (%ld)]\n, size, size);
+fprintf(f, %s\n, buf_spec(value, size));
 for(i = 0; i  size; i++) {
   if (i != 0) {
 	if ((i % 32) == 0)
@@ -153,7 +161,7 @@
   CK_ULONG i, j;
   CK_BYTE  c;
   if(size != (CK_LONG)(-1)) {
-fprintf(f, [size : 0x%lX (%ld)]\n, size, size);
+fprintf(f, %s\n, buf_spec(value, size));
 for(i = 0; i  size; i += j) {
   for(j = 0; ((i + j  size)  (j  32)); j++) {
 	if (((j % 4) == 0)  (j != 0)) fprintf(f,  );
@@ -862,20 +870,20 @@
 			if(ck_attribute_specs[k].type == pTemplate[j].type) {
 found = 1;
 fprintf(f, %s , ck_attribute_specs[k].name);
-if(pTemplate[j].pValue) {
+if(pTemplate[j].pValue  ((CK_LONG) pTemplate[j].ulValueLen)  0) {
 	ck_attribute_specs[k].display
 	(f, pTemplate[j].type, pTemplate[j].pValue,
 		pTemplate[j].ulValueLen,
 	ck_attribute_specs[k].arg);
 } else {
-	fprintf(f, has size %ld\n, pTemplate[j].ulValueLen); 
+	fprintf(f, %s\n, buf_spec(pTemplate[j].pValue, pTemplate[j].ulValueLen));
 }
 k = ck_attribute_num;
 			}
 		}
 		if (!found) {
 			fprintf(f, CKA_? (0x%08lx), pTemplate[j].type);
-			fprintf(f, has size %ld\n, pTemplate[j].ulValueLen); 
+			fprintf(f, %s\n, buf_spec(pTemplate[j].pValue, pTemplate[j].ulValueLen));
 		}
 	}
 }
@@ -891,13 +899,13 @@
   if(ck_attribute_specs[k].type == pTemplate[j].type) {
 	found = 1;
 	fprintf(f, %s , ck_attribute_specs[k].name);
-	fprintf(f, requested with %ld buffer\n,

[opensc-devel] #269

2010-11-10 Thread Andre Zepezauer

Hello Toni,

please could you try the attached patch. It should fix #269.

Regards
Andre

Index: libopensc/card.c
===
--- libopensc/card.c	(revision 4874)
+++ libopensc/card.c	(working copy)
@@ -216,11 +216,17 @@
 		card-name = card-driver-name;
 	*card_out = card;
 
-	/* Override card limitations with reader limitations */
-	if (reader-driver-max_recv_size  0)
-		card-max_recv_size = reader-driver-max_recv_size  card-max_recv_size ? reader-driver-max_recv_size : card-max_recv_size;
-	if (reader-driver-max_send_size  0)
-		card-max_send_size = reader-driver-max_send_size  card-max_send_size ? reader-driver-max_send_size : card-max_send_size;
+/*  Override card limitations with reader limitations.
+ *  Note that zero means no limitations at all.
+	 */
+if ((card-max_recv_size == 0) ||
+   ((reader-driver-max_recv_size != 0)  (reader-driver-max_recv_size  card-max_recv_size))) {
+card-max_recv_size = reader-driver-max_recv_size;
+}
+if ((card-max_send_size == 0) ||
+   ((reader-driver-max_send_size != 0)  (reader-driver-max_send_size  card-max_send_size))) {
+card-max_send_size = reader-driver-max_send_size;
+}
 
 	sc_debug(ctx, SC_LOG_DEBUG_NORMAL, card info: %s, %i, 0x%X\n,
 		card-name, card-type, card-flags);
Index: libopensc/ctx.c
===
--- libopensc/ctx.c	(revision 4874)
+++ libopensc/ctx.c	(working copy)
@@ -226,7 +226,7 @@
 	driver-max_send_size = 0;
 	driver-max_recv_size = 0;
 
-	conf_block = sc_get_conf_block(ctx, reader_driver, driver-name, 1);
+	conf_block = sc_get_conf_block(ctx, reader_driver, driver-short_name, 1);
 	
 	if (conf_block != NULL) {
 		driver-max_send_size = scconf_get_int(conf_block, max_send_size, driver-max_send_size);
___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] OpenSC PKCS#11 and Session Objects

2010-11-10 Thread Andre Zepezauer

Hello Douglas,

you should check if NSS does support ECDSA. If it does, then it should
verify the users certificate on its own. Calling a PKCS#11 provider for
doing it, is some kind of abuse. (See quotation below)

But if NSS tries to offload the verification to OpenSC, because it
doesn't has support for ECDSA, then you are in trouble. This is because
the recipient of your signed e-mail also would need OpenSC for
verification. Not practical I think.

PKCS#11 Section 6.2 Design goals:
Cryptoki was intended from the beginning to be an interface between
applications and all kinds of portable cryptographic devices [...] It is
not the goal of Cryptoki to be a generic interface to cryptographic
operations or security services [...]

Regards
Andre
 
On Wed, 2010-11-10 at 10:56 -0600, Douglas E. Engert wrote:
 Does OpenSC PKCS#11 support the creation of session objects?
 Has anyone looked at doing this?
 
 I bring this up as I am testing EC mods to OpenSC using
 Thunderbird to sign e-mail as a test. In my case, the user certificate
 is using ECDSA with a named curve, and the test CA is also using
 ECDSA to sign the user's certificate.
 
 Thunderbird 3.1.4 with NSS-3.12.x (x is at least 3) on Solaris 10
 tries to create a session public key, where the key is the public
 key of the CA. I think NSS is going to use this public key to verify
 the signature of the user's certificate asking the OpenSC PKCS#11
 ECDSA to do the verify. Depending on the card, this may have to be
 done in software.
 
 See the attached edited PKCS11-SPY output, showing mechanisms,
 open session, session info, and failed create object. Not shown
 are pin/login, and retrieval of the user certificate.
 
 PKCS#11 2.20 says : Table 4 R/O Public Session
 The application has opened a read-only session. The application
   has read-only access to public token objects and read/write access
   to public session objects.
 
 I don't think NSS does this if the CA is using RSA to sign
 the certificates, and I will try that next. (But eventually
 some CA will start using ECDSA to sign certificates.)
 
 Even if the ECDSA verify was to be added to OpenSC PKCS11,
 to be done in software, I would expect it might have to use
 OpenSSL to do the verification.
 
 ___
 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 PKCS#11 and Session Objects

2010-11-10 Thread Andre Zepezauer

On Wed, 2010-11-10 at 13:03 -0600, Douglas E. Engert wrote:
 
 On 11/10/2010 11:37 AM, Andre Zepezauer wrote:
  Hello Douglas,
 
  you should check if NSS does support ECDSA. If it does, then it should
  verify the users certificate on its own. Calling a PKCS#11 provider for
  doing it, is some kind of abuse. (See quotation below)
 
 I agree, but that is not what I am seeing.
 
 
  But if NSS tries to offload the verification to OpenSC, because it
  doesn't has support for ECDSA, then you are in trouble.
 
 Yes it has some support, as it knows how to list the algorithm and its
 parameters, as well as tell PKCS#11 to create the public key passing it
 the CKA_EC_POINT.
 
  This is because
  the recipient of your signed e-mail also would need OpenSC for
  verification. Not practical I think.
 
 Well I hope to find out in the next few days is it will try and use
 PKCS#11 for verification of signatures too, or find out of any of the
 Microsoft products can handle the e-mail too.

Some hints:

http://stackoverflow.com/questions/2228860/encrypting-a-message-using-ecdsa-in-openssl
http://mxr.mozilla.org/security/source/security/nss/lib/freebl/ec.c

 I also need to look at the PKCS#11 session to see if OpenSC somehow
 indicated to NSS that it could do verification.
 
 
  PKCS#11 Section 6.2 Design goals:
  Cryptoki was intended from the beginning to be an interface between
  applications and all kinds of portable cryptographic devices [...] It is
  not the goal of Cryptoki to be a generic interface to cryptographic
  operations or security services [...]
 
 Interesting, as Solaris 10 passes all its crypto through Solaris 
 Cryptographic
 Framework based on PKCS#11, so as to take advantage of any crypto hardware
 if available.
 
 http://docs.sun.com/app/docs/doc/816-4557/scf-1?l=ena=view
 
 
  Regards
  Andre
 
  On Wed, 2010-11-10 at 10:56 -0600, Douglas E. Engert wrote:
  Does OpenSC PKCS#11 support the creation of session objects?
  Has anyone looked at doing this?
 
  I bring this up as I am testing EC mods to OpenSC using
  Thunderbird to sign e-mail as a test. In my case, the user certificate
  is using ECDSA with a named curve, and the test CA is also using
  ECDSA to sign the user's certificate.
 
  Thunderbird 3.1.4 with NSS-3.12.x (x is at least 3) on Solaris 10
  tries to create a session public key, where the key is the public
  key of the CA. I think NSS is going to use this public key to verify
  the signature of the user's certificate asking the OpenSC PKCS#11
  ECDSA to do the verify. Depending on the card, this may have to be
  done in software.
 
  See the attached edited PKCS11-SPY output, showing mechanisms,
  open session, session info, and failed create object. Not shown
  are pin/login, and retrieval of the user certificate.
 
  PKCS#11 2.20 says : Table 4 R/O Public Session
  The application has opened a read-only session. The application
 has read-only access to public token objects and read/write access
 to public session objects.
 
  I don't think NSS does this if the CA is using RSA to sign
  the certificates, and I will try that next. (But eventually
  some CA will start using ECDSA to sign certificates.)
 
  Even if the ECDSA verify was to be added to OpenSC PKCS11,
  to be done in software, I would expect it might have to use
  OpenSSL to do the verification.
 
  ___
  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] rev 4853

2010-11-09 Thread Andre Zepezauer

On Mon, 2010-11-08 at 16:11 +0100, Nikos Mavrogiannopoulos wrote:
 On 11/08/2010 01:48 PM, Andre Zepezauer wrote:
 
  I'm interested in the security attributes, that are set when the file
  above is created. The simplest way to get these attributes is to use
  opensc-explorer:
 Here it is:
 
 $ opensc-explorer
 OpenSC Explorer version 0.12.0-rc1
 Using reader with a card: OmniKey CardMan 3121 00 00
 OpenSC [3F00]  cd 5015
 OpenSC [3F00/5015] info 4946
 
 Elementary File  ID 
 
 File path: 3F00/5015/4946
 File size: 128 bytes
 EF structure:  Transparent
 ACL for READ:N/A
 ACL for UPDATE:  N/A
 ACL for DELETE:  N/A
 ACL for WRITE:   N/A
 ACL for REHABILITATE:N/A
 ACL for INVALIDATE:  N/A
 ACL for LIST_FILES:  N/A
 ACL for CRYPTO:  N/A
 
 OpenSC [3F00/5015]

Thanks Nikos. It seems that the entersafe driver should be improved in
this direction. But with a APDU level specification under NDA, it's less
probable to happen soon.


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

Re: [opensc-devel] rev 4853

2010-11-08 Thread Andre Zepezauer

On Mon, 2010-11-08 at 08:49 +0100, Nikos Mavrogiannopoulos wrote:
 On Sun, Nov 7, 2010 at 8:07 AM, Andre Zepezauer
 andre.zepeza...@student.uni-halle.de wrote:
  Hello Nikos,
  please could you post the access conditions of 3F00/5015/4946. I wounder
  why the error code SC_ERROR_NOT_ALLOWED is returned. To me it seems,
  that r4853 has only discovered an older bug.
 Hello,
  I don't understand what you are asking here. If you can post more
 information, I could help.

I'm interested in the security attributes, that are set when the file
above is created. The simplest way to get these attributes is to use
opensc-explorer:

$opensc-explorer 
OpenSC [3F00] cd 5015
OpenSC [3F00/5015] info 4946

Elementary File  ID 4946

File path: 3F00/5015/4946
File size: 128 bytes
EF structure:  Transparent
ACL for READ:CHV1
ACL for UPDATE:  CHV1
ACL for DELETE:  CHV1
ACL for WRITE:   CHV1
ACL for REHABILITATE:CHV1
ACL for INVALIDATE:  CHV1
ACL for LIST_FILES:  N/A
ACL for CRYPTO:  N/A
Proprietary attributes:  00 
Security attributes: 01 01 01 01 01 01 01 00 00 

Regards
Andre


___
opensc-devel mailing list
opensc-devel@lists.opensc-project.org
http://www.opensc-project.org/mailman/listinfo/opensc-devel

1 2 3 >

1 - 100 of 208 matches

Mail list logo